Agentic RAG 설계 — 검색 판단을 에이전트에게 위임하는 RAG 아키텍처

목차

1. 개요
2. Agentic RAG의 핵심 개념과 동작 원리
3. 아키텍처 설계와 구성 요소
4. 검색 판단 에이전트 구현
5. 성능 특성과 트레이드오프
6. 운영 환경 적용 시 고려사항
7. 맺음말

개요

문제 배경

Agentic RAG는 기존 RAG(Retrieval-Augmented Generation) 파이프라인의 고질적인 한계를 극복하기 위해 등장한 아키텍처 패턴입니다. 전통적인 RAG는 질문이 들어오면 항상 검색을 수행하고, 검색된 문서를 그대로 LLM에 전달하는 단선적인 흐름을 따릅니다. 이 방식은 단순한 질의응답에서는 효과적이지만, 복잡한 추론이 필요하거나 여러 단계에 걸친 정보 수집이 요구되는 상황에서는 뚜렷한 한계를 드러냅니다. Agentic RAG는 검색 여부, 검색 전략, 검색 결과의 활용 방법에 관한 판단 권한을 에이전트에게 위임함으로써 이 문제를 해결합니다.

기존 방식의 한계

일반적인 RAG 파이프라인은 "질문 → 임베딩 → 벡터 검색 → 컨텍스트 주입 → 응답 생성"의 고정된 순서를 따릅니다. 이 구조는 구현이 단순하다는 장점이 있지만, 세 가지 근본적인 한계를 안고 있습니다.

첫째, 검색 필요성을 판단하지 않습니다. "2 더하기 2는 얼마인가?"처럼 LLM이 자체 지식으로 충분히 답할 수 있는 질문에도 무조건 검색을 수행합니다. 이는 불필요한 레이턴시와 토큰 비용을 유발합니다.

둘째, 단일 검색으로 충분하지 않은 질문을 처리하지 못합니다. "A 기술과 B 기술을 비교하고 우리 시스템에 어떤 것이 더 적합한지 분석해 달라"는 요청은 여러 번의 검색과 중간 추론을 거쳐야 합니다. 고정된 파이프라인은 이를 단 한 번의 검색으로 처리하려 하기 때문에 충분한 맥락을 확보하지 못합니다.

셋째, 검색 품질을 평가하지 않습니다. 검색된 문서가 질문과 실제로 관련이 있는지, 충분한 정보를 담고 있는지 확인하는 피드백 루프가 없습니다. 관련도가 낮은 문서가 그대로 컨텍스트에 삽입되어 응답 품질을 저하시킵니다.

기존 RAG는 판단 없이 고정된 파이프라인을 순서대로 실행하므로, 질문의 복잡도에 관계없이 동일한 비용과 구조를 소비합니다.

Agentic RAG의 핵심 개념과 동작 원리

에이전트 기반 검색 판단

Agentic RAG의 핵심 아이디어는 검색(Retrieval)을 도구(Tool)로 취급하고, LLM 에이전트가 스스로 이 도구의 사용 여부와 방법을 결정하게 한다는 것입니다. 이는 단순한 구현 변경이 아니라 RAG의 패러다임 자체를 바꾸는 접근입니다.

기존 RAG에서 검색은 파이프라인의 필수 단계였지만, Agentic RAG에서는 에이전트가 선택적으로 호출할 수 있는 옵션입니다. 에이전트는 질문을 분석한 뒤 "이 질문에 외부 정보가 필요한가?", "어떤 키워드로 검색해야 하는가?", "검색 결과가 충분한가?" 같은 판단을 내립니다. 이 판단 과정에서 LLM의 추론 능력이 핵심 역할을 합니다.

에이전트가 검색 결과를 평가하고 부족하면 다시 계획을 세우는 반복 구조가 Agentic RAG의 핵심입니다.

검색 전략의 동적 결정

단순히 "검색할지 말지"를 결정하는 것을 넘어, Agentic RAG는 어떻게 검색할지도 에이전트가 결정합니다. 에이전트는 질문의 특성에 따라 다양한 검색 전략을 선택합니다.

**쿼리 분해(Query Decomposition)**는 복잡한 질문을 여러 개의 단순한 하위 질문으로 분리하고 각각을 순서대로 검색하는 전략입니다. "AI 스타트업의 기술 스택 트렌드와 그것이 채용 시장에 미치는 영향"이라는 질문은 최소 두 개의 독립적인 검색이 필요합니다.

