오류 메시지 UX 라이팅: 복구 행동과 결과 불확실성 알리기

좋은 오류 메시지는 무슨 일이 일어났는지, 사용자가 무엇을 바꿀 수 있는지 설명하고 실제 상태에 맞는 다음 행동을 제공합니다. ‘문제가 발생했습니다’만으로는 어느 것도 해결되지 않습니다. 구체적인 메시지가 항상 긴 것은 아닙니다. 파일 형식이나 크기가 문제라면 ‘10MB 미만의 PDF 파일을 선택해 주세요’로 충분할 수 있습니다.

오류 문구는 화면을 완성한 뒤가 아니라 상태를 설계할 때 함께 작성하세요. UX 디자인 협업 과정에서 디자이너, 작성자, 개발자가 시스템이 아는 사실과 사용자가 안전하게 할 수 있는 다음 행동에 합의할 수 있습니다. 이 글에서는 청구서 업로드를 예로 들어 필드 검증부터 제출 결과가 확인되지 않은 상태까지 살펴봅니다.

문장을 쓰기 전에 실제 문제부터 구분하기

청구서 번호, 금액, 첨부파일을 입력하는 지급 요청 폼을 생각해 보겠습니다. 번호 누락, 지원하지 않는 파일, 일시적인 업로드 실패, 제출 결과를 확인하지 못한 상황을 같은 빨간 배너로 정확하게 설명할 수는 없습니다. 문제를 해결할 주체와 안전한 다음 행동이 서로 다르기 때문입니다.

이 예시의 10MB는 가상의 청구서 서비스가 정한 제한이며 Pixso의 업로드 제한이 아닙니다. 실제 프로젝트에서는 백엔드가 적용하는 제한을 사용하세요. 문구와 실제 검증 기준이 다르면 아무리 자연스럽게 쓴 문장도 결함이 됩니다.

필드 오류를 실행 가능한 안내로 쓰기

청구서 번호가 빠졌다면 ‘잘못된 입력입니다’보다 ‘청구서 번호를 입력해 주세요’가 낫습니다. 금액이 허용 범위를 벗어났다면 필드와 같은 통화·숫자 표기로 범위를 설명하세요. 서비스가 현재 확인할 수 없는 데이터 때문에 사용자를 탓해서는 안 됩니다.

GOV.UK의 오류 메시지 안내(영문)는 문제를 고칠 수 있도록 구체적이고 이해하기 쉬운 설명을 권합니다. 모든 폼에 일반적인 문장 하나를 복사하기보다, 실제 문제가 있는 필드에 이 원칙을 적용하세요.

메시지를 보는 사람에게 권한이 없다면 계좌번호, 비공개 공급업체 정보, 다른 사람의 정보를 포함하지 마세요. 구체성은 제품의 접근 권한 안에서 유용해야 합니다. 내부 진단 정보를 노출하는 대신 참조 번호를 제공하면 지원팀이 문제를 조사하는 데 도움이 될 수 있습니다.

작업 실패와 결과 미확인 구분하기

제출 전에 업로드가 실패했다면 ‘첨부파일을 업로드하지 못했습니다. 다른 입력 내용은 유지되어 있습니다. 파일 업로드를 다시 시도해 주세요’라는 안내가 맞을 수 있습니다. 하지만 폼을 보낸 뒤 응답만 오지 않았다면 ‘제출에 실패했습니다. 다시 시도해 주세요’는 중복 청구서를 만들 수 있습니다. 서비스가 요청을 수락했는지 인터페이스가 아직 모르는 상태이기 때문입니다.

결과 미확인 상태에서는 ‘청구서가 제출되었는지 아직 확인되지 않았습니다. 다시 보내기 전에 상태를 확인해 주세요’가 더 적절합니다. ‘상태 확인’ 버튼은 제품에 실제 확인 기능이 있을 때만 제공하세요. 그 기능이 없다면 청구서 목록을 살펴보거나 참조 번호와 함께 지원팀에 문의하는 등 가능한 경로를 안내합니다.

