오류 메시지는 사과문이 아니다: 다시 시도할 수 있게 만드는 UX/UI

“오류가 발생했습니다. 다시 시도해주세요.”

익숙한 문장이지만, 이 메시지를 본 사용자는 여전히 세 가지를 모릅니다. 무엇이 문제인지, 자신이 무엇을 바꿔야 하는지, 방금 입력한 내용은 남아 있는지입니다.

오류 메시지는 실패를 선언하는 문구가 아니라 다음 행동을 안내하는 인터페이스입니다. 이번 글에서는 GOV.UK 디자인 시스템과 W3C의 WCAG 2.2 해설을 바탕으로, 폼과 오류 상태를 설계할 때 놓치기 쉬운 지점을 정리합니다. 아래 한국어 문구와 제품 상황은 원문의 번역이 아니라 실무 적용을 위한 가상 예시입니다.

한 줄 요약

좋은 오류 UX는 “무엇이 잘못됐는지”를 알려주는 데서 끝나지 않습니다. 고칠 위치를 보여주고, 입력한 내용을 지키고, 다음 행동으로 연결합니다.

1. 먼저, 누가 해결할 수 있는 문제인지 구분하세요

모든 실패를 빨간 입력창으로 표현하면 책임 소재가 흐려집니다. 이메일 형식이 맞지 않는 상황과 서버가 응답하지 않는 상황은 사용자가 해야 할 행동부터 다릅니다.

• 입력 오류: 수정할 항목과 허용 형식을 안내합니다. 예: “이메일 주소에 @와 도메인을 포함해 입력해 주세요. 예: name@example.com”
• 서비스 장애: 사용자의 입력을 탓하지 않고 서비스 상태와 가능한 다음 경로를 설명합니다.
• 권한·이용 조건 문제: 값을 다시 적게 하기보다, 이용할 수 없는 이유와 신청·문의 등 실제 제공되는 대안을 안내합니다.

GOV.UK의 검증 패턴도 입력 검증을 서비스 이용 자격이나 권한 확인과 구분합니다. 사용 자격이 없다면 필드 오류를 반복해서 보여주기보다 상황과 다음 행동을 설명하는 화면으로 안내하라는 취지입니다.

디자인 리뷰 질문: “이 화면에서 사용자가 바꿀 수 있는 것이 있는가?” 없다면 입력 오류 문구가 아니라 서비스 상태 안내를 설계해야 할 수 있습니다.

2. ‘올바르게 입력하세요’ 대신 수정할 단서를 주세요

“유효하지 않은 값입니다”는 시스템의 판정입니다. 사용자가 필요한 것은 다음 시도에 쓸 수 있는 정보입니다.

예를 들어 PDF 또는 JPG, 최대 10MB라는 업로드 정책을 가진 서비스를 가정해보겠습니다.

• 부족한 문구: “파일을 업로드할 수 없습니다.”
• 형식 오류일 때: “PDF 또는 JPG 파일을 선택해 주세요.”
• 용량 오류일 때: “파일 크기가 10MB를 초과했습니다. 10MB 이하의 파일을 선택해 주세요.”

정책이 있다는 사실만 나열하는 것보다, 실제로 실패한 조건을 특정하는 편이 수정에 도움이 됩니다. 다만 시스템이 확인하지 못한 원인을 단정해서는 안 됩니다. 연결 문제인지 형식 문제인지 모르는 상황에서 “파일이 손상되었습니다”라고 말하면 사용자는 엉뚱한 곳을 고치게 됩니다.

WCAG의 3.3.1 Error Identification은 자동으로 감지한 입력 오류의 항목을 식별하고 텍스트로 설명하는 레벨 A 기준입니다. 3.3.3 Error Suggestion은 수정 방법을 알고 있다면 제안을 제공하는 레벨 AA 기준입니다. 단, 보안이나 콘텐츠의 목적을 해치는 경우는 예외입니다.

