1. 서문
챗봇 기획에서 폴백(Fallback) 과 쿠션멘트(Cushion Message) 는 단순한 보조 장치가 아닙니다.
서비스가 복잡해질수록 이 두 장치는 사용자 경험을 지키는 안전망이 됩니다.
저는 CS 챗봇 시절부터 AI 챗봇까지 이어지는 과정에서 이 두 요소를 어떻게 설계·운영했는지를 경험했고, 그 과정에서 얻은 시행착오와 교훈을 공유하고자 합니다.
2. 타임라인: Rule 기반 → AI 기반
CS 챗봇 (Rule-Based)
- 매칭 실패 → 폴백 동작 or 무조건 상담사 연결
- 폴백과 쿠션멘트의 구분이 명확했음
AI 챗봇 (LLM + RAG 도입)
- 단순 실패가 아니라, 다양한 케이스가 발생
- 검색은 됐는데 결과 신뢰도가 낮음
- 답변 후보가 너무 많음
- 외부 도메인 질문이 들어옴 등
- 결국 “각 케이스별로 사용자에게 어떻게 안내할 것인가?”라는 복잡도가 급격히 늘어남
👉 여기서 중요한 개념이 I.D.K vs. O.O.D
- IDK (I Don’t Know): 챗봇이 “내가 모른다”를 스스로 인지하는 상황 (답변 범위 안인데 답을 못 찾음)
- OOD (Out of Domain): 아예 서비스 영역 밖의 질문이 들어온 상황 (예: 게임 가이드 챗봇인데 ‘날씨 어때?’ 물어봄)
- 이 둘을 구분하지 않으면, 같은 폴백으로 처리되어 사용자 경험이 무너집니다.
3. 매칭 구분표 작성
AI 챗봇에서 가장 어려웠던 부분은, 이 다양한 케이스를 기술·운영·기획이 이해할 수 있는 “매칭 구분표”를 정의하는 일이었습니다.
- 실제 구분표(단순화 예시)
| 구분 | 케이스 | 처리 기준 | 사용자 노출 |
|---|---|---|---|
| IDK | FAQ 범위 내, 매칭 실패 | 유사 질문 추천 | 쿠션멘트 + 추천 리스트 |
| OOD | FAQ 범위 밖 질문 | 폴백 → 종료/이관 | 쿠션멘트 + 상담 안내 |
| RAG Low Score | 검색결과 신뢰도 낮음 | 답변 차단 | 쿠션멘트 + 공식 링크 |
- 효과
- 혼선 제거 → 기획/개발/운영이 같은 기준을 공유
- 개발 속도 향상 → 케이스별 기준이 명확해 구현 지연 최소화
4. 최종 구조도 & 사용자 안내 예시
챗봇 질문이 들어오면, 아래 흐름처럼 6가지 케이스로 분류 후 처리됩니다.
(단순화 된 예시입니다.)
| 구분 | 케이스 | 처리 기준 | 사용자 안내(쿠션/블럭 예시) |
|---|---|---|---|
| SAFETY 차단 | 비윤리 발화/금칙어/현금거래 등 | 즉시 차단(선차단) + 로그 | “안전한 서비스 제공을 위해 해당 내용은 안내드릴 수 없습니다.” 필요 시: “정확한 내용은 {official_link}에서 확인해 주세요.” |
| 입력 부적합‧미지원 언어 | 미지원 언어, 특수기호/형식 오류 | 언어 탐지/형식 검증 → 안내 후 재시도 | 미지원 언어: “죄송합니다. 해당 언어는 현재 지원하지 않습니다.” 형식 오류: “지원하지 않는 문자입니다. 다시 입력해 주세요.” |
| OOD (Out of Domain) | 도메인 밖 질문·일상대화·의미 없는 발화 | LLM 기반 폴백(종료 또는 재질문 유도) | “안녕하세요! 저는 {ip_name} {bot_scope} 정보를 안내하는 AI입니다. {bot_scope} 관련 질문을 해 주세요.” |
| 도메인 내이지만 챗봇 처리 불가 | 계정/결제/신고 등 사람 개입 필요 | 초동수사/상담 이관 | “이 요청은 챗봇이 처리하기 어려워 상담사에게 연결해 드릴게요.” (상담사 바로 연결 or 버튼 제공) |
| IDK (검색 실패/저신뢰) | 자료 없음·오래됨·커뮤니티 글 등 | 응답 차단 + 쿠션멘트 + 추천/링크 안내 | “질문 범위는 맞지만 적합한 답변을 찾지 못했습니다. 대신 도움이 될 수 있는 항목을 안내드릴게요: {추천_리스트}” “정확한 정보는 {official_link}에서 확인해 주세요.” |
| 정상 응답 | 검색·생성 정상 | 정상 RAG 응답 생성 | 일반 답변 제공 (RAG 환각을 감안하여, 부정확할 수 있음을 쿠션멘트로 안내) |
| 출력 체크(2차 SAFETY) | 생성 응답에 금칙어/민감 정보 포함 | 후처리 차단/마스킹 | “안전한 서비스 제공을 위해 일부 내용은 비공개 처리되었습니다.” |
5. 협업 포인트 (R&R)
- 프로젝트 리딩 = PM
- 서비스 리딩 = 기획
- 사용자 접점 최종 결정 = 운영실
→ 즉, 기획자가 초안을 설계하되 최종 컨펌은 운영실이 맡았습니다.
- 구조/플로우: 기획자가 주도
- 사용자 톤·멘트: 운영실이 최종 결정
→ 실제로도 약 80% 이상은 운영실이 최종 톤을 확정했고, 기획자는 시스템적 일관성을 맞추는 역할에 집중했습니다.
6. Tip & 시행착오
제가 직접 겪으면서 깨달은 몇 가지 포인트입니다.
기획자의 핵심 역할
복잡한 내용을 단순화하여, 가시성을 제공하고 팀이 속도를 낼 수 있도록 돕는 것.
기획은 결국 ‘지도’와 같은 역할이라는 점을 다시 한 번 확인했습니다.RAG 파이프라인 도입 시 복잡도 폭발
설계 초기부터 기술팀과 협의하며, 폴백 & 쿠션멘트 정의를 동시에 진행했어야 했습니다.
초반엔 따로 움직이다 보니 기준이 꼬였고, 나중에 통합 정리하는 데 시간을 더 썼습니다.
폴백과 쿠션멘트는 사용자 경험의 시작이자 마지막 방어선입니다.
특히 Rule 기반 → AI 기반으로 넘어가면서 복잡도가 커질수록, 기획자가 기준을 정리하고 협업 구조를 잡아주는 역할이 필수적이었죠.
결국 기획자가 길을 정리해주고, 개발팀이 빠르게 구현하고, 운영실이 최종 목소리를 결정하는 구조가 가장 효율적이었습니다.
P.S. 🙂
요즘 AI가 하루가 다르게 빠르게 발전하고 있습니다.
모든 내용은 단순한 경험과 프레임워크의 참고서일 뿐이며, 실제 진행 방식은 언제든지 바뀔 수도 있고 더 효율적인 방식으로 진화되어야 합니다.