AI 서비스 사용자 신뢰 확보를 위한 UX 라이팅

 

AI 기능을 붙인 서비스를 몇 개 운영해보면서 느낀 게 있습니다.
기능 자체의 정확도보다, 그 기능이 사용자에게 "어떻게 말을 거는지"가 신뢰에 훨씬 큰 영향을 준다는 거예요.
같은 정확도의 모델이라도 문구를 어떻게 쓰느냐에 따라 사용자 반응이 완전히 달라지는 걸 몇 번 경험했습니다.
그래서 이번엔 AI 서비스에서 UX 라이팅을 어떻게 다뤄야 하는지 정리해보려고 해요.

 

가장 흔한 실수는 모델이 틀렸을 때도 자신감 있는 어조를 그대로 두는 겁니다.
저희가 초반에 만든 상품 추천 챗봇은 "이 상품이 딱 맞습니다!"라는 문구를 항상 똑같이 붙였어요.
그런데 추천이 어긋났을 때도 같은 톤으로 말하니까, 사용자들이 "얘가 뭘 모르면서 아는 척한다"는 느낌을 받는다는 피드백이 계속 들어왔습니다.
반대로 확신이 낮을 때 "~일 수도 있어요", "참고로 봐주세요" 같은 표현을 섞었더니, 오히려 추천이 틀렸을 때도 불만이 줄었어요.
확신의 정도를 말투에 반영하는 것만으로도 신뢰도가 달라진다는 걸 그때 체감했습니다.

또 하나는 오류 메시지입니다.
"오류가 발생했습니다"라는 식의 기계적인 문구는 AI 기능에서 특히 더 불신을 키웁니다.
사용자는 "얘가 왜 틀렸는지"를 알고 싶어 하는데, 아무 설명 없이 실패만 던지면 "이거 원래 이렇게 부실한 거 아니야"라는 인상을 주게 돼요.

 

저희가 사내 문서 검색 챗봇을 만들 때 가장 신경 쓴 부분은 답변의 확신 정도를 세 단계로 나눠서 문구를 다르게 설계하는 것이었어요. 
근거 문서가 명확할 때는 "문서에 따르면"으로 시작하고, 근거가 간접적일 때는 "관련 자료를 참고하면"으로, 근거가 부족할 때는 "정확한 답을 찾지 못했지만"으로 시작하도록 했습니다.
이 세 단계를 나누는 데 두 달 가까이 걸렸는데, 나눈 뒤로는 사용자 만족도 조사에서 "믿을 만하다"는 응답이 눈에 띄게 늘었어요.

출처를 보여주는 것도 큰 역할을 했습니다.
답변 끝에 원문 링크를 붙였을 뿐인데, "확인해볼 수 있어서 좋다"는 피드백이 압도적으로 많았어요.
사실 링크를 실제로 클릭하는 사용자는 전체의 15% 정도밖에 안 됐는데, 그럼에도 "확인할 수 있는 문구가 있다"는 사실 자체가 신뢰를 만든다는 게 흥미로웠습니다.

 

AI가 답을 거부해야 하는 상황도 미리 문구를 준비해둬야 합니다.
저희는 민감한 질문이 들어오면 그냥 차단만 하고 아무 설명을 안 했었는데, 사용자들이 "버그인가"라고 오해하는 경우가 많았어요.
그래서 "이 질문에는 제가 답을 드리기 어려워요. 대신 이런 방법을 시도해보시면 어떨까요"라는 식으로 대체 경로를 함께 안내하도록 바꿨습니다.
거부하는 것 자체는 그대로였지만, 이유와 대안을 같이 주니까 불만 문의가 절반 가까이 줄었어요.

응답이 늦어질 때의 문구도 생각보다 중요했습니다.
"처리 중입니다"라는 무미건조한 문구 대신, "관련 자료 12건을 찾아보고 있어요"처럼 진행 상황을 보여주는 문구로 바꿨더니, 같은 대기 시간인데도 사용자가 느끼는 체감 시간이 줄었다는 인터뷰 결과를 받았습니다.

 

