GraphRAG: 환각(Hallucination)을 줄이고 복잡한 워크플로우를 자동화하는 엔드투엔드 가이드

한 컴플라이언스(Compliance) 팀이 AI 어시스턴트에게 간단한 질문을 던집니다: "이번 분기 모든 사고 전반에 걸쳐 반복되는 근본 원인은 무엇이며, 이들을 연결하는 정책적 공백은 무엇인가요?"

표준 RAG(Retrieval-Augmented Generation)는 벡터 유사성(Vector Similarity)을 기반으로 가장 유사한 5개의 사고 보고서를 검색합니다. 그리고 유창한 요약을 생성합니다. 하지만 이 요약은 패턴을 완전히 놓칩니다. 왜냐하면 그 패턴은 단일 문서 안에 존재하지 않기 때문입니다. 패턴은 단 한 번의 검색 과정으로는 결코 함께 드러낼 수 없는 40개 문서 사이의 관계 속에 존재합니다.

이것이 바로 GraphRAG가 해결하기 위해 만들어진 전형적인 실패 사례입니다.

더 나은 청크(Chunk)를 검색함으로써 해결하는 것이 아닙니다. 완전히 다른 종류의 것, 즉 엔티티(Entity)와 그들 사이의 관계를 구조화한 지도를 검색함으로써 해결합니다. 이는 인간 분석가가 복잡한 질문을 통해 실제로 추론하는 방식과 동일하게 탐색됩니다.

이 글은 GraphRAG에 대한 완전한 엔드투엔드(End-to-End) 가이드입니다. GraphRAG가 어떻게 작동하는지, 어떻게 환각(Hallucination)을 줄이는지, 어떻게 다단계 워크플로우를 자동화하는지, 그리고 정확히 언제 그 훨씬 더 높은 비용을 지불할 가치가 있는지에 대해 다룹니다.

벡터 RAG(Vector RAG)가 한계에 부딪히는 이유
GraphRAG의 실체
단계별 인덱싱 파이프라인(Indexing Pipeline) 설명
GraphRAG의 검색 방식: 로컬(Local) vs 글로벌(Global) 검색
GraphRAG가 환각(Hallucination)을 줄이는 방법
아무도 말하지 않는 추론 병목 현상(Reasoning Bottleneck)
GraphRAG vs LightRAG vs HippoRAG vs PathRAG
실제 프로덕션 벤치마크 수치
GraphRAG가 워크플로우를 자동화하는 방법
비용 현실과 의사결정 프레임워크

1. 벡터 RAG(Vector RAG)가 한계에 부딪히는 이유

표준 RAG는 지식 베이스를 독립적인 청크(Chunk)들의 더미로 취급합니다. 각 청크는 벡터(Vector)로 임베딩(Embedding)됩니다. 질의(Query) 또한 임베딩됩니다. 질의 벡터와 가장 가까운 청크들이 검색되어 모델에 전달됩니다.

질문에 대한 답이 단일 청크 또는 소수의 유사한 청크 안에 들어있을 때는 이 방식이 매우 효과적으로 작동합니다. "파손된 품목에 대한 환불 정책은 무엇인가요?"라는 질문의 경우, 파손 품목 환불에 관한 정책 문서 청크는 질의와 의미론적으로 가깝습니다. 벡터 RAG는 이를 안정적으로 찾아냅니다.

이 장벽은 두 가지 범주의 질문과 함께 나타납니다:

멀티홉 질문 (Multi-hop questions). "지난달 인프라 팀이 수행한 데이터베이스 마이그레이션으로 인해 발생한 장애의 영향을 받은 고객은 누구인가요?"라는 질문의 경우, 답변을 위해서는 마이그레이션 기록, 장애 보고서, 영향받은 시스템 목록, 고객 계정 데이터베이스라는 네 개의 서로 다른 문서에 걸친 네 개의 개별 사실을 연결해야 합니다. 단일 청크(chunk)에는 이 연결 고리가 포함되어 있지 않습니다. 또한 이들은 서로 의미론적으로 유사한 것이 아니라 인과적이고 관계적으로 연결되어 있기 때문에, 벡터 유사도 검색(vector similarity search)으로는 이 네 개의 청크를 한꺼번에 검색할 수 없습니다.

글로벌 질문 (Global questions). "이 5,000개의 고객 리뷰 전반에 걸친 주요 테마는 무엇인가요?"라는 질문의 경우, "주요 테마"라는 내용을 담고 있는 청크는 존재하지 않습니다. 답변을 위해서는 전체 코퍼스(corpus)를 가로질러 정보를 종합해야 합니다. 벡터 RAG는 질의에 가장 가까운 청크만을 가져올 수 있을 뿐, 모든 정보를 한꺼번에 아우르며 추론할 수 있는 메커니즘이 없습니다.

