[작성자:] hoonyoung

서문

LLM 기반 챗봇을 처음 기획하면서 가장 어려웠던 점은, 핵심 개념들이 전혀 익숙하지 않다는 점이었습니다. 예를 들어, 처음 들었던 ‘RAG’, ‘폴백 시나리오’, ‘쿠션멘트’ 같은 용어들은 그 의미조차 가늠이 되지 않아 막막했던 기억이 납니다. RAG, LLM, 프롬프트 등의 용어부터 구조, 그리고 대응 방식까지 모두 새로운 세계였습니다.

무엇보다도 제가 가장 먼저 가졌던 생각은…

“AI니까 방향만 입력해주면 알아서 다 하는 거 아니야? 내가 기획자로 꼭 필요할까?”

하지만 프로젝트를 진행할수록 명확해졌습니다.
AI가 더 똑똑해질 수 있도록, 그 방향과 기준을 제시하는 역할은 여전히 ‘기획자’에게 있다는 사실입니다.
AI는 방대한 정보를 학습했지만, 그 중 어떤 것을 언제 어떻게 보여줄 지를 스스로 정하지 못합니다. 예를 들어 어떤 발화가 ‘혐오인지 아닌지’, ‘차별인지 아닌지’를 아직은 완벽하게 판단하지는 못하죠.

즉, AI는 많은 걸 아는 존재지만, 정확히 어느 선에서 말해야 하는지를 모릅니다. 그 기준을 설정하는 사람이 필요합니다.
물론… 기획자가 아주 잘 설계해놓고 계속 피드백까지 제공한다면 언젠간 정말 기획자가 필요 없어질지도 모르겠습니다.

이 글은 저와 같은 입장에서 출발하는 모든 분들을 위해, LLM 챗봇을 기획하면서 반드시 마주치게 되는 기본 개념들을 정리한 글입니다.
가볍게 한 번 살펴봐 주시면 감사하겠습니다.

1. LLM + RAG

LLM (Large Language Model)은 대규모 텍스트 데이터를 학습해 문장을 생성하는 AI 모델입니다. 대표적인 예시로 GPT-4, Gemini, Claude 등이 있죠.

하지만 LLM은 모든 정보를 알고 있는 전지적 존재가 아닙니다. 일정 시점까지의 데이터로 학습되었고, 그 이후 정보나 기업 내부 정보는 모릅니다. 이를 보완하기 위해 도입된 개념이 RAG (Retrieval-Augmented Generation) 입니다.

• RAG 1.0: 유저 질문을 벡터화 → 문서 검색 → 검색된 문서를 기반으로 LLM이 응답 생성
• RAG 2.0: 유저 질문 + 문서 검색 결과를 통합 → 프롬프트에 구조화하여 응답 생성 (더 높은 정밀도와 출처 추적 가능)

RAG를 한 줄로 쉽게 설명한다면, 정보를 최신화하는 프레임워크라고 볼 수 있습니다. RAG 1.0이 ‘좋은 책 한 권’을 찾아 답변하는 것이라면, RAG 2.0은 ‘여러 권의 좋은 책’을 찾아 ‘정확하고 논리적인 비교 분석’까지 해주는 것이라고 생각하면 이해하기 쉽습니다. 다만 아직 2.0은 보편적으로 적용된 상태는 아닙니다.

기획자는 이 구조를 이해해야, 왜 ‘출처 표기’가 필요한지, 어떤 식으로 데이터를 전처리해야 하는지를 설계할 수 있습니다. 일반적으로 말하는 AI 모델은 이 두 가지를 함께 패키지로 언급하는 걸로 이해하시면 쉽습니다.

2. 메인 시나리오 / 폴백 시나리오

LLM 챗봇도 여전히 시나리오 설계가 핵심이고 기획자가 필요한 이유입니다. 사용자의 질문이 정해진 흐름대로 이어질 수 있는 경우에는 메인 시나리오, 그렇지 않거나 실패 상황에서는 폴백 시나리오로 구분됩니다.

• 메인 시나리오: 유저가 의도한 목적(예: “배송 조회”)에 도달하기 위한 핵심 플로우. 대부분의 시나리오 설계의 기반.
• 폴백 시나리오: ‘의도 불일치, 시스템 오류, 잡담 대응, 부적절 발화’ 등 예상 외 상황. (발화 예: “제가 잘 이해하지 못했어요. 다시 한 번 말씀해주시겠어요?”)

메인 시나리오 / 폴백 시나리오 구조는 챗봇에서 유래했지만, 챗봇에만 국한되지 않고 다양한 인터랙티브 시스템(서비스) 전반에 통용되는 개념입니다.

두 시나리오는 각각 다른 UX, 응답 톤, Safety 정책이 필요하며, 기획자가 이 경계를 명확히 잡아주는 것이 중요합니다.

3. 쿠션멘트

쿠션멘트란, 사용자의 감정선을 고려하여 직접적인 응답 이전에 제공하는 완충 문장을 의미합니다. 예를 들어, 사용자가 반복적으로 같은 질문을 하거나 챗봇이 명확히 답을 주지 못하는 상황에서, “죄송합니다. 다시 한번 확인해보겠습니다.”와 같은 문장이 쿠션멘트가 될 수 있습니다.

• 예: “확인해볼게요! 잠시만 기다려주세요.”
• 예: “질문 감사합니다. 안내드릴게요.”

