<div id="readability-page-1" class="page"><div>안녕하세요. 토스에서 고객센터 챗봇 설계를 담당하고 있는 Product Designer 김유라입니다. 이번 글에서는 토스 고객센터 AI 챗봇을 만들면서 시도했던 새로운 설계 방식을 이야기해 보려고 해요.<h2 id="381a360d-33e3-80fc-9c76-c647f4ff358c">배경</h2>고객센터 방문자는 한 달에 약 60만 명이고, 그 중 약 17만 명이 채팅 상담을 시도해요. 그런데 챗봇에 들어온 사용자의 약 60%가 중간에 이탈했어요. 가장 큰 문제는 챗봇의 구조였죠.<figure id="381a360d-33e3-8045-b588-ea52954b75d3"><img src="https://static.toss.im/ipd-tcs/toss_core/live/97631620-aad3-44f6-9695-992202ae7dfb/image.png" alt=""></figure><figure id="381a360d-33e3-80db-9e41-cbab31192ad0"><img src="https://static.toss.im/ipd-tcs/toss_core/live/35e73e6d-91c7-4b60-9299-334c0908623c/image.png" alt=""></figure>통신3사와 관련된 문의를 하려면 거쳐야 하는 과정원하는 답을 찾으려면 메뉴를 하나씩 눌러가며 탐색해야 했어요. 문제는 사용자는 자신의 문제는 알아도, 서비스가 그걸 어떤 카테고리로 분류했는지는 모른다는 거예요."결제가 안 돼요.""프리미엄 멤버십을 해지하고 싶어요.""송금을 잘못 보냈어요."사용자가 아는 건 이게 전부예요. 그래서 카테고리를 찾아야 하는 구조 자체를 없애고, 자연어로 말하면 AI가 의도를 파악해서 필요한 행동으로 바로 연결해 주는 경험으로 바꾸기로 했죠.<h2 id="381a360d-33e3-80c6-8645-ebdc7536de4c">설계 방식을 뒤집다</h2>챗봇은 보통 이런 순서로 만들어져요.고객 문의 분석 → 유형 정리 → 시나리오 작성 → 리뷰 및 수정 → 프로토타입 제작 → 개발시나리오란 특정 문의가 들어왔을 때 챗봇이 어떤 순서로 무슨 말을 할지 미리 짜놓은 대화 흐름인데요. 가장 설계하기 복잡한 부분이에요. 예를 들어 "프리미엄 멤버십을 해지하고 싶어요"라는 하나의 문의에도 전혀 다른 여러 상황이 숨어 있거든요.<ul><li id="381a360d-33e3-8017-afae-fbbc85f66640">이번 달 이용료를 이미 결제한 고객</li><li id="381a360d-33e3-80dd-9816-e892f59234b9">아직 결제하지 않은 고객</li><li id="381a360d-33e3-80ce-a88c-f74b74ebc2bb">혜택을 이미 사용한 고객</li><li id="381a360d-33e3-80c9-8d91-feec6298e8aa">혜택을 한 번도 사용하지 않은 고객</li><li id="381a360d-33e3-809c-84f8-f3fbb423b9eb">해지 예약이 이미 되어 있는 고객</li></ul>사용자는 모두 같은 말로 시작하지만, 확인해야 할 정보도 안내할 내용도 달라요. 하나의 문의처럼 보여도 뒤에서는 수십 개의 분기가 생기죠. 보통은 모든 시나리오를 완성한 뒤 프로토타입을 만들어요. 그런데 이번에는 순서를 조금 바꿔보기로 했어요.시나리오를 먼저 완성하는 대신, AI로 시나리오 초안을 만들고 곧바로 프로토타입에서 검증하기 시작한 거예요. 시나리오와 프로토타입을 함께 발전시키는 방식으로요.<h2 id="381a360d-33e3-8042-bab5-ff48564b3e83">1단계) 실제 상담 데이터로 시나리오 초안 만들기</h2>고객센터에서 가장 많이 발생하는 상담 유형 20개를 뽑아서 AI가 시나리오 초안을 만들도록 했어요. 학습에 활용한 데이터는 개인정보를 제거하고 가명·익명 처리한 뒤 활용했죠.우리가 만들고 싶었던 건 정책을 잘 설명하는 챗봇이 아니었어요. 고객의 문제를 이해하고, 필요한 정보를 확인하고, 해결 방법까지 자연스럽게 안내하는 ‘사람 같은 챗봇’이었죠.그래서 시나리오를 만들 때 AI가 어떤 정보를 참고하게 할지 고민했어요. 상담 가이드에는 정책과 기능이 잘 정리되어 있었지만, 실제 상담이 어떻게 진행되는지는 담겨 있지 않았어요. 반면 상담 데이터에는 고객이 어떤 표현으로 질문하는지, 상담사가 어떤 순서로 문제를 해결하는지 생생한 정보가 그대로 담겨 있었어요.고객은 "결제가 왜 안 되죠?"처럼 넓은 문제를 이야기하지만, 상담사는 필요한 정보를 확인하고 원인을 하나씩 좁혀가며 문제를 해결하잖아요. 복잡한 정책과 기능도 고객이 이해할 수 있는 언어로 풀어서 설명하고요.그래서 AI에게 정책을 학습시키기보다 상담 경험을 학습시키는 게 더 효과적이라고 판단했어요. 결과적으로 AI는 단순히 정보를 나열하는 대신, 실제 상담사가 고객을 응대하는 방식에 더 가까운 시나리오를 만들 수 있었어요.
<h2 id="381a360d-33e3-80d5-abcd-d74b10c683f5">2단계 ) 수십 개의 상황을 빠르게 검증하기</h2>시나리오 초안을 만들고 바로 프로토타입을 만들었어요. 답변이 어색한지, 질문 순서가 이상한지 실제로 대화를 해봐야 알 수 있으니까요.그런데 위에서 말했듯, 하나의 문의에도 수십 개의 상황 조합이 존재했어요. 매번 조건을 바꿔가며 테스트하는 건 너무 비효율적이었죠.그래서 다양한 상황을 빠르게 검증할 수 있는 시나리오 허브를 만들었어요.<figure id="382a360d-33e3-80f3-ad00-d33dfb3502e9"><img src="https://static.toss.im/ipd-tcs/toss_core/live/d8b4d38a-a698-47bf-9cf6-66002d5d5ad2/22.gif" alt=""></figure>같은 '프리미엄 멤버십 해지' 문의라도 '이미 이번 달 결제를 완료한 고객', '혜택을 사용한 고객'처럼 여러 상황이 있을 수 있잖아요. 이런 조합을 미리 저장해두고 원하는 시나리오를 선택할 수 있도록 했어요. 상황을 선택하면 오른쪽에서 해당 조건이 적용된 상태로 챗봇 대화가 바로 시작됐고요.덕분에 시나리오를 수정한 뒤에도 해당 상황으로 바로 들어가서 답변이 의도대로 나오는지 빠르게 확인할 수 있었어요. 새로운 분기가 추가되거나 규칙이 변경될 때도 같은 방식으로 반복 검증할 수 있었고요.무엇보다 좋았던 건 진짜 같은 결과물을 바로 만들어볼 수 있었다는 점이었어요. 시나리오만 봤을 때는 괜찮아 보였던 흐름도 실제로 대화를 해보면 어색한 경우가 많았거든요.실제 데이터를 적용한 상태로 프로토타입을 만들 수 있으니 고객이 겪게 될 경험을 훨씬 현실적으로 볼 수 있었어요. 덕분에 '이럴 것 같다'가 아니라 '실제로 이렇다'를 기준으로 판단할 수 있었죠.결과적으로 이 프로토타입은 단순한 목업이 아니라, AI가 생성한 시나리오를 테스트하고 개선하기 위한 실험 환경이 되었어요.<h2 id="381a360d-33e3-80df-99a0-c82a13099be4">3단계) 시나리오를 고치기보다 규칙을 만들기</h2>시나리오 허브를 만들고 실제로 대화를 검증해 보니 예상하지 못한 문제들이 계속 발견됐어요.이미 알고 있는 정보를 다시 물어보기도 하고, 같은 설명을 반복하기도 하고, 틀린 정보를 추측해서 답변하기도 했어요.처음에는 문제를 발견할 때마다 시나리오를 하나씩 수정했어요. 그런데 검증할수록 비슷한 문제가 반복해서 나타났어요. 그래서 개별 시나리오를 수정하는 대신, 이런 문제를 방지하기 위한 규칙을 만들기 시작했어요.예를 들면 이런 원칙들이요.<ul><li id="381a360d-33e3-8031-b604-fa6ce6386e4b">해결이 먼저, 설명은 나중에</li><li id="381a360d-33e3-8033-9a44-d8d51f59297f">추측하지 말고 모르면 모른다고 하기</li><li id="381a360d-33e3-805d-88cb-da225e5cf833">상담사 연결은 특정 조건에서 진행하기</li><li id="381a360d-33e3-8069-b073-f7b2827c0577">AI의 권한 경계 확실히 하기</li></ul>시나리오를 검증할 때마다 규칙이 하나씩 늘어났고, 그 규칙을 다시 AI에게 반영했어요.시나리오를 수정하면 하나만 좋아지는데, 규칙 하나를 수정하면 모든 시나리오가 같이 좋아지기 때문에 규칙을 만들수록 검증 속도가 빨라졌죠.<h2 id="381a360d-33e3-8005-8823-c1d3b601a189">경험을 먼저 만들고, 나머지는 나중에 정의하기</h2>이번 프로젝트에서 가장 재밌었던 점은 이상적인 사용자 경험을 먼저 그려보고, 그 경험을 구현하는 데 필요한 것들을 하나씩 역산해 나갔다는 거예요. 보통은 데이터 구조를 정의하고, 운영 도구를 만들고, 시스템을 설계한 뒤 그 위에 사용자 경험을 고민하죠. 그런데 이번에는 반대로 진행했어요.그러다 보니 오히려 그다음에 필요한 것들이 선명하게 보이기 시작했어요. "이 경험을 구현하려면 어떤 데이터가 필요하지?""어떤 API가 필요하지?""어떤 운영 도구가 필요하지?"이렇게 하니까 처음부터 모든 걸 설계하는 대신, 정말 필요한 것만 빠르게 정의할 수 있었어요. 팀에 합류하고 약 3주 만에 현황 분석부터 경험 설계, 시나리오 생성, 프로토타입 제작, 검증, 고도화까지 진행할 수 있었죠.AI가 바꾼 것은 단순한 생산성이 아니라 제품을 설계하는 순서였어요. 구현을 전제로 경험을 설계하는 것이 아니라, 경험을 먼저 그려보고 검증한 뒤 필요한 것들을 정의하는 방식으로요. 그래서 AI는 일을 대신 해주는 도구라기보다, 좋은 경험을 훨씬 빠르게 검증할 수 있게 해주는 도구에 가까웠어요.디자이너가 시간을 쓰는 지점도 달라졌어요.예전에는 화면을 그리고 시나리오를 작성하는 데 많은 시간을 썼어요. 좋은 아이디어가 있어도 구현 비용이 크다 보니 실제로 검증해 보기 전에 포기하는 경우도 많았고요.그런데 이번 프로젝트에서는 상황이 조금 달랐어요. AI 덕분에 시나리오를 만들고, 프로토타입을 구현하고, 검증하는 비용이 크게 줄어들었거든요. 덕분에 화면을 그리거나 시나리오를 작성하는 시간보다, 어떤 경험이 더 좋은 경험인지, 어떤 규칙이 더 좋은 규칙인지, 무엇을 검증해야 하는지를 판단하는 시간이 더 중요해졌어요.AI가 대신 만들어준 게 아니라, 더 많은 선택지를 빠르게 검증할 수 있게 된 거죠.이런 방식은 챗봇을 만드는 과정뿐 아니라, 새로운 제품이나 기능을 설계할 때도 충분히 적용될 수 있을 것 같아요.<h2 id="381a360d-33e3-801f-bc3c-ff8ffe62ca09">적용해 보기</h2></div></div>

