단순 RAG가 당신에게 거짓말을 합니다. 실제 프로덕션 환경에서 살아남는 7가지 아키텍처

모두가 처음 구축하는 RAG 파이프라인은 동일합니다. 문서를 청크(chunk)로 나누고, 임베딩(embed)한 다음, 코사인 유사도(cosine similarity)로 상위 몇 개를 검색하여 프롬프트에 넣고 모델이 답변하게 하는 방식입니다. 시연할 때는 매우 잘 작동하며, 답변도 그럴듯합니다. 그리고 당신은 그것을 출시합니다.

그러다가 실제로 중요한 질문이 들어오면 잘못된 청크를 가져옵니다. 혹은 올바른 문서를 찾았지만 필요한 단락 하나를 놓칩니다. 또는 답변 자체가 데이터베이스에 있는데 모델이 전혀 볼 수 없는 경우도 있습니다.

아무것도 고장 난 것이 아닙니다. 파이프라인은 당신이 구축하도록 설계된 대로 정확하게 작동하고 있는 것입니다. 그것이 문제입니다.

당신이 구축한 것은 **단순 RAG(Naive RAG)**이며, 이것이 쓸모없다는 뜻은 아닙니다. 시작점일 뿐입니다. 하지만 문서를 벡터 데이터베이스에 넣는 것이 쉬운 절반이라면, 올바른 정보를 모델의 컨텍스트 윈도우(context window)로 가져오는 것이 진짜 작업이며, 단순 RAG는 이 작업을 겨우 시도할 정도입니다.

이 글을 유용하게 만드는 재정립은 다음과 같습니다. '만능 고급 RAG'라는 것은 없습니다. 일곱 가지의 개별적인 아키텍처가 존재하며, 각각은 검색(retrieval)이 특정 방식으로 실패하기 때문에 존재합니다. 잘못된 것을 선택하면 아무것도 아닌데 비용과 지연 시간(latency)만 추가하게 됩니다. 따라서 목록을 보기 전에, 실패하는 방식을 이름 붙이는 법부터 배워야 합니다.

검색이 실제로 실패하는 다섯 가지 방식

1. 어휘 불일치(Vocabulary mismatch). 사용자가

아래 각 아키텍처는 이 중 하나 또는 두 가지를 목표로 합니다. 이를 매칭하면 불필요한 복잡성을 맹목적으로 도입하는 것을 막을 수 있습니다.

1. 하이브리드 검색 (Hybrid Search) + 재순위 지정 (Reranking)

해결 과제: 어휘 불일치(vocabulary mismatch)

이것은 더 화려한 기술을 추구하기 전에 모두가 해야 할 업그레이드이며, 대부분의 사람들은 에이전트(agents)를 쫓느라 이를 건너뜁니다. 순수 벡터 검색은 의미론적입니다: "cancel" ≈ "terminate"와 같은 유사성은 뛰어나지만, 오류 코드나 희귀한 성과 같은 정확한 일치에는 취약합니다. **하이브리드 검색(Hybrid search)**은 밀집 벡터 검색(dense vector search)과 고전적인 키워드 검색(BM25)을 실행하고 그 결과를 융합하며, 보통 Reciprocal Rank Fusion을 사용하여 문서가 나타나는 목록 전체에 걸쳐 1 / (k + rank)를 합산하여 각 문서를 점수화합니다. 밀집 벡터는 의미를 포착하고; BM25는 임베딩이 부드럽게 처리해버린 문자 그대로의 토큰(literal token)을 포착합니다.

그런 다음 **재순위 지정(rerank)**을 합니다. 검색은 속도에 맞춰 조정되므로 너무 많은 후보군(예: 150개)을 가져오고, 더 느린 크로스 인코더(cross-encoder)가 이를 질의와 비교하여 재점수화하고 가장 좋은 20개를 유지합니다. 크로스 인코더는 질의와 문서를 함께 읽기 때문에, 바이인코더 임베딩이 놓치는 관련성을 포착할 수 있습니다.

사용 시점: 항상. 이것은 고급 기술이 아니라 기본적인 필수 조건입니다(table stakes). 만약 귀하의 RAG에 재순위 지정기가 없다면, 다음 내용을 읽기 전에 이를 수정하십시오.

2. 질의 변환 (Query Transformation)

해결 과제: 질문이 답이 아니다

사용자가 작성한 짧고 지저분한 질문은 답변과 전혀 관련 없는 곳에 임베딩됩니다. 따라서 검색하기 전에 질문을 다시 작성합니다. 네 가지 유형이 있습니다:

