RAG 2026 — 검색 한 번으로 끝나던 시절은 지났다
Naive RAG에서 Agentic RAG로 이어진 진화 단계와 Graph RAG·CRAG·Modular RAG 아키텍처, 청킹 전략·RAGAS 평가 프레임워크·프로덕션 배포 시 고려사항을 정리한다.
2026-08-14 · 최초 발행 2026-03-29
검색 증강 생성(RAG, Retrieval Augmented Generation)은 2023년 등장 이후 불과 3년 만에 엔터프라이즈 AI 도입의 표준 패턴으로 자리 잡았다. 초기의 단순한 벡터 검색 + LLM 조합에서 출발해, 2026년의 RAG는 쿼리 분해, 다단계 추론, 에이전트 통합까지 포함하는 복합 아키텍처로 진화했다. 기본 RAG가 해결하지 못했던 한계들—낮은 검색 정밀도, 컨텍스트 창 한계, 다중 홉 추론 불가—을 어떻게 극복해 왔는지, 그리고 2026년 현재 엔터프라이즈 환경에서 어떤 아키텍처가 실제로 작동하는지를 단계별로 살펴본다.
검색 한 번에서 반복 추론으로
최초의 RAG 구현(Naive RAG, 2023)은 단순하다. 문서를 청크로 분할하고 임베딩 벡터로 저장한 뒤, 쿼리와 코사인 유사도가 높은 청크를 LLM 컨텍스트에 삽입하는 방식이다. 키워드 의미 불일치로 인한 검색 실패, 청크 경계에서의 컨텍스트 단절, 단순 유사도 검색의 낮은 정밀도가 한계였다.
Advanced RAG(2024)는 이 한계를 풀기 위해 여러 기법을 도입했다. 밀도 벡터 검색(dense retrieval)과 BM25 키워드 검색을 결합해 검색 커버리지를 높이는 Hybrid Search, 검색된 청크를 교차 인코더(cross-encoder)로 재정렬해 정밀도를 높이는 Re-ranking, 원본 쿼리를 분해하거나 가상 답변(HyDE)을 생성해 검색 품질을 높이는 Query Transformation, 검색된 청크에서 쿼리와 관련된 부분만 추출해 컨텍스트 창을 효율적으로 쓰는 Contextual Compression이 대표적이다.
Agentic RAG(2025~2026)는 에이전트가 검색 전략을 동적으로 결정하는 구조다. 단일 검색 호출이 아니라 필요에 따라 반복적으로 검색하고, 검색 결과를 평가하며, 전략을 조정한다.
그래프로, 스스로 고쳐가며, 모듈로
단순 청크 기반 검색을 넘어 지식 그래프(knowledge graph)를 활용하는 방식이 Graph RAG다. Microsoft Research가 제안한 GraphRAG는 문서에서 엔티티와 관계를 추출해 그래프로 구성하고, 쿼리 시 그래프 탐색과 벡터 검색을 결합한다. "A와 B가 모두 관련된 C에 대해 설명해줘" 같은 복잡한 다중 홉 질문에서 기존 RAG를 크게 능가한다.
from graphrag import GraphRAGPipeline
pipeline = GraphRAGPipeline(
llm_model="claude-opus-4-5",
embedding_model="text-embedding-3-large"
)
# 인덱싱: 엔티티/관계 추출 및 그래프 구성
pipeline.index(documents=docs, extract_entities=True)
# 쿼리: 로컬(특정 엔티티 중심) 또는 글로벌(전체 요약) 모드
answer = pipeline.query(
"AI 거버넌스 규제가 스타트업 생태계에 미치는 영향은?",
query_type="global" # 전체 코퍼스 요약 기반 답변
)
검색 결과의 관련성을 평가하고 신뢰도가 낮으면 웹 검색으로 보완하는 자가 수정 RAG가 CRAG(Corrective RAG)다.
검색, 재정렬, 압축, 생성 각 모듈을 독립적으로 교체할 수 있는 플러그인 아키텍처가 Modular RAG다. 특정 도메인에 최적화된 모듈을 조합하거나 A/B 테스트를 통해 각 컴포넌트를 독립적으로 개선할 수 있다.
청크를 어떻게 자를 것인가
| 전략 | 적합한 문서 유형 | 청크 크기 |
|---|---|---|
| 고정 크기 분할 | 비구조적 텍스트 | 512~1024 토큰 |
| 의미 기반 분할 | 문단이 명확한 문서 | 가변 (200~800 토큰) |
| 재귀적 분할 | 중첩 구조 문서 | 가변 |
| 문서 구조 기반 | PDF, HTML, 코드 | 구조 단위 |
청킹은 RAG 성능에 가장 큰 영향을 미치는 요소 중 하나다. 소형 청크로 검색하되 더 큰 부모 청크를 컨텍스트로 제공하는 "Parent Document Retriever" 패턴이 2026년 표준으로 자리 잡았다.
RAG 파이프라인의 품질을 정량적으로 측정하는 것은 엔터프라이즈 도입의 전제조건이며, RAGAS(RAG Assessment) 프레임워크가 사실상 표준이다.
from ragas import evaluate
from ragas.metrics import (
faithfulness, # 생성된 답변이 컨텍스트에 충실한가
answer_relevancy, # 답변이 질문에 관련되는가
context_precision, # 검색된 컨텍스트가 정확한가
context_recall # 관련 컨텍스트를 모두 검색했는가
)
results = evaluate(
dataset=eval_dataset,
metrics=[faithfulness, answer_relevancy, context_precision, context_recall]
)
print(results)
# {'faithfulness': 0.87, 'answer_relevancy': 0.91,
# 'context_precision': 0.79, 'context_recall': 0.84}
배포하고 나면 부딪히는 것들
다단계 RAG는 응답 시간이 늘어난다는 레이턴시 관리 문제가 있다. 검색 결과 캐싱(쿼리 임베딩 캐시), 비동기 병렬 검색, 스트리밍 응답을 결합해 체감 레이턴시를 낮춘다. 재정렬(reranking)과 LLM 기반 관련성 평가는 추가 비용을 발생시키므로, 트래픽 볼륨에 따라 경량 모델로 1차 필터링하고 고성능 모델은 최종 답변 생성에만 쓰는 캐스케이드 전략이 비용 최적화에 효과적이다. 엔터프라이즈 환경에서는 사용자 역할(role)에 따라 검색 가능한 문서를 제한하는 메타데이터 필터링이 보안·접근 제어의 필수 요소다.
2026년의 RAG는 단순한 검색 보조 도구를 넘어 기업의 지식 인프라 전반을 연결하는 AI 허브로 진화했다. Graph RAG, CRAG, Agentic RAG 같은 고도화된 패턴은 기존 RAG의 한계를 상당 부분 해소하지만, 구현 복잡도와 비용도 함께 늘어난다. 실무에서는 Naive RAG로 시작해 평가 결과를 보며 필요한 컴포넌트만 추가하는 단계적 도입이 오버엔지니어링을 피하는 최선의 전략이다.