LangGraph Agentic RAG: 한 번 검색으로 끝내던 RAG가 스스로 되묻고 고치는 에이전트가 되다

RAG 튜토리얼을 보면 구조가 대부분 같습니다. 문서를 청크로 나누고, 벡터 DB에 넣고, 질문이 오면 유사한 청크를 꺼내 LLM에 전달합니다. 질문이 모호하거나, 첫 검색 결과가 부족하거나, 이전 대화 맥락이 필요한 상황에서는 그냥 통과합니다. agentic-rag-for-dummies는 이 세 가지 한계를 에이전트 루프로 해결합니다.

1. Agentic RAG for Dummies란?

agentic-rag-for-dummies는 LangGraph 기반의 Agentic RAG 레퍼런스 구현입니다.

"Most RAG tutorials show basic concepts but lack guidance on building modular, agent-driven systems — this project bridges that gap."

기본 RAG와의 차이를 한 문장으로 요약하면: 기본 RAG가 "검색-답변" 2단계 파이프라인이라면, Agentic RAG는 "이해-재작성-병렬 검색-자가 수정-압축-답변"을 루프로 연결한 상태 기계(state machine)입니다.

Notebook 기반 학습 경로와 모듈화된 프로젝트 경로 두 가지를 모두 제공해, 개념 학습과 실제 배포를 동시에 지원합니다. LLM은 Ollama(로컬)로 시작하고 Anthropic Claude, OpenAI, Google Gemini로 교체할 수 있습니다. 벡터 DB는 Qdrant를 사용합니다.

2. 왜 기본 RAG만으로는 부족한가?

질문을 이해하지 않고 검색한다

"How do I update it?"처럼 대명사를 쓴 질문을 기본 RAG에 던지면, 벡터 DB에서 "update"와 유사한 청크를 꺼냅니다. 이전 대화에서 "SQL 설치"를 논의했더라도 그 맥락은 없습니다. 결과적으로 엉뚱한 문서를 참조하거나, 사용자가 직접 맥락을 다시 설명해야 합니다.

첫 검색 결과가 부족해도 그냥 답한다

검색 결과가 관련 없거나 부족한 경우, 기본 RAG는 그대로 LLM에 전달합니다. LLM은 빈 컨텍스트로도 그럴듯한 답을 생성합니다. 즉, 문서에 없는 내용을 아는 척 답합니다.

복잡한 질문을 병렬로 처리할 수 없다

"JavaScript란 무엇이고, Python과의 차이는?"처럼 두 가지를 동시에 묻는 질문을 기본 RAG는 하나의 쿼리로 처리합니다. 두 주제를 동시에 잘 검색하기 어렵고, 결과 품질이 나빠집니다.

3. 내부 구조: 어떻게 동작하는가?

핵심 아키텍처 구성요소

계층형 인덱싱 (Hierarchical Indexing)

문서를 두 번 분할합니다. 마크다운 헤더(H1, H2, H3) 기준으로 큰 Parent Chunk를 만들고, 그 안에서 고정 크기의 작은 Child Chunk를 파생합니다. 검색은 Child Chunk의 정밀도로, 컨텍스트는 Parent Chunk의 풍부함으로 읽습니다.

문서 → H2 헤더 기준 분할 → Parent Chunk (큰 맥락 보존)
           └→ 고정 크기 분할 → Child Chunk (검색 정밀도)

쿼리 처리 4단계 워크플로우

질문 → 대화 요약 → 쿼리 재작성 → 쿼리 명료화 → 병렬 에이전트 → 집계 → 최종 답변

Stage 1 — 대화 이해: 최근 대화와 롤링 요약을 유지해 "it", "that"같은 참조 대명사를 해석합니다. 컨텍스트를 무한히 늘리지 않고 요약으로 압축합니다.

Stage 2 — 쿼리 명료화: "Tell me about that thing"처럼 불명확한 질문을 탐지하면 Human-in-the-loop으로 잠시 멈추고 사용자에게 확인을 요청합니다. 명확한 질문이면 검색에 최적화된 형태로 재작성합니다.

Stage 3 — 병렬 에이전트 검색 (Multi-Agent Map-Reduce): 복수의 sub-query가 생성되면 LangGraph의 Send API로 독립적인 에이전트 서브그래프를 병렬 실행합니다. 각 에이전트는 Child Chunk 검색 → Parent Chunk 조회 → 결과 부족 시 자가 수정 → 토큰 예산 초과 시 컨텍스트 압축 루프를 독립적으로 수행합니다.

Stage 4 — 답변 집계: 모든 에이전트의 답변을 수집해 단일 응답으로 합칩니다.

LangGraph 그래프 구조

메인 그래프와 에이전트 서브그래프가 중첩됩니다.

# 메인 그래프
START → summarize_history → rewrite_query
  → [불명확] request_clarification → rewrite_query (재진입)
  → [명확]   Send(agent_subgraph × N개) → aggregate_answers → END

