오류 메시지 텍스트 작성 가이드 - UX 관점
앱과 웹 서비스의 오류 메시지 텍스트를 사용자 친화적으로 작성하는 방법, 최적 글자수, 좋은 오류 메시지의 4가지 요소를 설명합니다.
Q.UX 관점에서 좋은 오류 메시지 텍스트는 어떻게 작성하나요?
좋은 오류 메시지는 4가지 요소를 포함합니다: 1) 무슨 일이 일어났는지(What), 2) 왜 발생했는지(Why), 3) 어떻게 해결하는지(How), 4) 언제 다시 시도해야 하는지(When). '오류가 발생했습니다'보다 '파일 크기가 10MB를 초과합니다. 10MB 이하 파일을 업로드해 주세요.'가 훨씬 효과적입니다. 최적 길이는 30-80자입니다.
"오류가 발생했습니다"라는 메시지를 본 사용자는 무엇을 해야 할지 모른다. 이 메시지는 개발자에게도, 사용자에게도 쓸모가 없다. 오류 메시지 UX는 앱 신뢰도에 직접 영향을 준다.
핵심 답변
좋은 오류 메시지는 4가지 요소를 포함합니다: 1) 무슨 일이 일어났는지(What), 2) 왜 발생했는지(Why), 3) 어떻게 해결하는지(How), 4) 언제 다시 시도해야 하는지(When). '오류가 발생했습니다'보다 '파일 크기가 10MB를 초과합니다. 10MB 이하 파일을 업로드해 주세요.'가 훨씬 효과적입니다. 최적 길이는 30-80자입니다.
나쁜 오류 메시지 vs 좋은 오류 메시지
| 나쁜 예 | 문제점 | 좋은 예 |
|---|---|---|
| "오류가 발생했습니다" | 원인·해결책 없음 | "인터넷 연결을 확인해 주세요." |
| "유효하지 않은 입력" | 어떤 입력인지 불명확 | "이메일 형식이 올바르지 않습니다. (예: user@email.com)" |
| "Error 404" | 사용자가 이해 불가 | "페이지를 찾을 수 없습니다. [홈으로 돌아가기]" |
| "업로드 실패" | 원인 없음 | "파일 크기가 10MB를 초과합니다. (현재: 15MB)" |
오류 메시지 4요소
What - 무슨 일이 일어났나: "비밀번호가 일치하지 않습니다."
Why - 왜 발생했나: "(이전 비밀번호와 동일한 비밀번호는 사용할 수 없습니다)"
How - 어떻게 해결하나: "새 비밀번호를 입력해 주세요."
When - 언제 다시 시도 가능한가: "5분 후 다시 시도해 주세요." (타임아웃 오류)
최적 오류 메시지 길이
- 인라인 폼 오류 (필드 아래 표시): 20-50자
- 토스트 알림: 30-60자
- 모달 대화상자: 50-120자
- 전체 페이지 오류: 80-200자
길수록 사용자가 읽지 않는다. 핵심 해결 방법을 첫 문장에 배치하는 역피라미드 구조를 적용한다.
오류 메시지 개선 전후 예시
| 오류 상황 | 개선 전 | 개선 후 |
|---|---|---|
| 잘못된 이메일 형식 | "유효하지 않은 이메일" | "이메일 형식이 올바르지 않습니다. (예: name@email.com)" |
| 비밀번호 조건 미충족 | "비밀번호 오류" | "비밀번호는 8자 이상, 영문+숫자 조합이어야 합니다." |
| 파일 크기 초과 | "업로드 실패" | "파일 크기가 10MB를 초과합니다. (현재 파일: 15.3MB)" |
| 네트워크 오류 | "연결 오류가 발생했습니다" | "인터넷 연결을 확인하고 다시 시도해 주세요." |
실전 적용 가이드
1단계: 앱 내 모든 오류 메시지 목록화
앱의 오류 메시지를 모두 목록화하고 "What / Why / How / When" 요소가 포함되었는지 점검한다.
2단계: 개발자 용어 제거
HTTP 상태 코드(404, 500), 에러 코드(ERR_CONNECTION_REFUSED), 기술적 로그 메시지를 사용자 친화적 언어로 변환한다.
3단계: 해결 경로 제공
오류 메시지마다 사용자가 다음에 할 행동을 1가지 이상 제시한다. "다시 시도", "홈으로 돌아가기", "고객센터 문의" 같은 행동 버튼과 함께 오류 메시지를 표시하면 사용자 이탈이 줄어든다.
4단계: 오류 메시지 사용자 테스트
실제 사용자 5명에게 오류 메시지를 보여주고 "어떻게 하면 이 문제를 해결할 수 있을 것 같나요?"를 물어본다. 모두 정확히 행동할 수 있다면 메시지가 명확한 것이다.
자주 묻는 질문
Q. 오류 메시지에 유머를 넣으면 사용자 경험이 개선되나요?
A. 상황에 따라 다릅니다. 404 페이지처럼 실질적 피해가 없는 오류에서 가벼운 유머는 부정적 감정을 완화할 수 있습니다. 그러나 금융·결제·의료 관련 서비스나 데이터 손실이 발생한 경우에는 유머보다 명확한 사실과 해결 방법이 우선입니다.
Q. 서버 오류(500 에러)에서 기술적 정보를 사용자에게 얼마나 공개해야 하나요?
A. 보안 위험을 초래할 수 있는 서버 내부 정보(경로, 스택 트레이스, DB 쿼리 등)는 사용자에게 노출하지 않아야 합니다. 사용자에게는 "일시적인 오류가 발생했습니다. 잠시 후 다시 시도해 주세요." 정도의 메시지를 표시하고, 개발자를 위한 상세 로그는 서버 사이드에서 별도로 수집합니다.
마무리
이 글에서 정리한 기준을 실제 작업에 적용할 때는 [텍스터브 글자수 세기](/tools/char-counter/) 도구로 분량을 직접 확인하면서 진행하면 더 정확하게 맞출 수 있다.