티스토리 뷰
RAG 아키텍처 발전사 3편 - Modular / Self-Corrective RAG: 스스로 판단하고 교정하는 파이프라인
ebson 2026. 3. 6. 18:42이 글은 RAG 아키텍처 발전사 시리즈의 세 번째 편입니다. 이전 편에서 2세대 Advanced RAG의 네 가지 기법(Hybrid Search, Reranker, RAPTOR, Tree RAG)이 검색 품질을 어떻게 향상시켰는지 살펴보았고, 이번 편에서는 그 다음 단계인 3세대 Modular / Self-Corrective RAG를 다룹니다. 시리즈는 이후 3.5세대 Ontology-Enhanced RAG, 4세대 Agentic RAG로 이어질 예정입니다.
2세대가 해결하지 못한 것
2세대 Advanced RAG는 "더 좋은 문서를 더 정확하게 가져오는 것"에 성공했습니다. Hybrid Search로 검색 커버리지를 넓히고, Reranker로 정밀도를 높이며, RAPTOR와 Tree RAG로 검색 대상의 구조적 깊이를 확보했습니다. 그러나 이 기법들은 파이프라인의 각 단계를 독립적으로 개선한 것이지, 단계 간의 통합적 의사결정을 도입한 것은 아니었습니다.
검색된 문서가 정말 질의에 관련이 있는지 시스템 스스로 판단하지 못했고, 검색 결과가 전반적으로 저품질인 경우 대안적 경로로 전환하는 교정 메커니즘도 없었습니다. 이번 질의에 외부 검색이 정말 필요한지, 아니면 모델의 내부 지식만으로 충분한지를 판단하는 로직도 부재했습니다.
3세대의 핵심 전환은 이 지점에서 발생합니다. "더 좋은 문서를 가져오는 것"에서 "가져온 문서가 정말 쓸 만한지 판단하고, 문제가 있으면 스스로 교정하는 것"으로의 이동입니다. 자기 성찰, 자기 교정, 적응적 라우팅, 구조적 검색, 모듈화라는 다섯 가지 키워드가 이 세대를 관통합니다.
Self-RAG: 검색할지 말지를 모델이 판단한다
기존 RAG 시스템의 가장 단순한 비효율 중 하나는, 모든 질의에 대해 예외 없이 검색을 수행한다는 것이었습니다. "대한민국의 수도는?"이라는 질문에도 벡터 DB를 조회하고, "양자역학의 관측 문제에 대한 코펜하겐 해석과 다세계 해석의 차이를 설명해달라"는 질문에도 동일한 Top-k 검색을 수행합니다. 전자의 경우 검색이 불필요한 노이즈만 유입시키고, 후자의 경우 단일 검색으로는 충분한 맥락을 확보하지 못할 수 있습니다.
Asai et al. (2023)이 제안한 Self-RAG(ICLR 2024 Oral, arXiv:2310.11511)는 이 문제에 대해 근본적으로 다른 접근을 취했습니다. 검색 여부, 검색 결과의 품질, 생성 결과의 품질을 LLM 스스로 판단하도록 만든 것입니다.
Self-RAG의 핵심 메커니즘은 Reflection Token이라는 특수 토큰입니다. 단일 언어모델을 학습시켜, 생성 과정 중에 여러 종류의 특수 토큰을 출력하도록 합니다. 이 토큰들은 현재 시점에서 외부 검색이 필요한지 여부를 판단하고, 검색된 문서가 질의에 관련 있는지를 평가하며, 생성된 답변이 검색 문서에 의해 뒷받침되는지를 검증하고, 최종 응답의 유용성을 평가하는 역할을 각각 담당합니다. 논문에서는 이 토큰들을 검색 판단, 관련성 평가, 뒷받침 여부 평가, 유용성 평가의 네 단계로 구분하고 있습니다 (Asai et al., 2023).
이 네 단계의 비평이 각 검색 문서에 대해 병렬로 수행되고, Segment-level Beam Search를 통해 Critique 토큰의 가중 확률에 기반하여 최적의 출력 세그먼트가 선택됩니다. 검색이 불필요하다고 판단된 경우에는 검색 없이 생성한 세그먼트도 후보에 포함되어, 검색 유무에 관계없이 가장 품질이 높은 출력이 최종 결과가 됩니다.
실험 결과에서 Self-RAG(7B, 13B)는 ChatGPT, Llama2-chat, Retrieval-augmented Llama2-chat을 포함한 기존 모델들을 다양한 태스크에서 유의미하게 능가했습니다. 특히 흥미로운 점은, 추론 시점에 Reflection Token을 통해 LM이 태스크 요구사항에 맞게 동작을 조정할 수 있다는 것입니다 (Asai et al., 2023).
그러나 Self-RAG에도 한계는 있었습니다. Reflection Token을 생성하도록 모델을 학습시키려면 별도의 Critic 모델과 그에 따른 학습 데이터가 필요합니다. 더 중요한 한계는, Self-RAG가 검색 여부를 판단하고 검색 결과를 평가할 수는 있지만, 검색 결과가 전반적으로 저품질인 경우에 이를 적극적으로 교정하는 메커니즘은 갖추고 있지 않다는 점입니다. 검색된 문서가 관련 없다고 판단하면 해당 문서를 무시할 수는 있지만, 더 나은 문서를 찾기 위한 대안적 검색 경로를 제시하지는 않습니다. 이 한계가 CRAG의 등장 배경이 됩니다.
CRAG: 검색이 실패하면 웹에서 찾는다
Self-RAG가 "검색할 것인가, 말 것인가"를 판단하는 데 집중했다면, CRAG(Corrective RAG)는 한 단계 더 나아가 "검색 결과가 부족하면 어떻게 교정할 것인가"라는 질문에 답합니다.
Yan et al. (2024, arXiv:2401.15884)이 제안한 CRAG의 구조는 명확한 의사결정 분기를 중심으로 설계되어 있습니다. 질의에 대해 Retriever가 문서를 검색하면, 경량 Retrieval Evaluator가 각 문서의 관련성을 평가합니다. 이 평가 결과에 따라 파이프라인은 검색 결과의 신뢰도 수준별로 분기됩니다.
검색된 문서의 관련성이 충분히 높다고 판정되면, 검색 문서를 그대로 사용하지 않고 Decompose-then-Recompose라는 정제 과정을 거칩니다. 검색된 문서를 세분화된 지식 단위(knowledge strip)로 분해하고, 각 단위의 관련성을 다시 평가하여 핵심 정보만 선별적으로 추출한 뒤 재구성하는 것입니다. 이를 통해 검색 문서에 포함된 노이즈를 걸러낼 수 있습니다.
검색 결과가 신뢰할 수 없다고 판정되면, CRAG는 내부 검색 결과를 폐기하고 대안적 경로인 웹 검색으로 전환합니다. 원래 질의를 키워드 기반 검색 쿼리로 재작성하고, 웹 검색을 통해 문서를 수집한 뒤, 동일한 Decompose-then-Recompose 정제를 적용합니다.
판정이 모호한 경우에는 내부 검색의 정제 결과와 웹 검색 결과를 함께 활용합니다.
4개 데이터셋(Short-form 및 Long-form 생성 태스크)에서 CRAG는 기존 RAG 대비 유의미한 성능 향상을 보였습니다. 특히 주목할 점은 Plug-and-play 설계입니다. CRAG의 Retrieval Evaluator와 교정 메커니즘은 특정 RAG 아키텍처에 종속되지 않고, 다양한 기존 RAG 접근법 위에 결합할 수 있도록 설계되었습니다 (Yan et al., 2024).
CRAG의 한계는 외부 웹 검색에 대한 의존에서 비롯됩니다. 검색 결과가 신뢰할 수 없다고 판정될 때 웹 검색으로 전환하는 구조는 응답 지연 시간을 증가시키며, 폐쇄망 환경에서는 이 경로 자체를 사용할 수 없습니다. 또한 전체 파이프라인의 성능이 Retrieval Evaluator의 판별 정확도에 직결된다는 점도 고려해야 합니다. 그리고 Self-RAG, CRAG, Hybrid Search, Reranker 등 개별 기법들이 쏟아져 나오면서, 이들을 체계적으로 조합하는 프레임워크의 필요성이 대두되었습니다. 이것이 Modular RAG의 등장 배경입니다.
Adaptive-RAG: 질의 복잡도에 맞는 최소한의 검색
Self-RAG와 CRAG가 검색 결과를 사후에 평가하고 교정하는 데 집중했다면, Adaptive-RAG는 관점을 반대로 뒤집었습니다. 검색 결과가 나온 뒤에 판단하는 것이 아니라, 질의 자체의 복잡도에 따라 검색 전략을 사전에 결정하는 것입니다.
Jeong et al. (2024, NAACL, arXiv:2403.14403)의 핵심 관찰은 단순합니다. 단순한 질의에 복잡한 다단계 검색을 적용하면 불필요한 비용이 발생하고, 복잡한 질의에 단순 검색을 적용하면 답변 품질이 저하됩니다. 질의의 복잡도와 검색 전략의 강도가 일치해야 효율성과 정확도를 동시에 확보할 수 있다는 것입니다.
Adaptive-RAG는 소형 언어모델 기반의 분류기(classifier)를 두어 질의 복잡도를 자동 분류하고, 복잡도에 따라 검색 전략을 동적으로 선택합니다. 단순한 질의는 LLM의 내부 지식만으로 직접 답변하며 검색을 수행하지 않고, 중간 복잡도의 질의에는 단일 검색 후 답변을 생성하며, 복잡한 질의에는 검색-추론-재검색을 반복하는 다단계 검색을 적용합니다.
이 분류기의 학습 방식도 흥미롭습니다. 수동으로 레이블을 부여하는 대신, 각 검색 전략을 실제로 적용했을 때의 예측 결과와 데이터셋의 귀납적 편향으로부터 레이블을 자동 수집합니다 (Jeong et al., 2024). 다양한 복잡도의 Open-domain QA 데이터셋에서 기존 적응적 검색 접근법 대비 전체적인 효율성과 정확도가 모두 향상되었다는 실험 결과가 보고되었습니다.
Adaptive-RAG의 한계는 분류기의 정확도에 전체 파이프라인이 종속된다는 점입니다. 복잡한 질의를 단순하다고 잘못 판단하면 답변 품질이 크게 저하되고, 반대의 경우에는 불필요한 비용이 발생합니다. 또한 사전 정의된 복잡도 구분이 모든 질의 유형을 포괄하기에는 유연성이 부족할 수 있습니다. 그리고 Adaptive-RAG는 검색 전략의 선택에 집중할 뿐, 검색 결과 자체의 품질을 교정하는 메커니즘은 포함하지 않습니다.
Graph RAG: 전역 질의에 대한 구조적 응답
앞서 다룬 Self-RAG, CRAG, Adaptive-RAG가 검색 과정의 판단과 교정에 초점을 맞추었다면, Graph RAG는 검색 대상 자체를 근본적으로 다른 형태로 구축하는 접근입니다.
기존 RAG 시스템의 벡터 기반 검색은 질의와 의미적으로 유사한 개별 텍스트 청크를 찾아내는 지역적(local) 검색에 특화되어 있습니다. "프로젝트 X의 2분기 매출은 얼마인가?"와 같은 구체적인 사실 질의에는 이 방식이 효과적입니다. 그러나 "이 데이터셋의 주요 테마는 무엇인가?", "조직 전체에서 가장 빈번하게 논의되는 이슈는?" 같은 전역적(global) 질의에는 개별 청크의 유사도 검색만으로는 대응하기 어렵
습니다. 이런 질의는 데이터 전체를 관통하는 구조적 이해를 필요로 하기 때문입니다.
Edge et al. (2024, Microsoft Research, arXiv:2404.16130)이 제안한 Graph RAG는 이 문제를 Knowledge Graph와 커뮤니티 기반 요약으로 해결합니다.
인덱싱 단계에서 소스 문서를 청크로 분할한 뒤, LLM을 사용하여 각 청크에서 엔티티(노드)와 관계(엣지)를 추출합니다. 추출된 엔티티와 관계로 Knowledge Graph를 구축하고, Leiden 알고리즘으로 이 그래프에서 계층적 커뮤니티를 탐지합니다. 가장 거시적인 Level 0부터 가장 미시적인 Level N까지 여러 해상도의 커뮤니티가 식별되며, 각 커뮤니티에 대해 LLM이 요약을 사전 생성합니다.
질의 시에는 Map-Reduce 방식으로 응답을 구성합니다. Map 단계에서 각 커뮤니티 요약을 LLM에 전달하여 부분 답변과 유용성 점수를 생성하고, Reduce 단계에서 유용성 점수가 높은 부분 답변들을 토큰 한도까지 결합한 뒤 LLM이 최종 전역 답변을 합성합니다.
실험 결과는 특히 전역 질의에서 인상적이었습니다. 100만 토큰 규모 데이터셋에서 기존 벡터 RAG 대비 포괄성(Comprehensiveness)과 다양성(Diversity) 모두에서 상당한 개선을 달성한 것으로 보고되었습니다 (Edge et al., 2024). Knowledge Graph의 커뮤니티 구조가 전역 질의에 대한 효율적인 정보 조직 수단으로 기능한 것입니다.
Graph RAG의 한계는 인덱싱 비용에 있습니다. 모든 청크에서 LLM으로 엔티티와 관계를 추출해야 하므로, Knowledge Graph 구축 단계의 LLM 호출 비용이 상당합니다. 엔티티/관계 추출의 품질이 LLM의 성능에 직접 의존한다는 점도 고려해야 합니다. 또한 Graph RAG가 전역 질의에서 강점을 보이는 반면, 구체적인 사실을 찾는 지역적 세부 질의에서는 기존 벡터 RAG가 여전히 더 효과적일 수 있습니다.
Modular RAG: 모든 기법을 하나의 프레임워크로
Self-RAG, CRAG, Adaptive-RAG, Graph RAG, 그리고 이전 세대의 Hybrid Search, Reranker, RAPTOR까지, RAG 기법들이 빠르게 쏟아져 나오면서, 한 가지 질문이 떠오릅니다. 이 기법들을 어떻게 체계적으로 이해하고, 필요에 따라 조합할 수 있을까? 단순한 "Retrieve-then-Generate"라는 프레임으로는 이 다양한 방법론들을 통합적으로 설명하기 어려워졌습니다.
Gao et al. (2024, arXiv:2407.21059)이 제안한 Modular RAG는 이 질문에 대한 답으로, RAG 시스템을 LEGO 블록처럼 재구성 가능한 프레임워크로 분해합니다. 개별 기법의 성능 향상을 목표로 한 것이 아니라, 기존과 미래의 모든 RAG 기법을 수용할 수 있는 분류 체계와 설계 원칙을 확립한 것이 핵심 기여입니다.
Modular RAG는 RAG 시스템을 독립 모듈과 특수 오퍼레이터로 분해합니다. 문서 분할과 인덱싱, 검색 전 쿼리 최적화, 검색기 선택과 실행, 검색 후 정제, 생성, 그리고 전체 흐름 제어 등 각 단계가 독립적인 모듈로 구성됩니다.
이 프레임워크의 강점은 기존 기법들을 흐름 패턴으로 통합하여 설명할 수 있다는 점입니다. Naive RAG는 순차 실행하는 Linear 패턴입니다. CRAG는 Retrieval Evaluator의 판정에 따라 서로 다른 파이프라인으로 분기하는 Conditional 패턴입니다. 여러 검색기를 병렬 실행한 뒤 결과를 합산하는 것은 Branching 패턴이고, Self-RAG처럼 생성 결과가 불만족스러우면 검색을 반복하는 것은 Looping 패턴입니다. 새로운 RAG 기법이 등장하더라도 해당 모듈만 교체하거나 추가하면 되므로, 프레임워크 차원의 확장성이 확보됩니다 (Gao et al., 2024).
Modular RAG의 한계는 모듈 간의 최적 조합을 자동으로 탐색하는 메커니즘이 없다는 점입니다. 어떤 모듈을 어떤 순서로 어떤 설정으로 조합할지는 여전히 설계자의 판단에 의존합니다. 또한 모듈 수가 증가할수록 가능한 조합의 수가 급격히 늘어나면서 설계 복잡도가 상승합니다. 이 지점에서 자연스럽게 떠오르는 아이디어가 있습니다. LLM이 오케스트레이터 역할을 수행하여, 모듈의 선택과 조합을 동적으로 결정하는 것. 이것이 바로 4세대 Agentic RAG로의 진화 가능성입니다.
3세대가 남긴 것
이 세대의 다섯 기법을 관통하는 공통점은, 파이프라인의 각 단계에 지능적 판단을 도입했다는 것입니다. Self-RAG는 검색 필요성과 결과 품질을, CRAG는 검색 실패 여부와 교정 경로를, Adaptive-RAG는 질의 복잡도에 맞는 전략을, Graph RAG는 전역적 맥락의 구조적 표현을, Modular RAG는 기법들의 체계적 조합과 흐름 제어를 각각 담당합니다. 2세대가 파이프라인의 각 단계를 독립적으로 개선했다면, 3세대는 단계 간의 의사결정과 피드백 루프를 만들어낸 것입니다.
그러나 이 기법들도 여전히 사전 설계된 흐름에 의존합니다. Self-RAG의 Reflection Token 순서, CRAG의 신뢰도 기반 분기, Adaptive-RAG의 복잡도 구분, 모두 설계 시점에 정해진 규칙입니다. 실행 중에 예상치 못한 상황이 발생했을 때 파이프라인 자체를 동적으로 재구성하는 것은 불가능합니다. Modular RAG가 모듈의 재조합 가능성을 열어두었지만, 그 조합을 결정하는 것은 여전히 사람의 몫입니다.
또한, 이 세대의 기법들은 도메인의 구조적 지식을 명시적으로 반영하지 못한다는 한계도 있습니다. Graph RAG가 Knowledge Graph를 구축하긴 하지만, 이는 텍스트에서 자동 추출된 엔티티/관계 그래프이지, 도메인 전문가가 정의한 온톨로지(개념 간의 의미적 관계, 계층 구조, 제약 조건)를 체계적으로 활용하는 것과는 다릅니다.
정리하며
3세대의 기법들을 정리하면서 인상적이었던 것은, 각 기법이 이전 기법의 한계를 매우 구체적으로 짚고 그에 대한 해법을 제시하는 연쇄적 발전 구조입니다. Naive RAG의 무조건적 검색 → Self-RAG의 검색 판단 → Self-RAG의 저품질 검색 교정 부재 → CRAG의 검색 실패 교정 → CRAG의 개별 기법 조합 프레임워크 부재 → Modular RAG의 모듈화. 하나의 한계가 다음 기법의 등장을 촉발하는 이 흐름은, RAG가 단일 아이디어의 반복 개선이 아니라 패러다임 수준에서 진화해왔음을 보여줍니다.
동시에, 3세대까지 와서도 해결되지 않은 두 가지 과제가 남아 있습니다. 하나는 도메인의 온톨로지를 검색 과정에 명시적으로 반영하는 것이고, 다른 하나는 사전 설계된 정적 파이프라인의 한계를 넘어 LLM이 스스로 실행 계획을 수립하고 도구를 선택하는 자율적 시스템으로 나아가는 것입니다. 다음 편에서는 이 두 가지 과제에 각각 대응하는 3.5세대 Ontology-Enhanced RAG와 4세대 Agentic RAG를 다루겠습니다.
References
- Asai, A., Wu, Z., Wang, Y., Sil, A., & Hajishirzi, H. (2023). Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ICLR 2024. arXiv:2310.11511
- Yan, S.-Q., Gu, J.-C., Zhu, Y., & Ling, Z.-H. (2024). Corrective Retrieval Augmented Generation. arXiv:2401.15884
- Jeong, S., Baek, J., Cho, S., Hwang, S. J., & Park, J. C. (2024). Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity. NAACL 2024. arXiv:2403.14403
- Edge, D., Trinh, H., Cheng, N., et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. Microsoft Research. arXiv:2404.16130
- Gao, Y., Xiong, Y., Wang, M., & Wang, H. (2024). Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks. arXiv:2407.21059
- Gao, Y., Xiong, Y., Gao, X., et al. (2024). Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997
'TECH AND AI' 카테고리의 다른 글
| RAG 아키텍처 발전사 4편 - Agentic RAG: 에이전트가 파이프라인을 설계한다 (0) | 2026.03.06 |
|---|---|
| RAG 아키텍처 발전사 번외편 - Ontology-Enhanced RAG: 도메인 지식의 구조를 검색에 심다 (0) | 2026.03.06 |
| RAG 아키텍처 발전사 2편 - Advanced RAG: 검색 품질을 높이기 위한 네 가지 접근 (0) | 2026.03.06 |
| /RAG 아키텍처 발전사 1편 - Naive RAG: 검색 증강 생성의 시작점 (0) | 2026.03.06 |
| MongoDB Hybrid Search 완전 정리: $vectorSearch, $rankFusion, $scoreFusion 공식 문서 기반 분석 (0) | 2026.02.14 |
- Total
- Today
- Yesterday
- 캐시 장애
- Spring Batch
- DB 인덱스 성능
- 트래픽 처리
- Hot Key 문제
- Double-Checked Locking
- TTL 설계
- 백엔드 성능 튜닝
- Cache Avalanche
- Enum 기반 싱글톤
- Java Performance
- InterruptedException
- 캐시와 인덱스
- Redis 성능 개선
- Initialization-on-Demand Holder Idiom
- spring batch 5
- 스레드 생명주기
- Redis 캐시 전략
- 백엔드 성능
- mybatis
- Cache Aside
- 백엔드 성능 설계
- Cache Penetration
- 캐시 성능 비교
- Eager Initialization
- Redis vs DB
- 트랜잭션 관리
- DB 트랜잭션
- 백엔드 아키텍처
- 동시성처리
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |

