"2026년 엔터프라이즈 RAG가 무너지는 6가지 지점과 대응 청사진

2026년 엔터프라이즈 RAG가 무너지는 6가지 지점과 대응 청사진

2026년 기준 프로덕션급 RAG 시스템은 더 이상 "문서를 잘라서 벡터DB에 넣고 LLM에 던지는" 단일 경로 구조가 아닙니다. 이 글은 1세대 Naive RAG가 무너지는 6가지 지점 — 아키텍처 라우팅, 문서 파싱, 청킹, 점진적 인덱싱, 보안, 평가·관측성 — 을 차례로 짚고, 각 지점마다 어떤 결정을 내려야 하는지, 그리고 그 결정이 어디서 깨지는지를 구체 수치와 사건으로 살펴봅니다.

이 글은 엔터프라이즈 환경의 백엔드·AI 플랫폼 엔지니어가 2026년 프로덕션급 RAG 시스템의 6대 구성요소와 자주 무너지는 지점을 이해하고, PoC 설계에 바로 적용할 의사결정 체크리스트를 얻도록 돕습니다.

엔터프라이즈 환경에서 RAG는 정확도뿐 아니라 권한 제어, 운영 비용, 회귀 방지가 동시에 요구되는 시스템입니다. 컨텍스트 윈도우가 100만 토큰을 넘은 시점에도 검색 품질이 여전히 최대 병목으로 남아 있고, 동시에 맥킨지 Lilli 사건처럼 RAG 인프라가 단 2시간·$20에 뚫리는 현실도 함께 펼쳐졌습니다. 이 글은 그 둘을 같은 평면 위에 놓고 정리합니다.

이 글에서 다루는 것

• 모놀리식에서 모듈형·에이전틱 RAG로의 아키텍처 전환 흐름 (CRAG, Adaptive RAG, GraphRAG, RAPTOR)
• 고해상도 문서 파싱과 부모-자식·지연 청킹 전략
• 점진적 인덱싱(Incremental Indexing)과 HNSW 그래프 파편화 방지
• ABAC 기반 권한 인지형 검색과 사후 필터링 안티패턴
• RAG Triad 평가 프레임워크와 OpenTelemetry 관측성
• 5단계 엔터프라이즈 PoC 청사진

이 글에서 다루지 않는 것

• 특정 LLM 모델(예: GPT-4o, Claude 3.7) 자체 파인튜닝 방법
• 임베딩 모델 자체 학습·재학습 절차
• 온프레미스 GPU 클러스터 구성 및 하드웨어 사양
• 특정 클라우드 벤더(AWS/Azure/GCP)의 매니지드 RAG 서비스 비교

Naive RAG가 2026년에 무너지는 진짜 이유

Gemini 2.0 Flash가 100만 토큰, Claude 3.7이 20만 토큰 컨텍스트 윈도우를 지원하는 시대인데도 검색 정확도는 여전히 RAG 시스템의 가장 강력한 병목입니다^[8]. 일견 직관에 반하는 결과로 보일 수 있지만, 이유는 분명합니다. 방대한 컨텍스트를 무분별하게 주입하면 추론 품질이 오히려 저하되고 환각이 증가한다는 점이 실증적으로 보고됐기 때문입니다^[8]. 즉, "다 넣으면 LLM이 알아서 골라낼 것"이라는 가정은 깨졌습니다.

1세대 Naive RAG는 문서를 고정 크기로 분할·임베딩하여 벡터 DB에 저장하고, 상위 k개 결과를 LLM에 그대로 주입하는 단일 경로 구조입니다^[8]. 이 구조는 PoC 데모에서는 잘 동작하지만, 엔터프라이즈 환경에서는 세 가지 지점에서 동시에 무너집니다. 첫째, 모든 질의를 같은 자원으로 처리하기 때문에 단순 질의에는 과잉이고 복잡 질의에는 부족합니다. 둘째, 검색된 문서의 관련성을 검증하지 않으므로 노이즈가 그대로 LLM 프롬프트에 흘러들어갑니다. 셋째, 권한 검사와 평가 루프가 외부에 있어 보안 사고와 조용한 회귀가 누적됩니다.