**하이브리드 검색(Hybrid Retrieval)**은 벡터 검색과 키워드 검색을 조합하는 방식입니다. 에이전트는 질문이 개념적 유사성을 요구하는지(벡터 검색에 유리), 아니면 특정 용어나 코드 스니펫을 찾는지(키워드 검색에 유리) 판단하여 적절한 전략을 선택합니다.

**멀티-홉 검색(Multi-hop Retrieval)**은 첫 번째 검색 결과에서 얻은 정보를 바탕으로 두 번째, 세 번째 검색을 이어가는 방식입니다. 이는 위키피디아에서 링크를 따라가며 정보를 수집하는 방식과 유사합니다.

자기 평가와 피드백 루프

Agentic RAG가 기존 RAG와 가장 크게 구별되는 지점은 자기 평가(Self-Evaluation) 메커니즘입니다. 에이전트는 검색 결과를 받은 뒤 단순히 그것을 컨텍스트에 삽입하는 것이 아니라, 결과의 품질을 평가합니다.

이 평가에는 주로 세 가지 기준이 적용됩니다. 첫 번째는 관련성(Relevance) — 검색된 문서가 질문과 실제로 관련이 있는지입니다. 두 번째는 충분성(Sufficiency) — 현재 수집된 정보가 질문에 답하기에 충분한지입니다. 세 번째는 신뢰성(Credibility) — 정보 출처가 신뢰할 만한지입니다. 이 평가를 통해 에이전트는 추가 검색이 필요한지, 다른 검색 전략으로 전환해야 하는지 결정합니다.

이 피드백 루프는 RAG의 품질을 근본적으로 향상시키지만, 무한 루프의 위험성도 내포하고 있습니다. 따라서 최대 반복 횟수(max iterations)를 설정하고, 에이전트가 현재 정보로 부분적인 응답이라도 생성할 수 있도록 하는 폴백 전략이 필수적입니다.

아키텍처 설계와 구성 요소

에이전트 레이어 구조

Agentic RAG의 아키텍처는 크게 세 개의 레이어로 구성됩니다. 오케스트레이션 레이어, 도구 레이어, 지식 레이어입니다. 이 세 레이어의 분리는 각 컴포넌트를 독립적으로 교체하고 테스트할 수 있게 해줍니다.

오케스트레이션 레이어는 에이전트 자체입니다. LLM이 질문을 분석하고, 어떤 도구를 어떤 순서로 사용할지 계획을 세우며, 중간 결과를 평가하는 역할을 합니다. 이 레이어의 핵심은 시스템 프롬프트 설계입니다. 에이전트가 어떤 상황에서 검색 도구를 호출할지, 어떻게 결과를 평가할지에 대한 지침이 시스템 프롬프트에 명시되어야 합니다.

도구 레이어는 에이전트가 호출할 수 있는 실제 기능들의 집합입니다. 벡터 검색 도구, 키워드 검색 도구, 요약 도구, 계산 도구, 외부 API 호출 도구 등이 여기에 속합니다. 각 도구는 명확한 입출력 스펙과 오류 처리를 갖춰야 합니다.

지식 레이어는 검색 대상이 되는 데이터 저장소입니다. 벡터 데이터베이스, 전통적인 검색 엔진, 관계형 데이터베이스가 모두 지식 레이어에 포함될 수 있습니다.

오케스트레이션 레이어가 도구와 지식 레이어를 동적으로 조합하며 검색 전략을 결정합니다.

도구 명세와 함수 시그니처

에이전트가 도구를 효과적으로 활용하려면 각 도구의 **명세(Specification)**가 LLM이 이해할 수 있는 형태로 정의되어야 합니다. 함수 시그니처, 파라미터 설명, 반환값의 형태, 사용 시나리오 예시가 모두 포함되어야 합니다.

도구 명세의 품질이 에이전트 성능에 직접적인 영향을 미칩니다. 파라미터 이름과 설명이 모호하면 에이전트가 잘못된 인자를 전달하고, 이는 검색 품질 저하로 이어집니다. 현업에서 흔히 겪는 문제는 도구 명세가 너무 기술적으로 작성되어 LLM이 적절한 사용 시나리오를 파악하지 못하는 경우입니다. 도구 명세는 **"언제 이 도구를 써야 하는가"**에 대한 설명을 반드시 포함해야 합니다.

