AI 챗봇 프로젝트에서 배운 실전 Context Engineering

“챗봇 성능을 올린 건 프롬프트가 아니라, 컨텍스트였다.”

1. 들어가며

“Context Engineering? 어렵다고 생각했지만, 해보니 그렇지 않았다.”

요즘 LLM 관련 커뮤니티나 관련 글에서는 ‘Prompt Engineering은 끝났다. 이제는 Context Engineering의 시대다’라는 이야기가 심심치 않게 들립니다.

하지만 솔직히 말해, 처음에 Context Engineering이라는 말은 꽤 어렵게 느껴졌습니다. ‘컨텍스트’라는 단어 자체가 다소 추상적이고, 마치 개발자들만 다루는 고난도 영역처럼 느껴졌거든요.

그런데 최근 챗봇 프로젝트를 진행하며 직접 그 구조를 설계하고 반복 테스트해보니,
생각보다 복잡한 것도, 멀리 있는 것도 아니었습니다.

“사용자 질문이 다르게 표현돼도, LLM이 같은 의미로 이해하고 일관되게 답할 수 있도록 맥락을 구성해주는 일”
→ 이게 바로 제가 직접 설계하고 반복해본, 실전형 Context Engineering이었습니다.

2. 문제 발견

“의도는 같은데 표현이 달라지니, 챗봇은 다르게 이해했다.”

제가 맡은 챗봇 프로젝트의 초기 테스트 결과는 꽤 충격적이었습니다.
‘초보자 가이드’라는 질문에는 잘 대답하던 챗봇이,
‘뉴비 팁’이라는 표현에는 전혀 엉뚱한 답을 내놨거든요.

두 질문의 의도는 분명히 같았지만,
단지 표현 방식이 다르다는 이유만으로 챗봇은 서로 다른 질문으로 인식하고 있었습니다.

당시엔 챗봇 출시가 한 달 남짓 남은 시점이었고,
팀은 RAG 성능 향상을 위한 Knowledge 확장과 기능 개발에 집중하고 있던 상황이었습니다. 하지만 정작 가장 중요한 응답의 정확도와 신뢰도가 낮은 상태였고,
출시 여부조차 불투명해질 정도로 우려가 커졌습니다.

이때 발견한 핵심은 단순히 “지식이 부족해서”가 아니라,

“모델이 이해할 수 있도록 표현을 정리해주는 맥락(Context)이 설계되지 않았기 때문”이었습니다.

3. 해결 과정

“FAQ 중심 유사 표현군 테스트 구조 설계”

문제의 본질을 확인한 이후, 단순히 지식을 더 넣는 것이 아니라
사용자 표현의 다양성에 대응할 수 있는 구조를 만들기로 했습니다.
그 시작은 자주 묻는 질문(FAQ) 101개를 기준으로,
각 항목당 유사 표현 2개씩을 붙여 총 303건의 테스트셋을 구성한 것이었습니다.

콘텐츠 서비스 기획·운영 경험을 하며 체득한 팔레토 법칙에 착안해
“가장 많이 묻는 질문부터 제대로 잡자”는 방향으로 아이디어를 정리했고,
이를 내부에 제안하여 빠르게 승인받고 바로 실행에 들어갔습니다.

그 결과는 아래와 같습니다.

1차 테스트: 초기 정확도 21%
2차 테스트: 표현군 보완 및 KB 정비 후 정확도 79%로 대폭 향상
3차 테스트: 일시적 정확도 하락(67%) 발생 – 캐시/문서 갱신 문제로 확인
4차 테스트: 구조 개선 및 운영 이슈 해결 후 최종 정확도 약 89% 달성
※ 3차 테스트에서 발견된 배포 관리 이슈와 그 개선 과정은 다음 글에서 다룰 예정입니다.

이 일련의 과정을 거치며,
단순히 지식을 채우는 것이 아니라

“어떻게 컨텍스트를 구성해줘야 모델이 일관된 답변을 낼 수 있는가”를 체득할 수 있었습니다.

4. 교훈

“Context Engineering은 생각보다 가까이에 있다.”

이번 프로젝트를 통해 얻은 인사이트는 분명했습니다.

Context Engineering은 개발자만의 영역이 아니다.
오히려, 기획자처럼 사용자의 언어와 표현 방식을 이해하고 정리하는 사람이 잘 설계할 수 있는 영역이다.
복잡한 수식이나 모델 튜닝 없이도,
표현군 설계와 반복 테스트만으로 성능을 유의미하게 끌어올릴 수 있다는 걸 직접 경험했습니다.

