오류 안내 문구와 안내 사인, 오류 메시지 설계에서 놓치기 쉬운 기준
결제 버튼을 눌렀는데 화면에는 ‘오류가 발생했습니다’라는 말만 뜨고, 무엇을 해야 할지 알려주지 않는 경우가 있습니다. 사용자는 인터넷 문제인지, 입력을 잘못한 것인지, 서비스 자체가 멈춘 것인지 알 수 없어 같은 버튼을 여러 번 누르게 됩니다.
오류 안내를 잘 설계하면 사용자가 당황하는 시간을 줄이고 다음 행동까지 자연스럽게 이어지게 할 수 있습니다. 이 글을 읽으면 오류 원인을 어디까지 알려야 하는지, 안내 사인과 메시지를 어떻게 나눠야 하는지, 실제 문구를 어떤 순서로 만드는지 알게 됩니다.
오류 안내는 사과보다 다음 행동이 먼저다
좋은 오류 안내는 단순히 문제가 생겼다는 사실만 전하지 않습니다. 사용자가 지금 할 수 있는 행동을 알려주고, 다시 시도해도 되는 상황인지 기다려야 하는 상황인지 구분해 줍니다.
예를 들어 ‘처리할 수 없습니다’보다 ‘입력한 이메일 주소를 확인한 뒤 다시 시도해 주세요’가 낫습니다. 사용자가 고칠 수 있는 원인이 무엇인지 보이기 때문입니다. 반대로 서버 점검처럼 사용자가 해결할 수 없는 문제라면 반복 입력을 유도하지 않아야 합니다.
- 상황 알리기: 어떤 작업이 되지 않았는지 말합니다.
- 원인 설명하기: 확인된 범위 안에서만 이유를 알려줍니다.
- 행동 제시하기: 다시 입력하기, 잠시 기다리기, 이전 화면으로 돌아가기처럼 선택지를 줍니다.
- 불안 줄이기: 결제나 저장이 중복되지 않았는지 알려줍니다.
문구를 쓰기 전 확인할 체크리스트
오류 메시지를 만들기 전에 먼저 오류가 발생하는 위치와 사용자의 상태를 확인해야 합니다. 같은 오류라도 로그인 전과 결제 후의 안내 방식은 달라야 합니다.
- 사용자가 하려던 작업은 무엇인가?
- 입력값을 수정하면 해결되는 문제인가?
- 네트워크나 서버처럼 사용자가 통제할 수 없는 문제인가?
- 버튼을 여러 번 누르면 중복 저장이나 중복 결제가 생길 수 있는가?
- 오류가 화면 위쪽, 입력칸 옆, 전체 화면 중 어디에 나타나야 가장 잘 보이는가?
- 시각이나 기기와 관계없이 색상만으로 의미를 구분하고 있지는 않은가?
오류가 난 뒤 사용자가 가장 먼저 묻는 말은 대체로 세 가지입니다. ‘무슨 일이 생겼지?’, ‘내가 잘못했나?’, ‘지금 무엇을 하지?’입니다. 문구와 화면 배치는 이 순서에 맞춰 답을 줘야 합니다.
오류 메시지와 안내 사인의 차이
오류 메시지는 특정 행동이 실패한 이유와 해결 방법을 알려주는 글입니다. 안내 사인은 사용자가 화면 안에서 어디를 보고 어떤 방향으로 움직여야 하는지 알려주는 표시입니다. 둘을 같은 방식으로 만들면 정보가 부족하거나 화면이 지나치게 복잡해집니다.
| 구분 | 오류 메시지 | 안내 사인 |
|---|---|---|
| 목적 | 실패 원인과 해결 행동 전달 | 위치, 방향, 상태를 빠르게 전달 |
| 주요 위치 | 입력칸 주변, 알림창, 결과 화면 | 버튼, 메뉴, 진행 상태, 화면 상단 |
| 필요한 정보 | 무엇이 잘못됐는지와 다음 행동 | 어디로 가야 하는지와 현재 상태 |
| 주의점 | 모호한 표현과 책임 떠넘기기 금지 | 색상만으로 뜻을 전달하지 않기 |
예를 들어 파일을 올리는 화면에서 ‘빨간색 경고 표시’만 보여주면 사용자는 파일 형식이 문제인지 크기가 문제인지 알기 어렵습니다. ‘사진은 10메가바이트 이하의 파일만 올릴 수 있습니다’처럼 제한 조건을 글로도 적어야 합니다. 다만 실제 제한값이나 정책은 서비스의 공식 안내에서 다시 확인해 문구에 반영해야 합니다.
오류 안내 문구를 만드는 순서
첫째, 실패한 행동을 정확히 적습니다. ‘오류가 발생했습니다’ 대신 ‘예약 정보를 불러오지 못했습니다’처럼 대상과 행동을 함께 씁니다. 사용자는 자신의 행동이 실패한 것인지 서비스의 정보를 가져오지 못한 것인지 구분할 수 있습니다.
둘째, 확인된 원인만 설명합니다. 원인을 모를 때 ‘알 수 없는 오류’라고 단정하기보다 ‘잠시 연결이 불안정할 수 있습니다’처럼 확인된 가능성의 범위를 보여주는 편이 안전합니다. 개발자가 보는 오류 번호는 필요하다면 보조 정보로 제공하되, 사용자에게 읽기 어려운 긴 문장을 그대로 노출하지 않습니다.
셋째, 행동 버튼의 이름을 구체적으로 씁니다. ‘확인’ 하나만 두는 대신 ‘다시 불러오기’, ‘입력 내용 수정’, ‘처음 화면으로 이동’처럼 버튼을 누른 뒤의 결과가 보이게 합니다. 버튼이 하나라면 무엇을 하는 버튼인지 문구만 읽어도 알 수 있어야 합니다.
넷째, 성공 여부가 애매한 작업을 따로 다룹니다. 결제나 파일 저장 뒤 연결이 끊겼다면 무조건 다시 누르라고 안내해서는 안 됩니다. ‘결제 결과를 확인하는 중입니다. 주문 내역에서 처리 상태를 확인해 주세요’처럼 중복 행동을 막는 문장이 먼저 필요합니다.
실제 예시는 다음처럼 바꿀 수 있습니다.
- 나쁜 문구: ‘잘못된 요청입니다.’
- 개선 문구: ‘비밀번호는 8자 이상이어야 합니다. 영문과 숫자를 포함해 다시 입력해 주세요.’
- 나쁜 문구: ‘서버 오류가 발생했습니다.’
- 개선 문구: ‘자료를 불러오지 못했습니다. 잠시 후 다시 시도해 주세요. 계속되면 문의할 때 오류 번호 204를 알려주세요.’
자주 하는 실수와 고치는 방법
가장 흔한 실수는 사용자의 책임처럼 보이는 표현입니다. ‘잘못된 접근’, ‘비정상적인 요청’처럼 이유를 설명하지 않는 말은 사용자가 무엇을 고쳐야 하는지 알려주지 못합니다. 보안상 자세한 이유를 숨겨야 하는 경우에도 가능한 행동은 안내해야 합니다.
두 번째 실수는 오류를 팝업 하나로만 처리하는 것입니다. 팝업이 닫히면 사용자는 입력칸으로 돌아가야 하고, 방금 무엇을 고쳐야 하는지도 잊기 쉽습니다. 입력 오류는 해당 입력칸 가까이에 표시하고, 전체 작업이 멈춘 경우에만 별도 알림을 쓰는 편이 좋습니다.
세 번째 실수는 색상과 아이콘에만 의존하는 것입니다. 빨간색을 보지 못하거나 색을 다르게 인식하는 사용자도 있습니다. 경고 아이콘과 함께 ‘필수 항목을 입력해 주세요’ 같은 글을 제공해야 합니다. 글자 크기와 배경 대비도 작은 화면에서 확인해야 합니다.
네 번째 실수는 개발자용 정보와 사용자용 정보를 구분하지 않는 것입니다. 긴 오류 번호, 경로, 기술 용어는 도움말이나 문의 화면에서 복사할 수 있게 제공하고, 기본 화면에는 사용자가 이해할 수 있는 설명을 앞에 둡니다.
자주 묻는 질문
오류 원인을 모두 자세히 알려줘야 하나요?
아닙니다. 보안이나 시스템 구조가 드러날 수 있는 내용은 줄이는 것이 좋습니다. 대신 사용자가 수정할 수 있는 부분과 다음 행동은 구체적으로 알려야 합니다.
‘다시 시도’ 버튼만 있어도 괜찮나요?
네트워크가 잠깐 끊긴 경우에는 유용하지만, 입력 오류나 중복 처리 가능성이 있는 작업에는 부족합니다. 다시 시도하기 전에 무엇을 확인해야 하는지, 이미 처리가 끝났을 가능성은 없는지 함께 안내하세요.
오류 번호는 사용자에게 필요한가요?
문의나 기록 확인에 도움이 될 수 있습니다. 다만 문구의 앞부분을 오류 번호로 시작하면 사용자가 의미를 파악하기 어렵습니다. 설명을 먼저 보여주고, 필요할 때 복사할 수 있는 보조 정보로 배치하세요.
안내 사인은 화면 어디에 두는 것이 좋나요?
사용자의 시선이 머무는 행동 근처에 둡니다. 입력 오류는 입력칸 옆이나 아래, 진행 상태는 진행 영역 가까이, 전체 서비스 장애는 화면 상단이나 전체 알림 영역에 배치하는 식입니다. 작은 화면에서도 버튼과 설명이 겹치지 않는지 실제 기기로 확인해야 합니다.
오류 안내의 목표는 사용자가 오류를 전혀 보지 않게 만드는 것이 아닙니다. 문제가 생겨도 상황을 이해하고, 안전한 다음 행동을 선택하게 만드는 것입니다. 문구를 만든 뒤에는 처음 보는 사람에게 오류 화면만 보여주고 다음에 무엇을 할지 물어보세요. 예상과 다른 답이 나온다면 표현과 배치를 다시 다듬을 때입니다.