핵심 비유
'친절한 길 안내 vs 무뚝뚝한 통보' 비유 — 길을 잘못 들었을 때 "그쪽 아닙니다"라고만 하면 막막하다. "여기서 우회전하면 됩니다"라고 해주면 바로 해결한다. 앱 에러도 똑같다. "Error 500" 처럼 코드만 띄우면 사용자는 뭘 잘못했는지·어떻게 고치는지 모른다. 좋은 에러는 무엇이 잘못됐는지 + 어떻게 고치는지를 사람 말투로 알려준다. 에러 화면은 앱이 사용자를 대하는 '태도'가 드러나는 곳이다.
핵심 포인트
- 좋은 에러는 3가지를 준다 — 위치(어디가 틀렸나) + 이유(왜) + 해결(어떻게 고치나).
- 사람 말투로 — "Error: invalid input" ❌ → "올바른 이메일 형식으로 입력해 주세요" ✅.
- 입력 오류는 그 자리에서 표시 — 빨간 테두리 + 메시지를 해당 칸 옆에. 제출 후 전체가 사라지면 최악.
- '다시 시도' 버튼 필수 — 사용자가 막다른 길에 갇히지 않게.
- 잘못을 사용자 탓으로 몰지 않기 — "당신이 틀렸다"가 아니라 "이렇게 하면 됩니다" 톤.
- 가장 좋은 에러 처리는 에러가 안 나게 미리 막는 것 — 입력 규칙을 칸 옆에 미리 안내하고, 안 되는 날짜는 아예 못 고르게 비활성화한다(D2 상태 표시와 연결).
교사 팁
"올바른 이메일을 입력하세요" vs "Error: invalid input" 를 나란히 보여주고 "어떤 게 더 친절해?"를 물으면 좋은 에러의 조건이 바로 나온다(design-sense error-handling classGuide). 학생들이 실제로 겪은 황당한 에러 메시지를 모아 '명예의 전당'을 만들고 친절한 버전으로 고쳐 쓰게 하면 참여도가 높다. design-sense 퀴즈 탭으로 O/X 점검, 분석 탭으로 실제 앱 에러 화면을 평가한다.
좋은 예 vs 나쁜 예
- ✅ 빨간 테두리 + 메시지 + 해결 버튼: 어디가·왜·어떻게가 다 있음, 한 번에 해결. (design-sense
error-handling)
- ❌ "Error 500" 코드만: 뭐가 틀렸는지 모름, 사용자가 해결 불가, 신뢰 붕괴.
- ✅ 인터넷 끊김 화면: "연결이 불안정해요. 다시 시도" 버튼 + 친근한 일러스트 → 바로 재시도. ❌ 흰 화면에 영문 에러 한 줄만: 막다른 길, 사용자는 앱을 꺼버림.
실습·평가
- 실습: 무뚝뚝한 에러 3개("입력 오류", "Error 500", "실패")를 받아, 각각 '위치+이유+해결+사람말투'로 다시 쓰기. 짝과 교환해 친절도 평가.
- O/X 퀴즈: "에러는 'Error 500' 같은 코드만 정확히 보여주면 된다." → X (이유·해결을 사람 말투로 안내해야 함)