그래서 업계의 무게 중심은 모놀리식 RAG에서 모듈형(Modular) RAG로 이동했습니다. 모듈형 RAG는 파이프라인 각 구성 요소를 독립적으로 교체·조합 가능하게 만들고, 질의 복잡도에 따라 실행 경로를 동적으로 바꿉니다^[8]. 컨텍스트 윈도우 확장이 RAG 무용론을 만들지 못한 이유도 여기에 있습니다. RAG의 본질은 "긴 문맥을 넣는 것"이 아니라 "맞는 문맥만 골라 넣는 것"이기 때문입니다.

동적 라우팅과 자가 보정 — Adaptive RAG·CRAG·GraphRAG·RAPTOR의 분기점

모든 질의에 같은 자원을 쓰는 아키텍처는 비용과 지연 시간 양쪽에서 파산합니다. Adaptive RAG는 경량 분류기로 질의 성격을 먼저 분석해, 단순 질의는 Naive RAG로, 복잡한 분석 질의는 Agentic RAG 또는 다중 홉 추론기로 동적 라우팅합니다^[8]. 분류기의 추가 비용은 작지만, 단순 질의에서 LLM 호출 횟수를 줄여 평균 지연 시간과 토큰 비용을 함께 절감합니다. 즉, "모든 질의에 최대 자원을 쓰는 대신, 필요한 만큼만 쓴다"는 단순한 원리가 핵심입니다.

CRAG(Corrective RAG)는 검색된 문서의 관련성을 명시적으로 평가하는 사후 검색 단계를 내장합니다^[8]. 관련성이 낮으면 내부 다른 저장소를 다시 뒤지거나, 그래도 부족하면 웹 검색으로 대체 경로를 잡습니다. CRAG가 깨지는 지점은 분명합니다. 평가기가 너무 관대하면 노이즈가 그대로 통과하고, 너무 엄격하면 모든 질의가 웹 검색으로 빠져 비용이 폭발합니다. 평가 임계치 튜닝이 운영 단계의 숨은 변수입니다.

GraphRAG는 Microsoft Research가 개발·오픈소스화한 방식으로, LLM을 활용해 문서에서 엔티티와 관계를 추출하고 지식 그래프를 만든 뒤 커뮤니티 단위 계층 요약을 제공합니다^[2]. 엔티티 관계 추적에 탁월하지만, 일반 RAG 대비 평균 2.3배 이상 높은 지연 시간을 유발합니다^[2]. 더 흥미로운 한계는 시간 민감형 질의입니다. 실시간 지식 업데이트가 필요한 질의에서 GraphRAG는 일반 RAG보다 오히려 13.4% 성능이 하락하는 실증이 보고됐습니다^[2]. 그래프 구축 비용이 변경 빈도를 따라가지 못하기 때문입니다.

RAPTOR(Recursive Abstractive Processing for Tree-Organized Retrieval)는 텍스트 청크를 GMM 클러스터링으로 재귀적으로 군집화·요약하여 상향식 트리를 구축하고, 추론 시 평탄화된 트리(Collapsed Tree)에서 한 번에 유사도를 계산합니다^[1]. 복잡한 다중 홉 질의에서 GPT-4와 결합 시 QuALITY 벤치마크 절대 정확도 +20%를 기록했고, 부모 계층으로 올라갈수록 처리 토큰이 절반씩 감소하는 기하급수 수렴(N + N/2 + N/4 + …) 구조라서 GraphRAG보다 비용 효율이 좋습니다^[1].

결국 GraphRAG와 RAPTOR는 경쟁이 아니라 분기점입니다. 엔티티 관계 추론이 핵심이면 GraphRAG, 장문서 다단계 추론이 핵심이면 RAPTOR로 라우팅하고, 시간 민감형이거나 단순한 질의는 Naive 경로로 흘려보내는 하이브리드 구성이 프로덕션 표준에 가깝습니다. 2026년 발표된 Higress-RAG는 이러한 Adaptive Routing·Semantic Caching·Hybrid Retrieval·CRAG를 MCP 기반 레이어드 아키텍처에 통합해 엔터프라이즈 환각 저항성을 높이는 사례를 보여줬습니다^[8].

