RAG는 이제 검색기가 아니라 검색 에이전트다
"AI가 틀린 말을 자신 있게 한다"는 그 문제
한 번쯤 이런 경험 있으시죠?
ChatGPT한테 "최신 Python 버전이 뭐야?"라고 물었더니, 아무렇지 않게 틀린 버전을 대답합니다. 심지어 굉장히 자신 있는 말투로요. 아니면 "A 회사 2024년 3분기 실적이 어때?"라고 물었을 때, 모델이 학습 데이터 마감일(cutoff) 이후의 정보는 아예 모르니까 엉뚱한 말을 늘어놓거나, 조용히 "저는 그 정보를 모릅니다"라고 발을 빼버립니다.
이게 LLM(Large Language Model, 대형 언어 모델)의 구조적인 문제입니다. 학습할 때 봤던 데이터만 알고, 그 이후의 세계는 깜깜이거든요. 게다가 학습 중에 잘못된 패턴을 익혔다면, 없는 내용을 지어내는 할루시네이션(Hallucination) 까지 발생합니다.
그래서 등장한 게 검색 증강 생성(RAG, Retrieval-Augmented Generation) 입니다. 아이디어는 단순합니다. "모델이 모르면, 외부 문서에서 찾아서 알려주면 되잖아?" LLM이 답변하기 전에 관련 문서를 검색해서 컨텍스트로 넣어주는 방식이죠.
근데 문제는... RAG도 곧 한계에 부딪혔다는 겁니다.
"그래서 Agentic RAG가 뭔데요?" 궁금하시죠? 오늘 이야기가 바로 그겁니다. RAG가 단순한 검색기(Retriever) 에서 진짜 검색 에이전트(Search Agent) 로 진화하는 과정, 그리고 그게 왜 중요한지를 같이 살펴봅시다.
① 기존 RAG: 심부름꾼 모델
심부름꾼의 하루
기존 RAG를 가장 잘 설명하는 비유는 심부름꾼입니다.
상상해보세요. 당신이 팀장이고, 보고서를 써야 합니다. 그래서 막내 직원(RAG 시스템)한테 말합니다.
"야, 창고 가서 '2024년 매출 관련 문서' 가져와봐."
막내는 창고에 가서 '2024 매출'이라는 키워드가 들어간 문서 5개를 뽑아 옵니다. 당신은 그 문서들을 보면서 보고서를 씁니다.
이게 기존 RAG의 전부입니다. 정확히는 이런 흐름이에요:
사용자 질문
↓
[Retriever] 질문을 벡터로 변환 → 유사한 문서 검색
↓
[Context 주입] 검색된 문서 + 원래 질문을 LLM에게 전달
↓
[Generator] LLM이 문서를 참고해서 답변 생성
↓
최종 답변심플하고, 효과적이었습니다. 실제로 LLM의 할루시네이션을 줄이는 데 RAG는 큰 역할을 했고, 기업 내부 문서 검색이나 고객 서비스 챗봇 같은 곳에서 널리 쓰이기 시작했죠.
근데 이 심부름꾼, 좀 멍청합니다
문제는 이 심부름꾼이 딱 시키는 것만 한다는 겁니다. 논문에서도 이 한계를 명확하게 짚고 있어요.
"Static systems suffer from context overloading, lack native correction loops for noisy retrievals, and indiscriminately retrieve regardless of input necessity."
— SoK: Agentic RAG 논문 (arXiv:2603.07379)
쉽게 풀면:
문제 1: 쿼리가 애매하면 바로 망합니다
"AI 관련 최신 동향 알려줘"라고 물어보면, 심부름꾼은 '최신 동향'이라는 키워드로 대충 검색해서 문서를 가져옵니다. 근데 그 문서가 진짜 당신이 원하는 내용인지 아닌지는 확인 안 해요. 그냥 가져오는 게 임무니까요.
문제 2: 한 번 검색으로 모든 걸 해결해야 합니다
"A 기업이 B 기업을 인수한 이후에 주가가 어떻게 됐어?"라는 질문은 사실 두 단계입니다. 먼저 인수 시점을 알아야 하고, 그다음에 그 이후 주가를 봐야 하죠. 기존 RAG는 이걸 한 방에 검색하려고 합니다. 당연히 잘 안 됩니다.
문제 3: 잘못된 문서를 가져와도 그냥 씁니다
심부름꾼이 틀린 문서를 가져왔어도, LLM은 그걸 의심 없이 씁니다. "이거 진짜 맞아?"라고 되물어보는 능력이 없거든요.
문제 4: 쿼리 재구성이 안 됩니다
처음 질문이 불명확하다는 걸 깨달아도, 기존 RAG는 그냥 원래 쿼리로 검색합니다. "어, 이 질문 좀 더 구체화해서 다시 검색해볼까?"라는 생각을 못 하는 거죠.
두 가지 기존 패러다임의 한계
A-RAG 논문(arXiv:2602.03442)은 기존 RAG를 크게 두 가지 패러다임으로 정리하고, 둘 다 한계가 있다고 말합니다:
| 패러다임 | 방식 | 한계 |
|---|---|---|
| Graph/Algorithm RAG | 그래프 구조 등 알고리즘으로 문서를 한 번에 검색해서 입력에 붙여넣기 | 모델이 검색 결정에 참여 불가, 태스크 적응 불가 |
| Workflow RAG | 미리 정해진 워크플로우를 LLM이 단계적으로 실행 | 워크플로우가 고정되어 있어 유연성 없음, 진짜 에이전트적 자율성 없음 |
핵심은 이겁니다. 두 방식 모두 LLM이 검색 결정에 진짜로 참여하지 못한다는 것. 모델은 그냥 주어진 결과를 소비할 뿐, 전략을 짜지는 않는 거죠.
② Agentic RAG: 이제 스스로 생각한다
심부름꾼에서 탐정으로
자, 이제 패러다임이 바뀝니다.
기존 RAG의 심부름꾼과 달리, Agentic RAG는 탐정에 가깝습니다. 탐정 셜록 홈즈를 생각해보세요. 그는 단서를 받으면 그냥 넘기지 않습니다. 단서를 분석하고, 다음에 어떤 증거를 찾아야 할지 계획하고, 현장에 직접 나가서 추가 조사를 하고, 때로는 처음 가설이 틀렸다는 걸 깨닫고 방향을 바꿉니다.
Agentic RAG(에이전틱 RAG)가 바로 그겁니다.
검색 결과를 받는 것 → 검색 전략을 스스로 짜는 것
이 한 문장이 전부입니다.
핵심 컴포넌트 3가지
SoK 논문은 Agentic RAG를 유한 지평 부분 관측 마르코프 결정 과정(Finite-Horizon Partially Observable Markov Decision Process, POMDP) 으로 수식화합니다. 어렵게 들리지만, 쉽게 말하면 이겁니다: "에이전트가 세상을 완전히 볼 수는 없지만, 그 상황에서 최선의 다음 행동을 결정하는 구조"라는 거예요.
이 구조를 떠받치는 핵심 컴포넌트 세 가지를 봅시다:
🧠 1. Planning (계획 수립)
기존 RAG는 질문이 들어오면 바로 검색합니다. Agentic RAG는 일단 "이 질문을 어떻게 풀지"를 먼저 생각합니다.
"논문 5편을 찾아서 비교해줘"라는 요청을 받으면:
- 어떤 순서로 검색할지
- 각 논문에서 어떤 정보가 필요한지
- 언제 검색을 멈추고 답변을 작성할지
이 모든 걸 계획하는 거죠.
🔧 2. Tool Use (도구 사용)
Agentic RAG의 LLM은 단순히 텍스트를 생성하는 게 아니라 도구를 직접 호출합니다.
A-RAG 논문에서는 실제로 세 가지 검색 도구를 모델에게 노출시킵니다:
keyword_search("검색어") → 키워드 기반 정확 검색
semantic_search("의미") → 의미 기반 유사도 검색
chunk_read("문서ID", 위치) → 특정 문서의 특정 부분 읽기이게 왜 중요하냐고요? 상황에 따라 다른 도구를 쓸 수 있기 때문입니다. 고유명사를 찾을 땐 keyword_search, 개념적 내용을 찾을 땐 semantic_search, 이미 찾은 문서에서 세부 내용을 파볼 땐 chunk_read. 심부름꾼이 "창고 가서 뭔가 가져와"를 반복하는 것과는 차원이 다르죠.
🔄 3. Self-Reflection (자기 반성)
탐정이 "어, 이 단서는 내 가설과 안 맞는데?"라고 깨닫고 방향을 트는 것처럼, Agentic RAG도 자신의 검색 결과를 평가하고 전략을 수정합니다.
"이 문서는 내가 찾던 내용이 아니네. 쿼리를 바꿔볼까?" 또는 "아직 정보가 충분하지 않으니 한 번 더 검색해야겠어" 같은 판단을 스스로 내리는 거죠.
기존 RAG vs Agentic RAG 비교표
| 항목 | 기존 RAG | Agentic RAG |
|---|---|---|
| 검색 주도권 | 알고리즘/워크플로우가 결정 | LLM 에이전트가 직접 결정 |
| 검색 횟수 | 보통 1회 (Single-shot) | 필요에 따라 반복 (Multi-step) |
| 쿼리 수정 | 불가 | 중간에 쿼리 재구성 가능 |
| 검색 타이밍 | 항상 먼저 검색 | 필요할 때만 검색 |
| 오류 수정 | 없음 | 잘못된 검색 결과 감지 후 재시도 |
| 도구 선택 | 단일 검색 방식 | 상황에 맞는 도구 선택 |
| 메모리 | 없거나 제한적 | 단기/장기 메모리 관리 |
| 복잡한 질문 | 약함 | 멀티-홉 추론 가능 |
③ 두 논문이 말하는 것
SoK 논문: 숲을 보여주는 지도
arXiv:2603.07379 논문은 Agentic RAG의 전체 지형도를 그리는 서베이(SoK, Systematization of Knowledge) 논문입니다. 연구 현황을 정리하고 분류 체계를 만드는 메타적인 작업이에요.
이 논문에서 가장 핵심적인 인사이트 세 가지를 뽑으면:
인사이트 1: Agentic RAG는 단순한 RAG 개선이 아니다
SoK 논문은 Agentic RAG를 단순히 "더 좋은 RAG"가 아니라, 완전히 다른 패러다임으로 봅니다. 핵심 차이는 제어 흐름(Control Flow) 입니다. 기존 RAG는 정적(static) 제어 흐름이고, Agentic RAG는 동적(dynamic) 제어 흐름입니다. 에이전트가 환경을 관찰하고, 상태를 업데이트하고, 다음 행동을 결정하는 반복 루프가 핵심입니다.
인사이트 2: 시스템적 위험(Systemic Risks)이 새로 생긴다
"Compounding hallucination propagation, memory poisoning, retrieval misalignment, and cascading tool-execution vulnerabilities."
Agentic RAG가 강력해질수록, 실패했을 때의 파급효과도 커집니다. 멀티-스텝으로 추론하다가 중간에 잘못된 정보를 집어넣으면, 그 오류가 다음 단계로 계속 증폭됩니다(Compounding Hallucination). 또 외부 도구를 쓰다 보니 메모리 오염(Memory Poisoning) 이나 연쇄적 도구 실행 취약점(Cascading Tool-Execution Vulnerabilities) 같은 문제도 생깁니다.
인사이트 3: 평가 방법론도 바뀌어야 한다
기존 RAG는 "최종 답변이 맞냐 틀리냐"로 평가했습니다. 하지만 Agentic RAG는 과정(Trajectory) 도 평가해야 합니다. 맞는 답을 냈더라도 검색 과정이 비효율적이었다면? 운 좋게 맞춘 건지, 진짜 잘 추론한 건지 구분해야 합니다.
A-RAG 논문: 나무를 보여주는 구현체
arXiv:2602.03442 논문은 실제로 구현한 Agentic RAG를 제시합니다. 아이디어만 이야기하는 게 아니라, "이렇게 만들었더니 이렇게 됐다"는 실증적 결과를 보여주죠.
A-RAG의 핵심 아이디어는 계층적 검색 인터페이스(Hierarchical Retrieval Interfaces) 입니다.
[거시 레벨] keyword_search / semantic_search
↓ (관련 문서 식별)
[미시 레벨] chunk_read
↓ (특정 섹션 심층 읽기)
[판단] "충분한 정보가 모였나?" → 충분하면 답변, 아니면 반복이게 왜 중요하냐면, 세상의 모든 질문이 같은 수준의 검색이 필요하지 않기 때문입니다. 간단한 사실 확인은 키워드 검색 한 번으로 충분하지만, 복잡한 멀티-홉 질문은 여러 문서를 깊이 파야 합니다. A-RAG는 이걸 모델 스스로 결정하게 합니다.
논문에서 특히 강조하는 점: 더 많이 검색한다고 좋은 게 아니다. A-RAG는 오히려 기존 방식보다 검색 토큰(Retrieved Tokens)을 비슷하거나 더 적게 쓰면서도 성능이 높습니다. 효율적인 검색 전략이 핵심이라는 거죠.
두 논문을 연결하는 시각
SoK 논문은 "왜 Agentic RAG가 필요하고, 전체 그림이 뭔지" 를 알려주고, A-RAG 논문은 "실제로 어떻게 만드는지" 를 보여줍니다. 전자는 학자의 눈으로 현황을 정리하고, 후자는 엔지니어의 손으로 실물을 만든 셈이죠.
두 논문이 공통으로 강조하는 한 가지는 이겁니다:
"LLM은 이제 검색 결과의 소비자가 아니라, 검색 과정의 오케스트라 지휘자가 되어야 한다."
④ 실제로 어떻게 달라지나 — 예시 시나리오
말로만 하면 와닿지 않으니까, 구체적인 시나리오로 비교해봅시다.
시나리오: "Transformer 아키텍처의 등장 이후 NLP 발전 흐름을 정리해줘"
이건 단순한 질문이 아닙니다. 여러 논문과 사건, 시간 흐름이 얽혀 있죠.
🤖 기존 RAG의 하루
1. "Transformer NLP 발전" 키워드로 벡터 검색
2. 유사도 높은 문서 5개 가져옴
→ 문서1: BERT 논문 요약
→ 문서2: GPT-1 소개 블로그
→ 문서3: 2019년 NLP 동향 리포트
→ 문서4: Transformer 원본 논문 초록
→ 문서5: 관련 없는 NLP 일반 소개글
3. 이 5개 문서를 다 붙여서 LLM한테 전달
4. LLM이 이 문서들을 바탕으로 답변 작성결과: 나름 그럴싸한 답변이 나올 수 있지만, 2020년 이후 GPT-3, GPT-4, LLaMA 등의 발전은 포함 안 됐을 수도 있고, 문서5처럼 관련 없는 내용이 섞여 답변이 산만해질 수 있습니다. 그리고 "어, 이거 뭔가 빠진 것 같은데" 하고 다시 검색하는 능력이 없습니다.
🕵️ Agentic RAG의 하루
[Step 1 - 계획 수립]
에이전트: "이 질문은 시간 순서가 있는 복합 질문이네.
먼저 Transformer 원본부터 찾고, 이후 발전 흐름을
연도별로 추적해야겠다."
[Step 2 - 첫 번째 검색]
→ keyword_search("Attention is All You Need 2017")
결과: Transformer 원본 논문 관련 문서 발견
[Step 3 - 심층 읽기]
→ chunk_read(문서ID, "핵심 아키텍처 섹션")
에이전트: "Self-Attention, Encoder-Decoder 구조 확인.
다음으로 이 구조가 어떻게 발전했는지 찾아야겠다."
[Step 4 - 두 번째 검색]
→ semantic_search("BERT GPT 사전학습 언어모델 발전")
결과: BERT, GPT 시리즈 관련 문서들 발견
[Step 5 - 자기 반성]
에이전트: "2017~2019년은 커버됐는데, 2020년 이후
대규모 모델(GPT-3, ChatGPT 등)이 빠졌네."
[Step 6 - 세 번째 검색]
→ semantic_search("대규모 언어모델 GPT-3 이후 트렌드")
결과: GPT-3, InstructGPT, ChatGPT 관련 내용 발견
[Step 7 - 충분성 판단]
에이전트: "2017년 Transformer부터 최근 LLM까지
타임라인이 완성됐다. 이제 답변 작성 가능."
[Step 8 - 답변 생성]
시간 흐름이 있는 구조적인 답변 작성결과: 훨씬 체계적이고, 빠진 내용 없이 발전 흐름이 정리됩니다. 검색을 세 번 했지만, 각 검색이 목적이 있고 효율적입니다.
이 차이가 단순해 보여도, 실제 프로덕션 환경에서는 엄청납니다. 법률 문서 검색, 의료 정보 조회, 기업 내부 지식 관리 같은 곳에서 "정확하고 완전한 정보를 얼마나 믿을 수 있게 가져오느냐"는 단순한 품질 문제가 아니라 신뢰의 문제이기 때문입니다.
⑤ 한계와 과제: 탐정도 가끔 틀린다
Agentic RAG가 멋지게 들리지만, 솔직하게 한계도 봐야 합니다.
⚠️ 문제 1: 느립니다
기존 RAG는 검색 1번 + 생성 1번으로 끝납니다. Agentic RAG는 계획-검색-반성-재검색을 반복하니 당연히 레이턴시(Latency, 응답 지연) 가 늘어납니다. 실시간 챗봇에서 3~5번의 검색 루프를 돌리면 사용자는 기다리다 지칩니다.
⚠️ 문제 2: 비쌉니다
멀티-스텝 추론은 LLM API 호출 횟수가 늘어난다는 의미입니다. GPT-4 같은 비싼 모델을 5번 호출하면 비용이 선형으로 늘어납니다. SoK 논문도 이걸 "Cost-Aware Orchestration"이라는 연구 방향으로 제시할 만큼 중요한 문제입니다.
⚠️ 문제 3: 오류가 증폭됩니다
앞에서도 언급했지만, 할루시네이션 복합화(Compounding Hallucination) 가 Agentic RAG만의 특이한 위험입니다. 스텝 2에서 살짝 잘못된 정보를 가져왔는데 그걸 기반으로 스텝 3, 4, 5를 진행하면, 나중에 오류를 교정하기가 엄청 어렵습니다. 마치 수학 문제 첫 번째 줄에서 계산 실수를 한 채로 끝까지 풀어가는 것처럼요.
⚠️ 문제 4: 평가가 어렵습니다
"이 에이전트가 얼마나 잘하고 있나?"를 측정하기가 기존 RAG보다 훨씬 복잡합니다. 최종 답변만 볼 게 아니라 검색 경로 전체(Trajectory)를 평가해야 하는데, 아직 표준화된 방법론이 없습니다. SoK 논문이 이걸 "Formal Trajectory Evaluation"이라는 미해결 연구 방향으로 꼽는 이유가 여기 있습니다.
그럼에도 전망은 밝습니다
이 한계들이 Agentic RAG의 가치를 부정하진 않습니다. 오히려 이게 현재 연구의 뜨거운 주제들이에요. 모델이 강해질수록(추론 능력이 좋아질수록) 검색 전략도 더 정교해지고, 비용과 속도 문제도 최적화 연구로 계속 개선되고 있습니다.
A-RAG 논문에서 특히 흥미로운 건 "모델이 커질수록 Agentic RAG의 이득이 더 크다" 는 발견입니다. 즉, 더 강한 LLM을 쓸수록 검색 전략이 더 영리해진다는 뜻이고, 앞으로 모델이 발전할수록 Agentic RAG의 가치는 더 높아진다는 거죠.
⑥ 마무리: 검색의 주도권이 바뀐다
지금까지의 여정을 한 줄로 정리하면 이겁니다:
**RAG는 "문서를 가져다주는 심부름꾼"에서, 스스로 생각하고 전략을 ## ⑥ 마무리: 검색의 주도권이 바뀐다
지금까지의 여정을 한 줄로 정리하면 이겁니다:
RAG는 "문서를 가져다주는 심부름꾼"에서, 스스로 생각하고 전략을 짜는 "검색 탐정"으로 진화하고 있다.
돌아보면 이 흐름은 AI 전반의 흐름과 정확히 일치합니다. LLM이 처음 등장했을 때는 "텍스트를 잘 생성하는 모델"이었고, 그다음엔 "도구를 쓸 수 있는 모델"이 됐고, 지금은 "스스로 계획하고 실행하는 에이전트"가 되고 있잖아요. RAG도 똑같은 길을 걷고 있는 겁니다.
개발자/학생이라면 지금 당장 생각해볼 것들
만약 여러분이 RAG 시스템을 만들고 있거나 만들 계획이 있다면, 이런 질문을 스스로 던져보세요:
"내 시스템은 검색 실패를 감지할 수 있나?"
기존 RAG로도 충분한 경우가 많습니다. 단순한 FAQ 챗봇이나, 질문이 항상 명확하고 단순한 경우라면 굳이 복잡한 Agentic RAG를 쓸 필요가 없어요. 오버엔지니어링은 언제나 나쁩니다.
하지만 이런 상황이라면 Agentic RAG를 진지하게 고려해야 합니다:
- 사용자의 질문이 복잡하고 다단계 추론이 필요할 때
- 한 번의 검색으로 충분한 컨텍스트를 가져오기 어려울 때
- 검색 결과의 신뢰도를 검증해야 할 때
- 질문의 의도가 불명확하거나 다양하게 해석될 수 있을 때
앞으로의 방향
SoK 논문이 제시하는 미래 연구 방향들을 보면, Agentic RAG가 앞으로 어디로 가는지 힌트가 보입니다:
현재 풀고 있는 문제들
├── Stable Adaptive Retrieval → 안정적인 검색 루프 설계
├── Cost-Aware Orchestration → 비용을 고려한 검색 전략 최적화
├── Formal Trajectory Evaluation → 검색 과정 자체를 평가하는 방법론
└── Oversight Mechanisms → 에이전트의 오작동을 감지/교정하는 안전장치이 네 가지가 해결되는 순간, Agentic RAG는 진짜로 프로덕션 레디(Production-Ready)한 기술이 됩니다. 그리고 그 시점이 생각보다 멀지 않을 수도 있어요. 이미 OpenAI의 Deep Research, Google의 NotebookLM 같은 제품들이 이 방향으로 움직이고 있으니까요.
핵심 메시지 하나만 가져가세요
LLM이 강해질수록, 시스템은 LLM을 파이프라인의 부품으로 쓰는 게 아니라 파이프라인의 지휘자로 써야 한다는 겁니다.
기존 RAG는 LLM 앞에 검색 결과를 갖다 놓는 방식이었습니다. Agentic RAG는 LLM에게 검색 도구를 쥐여주고 "네가 알아서 필요한 거 찾아봐"라고 합니다. 이 작은 차이가 시스템 전체의 능력을 완전히 바꿉니다.
그리고 생각해보면 이건 인간이 일하는 방식과도 닮아 있습니다. 똑똑한 연구자한테 "여기 자료 5개 있으니까 이걸로 보고서 써"라고 하는 것보다, "이 주제로 보고서 써봐, 도서관 이용권 여기 있어"라고 하는 게 훨씬 좋은 결과가 나오잖아요.
AI도 이제 그런 방식으로 일하기 시작했습니다.
다음에 ChatGPT나 다른 AI 서비스가 "잠깐, 더 찾아볼게요"라고 하면서 검색을 여러 번 돌리는 걸 보게 된다면, 이제 그게 단순한 검색이 아니라는 걸 아시겠죠? 그건 에이전트가 전략을 짜고 있는 겁니다.
참고 논문
| 논문 | arXiv ID | 역할 |
|---|---|---|
| A-RAG: Scaling Agentic Retrieval-Augmented Generation via Hierarchical Retrieval Interfaces | 2602.03442 | Agentic RAG 구현 방법론 및 실험 |
| SoK: Agentic Retrieval-Augmented Generation (RAG): Taxonomy, Architectures, Evaluation, and Research Directions | 2603.07379 | Agentic RAG 전체 분류 체계 및 연구 지형도 |
이 글이 도움이 됐다면, RAG를 실제로 구현해보고 있는 분들과 공유해주세요. 그리고 여러분이 직접 Agentic RAG를 써보면서 느낀 점이 있다면 댓글로 남겨주세요. 실제 현장에서 어떻게 쓰이는지가 항상 가장 솔직한 후기니까요. 😄
