에러 메시지도 브랜드예요, 상황·원인·해결 3단 해요체 카피 규칙

혹시 "오류가 발생했습니다"라는 문구를 그대로 두고 계신가요? 랜딩 페이지 카피는 며칠씩 다듬으면서 에러 화면은 프레임워크 기본 문구로 남겨두는 경우가 많아요. 혼자 운영하면서 저도 그랬어요.

에러 화면이 브랜드 접점인 이유

사용자가 브랜드 말투를 가장 또렷하게 기억하는 순간은 잘 될 때가 아니라 막혔을 때예요. 저장이 안 되거나 검색 결과가 안 나올 때 어떤 말이 나오는지가 곧 그 서비스의 태도로 읽혀요. 1인 브랜드는 고객센터가 따로 없으니 에러 문구가 첫 응대이자 마지막 응대가 되기도 해요.

상황·원인·해결 3단 규칙

직접 만들어 보니 규칙은 단순할수록 지켜졌어요. 에러 문구 하나를 세 줄로 쪼갭니다.

상황(무슨 일이 생겼는지)→원인(왜 그런지)→해결(지금 할 수 있는 일)

상황은 사용자가 보는 결과만 적어요. "저장이 안 됐어요"처럼요. 원인은 사용자가 이해할 수 있는 말로 한 줄, 코드명이나 스택 트레이스는 넣지 않아요. 해결은 버튼 이름과 같은 동사로 끝내요. "다시 시도하기"처럼 버튼과 문구가 같은 말을 쓰면 다음 행동이 바로 보여요.

해요체는 세 줄 모두 유지해요. 상황은 해요체인데 해결만 "재시도하십시오"로 끝나면 톤이 갈라지고, 그 어긋남을 사용자가 먼저 느껴요.

직접 적용해 본 순서

플랜엘(plan-l)은 법령·판례 검색을 월 3건까지 무료로 제공하는데, 무료 횟수를 다 쓴 사용자에게 어떤 말을 보여줄지가 첫 실험 대상이었어요. 처음엔 "사용 한도를 초과했습니다" 한 줄이었어요. 3단으로 고쳐 보니 "이번 달 무료 검색 3건을 모두 썼어요 / 무료 검색은 한 달에 3건까지예요 / 다음 달에 다시 검색하기"가 됐어요. 문구는 길어졌지만 사용자가 왜 막혔는지 스스로 알 수 있게 됐어요.

순서는 이랬어요. 코드에서 에러 문구를 전부 뽑아 표로 만들었더니 12개가 나왔고, 상황·원인·해결 세 열을 채우는 데 30분 정도 걸렸어요. 적용해 봤더니 세 열 중 비는 칸이 있으면 그 에러는 아직 설계가 덜 된 상태였어요. 원인을 못 쓰겠으면 저도 원인을 모르는 거였고, 해결을 못 쓰겠으면 사용자에게 시킬 일이 없는 화면이었어요.

카피 점검 기준

• ✓한 줄 20자 안쪽
• ✓코드명 금지
• ✓버튼과 같은 동사
• ✓세 줄 모두 해요체

테스트해 보면 한 줄이 20자를 넘길 때 모바일에서 두 줄로 꺾여 3단 구조가 무너져요. 그래서 상황 문장은 20자 안에서 끊는 걸 기준으로 삼았어요. 사과 표현은 상황 줄에 한 번만 두고 원인과 해결에는 반복하지 않아요. 미안하다는 말이 세 번 나오면 오히려 불안해 보여요.

작은 브랜드일수록 먼저 손댈 곳

랜딩 카피는 한 번 보고 지나가지만 에러 문구는 막힐 때마다 다시 만나요. 열두 개 문구를 30분에 통일하는 일이 1인 브랜드가 할 수 있는 가장 싼 브랜딩이었어요. 지금 운영 중인 서비스가 있다면 에러 문구부터 표로 뽑아 보세요. 빈 칸이 보이는 순간 무엇을 고칠지도 같이 보여요.