Agentic RAG 개념 정리

2026-04-20

AI, Agent, Agentic RAG, LLM, RAG

Agentic RAG란

Agentic RAG는 검색(retrieval)을 고정된 단계로 실행하는 대신, 에이전트가 상황에 따라 검색 여부와 검색 방식을 스스로 결정하는 RAG 방식입니다.

기본 RAG는 보통 아래처럼 동작합니다.

사용자 질문 입력
검색 시스템에서 관련 문서 조회
검색 결과를 LLM에 넣어 답변 생성

즉, 검색은 항상 먼저 일어나고, 생성은 그 다음에 일어납니다.

반면 Agentic RAG는 조금 다릅니다.

질문만 보고 바로 답할 수도 있음
먼저 검색한 뒤 추가 검색이 필요하다고 판단할 수도 있음
내부 문서 검색과 웹 검색을 나눠서 사용할 수도 있음
한 번 검색하고 끝내지 않고, 여러 번 검색/정제/도구 호출을 반복할 수도 있음

즉, Agentic RAG의 핵심은 “RAG에 agent의 의사결정 능력을 붙인 것” 입니다.

왜 필요한가

기본 RAG는 구조가 단순하고 빠르지만, 아래 같은 한계가 있습니다.

질문이 너무 단순해도 항상 retrieval을 수행함
한 번의 검색으로 부족한 경우 추가 탐색이 어려움
어떤 데이터 소스를 써야 할지 유연하게 결정하기 어려움
멀티홉 질의나 복합 질의에 약할 수 있음

예를 들어 사용자가 이렇게 물을 수 있습니다.

“우리 사내 정책상 재택근무 승인 절차가 뭐야?”
“이 정책이 작년 버전과 뭐가 달라?”
“그 변경 이유를 관련 회의록 기준으로 설명해줘”

이런 질문은 한 번 검색해서 끝나는 문제가 아니라,

정책 문서 검색
이전 버전 검색
회의록 검색
필요하면 답변 재구성

같은 여러 단계를 거칠 수 있습니다.

Agentic RAG는 이런 상황에서 에이전트가 검색 도구를 필요한 만큼 선택적으로 호출할 수 있게 합니다.

기본 아이디어

Agentic RAG는 보통 아래 요소로 구성됩니다.

LLM Agent
- 질문을 보고 다음 행동을 결정
Retriever Tools
- 벡터 검색, BM25, SQL 조회, 웹 검색, API 호출 등
Reasoning Loop
- 검색 결과를 보고 추가 검색 또는 답변 생성을 결정
Final Generation
- 수집한 컨텍스트를 바탕으로 최종 답변 생성

즉, 기본 RAG가 retrieve -> generate 라면, Agentic RAG는 아래에 가깝습니다.

질문
  ->
에이전트가 계획 수립
  ->
필요한 도구 선택
  ->
검색 / 조회 / 재검색 / 정제 반복
  ->
최종 답변 생성

기본 RAG와 비교

구분	기본 RAG	Agentic RAG
검색 시점	항상 먼저 수행	필요할 때 수행
검색 횟수	보통 1회	여러 번 가능
검색 대상	대개 하나의 retriever	여러 도구 조합 가능
제어 방식	고정된 파이프라인	에이전트 의사결정 기반
장점	단순, 빠름, 예측 가능	유연함, 복합 질의 대응
단점	복잡한 질문에 한계	비용/지연/복잡도 증가

정리하면:

단순한 문서 Q&A 에는 기본 RAG가 더 실용적일 수 있음
복합 질의, 멀티스텝 탐색, 여러 데이터 소스 결합 에는 Agentic RAG가 유리함

어떤 식으로 동작하나

예를 들어 질문이 다음과 같다고 가정해보겠습니다.

“우리 제품의 장애 대응 가이드와 최근 장애 회고 문서를 바탕으로, 공통적으로 강조하는 운영 원칙을 정리해줘.”

Agentic RAG는 아래처럼 움직일 수 있습니다.

질문 분석
- 장애 대응 가이드
- 최근 장애 회고 문서
- 공통 운영 원칙 요약
첫 번째 검색
- runbook / incident guide 검색
두 번째 검색
- postmortem / retrospective 문서 검색
검색 결과 확인
- 정보가 부족하면 추가 검색
- 오래된 문서면 최신 문서 우선 재검색
최종 답변 생성
- 두 문서군의 공통 원칙만 요약

즉, Agentic RAG는 단순히 “문서를 가져오는 시스템”이 아니라, 질문 해결을 위해 검색을 하나의 도구처럼 사용하는 시스템에 가깝습니다.

언제 잘 맞는가

Agentic RAG는 아래 같은 상황에서 특히 잘 맞습니다.

여러 소스를 넘나드는 질의
멀티홉 reasoning이 필요한 경우
한 번 검색으로 충분하지 않은 경우
질문에 따라 검색이 필요 없을 수도 있는 경우
내부 문서, DB, 웹 검색을 함께 써야 하는 경우

예:

사내 문서 + Jira + Slack + 위키를 같이 참조해야 하는 질문
정책 문서와 변경 이력을 함께 봐야 하는 질문
먼저 요약한 뒤, 부족한 부분만 다시 검색해야 하는 질문

장점

1. 검색을 더 유연하게 쓸 수 있다

검색을 무조건 한 번 실행하는 것이 아니라, 필요할 때만 호출하고 필요하면 다시 호출할 수 있습니다.