문서 파싱과 청킹 — 데이터 품질이 답변 정확도의 천장을 결정한다

추출 계층에서 표·다단 레이아웃을 잃으면 다운스트림에서는 절대 복구되지 않습니다. 그래서 문서 파서 선택은 검색·생성보다 먼저 결정해야 하는 항목입니다. 2026년 4월 LlamaIndex가 발표한 ParseBench 기준으로, 종합 점수는 LlamaParse Agentic 71.89%, Gemini 3 Flash 71.0%, Reducto 67.8% 순입니다^[4]. 흥미로운 점은 Docling이 표 추출에서 97.9%로 1위지만 ParseBench 종합 점수에서는 포맷팅이 1.0%로 최하위라는 사실입니다^[4]. 단일 지표만 보고 선택하면 위험합니다.

운영 관점에서는 처리 속도와 컴플라이언스도 함께 봐야 합니다. LlamaParse는 문서 크기 무관하게 평균 6초의 처리 속도를 제공하지만, Unstructured는 페이지 수에 따라 51~141초가 소요됩니다^[4]. Reducto는 실제 기업 문서에서 경쟁사 대비 최대 20% 높은 추출 정확도를 제공하며, SOC 2 Type II 및 HIPAA를 준수하는 온프레미스 배포를 지원하는 유일한 엔터프라이즈 파서입니다^[4]. 즉, "정확도 최고"와 "엔터프라이즈 적합"은 같은 축이 아닙니다.

청킹 전략 역시 검색 작업의 종류에 따라 정반대 결과를 냅니다. 현재 상용 RAG의 디폴트 표준은 부모-자식 청킹입니다. 검색용 소단위(자식, 1~2문장)와 LLM 주입용 대단위(부모, 문단 크기)를 이중으로 인덱싱해 검색 정밀도와 생성 문맥 풍부성을 동시에 달성합니다^[7]. 2025년 피어리뷰 연구에 따르면 부모-자식 아키텍처는 기본 재귀 청킹 대비 +10~15% 정확도 향상을 보여줬습니다^[7].

반면 지연 청킹(Late Chunking)은 문서 전체를 롱컨텍스트 임베딩 모델로 한 번에 임베딩한 뒤 토큰 벡터를 풀링해 청크 벡터를 만드는 방식입니다^[7]. jina-embeddings-v3, Cohere Embed v4 같은 롱컨텍스트 모델이 전제입니다. 코퍼스 내 검색(In-corpus retrieval)에서는 nDCG +6.5의 향상을 보이지만, 문서 내 세부 검색(In-document retrieval)에서는 오히려 성능 저하를 일으킬 수 있습니다^[7]. 의미론적 청킹은 별도 임베딩 호출이 누적돼 비용 부담이 크다는 한계도 같이 고려해야 합니다.

# 의사 코드 — 부모-자식 청킹 인덱싱
parent_chunks = split_by_paragraph(document, max_tokens=512)
for parent in parent_chunks:
    child_chunks = split_by_sentence(parent.text, window=2)
    for child in child_chunks:
        vector_db.upsert(
            id=child.id,
            embedding=embed(child.text),
            metadata={"parent_id": parent.id, "doc_id": document.id}
        )
    # 부모는 임베딩하지 않고 별도 KV 스토어에 본문만 보관
    kv_store.put(parent.id, parent.text)

이 패턴이 그렇게 작성된 이유는 두 가지입니다. 첫째, 임베딩은 짧을수록 의미가 선명해져 검색 정밀도가 올라가지만 LLM에 그대로 주입하면 문맥이 부족합니다. 그래서 검색은 자식, 주입은 부모로 분리합니다. 둘째, 부모를 다시 임베딩하지 않고 KV 스토어에 본문만 보관하면 인덱스 크기와 임베딩 비용이 동시에 절감됩니다. 한계는 부모-자식 매핑이 깨지면 검색 결과가 잘못된 부모를 끌어오는 사일런트 버그가 생긴다는 점입니다.

점진적 인덱싱 — 벡터 DB는 정적 결과물이 아니다