아래는 Python 기반의 도구 명세 예시입니다. retrieve_documents 함수는 쿼리 문자열과 선택적 필터를 받아 관련 문서 목록을 반환하도록 정의되어 있습니다.

from typing import Optional
from anthropic import Anthropic

client = Anthropic()

# 도구 명세 — LLM이 이해할 수 있는 명확한 설명 포함
tools = [
    {
        "name": "retrieve_documents",
        "description": (
            "벡터 유사도 검색을 통해 질문과 관련된 문서를 가져옵니다. "
            "사실 확인이 필요하거나 최신 정보를 참조해야 할 때 사용하세요. "
            "단순 계산이나 일반 상식 질문에는 사용하지 않아도 됩니다."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {
                    "type": "string",
                    "description": "검색에 사용할 쿼리. 자연어 또는 핵심 키워드로 작성"
                },
                "top_k": {
                    "type": "integer",
                    "description": "반환할 문서 수 (기본값: 5, 최대: 20)",
                    "default": 5
                },
                "filter_tags": {
                    "type": "array",
                    "items": {"type": "string"},
                    "description": "특정 카테고리로 검색 범위 제한 (예: ['technical', 'recent'])"
                }
            },
            "required": ["query"]
        }
    },
    {
        "name": "keyword_search",
        "description": (
            "BM25 기반 키워드 검색으로 문서를 찾습니다. "
            "특정 코드 스니펫, 제품명, 고유명사를 포함한 검색에 적합합니다."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "keywords": {
                    "type": "array",
                    "items": {"type": "string"},
                    "description": "검색할 핵심 키워드 목록"
                },
                "operator": {
                    "type": "string",
                    "enum": ["AND", "OR"],
                    "description": "AND: 모든 키워드 포함, OR: 하나라도 포함",
                    "default": "AND"
                }
            },
            "required": ["keywords"]
        }
    }
]
# retrieve_documents 호출 결과: 관련도 순으로 정렬된 문서 목록 반환
# keyword_search 호출 결과: BM25 스코어 기준 문서 목록 반환

도구 명세에서 "언제 사용하지 않아도 되는지"를 명시하는 것이 에이전트의 불필요한 검색 호출을 줄이는 데 결정적입니다.

컨텍스트 관리와 메모리

멀티-홉 검색이나 여러 번의 도구 호출이 발생하면 컨텍스트 윈도우 관리가 중요한 설계 과제가 됩니다. 각 검색 결과가 그대로 컨텍스트에 누적되면 토큰 한도를 초과하거나 중요한 정보가 "lost in the middle" 현상으로 희석될 수 있습니다.

이를 해결하는 일반적인 접근법은 **요약 기반 압축(Summarization-based Compression)**입니다. 에이전트가 각 검색 단계에서 수집한 정보를 핵심만 남겨 요약하고, 다음 단계에서는 원문 대신 요약본을 참조합니다. 이 방식은 컨텍스트를 절약하지만 정보 손실의 위험이 있습니다.

다른 접근법은 **외부 메모리(External Memory)**를 두는 것입니다. 에이전트의 추론 과정에서 수집된 중간 사실들을 별도의 저장소에 기록하고, 필요할 때 조회합니다. 이는 구현 복잡도를 높이지만 장기 추론 세션에서 정보 무결성을 유지하는 데 효과적입니다.

검색 판단 에이전트 구현

에이전트 루프 구현

Agentic RAG의 핵심인 에이전트 루프를 구현합니다. 이 루프는 에이전트가 응답을 생성하거나 최대 반복 횟수에 도달할 때까지 계속됩니다. stop_reason이 "tool_use"이면 도구 호출이 필요한 상황이므로 해당 도구를 실행하고 결과를 다시 에이전트에게 전달합니다.

import json
from typing import Any

# 실제 검색 함수 (벡터 DB 또는 검색 엔진과 연결)
def execute_tool(tool_name: str, tool_input: dict) -> Any:
    if tool_name == "retrieve_documents":
        # 실제 환경에서는 벡터 DB 클라이언트 호출
        query = tool_input["query"]
        top_k = tool_input.get("top_k", 5)
        # 예시: 검색 결과 시뮬레이션
        return [
            {"id": f"doc_{i}", "content": f"문서 {i}: {query} 관련 내용", "score": 0.9 - i * 0.1}
            for i in range(top_k)
        ]
    elif tool_name == "keyword_search":
        keywords = tool_input["keywords"]
        return [{"id": "kw_doc_1", "content": f"키워드 {keywords} 포함 문서", "score": 0.85}]
    return []

