단순 RAG로 6개월을 버티다 결국 갈아엎은 후기 — Agentic RAG 직접 구축 실험 로그
지난 11월에 사내 위키 검색용으로 만든 RAG 챗봇이 5월 들어 사용자 만족도 38%까지 떨어졌다. 질문 100건 중 38건만 "도움이 됐다"고 답한 셈이다. 6개월 만에 처음부터 다시 짜기로 결정했고, 이번엔 모든 사람이 말하는 그 단어, Agentic RAG로 갔다.
이 글은 그 갈아엎는 과정의 실험 로그다. 결론부터 말하면 정확도는 38% → 71%로 올랐고, 토큰 비용은 글자 그대로 3.4배 늘었다. 어느 쪽을 택할지는 끝까지 읽고 판단하시길.
1. 왜 단순 RAG가 깨졌나 — 6개월 운영 데이터
처음 만든 구조는 교과서 그대로였다. 사내 위키 1,200문서 → OpenAI text-embedding-3-small 임베딩 → Pinecone Serverless → GPT-4o-mini로 합성. 한 번의 검색 → 한 번의 생성. 가장 흔한 RAG-101 구성이다.
운영 6개월 동안 쌓인 실패 패턴을 자체 로그에서 추출해 봤다.
| 실패 유형 | 비중 | 대표 사례 |
|---|---|---|
| 질문 모호로 검색 미스 | 31% | "지난 분기 보안 정책 변경 정리해줘" → 분기 정보 누락 |
| 다중 문서 종합 실패 | 24% | "A 정책과 B 정책 충돌점 찾아줘" → 한 문서만 인용 |
| 한국어 청크 깨짐 | 18% | 표·코드블록 중간이 잘려 의미 손실 |
| 최신성 부족 | 14% | 작년 문서 인용하고 "최신 정보"라고 답 |
| 환각 (출처 없음) | 13% | 본문에 없는 수치 생성 |
핵심 문제는 명확했다. "한 번 검색 → 한 번 생성" 파이프라인은 사용자의 진짜 질문 구조를 무시한다. 사람은 한 문장에 두세 개 의도를 섞어 묻고, 종종 자신이 뭘 묻는지조차 모호하게 말한다. 단순 RAG는 그걸 첫 검색에 다 욱여넣다가 어이없이 무너진다.
2. Agentic RAG로 갈아엎기 — 내가 고른 스택
5월 첫째 주에 새 구조를 짰다. 선택지는 LangGraph, CrewAI, LlamaIndex Agents 셋이었고 최종 결정은 LangGraph + LangSmith였다. CrewAI도 좋아 보였지만 데모용 시연이 아니라 프로덕션 안정성이 우선이었다.
스택 구성은 이렇다.
- 오케스트레이션: LangGraph 0.4
- LLM: Anthropic Claude Sonnet 4.6 (분해·검증), Claude Haiku 4.5 (요약·라우팅)
- 임베딩: Voyage AI
voyage-3-large(한국어 보강) - 벡터 DB: Qdrant Cloud (BM25 하이브리드)
- 관측: LangSmith
- 도구 연결: MCP 서버 3개 (위키, JIRA, GitHub)
LangGraph 노드는 다섯 개로 그렸다.
- 질문 분해기 — 사용자 질문을 1~4개 서브쿼리로 쪼갠다.
- 하이브리드 리트리버 — 각 서브쿼리에 대해 BM25 + 벡터 검색 후 RRF로 융합.
- 검증기 — 검색 결과가 질문에 충분한지 LLM-as-a-judge로 점수화.
- 재시도 라우터 — 점수 미달 시 쿼리 재작성 후 2회까지 재검색.
- 합성기 — 통과한 컨텍스트만 모아 인용 포함 답변 생성.
설계 그림을 화이트보드에 그렸을 때는 우아해 보였지만, 실제로 돌려보니 첫 주는 지옥이었다.
3. 첫 주의 사고들 — 환상이 깨지는 순간
5월 5일, 새 시스템 첫 24시간 동안 평균 응답 시간이 14.3초였다. 단순 RAG 시절의 2.1초와 비교하면 거의 7배. 사용자들이 "왜 이렇게 느려졌냐"고 항의했고 한 PM은 슬랙에서 "예전 게 더 나았다"고 대놓고 적었다.
문제는 분해된 서브쿼리 각각에 대해 LLM 호출이 반복되면서 생긴 직렬 지연이었다. LangGraph에서 Send API로 서브쿼리를 병렬화하니 평균 응답이 5.8초로 떨어졌다. 여전히 단순 RAG 대비 2.7배지만 사용자가 견딜 만한 수준이다.
두 번째 사고는 비용이었다. 5월 6일 하루 API 청구액이 단순 RAG 시절 한 달치를 넘겼다. 검증 노드가 매 검색마다 Sonnet을 부르고 있었던 게 원인이었다. 검증은 Haiku로 내리고 합성과 분해만 Sonnet에 맡기는 식으로 모델을 분리하니 비용이 1/4로 떨어졌다.
세 번째 사고는 한국어였다. 영어 문서에서는 잘 도는 RRF 융합이 한국어 위키에서 BM25 점수가 비정상적으로 튀었다. Mecab 형태소 분석을 거친 인덱스를 따로 만들고 BM25 가중치를 0.3에서 0.5로 올리니 안정됐다.
이 세 사고를 잡는 데만 9일이 걸렸다. 어떤 블로그에도 "병렬화 안 하면 평균 14초 나옵니다"라고 적혀 있지 않았다.
4. 14일차 자체 측정 — 단순 RAG vs Agentic RAG 직접 비교
5월 14일 기준, 같은 평가 셋(질문 80개, 사내 평가위원 3명 채점)으로 두 시스템을 돌려 봤다. 채점 기준은 답변이 (a) 정확한가 (b) 충분히 인용했는가 (c) 사용자 의도에 맞는가 셋이다.
| 지표 | 단순 RAG (4월) | Agentic RAG (5월) | 변화 |
|---|---|---|---|
| 만족도 (3인 평균) | 38% | 71% | +33pp |
| 평균 응답 시간 | 2.1초 | 5.8초 | +176% |
| 질문당 LLM 호출 | 1회 | 4.3회 평균 | +330% |
| 질문당 토큰 비용 | ₩42 | ₩143 | +240% |
| 출처 인용 비율 | 64% | 96% | +32pp |
| 환각 비율 (수동 검수) | 13% | 3% | -10pp |
수치만 보면 비용이 2.4배 늘었지만 만족도가 거의 두 배가 됐다. 우리 회사처럼 "잘못된 답변이 사람을 곤란하게 만드는" 워크로드에서는 명백히 이긴 게임이다. 반대로 사용량이 매우 많고 답변 품질이 60% 정도여도 괜찮은 경우라면 단순 RAG가 여전히 합리적이다.
5. MCP 도입으로 다시 한 번 바뀐 점
5월 둘째 주에 Model Context Protocol(MCP) 서버 세 개를 붙였다. 사내 위키, JIRA, GitHub 검색을 각각 MCP로 노출했더니 에이전트가 필요한 도구를 그때그때 호출하는 구조가 자연스럽게 잡혔다. Anthropic이 작년 말 공개한 이 표준이 1년 만에 진짜 의미를 갖기 시작한 시점이다.
MCP 전에는 도구별로 따로 함수 시그니처를 박아 넣어야 했고, 도구를 추가할 때마다 LangGraph 노드가 늘어났다. MCP 후에는 도구를 추가해도 노드는 그대로다. "위키 추가했어요" 한 줄이면 에이전트가 알아서 쓰기 시작한다. 운영 부담이 체감상 절반으로 줄었다.
다만 MCP가 만능은 아니다. 응답 스키마 검증, 권한 관리, 도구 호출 비용 한도는 별도로 챙겨야 한다. 이건 표준이 아직 못 따라온 영역이다.
6. 단순 RAG와 Agentic RAG, 어떻게 결정할까
지난 6개월의 운영과 9일의 갈아엎기로 정리한 결정 기준이다. 누구에게도 정답은 없고 워크로드가 결정한다.
단순 RAG가 충분한 경우
- 질문이 짧고 일관적인 FAQ 봇 수준
- 사용자가 답이 부정확해도 큰 손해를 보지 않는 영역
- 월 호출량이 매우 많아 비용이 절대적인 제약
- 응답 지연 1~2초 이내가 필수인 사용자 경험
Agentic RAG가 필요한 경우
- 한 질문 안에 2개 이상 의도가 섞이는 사내 검색·법무·연구
- 답변 한 건이 의사결정으로 이어지는 워크플로
- 출처 인용·감사 추적이 필수인 규제 산업
- 다양한 외부 도구(JIRA·GitHub·DB) 호출이 일상
내 경우는 명백히 후자였고, 그래서 비용 2.4배를 감수했다. 이 트레이드오프를 솔직히 인정하는 게 첫걸음이라고 본다.
7. 만약 다시 시작한다면
같은 작업을 다시 한다면 두 가지를 바꿀 것 같다.
첫째, 처음부터 LangSmith를 켜 둘 것이다. 9일간의 사고 중 절반은 어디서 시간이 새는지 안 보여서 헤맸다. 트레이싱을 첫날부터 깔아 두면 병렬화·모델 분리·BM25 가중치 문제 모두 4일 안에 잡혔을 것이다.
둘째, 단순 RAG와 Agentic RAG를 A/B로 동시 운영했을 것이다. 새 시스템 첫 주에 옛 시스템을 완전히 내리니 사용자 불만이 폭증했다. 두 파이프라인을 라우터 앞에 두고 질문 유형에 따라 분기하는 하이브리드 운영이 훨씬 안정적이었을 것이다.
지금도 늦진 않았다. 다음 주부터 라우터를 붙여 단순한 질문은 단순 RAG로 보내고 복합 질문만 Agentic RAG로 라우팅할 계획이다. 응답 시간과 비용 두 곡선을 동시에 잡을 수 있는 마지막 카드라고 본다.
자주 받는 질문 정리
Q. 로컬에서만 Agentic RAG 운영하면 비용 0원인가요?
Ollama + Gemma 4 E4B + Qdrant 로컬 조합이면 클라우드 비용은 거의 0원이지만, 노트북 GPU·전력·운영 시간 같은 숨은 비용이 든다. 동시 사용자 10명을 넘기는 순간 클라우드 GPU 비용이 다시 들어온다.
Q. CrewAI 대신 LangGraph로 간 결정적 이유는?
LangGraph는 노드·엣지·상태가 명시적인 그래프 모델이라 디버깅이 쉬웠다. CrewAI는 롤플레잉 메타포가 직관적이지만 사고 로그가 노드 단위로 떨어지지 않아 트레이싱이 어려웠다. 프로덕션 운영 관점에선 LangGraph가 안전했다.
Q. 한국어 RAG에서 임베딩 모델 가장 큰 차이는?
같은 평가 셋에서 OpenAI text-embedding-3-small 검색 적중률 61%, Voyage voyage-3-large 78%, Cohere embed-multilingual-v3 72%였다. 한국어 워크로드에 한해서는 Voyage가 의미 있게 앞섰고, 비용도 차이가 크지 않았다.
Q. 환각 비율 13% → 3%, 어디서 줄었나요?
주된 효과는 검증 노드의 거절 동작이다. 검색 결과가 부족하면 합성 단계로 못 가고 "관련 문서를 충분히 찾지 못했습니다"로 답하게 했다. "모르겠다"고 인정하도록 강제하는 것이 RAG 시스템 신뢰도의 절반을 만든다.
Q. 사용자 만족도 측정은 어떻게 했나요?
답변마다 "도움이 됐어요 / 부족했어요" 두 버튼을 띄우고, 매주 평가위원 3명이 무작위 80건을 정성 채점했다. 정량+정성 두 지표가 같은 방향으로 움직일 때만 진짜 개선으로 판단했다.
마치며
Agentic RAG는 만병통치약이 아니다. 잘못 쓰면 비용만 늘리고 응답만 느려지는, 한 단어로 "엔지니어링 부채"가 된다. 그런데 단순 RAG로 깨지던 워크로드에서 명확히 다른 결과를 만들어 낸다는 점은 6주의 실험으로 분명해졌다.
가장 중요한 교훈은 의외로 단순하다. 자신의 RAG가 어디서 깨지는지 데이터로 보지 않은 채 Agentic RAG로 옮기지 말 것. 실패 유형 분류표 한 장을 먼저 만들고, 그 표의 어떤 항목을 Agentic 구조가 풀어주는지 짚은 다음에 결정해도 늦지 않다.
다음 글에서는 라우터 도입 후 단순 RAG와 Agentic RAG 하이브리드 운영 결과를 같은 평가 셋으로 다시 측정해서 가져올 예정이다.
참고 자료
- LangChain Blog, "LangGraph Agents in Production", 2026-04 (langchain.dev)
- Anthropic, "Model Context Protocol Specification", 2025-11 (modelcontextprotocol.io)
- Voyage AI, "voyage-3-large Technical Report", 2026-02 (voyageai.com)
- Qdrant Docs, "Hybrid Search with BM25", 2026-03 (qdrant.tech)
- Pinecone Engineering Blog, "RAG Failure Modes in Production", 2025-12 (pinecone.io)
- 전자신문, "에이전트 AI 시대, 챗GPT 흔들리고 클로드 급성장", 2026-05-12
- LlamaIndex Docs, "Agentic Retrieval Strategies", 2026-04 (docs.llamaindex.ai)
by 정보연구소장 · 최종 검증 2026-05-16 · 문의: jikol2000@gmail.com
본 글은 사내 RAG 시스템 6개월 운영 데이터와 5월 5~14일 직접 진행한 갈아엎기 실험 로그를 바탕으로 작성됐습니다. 일부 수치는 사내 시스템 특성상 일반화에 한계가 있으니 자신의 워크로드에 맞춰 재측정하시길 권합니다.
댓글
댓글 쓰기