2026년 2월 기준: Agentic RAG로 “자율적 정보 검색 에이전트” 만드는 법 (설계 원리부터 코드까지)

게시 2026/02/13

By Daewook Kwon

10 분읽는 시간

들어가며

전통적인 RAG는 보통 (질문 → 검색 → 컨텍스트 주입 → 답변) 이라는 “고정 파이프라인”입니다. 하지만 실제 서비스에서는 사용자의 질문이 매번 동일한 검색 전략을 요구하지 않습니다. 어떤 질문은 검색 없이도 답할 수 있고, 어떤 질문은 재질문(query rewrite) 이나 하위 질문 분해(sub-questions), 혹은 검색 결과 검증/반성(reflection) 이 필요합니다.

여기서 등장하는 것이 Agentic RAG입니다. LLM이 “답변”만 생성하는 게 아니라, 상황에 따라 검색을 할지 말지, 어떤 키워드로, 몇 번 더, 어떤 소스가 신뢰할만한지를 스스로 결정하는 자율 에이전트 루프를 갖습니다. LangGraph는 이런 “상태 기반 그래프/루프”로 retrieval agent를 구성하는 튜토리얼을 공식 문서로 제공하고 있고, LlamaIndex 역시 routing/plan/agent loop를 “agentic strategies”로 체계화해 두었습니다. (docs.langchain.com)
또한 2025년 이후 OpenAI는 Responses API의 built-in tools(web search, file search, remote MCP 등) 및 Agents SDK를 통해 에이전트 구현/관찰을 표준화하는 흐름을 강화했습니다. (openai.com)

🔧 핵심 개념

1) Agentic RAG 정의

RAG: 외부 지식(문서/웹/DB)을 검색해 LLM 입력에 주입.
Agentic RAG: RAG를 “단계적 워크플로우”가 아니라, 에이전트가 도구(tool) 로 검색기를 쓰면서 필요할 때만 검색/재검색/요약/검증을 반복하는 구조.

LangGraph 문서가 말하는 retrieval agent의 핵심은 “LLM이 retriever tool을 쓸지, 그냥 답할지 결정한다”는 점입니다. (docs.langchain.com)

2) 자율적 정보 검색 에이전트의 내부 루프(상태 머신 관점)

자율 에이전트는 보통 아래 상태(state)를 가집니다.

State: messages(대화), plan(검색 계획), context(검색 결과), citations(출처), retries(재시도 횟수)
Nodes(그래프 노드)
1. Decide: 검색 필요성 판단 (no-retrieval vs retrieval)
2. Retrieve: vectorstore/web/file search 수행
3. Synthesize: 컨텍스트 기반 답변 생성
4. Verify/Reflect: 근거 부족/모순 여부 검사 → 필요 시 Retrieve로 루프

LlamaIndex도 routing, query transformation, reflection 같은 “agentic ingredients”를 개념적으로 정리합니다. (docs.llamaindex.ai)

3) Tooling 트렌드(2026년 2월 관점)

OpenAI Responses API는 모델 응답 생성 중 web_search / file_search / remote MCP 같은 도구를 붙여 “모델이 알아서 호출”하게 할 수 있습니다. (platform.openai.com)
Agents SDK는 agent, handoff, guardrails, tracing(관찰 가능성)을 중심으로 멀티 에이전트 오케스트레이션을 쉽게 만듭니다. (openai.com)
운영 관점에선 “에이전트가 목표를 달성했는가”를 평가해야 하는데, RAGAS는 Agent Goal Accuracy 같은 agentic metric을 제공합니다. (docs.ragas.io)

💻 실전 코드

아래 예제는 “Agentic RAG 자율 검색 에이전트”의 최소 단위를 (1) 검색 필요성 판단 → (2) retrieval tool 호출 → (3) 답변 → (4) 간단 검증 후 재검색 루프로 구현합니다.
LangGraph로도 동일한 상태 그래프를 만들 수 있지만, 여기선 2026년 실무에서 많이 쓰는 “tool 기반 자율 호출” 감각을 보여주기 위해 OpenAI Responses API의 built-in tool(web_search) 를 사용합니다. (서비스에서는 web_search 대신 vectorstore/file_search로 대체하면 됩니다.) (platform.openai.com)

  
# python
# 실행 전:
#   pip install openai
#   export OPENAI_API_KEY=...

from openai import OpenAI

client = OpenAI()

MODEL = "gpt-5"  # 문서 예시 기준: Responses API에서 tools 사용 가능 ([platform.openai.com](https://platform.openai.com/docs/guides/tools/file-search?utm_source=openai))

