RAG 아키텍처 발전사 4편 - Agentic RAG: 에이전트가 파이프라인을 설계한다

이 글은 RAG 아키텍처 발전사 시리즈의 다섯 번째이자 마지막 편입니다. 1편에서 Naive RAG의 단순한 Retrieve → Read 파이프라인으로 출발하여, 2편에서 Hybrid Search와 Reranker로 검색 품질을 높이고, 3편에서 Self-RAG와 CRAG로 자기 성찰과 교정 능력을 도입했으며, 4편에서 Ontology-Enhanced RAG로 도메인의 형식적 지식을 파이프라인에 심는 과정까지 살펴보았습니다. 이번 편에서는 그 여정의 2026년 3월 기준 현재 도달점인 4세대 Agentic RAG를 다룹니다.

---

정적 파이프라인의 한계

이 시리즈를 관통하는 하나의 흐름이 있습니다. 각 세대는 이전 세대의 명확한 한계에 대한 응답으로 등장했고, 그 한계의 상당 부분은 파이프라인이 사전에 설계된 정적 흐름에 의존한다는 구조적 특성에서 비롯되었습니다.

Self-RAG의 Reflection Token은 고정된 비평 순서를 따릅니다. CRAG의 Retrieval Evaluator는 신뢰도 수준에 따른 분기로 판정합니다. Adaptive-RAG의 분류기는 사전 정의된 복잡도 구분에 의존합니다. Modular RAG는 모든 기법을 독립 모듈로 분해하는 프레임워크를 제시했지만, 어떤 모듈을 어떤 순서로 조합할지는 여전히 설계자의 사전 판단에 맡겨져 있었습니다.

이 모든 경우에서 파이프라인의 흐름은 설계 시점에 결정됩니다. 실행 중에 예상치 못한 상황이 발생했을 때(예를 들어 검색 결과가 예상과 다른 형태이거나, 질의가 처음 보는 유형이거나, 중간 추론 결과에 따라 검색 전략을 바꿔야 할 때) 파이프라인 자체를 동적으로 재구성하는 것은 불가능했습니다.

4세대 Agentic RAG의 핵심 전환은 이 지점에서 발생합니다. "사전 설계된 파이프라인"에서 "에이전트가 실행 중에 자율적으로 계획을 수립하고 도구를 선택하는 동적 시스템"으로의 이동입니다.

---

 

에이전트가 파이프라인의 중심에 서다

Singh et al. (2025, arXiv:2501.09136)이 발표한 "Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG"는 이 새로운 패러다임을 체계적으로 정리한 서베이 논문입니다. 이 논문에 따르면, Agentic RAG는 자율 AI 에이전트를 RAG 파이프라인에 내장하여, 이전 세대의 모든 기법을  "도구(tool)"로 활용하면서 질의의 특성에 따라 검색 전략, 도구, 추론 경로를 자율적으로 결정하는 시스템입니다.

이전 세대들에서 벡터 검색, KG 검색, Reranker, 웹 검색, Text-to-SQL 등은 각각 독립적인 기법이나 파이프라인의 고정된 구성요소였습니다. Agentic RAG에서 이것들은 에이전트가 상황에 따라 선택할 수 있는 도구 목록의 항목이 됩니다. 어떤 도구를 언제 어떤 순서로 사용할지를 사전에 정하는 것이 아니라, 에이전트가 질의를 분석하고, 계획을 세우고, 도구를 실행하고, 결과를 평가하며, 필요하면 계획을 수정하는 전체 과정을 자율적으로 수행합니다.

---

 

네 가지 에이전틱 디자인 패턴

Singh et al. (2025)은 Agentic RAG의 동작 방식을 네 가지 디자인 패턴으로 분류합니다.

Reflection - 스스로 평가하고 반복적으로 개선한다

Reflection 패턴은 에이전트가 자신의 생성 결과를 스스로 평가하고, 만족스럽지 않으면 개선하여 재생성하는 반복 루프입니다. 3세대에서 다룬 Self-RAG의 Reflection Token과 유사한 목적을 가지고 있지만, 메커니즘에서 근본적인 차이가 있습니다.