토스테크

안녕하세요. 토스에서 고객센터 챗봇 설계를 담당하고 있는 Product Designer 김유라입니다. 이번 글에서는 토스 고객센터 AI 챗봇을 만들면서 시도했던 새로운 설계 방식을 이야기해 보려고 해요.
배경
고객센터 방문자는 한 달에 약 60만 명이고, 그 중 약 17만 명이 채팅 상담을 시도해요. 그런데 챗봇에 들어온 사용자의 약 60%가 중간에 이탈했어요. 가장 큰 문제는 챗봇의 구조였죠.
통신3사와 관련된 문의를 하려면 거쳐야 하는 과정
원하는 답을 찾으려면 메뉴를 하나씩 눌러가며 탐색해야 했어요. 문제는 사용자는 자신의 문제는 알아도, 서비스가 그걸 어떤 카테고리로 분류했는지는 모른다는 거예요.
"결제가 안 돼요."
"프리미엄 멤버십을 해지하고 싶어요."
"송금을 잘못 보냈어요."
사용자가 아는 건 이게 전부예요. 그래서 카테고리를 찾아야 하는 구조 자체를 없애고, 자연어로 말하면 AI가 의도를 파악해서 필요한 행동으로 바로 연결해 주는 경험으로 바꾸기로 했죠.
설계 방식을 뒤집다
챗봇은 보통 이런 순서로 만들어져요.
고객 문의 분석 → 유형 정리 → 시나리오 작성 → 리뷰 및 수정 → 프로토타입 제작 → 개발
시나리오란 특정 문의가 들어왔을 때 챗봇이 어떤 순서로 무슨 말을 할지 미리 짜놓은 대화 흐름인데요. 가장 설계하기 복잡한 부분이에요. 예를 들어 "프리미엄 멤버십을 해지하고 싶어요"라는 하나의 문의에도 전혀 다른 여러 상황이 숨어 있거든요.
이번 달 이용료를 이미 결제한 고객
아직 결제하지 않은 고객
혜택을 이미 사용한 고객
혜택을 한 번도 사용하지 않은 고객
해지 예약이 이미 되어 있는 고객
사용자는 모두 같은 말로 시작하지만, 확인해야 할 정보도 안내할 내용도 달라요. 하나의 문의처럼 보여도 뒤에서는 수십 개의 분기가 생기죠. 보통은 모든 시나리오를 완성한 뒤 프로토타입을 만들어요. 그런데 이번에는 순서를 조금 바꿔보기로 했어요.
시나리오를 먼저 완성하는 대신, AI로 시나리오 초안을 만들고 곧바로 프로토타입에서 검증하기 시작한 거예요. 시나리오와 프로토타입을 함께 발전시키는 방식으로요.
1단계) 실제 상담 데이터로 시나리오 초안 만들기
고객센터에서 가장 많이 발생하는 상담 유형 20개를 뽑아서 AI가 시나리오 초안을 만들도록 했어요. 학습에 활용한 데이터는 개인정보를 제거하고 가명·익명 처리한 뒤 활용했죠.
우리가 만들고 싶었던 건 정책을 잘 설명하는 챗봇이 아니었어요. 고객의 문제를 이해하고, 필요한 정보를 확인하고, 해결 방법까지 자연스럽게 안내하는 ‘사람 같은 챗봇’이었죠.
그래서 시나리오를 만들 때 AI가 어떤 정보를 참고하게 할지 고민했어요. 상담 가이드에는 정책과 기능이 잘 정리되어 있었지만, 실제 상담이 어떻게 진행되는지는 담겨 있지 않았어요. 반면 상담 데이터에는 고객이 어떤 표현으로 질문하는지, 상담사가 어떤 순서로 문제를 해결하는지 생생한 정보가 그대로 담겨 있었어요.
고객은 "결제가 왜 안 되죠?"처럼 넓은 문제를 이야기하지만, 상담사는 필요한 정보를 확인하고 원인을 하나씩 좁혀가며 문제를 해결하잖아요. 복잡한 정책과 기능도 고객이 이해할 수 있는 언어로 풀어서 설명하고요.
그래서 AI에게 정책을 학습시키기보다 상담 경험을 학습시키는 게 더 효과적이라고 판단했어요. 결과적으로 AI는 단순히 정보를 나열하는 대신, 실제 상담사가 고객을 응대하는 방식에 더 가까운 시나리오를 만들 수 있었어요.
2단계 ) 수십 개의 상황을 빠르게 검증하기
시나리오 초안을 만들고 바로 프로토타입을 만들었어요. 답변이 어색한지, 질문 순서가 이상한지 실제로 대화를 해봐야 알 수 있으니까요.
그런데 위에서 말했듯, 하나의 문의에도 수십 개의 상황 조합이 존재했어요. 매번 조건을 바꿔가며 테스트하는 건 너무 비효율적이었죠.
그래서 다양한 상황을 빠르게 검증할 수 있는 시나리오 허브를 만들었어요.
같은 '프리미엄 멤버십 해지' 문의라도 '이미 이번 달 결제를 완료한 고객', '혜택을 사용한 고객'처럼 여러 상황이 있을 수 있잖아요. 이런 조합을 미리 저장해두고 원하는 시나리오를 선택할 수 있도록 했어요. 상황을 선택하면 오른쪽에서 해당 조건이 적용된 상태로 챗봇 대화가 바로 시작됐고요.
덕분에 시나리오를 수정한 뒤에도 해당 상황으로 바로 들어가서 답변이 의도대로 나오는지 빠르게 확인할 수 있었어요. 새로운 분기가 추가되거나 규칙이 변경될 때도 같은 방식으로 반복 검증할 수 있었고요.
무엇보다 좋았던 건 진짜 같은 결과물을 바로 만들어볼 수 있었다는 점이었어요. 시나리오만 봤을 때는 괜찮아 보였던 흐름도 실제로 대화를 해보면 어색한 경우가 많았거든요.
실제 데이터를 적용한 상태로 프로토타입을 만들 수 있으니 고객이 겪게 될 경험을 훨씬 현실적으로 볼 수 있었어요. 덕분에 '이럴 것 같다'가 아니라 '실제로 이렇다'를 기준으로 판단할 수 있었죠.
결과적으로 이 프로토타입은 단순한 목업이 아니라, AI가 생성한 시나리오를 테스트하고 개선하기 위한 실험 환경이 되었어요.
3단계) 시나리오를 고치기보다 규칙을 만들기
시나리오 허브를 만들고 실제로 대화를 검증해 보니 예상하지 못한 문제들이 계속 발견됐어요.
이미 알고 있는 정보를 다시 물어보기도 하고, 같은 설명을 반복하기도 하고, 틀린 정보를 추측해서 답변하기도 했어요.
처음에는 문제를 발견할 때마다 시나리오를 하나씩 수정했어요. 그런데 검증할수록 비슷한 문제가 반복해서 나타났어요. 그래서 개별 시나리오를 수정하는 대신, 이런 문제를 방지하기 위한 규칙을 만들기 시작했어요.
예를 들면 이런 원칙들이요.
해결이 먼저, 설명은 나중에
추측하지 말고 모르면 모른다고 하기
상담사 연결은 특정 조건에서 진행하기
AI의 권한 경계 확실히 하기
시나리오를 검증할 때마다 규칙이 하나씩 늘어났고, 그 규칙을 다시 AI에게 반영했어요.
시나리오를 수정하면 하나만 좋아지는데, 규칙 하나를 수정하면 모든 시나리오가 같이 좋아지기 때문에 규칙을 만들수록 검증 속도가 빨라졌죠.
경험을 먼저 만들고, 나머지는 나중에 정의하기
이번 프로젝트에서 가장 재밌었던 점은 이상적인 사용자 경험을 먼저 그려보고, 그 경험을 구현하는 데 필요한 것들을 하나씩 역산해 나갔다는 거예요. 보통은 데이터 구조를 정의하고, 운영 도구를 만들고, 시스템을 설계한 뒤 그 위에 사용자 경험을 고민하죠. 그런데 이번에는 반대로 진행했어요.
그러다 보니 오히려 그다음에 필요한 것들이 선명하게 보이기 시작했어요. 
"이 경험을 구현하려면 어떤 데이터가 필요하지?"
"어떤 API가 필요하지?"
"어떤 운영 도구가 필요하지?"
이렇게 하니까 처음부터 모든 걸 설계하는 대신, 정말 필요한 것만 빠르게 정의할 수 있었어요. 팀에 합류하고 약 3주 만에 현황 분석부터 경험 설계, 시나리오 생성, 프로토타입 제작, 검증, 고도화까지 진행할 수 있었죠.
AI가 바꾼 것은 단순한 생산성이 아니라 제품을 설계하는 순서였어요. 구현을 전제로 경험을 설계하는 것이 아니라, 경험을 먼저 그려보고 검증한 뒤 필요한 것들을 정의하는 방식으로요. 그래서 AI는 일을 대신 해주는 도구라기보다, 좋은 경험을 훨씬 빠르게 검증할 수 있게 해주는 도구에 가까웠어요.
디자이너가 시간을 쓰는 지점도 달라졌어요.
예전에는 화면을 그리고 시나리오를 작성하는 데 많은 시간을 썼어요. 좋은 아이디어가 있어도 구현 비용이 크다 보니 실제로 검증해 보기 전에 포기하는 경우도 많았고요.
그런데 이번 프로젝트에서는 상황이 조금 달랐어요. AI 덕분에 시나리오를 만들고, 프로토타입을 구현하고, 검증하는 비용이 크게 줄어들었거든요. 덕분에 화면을 그리거나 시나리오를 작성하는 시간보다, 어떤 경험이 더 좋은 경험인지, 어떤 규칙이 더 좋은 규칙인지, 무엇을 검증해야 하는지를 판단하는 시간이 더 중요해졌어요.
AI가 대신 만들어준 게 아니라, 더 많은 선택지를 빠르게 검증할 수 있게 된 거죠.
이런 방식은 챗봇을 만드는 과정뿐 아니라, 새로운 제품이나 기능을 설계할 때도 충분히 적용될 수 있을 것 같아요.
적용해 보기
1️⃣ 완벽하게 설계하려고 하지 말고 먼저 만들어보기
구현이 어렵거나 비용이 많이 들 것 같아서 미뤄두고 있는 아이디어가 있나요? AI를 활용하면 생각보다 빠르게 프로토타입을 만들 수 있어요. 완벽한 설계가 끝날 때까지 기다리기보다 먼저 만들어보고 검증해 보세요. 어떤 문제가 있는지, 어떤 방향이 맞는지 훨씬 빨리 알 수 있어요.
2️⃣ 가이드보다 실제 데이터를 먼저 살펴보기
실제 사용자 데이터에는 문서에 없는 맥락이 숨어 있는 경우가 많아요. 사용자가 어떤 표현을 쓰는지, 어디에서 막히는지, 실제로 어떻게 문제를 해결하는지 먼저 살펴보세요. 생각보다 많은 답이 이미 사용자 행동 안에 들어있을 수 있어요.
3️⃣ 같은 문제를 반복해서 고치고 있다면 규칙을 찾아보기
비슷한 문제가 여러 번 반복된다면 개별 수정보다 공통 원칙을 만드는 편이 더 효과적일 수 있어요. 규칙 하나가 수십 개의 케이스를 동시에 개선하기도 하니까요.

AI로 바꾼 제품 설계의 순서

댓글