좋은 에러 상태는 사용자를 막지 않고 회복시킨다

먼저 던질 질문

에러 화면은 어떤 정보를 제공해야 하는가

에러 상태의 목적은 실패를 알리는 데서 끝나지 않는다. 사용자가 직접 고칠 수 있는 오류인지, 기다려야 하는 오류인지, 다른 사람에게 요청해야 하는 오류인지 구분하게 해야 한다.

이 글에서는 원인 설명, 재시도, 대체 경로, 문의 연결을 중심으로 살펴본다. 좋은 에러 UX는 실패 원인보다 먼저 회복 가능성을 보여준다.

핵심 관점

좋은 에러 상태는 문제를 알리는 데서 끝나지 않고 회복 가능성을 설계한다. 사용자가 고칠 수 있는 오류와 기다려야 하는 오류는 완전히 다르게 말해야 한다.

그래서 에러는 하나의 상태가 아니라 여러 상태의 묶음이다. 입력 오류, 권한 오류, 네트워크 오류, 서버 오류, 정책 오류는 문구, 위치, 액션, 포커스 처리가 달라야 한다.

상태가 잘 읽히는 장면

네트워크 오류에서 재시도 버튼과 오프라인 상태 안내를 제공한다.

사용자는 자신의 문제인지 서비스 문제인지 구분할 수 있다.

권한 오류에서 관리자에게 요청하기 버튼을 제공한다.

막힌 상태가 행동 가능한 상태로 바뀐다.

좋은 에러 상태는 실패 사실을 알리는 데서 멈추지 않고, 현재 작업을 이어갈 수 있는 회복 경로를 먼저 보여준다.

사용자를 막는 상태

Internal Server Error 같은 기술 메시지만 보여준다.

결제 실패를 Toast로 잠깐 보여주고 사라지게 만든다. 사용자는 실패 원인과 해결 방법을 놓칠 수 있다.

상태 피드백 사례와 근거

좋은 에러는 원인보다 회복 경로를 먼저 보여준다

NN/g의 오류 메시지 가이드라인은 쉬운 언어, 정확한 문제 설명, 해결 제안을 강조한다. 오류가 발생했다는 말만으로는 사용자가 무엇을 고쳐야 하는지 알 수 없다.

결제 실패는 카드 정보 확인, 다른 결제 수단, 잠시 후 재시도를 나눠 제안해야 한다. 파일 업로드 실패도 용량 초과, 형식 불일치, 네트워크 실패를 구분해야 사용자가 스스로 회복할 수 있다.

실무 해석

WCAG의 Error Identification과 Error Suggestion 기준, GOV.UK의 Error message와 Error summary는 에러 UX가 문구뿐 아니라 위치, 링크, 포커스 이동의 문제임을 보여준다.

실제 제품 흐름으로 바꾸면 결제 실패, 파일 업로드 실패, 권한 없음, 네트워크 실패는 같은 Error 컴포넌트로 끝나면 안 된다. 결제 실패는 다른 수단이나 재시도를, 파일 업로드 실패는 실패한 파일과 제한 조건을, 권한 없음은 요청 경로를, 네트워크 실패는 입력 보존과 재시도를 보여줘야 한다.

피드백 설계 기준

에러 상태는 오류 원인보다 사용자가 지금 할 수 있는 행동을 기준으로 평가한다.

기준 1. 오류의 원인이 사용자 입력인지 시스템 문제인지 구분한다

사용자 입력 오류라면 문제 필드 가까이에 보여주고 수정 방법을 제안한다. 서버 오류라면 사용자가 고칠 수 없는 문제이므로 사용자를 탓하지 않고 재시도나 문의 경로를 제공한다.

기준 2. 재시도, 수정, 문의, 대체 경로 중 하나를 제공한다

오류 메시지는 행동과 연결되어야 한다. 네트워크 오류에는 재시도, 권한 오류에는 요청하기, 정책 오류에는 조건 확인, 입력 오류에는 수정 경로가 필요하다.

기준 3. 사용자를 탓하는 문장 대신 다음 행동을 안내한다

잘못 입력했습니다보다 카드 번호 16자리를 확인해 주세요가 낫다. 제품 책임의 실패라면 잠시 후 다시 시도해 주세요처럼 사용자가 할 수 있는 행동만 남기고 원인 추측을 강요하지 않는다.

기준 4. 오류의 위치와 심각도에 맞는 표시 방식을 고른다

필드 하나의 입력 오류는 해당 필드 근처에 보여주는 편이 좋다. 제출 전체가 실패했거나 여러 필드가 동시에 잘못된 경우에는 상단 오류 요약과 필드별 메시지를 함께 제공해야 한다. 결제 실패, 세션 만료, 권한 없음처럼 작업 전체를 막는 오류는 자동으로 사라지는 Toast보다 화면에 남는 안내가 적합하다.

자주 빠지는 함정

