Back_to_Basics

{3줄 요약}

에러 순간은 사용자가 이미 막힌 상태라, 대응이 신뢰를 지키거나 깨뜨리는 갈림길이에요.
메시지는 상태 통보가 아니라 목표까지 이어주는 회복 안내가 되어야 해요.
"에러가 발생했습니다" 같은 막연한 말 대신 무엇이 왜 꼬였고 어떻게 풀 수 있는지가 담겨야 진짜 에러 메시지예요.

이 방법이 필요한 순간이에요

폼 입력 오류, 로그인 실패, 결제 실패, 네트워크 오류, 빈 상태(empty state), 권한 없음 — 사용자가 원하는 것을 얻지 못하는 모든 순간에 에러 UX가 적용돼요.

에러 UX는 화면 설계 단계에서 종종 빠져요.
"행복한 경로(happy path)"만 설계하고 오류 상황은 나중에 생각하는 거예요.
하지만 실제 서비스에서 사용자는 자주 오류를 만나요.
이 순간들이 모여 전체 경험의 품질을 만들어요.

실행 순서를 이렇게 나눠요

1단계 — 오류를 예방할 수 있는지 먼저 확인하기

가장 좋은 에러 UX는 에러가 안 나는 거예요.

오류 예방 방법들:

제약 두기: 날짜 입력에 달력 피커를 제공하면 날짜 형식 오류가 사라져요
인라인 유효성 검증: 비밀번호 강도를 실시간으로 보여주면 "너무 짧습니다" 오류를 방지해요
확인 요청: 되돌릴 수 없는 행동(삭제, 결제 확정)은 한 번 더 확인해요
스마트 기본값: 자주 쓰는 선택지를 기본값으로 설정해요

카카오뱅크에서 이체 금액을 입력할 때 한도를 넘으면 제출하기 전에 바로 알려줘요.
결제를 시도하다 실패하는 불쾌한 경험 대신, 입력 중에 예방해줘요.

2단계 — 오류 메시지 세 요소 갖추기

예방했지만 그래도 오류가 났다면, 좋은 메시지가 필요해요.

무엇이 잘못됐는가 (What): 어느 필드에서, 어떤 오류인지 구체적으로.

❌ "입력 오류가 있습니다"
✅ "이메일 주소가 올바르지 않아요"

왜 그런가 (Why): 가능하면 이유를 설명해요.

❌ "비밀번호가 맞지 않습니다"
✅ "비밀번호가 일치하지 않아요. 대소문자를 확인해보세요"

어떻게 해결하나 (How): 다음 행동을 안내해요.

❌ "카드 결제에 실패했습니다"
✅ "카드 결제에 실패했어요. 카드 번호를 다시 확인하거나, 다른 카드를 사용해보세요"

세 가지가 모두 있을 필요는 없어요.
상황에 따라 Why는 생략 가능하지만, What과 How는 항상 있어야 해요.

3단계 — 오류 위치와 시각 처리 결정하기

인라인 오류 (Inline Error): 폼에서 특정 필드 오류는 그 필드 바로 아래에 표시해요.
오류가 어디에 있는지 한눈에 보여야 해요.

요약 오류 (Summary Error): 여러 필드에 오류가 있을 때, 또는 제출 후 전체 오류를 위에서 요약해줄 때 써요.
"3개 항목을 수정해주세요"처럼요.
인라인 오류와 함께 쓰면 더 좋아요.

색과 아이콘: 오류는 빨간색 + 느낌표 아이콘이 관례예요.
색맹 사용자를 위해 색만으로 오류를 표시하면 안 되고, 아이콘이나 텍스트를 함께 써야 해요.

포커스 이동: 제출 후 오류가 발견되면 첫 번째 오류 필드로 자동으로 포커스를 이동시켜요.
사용자가 스크롤로 오류를 찾아야 하는 상황을 없애요.

4단계 — 네트워크·시스템 오류 처리하기

폼 오류가 아닌 오류도 있어요.
인터넷이 끊겼거나, 서버가 응답하지 않거나, 타임아웃이 났을 때예요.

이 경우 사용자가 입력한 내용을 잃지 않게 해야 해요.
페이지를 새로고침하거나 뒤로 가면 입력한 게 사라지는 경험은 큰 불만을 만들어요.

오류 메시지 예시:

네트워크 오류: "인터넷 연결을 확인해주세요. 연결 후 다시 시도하면 돼요"
서버 오류: "일시적인 오류예요. 잠시 후 다시 시도해주세요 (또는 고객센터: 1234-5678)"
타임아웃: "시간이 너무 오래 걸렸어요. 다시 시도해볼까요?" + [다시 시도] 버튼

5단계 — 빈 상태도 에러처럼 다루기

엄밀히 오류는 아니지만 빈 상태도 사용자가 원하는 것을 못 얻는 순간이에요.

장바구니가 비어있을 때, 검색 결과가 없을 때, 아직 아무것도 만들지 않은 대시보드 — 이런 화면을 그냥 "비어있음"으로 두면 사용자가 뭘 해야 할지 몰라요.

좋은 빈 상태는:

왜 비어있는지 설명해요 (아직 주문이 없어요)
다음 행동을 제안해요 (메뉴 둘러보기 버튼)
때로는 분위기 있는 일러스트로 덜 삭막하게 만들어요

토스에서 거래 내역이 없을 때 "아직 거래 내역이 없어요. 첫 이체를 해볼까요?" + 이체 버튼이 있어요.
빈 상태를 온보딩 기회로 활용한 거예요.

하지 말아야 할 것

사용자를 탓하는 말을 쓰지 마세요: "잘못 입력하셨습니다", "올바르지 않은 형식입니다"는 사용자의 잘못처럼 들려요.
"이 형식으로 입력해주세요"로 바꿔요.

오류를 기술적 용어로 설명하지 마세요: "HTTP 500 Internal Server Error", "NullPointerException" — 사용자에게 의미 없는 용어예요.
사람 말로 바꿔요.

성공처럼 보이는 오류를 만들지 마세요: 오류 메시지가 하얀 배경에 작은 글씨로 있으면 사용자가 "됐나 보다"라고 오해해요.
오류는 명확하게 눈에 띄어야 해요.

실행 후 확인하기

예방 가능한 오류를 설계 단계에서 막았나요?
오류 메시지에 What + How가 포함되어 있나요?
오류가 해당 필드 바로 근처에 표시되나요?
색만이 아니라 아이콘·텍스트로도 오류를 표현했나요?
네트워크 오류 시 사용자 입력이 보존되나요?
빈 상태에 다음 행동 안내가 있나요?

참고 문헌

Alan Cooper, 《About Face》(2014) — 오류 처리와 예방 중심 설계 원칙의 이론적 기반이에요.
Jakob Nielsen, 10 Usability Heuristics — https://www.nngroup.com/articles/ten-usability-heuristics/ — #5 Error Prevention, #9 Help Users Recognize and Recover from Errors가 이 아티클의 핵심이에요.