그리고 여러 팀이 각자 문구를 만들다 보니, 같은 서비스인데도 기능마다 AI가 다른 성격처럼 느껴지는 문제가 있었어요.
어떤 기능은 반말 톤에 가깝게 캐주얼했고, 어떤 기능은 지나치게 격식 있는 문어체였습니다.
저희는 결국 "AI 응답 톤 가이드"라는 짧은 문서를 만들어서, 1인칭 표현, 확신 표현 단계, 금지 표현 목록을 정리했어요.
이 가이드를 만든 뒤로는 신규 기능을 붙일 때마다 카피라이터가 먼저 체크하는 프로세스가 생겼고, 톤이 들쑥날쑥한 문제가 확실히 줄었습니다.

 

문구를 감으로만 정하는 게 불안해서, 몇몇 핵심 화면에는 실제로 A/B 테스트를 돌려봤습니다.
같은 폴백 상황에서 "죄송합니다, 이해하지 못했어요"와 "아직 이 부분은 제가 정확히 못 알아들었어요. 다르게 한번 물어봐 주시겠어요?"를 나눠서 노출했는데, 후자 쪽에서 재질문 시도율이 23%포인트 높게 나왔습니다.
숫자로 확인하고 나니, 그동안 "이 정도 문구면 되겠지"라고 감으로 넘겼던 부분들이 얼마나 근거 없었는지 새삼 깨달았어요.
그 이후로는 문구를 크게 바꾸는 결정이 있을 때마다 최소 1주일은 A/B로 검증하는 걸 원칙으로 삼았습니다.
다만 이 검증에는 시간이 걸리기 때문에, 급하게 나가야 하는 기능에는 과거 데이터에서 검증된 패턴을 우선 적용하고 사후에 검증하는 식으로 유연하게 조정하고 있어요.

 

지금 저희 팀이 새 AI 기능을 낼 때 항상 확인하는 목록입니다.
확신 정도에 따라 문구 톤이 다른가, 틀렸을 때 사용자가 이의를 제기할 경로가 있는가, 거부 상황에 대체 행동을 안내하는가, 대기 시간에 진행 상황을 보여주는가, 그리고 전체 서비스 안에서 톤이 일관적인가.
다섯 개밖에 안 되지만, 이 체크리스트를 통과하지 못해서 다시 문구를 고친 기능이 벌써 세 개나 됩니다. 

 

이 작업을 하면서 새롭게 정리된 게, 카피라이터와 기획자의 역할 경계였습니다.
예전엔 문구를 카피라이터에게 통째로 넘기고 "톤 좋게 다듬어주세요"라고 요청하는 식이었는데, AI 기능에서는 이렇게 넘기면 확신 표현이나 리스크 관련 뉘앙스가 빠질 위험이 있었습니다.
그래서 저는 기획 단계에서 먼저 "이 상황에서는 확신 표현을 어느 정도로 넣어야 하는지"를 초안으로 잡아두고, 그 위에 카피라이터가 톤을 다듬는 순서로 작업 방식을 바꿨어요.
반대로 카피라이터는 저희 기획자들이 놓치기 쉬운 "사용자가 실제로 이 표현을 어떻게 읽을지"에 대한 감각을 계속 짚어줬습니다.
이 역할 분담이 자리 잡은 뒤로는, 문구 하나를 두고 몇 번씩 왔다 갔다 하는 비효율이 확실히 줄었어요.

AI 기능의 UX 라이팅은 단순히 "친절하게 쓰기"가 아니라 "모델의 한계를 사용자에게 정직하게 전달하는 방법"이라고 생각합니다.
문구 하나 바꾸는 게 뭐 대단한 일이냐 싶었는데, 실제로 지표가 움직이는 걸 보고 나서는 이 작업을 절대 가볍게 보지 않게 됐어요.
다음엔 다국어 서비스에서 이 톤을 어떻게 유지할지도 한번 다뤄보고 싶은 생각이 들어요.