🚗 현대차 LLM 챗봇 데모 (Hybrid: Rule + RAG)

추석 연휴 ,
개인 프로젝트로 진행한 하이브리드 챗봇 데모를 공개합니다.

Rule의 안정성과 LLM의 확장성을 결합하여,
연휴 기간 동안 바이브코딩 방식으로 직접 구축하고 다듬어 보았습니다.
(※ 현대자동차 공식 챗봇과 무관합니다.)


🎬 Hook: 1 데모 + 최종 평가

👉 Demo: hyundai-chatbot-demo.vercel.app

※ 참고: Vercel 빌드 환경에서는 일부 RAG 질의(띄어쓰기·유사명칭·오탈자 등)의 인식률이 Stackblitz 실험 환경보다 낮게 나타날 수 있습니다.
본 영상은 Stackblitz 기준으로 촬영되었으며, 동일 코드 기반으로 Vercel에서도 대부분 정상적으로 작동합니다.


1️⃣ 만들었나 (Why)

이번 데모는 바이브코딩을 통한 챗봇 구현 프로젝트의 일환으로, 차량 구매 목적의 실제 사용자 시나리오에서 출발했습니다.

기존 챗봇의 경우 기본 정보 제공은 충분했지만, 구매·시승·상담 다음 행동으로 자연스럽게 이어지는 흐름은 더 보완될 여지가 있었습니다.

목표는 기존 시스템을 비판하는 것이 아닌, 정보 전달행동 전환간격을 줄이는 플로우 설계였습니다.

  • 구매 목적 사용자 시나리오의 개선 포인트
    • 견적/시승 문의까지 이동 단계가 비교적 길어지는 구간
    • 외부 페이지 이동 시 대화 맥락이 단절되는 지점
    • 동일 메뉴/버튼 반복 노출로 인한 탐색 피로

이에 따라 데모는 “FAQ 요약 + 공식 링크(CTA) + 최소 단계 전환을 원칙으로, 사용자가 질문하면 필요 행동까지 즉시 연결되고 순환되는 경험을 지향했습니다.


2️⃣ 어떻게 만들었나 (How)

Part 1. 분석 & 전략

  • 가설
    1. 목표 행동(구매·시승·AS)까지 경로 단축링크/CTA 무결성이 사용자 만족도와 목표(KPI) 전환에 결정적이라고 가정
    2. 또한 LLM 측면에서 유사 발화 대응력(띄어쓰기·별칭·오탈자)이 실사용성에 큰 영향을 준다고 가정
  • 분석
    1. 실제 공식 사이트 캡처·메뉴 트리 분석
    2. Top FAQ 및 유사 발화 수집&정규화
    3. 링크 유효성 및 도메인 점검
  • 전략
    1. 플로우 단순화(Simplify Flow) → 메뉴 통합, CTA 중심 설계, 1~2단계 내 해결
    2. 지속적인 연결(Connect Experience) → 핵심 정보는 대화 내 제공, 필요 시에만 외부 링크
    3. 데이터 최신화(Keep Data Fresh) 공식 FAQ 247 + 추가 Top 50 정비하여 반영 ( 지식 강화로 RAG 품질 안정화/고도화에 기여)

Part 2. 설계 & 개발

  • 아키텍처(Front-only Hybrid)
    • Rule Layer: 가격·보증·리콜·EV 추천 등 고정 의도 우선 처리
    • RAG Layer: faq.json + BM25 검색 → LLM 요약
    • UX Layer: 칩(Chips), 바텀시트, Sticky CTA(공식 링크/전화)

  • R1 → R2 → R3 개선 사이클
    • R1 (Prototype): Rule 70~80% + RAG 기본(가능성/흐름 우선)
    • R2 (Tuning): Rule 100% + 현대차 공식 FAQ 크롤링 반영 + BM25 교체, 유사 발화 정규화, 자동 테스트 루틴 구축
    • R3 (QA/Deploy): 자동/수동 라벨 교차검증, CTA·Fallback 보강 → 최종 평가 기준 항목 Pass

Part 3. 자동 테스트 & QA

  • 테스트 루틴
    • 콘솔 기반 runBatch() 자동 테스트 → 수동 라벨링으로 최종 판정
  • 라벨 분포 보정(R1 예시)
    • 자동: Good 40 / Fair 120 / Bad 136
    • 수동(최종): Good 183 / Fair 2 / Bad 111
    • “자동–수동 일치율: 45.6%”임계값·가중치 보정 상향
  • 보정 정책(R3 반영)
    • Retrieval TopScore 임계값 조정(예: ≥20=Good 후보)
    • Retrieval 성공 시 CTA 필수 부착, Fallback에도 고객센터 CTA 제공
    • 부분매칭 Good는 Gold 데이터 보강하여 업데이트
      → 위 보정 이후, 본문 상단 최종 평가 의 기준으로 품질을 점검·정리했습니다.