GraphRAG는 바로 이 두 가지 범주를 위해 특별히 구축되었습니다. GraphRAG는 벡터 RAG를 대체하는 것이 아닙니다. 벡터 RAG가 구조적으로 제공할 수 없는 구조적 계층(structural layer)을 추가하는 것입니다.

2. GraphRAG의 실체

GraphRAG는 검색 증강 생성 (RAG, Retrieval-Augmented Generation)에 지식 그래프 (knowledge graph) 계층을 추가합니다. 벡터 유사도에 따라 유사한 텍스트 청크를 찾는 대신, 엔티티(entity) — 사람, 회사, 제품, 정책, 사건, 개념 — 사이의 관계를 탐색하여 문맥적으로 연결된 정보를 검색합니다.

Microsoft의 GraphRAG 프로젝트가 개척한 이 아키텍처는 인덱싱 (indexing)과 쿼리 (querying)라는 두 가지 별개의 단계로 작동합니다.

인덱싱 (indexing) 단계 동안, 시스템은 전체 문서 코퍼스 (corpus)를 한 번 처리합니다. LLM은 엔티티와 그들 사이의 관계를 추출하여 지식 그래프를 구축합니다. 그런 다음 그래프는 계층적 커뮤니티 (hierarchical communities)로 클러스터링됩니다. 이는 일관된 주제나 테마를 나타내는 긴밀하게 연결된 엔티티 그룹입니다. 각 커뮤니티는 매우 구체적인 수준부터 광범위한 테마 수준에 이르기까지 다양한 수준의 세밀도 (granularity)로 요약됩니다.

쿼리(Querying) 과정에서 시스템은 이 미리 구축된 그래프와 커뮤니티 요약(community summaries)을 사용하여 벡터 검색(vector search)만으로는 도달할 수 없는 질문에 답합니다. 즉, 그래프의 관계 구조를 통해 문서 간의 정보를 연결하거나, 커뮤니티 요약을 가로질러 종합함으로써 전체 코퍼스(corpus)에 대한 전역적인 질문(global questions)에 답합니다.

근본적인 변화: 벡터 RAG는 "이 쿼리와 유사한 텍스트가 무엇인가?"라고 묻습니다. 반면 GraphRAG는 "이 쿼리가 어떤 엔티티(entities)를 건드리고 있으며, 그것들과 연결된 것은 무엇인가?"라고 묻습니다.

3. 인덱싱 파이프라인(Indexing Pipeline) 단계별 설명

인덱싱 파이프라인을 상세히 이해하는 것은 매우 중요합니다. 왜냐하면 이곳이 GraphRAG의 비용, 지연 시간(latency), 그리고 품질 특성이 결정되는 지점이기 때문입니다.

1단계 — 텍스트 청킹 (Text chunking). 코퍼스는 벡터 RAG와 유사하게 관리 가능한 단위로 분할됩니다. 여기서 청크 크기(Chunk size)는 벡터 RAG에서보다 더 중요합니다. 엔티티 추출(entity extraction) 품질이 청크 내의 관계를 식별할 수 있는 충분한 문맥(context)을 확보하는 데 달려 있기 때문입니다.

2단계 — 엔티티 및 관계 추출 (Entity and relationship extraction). 이 단계는 가장 비용이 많이 드는 단계이며 GraphRAG 비용의 주요 원인입니다. LLM이 각 청크를 처리하여 엔티티(이름이 있는 사람, 조직, 제품, 개념 등)를 추출하고, 이들 사이의 관계 및 각 관계에 대한 설명을 함께 추출합니다. 500페이지 분량의 코퍼스의 경우, 이 단일 단계가 전체 인덱싱 토큰의 약 58%를 소비합니다.

3단계 — 그래프 구축 (Graph construction). 추출된 엔티티와 관계는 그래프 구조로 조립됩니다. 여러 청크에 걸쳐 언급된 동일한 엔티티(예: "Acme Corp", "Acme Corporation", "the company")는 단일 그래프 노드(node)로 해결(resolved)되어야 합니다. 엔티티 해결(Entity resolution)의 품질이 그래프의 품질을 직접적으로 결정합니다.

4단계 — 커뮤니티 탐지 (Community detection). 그래프는 밀접하게 상호 연결된 엔티티(Entity) 그룹을 식별하는 Leiden 커뮤니티 탐지 (Leiden community detection)와 같은 알고리즘을 사용하여 클러스터링(Clustering)됩니다. 이러한 커뮤니티는 일관된 주제를 나타냅니다. 예를 들어, 하나의 제품 라인과 그와 관련된 이슈들, 하나의 부서와 그 부서의 주요 인력 및 프로젝트, 혹은 하나의 규제 프레임워크와 이를 실행하는 정책 등이 이에 해당합니다.