5. 마무리하며…

LLM 도입이 본격화되는 지금,
단순히 “모델을 붙였다”는 수준을 넘어서
Prompt → Context로 사고 전환이 이뤄져야 서비스가 실제로 잘 동작합니다.

저는 이번 프로젝트를 통해,
기획자도 충분히 LLM 챗봇의 성능을 구조적으로 개선할 수 있으며,
그 핵심은 컨텍스트 설계에 있다는 점을 실전 프로젝트를 통해 확인할 수 있었습니다.

그리고 더 나아가 결국
“기획자란 모두가 이해할 수 있는 기준을 세우고,
이를 테스트 및 분석하여, 실제 성과로 만드는 프레임을 설계하는 사람”
이라는 생각을 다시 한번 확인하게 되었습니다.

결국 LLM은 맥락을 먹고 자랍니다.
여러분만의 컨텍스트 설계 방식을 만들어보시길.
모두 파이팅입니다 💪

1. 서문

앞선 글에서는 Safety 정책과 폴백·쿠션멘트 설계를 다뤘습니다.
이번에는 이 요소들이 RAG 파이프라인 속에서 어떻게 연결되는지를 이야기하려 합니다.

먼저 간단히 복습하자면:

LLM (Large Language Model): 대규모 언어 모델. 질문을 이해하고 답변을 생성하는 엔진
RAG (Retrieval-Augmented Generation): LLM이 답변을 생성하기 전, 검색으로 근거 자료를 찾아 활용하는 최신화 프레임워크
→ 즉, “검색 기반 + 생성형”을 결합해 답변의 신뢰도를 높이는 방식입니다.

파이프라인 자체는 개발팀이 주도적으로 설계·구현했지만,
제가 맡은 역할은 그 흐름이 사용자 경험 차원에서 안정적으로 작동할 수 있도록 기준과 필요사항을 정의하는 것이었습니다.

2. RAG 파이프라인 개요

RAG는 보통 다음 단계를 거칩니다:

Input 처리 – 사용자 발화 전처리
Retriever – 검색 및 문서 매칭
Augment – 검색 결과 정제 및 후보 선택
Generator – LLM 응답 생성
Output Post-processing – 응답 후처리 및 검증

이 중 기획자의 역할은 각 단계에서 “어떤 경우를 어떻게 처리할지” 기준을 제공하는 것입니다.

3. 단계별 기획자의 터치포인트

각 단계는 개발팀이 주도적으로 구현했지만,
기획자는 사용자 경험 관점에서 기준을 정의하는 역할을 했습니다.

단순 요약이 아니라, 실제로 어떤 일이 일어나는지를 예시와 함께 풀어보겠습니다.

① Input (전처리 & Safety 1)

개발팀: 언어 탐지, 금칙어/개인정보(PII) 검출, 입력 포맷 정규화
기획:
- 미지원 언어 → “현재 한국어만 지원합니다. 다시 입력해 주세요.”
- 특수문자/형식 오류 → “입력하신 문구를 확인해 주세요.”
- 금칙어/불법 발화/개인정보 → “안전한 서비스 제공을 위해 해당 내용은 안내드릴 수 없습니다.”
- 계정/결제 등 사람 개입 필요 → 상담사 이관

👉 핵심은 차단/재시도/이관 플로우를 정의하는 것입니다. 이렇게 해야 사용자 경험을 보호하고 시스템 자원도 절약할 수 있습니다.

② Retriever (검색/매칭)

개발팀: 쿼리 빌드, 인덱스 검색, 스코어링, Top-K 후보 산출
기획:
- IDK (도메인 안인데 답 없음) vs OOD (도메인 밖 질문) 구분
- 검색 신뢰도 임계치(Threshold) → 기준 이상 = 답변 생성, 기준 이하 = 추천 리스트 제공
- 소스 우선순위 = 공식 문서 > 공지 > 커뮤니티

👉 임계치는 초기엔 개발팀이 임의로 정했지만, 실제 운영에서는 “언제 답변을 막고 언제 추천으로 돌릴지”가 사용자 경험에 직결됩니다.

📦 Top-K & Score Threshold란?

