RAG 종류 총정리 ⑥ — GraphRAG와 구조화 데이터: 색인에 1,000배를 쓸 것인가

GraphRAG는 제안서에 가장 자주 등장하고 실제로는 가장 자주 후회하는 선택이다. 문서에서 엔티티와 관계를 뽑아 그래프를 만들고 커뮤니티 요약을 미리 생성해 두면 "이 코퍼스의 주요 테마는?" 같은 전역 질문에 답할 수 있다 — 벡터 검색이 구조적으로 못 하는 일이다. 문제는 값이다. 이 계층은 비용이 배수가 아니라 자릿수로 갈린다.

원문 1토큰을 색인하려고 100토큰을 태운다

가장 신뢰할 만한 실측은 HippoRAG 2 논문의 부록 표다. MuSiQue 11,656 passage를 같은 조건에서 색인했을 때 소모 토큰:

방식	입력 토큰	출력 토큰
RAPTOR	1.7M	0.2M
HippoRAG 2	9.2M	3.0M
LightRAG	68.5M	18.3M
MS GraphRAG	115.5M	36.1M

같은 코퍼스에 HippoRAG 2의 12.5배다. 진짜 병목은 시간이다 — 원논문은 100만 토큰 색인에 GPT-4-turbo로 281분이 걸렸고, 미시간주립대·Meta의 통일 평가에서는 벡터 RAG 135초 vs KG-GraphRAG 7,702초(57배)였다. PoC를 한 번 돌리고 프롬프트를 고치면 그 시간을 통째로 다시 낸다.

질의 비용도 상식 밖이다. LightRAG 논문의 Legal 데이터셋 측정에서 GraphRAG의 검색 1회가 61만 토큰 + API 약 610회인데 LightRAG는 100토큰 미만 + 1회였다. GraphRAG-Bench도 global 질의당 최대 331,375토큰(vanilla RAG는 900~950토큰)을 기록했다.

Microsoft도 알고 있다 — 다만 해법은 아직 안 줬다

공식 레포 README 첫 줄이 "인덱싱은 비쌀 수 있으니 작게 시작하라"는 경고이고, 레포는 현재 사실상 유지보수 모드(신규 기능 PR 미수용)다. LazyGraphRAG는 색인 비용을 full GraphRAG의 0.1%, 전역 질의 비용을 1/700로 줄였다고 발표했지만 2026년 8월 현재 코드가 공개되지 않았다. 재현 불가능한 벤더 주장으로 취급하는 게 맞다.

지금 켤 수 있는 스위치는 둘이다. FastGraphRAG(LLM 추출을 명사구·동시출현으로 대체) — 공식 문서가 "그래프 추출이 색인 비용의 약 75%"라고 명시했으니 약 1/4로 떨어진다. 동적 커뮤니티 선택 — 정적 global이 리포트 1,500개를 전부 읽는 것을 라우터로 평균 470개만 고르게 해 비용 77% 절감, 품질 차이는 통계적으로 유의하지 않았다. 안 켤 이유가 없다.

그래프가 이기는 질문은 딱 세 가지다

학술 평가들은 마케팅과 반대 방향을 가리킨다. GraphRAG-Bench에서 소설 도메인 단순 사실 조회는 basic RAG 60.92%가 GraphRAG 전군(49~60%)을 이겼고, 의학도 64.73% vs 38~66%였다. 미시간주립대·Meta 평가에서도 NQ는 RAG F1 64.78 > Community-GraphRAG 63.01이었다. 선행 연구 인용으로는 NQ 정확도 13.4% 낮고 시간 민감 질의에서 16.6% 하락한다.

반대로 확실히 이기는 셋:

