코드만 보이는 화면은 이용자에게 답이 되지 않습니다
양식을 제출했는데 알 수 없는 영문 코드만 나타나면 이용자는 다시 시도해야 하는지, 입력을 고쳐야 하는지, 잠시 기다려야 하는지 알 수 없습니다. 오류 메시지가 해야 하는 일은 문제의 범위를 알리고 지금 할 수 있는 행동을 안내하는 것입니다.
내부 코드는 담당자가 원인을 찾을 때 도움이 됩니다. 다만 이용자에게 보이는 단독 안내가 되어서는 안 되고, 필요하다면 지원을 요청할 때 전달하는 참고 정보로 작게 곁들이는 정도가 적절합니다.
입력 문제와 서비스 문제를 구분해 표현하기
첫 단계는 오류의 성격을 나누는 것입니다. 필수 항목이 비어 있거나 형식이 맞지 않는 입력 문제라면, 어느 항목이 문제인지 표시하고 이미 입력한 다른 값은 지워지지 않게 유지합니다. 다시 처음부터 쓰게 만드는 화면은 이용자가 이탈하는 큰 이유가 됩니다.
서버나 외부 인증 같은 서비스 쪽 문제라면 이용자가 잘못한 것처럼 말하지 않습니다. 잠시 뒤 다시 시도하거나 공식 지원 경로를 확인하도록 안내하되, 확인되지 않은 복구 시간을 약속하지 않습니다.
결제와 예약에서는 완료 여부를 먼저 알려 주기
중요한 행동일수록 처리가 끝났는지가 가장 큰 관심사입니다. 오류 화면이 나타났어도 요청이 이미 접수되었을 수 있는데, 확인 없이 다시 제출하라고 안내하면 중복 신청이 생길 수 있습니다.
그래서 현재 상태를 확인할 수 있는 경로를 함께 제공합니다. 운영자가 추가로 확인해야 하는 경우에는 어떤 정보가 필요한지 최소한의 범위로 알려 줍니다. 이름이나 연락처 같은 개인정보를 공개된 댓글에 남기도록 유도하는 안내는 하지 않습니다.
메시지의 위치와 접근성 점검
메시지를 어디에 두는지도 중요합니다. 화면 맨 위에 오류가 있다는 표시만 있고 문제가 되는 입력란은 아래에 있으면 이용자가 찾느라 시간을 씁니다. 해당 항목 가까이에 이유를 적고, 키보드 이동이나 화면 읽기 도구에서도 오류가 전달되는지 확인합니다.
색상만으로 상태를 구분하지 않는 것도 기본입니다. 빨간색 테두리만으로 오류를 표시하면 색을 구별하기 어려운 사람은 알아차리기 어렵습니다. 문구와 아이콘을 함께 사용해 어떤 사람이든 같은 정보를 얻게 합니다.
이용자에게 보이는 문구와 내부 기록 분리하기
고객에게 보이는 문구와 내부 로그는 목적이 다릅니다. 접수번호나 발생 시각처럼 지원 담당자가 추적할 수 있는 값은 남기되, 시스템 구조나 민감한 설정이 공개 화면에 드러나지 않게 합니다. 개인정보가 포함되지 않는 범위에서 접수번호를 보여 주면 문의할 때 도움이 됩니다.
또한 이용자에게 오류 화면 전체를 캡처해 보내 달라고 요구하는 방식은 민감한 입력값이 함께 노출될 수 있어 신중해야 합니다. 필요한 정보만 골라 전달하도록 안내하는 편이 안전합니다.
문구를 고치기 전에 반복 원인을 확인하기
같은 오류가 되풀이된다면 문구를 친절하게 바꾸는 것만으로는 해결되지 않습니다. 원인을 찾아 고쳐야 하고, 그 전까지는 임시 안내가 실제 상황과 일치하는지 모바일과 컴퓨터 양쪽에서 시험합니다.
좋은 오류 메시지는 코드를 해석하라고 요구하지 않습니다. 이용자가 자신의 작업이 어떤 상태인지 이해하고, 안전한 다음 단계를 스스로 고를 수 있도록 돕는 문장입니다.
메시지를 정할 때 함께 정리할 표
오류의 종류가 많다면 메시지를 하나씩 새로 쓰기보다 표로 정리하는 것이 좋습니다. 열에는 오류가 생기는 상황, 이용자에게 보이는 문구, 이용자가 할 수 있는 행동, 운영자가 확인할 내용을 둡니다. 이 표를 개발 담당자와 서비스 담당자가 함께 보면 문구가 실제 동작과 어긋나는 부분을 일찍 찾을 수 있습니다. 새로운 오류가 생길 때마다 표에 한 줄씩 더하면 문구의 말투와 수준도 일정하게 유지됩니다.
문구를 시험할 때는 서비스를 처음 쓰는 사람에게 메시지만 보여 주고 다음에 무엇을 할지 말해 보게 합니다. 대답이 갈린다면 안내가 아직 모호하다는 뜻입니다.
오류 문구를 정리한 뒤에는 도움말 페이지나 문의 안내와도 연결합니다. 같은 문제를 설명하는 곳마다 용어가 다르면 이용자가 같은 상황인지 알아보기 어렵습니다. 화면의 문구, 도움말, 지원 담당자의 답변이 같은 표현을 쓰도록 맞춰 두면 문의 과정도 짧아집니다. 새 기능을 추가할 때는 정상 흐름과 함께 오류 흐름을 먼저 시험하는 것을 기본 절차로 삼으세요.