즉, 구체적일수록 항상 좋은 것은 아닙니다. 로그인이나 계정 복구에서는 계정 존재 여부 같은 민감한 정보를 드러내지 않는지 보안 정책과 함께 검토해야 합니다.

3. 문구와 함께 ‘보이는 위치’를 설계하세요

저장 버튼을 누른 뒤 화면 아래에 토스트가 잠깐 나타났다가 사라졌다고 해보겠습니다. 폼은 길고, 오류가 있는 입력창은 위쪽에 있습니다. 메시지가 친절하더라도 사용자는 어디로 돌아가야 하는지 찾아야 합니다.

GOV.UK의 오류 요약 컴포넌트는 검증 실패 시 페이지 위쪽에 오류를 모아 보여주고, 각 항목에서 문제가 있는 입력으로 이동할 수 있도록 연결합니다. 해당 패턴에서는 오류 요약으로 키보드 포커스를 옮기고, 요약 문구와 입력창 옆 문구를 일치시키도록 안내합니다.

이 구조를 우리 제품에 적용한다면 두 역할을 분리해볼 수 있습니다.

• 전체 안내: “수정할 항목이 2개 있습니다.”처럼 남은 작업을 파악하게 합니다.
• 입력창 옆 안내: 어떤 값을 어떻게 바꿀지 설명합니다.

이때 “2개” 같은 수치는 실제 검증 결과와 일치해야 합니다. 빨간 테두리만으로 오류를 알리지 말고 텍스트 설명을 함께 제공하며, 개발 명세에는 입력과 오류 설명의 프로그램적 연결도 포함합니다.

모든 앱에 GOV.UK의 화면 구성을 그대로 복제해야 한다는 뜻은 아닙니다. 이는 특정 디자인 시스템의 구현 패턴이지, 모든 제품에 동일한 오류 요약 UI를 요구하는 WCAG 조항은 아닙니다. 중요한 것은 사용자가 오류를 인지하고 수정할 곳에 도달할 수 있는가입니다.

4. 사용자가 쓰는 중인지, 제출한 뒤인지 구분하세요

이메일 입력창에 첫 글자를 넣자마자 빨간 경고가 나타나는 경험을 떠올려보세요. 아직 입력을 끝내지 않았는데 시스템은 계속 실패라고 말합니다.

GOV.UK는 기본적으로 사용자가 다음 단계로 진행하거나 제출하려는 시점에 검증하고, 단순히 필드를 벗어났다는 이유로 검증하지 않도록 권고합니다. 입력 중 검증은 사용자 조사에서 그 이점이 확인되는 경우에 추가하라는 입장입니다. 글자 수 제한처럼 오래 작성한 뒤에야 문제를 알게 되는 상황은 별도로 고려할 수 있습니다.

이를 “실시간 검증은 언제나 나쁘다”로 받아들일 필요는 없습니다. 제품의 과업에 맞춰 다음 상태를 구분해보는 것이 실무적으로 유용합니다.

1. 입력 전: 필요한 조건과 예시를 미리 보여줍니다.
2. 입력 중: 아직 완성되지 않은 값을 성급하게 실패로 규정하지 않습니다.
3. 제출 후: 확인된 문제를 구체적으로 안내합니다.
4. 수정 후: 오래된 오류가 그대로 남지 않도록 재검증 시점을 정의합니다.

시안에는 빨간 상태 하나만 남기지 마세요. “언제 나타나고, 무엇을 고치면 사라지는가”까지 있어야 동작이 완성됩니다.

5. 입력값 보존도 오류 UX의 일부입니다

이름, 연락처, 요청 사항을 모두 입력했는데 하나의 오류 때문에 폼이 비어버리면 어떨까요. 사용자는 잘못된 한 항목이 아니라 전체 작업을 다시 해야 합니다.

GOV.UK 검증 패턴은 오류가 발생해도 사용자가 입력한 값이 채워진 상태로 폼을 다시 보여주도록 안내합니다. 무엇이 잘못됐는지 확인하고, 이전 답을 수정하며, 재입력을 줄이기 위해서입니다.