# 에이전트 서브그래프 (각 sub-query마다 독립 실행)
START → orchestrator
  → [도구 필요] tools → should_compress_context
      → [임계치 초과] compress_context → orchestrator
      → [임계치 이하] orchestrator (루프)
  → [예산 소진]  fallback_response → collect_answer → END
  → [완료]       collect_answer → END

4. 컨텍스트 압축과 자가 수정

에이전트가 여러 번 도구를 호출하다 보면 메시지가 쌓입니다. 토큰이 임계값(BASE_TOKEN_THRESHOLD)을 넘으면 compress_context 노드가 지금까지의 대화를 요약으로 압축하고, 이미 검색한 Parent Chunk ID와 실행한 쿼리를 명시해 중복 검색을 방지합니다.

# 이미 실행한 검색을 추적해 중복 방지
updated_ids = state.get("retrieval_keys", set()) | new_ids

# 토큰 예산 초과 여부 판단
max_allowed = BASE_TOKEN_THRESHOLD + int(current_token_summary * TOKEN_GROWTH_FACTOR)
goto = "compress_context" if current_tokens > max_allowed else "orchestrator"

결과가 불충분하면 자동으로 쿼리를 재작성하고 재검색합니다. MAX_TOOL_CALLS와 MAX_ITERATIONS로 루프 횟수를 제한하고, 예산이 소진되면 fallback_response로 최선의 답변을 반환합니다.

5. 직접 해보기

1) Ollama 설치

ollama.com/download에서 OS에 맞는 설치 파일을 받아 설치한다.

# 설치 확인
ollama --version

2) 모델 선택 및 Pull

기본 설정(granite4.1:8b)은 공식적으로 한국어를 지원한다. 한국어 문서를 주로 다룬다면 아시아권 언어에 강점이 있는 qwen3:4b로 교체하는 것도 방법이다.

# 한국어 중심 테스트 시 (권장)
ollama pull qwen3:4b

# 기본값 유지 시
ollama pull granite4.1:8b

도구 호출(Tool Calling)이 핵심인 시스템이므로 4B 미만 소형 모델은 권장하지 않는다. 지시를 무시하거나 자가 수정 루프가 비효율적으로 작동할 수 있다.

3) 레포 클론 & 의존성 설치

git clone https://github.com/GiovanniPasq/agentic-rag-for-dummies
cd agentic-rag-for-dummies

python -m venv .venv

# macOS/Linux
source .venv/bin/activate
# Windows
.venv\Scripts\activate

pip install -r requirements.txt

4) 모델 설정 변경 (한국어 모델 사용 시)

project/config.py의 모델명 두 줄만 수정하면 된다.

# project/config.py

# 변경 전 (기본값)
LLM_MODEL = "granite4.1:8b"
JUDGE_MODEL = "ministral-3:3b-instruct-2512-q8_0"

# 변경 후 (한국어 모델)
LLM_MODEL = "qwen3:4b"
JUDGE_MODEL = "qwen3:1.7b"

JUDGE_MODEL은 evaluation.ipynb에서 RAGAS 품질 평가를 실행할 때만 쓰는 모델이다. 평가자가 자기 답변을 직접 채점하면 점수가 후해지는 편향(self-evaluation bias)을 막기 위해 메인 LLM과 다른 모델을 쓴다. python project/app.py 실행 시에는 사용되지 않으므로, 일단 테스트 목적이라면 신경 쓰지 않아도 된다.

5) 실행

python project/app.py
# → http://127.0.0.1:7860

Gradio UI에서 PDF를 업로드하고 한국어로 질문하면 된다. Notebook으로 먼저 개념을 확인하려면 Google Colab 링크를 열어 셀을 순서대로 실행한다.

6) 대화 예시

# 대화 메모리 동작
사용자: SQL 설치 방법을 알려줘
에이전트: [설치 단계 안내]
사용자: 업데이트는 어떻게 해?   ← "어떻게"가 SQL 업데이트를 의미함을 기억
에이전트: [SQL 업데이트 단계 안내]

# 쿼리 명료화 동작
사용자: 그거 좀 알려줘
에이전트: 어떤 주제를 말씀하시는 건가요?
사용자: PostgreSQL 설치 과정이요
에이전트: [PostgreSQL 설치 안내]

6. 기본 RAG vs. LangGraph Agentic RAG

한 줄 요약: 기본 RAG는 검색하고 답한다. Agentic RAG는 이해하고, 되묻고, 고치고, 병렬 처리하고, 압축하고 나서 답한다.

7. Google도 같은 길을 걷고 있다: Gemini Enterprise Agentic RAG

오픈소스 레퍼런스 구현인 agentic-rag-for-dummies가 다루는 개념은 Google Research도 동일하게 연구하고 있습니다. 2025년 Google은 Gemini Enterprise Agent Platform에 Cross-Corpus Retrieval powered by Agentic RAG를 출시했습니다.

