RAG + Multi Agent를 실무 구조 기준

 

핵심부터 말하면:

• RAG = 필요한 문서를 찾아서 LLM에 넣는 구조
• Multi Agent = 역할이 나뉜 여러 AI가 협업해서 결과를 만드는 구조

즉,

“문서를 잘 찾는 시스템” + “역할 분담해서 일하는 AI 시스템”
이 합쳐진 게 RAG + Multi Agent 아키텍처입니다.

---

1. 제일 단순한 전체 그림

 

[사용자 질문]
|
v
[Orchestrator Agent]
|
+-------------------+-------------------+
| | |
v v v
[Retriever Agent] [Planner Agent] [Tool Agent]
| | |
v v v
[Vector DB] [작업계획 생성] [API/DB/검색 호출]
|
v
[문서 검색 결과]
|
+--------------------------+
|
v
[Answer Agent]
|
v
[최종 응답]

 

이 구조에서
Orchestrator Agent가 총괄 PM 역할입니다.

---

2. RAG만 있는 경우 구조

먼저 Multi Agent 빼고, 기본 RAG만 보면 이렇습니다.

 

[사용자]
|
v
[Frontend / Chat UI]
|
v
[Backend API]
|
v
[Query Preprocessing]
|
v
[Embedding 생성]
|
v
[Vector DB 검색]
|
v
[관련 문서 Top-K]
|
v
[LLM Prompt 구성]
|
v
[LLM 응답 생성]
|
v
[사용자에게 답변]

 

이건 결국:

1. 질문 받음
2. 질문을 벡터로 바꿈
3. 문서 DB에서 비슷한 내용 찾음
4. 찾은 문서를 LLM에 넣음
5. 답변 생성

---

3. 여기에 Multi Agent가 붙으면 어떻게 바뀌나

RAG만으로는 한계가 있습니다.

예를 들어 사용자가 이렇게 묻는 경우입니다.

“사내 규정과 지난 회의록을 참고해서, 이번 분기 운영 개선안 초안을 작성해줘.”

이건 단순 문서검색만으로 끝나지 않습니다.

• 어떤 문서를 먼저 볼지 판단해야 하고
• 회의록과 규정을 비교해야 하고
• 필요한 경우 추가 검색도 해야 하고
• 결과를 보고서 형식으로 정리해야 합니다

그래서 역할 분리가 들어갑니다.

---

4. 실전형 RAG + Multi Agent 구조

 

┌─────────────────────┐
│ 사용자 질문 │
└─────────┬───────────┘
|
v
┌────────────────────────────┐
│ Orchestrator / Router │
│ 질문 분석, 흐름 제어, 분기 │
└───────┬─────────┬──────────┘
| |
| |
v v
┌─────────────────┐ ┌─────────────────┐
│ Planner Agent │ │ Retriever Agent │
│ 작업 단계 설계 │ │ 문서 검색 담당 │
└────────┬────────┘ └────────┬────────┘
| |
v v
┌───────────────────┐ ┌────────────────────┐
│ Task Breakdown │ │ Vector DB / BM25 │
│ 단계별 할 일 분해 │ │ 문서 / 규정 / 위키 │
└────────┬──────────┘ └────────┬───────────┘
| |
+-----------+-----------+
|
v
┌────────────────────────┐
│ Critic / Judge Agent │
│ 문서 적합성, 근거 점검 │
└──────────┬─────────────┘
|
+-------------------+-------------------+
| |
v v
┌─────────────────────┐ ┌─────────────────────┐
│ Tool Agent │ │ Writer Agent │
│ 외부 API/DB/검색 호출 │ │ 보고서/답변 작성 │
└──────────┬──────────┘ └──────────┬──────────┘
| |
+-------------------+-------------------+
|
v
┌────────────────────────────┐
│ Final Answer / Response │
│ 최종 응답 + 근거 + 요약 │
└────────────────────────────┘

 

---

5. 각 Agent 역할

1) Orchestrator Agent

총괄 제어기입니다.

역할:

• 질문 의도 분석
• 어떤 Agent를 호출할지 결정
• 순서를 제어
• 중간 결과를 모아서 최종 흐름 구성

실무로 치면 서비스 오케스트레이터 + PM입니다.

---

2) Planner Agent

질문을 작업 단위로 쪼갭니다.

예:

• 사내 규정 검색
• 지난 회의록 검색
• 공통 이슈 추출
• 개선안 초안 작성

즉, **“이 질문을 어떻게 풀어야 하는가”**를 설계합니다.

---

3) Retriever Agent

RAG의 핵심입니다.

역할:

• 질문 임베딩
• Vector DB 검색
• 키워드 검색(BM25) 병행
• Top-K 문서 추출
• 재정렬(reranking)

실무에서는 보통 아래를 붙입니다.

• Embedding Model
• Vector DB(pgvector, Pinecone, Weaviate, Milvus)
• Hybrid Search
• Reranker

---

4) Critic / Judge Agent

가져온 문서가 맞는지 검증합니다.

역할:

• 검색 결과 품질 확인
• 관련성 낮은 문서 제거
• 환각 가능성 낮추기
• 답변에 근거가 충분한지 체크

이게 없으면
검색은 했는데 엉뚱한 문서로 답변하는 문제가 많습니다.

---

5) Tool Agent

문서 검색 외의 실제 도구를 호출합니다.

예:

• 사내 DB 조회
• REST API 호출
• 웹 검색
• 이메일/캘린더 조회
• 계산기/코드 실행기 호출

