"AI 챗봇을 도입하겠습니다"라는 같은 문장 아래 전혀 다른 물건이 견적서에 오르는 경우가 많습니다. 어떤 견적은 버튼 메뉴와 시나리오 트리를 그리는 비용이고, 어떤 견적은 LLM이 사내 문서를 읽고 답하게 만드는 비용입니다. 버튼형을 들여 놓고 "왜 이 질문은 못 알아듣느냐"는 불만이 나오거나, 생성형을 들여 놓고 "답이 매번 조금씩 다른데 믿어도 되느냐"는 걱정이 나옵니다.
문제는 기술의 우열이 아니라 업무와 방식의 짝이 맞지 않는 데 있습니다. 이 글은 텍스트 챗봇 안의 세 세대를 비교하고 언제 바꿔야 하는지를 다룹니다.
결론부터 말씀드리겠습니다. 절차가 정해진 거래는 시나리오형이 여전히 맞고, 문의가 다양하고 근거 문서가 많은 영역은 생성형에 문서 근거를 붙인 방식이 유리합니다. 대부분의 기업에는 둘을 섞은 혼합형이 현실적인 답입니다.
아래 점검표의 빈칸을 자사 상담 로그로 채우시면, 전환 여부를 판단하는 결재 자료로 그대로 쓰실 수 있습니다.
챗봇의 세 세대: 버튼·시나리오형 vs 의도 분류형 vs 생성형
IBM은 챗봇을 정해진 규칙·결정 트리를 따르는 규칙 기반 챗봇과, AI 모델로 자연어를 해석해 응답을 생성하는 AI 챗봇으로 나눕니다. 학계도 응답 방식에 따라 규칙 기반·검색 기반·생성 모델로 구분하며, 규칙 기반은 철자·문법 오류에 약하다고 봅니다(Adamopoulou·Moussiades, 2020). 현장 언어로는 세 세대입니다.
| 유형 | 작동 방식 | 강점 | 약점 | 구축·유지 부담 |
|---|---|---|---|---|
| 버튼·시나리오형(룰 기반) | 버튼·트리·키워드 규칙으로 정해진 답 선택 | 답이 늘 같아 검수가 쉬움 | 트리 밖 질문·변형 표현에 막힘 | 가지마다 설계·개발 |
| 의도 분류(NLU)형 | 문장을 정의된 의도로 분류해 정해진 답에 연결 | 버튼 없이 문장 입력 | 정의 밖 의도는 '이해 못함' | 예문 수집·재학습·충돌 관리 |
| 생성형(LLM + 문서 근거) | 관련 문서를 찾아 근거로 답을 생성 | 롱테일·복합 질문 대응 | 근거 밖에서 그럴듯한 오답(환각) | 문서 품질·가드레일·테스트 운영 |
같은 생성형이라도 LLM이 학습한 지식만으로 답하는 구성과 회사 문서를 근거로 답하는 구성은 위험이 다르며, 기업 상담의 비교 대상은 후자입니다.
시나리오형이 여전히 맞는 업무: 절차가 고정된 거래
비밀번호 초기화, 예약 변경, 주문 취소처럼 순서가 정해진 거래는 시나리오형이 강합니다. 빠뜨리면 안 되는 본인 확인·확정 단계가 있고, 같은 입력에 같은 결과가 나와야 감사와 민원 대응이 가능하기 때문입니다. IBM도 규칙 기반이 예측 가능한 요청에 잘 맞는다고 봅니다.
한계는 거래 앞뒤에서 드러납니다. "예약을 바꾸면 위약금이 붙나요?" 같은 설명형 질문은 트리를 늘려도 끝이 없습니다. 깊은 메뉴 끝에 상담원 연결로 몰리는 전화 ARS와 같은 구조입니다(관련 글: 「ARS는 왜 AI 보이스봇으로 바뀌고 있을까? IVR과 AI 콜봇 차이 총정리 (2026)」).
| 업무 예시 | 권장 방식 | 이유 |
|---|---|---|
| 비밀번호 초기화 | 시나리오 + 시스템 연동 | 본인 확인 단계 누락 방지 |
| 예약 변경·주문 취소 | 확정은 시나리오, 접수 문장은 생성형 | 입구는 유연하게, 확정은 고정 |
| 상품·요금제 문의 | 생성형 + 문서 근거 | 조합이 많아 트리로 감당 어려움 |
| 약관·규정 해석 | 생성형 + 문서 근거, 범위 제한 | 근거 문장 안에서만 답변 |
| 환불 예외·보상 판단 | 상담원 이관 | 재량 판단은 사람이 책임 |
생성형이 이기는 지점: 문의의 롱테일과 문서의 양
고객 문의는 상위 몇 개 유형에 몰리고 나머지는 길고 얇은 꼬리를 이루는 경우가 많습니다. 시나리오형과 의도 분류형은 꼬리 쪽 질문마다 가지나 의도를 새로 만들어야 하고, 의도가 늘수록 충돌해 폴백이 쌓이기 쉽습니다.
생성형은 세 가지에서 앞섭니다. 첫째, 질문마다 답을 미리 만들지 않고 근거 문서를 관리합니다. 둘째, 지식 갱신이 빠릅니다. RAG(검색 증강 생성)를 제안한 Lewis 등(2020)의 논문은 검색 인덱스를 교체하는 것만으로 재학습 없이 지식을 갱신할 수 있음을 보였습니다. 약관이 바뀌면 시나리오 대신 문서를 바꾸면 됩니다. 셋째, 질문 두세 개가 섞인 복합 문의에도 한 번에 답합니다.
국내 은행권의 공개 사례도 문서가 많은 영역부터 생성형을 붙였습니다. KB국민은행은 2025년 7월 기존 머신러닝 기반 직원용 챗봇에 생성형 AI를 결합해 규정·지침·상품 정보를 안내하기 시작했고, 하나은행은 같은 해 6월 직원용 지식챗봇에 생성형 AI를 적용하면서 필요서류 안내·금융계산기 같은 기존 기능을 유지했습니다. 두 사례 모두 교체보다 결합에 가깝습니다.
생성형의 위험과 통제: 환각·문서 근거·가드레일
가장 큰 위험은 환각입니다. RAG 논문은 지식을 모델 내부에만 저장하면 고치기 어렵고 환각이 생길 수 있다고 지적하고, 문서에 근거한 RAG 모델에서 환각이 더 적었다고 보고합니다. 다만 줄어들 뿐 사라지지는 않습니다.
책임은 회사에 남습니다. 2024년 2월 캐나다 브리티시컬럼비아주 민사분쟁해결심판소는 웹사이트 챗봇이 유족 할인 운임의 사후 소급 신청이 가능하다고 잘못 안내한 사건에서, 정보가 정적 페이지에서 왔든 챗봇에서 왔든 차이가 없다며 에어캐나다에 배상을 명령했습니다(Moffatt v. Air Canada, 2024 BCCRT 149).
그래서 통제는 세 겹입니다. 첫째, 답변 범위를 등록 문서 안으로 제한하고 문서에 없으면 모른다고 답하게 합니다. 둘째, 금액 확정·법률 판단처럼 하지 말아야 할 응답을 가드레일로 정합니다. 셋째, 문서 밖 질문과 불만 신호는 사람에게 넘기고 대표 발화로 배포 전에 점검합니다. LLM의 문서 참조 원리는 별도 글에서 다뤘습니다(관련 글: 「음성 AI의 두뇌, LLM은 상담에서 어떻게 의도를 이해할까? (RAG·스킬북·환각 방지) 2026」).
전환 판단 체크리스트: 남길 시나리오와 옮길 문의
절차는 시나리오로, 지식은 문서로, 판단은 사람에게
이 원칙대로 나누면 대부분의 기업은 거래 절차를 남기고 설명형 문의부터 옮기는 혼합형에 도달합니다. 빈칸은 최근 상담 로그로 채워 보시기 바랍니다.
| 판단 질문 | 시나리오 유지 신호 | 생성형 전환 신호 | 자사 현황 |
|---|---|---|---|
| 상위 20개 유형의 문의 비중 | 대부분 | 꼬리 문의가 많음 | ( )% |
| 폴백 응답 비율 | 낮고 안정적 | 높거나 증가 | ( )% |
| 근거 문서의 양·개정 빈도 | 적고 안정적 | 많고 잦음 | ( )건, 월 ( )회 |
| 시나리오 수정 요청 적체 | 거의 없음 | 상시 적체 | ( )건 |
| 상담원 이관 주된 사유 | 절차 중 실패 | 메뉴 밖 질문 | ( ) |
| 오답 한 건의 비용 | 오차 불허 확정 안내 | 이관으로 보정 가능 | ( ) |
전환 신호가 많을수록 파일럿을 서두를 이유가 큽니다. 첫째, 폴백·이관된 대화에서 후보 영역을 고르고, 둘째, 그 영역의 근거 문서를 정리하며, 셋째, 기존 시나리오의 실패 대화를 테스트 케이스로 바꿉니다. 기존 시나리오는 버릴 자산이 아니라 절차 정의와 검증 기준이 됩니다.
휴멜로 프로소디 콘솔의 혼합형 설계: 문서 근거·가드레일·테스트 케이스
휴멜로 프로소디 콘솔은 생성형 답변을 스킬북 문서에 묶어 혼합형을 구성합니다. FAQ·매뉴얼·카탈로그를 PDF·DOCX 등 파일로 올리면 그 문서를 근거로 답하고, 약관이 바뀌면 문서를 교체해 다시 발행합니다. 가드레일에는 지켜야 할 응답 기준을, 상담원 이관 정책에는 이관 조건과 이관 전 수집할 정보, 1~5단계 이관 적극성을 정합니다.
휴멜로 프로소디 콘솔은 상담원 이관 요청과 정보 수집을 내장 동작으로 제공해 사람에게 넘기는 절차를 고정하며, 사내 시스템 거래 연동은 기업 도입 시 별도로 협의합니다. 테스트 케이스로 고객 발화와 기대 동작을 배포 전에 점검하고, 같은 에이전트를 웹 위젯·키오스크·콜센터 등 여러 채널에 배포합니다.
결론적으로, 버튼형과 생성형은 대체 관계가 아니라 업무를 나눠 맡는 관계이며, 전환의 기준은 기술의 새로움이 아니라 문의의 다양성과 문서의 양입니다. 위 체크리스트로 옮길 영역을 정해 보시고, 가입 시 제공되는 무료 크레딧으로 자사 FAQ 문서를 올려 직접 시험해 보시기 바랍니다.
