5
시나리오는 혼자 쓰는 문서가 아니라, 함께 듣고 엮어내는 ‘대화의 지도’다.
보이스봇 프로젝트가 본격적으로 시작되면, 회의실에는 이런 말이 가장 먼저 나온다.
“XX 상담 흐름을 정리해 주세요.”
겉으로는 단순한 업무 요청처럼 들리지만, 실제로 ‘흐름을 정리한다’는 건 훨씬 더 복잡한 일이다.
상담사가 고객과 나눈 말, 그 안에 스며든 감정과 맥락, 그리고 조직이 오랫동안 쌓아온 응대의 습관까지 하나의 이야기로 다시 엮는 작업이기 때문이다.
즉, 시나리오를 정리한다는 건 단순히 문서를 쓰는 일이 아니라 사람의 경험을 구조로 재해석하는 일이다.
그리고 그 과정은 ‘누가 쓰느냐’보다 ‘어떻게 함께 정리하느냐’가 훨씬 중요하다.
보이스봇은 대화를 설계하는 기술이다.
그래서 시나리오는 누군가 기획해 놓은 것을 옮겨 적는 문서가 아니라, 팀이 함께 정의해 가는 과정이어야 한다.
특히 여러 시스템이 얽힌 프로젝트에서는 시작 단계부터 모두가 같은 그림을 봐야 한다.
흐름이 완성된 뒤 합류하면, 그때부터는 이미 많은 게 결정되어 있다.
‘기획자만 먼저 정리하면 되지 않나요?’라는 질문이 자주 나오지만, 현실은 그 반대다.
같이 만들수록 명확해진다.
그 이유는 세 가지다.
① 함께 만들면, 역할이 또렷해진다.
요구사항이 모호한 프로젝트일수록 흐름을 만드는 과정 자체가 곧 업무 정의다.
대화 설계자는 필요한 시나리오를, 개발자는 필요한 연동 구조를, 운영 담당자는 필요한 화면을 동시에 파악한다.
따로 설계해 나중에 공유하고 합을 맞추는 방식보다 빠르고, 누락이 적다.
② 모두가 같은 그림을 본다.
같은 회의, 같은 화면 안에서 논의가 이뤄지면 문서보다 많은 것이 전달된다.
회의의 공기, 말의 톤, 문제의식까지 함께 공유된다.
그래서 작은 구현 하나에도 팀 전체의 맥락이 자연스럽게 스며든다.
③ 시나리오가 현실을 닮는다.
혼자 만든 시나리오는 논리적으로 완벽해 보여도 현장의 변수와 고객의 언어를 담기 어렵다.
현장과 개발, 고객의 시선이 한자리에 모일 때 비로소 대화는 현실의 언어가 된다.
결국 시나리오는 문서가 아니라 과정이다.
처음부터 같이 움직일 때만, 그 안에 ‘사람의 흐름’이 생긴다.
좋은 시나리오의 출발점은 감이 아니라 데이터다.
가급적 최근 12개월의 상담 데이터를 확보하는 게 이상적이다.
그 이유는 간단하다.
고객의 말은 계절과 시기에 따라 미묘하게 달라지기 때문이다.
여름엔 “에어컨 고장”, 겨울엔 “수도 동파”, 연말엔 “보험 갱신”처럼 상담에는 계절성이라는 리듬이 존재한다.
12개월 데이터는 계절성 패턴을 온전히 포착할 수 있다.
기업이 전년·전월 대비 실적을 기준으로 의사결정하는 이유와 같다.
물론 모든 녹취를 다 들을 순 없다.
보통 1,000건 내외 샘플링이 적정하며, 내용이 없는 인사말이나 잡담을 제외하면 실제 유효 데이터는 600~700건 수준이다.
이 정도면 상담 흐름을 그릴만큼 충분하다.
이 단계의 목적은 데이터를 통해 팀이 같은 언어로 현실을 이해하도록 만드는 일이다.
데이터를 모으는 과정 자체가 이미 팀의 사고를 정렬하는 협업의 출발점이 된다.
샘플링이 끝났다면, 이제 분석을 시작할 차례다.
음성 데이터는 일일이 들어야 하기에, 먼저 STT(Speech-to-Text) 기술을 이용해 녹취를 텍스트로 변환해야 한다.
귀로 듣기보다 눈으로 읽는 게 훨씬 빠르다.
이렇게 하면 일정도 단축되고, 팀원들의 피로도도 줄어든다.
녹취를 텍스트화할 땐 개인정보 마스킹도 꼭 잊지 말아야 한다.
하지만 텍스트만으로는 한계가 있다.
텍스트는 ‘무슨 말’을 했는지만 보여줄 뿐, ‘어떤 마음’으로 말했는지는 들려주지 않는다.
목소리의 떨림, 잠깐의 침묵, 말끝의 온도 같은 것들이다.
그래서 일정 비율은 반드시 귀로 들어야 한다.
현장 상담사와 함께 녹취를 들으면 시나리오는 훨씬 더 현실에 가까워진다.
“이건 불만이 쌓인 목소리예요.”
“이건 그냥 안심하려고 물어본 거예요.”
이런 판단이 시나리오의 리듬을 살리고, 대화에 온기를 불어넣는다.
시나리오는 텍스트가 아니라 대화이기 때문이다.
초안은 책상 위에서가 아니라 대화 속에서 완성된다.
시나리오는 ‘혼자 앉아 쓰는 글’이 아니라, 서로 다른 직군이 각자의 언어로 번역하며 만들어 가는 작업이다.
이때 유용한 방법이 바로 워크숍(Workshop)이다.
디자인씽킹(Design Thinking)이나 공감지도(Empathy Map) 같은 협업 도구를 활용해 서로의 관점을 교차시키는 시간이다.
“그건 고객 입장에서 불편할 것 같아요.”
“그럼 그 질문을 직설적으로 바꾸는 게 낫겠네요.”
이런 대화가 오가는 순간, 시나리오의 빈틈이 보이고, 현실적인 응답이 탄생한다.
Insight. 워크숍에서 자주 쓰인 도구 3가지
① 공감지도(Empathy Map) : 고객이 ‘보고·듣고·느끼는 것’을 시각화해, 감정의 언어로 문제를 다시 바라보게 한다.
② Glad / Sad / Mad : 실무자의 감정을 ‘좋았던 점, 아쉬웠던 점, 불편했던 점’으로 구조화해, 팀이 느끼는 현실을 감정의 언어로 공유하게 한다.
③ 브레인라이팅(Brainwriting) : 말이 적은 사람도 아이디어를 낼 수 있게 조용히 적고 돌려보는 방식이다. 감정을 넘어 생각을 언어로 펼쳐, 숨은 아이디어가 대화 속으로 흘러들게 한다.
이런 순간들이 쌓일수록, 시나리오는 점점 현실의 대화에 가까워진다.
시나리오는 결국 현장에서 벌어지는 일을 기계에게 가르치는 일이다.
그래서 책상 위 초안에는 항상 빠진 조각이 있다.
이때 필요한 건 보고가 아니라 대화다.
작은 회의실에서, 혹은 커피 한 잔 앞에서 조심스레 묻는다.
단, 두 가지 전제는 꼭 필요하다.
① 초안 작성에 참여하지 않은 상담사나 운영자가 피드백을 준다.
② 과거의 불만이 아니라 현재의 흐름을 기준으로 묻는다.
그러면 질문과 답이 달라지고, 시나리오의 핵심 맥을 채운다.
“이건 예전엔 문제였는데, 지금은 잘 돼요.”
“그건 문구보단 절차 요청이 더 많아요.”
현장 참여가 어려울 경우, VoC(Voice of Customer, 고객의 소리)나 관리자 피드백으로 대체해도 좋다.
단, 숫자가 아니라 사람의 말로 해석해야 한다는 점이 중요하다.
초안이 끝은 아니다. 진짜 검증은 ‘현실과 얼마나 닮았는가’다.
STT로 변환된 텍스트와 시나리오를 나란히 두고 다음 항목을 점검한다.
- 주요 흐름이 누락되지 않았는가
- 자주 등장하는 문의 유형이 반영됐는가
- 드물지만 반드시 필요한 예외 케이스가 포함됐는가
검증이 끝나면 마지막 단계는 베타 테스트다.
실제 고객이 사용하는 순간, 시나리오는 비로소 살아 있는 대화가 된다.
단, 이 테스트는 시나리오만으로 진행할 수 없다.
고객이 실제 보이스봇 서비스라고 느낄 만큼 시스템 연동, 화면 전환, 음성 응답 품질이 일정 수준 이상 구현되어야 한다.
이 단계는 보통 통합 테스트 구간에서 진행된다.
구체적인 방법은 ‘12. 진짜 고객이 사용하면, 어떤 일이 벌어질까?’에서 자세히 다룬다.
이 모든 과정의 본질은 하나다.
우리는 기술을 다루지만, 결국 사람의 대화를 설계하고 있다.
시나리오는 눈으로 읽는 글이 아니라, 귀로 듣고 마음으로 반응을 일으키는 언어다.
그 대화는 기업에겐 효율을, 상담사에겐 존엄을, 고객에겐 존중받는 경험을 남긴다.
좋은 시나리오란, 기술과 사람 사이의 균형을 회복한 흐름이다.
한 줄 요약
좋은 시나리오는 기술의 언어로 쓰지 않는다.
사람의 대화를 다시 배우는 일이다.