Agentic RAG · sunshinemoon

개념

Agentic RAG는 [[RAG]]를 Agent 루프로 감싼 구조다. 검색을 한 번 돌려서 끝내지 않고, LLM이 검색 결과를 평가하고 부족하면 검색어를 바꿔 재시도한다. ReAct(Reason + Act) 패턴이라고도 부른다.

왜 필요한가

기본 RAG는 이렇게 동작한다.

질문 → 검색 → top-3 → LLM → 답변 (끝)

검색 결과가 별로여도 그걸로 답한다. 사람이 자료를 찾을 때는 "이건 아닌데?" 하고 다시 찾아보는데, 기본 RAG는 그걸 못 한다. [[RAG-한계와-보완]]에서 다룬 "검색 실패" 문제가 여기서 대부분 생긴다.

동작 예시

질문: "OAuth에서 토큰 탈취 방지하려면?"

Agent: "OAuth 검색해보자"
→ 검색 → OAuth-OIDC-SAML.md (토큰 발급 흐름만 있음)

Agent: "토큰 보호 관련이 부족한데. BFF도 검색해보자"
→ 재검색 → BFF.md (토큰을 서버에 보관하는 패턴)

Agent: "이제 충분해"
→ OAuth-OIDC-SAML.md + BFF.md로 답변 생성

기존 RAG vs Agentic RAG

	기존 RAG	Agentic RAG
검색 횟수	1번	필요한 만큼
검색어	사용자 질문 그대로	Agent가 재작성해가며
판단	없음	"충분한가?" 판단
도구	벡터 검색만	벡터, 키워드, 필터, 백링크 등 선택

ReAct 루프

Reasoning + Acting. Agentic RAG의 내부 동작.

질문 받음
  ↓
[Reason] 뭘 검색해야 하나?
  ↓
[Act] 검색 도구 호출
  ↓
[Observe] 결과가 충분한가?
  ├── 부족 → 검색어 바꿔서 다시 [Act]
  └── 충분 → 답변 생성

LLM이 각 단계를 텍스트로 적으면서 진행한다. "이 결과로는 토큰 보호 관련이 부족하다. BFF를 검색해야겠다"처럼.

Tool Use

Agent한테 도구를 줘야 한다. 하나의 검색 도구만 있으면 Agent가 할 일이 적다.

tools = {
    "vector_search": "벡터 유사도로 검색",
    "keyword_search": "키워드로 검색",
    "filter_by_tag": "특정 태그 노트에서만 검색",
    "get_backlinks": "이 노트를 참조하는 다른 노트 찾기",
}

Agent가 질문을 보고 어떤 도구를 쓸지, 몇 번 쓸지 판단한다.

단점

LLM 호출이 여러 번 → 느리고 비용 높음
Agent가 무한 루프 돌 수 있음 → 최대 반복 횟수 설정 필요
작은 로컬 LLM으로는 도구 선택 판단이 약할 수 있음

Claude Code가 Agentic RAG

Claude Code가 정확히 이 구조다.

사용자 질문 → Glob으로 파일 찾기 → Read로 코드 읽기 → 부족하면 Grep으로 재검색
→ 충분하면 답변 또는 코드 수정

도구(Read, Grep, Bash 등)를 골라가며 반복 검색하는 Agent. Claude Code의 도구가 [[MCP]] 프로토콜로 연결돼 있다.

개념