실무에서는 “내용이 보존됩니다”라는 문구를 넣는 것보다 실제 동작을 먼저 확인해야 합니다.

• 오류가 난 항목뿐 아니라 정상적으로 입력한 값도 남는가?
• 뒤로 가기나 재시도 후에도 보존 범위가 일관적인가?
• 파일을 다시 선택해야 한다면 그 사실을 명확히 알려주는가?
• 비밀번호나 결제 정보처럼 보안상 별도 취급이 필요한 값은 정책에 맞게 처리하는가?

또 하나의 제안은 검증 오류와 결과를 확인하지 못한 상태를 구분하는 것입니다. 특히 결제나 예약에서 응답이 끊겼다는 이유만으로 “처리되지 않았습니다”라고 단정하면 위험할 수 있습니다. 먼저 처리 상태를 확인할 경로와 중복 실행 방지 동작을 팀과 정의해야 합니다. 이는 위 문서를 그대로 옮긴 요구사항이 아니라, 실패 상태 설계를 확장한 실무 제안입니다.

6. 오류율만 줄이지 말고, 복구할 수 있는지 확인하세요

오류 메시지를 개선한 효과를 보려면 “오류가 몇 번 발생했는가”만으로는 부족합니다. 입력 정책이 달라지면 오류 수 자체가 달라질 수 있고, 메시지가 잘 보여도 다음 단계로 이어지지 않을 수 있습니다.

팀에서 다음 지표를 함께 관찰해볼 수 있습니다. 아래는 공식 표준 지표가 아닌 운영 제안입니다.

• 오류 후 완료율: 오류를 경험한 시도 중, 같은 작업을 완료한 시도의 비율
• 동일 오류 반복 횟수: 같은 입력 항목에서 같은 문제가 얼마나 반복되는지
• 복구 소요 시간: 오류 노출부터 해당 문제를 해결하기까지 걸린 시간
• 오류 후 이탈 위치: 오류를 본 뒤 어느 단계에서 작업을 멈추는지

‘시도’의 구간과 완료의 정의를 먼저 정하고, 폼 종류별로 나누어 비교하세요. 분석 로그에 이메일, 비밀번호, 결제 정보 같은 원문 입력값을 불필요하게 남기지 않는 것도 중요합니다.

다음 디자인 리뷰에서 확인할 7가지

• 사용자 입력 문제와 서비스 장애를 구분했는가?
• 무엇이 잘못됐고 어떻게 수정할지 알 수 있는가?
• 필요한 형식·제한을 입력 전에 안내했는가?
• 오류를 발견하고 해당 입력으로 이동할 수 있는가?
• 입력 중·제출 후·수정 후의 동작이 정의되어 있는가?
• 다시 시도해도 정상 입력값을 불필요하게 잃지 않는가?
• 해결할 수 없는 상황에서도 실제 가능한 다음 경로가 있는가?

마무리: 사과보다 중요한 것은 다음 행동입니다

오류 메시지에서 공감과 정중함을 없애자는 뜻은 아닙니다. 다만 사과가 해결 방법을 대신할 수는 없습니다.

좋은 오류 경험은 문구, 위치, 검증 시점, 입력값 보존, 재시도 동작이 함께 만들어냅니다. 다음에 실패 상태를 디자인할 때는 빨간 문장을 고치기 전에 이 질문부터 던져보세요.

“이 화면을 본 사용자가, 지금 무엇을 해야 할지 알 수 있을까?”

---

참고 자료

• GOV.UK Design System · Recover from validation errors
• GOV.UK Design System · Error message
• GOV.UK Design System · Error summary
• W3C · Understanding SC 3.3.1: Error Identification
• W3C · Understanding SC 3.3.3: Error Suggestion

자료 확인일: 2026.09.18. 공식 기준과 디자인 시스템의 안내를 요약하고, 한국어 예시·실무 제안·점검표를 덧붙였습니다. 이 점검표만으로 WCAG 준수가 보장되는 것은 아닙니다.