def agentic_rag_query(user_question: str, max_iterations: int = 5) -> str:
    messages = [{"role": "user", "content": user_question}]
    system_prompt = """당신은 지식 베이스에서 정보를 검색하여 질문에 답하는 에이전트입니다.
    
검색 도구 사용 원칙:
1. 사실 확인이나 최신 정보가 필요할 때만 검색 도구를 호출합니다.
2. 검색 결과가 불충분하면 다른 키워드나 전략으로 재검색합니다.
3. 최대 3회 검색 후에는 수집된 정보로 최선의 답변을 생성합니다."""

    for iteration in range(max_iterations):
        response = client.messages.create(
            model="claude-opus-4-5",
            max_tokens=4096,
            system=system_prompt,
            tools=tools,
            messages=messages
        )

        # 에이전트가 응답을 완성한 경우
        if response.stop_reason == "end_turn":
            final_text = next(
                (block.text for block in response.content if hasattr(block, "text")), ""
            )
            return final_text  # 최종 응답 반환

        # 에이전트가 도구 호출을 요청한 경우
        if response.stop_reason == "tool_use":
            messages.append({"role": "assistant", "content": response.content})
            tool_results = []

            for block in response.content:
                if block.type == "tool_use":
                    result = execute_tool(block.name, block.input)
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": json.dumps(result, ensure_ascii=False)
                    })

            messages.append({"role": "user", "content": tool_results})

    return "최대 반복 횟수 초과 — 현재까지 수집된 정보를 바탕으로 답변할 수 없습니다."

# 사용 예시
answer = agentic_rag_query("최근 AI 에이전트 프레임워크의 주요 트렌드는 무엇인가요?")
# 결과: 에이전트가 검색 여부를 스스로 결정하여 관련 문서를 조회 후 종합 응답 반환

에이전트 루프의 핵심은 stop_reason을 기반으로 도구 호출과 최종 응답을 구분하는 것입니다. 도구 결과를 다시 메시지로 추가하여 에이전트가 연속적인 추론 맥락을 유지할 수 있게 합니다.

쿼리 분해와 멀티-스텝 검색

단순한 단일 도구 호출을 넘어, 에이전트가 복잡한 질문을 스스로 분해하여 여러 단계로 검색하는 패턴을 구현합니다. 이 접근법은 복잡한 분석 질문에 특히 효과적입니다.

# 쿼리 분해를 명시적으로 유도하는 시스템 프롬프트 전략
decomposition_system = """복잡한 질문을 받으면 다음 단계를 따르세요:

1. 질문을 독립적인 하위 질문으로 분해합니다.
2. 각 하위 질문에 대해 retrieve_documents를 호출합니다.
3. 수집된 정보를 종합하여 최종 답변을 생성합니다.

예시: "Python과 Go의 동시성 모델 차이점과 각 언어의 적합한 사용 사례"
→ 하위 질문 1: "Python 동시성 모델 (asyncio, threading, multiprocessing)"
→ 하위 질문 2: "Go goroutine과 채널 기반 동시성"
→ 하위 질문 3: "각 언어의 적합한 사용 사례 비교"
"""
# 각 하위 질문에 대한 개별 검색 결과가 에이전트 컨텍스트에 누적
# stop_reason == "end_turn"이 될 때까지 루프 반복

쿼리 분해 전략은 시스템 프롬프트에 명시적인 지침과 예시를 포함시킬 때 가장 일관된 성능을 발휘합니다.

검색 결과 평가와 재시도

에이전트가 검색 결과의 품질을 자체 평가하도록 유도하려면 평가 기준을 시스템 프롬프트에 명시해야 합니다. 단순히 "검색 결과가 부족하면 재검색하라"는 지침만으로는 부족합니다. 구체적으로 어떤 기준으로 충분성을 판단하는지 알려줘야 합니다.

검색 결과 평가는 단순 카운트가 아니라 "질문의 핵심에 직접 답하는 내용이 있는가"를 기준으로 판단해야 합니다.

성능 특성과 트레이드오프

레이턴시와 비용 프로파일

Agentic RAG는 기존 RAG보다 우수한 응답 품질을 제공하지만, 그 대가로 레이턴시와 비용이 증가합니다. 이는 설계 단계에서 반드시 고려해야 할 트레이드오프입니다.