즉, 단순 채팅이 아니라 실행 가능한 AI 서비스로 바뀝니다.

---

6) Writer Agent

최종 답변을 사용자 친화적으로 정리합니다.

역할:

• 요약
• 보고서 형식 변환
• 메일 초안 생성
• 표/문단 구성
• 근거 포함 정리

실무에서는 이 단계가 사용자 체감 품질을 크게 좌우합니다.

---

6. 인프라 관점 아키텍처

르무엘님 스타일로 백엔드/운영 구조로 보면 이런 그림이 더 중요합니다.

 

┌────────────────────┐
│ Frontend UI │
│ React / Next.js │
└─────────┬──────────┘
|
v
┌────────────────────┐
│ API Gateway │
│ Spring / FastAPI │
└─────────┬──────────┘
|
┌─────────────────┼──────────────────┐
| | |
v v v
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ Orchestrator │ │ Auth / User │ │ Logging / Trace │
│ Agent Service │ │ Service │ │ Observability │
└───────┬────────┘ └────────────────┘ └────────────────┘
|
┌───────┼───────────────────────────────────────┐
| | | |
v v v v
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────────┐
│ Planner │ │Retriever │ │Tool Agent│ │Writer / Judge │
│ Service │ │Service │ │Service │ │Service │
└────┬─────┘ └────┬─────┘ └────┬─────┘ └──────┬─────────┘
| | | |
v v v v
┌──────────┐ ┌─────────────┐ ┌─────────────┐ ┌──────────────┐
│Prompt/LLM│ │ Vector DB │ │ Internal API │ │ Redis / Queue │
│Gateway │ │ pgvector etc │ │ ERP / Group │ │ Kafka / Celery│
└──────────┘ └─────────────┘ └─────────────┘ └──────────────┘

 

이걸 Kubernetes에 올리면 각 서비스가 Pod 단위로 분리될 수 있습니다.

---

7. 데이터 흐름 예시

질문:

“지난달 장애 보고서와 운영 매뉴얼을 참고해 재발 방지 대책 정리해줘.”

흐름은 대략 이렇습니다.

 

1. 사용자 질문 수신
2. Orchestrator가 질문을 분석
3. Planner가 작업을 분해
- 장애 보고서 찾기
- 운영 매뉴얼 찾기
- 원인/대응 비교
- 재발 방지안 작성
4. Retriever가 관련 문서 검색
5. Judge가 문서 품질 검증
6. Tool Agent가 장애 통계 API 조회
7. Writer가 최종 보고서 작성
8. 사용자에게 응답 반환

 

이게 곧 문서 기반 + 툴 실행 기반 + 역할 분담 기반 AI 시스템입니다.

---

8. 왜 굳이 Multi Agent를 쓰나

단일 LLM 한 방으로도 답변은 가능합니다.
그런데 실무에서는 아래 문제가 큽니다.

단일 Agent 한계

• 질문이 복합적이면 흐름이 꼬임
• 검색 품질 검증이 약함
• 툴 호출 순서가 불안정함
• 긴 작업에서 맥락 손실
• 결과 품질 편차 큼

Multi Agent 장점

• 역할 분리
• 재사용 가능한 컴포넌트
• 디버깅 쉬움
• 확장 쉬움
• 품질 관리 쉬움

즉, 실무에서는
“똑똑한 한 명”보다 “역할이 분리된 팀”이 더 안정적입니다.

---

9. 르무엘님 관점에서 기술 스택 매핑

Java/Spring 백엔드 기준으로 보면 이런 식으로 가져가면 됩니다.

백엔드

• Spring Boot 또는 FastAPI
• API Gateway / BFF
• Agent Orchestrator Service

RAG

• Embedding Model
• pgvector / Elasticsearch / Pinecone
• Chunking / Metadata / Reranking

Agent

• LangGraph / CrewAI / AutoGen 계열
• 또는 직접 State Machine으로 구현

운영

• Docker
• Kubernetes
• Redis
• Kafka or RabbitMQ
• Prometheus / Grafana / Loki

---

10. 추천하는 현실적인 첫 구조

처음부터 Agent를 6개씩 나누면 과합니다.
실무적으로는 3단 구조부터 시작하는 게 맞습니다.

 

[User]
|
v
[Orchestrator]
|
+---------> [Retriever]
|
+---------> [Tool Executor]
|
v
[Answer Generator]

 

이렇게 먼저 만들고, 필요할 때:

• Planner 분리
• Judge 분리
• Writer 분리

로 확장하는 게 맞습니다.

---

11. 가장 현실적인 예시: 사내 AI 어시스턴트

르무엘님이 R&D에서 만들 가능성 높은 건 이런 겁니다.

 

사용자 질문
↓
질문 분류
↓
문서 검색 (RAG)
↓
필요 시 사내 시스템 조회
↓
답변 생성
↓
근거 링크/출처 반환

 

예:

• 사규 조회
• 매뉴얼 검색
• 회의록 요약
• 보고서 초안 작성
• 장애 대응 가이드 생성

이건 공공/기업 환경에서 바로 돈 되는 패턴입니다.

---

12. 한 줄 결론

RAG + Multi Agent는
단순 챗봇이 아니라,

“문서를 이해하고, 필요한 정보를 찾고, 역할 분담된 AI들이 협업해서, 실제 업무 결과물을 만들어내는 시스템 구조”입니다.

즉,

• RAG는 근거 확보
• Multi Agent는 업무 분업
• Kubernetes는 운영 기반

입니다.