경험 먼저, 시스템은 역산 | 토스 챗봇 설계 공부 정리

Toss Tech 블로그에서 고객센터 챗봇을 만든 이야기를 읽었다. 제목에 “AI로 바꾼 제품 설계의 순서”라고 돼 있어서, AI 기술을 어떻게 다뤘는지 기술적인 내용이 많을 줄 알았다. 읽어보니 그쪽보다는 제품 설계를 어디서부터 시작하느냐는 이야기였다. 그 방향이 흥미로워서 공부해봤다.

1️⃣ 이게 뭐냐?

일반적으로 제품을 만들 때 자주 보이는 흐름이 있다. 데이터 구조를 정의하고, 시스템을 설계하고, 사용자 경험은 그다음에 맞춰 넣는 방식. 토스팀이 소개한 건 그 반대였다. 이상적인 경험을 먼저 그리고, 그걸 가능하게 하는 것들을 역산해나갔다고.

기존 챗봇은 메뉴 선택식이었다. 고객이 버튼을 단계별로 클릭하면서 문제를 좁혀가는 방식인데, 절반 이상이 중간에 이탈했다고 한다. 자연어 입력으로 전환하면서 AI가 의도를 파악해 바로 해결해주는 방식으로 바뀌었다.

흥미로웠던 건 자연어 한 줄에 숨어 있는 상황의 복잡성이었다. “프리미엄 멤버십 해지”라는 말 안에 결제가 이미 됐는지, 혜택을 썼는지 같은 수십 가지 경우가 들어 있다. 이걸 전부 시나리오로 미리 짜두는 대신, AI가 맥락을 파악하게 만든 거다.

2️⃣ 내가 든 생각

기억에 남은 부분이 두 가지 있다.

하나는 무엇을 학습시키느냐의 차이였다. 정책 문서를 AI에게 먹이는 대신, 상담사와 고객이 실제로 나눈 대화 패턴을 학습시켰다고 한다. “정책 설명가”가 아니라 “문제해결가”처럼 움직이게 하기 위해서. 같은 AI를 써도 어떤 데이터를 학습시키느냐에 따라 결과물의 성격 자체가 달라진다는 게, 단순해 보이면서도 실제로는 꽤 중요한 선택인 것 같았다.

다른 하나는 시나리오 허브라는 내부 테스트 도구였다. 다양한 조건 조합을 미리 저장해두고 클릭 한 번으로 검증할 수 있는 도구인데, “이럴 것 같다”가 아니라 “실제로 이렇다”로 판단할 수 있게 해줬다고. 빠른 검증을 가능하게 하는 작은 도구 하나가 의사결정 방식을 바꿀 수 있다는 게 인상적이었다.

👉🏻 반복되는 문제를 개별로 고치는 대신 공통 원칙으로 수렴시켰다는 부분도 눈에 띄었다. “해결이 먼저, 설명은 나중에” 같은 원칙 하나가 수십 개의 케이스를 한 번에 바꾸는 방식.

💡 원칙은 언제 세우는 걸까? 처음부터 정해두는 건 어려울 것 같고, 반복 패턴이 어느 정도 쌓인 다음에야 보이는 게 아닐까 싶은데 — 이 부분은 지금도 잘 모르겠다.

공부하다 보니 이 접근이 디자인 작업과 닮은 구석이 있었다. 디자인에서도 이상적인 사용자 흐름을 먼저 그리고 제약을 나중에 넣는 게 이론상 맞는 방향이라고 하는데, 실제로는 기술 제약이나 데이터 제약을 먼저 전제하고 시작하는 경우가 많은 것 같다. 어디서 시작하느냐가 결과를 어떻게 다르게 만드는지 — 이 케이스를 읽으면서 그 차이가 조금 더 구체적으로 느껴졌다.

⭐️ 마지막으로, 제품 설계를 공부하면서 느낀 것

정리해보니 AI 챗봇 기술 이야기라기보다, 어디서 시작하느냐가 제품을 얼마나 다르게 만드는지에 대한 이야기에 가까웠다. 경험을 먼저 그리고 역산한다는 게 말로는 간단하게 들리는데, 데이터도 없고 시스템도 없는 상태에서 이상적 경험부터 정의한다는 게 실제로 어떤 작업인지는 문서만 봐서는 잘 안 와닿는다. 그 부분이 지금 남은 질문이다.

---

참고 원문: AI로 바꾼 제품 설계의 순서