원장 메시지는 왜 그대로 고객에게 보여주기 어려울까

모바일 웹서비스에 다국어 지원을 미리 준비해두면 좋겠다는 생각으로 화면에 노출되는 메시지를 하나씩 살펴보기 시작했습니다.

처음에는 기존 메시지를 리소스 파일로 옮기고 언어별 문구를 연결하면 될 것이라고 생각했습니다. 그런데 원장과 여러 내부 시스템에서 전달되는 메시지를 들여다보니, 번역 전에 먼저 고민해야 할 것이 있었습니다.

이 메시지를 고객에게 그대로 보여줘도 되는가 하는 문제였습니다.

시스템에는 정확하지만 고객에게는 어려웠습니다

원장 메시지는 업무 처리 상태를 구분하고 운영자가 원인을 확인하는 데 필요한 정보입니다.

업무 코드와 내부 용어, 처리 조건이 포함되어 있어 시스템 관점에서는 정확할 수 있습니다. 하지만 고객은 내부 구조를 알지 못합니다. 같은 메시지를 보더라도 무엇을 확인해야 하는지, 다시 시도하면 되는지, 상담이 필요한지 판단하기 어렵습니다.

하나의 원인에 비슷한 기술 메시지가 여러 개 존재하기도 했습니다. 반대로 고객에게는 서로 다르게 안내해야 하는 상황이 같은 메시지로 묶여 있는 경우도 있었습니다.

기술 메시지를 그대로 번역하면 언어만 바뀔 뿐 이해하기 어려운 문제는 그대로 남습니다.

고객 메시지를 정리하면서 문구의 자연스러움보다 고객이 다음에 무엇을 할 수 있는지를 먼저 보기로 했습니다.

원장의 상세 메시지는 로그와 운영 추적을 위해 보존하되, 화면에는 고객이 이해하고 행동할 수 있는 메시지를 제공하는 방향을 검토했습니다.

이를 위해 원장 메시지와 고객 메시지를 일대일로 단순 치환하기보다 업무 상황과 오류 코드, 화면 맥락을 함께 매핑해야 했습니다.

메시지를 너무 세분화하면 관리해야 할 문구가 계속 늘어납니다. 반대로 몇 개의 공통 메시지로만 줄이면 고객이 왜 업무를 진행할 수 없는지 알기 어렵습니다.

이번에는 고객의 다음 행동이 같다면 공통 메시지로 묶고, 다른 행동이 필요하다면 메시지를 분리하는 기준을 사용했습니다.

예를 들어 여러 기술 원인이 있더라도 고객이 입력값을 확인해야 하는 상황이라면 하나의 안내 유형으로 정리할 수 있습니다. 하지만 재로그인이 필요한 상황과 거래 조건을 충족하지 못한 상황은 서로 다른 안내가 필요합니다.

다국어 리소스에는 고객 메시지 키를 저장하고, 원장의 상세 코드와 원문은 서버 로그와 추적 정보에 남기는 구조를 함께 생각했습니다.

메시지를 정리하기 전에는 오류 응답에 들어가는 문구 정도로 생각하기 쉬웠습니다.

하지만 고객이 업무를 중단하게 되는 순간에는 메시지가 서비스 경험의 대부분이 됩니다. 무엇이 잘못되었는지보다 이제 무엇을 하면 되는지를 알려주는 것이 더 중요할 때도 있습니다.

다국어 지원을 준비하며 시작한 작은 점검은 원장 메시지와 고객 메시지의 역할을 다시 나누는 일로 이어졌습니다.

좋은 고객 메시지는 기술적인 원인을 감추는 문장이 아니라, 내부의 복잡한 상황을 고객이 이해할 수 있는 다음 행동으로 바꾸는 번역이라고 생각합니다.