ChanghyukBan
7가지 RAG 아키텍처는 옛말이다
2026년 프로덕션 RAG의 진짜 지형도
학계는 이미 25개 변종을 분류했고, 현장은 "유형"이 아닌 "조합"으로 움직인다. 인포그래픽이 보여주지 않는 진짜 RAG 기술 지도.
"7가지 RAG 아키텍처를 정리한 인포그래픽"이 SNS에 자주 돈다. Naive, Advanced, Agentic, Graph, Multi-Modal, Hybrid, Corrective. 입문용 지도로는 충분하다. 그러나 2026년 프로덕션 현장에 그대로 적용하기엔 두 가지 문제가 있다.
첫째, 분류가 2024년에 멈춰있다. 2025년 이후 RAG는 모듈러·에이전틱 단계로 넘어갔고, 학계 서베이는 이미 REPLUG, REALM, REVEAL 등을 포함한 25개 이상의 변종을 다룬다.
둘째, "유형"과 "기법"을 혼동한다. Hybrid는 사실 아키텍처 유형이 아니라 검색 기법이다. Agentic RAG 안에서도 Hybrid 검색을 쓴다. 현장에서 RAG는 "어떤 유형을 고를까"가 아니라 "어떤 패턴들을 어떻게 조합할까"의 문제다.
이 글은 2026년 프로덕션 RAG를 세 개의 층위로 정리한다. 입문 지도 → 현장에서 실제로 쓰이는 최신 기법 → 쿼리 클래스별 의사결정 프레임워크.
입문 지도: 7가지 기본 패턴
먼저 가장 자주 인용되는 7가지 분류를 정리한다. 이것이 출발점이다.
Naive RAG
사용자 쿼리 → 벡터 검색 → LLM → 응답. RAG의 원형. 데모에는 충분하나 프로덕션엔 부족하다.
Advanced RAG
Naive에 Query Rewriting, 메타데이터 필터링, Re-ranking을 추가. 검색 품질을 끌어올리는 가장 표준적인 진화.
Agentic RAG
에이전트가 "무엇을 어떻게 검색할지" 직접 결정. 다단계 추론과 도구 호출이 필요한 작업의 답이다.
Graph RAG
지식 그래프 위에서 추론. 다중 홉(multi-hop) 질의가 잦은 법률·의료·기술 명세 도메인에 적합.
Multi-Modal RAG
텍스트뿐 아니라 이미지·PDF·오디오·비디오를 함께 검색. 문서 AI와 비주얼 어시스턴트의 기반.
Hybrid RAG
벡터 검색과 키워드 검색을 결합. 유형이라기보다 모든 프로덕션 RAG의 기본 위생.
Corrective RAG (CRAG)
검색 결과를 검증한 후 LLM에 전달. 신뢰도가 낮으면 재검색하거나 웹 검색으로 폴백. 환각 감소의 표준 패턴.
이 7가지는 병렬적 선택지가 아니다. Hybrid는 거의 모든 시스템에서 기본으로 깔리고, Corrective는 Agentic 안에 들어가며, Multi-Modal은 데이터 타입의 문제다. 실제 분류축은 "선형(linear) vs 반복(iterative)", "정적(static) vs 적응형(adaptive)" 두 가지다.
현장의 진짜 무기: 2026년 검증된 기법들
인포그래픽에는 거의 등장하지 않지만, 프로덕션에서 품질을 결정하는 기법 6선.
HyDE (Hypothetical Document Embeddings)
질문 자체가 아니라 "가상의 답변"을 먼저 생성해서 그것을 임베딩해 검색한다. 사용자의 짧은 질문과 문서의 긴 설명문 사이의 어휘 간극을 메운다.
비용: LLM 호출 1회 추가 (인프라 변경 없음)
적합: 짧고 모호한 쿼리, 전문 도메인 검색
Contextual Retrieval
각 청크를 임베딩하기 전에, LLM이 그 청크가 전체 문서에서 어떤 맥락인지 한두 문장으로 설명해 함께 저장한다. "이 청크는 2024년 Q3 매출 섹션의 일부로…" 같은 식이다.
비용: 인덱싱 시 청크당 LLM 호출 (1회성)
적합: 청크가 독립적으로 이해 어려운 문서 (법률, 보고서)
Cross-Encoder Reranking
1차로 벡터 검색에서 Top-50을 뽑고, 2차로 cross-encoder 모델이 쿼리-문서 쌍을 직접 비교해 Top-5로 정밀 재정렬한다. 정확도와 latency의 균형점.
비용: 추론 latency 100–500ms 추가
적합: 검색 품질이 답변 품질을 좌우하는 모든 시스템
Self-RAG
모델이 스스로 "지금 검색이 필요한가?"를 판단하고, 검색 결과를 비평한 뒤 응답한다. 고신뢰 → 즉시 생성, 저신뢰 → 재검색, 중신뢰 → 쿼리 재작성. 무한 루프를 막기 위해 보통 5–6회로 제한.
비용: 토큰 사용량 1.5–3배
적합: 쿼리 복잡도가 크게 갈리는 시스템
CRAG (Corrective RAG)
Self-RAG의 검증 부분을 별도 grader 모델로 떼어낸 형태. 검색 결과를 점수화해 임계값 이하면 웹 검색이나 다른 소스로 폴백. "관련 없는 컨텍스트로 자신만만하게 틀린 답"을 막는 가장 실용적인 패턴.
비용: grader 모델 호출 1회 + (필요 시) 외부 검색
적합: 의료·법률·금융 등 고신뢰 요구 도메인
Adaptive RAG
쿼리의 복잡도를 먼저 분류해서 경로를 다르게 태운다. "환불 정책이 뭔가요" → Naive로 충분. "지난 5개 계약의 4조항을 비교하고 SOC 2와 충돌하는 것 표시" → Agentic 루프. 비용과 latency의 가장 큰 절감 레버.
비용: 라우터 분류기 1회 호출 (작은 모델로 OK)
적합: 다양한 난이도의 쿼리가 섞이는 모든 시스템
RAPTOR — 긴 문서를 재귀적 트리로 인덱싱해 요약과 디테일을 동시에 검색.
RAG Fusion — 여러 쿼리 변형을 병렬 실행 후 Reciprocal Rank Fusion으로 결과 통합. 리콜 강화.
의사결정: 무엇을 언제 쓸 것인가
핵심 질문은 "어느 것이 더 좋은가"가 아니라 "이 쿼리 클래스에서 이 비용을 정당화하는가"이다.
| 쿼리 클래스 | 권장 조합 | 목표 응답 시간 |
|---|---|---|
| FAQ·정책 조회 단답형, 단일 문서 |
Naive + Hybrid + Reranking (선택) |
< 2초 |
| 전문 도메인 Q&A 기술·의료·법률 |
Hybrid + HyDE + Contextual Retrieval + Reranking + CRAG | 3–5초 |
| 다중 홉 추론 "A와 B를 비교해 C 평가" |
Agentic RAG + Graph RAG + Self-RAG | 8–15초 |
| 혼합 트래픽 난이도가 들쭉날쭉 |
Adaptive RAG 라우터 + 위 셋 중 분기 | 평균 3초 |
| 긴 문서 분석 계약서·논문 |
RAPTOR + Contextual Retrieval + Self-RAG | 5–10초 |
"간단하게 시작하고, 측정하고, 측정 가능한 가치를 줄 때만 복잡성을 더한다."
에이전트부터 시작하는 것이 가장 흔한 실수다. Naive RAG가 작동하지 않으면 그 어떤 것도 구해주지 못한다. 먼저 Hybrid 검색과 Reranking 같은 기본 위생을 갖추고, 실패 케이스를 측정한 다음, 그 실패가 검색 문제인지 추론 문제인지에 따라 다음 기법을 고른다.
RAG의 다음 단계는 "조합 설계자"
2026년의 RAG는 더 이상 "어떤 유형을 골랐는가"로 평가되지 않는다. "어떤 패턴을 어떤 쿼리 클래스에 어떻게 연결했는가"가 시스템의 품질을 결정한다.
인포그래픽의 7가지 분류는 출발점일 뿐, 종착점이 아니다. 진짜 작업은 HyDE·Contextual Retrieval·CRAG·Self-RAG 같은 기법들을 자기 도메인의 쿼리 분포에 맞춰 조합하고, 측정하고, 다듬는 일이다.
AI 빌더가 해야 할 일은 더 화려한 아키텍처를 좇는 것이 아니라, 자기 사용자의 쿼리가 어느 클래스에 속하는지 정확히 파악하고, 그에 맞는 가장 검소한 조합을 만드는 것이다. 그것이 2026년 프로덕션 RAG의 진짜 지형도다.