코드만 보이는 화면은 이용자를 멈추게 합니다
문의 양식을 보냈는데 알 수 없는 영문 코드만 나타나면 이용자는 어떻게 해야 할지 판단하기 어렵습니다. 입력을 고쳐야 하는지, 잠시 뒤 다시 시도해야 하는지, 이미 접수가 끝났는지가 화면에 드러나지 않기 때문입니다. 내부 코드는 담당자가 원인을 추적할 때 쓰는 단서이지 이용자가 읽는 안내가 아닙니다.
좋은 오류 메시지는 무슨 일이 일어났는지, 지금 할 수 있는 일이 무엇인지를 짧게 알려 줍니다. 두 가지가 빠지면 이용자는 같은 버튼을 여러 번 누르거나 페이지를 떠나게 됩니다. 문구를 다듬기 전에 먼저 이 두 질문에 답이 있는지 확인하는 것이 출발점입니다.
입력 오류와 서비스 문제를 나누어 표현합니다
필수 항목이 비어 있거나 형식이 맞지 않는 경우는 이용자가 바로 고칠 수 있는 문제입니다. 이때는 어떤 항목이 문제인지 해당 입력란 가까이에 표시하고, 이미 입력한 다른 내용은 지워지지 않게 유지해야 합니다. 전체를 다시 쓰게 만드는 화면은 이탈의 큰 원인이 됩니다.
반대로 서버나 외부 연동에서 생긴 문제라면 이용자가 잘못한 것처럼 읽히지 않아야 합니다. 잠시 후 다시 시도하거나 공식 문의 경로를 이용하도록 안내하되, 확인되지 않은 복구 시점을 약속하지 않습니다. "곧 해결됩니다" 같은 표현은 실제로 약속할 수 없다면 쓰지 않는 편이 안전합니다. 확정된 사실만 적고 모르는 부분은 모른다고 쓰는 것이 이용자의 신뢰를 지키는 방법입니다.
예약과 결제처럼 중요한 행동에서는 완료 여부가 먼저입니다
오류 화면이 나타났더라도 요청 자체는 이미 접수되었을 수 있습니다. 이런 상황에서 곧바로 다시 제출하라고 안내하면 같은 신청이 두 번 들어가는 문제가 생길 수 있습니다. 그래서 현재 처리 상태를 확인할 수 있는 경로를 함께 제공하는 것이 좋습니다.
운영자가 따로 확인해야 하는 경우에는 어떤 정보를 알려 주면 되는지 최소한의 범위로 안내합니다. 접수 번호처럼 개인을 직접 드러내지 않는 값이 있다면 화면에 보여 줄 수 있습니다. 반대로 화면 전체를 캡처하거나 민감한 입력값을 보내 달라고 요청하는 방식은 피하고, 공개된 댓글이나 게시판에 개인정보를 남기게 하지 않습니다.
메시지의 위치와 전달 방식도 함께 확인합니다
메시지가 화면 맨 위에만 "오류"라고 나타나고 실제 문제가 있는 입력란은 아래쪽에 있다면 이용자가 원인을 찾기 어렵습니다. 문제가 생긴 항목 가까이에 설명을 두고, 키보드로 이동하는 사람과 화면 읽기 도구를 쓰는 사람에게도 같은 내용이 전달되는지 점검합니다. 빨간색 같은 색상만으로 오류를 구분하면 색을 구별하기 어려운 이용자에게는 전달되지 않습니다.
모바일 화면에서는 키보드가 올라오면서 메시지가 가려지는 경우도 있습니다. 실제 기기에서 양식을 일부러 틀리게 입력해 보고, 메시지가 눈에 띄는 위치에 남아 있는지 확인합니다. 컴퓨터와 모바일에서 각각 시험해 보면 놓친 부분이 드러나는 경우가 많습니다.
고객에게 보이는 문구와 내부 기록을 분리합니다
내부 코드와 발생 시각은 지원 담당자가 추적할 수 있도록 로그에 남기되, 시스템 구조를 짐작하게 하는 민감한 정보는 공개 화면에 노출하지 않습니다. 이용자에게 보이는 문구는 사람의 언어로 쓰고, 내부 기록은 담당자가 읽는 형태로 따로 관리합니다. 두 가지를 섞으면 화면은 어렵고 기록은 부실해집니다.
또한 메시지의 약속과 실제 동작이 같은지 정기적으로 시험합니다. "다시 시도해 주세요"라고 안내했는데 다시 시도해도 같은 오류가 나온다면 문구보다 원인을 고쳐야 합니다. 문구를 친절하게 바꾸는 일은 같은 오류가 반복되는 문제를 해결해 주지 않습니다.
점검할 때 확인할 질문
오류 화면을 점검할 때는 몇 가지 질문으로 정리할 수 있습니다. 이용자가 코드를 해석하지 않아도 현재 상황을 이해할 수 있는지, 다음에 할 수 있는 행동이 하나 이상 보이는지, 중복 제출을 막을 수 있는지를 봅니다. 입력한 내용이 유지되는지, 문의 경로가 화면에서 가까운지도 함께 확인합니다.
이 기준은 한 번 정해 두고 끝내기보다 문의 기록과 함께 갱신하는 편이 좋습니다. 같은 문의가 반복되는 화면이 있다면 그 화면의 메시지부터 다시 읽어 봅니다. 오류 메시지는 이용자가 자신의 작업 상태를 이해하고 안전한 다음 단계를 고르도록 돕는 안내라는 점을 기준으로 삼으면 됩니다.
문구를 점검하는 담당자는 개발자와 운영자, 안내를 쓰는 편집자가 함께 참여하면 좋습니다. 개발자는 어떤 상황에서 어떤 오류가 생기는지 알고 있고, 운영자는 이용자가 실제로 무엇을 묻는지 알고 있으며, 편집자는 그 내용을 쉬운 문장으로 옮길 수 있기 때문입니다. 세 관점이 만나면 코드 중심의 화면이 행동 중심의 안내로 바뀌는 속도가 빨라집니다.