기존 RAG의 응답 시간은 일반적으로 벡터 검색(50-200ms) + LLM 추론(1-5초)로 구성됩니다. Agentic RAG는 에이전트의 초기 계획 수립, N번의 도구 호출, 각 호출 사이의 LLM 추론이 더해져 전체 레이턴시가 2배에서 최대 10배까지 증가할 수 있습니다.

비용 측면에서도 차이가 큽니다. 에이전트가 도구를 호출할 때마다 메시지 히스토리 전체가 토큰으로 계산되기 때문에, 반복 횟수가 늘어날수록 비용이 급격히 증가합니다. 3번의 도구 호출이 발생하면 단순 계산으로도 기존 RAG 대비 3-4배의 입력 토큰이 소비됩니다.

대안 기술과 비교

Agentic RAG와 자주 비교되는 패턴으로는 FLARE(Forward-Looking Active REtrieval), Self-RAG, **Corrective RAG(CRAG)**가 있습니다.

FLARE는 LLM이 응답을 생성하는 중간에 불확실성이 감지될 때 검색을 트리거하는 방식입니다. 생성 과정을 직접 모니터링한다는 점에서 Agentic RAG보다 세밀하지만, 구현 복잡도가 매우 높습니다.

Self-RAG는 특별히 파인튜닝된 LLM이 검색 트리거, 관련성 판단, 지원 여부 평가를 특수 토큰을 통해 처리합니다. 오픈소스 모델에 적합하지만 파인튜닝 비용과 인프라가 필요합니다.

Corrective RAG는 검색 결과의 관련도를 평가하는 별도의 평가자(evaluator) 모델을 두고, 점수가 낮으면 웹 검색으로 폴백하는 구조입니다. 그래서 검색 커버리지가 가장 넓지만, 시스템 구성 요소가 많아 운영 부담이 큽니다.

Agentic RAG는 파인튜닝 없이 고복잡도 추론을 처리해야 할 때 가장 적합한 선택입니다.

어떤 상황에서 Agentic RAG를 선택할 것인가

Agentic RAG의 도입을 정당화하는 상황은 명확합니다. 단순 FAQ 시스템, 제품 스펙 조회, 고객 지원 봇처럼 질문의 구조가 단순하고 예측 가능한 경우에는 기존 RAG가 더 효율적입니다. 레이턴시와 비용을 낭비할 이유가 없습니다.

반면 분석 리포트 생성, 기술 비교 및 의사결정 지원, 여러 데이터 소스를 조합해야 하는 리서치 작업에서는 Agentic RAG의 유연성이 결정적 우위를 만듭니다. 특히 LLM의 자체 지식만으로 답할 수 있는 질문의 비율이 높은 도메인에서는 "검색을 하지 않는 판단"만으로도 비용을 상당히 절감할 수 있습니다.

운영 환경 적용 시 고려사항

흔한 실수와 함정

Agentic RAG를 처음 운영 환경에 도입할 때 가장 자주 마주치는 문제는 에이전트 루프 제어 실패입니다. 검색 결과가 계속 불충분하다고 판단하여 무한히 재검색을 시도하거나, 반대로 너무 일찍 검색을 포기하는 경우가 있습니다.

이를 방지하려면 세 가지 안전 장치를 반드시 구현해야 합니다. 첫째, max_iterations를 강제 적용하고 초과 시 현재 수집 정보로 최선의 응답을 생성합니다. 둘째, 동일한 쿼리로 반복 검색하는 것을 감지하고 차단합니다. 셋째, 에이전트가 호출한 도구 목록과 결과를 로깅하여 디버깅 근거를 확보합니다.

또 다른 흔한 실수는 도구 명세의 과도한 중복입니다. 비슷한 기능을 하는 도구가 여럿 있으면 에이전트가 어떤 것을 선택할지 혼란스러워합니다. 도구 수를 5개 이하로 유지하고, 각 도구의 사용 시나리오가 겹치지 않도록 설계해야 합니다.

루프 제어와 중복 감지가 없으면 비용 폭증과 타임아웃 장애로 이어질 수 있습니다.

모니터링과 디버깅

Agentic RAG는 기존 RAG보다 관찰 가능성(Observability) 확보가 훨씬 중요합니다. 응답 품질이 저하되었을 때 원인을 파악하려면 에이전트의 추론 과정 전체를 추적할 수 있어야 합니다.

