GraphRAG는 정말 Vector RAG보다 우수한가 — 자신의 문서 1만 건으로 비교한 결과

「Vector RAG는 이제 구식이다, 앞으로는 GraphRAG다」라는 기사를 저는 2024년부터 계속 지켜보고 있습니다.

Microsoft Research의 논문도 GraphRAG의 포괄성이 +26%, 다양성이 +57%라는 화려한 수치를 제시하고 있습니다. 하지만 제 주변의 실무 엔지니어 중 「GraphRAG를 실무에 도입했다」는 사람은 생각보다 적습니다.

이유는 두 가지라고 느끼고 있었습니다. (1) 구축 비용이 높다, (2) 단순한 사실 검색에서는 패배하는 케이스가 있다. 이를 직접 확인하지 않으면 납득할 수 없기에, 저의 문서 약 1만 건 (블로그 포스트 + 기술 메모 + Slack 이력)을 사용하여 Vector RAG와 GraphRAG (Microsoft 버전) 그리고 LightRAG 세 가지를 나란히 놓고 검증했습니다.

이 기사에서는 그 결과와 어떤 유스케이스에서 GraphRAG를 채택해야 하는지를 비용 수치와 함께 작성하겠습니다.

가볍게 복습해 보겠습니다.

질문 → 임베딩 벡터화 (Embedding) → 유사 문서 상위 N건 검색
→ LLM에 "이것들을 참고해서 답해줘"라고 전달

심플하고 저렴하며 빠릅니다. pgvector나 ChromaDB로 간편하게 만들 수 있습니다.

[인덱스 시]
문서 → LLM이 엔티티 (Entity)와 관계 (Relationship)를 추출
→ 지식 그래프 (Knowledge Graph) 구축
...

문서를 단순한 「텍스트 덩어리」가 아니라, 엔티티와 관계의 네트워크로 취급합니다.

질문 타입	Vector RAG	GraphRAG
「X란 무엇인가」(단일 사실)	특기	서투름 (오버킬)
「X와 Y의 차이는」(비교)	보통	특기
「X와 관련된 모든 프로젝트를 알려줘」(조망)	서투름	특기
「이 리포지토리 전체의 테마는」(집약)	불가능	특기
「ABCD 4자의 관계성은」(다단계 추론)	서투름	특기

이것이 이론적인 전제입니다. 문제는 실제 데이터에서 정말로 이 차이가 나타나는가 하는 점입니다.

저의 지난 5년 치 문서. 내역:

• 개인 블로그 포스트: 320개
• Zenn / Qiita 기사: 180개
• 기술 메모 / 설계 문서: 6,200개 파일
• Slack 채널 로그 (export): 약 3,300개 스레드

합계 약 1만 건의 텍스트 단위, 약 45MB, 약 800만 토큰.

3가지 패턴 구축:

• Vector RAG (Baseline): pgvector + OpenAI text-embedding-3-small
• GraphRAG (Microsoft 버전): 공식 리포지토리 (microsoft/graphrag)로 구축
• LightRAG: HKUDS 버전 (HKUDS/LightRAG)

질문 타입별로 50문항씩, 총 250문항을 준비.

질문 타입	예시
단일 사실 (50문항)	「Whisper v3 Turbo의 RTF는 얼마인가?"
...	각 답변은 인간 (나) 이 4단계 평가: 0=엉뚱함, 1=부분적, 2=거의 정답, 3=완전 정답。

1만 건의 코퍼스 (Corpus)를 인덱싱하는 시점에서의 비용 비교입니다.

엔진	소요 시간	API 과금	로컬 계산 부하
Vector RAG (pgvector)	약 12분	$3.20	CPU 부하 거의 없음
GraphRAG (Microsoft)	약 8시간	$184.50	LLM 호출 7,200회
LightRAG (HKUDS)	약 2시간	$42.80	LLM 호출 1,800회

GraphRAG의 57배 비용입니다.

참고: paperclipped.de/en/blog/graph-rag-production에서도 「10배~40배의 인덱스 비용」이라고 보고되어 있으며, 저의 실측치와도 대체로 일치합니다.

