"기획서엔 없었는데요?" 개발자 당황시키는 예외 케이스(Edge Case) 정복하기
"기획서엔 없었는데요?" 개발자 당황시키는 예외 케이스(Edge Case) 정복하기
기획자가 가장 듣기 두려워하는 말은 대개 이겁니다.
“이 상황에선 어떻게 동작해야 하나요?”
해피 패스(Happy Path)는 반짝이게 만들었는데, 사용자는 네트워크 끊긴 골목도 걷고 결제 직전 뒤로 가기도 누릅니다.
이때 답이 없으면 개발은 “일단 이렇게 처리할게요”가 되고, 나중에 재작업(Rework)이 청구서처럼 날아옵니다. 🧾
이 글은 기획자가 반드시 챙겨야 할 4대 예외 시나리오를 기준으로, 기획서에 바로 붙여 넣을 템플릿과 What-if 체크리스트를 제공합니다. 목표는 하나, 소통 비용과 QA 리드타임을 줄이는 것입니다.
1) 예외 케이스(Edge Case)가 왜 중요한가요?
사용자는 우리가 의도한 대로만 움직이지 않습니다. 예외 케이스 처리가 미흡하면 보통 아래 3종 세트가 터집니다. “세트 메뉴 주문하셨죠?” 같은 느낌으로요.
- 무한 로딩: 데이터가 안 오는데 화면은 멈춘 척 웃고 있음
- 데이터 꼬임: 중복 클릭으로 결제 2회, 저장 2회, 분노 2배
- 불쾌한 UX: 에러는 났는데 유저가 다음 행동을 못 고름
예외 케이스는 “있으면 좋은 것”이 아니라, 제품 신뢰도를 지키는 안전벨트입니다. 특히 결제·가입·저장처럼 되돌리기 어려운 흐름에서 예외 정의는 거의 필수 스펙입니다.
2) 기획자가 예외 케이스를 설계할 때 쓰는 1장짜리 프레임
예외 케이스는 종류가 많아서, 기획서에 다 쓰려다 보면 끝이 없습니다. 대신 아래 6칸만 채우면 “개발자가 구현할 수 있는 수준”까지 정리가 됩니다.
Trigger무슨 계기로 발생했나(네트워크 끊김, 뒤로가기, 중복 클릭)
State그 순간 시스템 상태는 무엇인가(결제 요청 전/후, 저장 중, 토큰 만료)
UI사용자에게 무엇을 보여주나(스켈레톤, 팝업, 토스트, 빈 화면)
Action사용자가 할 수 있는 다음 행동은 무엇인가(재시도, 취소, 고객센터)
Recovery복구 정책은 무엇인가(이전 데이터 유지, 롤백, 재조회)
Logging추적은 어떻게 남기나(에러 코드, 요청 ID, 재현 단서)
이 프레임을 쓰면 “그때 알아서”가 아니라 “그때 이렇게”로 바뀝니다. 개발자도, QA도 행복해져요.
3) 기획자가 반드시 챙겨야 할 4대 예외 시나리오
① 네트워크 및 데이터 로딩 (Loading & Error)
데이터는 항상 순식간에 나타나지 않습니다. 로딩은 기본 상태고, 에러는 현실입니다. 기획서에 아래를 명확히 적어두면 “무한 로딩” 확률이 급감합니다.
- 로딩 UI: 스켈레톤 UI vs 스피너, 어떤 화면을 몇 초까지 보여줄지
- 타임아웃 기준: 예) 10초 이상이면 “연결이 원활하지 않습니다” 안내
- 에러 분기: 서버 500(점검/일시 오류) vs 인증 만료(로그인 유도) vs 404(삭제/비공개)
- 재시도 정책: “다시 시도” 버튼 제공 여부, 자동 재시도 횟수
기획서에 넣기 좋은 한 문장 예시
“API 실패 시(HTTP 500), 안내 팝업을 노출하고 다시 시도 버튼을 제공한다. 재시도 실패가 3회 이상이면 고객센터 연결 CTA를 노출한다.”
② 빈 화면 처리 (Empty States)
“데이터가 0개일 때”는 기획서에서 가장 자주 누락됩니다. 그리고 유저는 가장 자주 만납니다. 빈 화면은 하얀 캔버스가 아니라, 다음 행동을 안내하는 표지판이어야 합니다.
- 메시지: “검색 결과가 없습니다” 같은 사실 + 이유 힌트(필터/철자) + 다음 행동
- 대체 행동: 인기 키워드, 추천 상품/콘텐츠, 필터 초기화, 둘러보기 버튼
- 초기 상태: 첫 방문(아직 아무것도 안 함)과 결과 없음(했는데 없음)은 메시지가 달라야 함
체크 포인트
“장바구니가 비었을 때, 단순 안내만 할지, 추천/베스트/최근 본 상품으로 ‘다음 클릭’을 설계할지”를 결정하세요.
③ 사용자 입력 오류 (Validation)
유저는 기획자가 원하지 않는 값을 넣기도 합니다. 가끔은 실수고, 가끔은 실험이고, 가끔은… 그냥 손이 빠릅니다. 중요한 건 “어떤 순간에, 어떤 톤으로, 어떻게 막을 것인가”입니다.
- 검증 시점: 실시간(입력 중) vs 제출 시점(확인 버튼 클릭)
- 버튼 정책: 조건 미충족 시
확인비활성화 vs 누르면 오류 안내 - 문구 정책: 무엇이 문제인지(형식/길이/금지문자)와 해결 방법을 함께
- 데이터 손실 방지: 오류로 화면 이동/새로고침 시 입력값 유지 여부
실무에서 자주 깨지는 지점
“한글만 허용” 같은 규칙이 있으면, 붙여넣기/자동완성/이모지/공백/줄바꿈까지 같이 정의해야 합니다.
④ 중간 이탈 및 중복 액션 (Interruption)
가장 골치 아픈 건 “상태” 문제입니다. 결제 중 뒤로가기, 저장 중 탭 닫기, 버튼 광클 같은 것들. 여기서 스펙이 비면, QA에서 귀신처럼 다시 등장합니다.
- 중복 클릭: 버튼 비활성화(Disabled) + 로딩 표시 + 완료 후 성공 화면 고정
- 뒤로가기/이탈: 진행 중 이탈 시 경고 팝업 여부, 이탈해도 데이터가 안전한지
- 재진입: 저장/결제가 “진행 중이었음”을 감지하면 어떤 화면으로 유도할지
- 결제/주문: 성공/실패/미확인의 3상태(특히 PG 응답 지연)를 분리해서 정의
핵심 질문(이거 하나로 회의가 정리됨)
“사용자가 이탈했을 때, 서버의 진실은 무엇인가요? 결제가 됐나요, 안 됐나요, 아직 모르는 건가요?”
4) [템플릿] 기획서에 “한 줄” 더 넣기
기능 명세 옆에 아래 표를 붙여보세요. 개발자는 구현 기준이 생기고, QA는 테스트 케이스가 바로 나옵니다. 기획서는 갑자기 “말이 되는 문서”가 됩니다. (마법 아님, 구조의 힘) 🧩
| 구분 | 상황 (Case) | 기대 동작 (Expectation) |
|---|---|---|
| Empty | 검색 결과가 없는 경우 | ‘검색 결과가 없습니다’ 안내 + 인기 키워드 추천 + 필터 초기화 버튼 제공 |
| Error | API 호출 500 에러 발생 시 | 서비스 점검 안내 팝업 노출 + ‘다시 시도’ 버튼 + 고객센터 연결 CTA |
| Action | 등록 버튼 클릭 후 대기 중 | 버튼 Disabled 처리 + 로딩 상태 표시 + 요청 완료 시 성공 토스트 및 화면 갱신 |
| Limit | 텍스트 200자 초과 입력 시 | 입력창 테두리 강조 + 초과 안내 문구 + 초과분 자동 절삭(또는 입력 차단) 정책 명시 |
보너스: What-if 체크리스트(필수만 추림)
- 로딩이 10초 이상 지속되면 무엇을 보여주나?
- 네트워크가 끊겼다 다시 연결되면 자동 재시도하나?
- 빈 상태가 “첫 방문”인지 “결과 없음”인지 구분하나?
- 중복 클릭을 UI만 막는가, 서버도 함께 고려하는가?
- 결제 결과가 “미확인”일 때 사용자에게 뭐라고 안내하나?
- 에러가 났을 때 사용자가 할 수 있는 다음 행동이 최소 1개는 있는가?
5) 결론: 디테일이 곧 실력입니다
“그건 개발자가 알아서 해주겠지”는 위험한 주문입니다. 예외 상황 정의가 없으면 개발자는 임의로 처리하게 되고, 나중에 “기획 의도와 다르다”는 말과 함께 재작업(Rework)으로 되돌아옵니다.
기획 단계에서 ‘만약에(What if)’를 한 번 더 고민하는 습관이 프로덕트의 품격을 결정합니다. 해피 패스는 프로덕트를 움직이게 하고, 예외 케이스는 프로덕트를 살아남게 합니다.
FAQ
Q예외 케이스(Edge Case)는 어디까지 정의해야 하나요?
A 빈도(자주 발생)와 리스크(치명도)로 우선순위를 잡으세요. 예: 빈 목록, 네트워크 불안정은 빈도가 높고, 결제·저장·가입은 리스크가 큽니다. 우선 “자주 만나거나 크게 다치는 구간”부터 정의하면 효율이 좋습니다.
Q에러 문구는 어떤 원칙으로 써야 하나요?
A 최소 3가지를 포함하세요. (1) 무슨 일이 일어났는지 (2) 사용자가 다음에 무엇을 하면 되는지 (3) 데이터가 안전한지. 문구는 길어도 괜찮습니다. 유저는 시를 읽는 게 아니라 길을 찾는 중이니까요.
Q중복 클릭(Double Click) 방지는 어떻게 설계하나요?
A UI에서 버튼을 Disabled 처리하는 것만으로는 부족할 수 있습니다. 기획서에는 (1) 버튼 상태(로딩/비활성화) (2) 완료 후 화면 고정/재진입 정책 (3) 서버 측 중복 처리 기준(가능하면)을 함께 적어두면, 결제나 저장 같은 흐름에서 사고 확률이 크게 줄어듭니다.
Q참고할 만한 UX 가이드가 있나요?
A 아래 문서들은 “에러/피드백/상태” 설계 기준을 잡는 데 도움이 됩니다.