모든 오류를 같은 문구로 통일하면 운영은 편하지만 사용자는 아무것도 해결할 수 없다. 에러 메시지의 일관성은 같은 문장을 반복하는 것이 아니다.

고급 관점

에러 UX를 깊게 다루려면 에러를 하나의 상태로 뭉뚱그리면 안 된다. 사용자가 직접 고칠 수 있는 오류와 시스템이 해결해야 하는 오류는 문구, 위치, 액션, 접근성 처리가 모두 다르다.

실무에서는 최소한 아래처럼 나누어 보는 편이 좋다.

• 입력 오류: 사용자가 값을 수정하면 해결된다. 문제 필드 근처에 보여주고, 해결 방법을 함께 제공한다.
• 권한 오류: 사용자가 직접 고치기 어렵다. 권한 요청, 관리자 문의, 다른 계정 전환 같은 대체 경로가 필요하다.
• 네트워크 오류: 일시적 실패일 수 있다. 입력을 보존하고 재시도 가능성을 명확히 보여준다.
• 서버 오류: 사용자가 원인을 해결할 수 없다. 사용자 탓으로 읽히는 문장을 피하고, 다시 시도하거나 문의할 수 있게 한다.
• 정책 오류: 규칙 때문에 막힌 상태다. 어떤 조건을 만족해야 하는지 구체적으로 알려줘야 한다.

이 분류가 중요한 이유는 에러 메시지의 목적이 서로 다르기 때문이다. 입력 오류는 수정하게 해야 하고, 권한 오류는 요청하게 해야 하며, 네트워크 오류는 기다리거나 재시도하게 해야 한다. 모든 오류를 문제가 발생했습니다로 통일하면 운영은 편하지만 사용자는 아무것도 해결할 수 없다.

에러 상태 모델로 바꾸기

에러 상태는 코드에서도 구분되어야 한다.

• validationError: 사용자의 입력 수정이 필요한 상태
• permissionError: 권한 요청이나 계정 전환이 필요한 상태
• networkError: 재시도와 입력 보존이 필요한 상태
• serverError: 사용자가 해결할 수 없고 서비스 측 복구가 필요한 상태
• policyError: 제품 정책이나 비즈니스 규칙을 설명해야 하는 상태

이 구분은 문구뿐 아니라 포커스 이동과 테스트에도 영향을 준다. 폼 검증 실패라면 첫 번째 오류 필드로 포커스를 보낼 수 있지만, 서버 오류라면 페이지 상단 Alert나 Inline 메시지로 전체 상태를 알려주는 편이 더 적합하다.

테스트해야 할 흐름

• 입력 오류: 오류 필드, 오류 문구, 해결 안내가 연결되어 있는가
• 권한 오류: 막힌 이유와 권한 요청 경로가 있는가
• 네트워크 오류: 사용자의 입력이 사라지지 않고 재시도할 수 있는가
• 서버 오류: 사용자를 탓하지 않고 대체 행동이나 문의 경로를 제공하는가
• 오류 요약: 제출 실패 후 첫 오류로 이동하거나 해당 필드로 건너갈 수 있는가
• 접근성 경로: 오류 요약과 필드별 오류를 키보드와 스크린 리더로 확인할 수 있는가

추가로 비교할 상태

• 개발자 도구의 404/500, 결제 오류, 협업 도구의 연결 오류 사례를 비교한다
• 권한 없음 화면에서 요청하기 액션을 제공하는 사례를 찾는다
• 기술 메시지를 사용자 메시지로 바꾼 전후 예시를 만든다

상태 설계 질문

• 사용자가 직접 해결 가능한 오류와 불가능한 오류를 구분했는가
• 재시도, 문의, 대체 경로가 각각 언제 필요한지 설명했는가

FAQ

언제 쓰면 좋을까?

사용자가 작업을 계속하려면 실패 원인이나 회복 경로를 알아야 할 때 필요하다. 특히 결제, 저장, 권한 요청, 파일 업로드처럼 결과가 중요한 흐름에서는 에러 상태를 별도로 설계해야 한다.

언제 피해야 할까?

중요한 오류를 자동으로 사라지는 Toast에만 담는 것은 피한다. 사용자가 내용을 읽고 행동해야 한다면 화면 안에 남아 있는 메시지나 오류 요약이 필요하다.

구현할 때 먼저 볼 것은?

오류 유형을 먼저 나누는 일이다. validationError, permissionError, networkError, serverError, policyError를 구분하면 문구, 액션, 포커스 이동, 테스트 케이스가 달라진다.

출처

• Nielsen Norman Group, Error-Message Guidelines: https://www.nngroup.com/articles/error-message-guidelines/
• W3C, Web Content Accessibility Guidelines WCAG 2.2: https://www.w3.org/TR/WCAG22/
• GOV.UK Design System, Error message: https://design-system.service.gov.uk/components/error-message/
• GOV.UK Design System, Error summary: https://design-system.service.gov.uk/components/error-summary/