쿼리 시의 비용은 거의 동일합니다 ($0.001~$0.005/쿼리). 차이는 인덱싱 시점에 집중됩니다.

GraphRAG를 제대로 작동시키려면, **최소한 본방 LLM (GPT-4o 또는 Claude Sonnet)**이 필요합니다. GPT-4o-mini나 Haiku를 사용하면 엔티티 추출 (Entity Extraction) 품질이 떨어지고, Leiden 클러스터링 (Leiden Clustering) 결과가 무너집니다. 비용 최적화를 위해 모델을 낮추면, GraphRAG의 장점 자체가 사라집니다.

이것이 본론입니다.

질문 유형	Vector RAG	LightRAG	GraphRAG
단일 사실	86%	78%	72%
비교	64%	76%	84%
조망 (Overview)	38%	64%	88%
...	종합 평균	47%	66%

결론: GraphRAG는 「단일 사실」에서는 Vector RAG에 지지만, 그 외의 4가지 유형에서는 압도적으로 승리한다. LightRAG는 중간 단계다.

이는 Microsoft 논문의 경향 (포괄성 +26% / 다양성 +57%)과 동일한 방향의 결과입니다.

GraphRAG는 커뮤니티 요약을 통해 답변합니다. 커뮤니티 요약은 **추상화된 요약 (Abstracted Summary)**이므로, "Whisper v3 Turbo의 RTF는 1300배"와 같은 특정 수치가 요약 과정에서 "Whisper v3 Turbo는 매우 빠름"과 같이 뭉뚱그려질 수 있습니다.

Vector RAG는 원래의 청크 (Chunk)를 그대로 전달하므로, 수치나 고유명사를 유지하는 데 강점이 있습니다.

"과거에 작성한 음성 AI 관련 기사를 모두 알려줘"와 같은 조망형 질문은 코퍼스 (Corpus) 전체를 스캔하지 않으면 답할 수 없습니다. Vector RAG는 "쿼리에 유사한 상위 N개"만을 반환하기 때문에, 관련 기사의 절반 이상을 놓치게 됩니다.

GraphRAG는 커뮤니티 단위로 요약하고 있기 때문에, "음성 AI에 관한 커뮤니티"를 통째로 가져올 수 있습니다.

실측 결과와 구축 비용을 나열한 뒤, 저의 판단 기준을 적겠습니다.

GraphRAG를 선택해야 하는 경우

• 사용자 질문의 절반 이상이 「조망」 「집약」 「다단계 추론 (Multi-step Reasoning)」 유형일 것
• 코퍼스의 인덱싱 비용 ($100~$1,000)을 허용할 수 있을 것
• 문서 추가가 **배치 업데이트 (Batch Update)**로 충분할 것 (실시간 추가가 빈번한 용도에는 부적합)
• 도메인 지식의 온톨로지 (Ontology, 엔티티의 타입 정의)를 사전에 설계할 인력이 있을 것

Vector RAG를 선택해야 하는 경우

• 질문이 개별 사실 검색 중심일 것
• 인덱싱 비용을 최소화하고 싶을 것
• 문서가 빈번하게 추가 및 업데이트될 것
• 프로토타입 단계에서 우선 작동하는 것을 빠르게 내놓고 싶을 것

제3의 선택지 (Hybrid/Alternative)

• GraphRAG의 혜택은 원하지만, Microsoft 버전의 비용은 부담스러울 때
• Leiden 클러스터링을 건너뛰고, 엔티티 단위의 검색만으로 충분할 때
• 프로덕션 통계가 적은 것을 수용할 수 있을 때 (아직 채택 사례가 적음)

참고: agentmarketcap.ai/.../graph-rag-vs-vector-rag-agent-memory 에 따르면, 에이전트 메모리 용도로는 Neo4j 기반의 Graph RAG가 pgvector를 다단계 추론에서 앞선다고 합니다. 저의 검증 결과와도 일치합니다.

저는 장기 기억이 필요한 것과 즉각적인 응답성이 필요한 것을 나누고 있습니다.

[Vector RAG (pgvector)]
- 개별 사실 검색
- 최신 문서 (24시간 이내)
...