• Multi-query: LLM에게 질문을 3~4가지 방식으로 재구성(rephrase)하도록 요청하고, 모든 재구성된 질문으로 검색한 뒤 결과를 병합합니다. 원래 질문이 놓쳤던 각도를 포착할 수 있습니다.
• RAG-Fusion: Multi-query에 더해 결합된 결과에 대해 Reciprocal Rank Fusion을 적용합니다. 여러 가지 재구성을 거치면서 표면화되는 문서들이 상위에 노출됩니다. 원본 연구의 주의사항: 생성된 질문이 주제에서 벗어나면 답변도 그 방향으로 흐를 수 있습니다.
• HyDE (Hypothetical Document Embeddings): _질문_을 임베딩하는 대신, LLM에게 가짜 _답변_을 작성하도록 요청한 다음, 이를 임베딩하여 검색에 사용합니다. 가상의 답변은 질문보다 실제 문서와 훨씬 유사해 보입니다. 잘못된 가설을 생성할 수 있으므로 리랭킹(reranking)과 함께 사용하는 것이 좋습니다.
• Step-back prompting: 좁은 질문에 대해 먼저 더 일반적인 질문(

4. 계층적 검색 (Hierarchical Retrieval, RAPTOR)

해결책: 답변은 문서 전체에 걸쳐 있다

평면적인 청킹(Flat chunking)은 답변이 하나의 구절 안에 존재한다고 가정합니다. '이 80페이지 보고서의 전반적인 주장은 무엇인가?'와 같은 질문에는 단일 청크로는 담을 수 없습니다. RAPTOR는 트리를 구축합니다: 관련 청크들을 클러스터링하고, 각 클러스터를 요약하며, 그 요약들을 다시 클러스터링하고, 그것들을 또 요약하는 식으로 위로 올라갑니다. 쿼리 시간이 되면 여러 레벨에 걸쳐 검색하므로, 미세한 세부 사항을 가져올 수도 있고 높은 수준의 종합(high-level synthesis)을 가져올 수도 있습니다.

해당 논문은 GPT-4와 함께 QuALITY 벤치마크(장문 QA)에서 약 20포인트의 절대 정확도 향상을 보고했습니다. 이를 해당 논문의 데이터셋에 대한 결과로 받아들이시고, 여러분의 코퍼스에 대한 보장으로 생각하지 마십시오.

사용 시점: 질문이 여러 섹션, 계약서, 연구 논문, 신고서, 기술 매뉴얼에 걸쳐 있는 길고 구조화된 문서. FAQ에는 과도한 방법입니다.

5. 그래프 RAG (GraphRAG)

해결책: 관계적이고 코퍼스 전체의 질문

벡터 RAG는 관계를 인식하지 못합니다. '이 두 사람이 어떻게 연결되어 있는가', '우리 모든 사고 보고서에 걸쳐 어떤 주제들이 흐르고 있는가'와 같은 것들은 유사성(similarity)을 묻는 질문이 아니며, top-k 검색으로는 찾아낼 수 없습니다. Microsoft의 GraphRAG는 LLM을 사용하여 개체(entities)와 관계(relationships)를 지식 그래프(knowledge graph)로 추출한 다음, 커뮤니티 감지(community detection, Leiden 알고리즘)를 실행하여 그래프를 클러스터링하고 각 클러스터를 바텀업 방식으로 사전 요약합니다.

두 가지 모드: **로컬 검색(local search)**은 질문 근처의 엔티티에서 시작하여 그래프를 따라 이동하며 (저렴하고, 종종 LLM 호출 1회만 필요합니다). **글로벌 검색(Global search)**은 모든 커뮤니티 요약본을 매핑 축소(map-reducing)하여 "어떤 주제들이 있는지"에 답하는 방식으로, 강력하지만 비용이 많이 듭니다. 한 테스트 트레이스에서는 단일 글로벌 쿼리에 대해 10개 이상의 LLM 호출과 약 200K 토큰이 소요된 반면, 로컬 쿼리에는 약 11,500 토큰만 소요되었습니다.

주의할 점: 인덱싱(indexing). 그래프를 구축하는 과정은 코퍼스 전체에 걸쳐 수백 번의 LLM 호출을 선행해야 합니다. Microsoft는 이를 줄이기 위해 나중에 LazyGraphRAG를 출시했습니다. 관계성 및 글로벌 종합이 실제 작업인 경우, 그리고 코퍼스가 인덱싱 비용을 상쇄할 만큼 안정적일 때 사용하세요. 도움말 데스크에 적용해서는 안 됩니다.

6. Self-RAG와 Corrective RAG

개선점: 검색 후에도 여전히 틀릴 수 있음

때로는 검색 과정에서 확신에 찬 오답(garbage)이 반환되고 모델이 이를 바탕으로 답변을 생성합니다. 이 두 가지 기법은 검증 단계를 추가합니다.

Self-RAG는 모델에게 "성찰 토큰(reflection tokens)"을 방출하도록 훈련시킵니다. 즉, 검색할지 여부를 결정하고, 각 구절의 관련성을 판단하며, 자신의 답변이 실제로 뒷받침되는지 비평합니다. 이 판단 과정은 모델 내부에 존재합니다.

**Corrective RAG (CRAG)**는 판단 과정을 외부에 배치합니다. 경량 평가기(lightweight evaluator)가 검색된 문서를 정확한지, 모호한지, 부정확한지 점수를 매깁니다. 점수가 낮으면 진행하지 않고, 더 나은 출처를 찾기 위해 폴백(fallback, 일반적으로 웹 검색)을 트리거합니다. Self-RAG는 훈련된 토큰이 필요하기 때문에, CRAG가 기존 파이프라인에 통합하는 것이 더 쉽습니다.

사용 시점: "확신에 찬 오답"보다 "검증할 수 없습니다"라는 답변이 더 위험한 고위험(high-stakes) 답변, 지원, 규정 준수(compliance), 의료, 법률 분야. 쿼리당 추가적인 지연 시간(latency) 비용이 발생하므로, 이 비용을 감수할 가치가 있는 질문에만 사용해야 합니다.

7. Agentic RAG (및 적응형 라우팅)

개선점: 단일 파이프라인으로는 모든 쿼리를 처리할 수 없음

위의 여섯 가지는 도구입니다. **에이전트 기반 RAG (Agentic RAG)**는 이 도구들을 선택하고 연결하는 워크플로우입니다. 단순히 한 번 검색(retrieve) 후 답변을 생성하는 방식 대신, 에이전트는 계획합니다: 무엇을 찾아볼지 결정하고, 검색하며, 그것으로 충분했는지 확인하고, 더 나은 쿼리로 다시 검색하거나, 어쩌면 두 번째 인덱스를 호출하고, 답변하기 전에 검증합니다. 이를 통해 다단계 질문(Multi-step questions)이 가능해집니다.

위험성은 무엇일까요? 모든 쿼리에 대해 에이전트 루프를 실행하는 것은 느리고 비용이 많이 들며, 대부분의 질문에는 그럴 필요가 없습니다. 이것이 바로 새롭게 등장하는 2026년 기본 방식인 **어댑티브 RAG (Adaptive RAG)**입니다: 저렴한 분류기(classifier)가 앞에 위치하여 각 쿼리를 답변할 수 있는 가장 가벼운 파이프라인으로 라우팅합니다. 단순 조회 → 하이브리드 검색. 관계형 → 그래프. 다단계 → 에이전트. 질문이 요구하는 경우에만 복잡성에 비용을 지불하게 됩니다.

전체 지도 (The whole map)

| # | 아키텍처 | 해결하는 실패 사례 | 비용 |
| :--- | :--- | :--- |
| 1 | 하이브리드 + 재순위화(Hybrid + Reranking) | 임베딩이 놓치는 정확한 용어 | 낮음 · 항상 적용해야 함 |
| ... |

그렇다면 무엇을 구축할까요?

모두 아닙니다. 순서대로 따르는 정직한 결정 규칙은 다음과 같습니다:

1. 누구나: 하이브리드 검색 + 재순위화(reranking). 이것을 건너뛰면 다른 어떤 것도 중요하지 않습니다.
2. 검색 결과가 여전히 불완전한가요? 쿼리 변환(query transformation)을 추가하세요. 호출이 하나 더 필요합니다.
3. 청크의 의미를 잃어가나요? 문맥적 검색(contextual retrieval)을 추가하세요. 목록에서 비용 대비 효용성이 가장 좋습니다.
4. 질문이 전체 문서에 걸쳐 있나요? RAPTOR를 사용하세요.
5. 질문이 관계적이거나 코퍼스 전반인가요? 인덱싱 비용을 감당할 수 있다면 GraphRAG를 사용하세요.
6. 확신하는 잘못된 답변이 피해를 주나요? CRAG 또는 Self-RAG를 사용하세요.
7. 하나의 제품에 여러 유형의 쿼리가 있나요? 어댑티브 라우팅(adaptive routing)을 앞에 배치하여 디스패치하게 하세요.

여기서 제시된 수치들에 대한 하나의 주의사항이 있습니다. 컨텍스트 기반 검색(contextual-retrieval) 성능 하락, RAPTOR의 QuALITY 향상분, GraphRAG의 토큰 비용 등은 하나의 통제된 전면 비교 벤치마크에서 나온 것이 아니라, 개별 논문이나 공급업체 게시물에서 가져온 것입니다. 이 일곱 가지 아키텍처를 모두 동일한 코퍼스로 실행하는 깔끔한 2026년 연구는 존재하지 않습니다. 이것들을 방향성 지표로 간주하고, 결정적인 역할을 하는 유일한 벤치마크를 수행하세요. 즉, 사용자로부터 실제 질문 10개를 가져와서, 정답이 무엇인지 정의하고, 그 기준에 맞춰 아키텍처들을 테스트하는 것입니다.

프로토타입 데모와 프로덕션 RAG를 구분 짓는 능력은 가장 화려한 아키텍처를 아는 것이 아닙니다. 다섯 가지 실패 유형 중 어느 것이 자신에게 해당하는지 진단하고, 그것을 해결할 수 있는 단 하나의 도구를 찾아내는 것입니다. 단순한(Naive) RAG가 조용히 당신을 실패하게 만들었습니다. 그 해결책은 '어떻게' 실패했는지 이름을 붙이는 것에서 시작됩니다.

출처: Anthropic,