운영 환경에서 반드시 수집해야 할 지표는 다음과 같습니다. **도구 호출 횟수(Tool Call Count)**는 에이전트가 질문당 평균 몇 번의 검색을 수행하는지 보여줍니다. 이 수치가 예상보다 높으면 시스템 프롬프트나 도구 명세를 재검토해야 합니다. **검색 성공률(Retrieval Success Rate)**은 검색된 문서가 실제로 최종 응답 생성에 활용된 비율입니다. 이 비율이 낮으면 인덱스 품질이나 검색 전략을 개선해야 합니다. **에이전트 오류율(Agent Error Rate)**은 루프 내에서 도구 호출 실패, JSON 파싱 오류, 타임아웃이 발생한 비율입니다.

분산 추적 시스템(예: OpenTelemetry)과 연동하여 에이전트의 각 도구 호출을 별도의 스팬(Span)으로 기록하면, 레이턴시 병목 구간을 정밀하게 파악할 수 있습니다.

확장과 마이그레이션

기존 RAG 시스템을 Agentic RAG로 마이그레이션할 때는 점진적 전환 전략이 안전합니다. 모든 트래픽을 한 번에 전환하지 않고, 카나리(Canary) 배포 방식으로 복잡한 질문 유형부터 적용합니다.

질문 복잡도를 자동으로 분류하는 라우터(Router) 레이어를 추가하면 비용을 효과적으로 제어할 수 있습니다. 단순 질문은 기존 RAG로, 복잡한 질문은 Agentic RAG로 라우팅합니다. 이 라우터 자체도 간단한 분류 LLM 또는 규칙 기반 분류기로 구현할 수 있습니다.

라우터를 통한 선택적 적용은 Agentic RAG의 비용 문제를 실질적으로 해결하는 핵심 설계입니다.

규모가 커질수록 벡터 DB의 파티셔닝 전략도 중요해집니다. 모든 문서를 단일 인덱스에 넣으면 검색 시 불필요한 문서까지 조회 대상에 포함되어 품질이 저하됩니다. 도메인이나 문서 유형별로 인덱스를 분리하고, 에이전트가 적절한 인덱스를 선택하도록 도구 명세에 반영하면 검색 정밀도를 높일 수 있습니다.

맺음말

핵심 요약

Agentic RAG는 검색 판단 권한을 에이전트에게 위임함으로써 기존 RAG의 세 가지 한계 — 불필요한 검색, 단일 검색의 불충분함, 검색 품질 평가 부재 — 를 구조적으로 해결합니다. 에이전트는 질문을 분석하여 검색 여부를 결정하고, 적합한 검색 전략을 선택하며, 결과의 품질을 평가하여 필요하면 재검색합니다. 이 과정에서 LLM의 추론 능력이 파이프라인의 중심에 놓이게 됩니다.

구현 관점에서는 도구 명세의 품질이 시스템 전체 성능을 좌우합니다. 각 도구의 사용 시나리오를 명확히 정의하고, 중복을 최소화하며, "언제 사용하지 않아도 되는지"까지 명시하는 것이 핵심입니다. 운영 관점에서는 루프 제어, 비용 모니터링, 복잡도 기반 라우팅이 안정적인 서비스를 위한 필수 요소입니다.

적용 판단 기준

Agentic RAG 도입을 고려할 때 가장 먼저 스스로에게 물어야 할 질문은 "우리 시스템에 들어오는 질문의 복잡도 분포는 어떻게 되는가?"입니다. 단순 사실 조회가 80% 이상이라면 기존 RAG가 비용 효율 면에서 더 나은 선택입니다.

반면 다음 조건 중 두 가지 이상에 해당한다면 Agentic RAG의 도입을 적극 검토할 만합니다. 첫째, 여러 데이터 소스를 조합해야 하는 복합 질문이 자주 발생한다. 둘째, LLM 자체 지식으로 충분히 답할 수 있는 질문의 비율이 30% 이상이다. 셋째, 검색 결과의 관련도가 낮아 응답 품질 문제가 지속적으로 발생하고 있다. 넷째, 사용자가 보고서나 분석 결과 수준의 심층 응답을 기대한다.

레이턴시와 비용 증가는 분명한 단점이지만, 질문 복잡도에 따른 동적 라우팅과 적절한 캐싱 전략으로 실제 운영 비용을 기존 RAG 대비 1.5-2배 수준으로 유지할 수 있습니다. 도입 전 소규모 파일럿 테스트를 통해 실제 질문 분포와 에이전트 행동 패턴을 측정하는 것이 리스크를 줄이는 가장 현실적인 방법입니다.