챗봇 프로젝트를 진행하면서 가장 곤란했던 순간은 항상 "이런 질문은 예상 못 했는데요"라는 말이 나올 때였습니다.
시나리오를 열심히 짜놔도 실제 사용자는 예상치 못한 방식으로 질문을 던지더라고요.
이번 프로젝트를 거치면서 엣지케이스를 잡아내는 나름의 방법을 정리해봤습니다.
정상 시나리오만 테스트하면 절반만 검증한 것
처음 챗봇 테스트를 할 때는 저희가 정의한 시나리오대로만 대화를 주고받으면서 확인했습니다.
"배송 조회해주세요" → "주문번호 입력" → "배송 상태 안내" 순으로 흐름대로 진행하면 다 통과였어요.
그런데 실제 런칭 후 로그를 보니, 사용자들은 "배송 조회해주세요" 대신 "내 택배 어디 갔어요", "주문한 거 아직 안 왔는데요"처럼 훨씬 다양한 표현을 썼습니다.
정상 시나리오 테스트만으로는 이런 실제 표현의 다양성을 전혀 검증하지 못했던 거예요.
실제 사용자 표현을 미리 수집하는 방법
이 문제를 겪은 뒤로는 챗봇을 만들기 전에 먼저 "사람들이 이 의도를 어떻게 표현하는가"를 최대한 많이 수집하는 작업을 우선으로 두게 됐습니다.
저희가 쓴 방법은 세 가지였어요.
첫째, 기존 CS 상담 로그에서 같은 의도의 문의를 모두 뽑아서 표현 패턴을 정리했습니다.
"배송"이라는 단어가 들어간 문의만 300개 넘게 모아서 읽어봤는데, 표현 방식이 생각보다 훨씬 다양했어요.
둘째, 사내 동료들에게 "이 챗봇에 배송 조회를 요청한다면 어떻게 말할 것 같아요"라고 직접 물어봤습니다.
같은 팀 안에서도 사람마다 표현이 다르다는 걸 확인할 수 있었고, 이게 실제 사용자의 다양성을 어느 정도 미리 짐작하는 데 도움이 됐습니다.
셋째, 경쟁사나 유사 서비스의 챗봇에 비슷한 질문을 실제로 던져보면서 어떤 표현까지 처리하는지 참고했습니다.
오타와 축약어를 테스트에 반드시 포함시킨다
모바일 환경에서 사용자들은 오타를 정말 많이 냅니다.
"환불"을 "환볼"이라고 치거나, "배송"을 "배소"라고 치는 경우가 실제 로그에서 꽤 자주 보였어요.
저희는 테스트 케이스에 일부러 오타가 섞인 문장을 넣어서 챗봇이 어느 정도까지 이해하는지 확인했습니다.
완벽하게 다 잡아낼 수는 없었지만, 최소한 자주 나오는 오타 패턴 몇 가지는 사전에 유사어 처리로 잡아둘 수 있었어요.
연속된 대화에서 맥락이 깨지는 경우
단발성 질문은 대부분 잘 처리했는데, 대화가 몇 턴 이어지면 문제가 생기는 경우가 많았습니다.
사용자가 "배송 조회해주세요" 다음에 "그럼 반품은 어떻게 해요"라고 물으면, 챗봇이 이걸 새로운 독립적인 질문으로 처리하면서 방금 조회한 주문번호를 다시 물어보는 상황이 자주 발생했어요.
저희는 이 문제를 발견하고 나서 "직전 대화의 맥락(주문번호 등)을 몇 턴까지 유지할 것인가"를 명확히 정의하는 작업을 추가했습니다.
사용자 입장에서는 당연히 이어지는 대화라고 생각하는데, 챗봇이 매번 처음부터 다시 물어보면 짜증이 날 수밖에 없더라고요.
감정적인 문의에 대한 대응도 테스트해야 한다
이 부분은 초반에 전혀 신경 쓰지 못했던 부분입니다.
사용자가 화가 난 상태로 "환불 왜 안 해주는 거예요", "진짜 답답하네요"처럼 감정적인 표현을 섞어서 문의하는 경우가 꽤 있었어요.
이런 문의에 챗봇이 평소와 똑같이 기계적인 톤으로 응대하면 오히려 사용자의 불만이 더 커지는 걸 로그에서 확인했습니다.
그래서 특정 감정 표현 키워드가 감지되면 우선적으로 상담원 연결 옵션을 먼저 보여주는 예외 규칙을 추가했어요.
챗봇이 감정을 이해하는 척할 필요는 없지만, 최소한 감정적인 상황에서는 더 빠르게 사람에게 넘겨주는 판단은 필요하다고 생각합니다.
테스트를 누가, 언제 반복할 것인가
엣지케이스는 한 번 잡아낸다고 끝나는 게 아니라 서비스가 운영되면서 계속 새로 발견됩니다.
저희는 매주 실패 로그 상위 20개를 팀 전체가 같이 리뷰하는 시간을 만들었어요.
그 자리에서 "이건 왜 실패했지", "이건 어떤 표현으로 다시 물어보면 성공할까"를 같이 확인하면서 시나리오를 계속 보강했습니다.
처음엔 매주 이 시간을 내는 게 부담스러웠는데, 몇 달 지나고 나니 실패율이 확실히 줄어드는 게 눈에 보여서 오히려 이 시간이 팀에서 가장 만족도 높은 미팅이 됐습니다.
챗봇의 엣지케이스는 결국 "사람이 얼마나 다양하게 말하는가"를 미리 상상하는 능력의 문제였습니다.
아무리 꼼꼼하게 시나리오를 짜도 실제 사용자를 완벽하게 예측할 수는 없다는 걸 인정하고, 대신 실패를 빨리 발견하고 빠르게 보강하는 루틴을 만드는 게 현실적인 답이라고 생각합니다.
다음 프로젝트에서는 처음부터 이 리뷰 루틴을 기본 프로세스로 넣고 시작해볼 계획이에요.