[카테고리:] 3_일하다 | Work

AI 챗봇 프로젝트에서 배운 배포 환경의 중요성

1. 들어가며

앞선 글에서는 “컨텍스트를 어떻게 설계했는가”를 다뤘습니다.
하지만 프로젝트를 진행하며 다시 깨달은 건, 아무리 컨텍스트를 잘 짜도 배포 환경이 받쳐주지 않으면 안 된다는 사실이었습니다.

실제 경험을 예로 들어보겠습니다.
2차 테스트에서 정확도가 79%까지 수직 상승하며 “드디어 안정권이다”라고 안심했습니다. 그런데 3차 테스트에서는 빌드와 데이터가 동일했음에도 불구하고, 정확도가 67%로 급락했습니다. 당시 팀 분위기는 충격 그 자체였습니다.

2. 문제 발견

처음엔 모델의 성능 저하나 데이터 이슈를 의심했지만, 실제 원인은 전혀 다른 곳에 있었습니다. 바로 빠르게 진행된 배포 과정에서 발생한 관리 부재였습니다.

  • 캐시 갱신 실패: 빌드는 동일했지만, 하루치 캐시가 남아 있어 새 지식이 반영되지 않음
  • 빌더/운영 환경 불일치: RC와 Live 빌더에 각각 지식을 삽입했는데, 환경 간 불일치로 답변 공백 발생
  • 지식 삭제 문제: 일부 항목(예: 프레임 관련)이 잘못 제거되며 답변 불가 상태 노출

즉, 모델 개선 문제가 아니라 운영 환경 관리의 허점이 서비스 품질을 무너뜨린 것이었습니다.

3. 해결 과정

론칭을 불과 며칠 앞둔 상황이라, 개발/운영/PM/기획이 모두 모여 긴급 논의를 진행했습니다. 그리고 두 개의 트랙으로 문제를 정리했습니다.

Track 1. 론칭 대응

  • 컨텍스트 엔지니어링 기반으로 챗봇 응답 정확도 최대한 끌어올리기
  • 문제된 세 가지 이슈(캐시·환경 불일치·지식 삭제) 즉시 보완 후 QA 진행
  • 원칙: 론칭 후 버전 업데이트 시 임의 수정 금지 (롤백 기능 부재로 동일 리스크 재현 우려)

Track 2. 사후 대응

  1. 캐시 갱신 기능 – 자동·수동 병행 도입
  2. 빌더 버전 관리 – 빌드 버전별 프리징 및 배포 이력 관리
  3. 지식 기반(KB) 관리 – KB 등록/삭제 이력, RAG 활용 여부, 연결된 답변 예시까지 투명하게 관리

4. 성과

이 과정을 통해, 배포 관리의 중요성을 시스템 차원에서 각인할 수 있었습니다.
결과적으로 정확도는 다시 끌어올려, 안정적으로 마무리할 수 있었습니다.

  • 정확도: 3차 67% → 최종 89%
  • 운영 환경 안정화: 캐시·빌더·KB 관리 프로세스 확립
  • 팀워크 개선: 배포와 운영까지 “하나의 제품 경험”이라는 인식이 공유됨

5. 교훈

이 경험에서 얻은 인사이트는 분명했습니다.

  • 좋은 모델도 운영 환경에서 무너지면 끝이다.
  • 배포 환경과 운영 설계는 단순 지원이 아니라, 사용자 경험을 결정짓는 핵심이다.
  • PM과 기획자는 모델과 컨텍스트뿐 아니라 운영 환경까지 미리 챙겨야 한다.

1편에서 다룬 컨텍스트 설계가 챗봇의 ‘두뇌’를 만드는 과정이었다면,
이번 2편에서 다룬 배포 환경/운영 설계는 그 두뇌가 현실에서 제대로 작동하도록 하는 ‘신경망’을 세우는 과정이었습니다.

결국 챗봇은 모델-컨텍스트-운영 환경 이 세 박자가 맞아야만 제대로 작동합니다.
만약 본인이 PM 혹은 기획자라면, 놓치기 쉬운 배포와 운영 환경까지 반드시 점검하시길 권합니다.

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은 맥락을 먹고 자랍니다.
여러분만의 컨텍스트 설계 방식을 만들어보시길.
모두 파이팅입니다 💪

AI 챗봇, RAG 파이프라인 속 기획자의 역할

1. 서문

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

먼저 간단히 복습하자면:

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

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

2. RAG 파이프라인 개요

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

  1. Input 처리 – 사용자 발화 전처리
  2. Retriever – 검색 및 문서 매칭
  3. Augment – 검색 결과 정제 및 후보 선택
  4. Generator – LLM 응답 생성
  5. 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 파이프라인 구축은 어디까지나 하나의 프레임워크이자 레퍼런스일 뿐입니다.
앞으로 새로운 기술 트렌드에 맞춰 계속 진화할 것이고,
기획자는 급변하는 흐름 속에서 유연하게 기준과 해결책을 설계하는 태도를 가져야 할 것입니다.