RAG vs Agentic RAG 정리

RAG vs Agentic RAG 정리

1. 한 줄 차이

RAG

• 사용자의 질문이 들어오면
• 검색 시스템이 관련 문서를 찾아오고
• 그 결과를 LLM에 붙여서 답하게 하는 방식

Agentic RAG

• 단순 검색만 하지 않고
• 에이전트가 계획을 세우고, 필요한 도구를 선택하고, 여러 소스를 순차적으로 탐색한 뒤
• 더 능동적으로 답을 만드는 방식

---

2. 기본 RAG 구조

이미지 상단의 흐름은 거의 이렇게 보면 됩니다.

동작 흐름

1. 사용자가 질문 입력
2. 서버가 질문을 검색 시스템에 전달
3. Search가 지식 소스에서 관련 정보 가져옴
   • PDF
   • Database
   • Documents
   • Code
   • Web Search
   • API
4. 검색 결과를 서버가 받음
5. 서버가 원래 질문 + 검색된 문맥을 합쳐서 LLM에 전달
6. LLM이 최종 답변 생성

특징

• 구조가 단순함
• 빠르고 구현이 쉬움
• 질문 1개 → 검색 1번 → 답변 1번 같은 흐름에 적합
• 정적인 문서 검색형 QA에 강함

한계

• 검색 전략이 고정적임
• 질문이 복잡하면 스스로 중간 계획을 세우지 못함
• “먼저 뭐를 찾고, 그다음 어떤 도구를 써야 하는지”를 능동적으로 판단하는 능력이 약함

---

3. Agentic RAG 구조

이미지 하단은 단순 검색이 아니라 중간에 에이전트 레이어가 들어간 구조입니다.

동작 흐름

1. 사용자가 질문 입력
2. Aggregator Agent가 질문을 받음
3. 에이전트가 먼저 Plan(계획) 수립
   • ReAct
   • CoT
   • Planning
4. 필요한 작업을 여러 하위 Agent에게 분배
5. 각 Agent가 MCP 서버나 외부 도구를 통해 정보 수집
   • Local Data
   • Local Data Sources
   • Search Engine
   • Web Search
   • Cloud Engine
   • AWS & Azure
6. 필요한 경우 Memory
   • Short Term
   • Long Term
     를 활용해 문맥 보강
7. 모은 정보를 통합해서 최종 응답 생성

---

4. Agentic RAG의 핵심 요소

4-1. Aggregator Agent

중앙 조정자 역할입니다.

하는 일:

• 질문 해석
• 작업 분해
• 어떤 도구를 쓸지 결정
• 어떤 에이전트에게 맡길지 결정
• 결과를 합쳐 최종 응답 생성

즉, 단순 서버가 아니라 오케스트레이터에 가깝습니다.

---

4-2. Planning

기본 RAG와 가장 큰 차이 중 하나입니다.

예를 들어 질문이:

• “최신 시장 동향 찾아서 요약하고,
• 내부 문서랑 비교하고,
• 누락된 리스크도 정리해줘”

이런 식이면 Agentic RAG는:

1. 최신 웹 검색
2. 내부 문서 조회
3. 비교 분석
4. 리스크 정리

이렇게 중간 단계를 나눠서 처리할 수 있습니다.

---

4-3. Multi-Agent

Agent 1, 2, 3 같은 여러 작업 단위를 둘 수 있습니다.

예:

• Agent 1: 내부 문서 검색
• Agent 2: 웹 검색
• Agent 3: 클라우드/API 질의
• Aggregator: 결과 종합

즉, 병렬 처리 + 역할 분담이 가능합니다.

---

4-4. Memory

Agentic RAG는 메모리를 붙이기 쉽습니다.

Short-term memory

• 현재 대화 안에서 방금 찾은 정보
• 중간 추론 결과
• 직전 도구 호출 결과

Long-term memory

• 사용자 선호
• 반복적으로 쓰는 프로젝트 맥락
• 과거 작업 이력

이 덕분에 단순 “문서 검색기”가 아니라
점점 상황을 기억하는 작업형 시스템으로 확장됩니다.

---

4-5. MCP / Tool Use

이미지에서는 MCP Servers가 외부 실행 계층처럼 보입니다.

의미는 대체로:

• 단순 문서 검색뿐 아니라
• 로컬 데이터, 검색엔진, 웹, 클라우드 서비스, 각종 API 같은
• 실행 가능한 도구들에 접근할 수 있다는 것

즉 Agentic RAG는
“검색해서 붙여주는 시스템”을 넘어서
도구를 실제로 쓰는 시스템으로 발전합니다.

---

5. 둘의 차이를 표처럼 보면

기본 RAG

• 중심: 검색 + 문맥 주입
• 흐름: 단일 패스
• 판단: 거의 없음
• 도구 사용: 제한적
• 메모리: 보통 없음 또는 약함
• 적합한 작업: 문서 QA, FAQ, 단순 검색 응답

Agentic RAG

• 중심: 계획 + 검색 + 도구 실행 + 통합
• 흐름: 다단계
• 판단: 에이전트가 수행
• 도구 사용: 적극적
• 메모리: 단기/장기 확장 가능
• 적합한 작업: 복합 조사, 자동화, 멀티스텝 문제 해결

---

6. 언제 무엇을 쓰면 좋은가

RAG가 맞는 경우

• 사내 문서 검색 챗봇
• 고객지원 FAQ
• 메뉴얼 기반 질의응답
• 속도와 단순성이 중요한 경우

Agentic RAG가 맞는 경우

• 질문이 여러 단계로 나뉘는 경우
• 검색 외에 API 호출, DB 조회, 웹 탐색이 필요한 경우
• 사용자별 문맥 기억이 중요한 경우
• 조사 → 비교 → 판단 → 정리 같은 워크플로우가 필요한 경우

---

7. 실무 관점에서 더 현실적으로 보면

많은 서비스는 사실 아래처럼 갑니다.

1단계

기본 RAG

• 벡터 검색
• 문서 chunking
• reranking
• answer synthesis

2단계

Tool-augmented RAG

• 검색 + API 호출
• 검색 실패 시 웹 검색 fallback
• citation 정리

3단계

Agentic RAG

• planner
• retriever agent
• tool agent
• memory
• evaluator / verifier

즉 처음부터 무조건 Agentic으로 가기보다,
대부분은 RAG → 도구 결합 → 에이전트화 순서로 진화합니다.

---

8. 이 이미지의 핵심 메시지

이 그림이 말하는 본질은 딱 이겁니다:

RAG는 "찾아서 넣어주는 구조"이고,
Agentic RAG는 "생각하고, 나누고, 도구를 써서, 종합하는 구조"다.

---

9. 아주 짧게 다시 요약

RAG

질문 → 검색 → 문맥 추가 → LLM 답변

Agentic RAG

질문 → 계획 → 여러 에이전트/도구 사용 → 메모리 활용 → 결과 통합 → 답변