Part 4. RAG + Rule 하이브리드

  • 현업에서는 Rule-first를 반영했으나, 본 프로젝트에서는 RAG-first를 도입하여 실험
  • Retrieval 신뢰도(TopScore/Threshold)에 따라 FAQ → OpenDomain → Fallback으로 분기 처리
  • 역할 분리: “Rule = 안정성, “RAG = 커버리지·설명력
    ※ Vercel 배포 환경에서는 런타임(Edge vs Node) 및 경로 처리 차이로 인해 일부 질의(띄어쓰기, 유사명칭 등)의 검색 인식률이 Stackblitz 실험 환경 대비 다소 낮게 나타났습니다. 코드 구조와 데이터는 동일하며, 이는 환경 특성에서 비롯된 결과로 판단됩니다.

Part 5. 배포 트러블슈팅

  • Vercel 환경: OpenAI 직접 호출 지양 → /api/chat.ts 에지 프록시
  • 인덱싱 race 방지: ensureRagReady() 싱글톤 초기화 + 임베디드 코퍼스
  • dev/prod 코퍼스 동기화: assets 임베드 + 런타임 /faq.json 덮어쓰기
  • 재할당 경고 해결: const → let
  • 공식 FAQ URL 변경: 리다이렉트 미지원 건은 외부 이슈로 Skip

3️⃣ 결과 & 배운 (What / Lessons)

🎯 핵심 성과

  • 최상단 최종 평가 표 기준으로 정확도·라우팅/폴백·링크/CTA·성능·스타일/안전·UI/UX 항목 Pass 달성했습니다.
  • Rule + RAG 결합 구조를 구축하고, 자동 QA 루틴(runBatch)을 적용했습니다.
  • R1→R2→R3 개선 사이클을 통해 품질을 확보하고 프로덕션 레디 수준으로 정비하였습니다.

🧩 진행 어려움

  • 마지막 5% 완성 구간에서 시간 소요가 집중되었습니다. (체감상 전체 소요 시간의 20% 이상)
  • 공식 사이트 URL 변경(리다이렉트 미지원)로 일부 항목은 Skip 처리했습니다.
  • 바이브 코딩 시, 프롬프트 반복 입력 시 맥락을 벗어나 필요 이상으로 수정 발생하는 케이스가 많았습니다.
  • 배포 환경(Vercel)에서 RAG 검색 성능이 Stackblitz 대비 약하게 나타났습니다. 이는 런타임 및 빌드 환경 차이로 인한 현상으로, 실 서비스 영향 범위는 RAG 한정으로 나타났습니다.

💡 교훈

  1. 작업 단위는 최대한 작게 쪼개고, 문맥은 명확하게 가져가야 합니다. (챗방 최대한 쪼개기 + 상세한 프롬프트 필요)
  2. 제안 코드는 그대로 적용하기보다 구조를 확인하고 최소 수정으로 해결해야 합니다.
  3. 바이브 코딩은 개발 도구에 가깝습니다(기본 문법·구조 이해가 효율을 좌우).
  4. Agent 자동 검수 + 수동 QA 조합으로 효율적으로 시간을 아끼고 품질을 높여줍니다.
  5. 초기 목표는 50% 범위로 설정해야 합니다. 최초 예상보다 2~3배의 시간과 노력이 소요되기 쉬워, 단계별 확장이 현명합니다.
  6. RAG 보정은 생각보다 어렵습니다. (예: 유사 발화·띄어쓰기·별칭 대응 등)

 

P.S. 추석 연휴 내내 작업하여 마지막 보정 작업과 글 작업을 진행하니 어느덧 1주일이 금방이네요. 처음 해보는 바이브코딩은 생각보다 어렵고 힘들었지만, 생각보다 재미있고 많은 걸 배울 수 있었습니다. 더 재미나고 쉬운 바이브코딩 2탄으로 찾아오겠습니다 😊🤩

 

AI 챗봇 기획, 처음이라면 꼭 알아야 할 개념 5가지

서문

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 멀티턴

구분설명예시
싱글턴(Single-turn)한 번의 질문과 응답으로 끝나는 단문 대화 구조대부분의 고객센터, 쇼핑몰, 은행, 공공기관 챗봇 등
멀티턴(Multi-turn)이전 대화 맥락을 기억하며 이어지는 연속 대화 구조ChatGPT, Claude, Copilot 등 생성형 AI 서비스

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


UI 출력 방식

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

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


LLM의 한계 및 환각(Hallucination)

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

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

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

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


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