5단계 — 계층적 요약 (Hierarchical summarization). 각 커뮤니티는 계층 구조의 여러 수준에서 LLM에 의해 요약됩니다. 이는 작고 구체적인 커뮤니티부터 광범위한 최상위 테마에 이르기까지 포함됩니다. 이것이 바로 글로벌 쿼리 (Global queries)를 가능하게 하는 핵심입니다. 즉, 시스템이 모든 문서를 일일이 읽는 대신, 이미 합성된 지식을 나타내는 커뮤니티 요약본을 읽을 수 있게 됩니다.

이 파이프라인의 비용적 결과: 500페이지 분량의 코퍼스 (Corpus)를 기준으로, Microsoft GraphRAG의 인덱싱 (Indexing) 비용은 50달러에서 200달러 사이이며 약 45분이 소요됩니다. 동일한 코퍼스에 대한 표준 벡터 RAG 임베딩 (Vector RAG embedding) 비용은 5달러 미만입니다. 엔터프라이즈 규모에서 Microsoft의 2024년 GraphRAG 구현 사례를 보면, 대규모 코퍼스를 인덱싱하는 데 약 33,000달러가 소요되었습니다.

이 비용은 일회성으로 발생하는 불편함이 아닙니다. 이는 GraphRAG를 채택할 때 직면하게 되는 핵심적인 경제적 결정 사항이며, 동시에 7절에서 다룰 2026년의 대안적 아키텍처들이 존재하는 이유이기도 합니다.

4. GraphRAG의 검색 방식: 로컬 검색 vs 글로벌 검색

그래프와 커뮤니티 요약이 구축되면, GraphRAG는 1절에서 언급한 두 가지 실패 범주에 직접적으로 대응하는 두 가지 별개의 쿼리 모드를 지원합니다.

**로컬 검색 (Local search)**은 엔티티 중심(entity-centric) 및 멀티홉(multi-hop) 질문을 처리합니다. 쿼리가 주어지면 시스템은 관련 엔티티를 식별한 다음, 해당 엔티티로부터 그래프를 바깥쪽으로 탐색하며 관계를 따라 연결된 컨텍스트를 수집합니다. "결제 게이트웨이(payment gateway)에 의존하는 서비스에 의해 영향을 받은 고객은 누구인가요?"라는 질문의 경우, 로컬 검색은 "결제 게이트웨이" 엔티티에서 시작하여 "의존함 (depends on)" 관계를 통해 연결된 서비스들을 찾고, 다시 "사용함 (uses)" 관계를 탐색하여 연결된 고객들을 찾아냅니다. 이러한 멀티홉 탐색은 단일 임베딩 (embedding)이 전체 체인을 포착하기를 기대하는 방식이 아니라, 명시적인 그래프 에지 (graph edges)를 통해 이루어집니다.

**글로벌 검색 (Global search)**은 주제 중심 및 코퍼스 전반 (corpus-wide)에 걸친 질문을 처리합니다. 특정 엔티티로부터 그래프를 탐색하는 대신, 시스템은 미리 계산된 커뮤니티 요약 (community summaries)을 가로질러 정보를 검색하고 합성합니다. "이번 분기 모든 장애 사례에서 반복되는 근본 원인은 무엇인가요?"라는 질문의 경우, 글로벌 검색은 "근본 원인 (root causes)"에 관한 문서를 검색하는 것이 아닙니다. 대신 관련 장애 사례들을 이미 함께 클러스터링해 놓은 커뮤니티 요약들을 읽고, 그 요약들로부터 답변을 합성합니다. 이는 검색 (retrieval)과는 근본적으로 다른 작업입니다.

이러한 이중 모드 설계 덕분에 GraphRAG는 멀티홉 추론 (multi-hop reasoning)과 글로벌 요약 (global summarization)을 모두 가능하게 한다고 설명됩니다. 이 두 가지 능력은 벡터 RAG (vector RAG)와 GraphRAG 사이의 격차를 정의하는 핵심 요소입니다.

5. GraphRAG가 환각 (Hallucination)을 줄이는 방법

GraphRAG에서의 환각 감소는 프롬프팅 기술 (prompting technique)이 아닌 구조적 특성에서 비롯됩니다. 즉, 모델이 단절된 텍스트 청크 (text chunks)로부터 관계를 암시적으로 재구성하는 대신, 사실과 관계가 명시적이고 추적 가능한 그래프 위에서 추론하기 때문입니다.

추적 가능성 메커니즘 (The traceability mechanism). 그래프 내의 모든 엔티티 (Entity)와 관계 (Relationship)는 인덱싱 (Indexing) 과정에서 특정 소스 문서로부터 추출되었습니다. GraphRAG가 질문에 답하기 위해 그래프를 통한 경로를 검색할 때, 해당 경로는 소스 문서로 거슬러 올라가 추적될 수 있습니다. 이는 모델이 "엔티티 A가 엔티티 B와 관련이 있다"라고 추론하는 것이 아니라, 인덱싱 과정에서 추출되고 검증되었으며 원문으로의 출처 (Provenance)가 확인된 명시적 관계를 보여주는 것임을 의미합니다.