매일 밤 배치 작업이 모든 문서를 다시 임베딩하다가 토큰 비용 청구서가 도착한 날, 운영팀은 점진적 인덱싱이라는 단어를 처음 듣곤 합니다. 점진적 인덱싱(Incremental Indexing)은 전체 재인덱싱 없이 변경된 문서만 탐지하여 삭제·삽입하는 운영 전략입니다^[2]. 변경 감지는 보통 SHA-256 해시 비교로 구현합니다. 문서 본문 또는 청크 단위 해시를 마지막 인덱싱 시점의 해시와 비교해, 일치하면 건너뛰고 불일치하면 해당 청크만 갱신합니다.

이때 반드시 필요한 인프라가 doc_id ↔ chunk_ids 매핑 테이블입니다. 벡터 DB만으로는 "한 문서가 어떤 청크들로 쪼개졌는지"를 안정적으로 역추적하기 어렵기 때문에, 별도 RDBMS(PostgreSQL 등)에 매핑 테이블을 두는 패턴이 권장됩니다. 매핑 테이블이 없으면 문서 한 건이 갱신될 때 해당 청크만 정밀 삭제할 방법이 사라지고, 결국 전체 재인덱싱으로 회귀합니다.

대규모 일괄 삭제는 HNSW(Hierarchical Navigable Small World) 그래프를 망가뜨립니다. HNSW는 노드 간 연결을 통해 근사 최근접 이웃(ANN) 탐색 속도를 끌어올리는데, 노드 다수가 한꺼번에 사라지면 그래프가 파편화돼 검색 품질과 속도가 조용히 죽습니다. 그래서 운영 패턴은 소프트 삭제(Soft Deletion) + 저부하 시간대 압축(Compaction)입니다^[2]. 삭제 플래그만 먼저 표시해 검색 결과에서 즉시 제외하고, 새벽 등 저부하 시간대에 그래프를 재구성합니다.

# 의사 코드 — SHA-256 기반 점진적 인덱싱
import hashlib

def incremental_index(doc_id: str, new_text: str):
    new_hash = hashlib.sha256(new_text.encode()).hexdigest()
    old_hash = mapping_db.get_hash(doc_id)
    if new_hash == old_hash:
        return  # 변경 없음

    old_chunk_ids = mapping_db.get_chunks(doc_id)
    vector_db.soft_delete(old_chunk_ids)  # 즉시 제외, 압축은 야간에
    new_chunks = chunk_and_embed(new_text)
    vector_db.upsert(new_chunks)
    mapping_db.update(doc_id, new_hash, [c.id for c in new_chunks])

이 코드의 다음 단계는 야간 압축 작업입니다. 압축 시점에 소프트 삭제된 노드를 실제로 제거하고 HNSW 그래프를 재배선하면, 운영 시간 검색 품질을 유지하면서도 그래프 파편화를 막을 수 있습니다. 한계는 매핑 테이블과 벡터 DB의 트랜잭션이 분리돼 있다는 점입니다. 두 저장소 간 일관성이 깨지면 검색되지 않는 유령 청크 또는 매핑이 없는 청크가 누적되므로, 주기적 일관성 검증 잡이 별도로 필요합니다.

권한 인지형 검색 — 맥킨지 Lilli가 2시간·$20에 뚫린 진짜 원인

2026년 3월 맥킨지의 사내 AI 플랫폼 'Lilli'가 뚫렸습니다. CodeWall의 자율 AI 에이전트가 2시간, 20달러 비용으로 프로덕션 DB 전체 읽기/쓰기 권한을 탈취했고, 4,650만 건 채팅 메시지·368만 개 RAG 청크·72만 8,000건 파일이 유출됐습니다^[3]. 더 의미심장한 사실은 공격 벡터가 최신 AI 공격 기법이 아니었다는 점입니다. 22개 비인증 API 엔드포인트 중 하나에서 JSON 필드명이 SQL에 직접 연결된 전통적 SQL 인젝션이었습니다^[3].