2. 복합 질의 대응력이 좋다

질문을 여러 하위 질문으로 나누고, 각 단계마다 다른 검색 전략을 적용할 수 있습니다.

3. 여러 도구를 조합할 수 있다

벡터 DB, 키워드 검색, SQL, API, 웹 검색 등을 하나의 에이전트 도구셋으로 묶을 수 있습니다.

4. 비용을 아낄 수도 있다

모든 질문에 retrieval을 수행하지 않고, 에이전트가 “이건 바로 답해도 된다”고 판단하면 검색을 건너뛸 수 있습니다.

단점과 주의점

1. 구조가 복잡해진다

기본 RAG보다 설계 요소가 많습니다.

도구 정의
에이전트 프롬프트
중간 상태 관리
재시도/루프 제어

2. latency와 비용이 늘 수 있다

검색을 여러 번 하고, 도구를 여러 개 부르면 응답 시간이 길어질 수 있습니다.

3. agent가 쓸데없는 검색을 할 수 있다

에이전트가 불필요한 도구 호출을 반복하면 비용만 증가하고 성능은 오히려 나빠질 수 있습니다.

4. 디버깅이 어려워진다

왜 특정 검색을 했는지, 왜 이 문서를 선택했는지, 왜 중간에 잘못 판단했는지 추적이 필요합니다.

즉, Agentic RAG는 성능 잠재력은 높지만 운영 난이도도 같이 올라가는 구조입니다.

간단한 예제 코드

아래 예시는 Agentic RAG의 핵심만 보여주는 단순 Python 예제입니다.

질문을 보고 검색 필요 여부 판단
필요하면 retriever tool 호출
부족하면 웹 검색 tool 추가 호출
최종 답변 생성

from dataclasses import dataclass
from typing import List


@dataclass
class Document:
    content: str
    source: str


def should_retrieve(query: str) -> bool:
    keywords = ["policy", "document", "guide", "manual", "spec", "wiki"]
    return any(keyword in query.lower() for keyword in keywords)


def retrieve_internal_docs(query: str) -> List[Document]:
    return [
        Document("Internal guide: Incident response starts with impact assessment.", "kb://incident-guide"),
        Document("Internal runbook: Communication channel must be opened within 10 minutes.", "kb://runbook"),
    ]


def web_search(query: str) -> List[Document]:
    return [
        Document("Web result: Incident management best practice emphasizes fast triage.", "web://result-1"),
    ]


def need_more_context(query: str, docs: List[Document]) -> bool:
    return len(docs) < 2 or "recent" in query.lower()


def generate_answer(query: str, docs: List[Document]) -> str:
    context = "\n".join(f"- {doc.content} ({doc.source})" for doc in docs)
    return f"""질문: {query}

참고 문서:
{context}

답변:
운영 원칙의 핵심은 빠른 영향도 파악, 초기 커뮤니케이션 채널 확보, 그리고 필요한 경우 추가 근거를 더 검색해 보강하는 것입니다.
"""


def run_agentic_rag(query: str) -> str:
    docs: List[Document] = []

    if should_retrieve(query):
        docs.extend(retrieve_internal_docs(query))

    if need_more_context(query, docs):
        docs.extend(web_search(query))

    return generate_answer(query, docs)


if __name__ == "__main__":
    print(run_agentic_rag("Summarize our incident response policy and recent best practices"))

이 코드는 매우 단순화된 버전이지만, 핵심은 보입니다.

retrieval이 무조건 실행되지 않음
한 종류의 검색으로 끝나지 않을 수 있음
중간 판단에 따라 다음 행동이 달라짐

LangChain / LangGraph 관점에서 보면

LangChain 공식 문서에서는 Agentic RAG를 에이전트가 retrieval tool을 필요 시 호출하는 구조로 설명합니다.
반면 2-step RAG는 retrieval이 항상 먼저 실행되는 고정형 파이프라인입니다.

즉, 아래처럼 이해하면 됩니다.

2-step RAG: 정해진 순서대로 검색 후 생성
Agentic RAG: 에이전트가 검색 여부와 검색 전략을 결정

실제 구현에서는 보통 아래 구성으로 나뉩니다.

retriever tool
web search tool
planner / agent node
answer generation node
필요 시 grading / reranking / query rewrite node

Agentic RAG와 CRAG의 차이

둘 다 “더 똑똑한 RAG”처럼 보이지만 초점이 다릅니다.

구분	Agentic RAG	CRAG
핵심 질문	무엇을 언제 검색할까?	검색 결과가 믿을 만한가?
중심 개념	agent의 의사결정	retrieval quality correction
검색 횟수	여러 번 가능	보통 검색 후 평가/보정
강점	복합 질의, 도구 조합	retrieval 오류 보정

즉:

Agentic RAG는 검색 전략의 유연성
CRAG는 검색 결과 품질 보정

에 더 초점이 있습니다.

한 줄 요약

Agentic RAG는 검색을 고정된 한 단계로 처리하지 않고, 에이전트가 질문 해결 과정에서 검색 도구를 동적으로 사용하는 RAG 방식입니다.

참고

LangChain Retrieval Docs: https://docs.langchain.com/oss/python/langchain/retrieval
LangChain RAG Docs: https://docs.langchain.com/oss/python/langchain/rag
LangGraph Agentic RAG Docs: https://docs.langchain.com/oss/python/langgraph/agentic-rag

딴짓하는 개발자

AIRAG