RAG는 이제 하나의 기술이 아니라 하나의 생태계다. 지식 그래프를 활용하는 GraphRAG, 스스로 판단하는 Self-RAG, 에이전트로 진화한 Agentic RAG까지 — 각 접근법이 해결하는 문제와 선택 기준을 논문 기반으로 정리한다.
2020년 Lewis et al.이 "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"를 발표했을 때, RAG는 하나의 명확한 아이디어였다. 질문이 들어오면 관련 문서를 검색하고, 그 문서를 LLM에 넘겨 답변을 생성한다. 단순하고 강력했다.
그로부터 6년이 지난 2026년, "RAG를 도입하겠다"고 말하는 것은 "데이터베이스를 쓰겠다"고 말하는 것과 비슷해졌다. 어떤 RAG를 쓸 것인가가 문제다. 문서를 그래프로 변환하는 GraphRAG, 검색 필요 여부를 스스로 판단하는 Self-RAG, 트리 구조로 계층적 요약을 만드는 RAPTOR, 에이전트가 검색 전략을 동적으로 결정하는 Agentic RAG — 선택지가 이렇게 많아졌다.
이전 글에서 RAG의 기본 원리와 실전 개선 기법(Advanced RAG)을 다뤘다. 이 글에서는 한 발 물러서 RAG 생태계 전체를 조망한다. 각 접근법이 어떤 문제를 해결하기 위해 탄생했는지, 어떻게 작동하는지, 그리고 당신의 상황에서는 무엇을 선택해야 하는지를 정리한다.
Gao et al. (2024)의 서베이 논문과 이후의 Modular RAG 논문(Gao et al., 2024b)은 RAG의 발전을 세 가지 패러다임으로 구분한다. 여기에 2025년 이후 급부상한 Agentic RAG를 더하면 네 단계가 된다.
이 네 단계는 시간순이자 복잡도순이다. 하지만 "최신이 최선"은 아니다. 각 단계는 특정 문제를 해결하기 위해 존재하며, 문제의 복잡도에 따라 적절한 단계가 달라진다.
이 글에서는 주요 RAG 변형들을 해결하는 문제를 기준으로 분류한다:
| 문제 | 접근법 |
|---|---|
| 문서 간 관계와 전체 맥락 파악 | GraphRAG, RAPTOR |
| 검색 필요 여부·품질의 자동 판단 | Self-RAG, CRAG, Adaptive RAG |
| 복잡한 멀티스텝 질문 처리 | Agentic RAG |
| 파이프라인의 유연한 재구성 | Modular RAG |
하나씩 살펴보자.
"이 문서 전체의 핵심 주제는 무엇인가?"
이 질문에 기본 RAG는 답할 수 없다. 왜? 기본 RAG는 질문과 가장 유사한 개별 청크를 가져올 뿐, 문서 전체를 조망하는 능력이 없기 때문이다. 1000개의 청크 중 상위 5개를 가져와도, 그것은 전체의 0.5%에 불과하다.
기업 현장에서 이런 질문은 흔하다:
이 모든 질문에는 문서 간 관계와 전체를 관통하는 패턴에 대한 이해가 필요하다.
2024년 4월, Microsoft Research의 Darren Edge et al.이 "From Local to Global: A Graph RAG Approach to Query-Focused Summarization"을 발표했다. 이 논문의 핵심 아이디어는 이렇다:
"문서를 벡터로 변환하는 대신, 문서에서 개체(entity)와 관계(relationship)를 추출하여 지식 그래프(knowledge graph)를 구축하고, 이 그래프의 커뮤니티 구조를 활용하여 질문에 답하자."
GraphRAG의 인덱싱 파이프라인은 기본 RAG보다 훨씬 정교하다.
개체·관계 추출에서는 LLM이 각 텍스트 단위에서 "삼성전자 — 투자 → 반도체 공장", "NVIDIA — 협력 → 현대자동차" 같은 구조화된 정보를 뽑아낸다. 논문에서는 다중 라운드 글리닝(gleaning) 기법을 사용한다 — 1차 추출 후 "빠뜨린 개체가 있지 않은가?"라고 LLM에게 자기 점검시켜 추가 추출을 유도한다.
커뮤니티 탐지에서는 Leiden 알고리즘으로 밀접하게 연결된 개체들을 그룹으로 묶는다. 이 과정이 재귀적으로 반복되어, 최상위(C0, 가장 추상적)에서 최하위(C3, 가장 구체적)까지의 계층 구조가 만들어진다. 그리고 각 커뮤니티에 대해 LLM이 구조화된 요약 보고서를 생성한다.
글로벌 검색(Global Search): "이 데이터셋의 핵심 주제는?" 같은 전체 조망 질문에 사용된다. 커뮤니티 요약들을 map-reduce 방식으로 처리한다. 2025년 개선판에서는 **동적 커뮤니티 선택(Dynamic Community Selection)**을 도입해, 관련 없는 커뮤니티를 사전에 제거하여 비용을 평균 77% 절감하면서도 품질을 유지했다.
로컬 검색(Local Search): "카모마일의 약효 성분은?" 같은 특정 개체 관련 질문에 사용된다. 질문과 의미적으로 관련된 개체를 찾고, 그래프를 따라 연결된 이웃 개체, 관계, 커뮤니티 보고서를 수집하여 LLM에 전달한다.
논문의 실험 결과가 인상적이다. 팟캐스트 트랜스크립트(~100만 토큰)와 뉴스 기사(~170만 토큰) 데이터셋에서:
| 지표 | GraphRAG 승률 (vs 기본 RAG) |
|---|---|
| 포괄성(Comprehensiveness) | 72~83% |
| 다양성(Diversity) | 62~82% |
| 평균 추출 주장 수 | 31.6 |
특히 주목할 점: 최상위 수준(C0) GraphRAG는 나이브 텍스트 요약 대비 97% 이상 적은 토큰을 사용하면서도 72% 승률을 유지했다.
적합한 경우:
과한 경우:
같은 문서에 대해서도 질문의 추상화 수준은 다양하다:
기본 RAG는 원본 텍스트 청크만 저장하므로, 구체적 질문에는 강하지만 추상적 질문에는 약하다. 반대로 문서 전체를 요약하면 구체적 정보를 잃는다.
Sarthi et al. (ICLR 2024)이 제안한 RAPTOR(Recursive Abstractive Processing for Tree-Organized Retrieval)는 이 문제를 트리 구조로 해결한다.
트리 구축 (상향식):
검색 (Collapsed Tree 방식):
트리의 모든 노드(원본 + 모든 레벨의 요약)를 하나의 레이어로 평탄화한 뒤, 질문과 코사인 유사도가 높은 노드를 토큰 한도(~2000토큰)에 맞춰 검색한다. 구체적 질문이면 원본 청크(하위 레벨)가 선택되고, 추상적 질문이면 상위 요약이 선택된다. 질문의 추상화 수준에 자동으로 적응하는 것이 핵심이다.
QuALITY 벤치마크에서 GPT-4 기준 82.6% 정확도를 달성해 기본 RAG(62.3%) 대비 20%p 향상. NarrativeQA에서도 SOTA를 기록했다. 특히 긴 문서에 대한 종합적 이해가 필요한 태스크에서 강점을 보인다.
"1+1은?"에 검색이 필요한가? 아니다. "어제 삼성전자 종가는?"에는? 반드시 필요하다.
기본 RAG는 이 판단을 하지 못한다. 모든 질문에 무조건 검색을 수행한다. 불필요한 검색은 지연 시간을 늘리고 비용을 높이며, 때로는 관련 없는 문서가 유입되어 오히려 답변 품질을 떨어뜨리기도 한다.
Asai et al. (ICLR 2024, Oral — 상위 1%)이 발표한 Self-RAG는 모델이 스스로 검색을 판단하고, 검색 결과를 평가하고, 자기 답변을 비판하는 구조를 제안했다.
핵심은 4가지 **리플렉션 토큰(reflection token)**이다:
| 토큰 | 역할 | 판단 값 |
|---|---|---|
| Retrieve | 검색이 필요한가? | yes / no / continue |
| IsRel | 검색된 문서가 질문과 관련 있는가? | relevant / irrelevant |
| IsSup | 생성된 답변이 문서에 의해 뒷받침되는가? | fully / partially / no support |
| IsUse | 최종 답변이 유용한가? | 1~5 점수 |
모델이 "Retrieve = no"를 출력하면 검색 없이 바로 답변을 생성한다. "Retrieve = yes"이면 검색을 수행하고, 가져온 문서에 대해 IsRel로 관련성을 평가한다. 답변 생성 후에도 IsSup과 IsUse로 자기 답변의 품질을 자체 평가한다.
Self-RAG 7B/13B 모델은 ChatGPT와 검색 증강 Llama2를 오픈 도메인 QA, 사실 검증, 추론 태스크에서 능가했다.
검색된 문서가 질문과 관련이 없거나, 부분적으로만 관련 있는 경우가 빈번하다. 기본 RAG는 이런 "나쁜 검색 결과"를 그대로 LLM에 전달해 답변 품질을 떨어뜨린다.
Yan et al. (2024)이 제안한 CRAG(Corrective RAG)는 검색 결과의 품질을 평가하고, 결과에 따라 세 가지 행동을 취한다.
검색 평가자는 T5-large 기반의 경량 모델(0.77B 파라미터)로, 각 문서에 -1~1 범위의 관련성 점수를 매긴다. 점수가 높으면 Correct (문서를 정제하여 사용), 중간이면 Ambiguous (검색 + 웹 검색 결합), 낮으면 Incorrect (폐기 후 웹 검색 대체).
지식 정제(Knowledge Refinement) 단계도 주목할 만하다. 문서를 문장 단위로 분해하고, 각 문장의 관련성을 개별 평가하여 관련 없는 부분을 걸러낸다. 이것은 이전 글에서 다룬 "컨텍스트 압축"과 유사하지만, 자동화된 평가 모델이 판단한다는 점이 다르다.
CRAG의 핵심 장점은 플러그 앤 플레이라는 것이다. 기존 RAG 시스템(Naive RAG든 Self-RAG든)에 그대로 붙여서 사용할 수 있다.
"대한민국의 수도는?" 같은 단순 질문에 하이브리드 검색 + 리랭킹 + 컨텍스트 압축을 적용하는 것은 낭비다. 반대로 "2025년 한미 반도체 협력이 공급망에 미친 구체적 영향은?" 같은 복잡한 질문에 단순 검색만 적용하면 부족하다.
Jeong et al. (NAACL 2024)이 제안한 Adaptive RAG는 질문의 복잡도를 먼저 분류하고, 복잡도에 맞는 전략을 선택한다.
| 질문 복잡도 | 전략 | 예시 |
|---|---|---|
| 단순 | 검색 없이 LLM 직접 답변 | "Python의 리스트 정렬 함수는?" |
| 중간 | 단일 검색 → 생성 (기본 RAG) | "Next.js 16의 새로운 기능은?" |
| 복잡 | 반복적 다단계 검색 + 추론 | "최근 3년 AI 규제 변화가 스타트업에 미친 영향을 분석하라" |
복잡도 분류기는 별도의 경량 LM으로, 학습 데이터를 별도 어노테이션 없이 자동으로 수집한다. 각 전략의 예측 결과를 정답과 비교하여, "이 질문은 어떤 전략이 성공했는가"를 역추적하는 방식이다.
핵심 인사이트: 단순 질문에 복잡한 파이프라인을 적용하면 비용이 불필요하게 높아지고, 때로는 불필요한 검색이 노이즈를 유입시켜 성능이 오히려 떨어진다. Adaptive RAG는 "적절한 복잡도"를 자동으로 선택함으로써 비용과 품질을 동시에 최적화한다.
지금까지 본 RAG 변형들 — GraphRAG, Self-RAG, CRAG — 은 각각 특정 문제에 대한 해결책이다. 하지만 실전에서는 이것들을 조합해야 할 때가 많다. "GraphRAG로 인덱싱하되, CRAG로 검색 결과를 검증하고, Self-RAG 방식으로 검색 필요 여부를 판단"하고 싶다면?
기존 RAG 구현체들은 대부분 단일 파이프라인으로 설계되어, 이런 조합이 어렵다.
Gao et al. (2024b)은 "Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks"에서 RAG를 6개의 독립 모듈로 분해하는 아키텍처를 제안했다.
각 모듈은 독립적으로 교체 가능하다. Indexing 모듈을 벡터 기반에서 그래프 기반으로 바꾸거나, Retrieval 모듈을 하이브리드 검색으로 교체하거나, Post-Retrieval에 CRAG의 검증 단계를 끼워넣을 수 있다.
특히 Orchestration 모듈이 핵심이다. 기존의 직선형 파이프라인을 넘어, 라우팅(질문 유형에 따라 다른 경로), 스케줄링(단계 간 실행 순서 결정), 퓨전(여러 결과를 결합) 같은 고급 흐름 제어를 지원한다.
Modular RAG는 특정 기법이라기보다 사고 프레임워크에 가깝다. "이 모듈을 바꾸면 전체 시스템에 어떤 영향을 미치는가?"를 체계적으로 분석하고 실험할 수 있는 틀을 제공한다.
"우리 서비스의 3월 MAU가 감소한 원인을 분석하고, 경쟁사 동향과 비교해서 대응 방안을 제안해줘."
이 질문에는 다음이 필요하다:
어떤 데이터 소스에 접근하고, 어떤 순서로 처리하고, 중간 결과에 따라 다음 행동을 바꿔야 한다. 정적 파이프라인으로는 불가능하다.
Singh et al. (2025)의 서베이 "Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG"에 따르면, Agentic RAG는 자율적 AI 에이전트를 RAG 파이프라인에 통합하여 동적으로 검색 전략을 결정하는 시스템이다.
기존 RAG와의 핵심 차이:
| 차원 | 기존 RAG | Agentic RAG |
|---|---|---|
| 워크플로 | 정적, 직선형 | 동적, 적응적 |
| 추론 | 단일 단계 검색/생성 | 다단계 반복 정제 |
| 도구 활용 | 벡터 DB만 | DB, API, 웹 검색, 코드 실행 등 |
| 상태 관리 | 무상태(stateless) | 대화 전반에 걸쳐 컨텍스트 유지 |
실전 예시 — 단일 에이전트 라우터:
# 의사 코드: 에이전트가 질문을 분석하고 적절한 도구 선택
def agentic_rag(question: str, agent: Agent):
# 에이전트가 질문을 분석하고 계획을 수립
plan = agent.think(f"""
질문: {question}
사용 가능한 도구:
- vector_search: 내부 문서 검색
- sql_query: 데이터베이스 조회
- web_search: 웹 검색
- calculator: 수치 계산
어떤 도구를 어떤 순서로 사용할지 계획하세요.
""")
# 계획에 따라 도구를 순차적으로 실행
context = []
for step in plan.steps:
result = agent.execute_tool(
step.tool, step.params
)
context.append(result)
# 중간 결과를 보고 계획 수정 가능
if agent.needs_revision(result):
plan = agent.revise_plan(plan, result)
# 수집된 모든 컨텍스트를 종합하여 답변 생성
return agent.generate(question, context)
핵심은 에이전트가 중간 결과에 따라 계획을 수정할 수 있다는 점이다. 첫 번째 검색에서 충분한 정보를 얻지 못하면 다른 소스를 시도하고, 예상과 다른 데이터를 발견하면 분석 방향을 조정한다. 마치 인간 연구자가 리서치를 하는 것처럼.
지면 관계상 깊이 다루지 못했지만, 알아두면 유용한 접근법들이다.
LLM 추론의 "투기적 실행(speculative execution)"에서 영감을 받은 접근법. 작은 전문 모델이 서로 다른 문서 조합으로 여러 개의 초안 답변을 병렬 생성하고, 큰 범용 모델이 이들을 한 번에 검증하여 최종 답을 고른다. PubHealth에서 정확도 12.97% 향상, 지연 시간 50.83% 감소를 동시에 달성.
생성 중에 실시간으로 검색 필요성을 판단하는 방법. LLM이 다음 문장을 임시로 생성하고, 특정 토큰의 확률이 낮으면(=확신이 없으면) 그 문장을 쿼리로 사용해 검색을 수행하고, 검색 결과를 반영하여 문장을 재생성한다. Self-RAG와 달리 별도 학습 없이 기존 모델에 적용 가능.
하나의 LLM이 검색 결과 순위 매기기와 답변 생성을 동시에 수행하도록 학습시키는 방법. 순위 학습 데이터를 소량만 추가해도 전문 리랭킹 모델을 능가하며, Llama3-RankRAG는 ChatQA-1.5 대비 10% 이상 향상을 달성.
원래 질문에서 여러 변형 쿼리를 생성하고, 각각으로 검색한 뒤, **Reciprocal Rank Fusion(RRF)**으로 결과를 통합. 이전 글에서 다룬 멀티 쿼리 검색 + 하이브리드 검색의 결합에 해당한다.
모든 RAG 프로젝트가 같은 수준의 복잡도를 필요로 하지는 않는다. 다음 질문들을 순서대로 답해보자:
질문 1: 문서 간 관계나 전체 패턴 파악이 필요한가?
질문 2: 질문의 복잡도가 크게 다양한가?
질문 3: 여러 데이터 소스를 조합하거나 다단계 추론이 필요한가?
| 시나리오 | 추천 접근법 | 이유 |
|---|---|---|
| 사내 문서 Q&A 챗봇 | Advanced RAG | 청킹 + 하이브리드 검색 + 리랭킹으로 대부분 해결 |
| 법률 문서 분석 | GraphRAG | 조항 간 관계, 판례 간 연결 추적이 핵심 |
| 학술 논문 리서치 도우미 | RAPTOR | 구체적 수치부터 전체 흐름까지 다양한 추상화 수준 |
| 고객 지원 챗봇 | Adaptive RAG | 단순 FAQ부터 복잡 문의까지 질문 복잡도가 다양 |
| 비즈니스 인텔리전스 | Agentic RAG | DB 조회, 리포트 검색, 웹 정보 등 다중 소스 필요 |
| 의료/금융 규제 준수 | CRAG + Advanced RAG | 답변 정확도가 최우선, 부적절한 검색 결과 필터링 필수 |
| 대규모 문서셋 주제 분석 | GraphRAG (Global Search) | 수만 건 문서의 전체 패턴 파악 |
실전에서는 하나의 접근법만 쓰는 경우가 드물다. 효과적인 조합 예시:
조합 1: Advanced RAG + CRAG 기본 하이브리드 검색에 CRAG의 검증 단계를 추가. 구현이 간단하면서 검색 품질을 크게 높인다. CRAG가 플러그 앤 플레이이므로 기존 시스템에 쉽게 붙일 수 있다.
조합 2: GraphRAG + Advanced RAG 글로벌 질문은 GraphRAG로, 구체적 질문은 Advanced RAG로 라우팅. Adaptive RAG의 분류기로 라우팅을 자동화할 수 있다.
조합 3: Agentic RAG + 모든 것 에이전트가 질문을 분석하여 GraphRAG, 벡터 검색, SQL 쿼리, 웹 검색 중 적절한 도구를 동적으로 선택. 가장 유연하지만 가장 복잡하다.
각 접근법의 도입에는 비용이 따른다. 현실적인 판단을 위해 트레이드오프를 정리한다.
| 접근법 | 인덱싱 비용 | 쿼리 지연 | 답변 품질 | 유지보수 |
|---|---|---|---|---|
| Naive RAG | 낮음 | 빠름 | 기본 | 쉬움 |
| Advanced RAG | 낮~중간 | 중간 | 좋음 | 중간 |
| CRAG | 낮음 (플러그인) | 중간 | 좋음+ | 쉬움 |
| Self-RAG | 높음 (모델 학습) | 중간 | 좋음+ | 어려움 |
| Adaptive RAG | 중간 (분류기 학습) | 가변적 | 좋음+ | 중간 |
| RAPTOR | 중간 (트리 구축) | 빠름 | 우수 | 중간 |
| GraphRAG | 높음 (그래프 구축) | 중간~느림 | 우수 | 높음 |
| Agentic RAG | 가변적 | 느림 | 우수+ | 높음 |
핵심 원칙: 가장 단순한 것부터 시작하라. Advanced RAG(하이브리드 검색 + 리랭킹)로 시작하여 성능을 측정하고, 구체적인 병목이 확인된 후에 더 복잡한 접근법을 도입하라. 90%의 사용 사례는 Advanced RAG로 충분하다.
이 글에서 조망한 RAG 생태계의 진화 방향을 몇 가지 키워드로 정리하면:
자율성의 증가 — Naive RAG의 "무조건 검색"에서, Self-RAG의 "검색 필요성 자체 판단"을 거쳐, Agentic RAG의 "전략 자체를 동적으로 설계"로. 시스템이 점점 더 스스로 판단하는 방향으로 진화하고 있다.
구조화의 심화 — 평면적 텍스트 청크에서, GraphRAG의 지식 그래프와 RAPTOR의 계층적 트리로. 정보를 단순 벡터가 아니라 구조화된 형태로 표현하는 방향이 강해지고 있다.
모듈화와 조합 — 하나의 거대한 파이프라인 대신, Modular RAG의 독립적 모듈들을 레고처럼 조합하는 방향. 이것은 RAG가 "기법"에서 "프레임워크"로 성숙하고 있음을 보여준다.
멀티모달 확장 — 텍스트만이 아니라 이미지, 테이블, 코드, 구조화된 데이터를 함께 검색하고 생성하는 멀티모달 RAG가 2025년부터 빠르게 발전하고 있다.
RAG 생태계는 여전히 빠르게 움직이고 있다. 하지만 이 글에서 다룬 핵심 패러다임들 — 구조화된 지식, 자기 판단, 에이전트 기반 전략 — 은 앞으로 어떤 새로운 변형이 나오더라도 그 기반이 될 것이다. 각 접근법이 어떤 문제를 해결하기 위해 탄생했는지를 이해하고 있으면, 새로운 기법이 등장해도 "이것이 내 상황에 필요한가?"를 명확히 판단할 수 있다.
참고 논문 및 자료