이 사건이 RAG 보안에 던지는 교훈은 두 가지입니다. 첫째, RAG의 가장 큰 보안 위협은 프롬프트 인젝션이 아니라 인프라 기본기입니다. 둘째, RAG가 보유한 데이터의 양과 민감도는 일반 DB와 비교가 안 됩니다. 한 번의 침투로 수천만 건의 임베딩과 원문이 동시에 빠져나갑니다. 그래서 RAG 보안은 "벡터 스코어링 이전"에 강제돼야 합니다.

사후 필터링(Post-Filtering) 안티패턴은 가장 흔한 실수입니다. 일단 ANN 검색을 돌리고, 그 결과 중 권한 없는 문서를 사후에 걸러내는 방식입니다^[7]. 구현은 단순하지만 두 가지 치명적 결함이 있습니다. 첫째, 권한 없는 문서가 ANN 스코어 계산에 이미 개입해 벡터 공간을 왜곡합니다. 이로 인해 순위 부채널(Ranking Side Channel) 공격이 가능해집니다 — 권한 없는 문서의 존재 여부가 결과 순위로 새어 나갑니다^[7]. 둘째, 크로스 인코더 재랭커에 비인가 문서가 노출돼 컴플라이언스 위반이 발생합니다.

권한 인지형 검색(Authorization-Aware Retrieval)은 벡터 스코어링이 시작되기 전에 ANN 탐색 알고리즘 계층에서 직접 보안 필터를 적용합니다^[7]. 구체적으로는 데이터베이스 네이티브 필터링을 사용합니다. Milvus는 expr='tenant_id == "acme" && array_contains(allowed_roles, "hr_admin")' 형태의 불리언 표현식을 ANN 탐색 계층에서 직접 적용하고, Elasticsearch는 KNN 쿼리 내부에 filter 블록을 통합해 스코어링 이전에 데이터 접근 범위를 제한합니다^[7]. Weaviate의 Filter.by_property 역시 같은 계열의 사전 필터링입니다.

권한 모델 자체는 RBAC보다 ABAC(Attribute-Based Access Control)가 적합합니다. ABAC는 사용자의 부서·지역·고용 형태와 문서의 기밀 등급·법적 보존 상태 등 다중 속성의 교집합을 실시간 평가하므로, 다중 리소스 엔터프라이즈 환경에서 정책 폭증을 막을 수 있습니다^[7]. 또한 ABAC 메타데이터를 청크 단위로 기록해 두면 GDPR 대응에도 구조적 이점이 생깁니다. 모델 가중치를 변경하지 않고도, 특정 사용자·문서 범위의 청크를 격리하거나 삭제할 수 있기 때문입니다.

평가와 관측성 — LLM은 비결정론적이고, 어제의 답변은 오늘 깨진다

프롬프트를 한 줄 바꿨더니 답변이 망가졌다 — 이때 어느 단계에서 무너졌는지 30분 안에 답할 수 있는가가 프로덕션 RAG의 분기점입니다. 개발자의 직감으로는 불가능합니다. 그래서 등장한 것이 RAG Triad입니다. TruEra(현 Snowflake 생태계)가 주도한 평가 3요소로, 문맥 관련성(Context Relevance)·사실 기반성(Groundedness/Faithfulness)·답변 관련성(Answer Relevance)을 분리해 측정합니다^[5]. 세 지표를 따로 보면 환각의 원인이 검색에 있는지, 생성에 있는지, 질의 해석에 있는지 추적할 수 있습니다.

운영 도구는 계층적으로 쌓입니다. RAGAS는 Ground Truth 없이 4개 지표(Faithfulness, Answer Relevancy, Context Precision, Context Recall)를 평가하는 참조 독립형 경량 패키지로, 하이퍼파라미터 튜닝 중 빠른 피드백에 최적입니다^[5]. DeepEval은 50개 이상의 지표를 Pytest와 네이티브 통합해 RAG Triad 점수가 임계치(예: 0.95) 미달 시 CI/CD 파이프라인에서 자동으로 배포를 차단하는 게이트 역할을 합니다^[5]. TruLens는 Snowflake 생태계에 편입된 OpenTelemetry 기반 분산 추적 기능으로, 파이프라인 중 정확히 어느 노드(재랭커, 검색 노드)에서 성능 저하가 발생했는지 시각 진단합니다^[5].

