왜 롤플레이 챗봇을 직접 만들었나 — 온보딩을 압축하는 개인 연습 도구

어느 실무 미팅에서, 이제 막 팀에 합류한 사람이 한 시간 내내 거의 입을 열지 못하는 장면을 본 적이 있습니다. 대화가 안 통해서가 아니었습니다. 상대방과 우리 쪽 담당자가 주고받는 도메인 용어 — 상담 흐름을 가리키는 약어, 특정 방식의 구축 형태를 부르는 이름, 업계에서만 통하는 줄임말 — 를 그 사람만 못 알아들었기 때문입니다. 뜻을 물어보자니 미팅 흐름을 끊고, 아는 척하자니 다음 질문에서 막히는 상황이었습니다. 필자 자신도 이 도메인에 처음 발을 들였을 때 똑같은 자리에 앉아 있었기 때문에, 그 침묵이 무엇인지 정확히 알 수 있었습니다. 이 글은 그 침묵을 줄여 보려고 AI 고객과 사업 미팅을 롤플레이하는 챗봇을 직접 만든 이야기입니다. 미리 밝혀 두면 이 챗봇은 개인 학습용으로 직접 만든 것이고, 글에 등장하는 시나리오는 실제 고객 미팅을 특정할 수 없게 익명화·재구성한 것이며, 2026년 7월 시점 기준으로 특정 회사·고객사의 정보나 계약 수치는 담지 않았습니다.

[시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 10-1편

← 이전: 9-7 온프레미스 상담어시스트 — GPU 제약과 모델 선택 / 다음 → 10-2 전체 아키텍처 한 장

전체 목차 펼치기 (63편)

Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편)

Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편)

Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편)

Part 4 — 인프라·세션·보안: 프로덕션 백엔드 (5편)

Part 5 — 운영·품질·평가: 에이전틱 워크플로우와 신뢰성 (7편)

Part 6 — 음성 경험 고도화·실전 통합: 한국어·UX·전화망·엣지 (5편)

Part 7 — S2S 도입 전략·구매 의사결정 (4편)

Part 8 — LLM 콜봇 PoC 현장 (6편)

Part 9 — 상담어시스트: 상담사 화면을 바꾸는 실시간 AI (7편)

Part 10 — 직접 만든 롤플레이 챗봇: RAG 에이전트 구축기 (8편)

Part 11 — KMS 실무 — 지식관리시스템의 설계와 운영 현실 (8편)

온보딩이 압축되지 않는다는 문제

특정 B2B 도메인, 그중에서도 컨택센터·AICC 영역의 온보딩은 유독 더디게 진행됩니다. 신입이 첫 고객 미팅에 배석해 진땀을 흘리는 장면을 떠올려보면 답이 나옵니다. 제품 지식은 문서를 읽으면 어느 정도 따라잡히지만, "고객이 이런 질문을 던졌을 때 어떻게 받아치는가"라는 대화의 감각은 그 자리에서 몸으로 부딪혀야 붙습니다. 이건 문서로 익혀지지 않습니다. 실제 미팅에 여러 번 들어가 보면서, 상대가 무엇을 걱정하는지, 어떤 순서로 설득해야 하는지, 어떤 용어를 자연스럽게 써야 신뢰를 얻는지를 몸으로 익히는 수밖에 없습니다.

문제는 그 "실제 미팅 경험"이 희소하다는 점입니다. 신입이나 경력직이 팀에 합류해도 바로 중요한 고객 미팅에 투입할 수는 없습니다. 미팅은 자주 열리지 않고, 실패의 비용이 큽니다. 그래서 대부분의 온보딩은 선배 옆에 앉아 여러 번 지켜보며 감을 잡는 방식으로 이뤄지는데, 이건 물리적으로 압축이 되지 않습니다. 선배 옆자리에 앉아 몇 달째 상황을 지켜만 보는 신입의 모습을 떠올려보면, 이 방식으로는 도저히 시간이 압축되지 않겠다는 생각이 듭니다. "매일 롤플레이로 단련하면 어떨까"라는 아이디어는 그 장면에서 나왔습니다. 실제 고객이 아니라 AI 고객을 상대로, 언제든 반복해서, 실패 비용 없이 대화 연습을 할 수 있다면 온보딩의 가장 느린 구간을 압축할 수 있을 거라고 봤습니다.

왜 시중 챗봇으로는 안 됐나

처음에는 굳이 직접 만들 필요가 있나 싶었습니다. 이미 잘 만들어진 범용 챗봇들이 있으니, "너는 까다로운 고객이야, 나랑 사업 미팅 롤플레이를 해 줘"라고 시켜 보면 되지 않을까 하는 생각이었습니다. 실제로 몇 번 시켜 봤습니다. 그리고 곧, 이 방식으로는 온보딩 도구가 될 수 없다는 걸 알게 됐습니다.

