화면만 예쁘고 서버가 약한 프로젝트의 실패 신호

시안 발표 때 모두가 만족하던 화면이, 오픈 직전에 분위기가 바뀌는 경우가 있습니다.

“목록이 느리다”, “결제가 가끔 두 번 잡힌다”, “관리자에서 수정해도 앱에 안 반영된다” 같은 이야기입니다. 원인은 종종 디자인 품질이 아닙니다. 보이는 화면(프론트)과 서버·데이터·권한(백엔드)의 균형이 무너진 상태인 경우가 많습니다.

발주 입장에서는 화면이 가장 이해하기 쉽습니다. 그래서 평가도 화면에 치우칩니다. 제작 쪽도 시안·퍼블리싱 진척이 눈에 보이니 보고가 쉽습니다.

그 사이 서버와 앱이 데이터를 주고받는 약속(API), 권한, 로그, 배포는 “나중에 붙이면 된다”로 밀립니다. 결과적으로 예쁜 껍데기 + 약한 서버 조합이 생기고, 실패 신호는 오픈 직전에야 한꺼번에 드러납니다.

왜 이런 일이 생기나요?

아래 항목이 여러 개 겹치면, 일정 문제보다 구조 리스크로 보는 편이 안전합니다.

1) 서버와 화면이 주고받는 약속이 문서에 없다

화면은 완성됐는데 “어떤 정보를 어떤 조건으로 받는지”가 채팅 기록에만 있으면, 앱·웹·관리자가 서로 다른 가정을 하게 됩니다. 필드명 하나 바뀌어도 세 군데가 깨집니다.

2) 목록·검색을 전부 휴대폰·브라우저에서 처리한다

초기 데이터가 적을 때는 괜찮아 보입니다. 데이터가 늘면 앱이 멈추거나 배터리를 소모합니다. 서버에서 걸러 주지 않으면 보안 구멍도 생깁니다. “일단 다 받아와서 화면에서 걸러요”는 데모용 패턴에 가깝습니다.

3) 권한 검사가 화면에만 있다

버튼을 숨겼다고 관리자 기능을 막은 것은 아닙니다. 실제 보호는 서버에서 이뤄져야 합니다. 화면만 예쁜 프로젝트는 권한 검사가 허술하거나 아예 없는 경우가 많습니다.

4) 결제·주문 상태가 화면 표시에만 묶여 있다

“결제 완료 버튼을 누르면 주문 완료로 표시”처럼, 서버 확정 없이 화면 상태만 바꾸는 구현은 장애·환불·중복 결제에서 비용이 큽니다. 돈과 재고는 화면이 아니라 서버가 확정한 기록이어야 합니다.

5) 에러가 사용자에게 “잠시 후 다시”만 보인다

원인은 서버 지연, 입력 검증 실패, 권한 오류, 결제 실패 등 다양합니다. 기록 없이 같은 메시지만 띄우면 운영이 어렵습니다.

6) 관리자와 사용자 앱이 다른 규칙을 쓴다

관리자에서 할인을 넣었는데 앱 계산과 다르거나, 재고가 따로 노는 경우입니다. 공통 규칙이 서버에 없고 화면마다 계산하면 발생합니다.

이렇게 보면 쉬워요

기술 용어를 몰라도 아래는 확인할 수 있습니다.

1. 목록에 들어갈 때 요청이 비정상적으로 많은가? 같은 호출을 화면마다 반복하는가?
2. 일반 사용자 계정으로 관리자 주소·기능을 호출했을 때 서버가 거절하는가?
3. 결제·저장 버튼을 두 번 눌렀을 때 주문이 두 건 생기는가?
4. 관리자에서 상품명·가격을 바꾸면 앱/웹에 예측 가능하게 반영되는가?
5. 결제 창을 닫거나 통신을 끊었을 때 주문 상태가 모순 없이 남는가?
6. “데이터가 1만 건이면?”에 대한 답이 “그때 최적화”뿐인가, 이미 페이지를 나누어 가져오는가?

이렇게 준비하면 좋아요

주간 보고에 막대를 하나만 두지 말고 둘로 나누면, 화면 편중을 일찍 발견할 수 있습니다.

• 표현 진척
  
  시안 확정, 퍼블리싱, 화면 전환, 반응형
• 계약 진척
  
  데이터 약속, 권한 시나리오, 결제/주문 상태, 관리자 동일 규칙, 테스트 서버 배포

표현 진척만 90%이고 계약 진척이 30%라면, 데모는 가능해도 오픈은 위험합니다. 반대로 계약 진척이 앞서고 표현이 늦는 팀은 일정 압박은 있어도 사고형 실패 확률은 낮습니다.

발주자는 “예쁜가?”와 별개로 계약 진척 질문을 매주 한 개 이상 하면 됩니다. 예: “이번 주 통과한 실패 시나리오는 무엇인가?”, “관리자 수정이 앱에 반영되는 경로를 한 문장으로 설명해 달라.”

외주 계약서의 중간 납품도 화면만으로 묶지 않는 것이 좋습니다. “목록을 나눠 가져오고 권한이 적용됨”, “결제 실패 시 주문 상태 정의 완료”처럼 서버 산출물 중간 목표를 섞으면 화면만 앞서가는 구조를 계약이 제어합니다.

소수 인원 팀이라도 역할이 문서에 없으면, 실제로는 화면 작업자 한 명에게 서버까지 몰리는 구조가 됩니다.

자주 하는 실수

화면만 보고 업체를 고르면 초기 만족도는 높을 수 있습니다. 비용은 보통 오픈 전후 3~12개월에 집중됩니다.

• 성능 이슈로 긴급 서버 증설·조회 재작성
• 권한·개인정보 사고로 인한 대응·공지·법률 비용
• 결제 불일치 정산·고객센터 폭주
• 화면 전면 개편과 별개로 서버 재구축(사실상 이중 비용)
• 스토어 심사·보안 점검에서 막혀 마케팅 일정 붕괴

“디자인 잘하는 팀”과 “서비스 운영 가능한 팀”은 겹칠 수 있습니다. 다만 평가 기준을 화면 완성도에만 두면 후자를 걸러내지 못합니다.

• □ 주요 요청/응답 필드가 문서 또는 이슈로 존재한다
• □ 목록·검색·권한 필터가 서버에서 이뤄진다
• □ 결제·주문·재고 등 핵심 상태가 서버 기준으로 정의되어 있다
• □ 관리자·사용자·외부 연동이 같은 업무 규칙을 참조한다
• □ 중복 제출·타임아웃·부분 실패 시나리오가 검수 항목에 있다
• □ 로그로 장애 재현이 가능한 최소 수준이 오픈 범위에 포함된다
• □ 화면 진척 %와 서버 시나리오 통과를 별도 지표로 본다
• □ “나중에 서버 붙이면 됩니다”가 핵심 경로에 남아 있지 않다

LB Contents는 앱·홈페이지·쇼핑몰의 화면과 서버·운영 구조를 한 흐름으로 설계합니다. 시안은 있는데 권한·결제 경계가 불안한 단계에서도 점검 상담이 가능합니다.