분산 추적의 표준은 OpenTelemetry(OTel)입니다. CNCF가 관리하는 분산 추적·메트릭 표준으로, LLMOps 영역에서 벤더 종속을 끊는 계측 표준으로 자리잡았습니다^[6]. 예컨대 Langfuse는 OpenTelemetry Backend로 동작해 /api/public/otel OTLP 엔드포인트로 트레이스를 수신하며, 단일 OTel SDK로 Langfuse·LangSmith·Datadog·New Relic 등 다수 백엔드 중 설정 변경만으로 전환 가능합니다^[6]. 즉, 코드를 한 줄도 바꾸지 않고도 관측성 백엔드를 갈아 끼울 수 있습니다.

한계도 솔직하게 인정해야 합니다. OTel의 GenAI 컨벤션은 2024년 중반 안정화(stable)됐지만, 아직 모든 도구가 동일한 시맨틱 속성을 지원하지는 않습니다^[6]. 따라서 도입 초기에는 일부 속성을 자체 정의해 메우는 임시 매핑이 필요합니다. 이 한계는 시간이 해결할 문제지만, 2026년 시점에서는 도구별 호환성 매트릭스를 PoC 단계에 한 번 확인해야 합니다.

🔤 용어 사전

처음 보는 단어가 있다면 여기서 의미를 확인하세요.

RAG (Retrieval-Augmented Generation)

검색으로 찾은 문서를 LLM 답변 생성에 함께 사용해 정확도를 높이는 기법입니다.

LLM (Large Language Model)

대규모 텍스트 데이터로 학습한 대형 언어 모델로, 질문에 자연어로 답변을 생성합니다.

HNSW (Hierarchical Navigable Small World)

벡터 DB에서 유사한 항목을 빠르게 찾기 위한 그래프 기반 근사 탐색 구조입니다.

ABAC (Attribute-Based Access Control)

사용자 속성(부서·직급 등)과 문서 속성(기밀 등급 등)을 조합해 접근 권한을 동적으로 결정하는 방식입니다.

RAPTOR (Recursive Abstractive Processing for Tree-Organized Retrieval)

문서를 계층적으로 요약한 트리 구조로 인덱싱해 장문서 다단계 질의를 효율적으로 처리하는 RAG 방식입니다.

CRAG (Corrective RAG)

검색된 문서의 관련성을 평가해 부족하면 다른 저장소나 웹 검색으로 자동 보완하는 RAG 방식입니다.

GraphRAG

문서에서 엔티티(사람·조직·개념)와 관계를 추출해 지식 그래프를 만들고 이를 검색에 활용하는 방식입니다.

임베딩

텍스트나 이미지의 의미를 숫자 배열로 변환한 표현으로, 벡터 DB에 저장해 유사도 검색에 사용합니다.

OpenTelemetry (OTel)

분산 시스템의 트레이스·메트릭·로그를 수집하는 오픈소스 표준으로, 특정 벤더 없이 다양한 관측 도구에 연결됩니다.

정리 — 5단계 PoC 청사진 의사결정 체크리스트

월요일 아침, 팀에게 "우리도 RAG 도입합시다"라는 말이 떨어졌다고 가정해 봅시다. 첫 회의에서 무엇을 결정해야 할까요. 위 6개 지점은 독립 결정이 아니라 하나의 PoC 청사진으로 연결됩니다. 다음 5단계를 자신의 환경에 매핑해 가장 약한 단계부터 점검하는 것을 권장합니다.

1단계 — 이중 파서 라우팅: 표·다단 레이아웃이 중요한 문서는 Docling으로(표 추출 97.9%^[4]), 빠른 처리와 종합 점수가 중요한 일반 문서는 LlamaParse로(평균 6초, 종합 71.89%^[4]) 라우팅합니다. 컴플라이언스가 결정적이면 Reducto(SOC 2 Type II·HIPAA^[4])를 후보에 포함합니다. 단일 파서로 시작하지 않는 이유는 단일 지표가 가리는 약점이 있기 때문입니다.