Self-RAG에서 자기 평가는 사전 학습된 특수 토큰의 출력 확률로 수행됩니다. 이 토큰들의 의미와 평가 기준은 학습 시점에 고정됩니다. 반면 Agentic RAG의 Reflection에서는 에이전트가 프롬프트 기반으로 자기 평가를 수행합니다. "이 답변이 질의에 충분히 답하고 있는가?", "근거가 충분한가?", "빠진 관점은 없는가?"와 같은 평가 기준을 상황에 맞게 유연하게 적용할 수 있습니다. 평가 기준 자체가 질의의 특성이나 도메인에 따라 달라질 수 있다는 점이 핵심적인 차이입니다.

만족스럽지 않다고 판단되면 에이전트는 추가 검색을 수행하거나, 다른 도구를 사용하거나, 쿼리를 재구성하여 답변을 개선합니다. 이 과정은 품질 기준을 충족할 때까지 반복됩니다.

Planning - 복잡한 질의를 하위 태스크로 분해한다

Planning 패턴은 복잡한 질의를 에이전트가 여러 하위 태스크로 분해하고, 각 태스크의 실행 순서와 방법을 계획하는 것입니다. 이전 세대에서 Adaptive-RAG가 질의 복잡도에 따라 검색 전략을 선택했다면, Planning 패턴은 각 단계를 에이전트가 직접 설계합니다.

예를 들어 "2024년 한국 반도체 수출이 전년 대비 증가한 주요 원인을 미·중 무역갈등 관점에서 분석하라"는 질의를 생각해볼 수 있습니다. 이 질의에 답하려면 2024년 수출 통계, 2023년 비교 데이터, 미·중 무역 정책 변화, 한국 반도체 기업의 대응 전략 등 여러 종류의 정보가 필요합니다. Planning 패턴에서 에이전트는 이 질의를 하위 태스크로 분해하고(수출 데이터 검색, 정책 변화 검색, 기업 전략 검색) 각 태스크에 적합한 검색 전략을 독립적으로 결정한 뒤, 결과를 종합하여 최종 답변을 구성합니다.

Tool Use - 상황에 맞는 도구를 동적으로 선택한다

Tool Use 패턴은 에이전트가 가용한 도구 목록에서 질의에 가장 적합한 도구를 동적으로 선택하여 실행하는 것입니다. 이것이 Agentic RAG가 이전 세대의 모든 기법을 통합하는 핵심 메커니즘입니다.

벡터 검색, Knowledge Graph 검색, Text-to-SQL, 웹 검색, 계산기, 코드 실행기, 이전 세대에서 각각 독립적인 파이프라인이나 모듈이었던 것들이 에이전트의 도구 상자에 들어갑니다. 에이전트는 질의의 특성을 분석하여, 정형 데이터가 필요하면 Text-to-SQL을, 최신 정보가 필요하면 웹 검색을, 도메인 지식의 구조적 탐색이 필요하면 KG 검색을 선택합니다. 하나의 질의에 여러 도구를 순차적으로 또는 병렬로 사용할 수도 있습니다.

3.5세대에서 다룬 온톨로지도 여기서 하나의 도구가 됩니다. 에이전트가 의료 도메인의 질의를 처리할 때 SNOMED CT 온톨로지 기반 검색을 도구로 선택하고, 필요하면 벡터 검색 결과와 결합하는 식입니다. 온톨로지의 활용 여부와 방법이 사전에 고정되는 것이 아니라, 에이전트가 상황에 따라 판단합니다.

Multi-Agent Collaboration - 전문 에이전트들이 협업한다

Multi-Agent Collaboration 패턴은 하나의 범용 에이전트가 모든 것을 처리하는 대신, 검색 전문 에이전트, 추론 전문 에이전트, 검증 전문 에이전트 등 역할이 특화된 에이전트들이 공유 워크스페이스에서 협업하는 구조입니다.

각 에이전트는 자신의 전문 영역에서 최적화된 판단을 내리고, 그 결과를 공유 워크스페이스에 기록합니다. 검색 에이전트가 가져온 문서를 추론 에이전트가 분석하고, 추론 결과를 검증 에이전트가 사실 확인하는 식입니다. 이 패턴은 단일 에이전트의 능력 한계를 전문화와 협업으로 극복하려는 접근입니다.

---

세 가지 아키텍처 변형

Singh et al. (2025)은 Agentic RAG 아키텍처의 상세한 분류 체계(taxonomy)를 제시합니다. 참고 문서에 기반하여 정리하면, 에이전트의 구성 방식에 따라 다음과 같은 변형들이 구분됩니다.