단순히 친절해 보이기 위한 표현이 아니라, LLM이 제공하는 불안정하거나 모호한 응답을 감싸는 장치로써 매우 중요한 역할을 합니다. 특히 반복된 fallback 시나리오에서는 사용자 피로감을 줄여주거나, 부정적 사용 경험을 완화하는 효과도 있습니다.

실제 운영에서도 쿠션멘트가 포함된 응답은, 포함되지 않은 응답보다 사용자 만족도와 피드백 지표가 더 높게 나타났습니다. 정성 분석 결과, 사용자들은 쿠션멘트가 포함될 경우 “배려받는 느낌이다”, “AI가 나를 신경 쓰는 것 같다”는 반응을 보이기도 했습니다.

실험 설계나 AB 테스트를 통해 쿠션멘트의 효과를 직접 검증해보는 것도 기획자에게 매우 유의미한 경험이 될 수 있습니다.

4. 파지티브 규제 / 네거티브 규제

챗봇이 어떤 질문에 답을 해도 되는지, 어떤 질문은 막아야 하는지를 정하는 방식은 두 가지로 나뉩니다.

• 파지티브 규제 (Positive Regulation): 정해진 질문과 응답만 허용 (화이트리스트 기반)
• 네거티브 규제 (Negative Regulation): 금지된 항목만 차단, 그 외는 허용 (블랙리스트 기반)

용어 때문에 자칫 헷갈릴 수 있는데, 실제 자유도는 반대입니다. 파지티브 규제는 ‘되는 거만 빼고 다 안되기’에 자유도가 낮고, 오히려 ‘네거티브 규제’는 ‘안되는 거만 빼고 다되기 때문’에 자유도가 높습니다.

LLM 기반 챗봇은 자유도가 높기 때문에 네거티브 규제를 적용해야 하며, 민감 이슈나 출처 문제로 인해 일부 영역에서는 파지티브 규제를 혼합 적용하기도 합니다. 특히 금융, 의료, 공공 분야에서는 이 균형이 매우 중요합니다.

5. Safety 정책

AI 챗봇은 사용자와 직접적으로 상호작용하기 때문에, 적절한 안전 정책(Safety Policy) 설정이 필수입니다.

• 예: 욕설, 차별, 혐오 발언 차단
• 예: 개인정보 질문 차단 (예: 주민번호, 계좌번호 등)
• 예: 자살/자해 등 심각한 이슈에 대한 대응 시나리오

이를 해결하는 장치로는 프롬프트 차단(input filtering)과 응답 차단(output filtering)이 있습니다. 리스크가 큰 경우에는 프롬프트 차단을 우선 적용하며, 기본적으로는 응답 차단을 적용합니다.

카테고리 중 리스크가 큰 ‘아동 성착취, 혐오 및 차별’ 관련해서는 면밀한 검토가 필요하며, 출시 전에 높은 수준의 내부 검수가 필요합니다.

✅ 함께 알아두면 좋은 개념들

▸ 프롬프트(Prompt) & 프롬프트 엔지니어링

프롬프트는 LLM에게 질문이나 지시를 내리는 문장입니다.
“AI에게 말을 거는 방식”이라 생각하면 이해가 쉽습니다.

예시:
→ “이 글을 두 문장으로 요약해줘.”
→ “너는 친절한 고객센터야. 질문에 간결하게 답변해줘.”

좋은 프롬프트를 설계하면 더 정확하고 명확한 응답을 받을 수 있습니다.
기획자는 단순히 질문을 적는 게 아니라, 어떤 맥락에서 어떤 톤으로 응답해야 할지를 고려해 프롬프트를 설계해야 합니다.

📃참고: 안트로픽(Claude) 프롬프트 엔지니어링 가이드

▸ 싱글턴 vs 멀티턴

현재 대부분의 상용 챗봇은 싱글턴 구조를 기반으로 구현되며, 멀티턴은 고도화 단계에서 도입됩니다.
반면, 생성형 AI 서비스는 멀티턴을 기본 전제로 설계됩니다.

▸ UI 출력 방식

LLM 챗봇은 단순 텍스트 외에도 이미지, 동영상, 버튼, 문서 링크 등을 포함할 수 있습니다. 이는 사용자의 몰입도와 정보 이해도를 높이기 위한 중요합니다. 실제 챗봇 UI에서 다양한 출력 형태가 어떻게 표현될 지는 정리하는 것은 주요한 기획 포인트입니다.

예시:
– 대표 이미지 썸네일
– 관련 문서 링크 버튼
– 답변 내용 하이라이트
– 출처 명시 (문서명, 링크 등)

▸ LLM의 한계 및 환각(Hallucination)

LLM은 정답을 “검색”하는 게 아니라, 가장 그럴듯한 답을 생성합니다.
그래서 다음과 같은 특징이 존재합니다.

– 동일한 질문에도 응답이 달라질 수 있음 → 비결정성
– 실제 존재하지 않는 정보를 만들어낼 수 있음 → 환각(hallucination)

이런 이유로, 다음 상황에서는 Rule 기반 시나리오와 병행이 필요합니다.

– 정답이 반드시 고정되어야 하는 영역 (예: 약관, 정책, 법률 등)
– 민감한 주제 또는 정확성이 중요한 고객상담 영역
– 내부 기준이나 구조화된 출력이 필요한 응답

이 글이 AI 챗봇 기획의 첫걸음을 떼는 분들께 작게나마 도움이 되기를 바랍니다. 끝까지 읽어주셔서 고맙습니다 🙂