• 멀티홉 — Recall@5가 73.4% → 87.8%(+19.6%p), 2Wiki +28점, MuSiQue +31점. HippoRAG 2는 평균 Recall@5 78.2로 NV-Embed-v2(73.4)를 앞선다.
• 전역 요약 — "주요 테마는?" 류에서 MS-GraphRAG 64.40 vs 51.30, naive RAG 대비 승률 80~82%.
• 엔티티 중심 탐색 — 원래 구조가 있는 데이터일 때. 가장 믿을 만한 프로덕션 사례가 LinkedIn 고객지원이다 — 티켓의 이슈 구조를 그래프로 보존해 약 6개월 실운영, MRR +77.6%, 이슈당 중앙값 해결시간 −28.6%.

단, 승률표 대부분이 LLM 심판 기반이라는 점은 감안해야 한다. 같은 평가에서 심판의 순서 편향을 보정하자 어떤 방식의 승률이 66.7% → 약 39%로 무너진 사례가 보고됐다.

문서가 계속 늘어나면 구조적으로 못 버틴다

MS GraphRAG는 증분 갱신 시 커뮤니티를 전면 재구축한다 — LightRAG 논문 계산으로 약 1,400만 토큰이 다시 든다. 월간 문서 유입이 있는 사내 위키·티켓 시스템에 MS GraphRAG를 넣으면 안 된다. LightRAG(GitHub 39.3k stars)·nano-graphrag·HippoRAG는 증분 삽입을 지원하고, LightRAG는 품질에서도 GraphRAG와 승률 49.6~54.8%로 무승부다. 이긴 건 비용이다. 2026년에 "GraphRAG 도입"이라고 쓴다면 MS 구현이 아니라 이쪽 계열을 뜻해야 한다.

DB에 물어보는 건 벡터가 아니라 SQL이다

"지난 분기 지역별 매출 상위 5"는 벡터 검색으로 풀 수 없다. 정형 데이터는 text-to-SQL인데 여전히 어렵다 — BIRD(95개 DB, 33.4GB) 최고 81.95% vs 인간 92.96%, 그리고 Spider 2.0의 실제 웨어하우스 환경에서는 GPT-4o가 12.98%로 무너진다(Spider 1.0에서는 86.6%였다). 테이블 하나가 1,000~3,000 컬럼이고 정답 SQL이 100줄을 넘기 때문이다. 처방은 모델 교체가 아니라 시맨틱 레이어로 질의 표면적을 줄이는 것이고, 무엇보다 text-to-SQL은 정답 생성기가 아니라 초안 생성기로 설계해야 한다. 리더보드 90%대는 벤더 자체 제출 에이전트라는 점도 기억할 것.

한국에서 검토 중이라면

세 가지를 먼저 확인해야 한다. 첫째, 국내 공개 사례와 수치가 사실상 없다 — 국내 벤더 백서에는 비용·정확도·지연 수치가 없고 사례도 해외 기업뿐이다. 제안서에 실려 오는 "정확도 3배" 류는 대개 Neo4j 매니페스토의 2차 인용이고 원출처 표본이 질문 43개다. 둘째, 진짜 실패 지점은 한국어 엔티티 해소다 — 뉴스에서 "LG전자"와 "LG에너지솔루션"을 가르는 문제처럼 약칭·보통명사·조사 때문에 같은 회사가 노드 서너 개로 갈라진다. 삼성SDS도 순수 딥러닝이 아니라 형태소 분석 → NER(딥러닝+사전 하이브리드) → 관계 추출 순서를 택했다. 셋째, 그래프를 만들어도 질의할 자원이 없다 — Neo4j의 text-to-Cypher 데이터셋(44.4k)은 영어 전용이고 한국어 공개 자원을 찾지 못했다.

결정 규칙으로 접는다: 10만 토큰 이하면 통째로 넣고, 사실 조회면 벡터, 멀티홉이면 HippoRAG 2, 전역 요약이면 FastGraphRAG + 동적 선택, 문서가 계속 늘면 LightRAG, 숫자 질문이면 text-to-SQL. 다음 글은 비용이 한 번 더 자릿수로 뛰는 계층이다.

— RAG 종류 총정리 시리즈 ⑥ / 다음 글: 에이전틱 RAG와 "RAG는 죽었나" 논쟁