개발팀과 이 동작에 합의하세요. 더 부드러운 표현보다 버튼의 비활성화, 요청 식별자, 상태 조회 기능이 중요할 수 있습니다. 작성자는 다시 시도했을 때 같은 작업을 이어가는지, 새 작업을 시작하는지 알아야 합니다. 요청 시간이 초과되었다는 이유만으로 ‘아무것도 저장되지 않았습니다’라고 말해서는 안 됩니다.

메시지 위치와 표시 시점 맞추기

청구서 번호 오류는 필드 옆에 표시하고 구현 단계에서 해당 컨트롤과 연결합니다. 서비스 전체의 중단은 폼 수준에서 안내해야 합니다. 제출 후 여러 필드에 오류가 있다면 오류 요약에서 각각의 문제로 이동하는 경로를 제공할 수 있습니다. 같은 문단을 배너, 토스트, 필드 옆에 동시에 반복하지 마세요.

입력을 마칠 만한 시간을 주기 전에 필드를 잘못된 값으로 단정하지 마세요. 숫자를 입력하는 중의 미완성 금액과 제출 후 거절된 값은 다릅니다. 파일 제한처럼 선택에 영향을 주는 유용한 안내는 오류가 나기 전부터 보이게 합니다.

오류는 색상만이 아니라 텍스트나 아이콘으로도 의미를 전달해야 합니다. 긴 번역문이 버튼을 가리거나 필드와의 관계를 흐리지 않는지 확인하세요. 제품의 보안 요구를 고려해 수정 가능한 입력은 실패 후에도 유지하고, 실제로 구현된 경우에만 무엇이 유지되었다고 안내합니다.

Pixso에서 전체 오류 흐름 검토하기

정보가 빠진 청구서 폼, 크기를 초과한 첨부파일, 업로드 중, 업로드 실패, 제출 결과 미확인, 접수 완료 상태를 각각 프레임으로 만듭니다. 흐름 전체에 같은 청구서 번호를 사용하세요. 정확한 메시지와 버튼 문구를 별도 문서에만 적지 말고 실제로 표시될 화면에 배치합니다.

각 프레임 옆에 그 상태가 되는 조건, 저장된 채 남는 정보, 주요 버튼의 동작을 기록합니다. 개발자에게 서비스가 보장할 수 없는 표현을 찾아 달라고 요청하세요. 흐름을 모르는 디자이너나 작성자에게는 다음에 무엇을 할지 설명해 달라고 합니다. 결과 미확인 상태에서 다시 제출하려 한다면 버튼 문구, 위치, 설명을 함께 검토해야 합니다.

첨부파일의 전체 상호작용을 설계할 때는 파일 선택, 진행 상태, 다시 시도하는 상태까지 함께 정하세요. 이 글의 오류 문구도 해당 동작에 연결되어야 하며 화면을 꾸미는 부가 요소로 다뤄서는 안 됩니다.

원인과 복구 행동에 따라 메시지 관리하기

유용한 메시지 라이브러리는 값 누락, 잘못된 형식, 충돌, 서비스 이용 불가, 결과 미확인처럼 원인별로 재사용 가능한 패턴을 묶습니다. 각 패턴에 필요한 변수와 조건도 함께 저장하세요. ‘최대 크기’ 안내에는 실제 제한값이 필요하고, ‘기존 항목 확인’ 버튼에는 접근할 수 있는 목적지가 필요합니다.

찾기 쉽다는 이유로 팀이 모든 곳에 복사하는 만능 문장 하나는 피하세요. 제품의 용어는 통일하되 대상과 행동은 구체적으로 유지합니다. 같은 ‘다시 시도’ 버튼 세 개보다 ‘첨부파일 업로드’, ‘청구서 상태 확인’, ‘기존 청구서 보기’가 더 많은 정보를 알려 줍니다.

지원 문의나 조사에서 혼란이 드러나면 그 바탕이 되는 상태와 메시지를 함께 수정하세요. 더 나은 문구만으로는 입력을 지워 버리거나 두 번 제출하는 동작을 고칠 수 없습니다. Pixso에서 오류 상태 설계하고 검토하기