def agentic_rag(query: str, max_loops: int = 2) -> str:
    """
    Agentic RAG 핵심:
      - 모델이 '검색이 필요하면' web_search tool을 호출
      - 검색 결과를 바탕으로 답변을 합성
      - 불확실하면 재검색 루프(간단한 self-check)
    """
    messages = [
        {
            "role": "system",
            "content": (
                "You are an agentic RAG assistant.\n"
                "Decide whether to use web_search based on the question.\n"
                "If you use web_search, cite key sources succinctly.\n"
                "If evidence is weak, refine the query and search again.\n"
            )
        },
        {"role": "user", "content": query}
    ]

    last_output_text = ""
    for step in range(max_loops):
        # tools에 web_search를 넣으면 모델이 필요 시 자동 호출 가능 ([platform.openai.com](https://platform.openai.com/docs/guides/tools/file-search?utm_source=openai))
        resp = client.responses.create(
            model=MODEL,
            tools=[{"type": "web_search"}],
            input=messages
        )

        answer = resp.output_text
        last_output_text = answer

        # --- 매우 단순한 검증 로직(실무에서는 별도 verifier 모델/규칙 추천) ---
        # "근거 부족" 신호가 있으면 재검색 루프로 유도
        needs_retry = any(s in answer.lower() for s in [
            "i'm not sure", "unclear", "insufficient", "cannot verify", "not enough information"
        ])

        if not needs_retry:
            return answer

        # 재검색을 위한 query refinement 힌트 추가
        messages.append({
            "role": "user",
            "content": (
                "Refine the search query to be more specific (add time range, key terms, official docs). "
                "Then search again and answer with stronger evidence."
            )
        })

    return last_output_text


if __name__ == "__main__":
    print(agentic_rag("2026년 2월 기준 Agentic RAG 자율 에이전트를 구현할 때 핵심 아키텍처와 모범 사례는?"))

핵심 포인트는 tools=[{"type":"web_search"}]처럼 “검색 도구를 장착”해두고, LLM이 Decide/Retrieve를 자율적으로 수행하게 만드는 것입니다. (같은 패턴으로 file_search를 붙이면 “내 문서 기반 Agentic RAG”가 됩니다.) (platform.openai.com)

⚡ 실전 팁

1) 검색을 ‘항상’ 하지 말고, “검색 트리거”를 설계하라
LangGraph가 강조하는 가치가 바로 “retriever tool을 쓸지 말지 결정”입니다. 토큰/지연시간 최적화에도 직결됩니다. (docs.langchain.com)

예: “정의/개념” 질문은 검색 없이, “최신/비교/수치/정책” 질문은 검색 강제

2) Query Transformation은 성능을 급격히 올린다
LlamaIndex가 agentic strategies로 분류한 것처럼, routing + query rewrite + sub-questions는 “에이전트다움”을 만드는 핵심 부품입니다. (docs.llamaindex.ai)

예: 사용자의 질문이 넓으면 “하위 질문 3개 생성 → 각각 검색 → 합성”

3) 관찰 가능성(Tracing) 없이는 디버깅이 불가능
에이전트는 내부적으로 tool call과 루프가 발생하므로, “왜 검색했는지/왜 실패했는지”가 로그로 남아야 합니다. OpenAI는 Agents SDK에서 tracing/observability를 강조합니다. (openai.com)

4) 평가(Evaluation)를 RAG에서 Agent로 확장하라
정확도만 보면 “검색을 많이 해서 그럴듯한 답”이 좋아 보일 수 있습니다. 에이전트는 목표 달성 여부가 중요하고, RAGAS의 Agent Goal Accuracy 같은 지표가 이를 겨냥합니다. (docs.ragas.io)

🚀 마무리

Agentic RAG의 본질은 “RAG 파이프라인을 에이전트 루프로 바꾸는 것”입니다. 즉, 검색은 옵션이고 에이전트는 상태/계획/도구/검증을 통해 스스로 정보 탐색을 최적화합니다. LangGraph는 retrieval agent를 그래프 기반으로 구현하는 표준 레퍼런스를 제공하고, LlamaIndex는 routing/plan/reflect 같은 agentic 구성요소를 체계화했습니다. (docs.langchain.com)
또한 OpenAI Responses API/Agents SDK는 web_search, file_search, remote MCP 같은 도구와 tracing을 묶어 “운영 가능한 에이전트”로 가는 길을 넓혔습니다. (platform.openai.com)

다음 학습 추천:

LangGraph로 Decide→Retrieve→Synthesize→Reflect 상태 머신을 직접 구성해보기 (docs.langchain.com)
OpenAI file_search로 사내 문서 기반 “내부 지식 Agentic RAG” 만들기 (platform.openai.com)
RAGAS로 agentic workflow 평가 파이프라인 붙이기 (docs.ragas.io)

AI, Agent

ai agent trend 2026-02