Classical RAG vs Agentic RAG: 실무적인 의사결정 가이드

"RAG를 사용해야 할까요, 아니면 에이전트(Agent)를 사용해야 할까요?"는 제가 참여하는 거의 모든 LLM 프로젝트에서 나오는 질문입니다. 솔직한 답변은 이 둘이 서로 경쟁 관계에 있는 선택지가 아니라는 것입니다. Classical RAG와 Agentic RAG는 하나의 스펙트럼 상에 놓여 있으며, 스펙트럼의 잘못된 끝을 선택하면 비용을 낭비하거나 부실한 답변을 얻게 됩니다. 이 포스트는 제가 준비한 가이드와 데모를 바탕으로 결정할 수 있는 실무적인 방법을 제시합니다.

실행 가능한 코드가 포함된 리포지토리(Repo): https://github.com/ahmet-ozel/rag-architecture-guide

Classical RAG 한 문단 요약

Classical RAG는 고정된 파이프라인(Pipeline)입니다. 쿼리(Query)를 임베딩(Embed)하고, 벡터 스토어(Vector Store)에서 상위 k개의 청크(Chunk)를 검색(Retrieve)한 뒤, 이를 프롬프트(Prompt)에 집어넣어 답변을 생성합니다. 한 번의 검색과 한 번의 생성으로 이루어집니다. 비용이 저렴하고 빠르며 예측 가능합니다. 정답이 한두 개의 문서에 들어 있는 지식 베이스(Knowledge Base)의 경우, 대개 이것만으로 충분하며 그 이상의 기능을 추가하는 것은 지연 시간(Latency)과 비용만 증가시킬 뿐입니다.

Agentic RAG 한 문단 요약

Agentic RAG는 제어권을 모델에게 넘깁니다. 고정된 파이프라인 대신, LLM이 무엇을 할지 결정합니다. 쿼리를 재구성(Reformulate)하거나, 검색하고, 결과가 충분히 좋은지 확인하고, 다른 소스에서 다시 검색하거나, 도구(Tool)를 호출한 뒤에야 답변을 내놓습니다. 루프(Loop)를 돌 수도 있습니다. 이는 어려운 질문에 대해 훨씬 더 강력한 성능을 발휘하지만, 속도가 더 느리고 더 많은 토큰(Token) 비용이 들며 결정론적(Deterministic)으로 만들기 더 어렵습니다.

실무에서 작동하는 의사결정 트리

단순하게 시작하고, 데이터가 요구할 때만 복잡성을 추가하세요:

1. 답변이 보통 단일 청크 (chunk) 또는 문서에 포함되어 있습니까? 그렇다면 Classical RAG를 사용하세요.
2. 답변을 위해 여러 문서의 정보를 결합하거나 추론 단계가 필요합니까? 그렇다면 Agentic RAG 쪽으로 기울어야 합니다.
3. 답변을 위해 여러 소스 (벡터 DB, SQL 테이블, 외부 API 등)를 쿼리해야 합니까? 모델이 도구 (tools)를 선택해야 하므로 Agentic RAG를 사용하세요.
4. 지연 시간 (latency)과 비용이 엄격한 제약 조건입니까 (높은 트래픽, 사용자 대면 서비스)? Classical RAG를 우선시하고, 실제로 필요한 쿼리에 대해서만 에이전트 (agent)로 격상시키세요.
5. 비결정론적 (non-deterministic) 동작을 허용할 수 있습니까? 허용할 수 없다면, 가끔 예상치 못한 방식으로 루프 (loop)를 도는 에이전트보다 강력한 검색 (retrieval) 기능을 갖춘 Classical RAG가 더 낫습니다.

제가 선호하는 패턴은 다음과 같습니다: 먼저 Classical RAG를 실행하고, 신뢰도 (confidence) 또는 자가 점검 (self-check) 단계에서 검색된 컨텍스트 (context)가 약하다고 판단되면 해당 단일 쿼리만 Agentic 경로로 격상시키는 것입니다. 대부분의 쿼리는 저렴하게 유지되며, 어려운 쿼리에 대해서만 에이전트 비용 (agent tax)을 지불하게 됩니다.

모두가 건너뛰는 부분: 평가 (evaluation)

측정 없이는 어떤 접근 방식도 의미가 없습니다. 아키텍처에 대해 논쟁하기 전에, 정답이 알려진 실제 질문들로 구성된 평가 세트 (eval set)를 구축하세요. 그런 다음 다음 항목들을 추적하십시오:

• 검색 품질 (Retrieval quality): 올바른 청크가 실제로 검색되고 있는가? (recall@k, hit rate)
• 답변 품질 (Answer quality): 충실도 (faithfulness, 답변이 검색된 컨텍스트에 근거하고 있는가?) 및 관련성 (relevance).
• 쿼리당 비용 및 지연 시간: 이를 통해 Agentic 동작이 실제로 얼마만큼의 비용을 발생시키는지 확인할 수 있습니다.

제가 접하는 대부분의 "RAG는 별로다"라는 불만은 사실 검색 (retrieval) 문제입니다: 잘못된 청킹 (chunking), 잘못된 임베딩 모델 (embedding model), 또는 리랭킹 (reranking)의 부재 등입니다. 검색 문제를 해결하는 것이 에이전트로 전환하는 것보다 효과적인 경우가 많습니다.

데모 포함 내용

이 리포지토리 (repo)는 벡터 검색을 위한 ChromaDB를 사용하여 두 아키텍처를 처음부터 끝까지 살펴봅니다. 또한 OpenAI, Gemini, Claude, Ollama, vLLM을 모두 지원하므로, 완전히 로컬에서 실행하거나 호스팅된 모델을 대상으로 실행할 수 있습니다. 여기에는 청킹 및 검색 단계, 에이전트의 도구 선택 루프 (tool-selection loop), 그리고 자신의 데이터로 두 방식을 비교할 수 있는 평가 지표 (evaluation metrics)가 포함되어 있습니다.

요약 (Takeaway)

기본적으로는 classical RAG (고전적 RAG)를 사용하세요. 질문이 진정으로 다단계 추론 (multi-step reasoning)이나 여러 소스를 필요로 할 때 agentic behavior (에이전트적 동작)를 추가하고, 그렇게 할 때는 비용을 측정하세요. 아키텍처 (Architecture)는 스위치가 아니라 다이얼입니다.

Repo: https://github.com/ahmet-ozel/rag-architecture-guide

여러분은 프로덕션 환경에서 고정된 파이프라인 (fixed pipelines)과 agentic retrieval (에이전트적 검색) 사이에서 어떻게 의사결정을 내리고 계신가요? 특히 사람들이 비용 측면에서 어디에 선을 긋는지 궁금합니다.