가장 큰 벽은 도메인 정확도였습니다. 범용 챗봇은 우리 도메인의 상담 구조, 구축 방식의 종류, 업계에서만 통하는 용어의 실제 쓰임을 정확히 알지 못합니다. 화면 속 AI 고객이 뻔한 질문을 던지고, 사용자가 아무렇게나 답해도 고개를 끄덕이는 장면을 떠올려보면 문제가 선명해집니다. 질문 자체가 실제 미팅에서 나올 법한 질문이 아니라 어디서 본 듯한 일반론에 머물렀고, 사용자가 답을 해도 그 답이 도메인 기준으로 맞는지 틀린지 판단하지 못했습니다. 연습의 핵심은 실전에서 실제로 통하는 대화를 반복하는 것인데, 그 실전성이 통째로 빠져 있었던 겁니다.

그래서 방향을 정했습니다. 도메인 자료와 구축 사례, 실무에서 하나씩 쌓인 노하우를 문서로 정리해 RAG(검색 증강 생성)로 챗봇에 물리는 장면을 그려 보면, 이렇게 해야 범용 챗봇에 물어보는 것과는 차원이 다른 정확도가 나오겠다는 확신이 섭니다. RAG 기반이 아니면 애초에 차별화가 되지 않는다 — 이게 직접 만들기로 한 결정의 뿌리였습니다. AI 고객의 질문도, 사용자 답변에 대한 판정도, 전부 우리 도메인 자료에 근거해야 비로소 연습이 성립했습니다.

세 가지 설계 원칙

직접 만들기로 한 뒤, 무엇을 절대 원칙으로 삼을지를 먼저 정했습니다. 기능을 붙이기 전에 이 세 가지가 흔들리면 도구 자체가 쓸모없어진다고 봤기 때문입니다.

첫째, 평가 도구가 아니라 개인 연습 도구로 만든다는 것이었습니다. 이 챗봇은 점수를 매기고 피드백을 주지만, 그 점수와 연습 이력은 오직 본인만 열람할 수 있어야 합니다. 관리자나 인사 평가에는 절대 넘어가지 않는다는 선을 처음부터 그었습니다. 이유는 단순합니다. 점수가 공개되는 순간 아무도 시뮬레이션을 하지 않기 때문입니다. 틀리는 게 두려운 도구는 연습 도구가 아닙니다. 마음 편히 틀릴 수 있어야 반복하고, 반복해야 늘기 때문에, 수용성이 곧 이 도구의 생존 조건이라고 판단했습니다.

둘째, RAG 차별화입니다. 앞서 말한 이유 그대로, 도메인 자료에 근거하지 않으면 이 도구는 시중 챗봇과 구별되지 않습니다. 그래서 정확도의 원천을 모델 자체가 아니라 우리가 넣은 자료에 두기로 했습니다.

셋째, 데이터 프라이버시입니다. RAG에 물리는 지식 소스는 민감한 원문이 아니라 비식별 요약본을 기반으로 구성했습니다. 롤플레이 시나리오도 실제 고객 미팅을 그대로 쓰는 게 아니라 익명화·재구성한 세트로만 만들었습니다. 연습에 필요한 것은 대화의 구조와 맥락이지 특정 고객의 실제 정보가 아니기 때문에, 처음부터 민감 정보가 도구에 들어오지 않도록 설계했습니다.

그래서 무엇을 만들었나

이 세 원칙 위에서 만든 것은 네 개의 기능을 가진 자기학습 챗봇입니다. 핵심은 AI 고객과 실제 사업 미팅을 익명화·재구성한 시나리오로 롤플레이하는 기능이고, 여기에 도메인 지식을 문답으로 점검하는 퀴즈, 현장 용어를 빠르게 찾아보는 용어사전, 구축 형태의 큰 그림을 잡아 주는 아키텍처 가이드가 붙습니다. 롤플레이가 끝나면 대화 전체를 놓고 피드백·스코어링·코칭이 이어지는데, 이 채점이 "정답 하나"를 맞혔는지가 아니라 필요한 핵심을 짚었는지를 본다는 점이 이 도구의 성격을 가장 잘 보여 줍니다. 각 기능이 어떻게 동작하고 왜 그렇게 설계했는지는 이어지는 편들에서 하나씩 풀겠습니다.

다음 편에서는 이 챗봇의 전체 아키텍처를 한 장으로 펼쳐 보겠습니다. FastAPI 백엔드, 로컬 임베딩 기반 RAG, 그리고 여러 LLM 백엔드를 런타임에 갈아 끼우는 구조를 어떤 레이어로 나눴고 왜 그렇게 엮었는지 — 지금까지 이야기한 세 원칙이 실제 구조에서 어떻게 자리 잡는지를 그림처럼 보여 드리겠습니다.

AI 보이스봇이 답답한 이유: Cascaded 구조 레이턴시 완전 분석

6월 13, 2026

자세한 내용 보기

이 블로그 검색

AI에이전트엔지니어링