벤치마크 증거 (The benchmark evidence). 기업용 벤치마크에서 Microsoft의 계층적 커뮤니티 접근 방식 (Hierarchical community approach)은 86%의 정확도를 달성한 반면, 베이스라인 벡터 RAG (Baseline vector RAG)는 32%에 그쳤습니다. 이는 벡터 RAG의 암시적 재구성 (Implicit reconstruction)이 가장 자주 오류를 범하는 유형인 멀티홉 (Multi-hop) 및 관계형 질문에서 54%포인트의 격차를 보인 것입니다.

온톨로지 접지 메커니즘 (The ontology-grounding mechanism). GraphRAG의 온톨로지 접지 변형 모델인 OG-RAG는 엔티티 및 관계 추출을 자유 형식 (Free-form)으로 허용하는 대신 미리 정의된 스키마 (Schema)로 제한합니다. 이러한 스키마 제한 추출은 환각 (Hallucination)을 약 40% 감소시키는데, 그 이유는 모델이 도메인 온톨로지 (Domain ontology)에 정의되지 않은 관계 유형을 추출하거나 추론할 수 없기 때문입니다. 이를 통해 그럴듯하게 들리지만 조작된 관계라는 범주 자체를 제거할 수 있습니다.

더 넓은 RAG 맥락. GraphRAG가 개선하고자 하는 기초적인 문제에 근거하여 이를 살펴볼 가치가 있습니다. 대규모 언어 모델 (LLM)은 다양한 작업에서 일반적으로 3~20% 범위로 보고되는 기초 환각 (Hallucination) 발생률로 조작되거나 부정확한 진술을 생성하며, 데이터가 희소한 도메인이거나 모순된 입력을 처리할 때 그 비율이 현저히 높아집니다. 표준 RAG는 이를 상당히 감소시킵니다. 한 교차 모델 연구에 따르면, 평균 환각률이 RAG 적용 전 50%에서 RAG 적용 후 13.9%로 떨어졌으며, 이는 평균 36%포인트의 개선을 의미합니다. GraphRAG의 구조적 추적 가능성 (Structural traceability)은 멀티홉 (Multi-hop) 및 관계형 환각의 특정 범주를 벡터 RAG (Vector RAG)가 도달할 수 있는 수준보다 더 낮게 밀어냅니다. 이는 바로 벡터 RAG의 "최근접 청크 (Nearest chunk)" 메커니즘이 가장 취약한 근거를 제공하는 범주가 바로 해당 카테고리들이기 때문입니다.

중요한 주의 사항 — 검색 품질이 전부는 아닙니다. 선도적인 GraphRAG 시스템인 KET-RAG를 세 가지 멀티홉 질의응답 (QA) 벤치마크에서 평가한 2026년 연구에 따르면, 질문의 77~~91%가 검색된 컨텍스트 어딘가에 정답을 포함하고 있었음에도 불구하고, 최종 정확도는 35~~78%에 불과했습니다. 오류의 73~84%는 검색 실패가 아닌 추론 실패 (Reasoning failures)였습니다. GraphRAG는 검색 문제를 해결했습니다. 하지만 그 검색 위에 놓인 추론 문제까지 자동으로 해결하지는 못했습니다. 이것이 이 블로그 전체에서 가장 중요한 뉘앙스이며, 별도의 섹션으로 다룰 가치가 있습니다.

6. 아무도 말하지 않는 추론 병목 현상 (The Reasoning Bottleneck)

GraphRAG에 관한 대부분의 논의는 "더 나은 검색을 수행한다"에서 멈춥니다. 2026년의 연구는 더 나은 검색이 필요조건이지만 충분조건은 아니라는 점을 명확히 합니다.

검색-추론 간극 (retrieval-reasoning gap)은 다음과 같이 작동합니다: GraphRAG의 그래프 탐색 (graph traversal)은 대다수의 경우 모델의 컨텍스트 (context) 내에 정확한 사실과 관계를 성공적으로 노출합니다. 하지만 컨텍스트 내에 올바른 사실이 있다고 해서 모델이 이를 바탕으로 올바른 답변을 생성하도록 정확하게 추론 (reasoning)한다는 것을 보장하지는 않습니다. 모델은 5-홉 체인 (five-hop chain)의 다섯 가지 요소를 모두 컨텍스트 윈도우 (context window)에 가지고 있더라도, 특히 홉 (hop)의 수가 증가함에 따라 이들을 올바르게 연결하는 데 실패할 수 있습니다.

현재 연구에서 제시하는 두 가지 완화 방법 (mitigations)은 이 간극을 직접적으로 다룹니다: