코드만 보이는 화면이 만드는 막막함
문의나 예약 양식을 보냈는데 알 수 없는 영문 코드나 숫자만 나타나는 화면을 만난 적이 있을 것입니다. 이런 화면 앞에서 방문자는 입력을 고쳐야 하는지, 잠시 후 다시 시도해야 하는지, 이미 접수가 된 것인지 판단하지 못합니다. 그 상태에서 사이트를 떠나면 운영자는 문의를 놓치고, 방문자는 불편한 기억만 안고 가게 됩니다.
오류 안내의 목적은 무엇이 잘못되었는지 설명하는 데 그치지 않고 방문자가 지금 할 수 있는 다음 행동을 알려 주는 것입니다. 개발 담당자에게는 내부 오류 번호가 유용하지만, 방문자에게 유일한 단서로 보여서는 안 됩니다. 문구를 쓰는 사람과 시스템을 관리하는 사람이 함께 오류의 종류를 정리하는 일이 첫 단계입니다.
입력 오류와 시스템 문제를 나누어 쓰기
오류는 크게 두 갈래로 나뉩니다. 하나는 방문자가 고칠 수 있는 입력 문제이고, 다른 하나는 서버나 외부 연동처럼 방문자가 손쓸 수 없는 문제입니다. 필수 항목이 비었거나 연락처 형식이 맞지 않는 경우에는 어느 칸을 고쳐야 하는지 해당 칸 가까이에 표시하고, 이미 적은 다른 내용은 지워지지 않도록 유지해야 합니다. 긴 문의 내용을 다시 입력하게 만드는 양식은 그 자체로 이탈 원인이 됩니다.
시스템 쪽 문제라면 방문자가 잘못한 것처럼 읽히는 표현을 피하고, 잠시 뒤 다시 시도하거나 다른 연락 수단을 이용하도록 안내합니다. 이때 실제로 확인되지 않은 복구 시점을 약속하면 오히려 신뢰를 잃을 수 있으므로, 알 수 있는 사실만 담백하게 적습니다.
접수 여부를 먼저 알려야 하는 이유
예약이나 신청처럼 중요한 행동에서는 접수가 되었는지가 가장 궁금한 정보입니다. 오류 화면이 나타났어도 내부에서는 처리가 끝났을 수 있습니다. 이런 상황에서 무조건 다시 제출하라고 안내하면 같은 요청이 여러 번 접수되는 중복이 생깁니다. 접수 상태를 확인할 수 있는 경로를 마련하고, 확인이 어렵다면 어떤 방법으로 문의하면 되는지를 함께 알려 주는 편이 안전합니다.
운영자가 추가로 확인해야 하는 경우에도 요청하는 정보는 필요한 최소 범위로 줄입니다. 개인정보나 민감한 입력값을 공개된 댓글이나 게시판에 남기게 하는 안내는 하지 않아야 하고, 화면 전체를 캡처해서 보내 달라는 요청도 신중해야 합니다. 문의 번호처럼 개인을 식별하지 않는 값으로 상황을 설명할 수 있게 해 두면 서로 편합니다.
메시지가 놓이는 위치와 접근성
문구 못지않게 위치도 중요합니다. 화면 맨 위에 오류가 있다는 말만 보이고 실제로 고칠 칸은 아래쪽에 있으면 방문자는 어디를 봐야 하는지 알기 어렵습니다. 문제가 생긴 입력 칸 바로 옆에 이유를 쓰고, 첫 번째 문제 칸으로 화면이 이동하도록 구성하는 방식이 좋습니다.
화면 낭독 프로그램이나 키보드만으로 사이트를 쓰는 사용자도 오류를 알아챌 수 있어야 합니다. 빨간색 같은 색상 변화만으로 상태를 구분하면 일부 사용자에게는 전달되지 않습니다. 문구와 아이콘, 위치를 함께 사용하고, 실제로 키보드만으로 양식을 제출해 보며 오류가 전달되는지 시험합니다.
방문자 문구와 내부 기록 분리하기
방문자에게 보이는 문장과 담당자가 추적하는 기록은 따로 관리합니다. 내부 코드와 발생 시각은 지원 담당자가 원인을 찾도록 서버 기록에 남기되, 시스템 구조가 드러나는 민감한 정보는 공개 화면에 노출하지 않습니다. 또한 화면의 문구가 실제 시스템 동작과 맞는지 휴대전화와 컴퓨터에서 직접 시험해야 합니다. 문구가 다시 시도하라고 하는데 실제로는 입력값이 사라지는 식의 불일치가 있으면 안내 자체가 신뢰를 잃습니다.
같은 오류가 반복된다면
같은 오류 보고가 거듭되면 문구를 더 친절하게 고치는 데서 멈추지 말고 원인을 해결해야 합니다. 오류가 발생한 횟수와 종류를 간단히 기록해 두면 어떤 양식에서 문제가 자주 생기는지 알 수 있고, 수정 우선순위를 정하는 근거가 됩니다. 좋은 오류 안내는 코드를 해독하라고 요구하지 않고 방문자가 자기 작업의 상태를 이해해 안전한 다음 선택을 하도록 돕습니다. 양식을 바꿀 때마다 실제 오류 상황을 일부러 만들어 보는 점검 절차를 작업 목록에 넣어 두시기 바랍니다.