Single-Agent RAG는 하나의 중앙 에이전트가 라우터이자 추론기 역할을 겸합니다. 이 에이전트가 질의를 받아 분석하고, Text-to-SQL, 시맨틱 검색, 웹 검색, 추천 시스템 등 가용한 도구 중 적합한 것을 선택하여 실행하고, 결과를 합성하여 답변을 생성합니다. 구현이 상대적으로 단순하고 오케스트레이션 오버헤드가 낮지만, 단일 에이전트의 판단 능력과 컨텍스트 윈도우에 의존한다는 제약이 있습니다.

Multi-Agent RAG는 코디네이터 에이전트가 SQL Agent, Semantic Agent, Web Agent, Domain Agent 등 전문 에이전트에게 태스크를 분배하고, 각 에이전트의 결과를 LLM이 합성하는 구조입니다. 각 에이전트가 자신의 전문 영역에 최적화될 수 있어 복잡한 질의에 대한 대응력이 높지만, 에이전트 간 통신과 결과 통합의 복잡도가 증가합니다.

Hierarchical Agentic RAG는 전략 에이전트(Strategic Agent), 슈퍼바이저 에이전트(Supervisor Agent), 워커 에이전트(Worker Agent)로 구성된 계층적 위임 구조입니다. 전략 에이전트가 전체 태스크의 우선순위와 방향을 결정하고, 슈퍼바이저가 하위 태스크를 관리하며, 워커가 실제 검색과 생성을 수행합니다. 대규모의 복잡한 태스크에 적합하지만, 계층 간 통신 지연과 설계 복잡도가 가장 높습니다.

---

RAG 진화의 전체 경로

Singh et al. (2025)은 RAG의 진화 경로를 Naive RAG → Advanced RAG → Modular RAG → Graph RAG → Agentic RAG로 제시합니다. 이 시리즈에서 다룬 전체 세대와 매핑하면 다음과 같은 그림이 완성됩니다.

1세대 Naive RAG는 단일 Dense Retriever로 Top-k 청크를 검색하고 LLM에 전달하는 Retrieve → Read 파이프라인이었습니다. 검색 품질에 전적으로 의존하는 구조의 한계가 2세대 Advanced RAG를 촉발했고, Hybrid Search, Reranker, RAPTOR, Tree RAG가 검색 커버리지, 정밀도, 구조적 깊이를 각각 보강했습니다. 그러나 각 단계가 독립적으로 발전하면서 통합과 자기 교정의 부재가 드러났고, 이것이 3세대 Modular/Self-Corrective RAG의 등장 배경이 되었습니다. Self-RAG, CRAG, Adaptive-RAG, Graph RAG, Modular RAG가 자기 성찰, 교정, 적응적 라우팅, 구조적 검색, 모듈화를 도입했습니다. 이 세대가 도메인의 구조적 지식을 명시적으로 반영하지 못한다는 한계는 3.5세대 Ontology-Enhanced RAG로 이어졌고, OG-RAG, KG-RAG, KG2RAG가 형식적 온톨로지를 파이프라인에 통합했습니다. 마지막으로, 이 모든 세대의 기법이 여전히 사전 설계된 정적 파이프라인에 머물러 있다는 한계가 4세대 Agentic RAG를 낳았습니다.

각 세대가 이전 세대의 한계를 정확히 짚고 그에 대한 해법을 제시하는 이 연쇄적 발전은, 하나의 방향을 향해 수렴하고 있습니다. 파이프라인의 자율성과 유연성을 높이는 것, 다시 말해 RAG 시스템이 더 많은 것을 스스로 판단하고 결정할 수 있도록 만드는 것입니다.

---

아직 열려 있는 과제들

Agentic RAG가 RAG 발전의 현재 도달점이라고 해서, 모든 문제가 해결된 것은 아닙니다. 오히려 에이전트 기반 접근이 도입되면서 새로운 차원의 과제들이 등장했습니다.

오케스트레이션의 복잡도가 첫 번째 과제입니다. Multi-Agent나 Hierarchical 아키텍처에서 에이전트 간의 통신, 태스크 위임, 결과 통합을 관리하는 것은 그 자체로 상당한 엔지니어링 과제입니다. 에이전트 수가 늘어날수록 통신 경로가 기하급수적으로 증가하고, 에이전트 간의 충돌이나 중복 작업을 방지하기 위한 조율이 필요합니다.

