AI 엔지니어라면 반드시 이해해야 할 9가지 RAG 아키텍처

지금 LLM으로 무언가를 만들고 있다면, 이 말을 수백 번은 들어봤을 것이다.

"그냥 RAG 붙이면 돼."

간단하게 들린다... 프로덕션에서 작동하지 않기 전까지는.

할루시네이션. 관련 없는 컨텍스트. 느린 응답. 그리고 갑자기 당신의 "스마트 AI"는... 멍청하게 느껴진다.

문제는 RAG 자체가 아니다.

문제는 상황에 맞지 않는 RAG 아키텍처를 사용하는 것이다.

그러니 또 다른 이론적인 설명 대신, 각 RAG 타입이 실제로 무엇을 하는지, 언제 망가지는지, 언제 써야 하는지를 짚어보자.

---

먼저, RAG란 무엇인가? (쉽게 말하면)

핵심만 보면 RAG는 그냥 이것이다.

사용자 쿼리 → 데이터 검색 → LLM에 전달 → 답변 생성

그게 전부다.

하지만 마법(과 문제)은 이 부분에서 일어난다.

• 어떻게 검색하는가
• 무엇을 검색하는가
• 어떻게 검증하는가
• 모델이 어떻게 추론하는가

바로 여기서 9가지 아키텍처가 등장한다.

---

1. Standard RAG (시작점)

튜토리얼의 90%가 보여주는 방식이다.

1. 문서를 임베딩한다
2. 벡터 DB에 저장한다
3. 상위 K개 청크를 검색한다
4. LLM에 전달한다

잘 작동하는 경우: FAQ, 내부 문서, 기본 검색

망가지는 경우: 쿼리가 복잡할 때, 컨텍스트가 노이즈할 때, 추론이 필요할 때

현실 점검: MVP에는 좋다. 진지한 시스템에는 부족하다.

---

2. Conversational RAG

여기서 메모리가 추가된다.

모든 쿼리를 독립적으로 처리하는 대신, 다음을 활용한다.

• 대화 히스토리
• 이전 컨텍스트

잘 작동하는 경우: 챗봇, 고객 지원 시스템, 어시스턴트

망가지는 경우: 대화가 길어질수록 컨텍스트가 비대해지고, 관련 없는 히스토리가 답변을 오염시킨다

핵심 인사이트: 메모리는 도움이 된다... 하지만 너무 많은 메모리는 오히려 해가 된다.

---

3. Corrective RAG (CRAG)

대부분의 시스템이 무시하는 것을 추가한다.

👉 검증 레이어

흐름이 이렇게 된다.

1. 문서를 검색한다
2. 품질을 평가한다
3. 필요하면 수정하거나 재검색한다

잘 작동하는 경우: 금융, 법률, 컴플라이언스 시스템

왜 중요한가: 대부분의 RAG 실패는 생성 문제가 아니다. 검색 실패다. CRAG가 바로 그것을 고친다.

---

4. Adaptive RAG

모든 쿼리가 동등하지 않다.

단순한 쿼리도 있다.

"Redis가 뭔가요?"

 

복잡한 쿼리도 있다.

"이벤트 드리븐 시스템에서 Redis vs Kafka를 비교해줘"

 

Adaptive RAG는 다음을 스스로 결정한다.

• 몇 개의 소스를 검색할지
• 얼마나 깊이 검색할지
• 여러 전략을 사용할지

👉 쉽게 말하면: 쿼리를 위한 스마트 백엔드 라우터다.

---

5. Self-RAG

이제 흥미로워진다.

모델이 스스로:

1. 답변을 생성하고
2. 자기 자신을 비판하고
3. 응답을 개선한다

👉 쉽게 말하면: "LLM이 자기 코드를 코드 리뷰하는 것"

잘 작동하는 경우: 장문 답변, 리서치, 콘텐츠 생성

트레이드오프: 품질은 올라가지만, 레이턴시도 올라간다.

---

6. Fusion RAG

하나의 쿼리 대신, 여러 쿼리를 던진다.

예시: 사용자가 이렇게 묻는다.

"Node.js 앱을 어떻게 스케일링하나요?"

시스템이 이런 쿼리들을 생성한다.

• "Node.js 스케일링 기법"
• "horizontal scaling node"
• "load balancing node apps"

그런 다음 전부에서 검색하고, 결과를 합치고, 순위를 매긴다.

결과: 훨씬 나은 커버리지.

👉 프로덕션 시스템에서 범죄적으로 저평가된 방식이다.

---

7. HyDE (Hypothetical Document Embedding)

좀 이상하게 느껴지지만... 놀랍도록 잘 작동한다.

직접 검색하는 대신,

1. 가상의 이상적인 답변을 생성한다
2. 그것을 임베딩한다
3. 그것을 기반으로 검색한다

왜 작동하는가: 생성된 답변이 원본 쿼리보다 관련 문서에 더 가까운 경우가 많다.

가장 적합한 경우: 모호한 쿼리, 잘 구조화되지 않은 입력

---

8. Agentic RAG

RAG와 에이전트가 만나는 지점이다.

단일 흐름 대신, 다음이 가능해진다.

• 계획 수립
• 툴 사용
• 다단계 추론

예시: 사용자가 이렇게 묻는다.

"매출 하락을 분석하고 전략을 제안해줘"

에이전트는 이렇게 동작할 수 있다.

1. 데이터를 가져오고
2. 분석을 실행하고
3. 문서를 검색하고
4. 인사이트를 생성한다

👉 이건 그냥 RAG가 아니다. 생각하고 행동하는 AI 시스템이다.

---

9. GraphRAG

일반적인 RAG는 청크를 사용한다.

GraphRAG는 👉 관계(relationship) 를 사용한다.

"임의의 문단 검색" 대신, 이 항목들을 활용한다.

• 엔티티
• 연결
• 구조화된 지식

예시:

"Node.js → 이벤트 루프 → async → 성능"

 

가장 적합한 경우는 엔터프라이즈 지식 베이스,  리서치,  연결된 데이터 이다.

---

⚡ 대부분의 글이 말해주지 않는 진실

실제 시스템은 하나만 사용하지 않는다.

프로덕션 구성은 보통 이렇게 생겼다.

실제 구축되는 역할 아키텍처

검색	Fusion RAG
검증	CRAG
라우팅	Adaptive RAG
추론	Agentic layer

 

👉 RAG는 기능(feature)이 아니다.

👉 RAG는 파이프라인 아키텍처다.

---

만들고 있다면 (실용적인 로드맵)

현실적으로 정리해보자.

✅ Level 1 (MVP)

• Standard RAG
• 좋은 청킹
• 리랭커 추가

⚙️ Level 2 (프로덕션)

• Fusion RAG (멀티 쿼리)
• CRAG (검증 레이어)

🚀 Level 3 (고급 시스템)

• Agentic RAG
• GraphRAG (데이터가 관계형이라면)

---

💡 마무리

대부분의 개발자는 할루시네이션을 이렇게 고치려 한다.

• 모델을 바꾼다
• 토큰을 늘린다

하지만 진짜 해결책은 거의 항상 더 나은 검색 아키텍처 에 있다.

 

🔥 이 글에서 하나만 가져간다면:

❌ "RAG를 써야 할까?"라고 묻지 마라.
✅ "내 문제에 어떤 RAG 아키텍처가 맞는가?" 라고 물어라.

 

이 둘 간의 차이는 데모 수준과 실제 운영 수준의 AI 시스템 정도의 차이이다.