2단계 — 부모-자식 청킹 + 외부 매핑 테이블: 자식 청크(1~2문장)는 임베딩해 벡터 DB에, 부모 청크(문단)는 KV 스토어에 본문만 보관합니다^[7]. 동시에 별도 RDBMS에 doc_id ↔ chunk_ids 매핑 테이블을 만들어 점진적 인덱싱·정밀 삭제의 기반을 미리 깔아둡니다. 이 단계를 PoC에서 생략하면 운영 단계에서 재설계가 필요합니다.

3단계 — ABAC 메타데이터 강제 주입: 모든 청크에 부서·기밀 등급·법적 보존 상태 등 속성을 메타데이터로 기록합니다^[7]. 검색은 반드시 ANN 탐색 계층 내부의 사전 필터(Milvus boolean expr, Elasticsearch KNN filter, Weaviate Filter.by_property)로 강제합니다. 사후 필터링은 PoC에서도 허용하지 않는 편이 안전합니다. 맥킨지 Lilli 사건이 보여주듯, 보안 계층은 처음부터 ANN 안쪽에 있어야 합니다^[3].

4단계 — 라우팅 그래프 구성: Adaptive 분류기 → 질의 유형별 라우팅으로 흐름을 그립니다. 단순 사실 질의는 Naive, 엔티티 관계 질의는 GraphRAG, 장문서 다단계 추론은 RAPTOR, 검색 품질 검증이 필요한 경로에는 CRAG를 끼웁니다. LangGraph 같은 워크플로우 도구로 이 그래프를 명시적으로 그려두면 디버깅과 확장이 쉬워집니다. GraphRAG의 2.3배 지연·13.4% 성능 하락(시간 민감형)^[2] 같은 한계는 라우터 단계에서 회피합니다.

5단계 — OTel 계측 + DeepEval CI/CD 게이트: OpenTelemetry GenAI 컨벤션으로 파이프라인 전체를 계측하고^[6], DeepEval로 RAG Triad 임계치(예: 0.95)를 CI/CD에 박아 회귀 시 배포 자체를 차단합니다^[5]. 프로덕션 진단은 TruLens, 빠른 개발 이터레이션은 RAGAS로 보완합니다. 평가 체계가 없으면 어제의 답변이 오늘 깨진 것을 한 달 뒤에 알게 됩니다.

자신의 팀에서 가장 약한 단계 한 곳부터 시작해 단계적으로 보강하는 편이, 6개 지점을 한 번에 다 잡으려는 시도보다 훨씬 빠르게 결과를 만듭니다. 2026년의 엔터프라이즈 RAG는 "어떤 LLM을 쓰느냐"보다 "이 6개 지점에서 어떤 결정을 내렸느냐"로 품질이 갈리기 때문입니다.

---

1. Sarthi et al., "RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval," arXiv:2401.18059, 2024. https://arxiv.org/abs/2401.18059 ↩
2. Microsoft Research, "Project GraphRAG." https://www.microsoft.com/en-us/research/project/graphrag/ ↩
3. Outpost24, "How an AI Agent Hacked McKinsey's AI Platform," 2026. https://outpost24.com/blog/ai-agent-hacked-mckinsey-ai-platform/ ↩
4. Reducto, "Docling vs LlamaParse vs Unstructured vs Reducto: Document Parser Comparison," 2025-2026. https://llms.reducto.ai/document-parser-comparison ↩
5. Atlan, "RAGAS, TruLens, DeepEval: LLM Evaluation Frameworks," 2026. https://atlan.com/know/llm-evaluation-frameworks-compared/ ↩
6. Langfuse, "OpenTelemetry (OTEL) for LLM Observability." https://langfuse.com/integrations/native/opentelemetry ↩
7. "Secure RAG: Authorisation-Aware Retrieval and Row-Level Security," Medium, 2026. https://photokheecher.medium.com/secure-rag-authorisation-aware-retrieval-and-row-level-security-c6542500ec21 ↩
8. Humanloop, "8 Retrieval Augmented Generation (RAG) Architectures You Should Know in 2025." https://humanloop.com/blog/rag-architectures ↩