하이브리드 방식으로 구성함으로써, Vector RAG의 저비용+고속 응답과 GraphRAG의 조망·집약 능력을 모두 챙기고 있습니다.

질문이 들어오면, 먼저 쿼리의 유형을 판정 → 단일 사실이면 Vector, 그 외에는 GraphRAG로 보내는 라우팅 (Routing) 방식입니다. 판정 자체는 GPT-4o-mini로도 충분한 정확도가 나옵니다.

3개월간 운용하며 초기 설계에서는 깨닫지 못했던 함정을 공유합니다.

매일 업데이트가 필요한 문서를 GraphRAG에 올리면, 월 API 과금이 5만~10만 엔을 넘기 시작합니다. 저는 처음에 이를 간과했다가 월 ¥87,000의 청구서를 받았습니다.

GraphRAG는 주간~월간 업데이트로 운용하는 것이라고 선을 긋는 것이 안전합니다.

"Claude Code", "claude code", "Claude-code", "클로드"가 모두 별개의 엔티티가 됩니다. LLM 추출은 캐주얼하게 흔들리기 때문에, 후처리에서의 정규화 (Normalization)가 필수입니다.

저의 그래프에는 Claude Code가 7가지 표기법으로 나열되어 있었고, 처음 이를 발견했을 때는 조용히 화면을 닫았습니다.

저는 엔티티(Entity) 이름을 OpenAI Embedding → 유사도 0.92 이상일 때 동일시하는 후처리(Post-process) 과정을 넣고 있습니다.

동일한 코퍼스(Corpus)라 하더라도, 엔티티 추출을 수행하는 LLM의 출력이 미세하게 흔들리기 때문에 재인덱싱(Re-indexing)을 할 때마다 커뮤니티 구조가 변합니다. "지난주의 그래프와 이번 주의 그래프의 커뮤니티 ID가 다르다"는 현상이 발생하는 것이죠.

첫 번째와 두 번째 실행에서 "같은 코퍼스인데 왜 다른 그래프가 반환되는 거지?"라며 밤새 고민했던 사람이 바로 저입니다. LLM이 포함되어 있는 이상, 어느 정도의 비결정성(Non-determinism)은 전제로 받아들일 수밖에 없습니다.

이를 허용할 수 있는 설계로 만들지, 아니면 시드 고정(Seed fixing) + 차분 인덱싱(Incremental indexing)을 할지는 요구사항에 따라 달라집니다.

상세한 지식 그래프(Knowledge Graph) 구축, GraphRAG vs Vector RAG의 비교 설계, Neo4j Cypher 쿼리 실습은 '지식 그래프 실전 가이드'에 정리해 두었습니다. LightRAG의 통합, 엔티티 정규화(Entity Normalization), 커뮤니티 요약(Community Summary)의 프롬프트 설계부터 실무 투입을 위한 체크리스트까지 모두 담았습니다.

• 저의 코퍼스(약 1만 건)로 Vector RAG / LightRAG / GraphRAG 비교
• 인덱싱 비용은 Vector $3 / LightRAG $43 / GraphRAG $185 (약 57배 차이)
• 종합 정답률은 Vector 47% / LightRAG 66% / GraphRAG 80%
• 단, "단일 사실"에 대해서는 Vector RAG가 GraphRAG를 상회함 (86% vs 72%)
• 조망(Overview)·집약(Aggregation)·다단계 추론(Multi-hop reasoning)에서는 GraphRAG가 압승
• 채택 조건: 질문의 절반 이상이 조망형 + 배치 업데이트(Batch update) 가능 + 온톨로지(Ontology) 설계 인력 보유
• 실제 운용 시에는 Vector + GraphRAG의 하이브리드 방식, 쿼리 유형에 따른 라우팅(Routing) 권장
• 함정: 업데이트 빈도 × 비용, 엔티티 정규화, Leiden 알고리즘의 비재현성

"GraphRAG vs Vector RAG"는 이지선다의 문제가 아니라, 질문 유형에 따라 나누어 사용하는 것이 2026년 5월 시점의 현실적인 해답입니다.

재미있게 가봅시다.