구조 비교

두 시스템 모두 "부족하면 루프를 돌며 스스로 고친다"는 동일한 철학을 공유합니다.

Google이 추가한 것: Sufficient Context Agent

가장 눈에 띄는 차이는 Sufficient Context Agent입니다. dummies에서는 LLM이 암묵적으로 재검색 여부를 판단하는 반면, Google은 이를 독립 에이전트로 분리했습니다.

Finding: "의약품 목록과 저염식 식단 정보를 찾았습니다."
Gap:     "입원 중 알레르기 반응 정보가 없습니다."
Action:  "'발진' 또는 '이상 반응'으로 재검색하세요."

무엇이 있고 무엇이 빠졌는지를 명시적으로 식별해 피드백합니다. 덕분에 응답이 감사(audit) 가능하고 추적 가능한 구조가 됩니다. FramesQA 벤치마크에서 Vanilla RAG 대비 최대 34% 정확도 향상을 달성했습니다.

Google에는 없는 것

반대로 dummies에만 있는 기능도 있습니다.

• Human-in-the-loop 명료화: 모호한 질문을 사용자에게 되묻는 단계
• 대화 메모리: 롤링 요약으로 이전 맥락 유지
• 컨텍스트 압축: 토큰 초과 시 자동 요약

포지셔닝

2절에서 설명한 세 가지 실패 지점—모호한 질문, 부족한 검색 결과, 복잡한 쿼리—은 Google만 인식한 문제가 아닙니다. LangGraph, AWS Bedrock Knowledge Bases, Azure AI Foundry가 모두 같은 방향의 Agentic RAG 워크플로우를 공식 지원하고, Morgan Stanley(금융 리서치), PwC(세금·컴플라이언스), ServiceNow(IT 워크플로우) 같은 기업들이 이 패턴을 실제 업무에 투입하고 있습니다. GenAI를 운영 중인 기업 중 52%가 에이전트를 프로덕션에서 사용한다는 조사 결과(Google Cloud, 2025)는 이 흐름이 실험 단계를 넘어섰음을 보여줍니다.

다만 현장의 가장 큰 장벽은 여전히 응답 품질입니다. 루프가 많아질수록 잘못된 방향으로 반복될 위험도 커집니다. 단순 Q&A나 단일 문서 검색은 기본 RAG로도 충분합니다. 멀티홉 추론이 필요하거나 여러 데이터 소스를 넘나들어야 할 때—이 레포가 해결하려는 바로 그 상황—이 패턴을 설계 참고점으로 꺼내드는 것이 적절합니다.

8. 한계

로컬 모델 품질 의존도가 높다. 기본 설정이 Ollama이고 8B 이상 모델을 권장합니다. 소형 모델에서는 도구 호출 지시를 무시하거나 자가 수정 루프가 비효율적으로 작동할 수 있습니다.

튜닝 파라미터가 많다. MAX_TOOL_CALLS, MAX_ITERATIONS, BASE_TOKEN_THRESHOLD, TOKEN_GROWTH_FACTOR, k 등 민감한 파라미터가 여럿입니다. 문서 도메인이나 쿼리 유형에 따라 직접 조정이 필요합니다.

벡터 DB가 Qdrant로 고정돼 있다. 다른 벡터 DB를 사용하려면 db/ 모듈을 직접 교체해야 합니다.

공개 벤치마크가 없다. 기본 RAG 대비 성능 향상 수치는 레포에 명시적으로 제시되지 않습니다. 도메인별 직접 평가(RAGAS 노트북 활용)가 필요합니다.

9. 마치며

기본 RAG가 실패하는 지점은 대부분 비슷합니다. 질문이 모호하거나, 검색 결과가 부족하거나, 이전 대화 맥락을 모르거나, 복잡한 질문을 하나의 쿼리로 처리합니다.

LangGraph Agentic RAG는 이 네 가지 실패 지점을 에이전트 루프로 막습니다. 질문을 먼저 명료하게 만들고, 결과가 부족하면 재검색하고, 복잡한 질문은 쪼개서 병렬 처리하고, 대화 맥락은 롤링 요약으로 유지합니다.

구현 복잡도는 높습니다. LangGraph 상태 기계, Qdrant, Hierarchical Indexing, Langfuse까지 스택이 두텁습니다. 하지만 Notebook → 모듈형 프로젝트의 두 단계 학습 경로가 진입 장벽을 낮춥니다. RAG를 프로덕션에 올리기 전에, 기본 RAG가 어디서 실패하는지를 먼저 파악하는 것이 중요합니다. 이 레포는 그 실패 지점과 해결 방법을 코드로 보여줍니다.

참조

• agentic-rag-for-dummies GitHub
• LangGraph 공식 문서
• Qdrant 공식 문서
• RAGAS 평가 프레임워크
• Langfuse 관찰 가능성
• Chunky — RAG 청킹 툴킷