Top-K Retrieval: 검색 결과 중 상위 K개만 가져오는 방식.
예: 200개 검색 → 상위 5개만 선택 = Top-5. (보통 K=3~10)
Score Threshold(임계치): 검색 결과의 유사도 점수(score)가 기준 T 이상일 때만 “신뢰 가능”으로 간주.
예: 0.85 ≥ 0.8 → 답변 생성
예: 0.55 < 0.8 → “정확한 답변을 찾지 못했습니다. 대신 [추천 리스트]를 확인해 주세요.”
왜 기획자가 알아야 할까? 이 값들은 사용자 경험에 직접 영향을 주는 값이기 때문입니다.
예: T가 너무 높으면 → 답변이 자주 막힘
예: T가 너무 낮으면 → 엉뚱한 답변까지 노출

③ Augment (컨텍스트 구성)

개발팀: Top-K 결과 중 프롬프트에 넣을 자료 정제
기획:
- 최신 자료/공식 자료 우선 순위 설정 (이번 달 공지 > 작년 글, 공식 FAQ > 커뮤니티)
- 중복 제거 (비슷한 문서 여러 개일 경우 1개만 남김)
- 신뢰도 낮음 → 다운그레이드 응답 (“정확한 답변은 제공되지 않습니다. 대신 [공식 문서]를 참고하세요.”)

👉 즉, 어떤 자료를 남기고/빼고, 불충분할 때 어떻게 보여줄지를 정하는 단계입니다.

④ Generator (LLM 생성)

개발팀: 프롬프트 구성 및 LLM 호출
기획:
- 브랜드 톤·쿠션멘트 정의
  - 게임 = 친근/재밌게 (“이 부분은 아직 준비되지 않았어요 😅”)
  - 금융 = 단정/공식 (“현재 해당 정보는 제공되지 않습니다.”)
- 신뢰도 낮음 → 정중 거절 + 대체 링크 안내
- 프롬프트 가드레일
  - 범위 벗어난 질문은 거절
  - 모르면 IDK
  - 출처 없이 단정 금지

👉 답변 자체는 모델이 생성하지만, “어떤 톤과 규칙 안에서 말하게 할지”는 기획이 정합니다.

⑤ Output (후처리 & Safety 2)

개발팀: 최종 응답 필터링, 금칙어/민감정보 제거, 마스킹 처리
기획:
- 차단 발생 시 대체 문구 정의
  - “안전한 서비스 제공을 위해 일부 내용은 표시되지 않습니다.”
- 필요 시 공식 링크/상담 버튼 제공
- 책임 문구/출처 표기 여부 결정

👉 Output은 마지막 안전망입니다. Input에서 걸러지지 않은 리스크가 여기서 최종적으로 검수됩니다.

5. 경험담 & 마무리

처음엔 “개발팀이 기술적으로 잘 만들겠지”라고 생각했습니다.
하지만 막상 업무를 진행하다 보니, 사용자 안내 기준이 빠진 채로는 파이프라인이 온전히 작동하지 않는다는 걸 알게 되었습니다.

결국 기획자의 역할은 직접 파이프라인을 설계하는 것이 아니라,
각 단계가 사용자 경험 차원에서 일관되게 동작하도록 기준과 필요사항을 정의하고 정리하는 것이었습니다.

겉으로 보면 RAG 파이프라인은 기술 중심 프로세스처럼 보입니다.
그러나 실제로는 Safety 정책, 폴백, 쿠션멘트 같은 사용자 경험 설계가 파이프라인 속에 녹아 있어야 비로소 서비스가 제대로 굴러갑니다.

결국 기획자는 기술의 빈 공간을 채우는 사람이 아니라,
서비스 전체가 일관된 경험을 주도록 연결해주는 역할을 맡습니다.

P.S.

RAG 2.0이 아직 일반화되지도 않았는데, 벌써 RAG 3.0이 논의될 정도로
AI는 지금도 하루가 다르게 발전하고 있습니다.

따라서 지금의 RAG 파이프라인 구축은 어디까지나 하나의 프레임워크이자 레퍼런스일 뿐입니다.
앞으로 새로운 기술 트렌드에 맞춰 계속 진화할 것이고,
기획자는 급변하는 흐름 속에서 유연하게 기준과 해결책을 설계하는 태도를 가져야 할 것입니다.

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가 하루가 다르게 빠르게 발전하고 있습니다.
모든 내용은 단순한 경험과 프레임워크의 참고서일 뿐이며, 실제 진행 방식은 언제든지 바뀔 수도 있고 더 효율적인 방식으로 진화되어야 합니다.

CannotBeHidden

AI 챗봇 프로젝트에서 배운 실전 Context Engineering

1. 들어가며

“Context Engineering? 어렵다고 생각했지만, 해보니 그렇지 않았다.”