오류 메시지 설계, 입력 오류·안내 문구·사용자 경험을 바꾸는 말의 기준
회원가입을 하다가 빨간 글씨로 ‘잘못된 요청입니다’라는 문장을 만난 적이 있나요? 무엇을 잘못했는지 알 수 없어 입력한 내용을 모두 지우고 다시 시도했지만, 같은 화면만 반복되면 서비스 자체를 믿기 어려워집니다. 오류는 피할 수 없어도 당황하는 경험은 줄일 수 있습니다.
오류 메시지 설계를 살펴보면 어떤 정보를 알려줘야 사용자가 다음 행동으로 넘어가는지 알게 됩니다. 문장의 길이보다 중요한 것은 원인, 해결 방법, 다시 시도할 시점을 정확히 보여주는 일입니다. 회원가입, 결제, 검색, 파일 업로드처럼 상황이 다른 화면에 같은 문구를 쓰면 왜 문제가 생기는지도 함께 확인해 보겠습니다.
오류 메시지 설계란 무엇인가
오류 메시지는 사용자의 행동이 정상적으로 끝나지 않았을 때 보여주는 안내문입니다. 단순히 실패를 알리는 문장이 아니라, 사용자가 현재 상태를 이해하고 다음 행동을 고르게 하는 작은 길잡이에 가깝습니다.
좋은 메시지는 보통 세 가지 질문에 답합니다. 무엇이 잘못되었는가, 왜 문제가 생겼는가, 이제 무엇을 하면 되는가입니다. 예를 들어 ‘입력 오류’보다 ‘비밀번호는 8자 이상이며 숫자를 포함해야 합니다’가 더 유용합니다. 잘못된 점과 수정 기준이 함께 있기 때문입니다.
- 문제의 위치: 어느 입력란이나 기능에서 문제가 발생했는지 알려줍니다.
- 문제의 원인: 형식, 권한, 연결 상태처럼 사용자가 이해할 수 있는 이유를 설명합니다.
- 해결 행동: 다시 입력하기, 파일 크기 줄이기, 잠시 후 재시도하기처럼 다음 행동을 제시합니다.
좋은 오류 문구를 만드는 체크 기준
문구를 작성하기 전에는 기술자가 보는 오류와 사용자가 겪는 문제를 나눠야 합니다. 서버에서는 ‘인증 토큰 만료’가 원인일 수 있지만, 사용자는 로그인 화면으로 돌아가야 한다는 사실만 알면 됩니다. 내부 원인을 모두 공개하기보다 사용자의 행동에 필요한 수준으로 바꾸는 것이 좋습니다.
- 누구를 탓하지 않는가: ‘잘못 입력했습니다’보다 ‘이메일 형식을 확인해 주세요’처럼 문제를 행동 중심으로 씁니다.
- 문제 위치가 보이는가: 입력란 옆에 메시지를 두고, 여러 오류가 있으면 가장 먼저 고칠 항목을 분명히 합니다.
- 구체적인 기준이 있는가: ‘파일이 너무 큽니다’ 대신 ‘10메가바이트 이하의 파일을 올려 주세요’처럼 확인할 기준을 넣습니다.
- 해결 방법이 현실적인가: 사용자가 할 수 없는 ‘관리자에게 문의하세요’만 남기지 말고 문의 경로와 필요한 정보를 안내합니다.
- 다시 시도해도 데이터가 사라지지 않는가: 긴 글이나 설문 답변을 작성한 뒤 오류가 나면 입력 내용 보존 여부가 특히 중요합니다.
색상만으로 오류를 알리는 것도 조심해야 합니다. 색을 구분하기 어려운 사람은 빨간색 표시를 보지 못할 수 있습니다. 오류 아이콘, 문장, 입력란의 상태 변화처럼 여러 신호를 함께 사용하고, 화면을 읽어주는 기능에서도 문구가 전달되는지 확인해야 합니다.
상황에 따른 오류 메시지 비교
모든 오류에 같은 말투와 버튼을 적용하면 문장은 단순해 보여도 행동은 헷갈립니다. 오류가 사용자의 입력 때문에 생겼는지, 서비스의 상태 때문에 생겼는지를 먼저 나누면 설계 방향이 달라집니다.
| 상황 | 좋지 않은 표현 | 더 나은 표현 | 필요한 행동 |
|---|---|---|---|
| 필수 입력 누락 | 입력 오류 | 이름을 입력해 주세요. | 입력란으로 이동 |
| 형식이 맞지 않음 | 유효하지 않은 값 | 휴대전화 번호 11자리를 입력해 주세요. | 형식 수정 |
| 권한 없음 | 접근 거부 | 이 자료를 볼 권한이 없습니다. 담당자에게 권한을 요청해 주세요. | 요청 또는 이전 화면 |
| 일시적 연결 실패 | 알 수 없는 오류 | 연결이 잠시 끊겼습니다. 작성한 내용은 저장되지 않았을 수 있으니 확인 후 다시 시도해 주세요. | 상태 확인 후 재시도 |
입력 오류는 사용자가 바로 고칠 수 있으므로 해당 입력란 가까이에 보여주는 편이 좋습니다. 반면 서버 장애나 결제 승인 실패는 사용자의 잘못이 아닐 수 있습니다. 이때는 실패 사실, 처리 여부, 문의할 때 필요한 정보가 중요합니다. 결제 화면에서 ‘실패’만 표시하면 돈이 빠져나갔는지 걱정하게 되므로 거래 상태를 확인하라는 안내가 필요합니다.
오류 메시지를 설계하는 순서
1. 오류가 발생하는 장면을 모읍니다
회원가입, 로그인, 검색, 결제, 파일 업로드 등 주요 기능을 목록으로 만들고 각 기능에서 사용자가 할 수 있는 실수를 적습니다. 실제 사용자 테스트에서 나온 표현도 함께 기록하면 개발팀의 오류 코드만 볼 때보다 빠진 상황을 줄일 수 있습니다.
2. 사용자의 목표를 먼저 적습니다
사용자는 오류를 읽으려고 화면에 온 것이 아닙니다. 가입을 끝내거나 파일을 제출하려고 왔습니다. 따라서 ‘무슨 오류인가’만 적지 말고 ‘목표를 이루려면 지금 무엇을 해야 하는가’를 기준으로 문장을 만듭니다.
3. 짧은 제목과 설명을 나눕니다
제목은 상황을 빠르게 알려주고, 설명은 원인과 해결 방법을 덧붙입니다. 예를 들어 제목은 ‘파일을 올릴 수 없습니다’, 설명은 ‘파일 형식은 문서 파일만 지원합니다. 다른 형식으로 저장한 뒤 다시 올려 주세요’처럼 구성할 수 있습니다.
4. 버튼의 결과를 예측 가능하게 만듭니다
‘확인’만 있는 창은 버튼을 눌렀을 때 무엇이 일어나는지 알기 어렵습니다. ‘다시 시도’, ‘로그인 화면으로 이동’, ‘문의하기’처럼 결과가 드러나는 말을 사용합니다. 단, 실제로 작동하지 않는 버튼을 배치해서는 안 됩니다.
5. 실패 상태를 직접 시험합니다
빈칸, 너무 긴 값, 잘못된 파일, 느린 인터넷, 중복 요청, 권한이 없는 계정으로 화면을 각각 확인합니다. 휴대전화 화면에서도 문장이 잘리지 않는지, 키보드가 메시지를 가리지 않는지, 오류 뒤 입력 내용이 유지되는지도 체크해야 합니다.
자주 생기는 실수와 고치는 방법
첫째, 기술 용어를 그대로 보여주는 경우입니다. ‘오류 코드 403’은 개발자에게는 의미가 있지만 일반 사용자에게는 행동 기준이 부족합니다. 필요하다면 쉬운 설명 뒤에 문의용 코드로 따로 제공하세요.
둘째, 문제를 한꺼번에 몰아서 보여주는 경우입니다. 설문 문항 열 개에 오류가 있어도 화면 위쪽에 ‘다시 확인하세요’만 쓰면 어디부터 고쳐야 할지 모릅니다. 각 항목 옆에 이유를 두고, 오류가 있는 첫 위치로 이동시키는 편이 낫습니다.
셋째, 친근함을 지나치게 앞세우는 경우입니다. ‘앗, 뭔가 문제가 생겼어요’는 부드럽지만 해결 방법이 없습니다. 말투는 따뜻하게 유지하되 정보는 구체적으로 써야 합니다. 유머는 결제, 개인정보, 업무 제출처럼 긴장이 큰 화면에서는 오히려 가볍게 느껴질 수 있습니다.
넷째, 오류가 사라지는 시간만 믿는 경우입니다. 잠깐 나타나는 알림은 읽기 전에 사라질 수 있습니다. 중요한 오류는 화면에 남기고, 자동으로 사라지는 안내는 사용자가 놓쳐도 문제가 없는 성공 알림이나 단순 상태 변화에 제한하는 것이 안전합니다.
오류 메시지 설계 자주 묻는 질문
오류 문구는 얼마나 길어야 하나요?
정해진 글자 수보다 한 번에 이해할 수 있는지가 중요합니다. 제목은 짧게 두고, 상세한 원인과 해결 방법은 설명 영역으로 분리하세요. 모바일에서는 두세 줄 안에 핵심 행동이 보이는지 먼저 확인하는 것이 좋습니다.
‘다시 시도해 주세요’만 써도 되나요?
일시적인 연결 문제처럼 다시 시도할 이유가 분명할 때만 적합합니다. 입력 형식이 잘못된 상황이라면 다시 눌러도 같은 문제가 생기므로 수정해야 할 값을 알려줘야 합니다. 재시도 전에 기다려야 한다면 대략적인 대기 상황도 함께 안내하세요.
오류 코드도 사용자에게 보여줘야 하나요?
일반 화면에는 쉬운 설명을 우선하고, 고객센터나 관리자에게 전달할 코드만 보조 정보로 제공하는 방식이 좋습니다. 오류 코드는 문의 처리에 도움이 되지만, 그것만 보여주면 사용자가 스스로 해결하기 어렵습니다.
좋은 메시지인지 어떻게 검증하나요?
문구를 가린 뒤 오류 상황만 보여주고 사용자가 무엇을 해야 한다고 말하는지 확인해 보세요. 세 명 정도만 테스트해도 ‘어디를 고쳐야 하는지’, ‘내용이 사라졌는지’, ‘다음 버튼이 무엇인지’ 같은 혼란을 발견할 수 있습니다. 설계가 끝난 뒤에도 문의 기록과 이탈 구간을 살펴 문구를 계속 다듬어야 합니다.
오류 메시지는 화면의 작은 문장이지만 서비스에 대한 신뢰와 바로 이어집니다. 사용자의 실수를 꾸짖지 않고, 시스템의 한계를 숨기지 않으며, 다음 행동을 분명히 알려주는 것이 좋은 오류 메시지 설계의 출발점입니다.