지연 시간(latency)도 무시할 수 없습니다. 에이전트가 질의를 분석하고, 계획을 세우고, 도구를 선택하여 실행하고, 결과를 평가하는
각 단계가 LLM 호출을 수반합니다. Multi-Agent 구조에서는 여러 에이전트가 순차적 또는 병렬로 동작하면서 각각 LLM을 호출합니다. 이 누적된 지연은 실시간 응답이 필요한 서비스에서 심각한 제약이 될 수 있습니다.

안전장치(guardrail)의 필요성은 에이전트의 자율성이 높아질수록 더 중요해집니다. 에이전트가 잘못된 판단을 내려 부적절한 도구를 선택하거나, 잘못된 추론 경로를 끝까지 밀고 나가거나, 민감한 데이터에 대해 부적절한 접근을 시도하는 상황을 방지해야 합니다. 에이전트의 자율성과 안전성 사이의 균형은 Agentic RAG의 핵심 설계 과제입니다.

재현성과 디버깅의 어려움도 있습니다. 정적 파이프라인에서는 동일한 입력이 동일한 경로를 따르므로, 문제가 발생했을 때 어디서 잘못되었는지 추적하기 비교적 수월합니다. 반면 Agentic RAG에서 에이전트는 동일한 질의에 대해서도 상황에 따라 다른 도구를 선택하고 다른 경로를 거칠 수 있습니다. 이 동적 판단 경로를 로깅하고, 문제 발생 시 재현하며, 원인을 진단하는 것은 훨씬 더 복잡한 작업입니다.

---

시리즈를 마치며

다섯 편에 걸쳐 RAG의 발전사를 정리하면서 계속 떠오른 생각이 있습니다. 이 발전의 방향이 어딘가 익숙하다는 것입니다. 단순한 규칙 기반 시스템에서 시작하여, 점점 더 많은 판단을 시스템 자체에 위임하고, 최종적으로는 자율적 에이전트에 이르는 흐름. 이것은 RAG에 국한된 이야기가 아니라, 소프트웨어 시스템 전반에서 반복되어 온 패턴이기도 합니다.

동시에, 각 세대가 이전 세대의 한계를 해결하면서 새로운 한계를 만들어냈다는 점도 인상적입니다. Naive RAG의 검색 품질 문제를 Advanced RAG가 해결하자 통합과 자기 교정의 부재가 드러났고, 그것을 Self-Corrective RAG가 해결하자 도메인 구조 지식의 미반영이 드러났으며, 그것을 Ontology-Enhanced RAG가 해결하자 정적 파이프라인의 한계가 드러났습니다. 각 세대의 해법이 다음 세대의 문제를 노출시키는 이 구조는, 기술 발전이 완성을 향한 직선이 아니라 해상도를 높여가는 나선임을 보여줍니다.

이 시리즈를 정리하면서 개인적으로 가장 유용했던 것은, 개별 기법을 단편적으로 이해하는 것이 아니라 왜 이 기법이 등장해야 했는가라는 맥락 속에서 파악하게 되었다는 점입니다. Hybrid Search가 왜 필요했는지를 알면 Dense Retrieval의 한계가 보이고, CRAG가 왜 등장했는지를 알면 Self-RAG의 한계가 보입니다. 기법 하나하나의 작동 방식을 아는 것과, 그 기법이 어떤 문제에 대한 응답인지를 아는 것은 다른 차원의 이해입니다.

RAG는 여전히 빠르게 발전하고 있는 분야입니다. Agentic RAG 이후에도 새로운 한계가 드러나고, 그에 대한 새로운 해법이 등장할 것입니다. 이 시리즈가 그 흐름을 따라가기 위한 하나의 지도 역할을 할 수 있다면 좋을 것 같습니다. 

---

References

• Singh, A., Ehtesham, A., Kumar, S., & Khoei, T. T. (2025). Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG. arXiv:2501.09136 · GitHub
• Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arXiv:2005.11401
• Gao, Y., et al. (2024). Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997
• Gao, Y., et al. (2024). Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks. arXiv:2407.21059
• Asai, A., et al. (2023). Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ICLR 2024. arXiv:2310.11511
• Yan, S.-Q., et al. (2024). Corrective Retrieval Augmented Generation. arXiv:2401.15884
• Edge, D., et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. Microsoft Research. arXiv:2404.16130
• Sharma, K., Kumar, P., & Li, Y. (2025). OG-RAG: Ontology-Grounded Retrieval-Augmented Generation for Large Language Models. EMNLP 2025. arXiv:2412.15235