GraphRAG를 구축하려는 사람들은 대개 같은 구글 검색으로 시작해서 똑같은 마이크로소프트(Microsoft) 논문에 도달한다. 그리고는 3주 동안 커뮤니티 탐지(community detection) 파이프라인을 구축하고, 계층적 요약을 생성하며, 막대한 API 크레딧을 태운다. 그러고 나서야 자신들의 실제 쿼리에는 그 어떤 것도 필요하지 않았다는 사실을 뒤늦게 깨닫는다.
GraphRAG의 정교함에는 엄연한 위계가 있다. 하지만 대부분의 사람들은 유명한 논문에서 다루었다는 이유만으로 곧장 맨 꼭대기로 뛰어든다. 실제 풀려는 문제는 레벨 1 수준인데, 시스템은 레벨 3으로 짓고 있는 것이다.
GraphRAG의 5단계 레벨
GraphRAG는 이분법적인 기술이 아니라 연속적인 스펙트럼으로 이해해야 한다.
레벨 0 — 벡터 RAG (Vector RAG). 문서를 청크로 나누고, 임베딩하고, 상위 K개의 유사 청크를 검색하여 LLM에 전달한다. 그래프는 없다. Qdrant, Pinecone, Weaviate 같은 벡터 DB들이 기본적으로 제공하는 방식이다. 단순한 사실 기반 질문에는 놀라울 정도로 잘 작동한다. “SOP-123에서 온도 모니터링에 대해 뭐라고 규정하는가?” — 벡터 검색이 청크를 찾아내고, LLM이 답한다. 끝이다.
하지만 여러 청크에 걸쳐 흩어져 있는 정보를 연결해야 할 때 이 방식은 무너진다. “Part 11을 참조하는 SOP의 규제를 받는 시스템은 무엇인가?“라는 질문은 단일 청크에는 존재하지 않는 관계들을 넘나들며 추적(traversal)해야 하기 때문이다.
레벨 1 — 그래프 강화 RAG (Graph-Enhanced RAG). 기존 벡터 검색을 유지하되, 그 옆에 그래프 탐색 기능을 추가한다. 벡터 검색이 진입점(“SOP-123”)을 찾으면, 그래프가 요구사항, 시스템, 밸리데이션, 일탈(deviation) 등으로 관계를 바깥쪽으로 확장해 나간다. 순수 벡터 검색으로는 놓칠 수밖에 없는 구조화된 맥락을 확보할 수 있다.
이것이 Neo4j의 하이브리드 리트리버(hybrid retriever)가 하는 일이다. 또한 모든 것을 새로 갈아엎지 않고도 기존 벡터 파이프라인 위에 얹을 수 있기 때문에, 프로덕션 시스템에서 가장 실용적인 레벨이기도 하다.
레벨 2 — 지식 그래프 RAG (Knowledge Graph RAG). 이제 그래프 자체가 지식 표현의 핵심 축이 된다. 문서 전체에 LLM을 실행하여 엔티티와 관계를 추출하고, 제대로 된 지식 그래프(Knowledge Graph)를 구축한 뒤 Cypher로 쿼리한다. “LabVantage”를 언급하는 텍스트를 검색하는 대신, 요구사항, 밸리데이션, 일탈과 타입이 지정된 관계로 연결된 정규 :System 노드를 직접 조회하는 방식이다.
LlamaIndex의 PropertyGraphIndex와 Neo4j의 LLM Graph Builder가 바로 이 영역에 속한다. 레벨 1보다 구축 비용이 많이 들지만, 그래프는 훨씬 풍부해지고 쿼리는 훨씬 정밀해진다.
레벨 3 — 마이크로소프트 스타일 GraphRAG (Microsoft-Style GraphRAG). 바로 그 유명한 방식이다. 지식 그래프 위에 계층적 커뮤니티 탐지(Leiden 알고리즘)를 얹고, 다양한 추상화 수준에서 LLM이 생성한 커뮤니티 요약을 추가한다. 로컬 커뮤니티는 “John과 Jane은 마이크로소프트의 GraphRAG 팀을 구성하고 있다”고 요약할 수 있다. 더 상위 커뮤니티는 “마이크로소프트의 AI 연구 부서는 GraphRAG, Copilot, Azure AI를 개발하는 팀들을 포함한다”고 요약한다.
이를 통해 하위 레벨에서는 다룰 수 없는 쿼리 유형, 즉 말뭉치(corpus) 전체를 아우르는 글로벌 질문이 가능해진다. “500건의 일탈 조사 전체에서 나타나는 주요 테마는 무엇인가?” 커뮤니티 요약 덕분에 LLM은 개별 나무뿐만 아니라 숲 전체를 조망할 수 있게 된다.
레벨 4 — 에이전틱 GraphRAG (Agentic GraphRAG). 하나의 검색 전략을 하드코딩하는 대신, AI 에이전트가 직접 전략을 결정하도록 한다. 에이전트는 질문을 보고 벡터 검색이 필요한지, 그래프 탐색이 필요한지, 커뮤니티 요약이 필요한지, SQL 쿼리가 필요한지, 혹은 이들의 조합이 필요한지를 판단하여 라우팅한다. Memgraph가 바로 이 아키텍처를 적극적으로 지향하고 있다. 질문의 성격에 따라 Text2Cypher, 로컬 그래프 확장, 쿼리 중심 요약(query-focused summarization) 사이를 자율적으로 선택하는 에이전트 구조다.
실제 비용 곡선
실제 비용 관점에서 이 계층 구조를 살펴보면 다음과 같다.
| 레벨 | 인덱싱 비용 (문서 1,000건 기준) | 쿼리 지연 시간 | 구현 소요 시간 |
|---|---|---|---|
| 0 — 벡터 RAG | 수 센트 | <100ms | 수 시간 |
| 1 — 그래프 강화 | 낮음 (기존 벡터에 그래프 탐색 추가) | 100~500ms | 수 일 |
| 2 — 지식 그래프 | 중간 (LLM 기반 엔티티 추출) | 100ms~2초 | 수 주 |
| 3 — 마이크로소프트 GraphRAG | 높음 (GPT-4o 기준 $50~$500+) | 2~10초 (Map-Reduce 방식) | 수 주 |
| 4 — 에이전틱 | 가변적 (라우팅 복잡도에 따라 다름) | 가변적 | 수 개월 |
레벨 3의 비용 수치는 과장이 아니다. 마이크로소프트의 레퍼런스 구현체는 모든 청크마다 엔티티를 추출하기 위해 LLM을 호출하고, 모든 커뮤니티마다 요약을 만들기 위해 다시 LLM을 호출한다. 적당한 규모의 문서 말뭉치라 해도, 단 하나의 질문을 던지기도 전에 수천 번의 API 호출이 일어난다.
마이크로소프트 자체의 비용 최적화 버전인 LazyGraphRAG는 요약 생성을 쿼리 시점까지 미룸으로써 이 문제를 해결하려 했다. 인덱싱 비용을 전체 GraphRAG의 약 0.1%로 줄이면서 로컬 쿼리 품질은 유지하고, 글로벌 쿼리 비용은 700배나 낮췄다. 이는 마이크로소프트 스스로도 원래 접근법이 너무 비쌌음을 인정한 셈이다.
LightRAG는 여기서 한 걸음 더 나아간다. 커뮤니티 탐지 자체를 완전히 생략하고, 무거운 Leiden 클러스터링 없이 듀얼 레벨 검색(엔티티 레벨 + 관계 레벨)을 사용한다. 전체 GraphRAG 비용의 극히 일부만으로 대략 70~90%의 품질을 낸다. 대부분의 프로덕션 환경에서 이 정도의 미세한 품질 격차는 큰 문제가 되지 않는다.
벤치마크가 제대로 말해주지 않는 진실
모든 GraphRAG 홍보 자료에는 똑같은 숫자가 등장한다. “포괄성 72~83% 향상!”, “MuSiQue 벤치마크 31점 상승!” 그 숫자 자체는 사실이다. 하지만 이는 GraphRAG가 애초에 잘하도록 설계된 질문 유형, 즉 멀티홉(multi-hop) 추론과 글로벌 요약만을 측정한 결과다.
정작 전면에 내세우지 않는 사실들은 다음과 같다.
단일 사실 조회: 순수 RAG의 승리. 미시간 주립대와 메타(Meta)의 2025년 대조 연구에 따르면, 단순한 사실 확인 질문의 경우 순수 벡터 RAG가 F1 점수 64.8점을 기록한 반면 GraphRAG는 63.0점에 그쳤다. 질문에 필요하지도 않은 그래프 구조가 오히려 오버헤드로 작용한 것이다.
GraphRAG-Bench(ICLR 2026) 역시 이 패턴을 확인해 주었다. 단순 사실 검색에서는 동점(60.9점 대 60.1점)이었다. 복잡한 추론에서는 그래프가 10점 앞섰고(53.4점 대 42.9점), 맥락적 요약에서는 13점 앞섰다(64.4점 대 51.3점).
평가 방식 자체의 한계. LLM을 심판(LLM-as-judge)으로 사용하는 평가는 답변의 순서, 길이, 위치 편향에 따라 승률이 30점 이상 출렁일 수 있다. 보고된 66.7%의 승률이 편향을 보정한 후 약 39%로 떨어진 사례도 있었다.
냉정하게 요약하자면 이렇다. GraphRAG는 복잡하고 멀티홉이 필요하며 거시적 종합(global-to-local synthesis)을 요구하는 쿼리에서 승리한다. 반면 단순 RAG가 여전히 경쟁력을 갖는 단일 사실 조회에서는 거의 이점을 주지 못한다. 만약 당신의 시스템 워크로드가 80%의 단순 Q&A와 20%의 복잡한 추론으로 이루어져 있다면, 당신은 레벨 0 문제에 레벨 3의 비용을 지불하고 있는 셈이다.
실제 생태계 지형도
GraphRAG 생태계는 네 개의 레이어로 나뉘며, 이를 혼동하는 데서 대부분의 혼란이 발생한다.
레이어 1: 프레임워크 (Frameworks)
마이크로소프트 GraphRAG는 레퍼런스 구현체로, 모두가 가장 먼저 읽는 표준이다. LightRAG(홍콩대, 깃허브 스타 약 2만 9천 개)는 파이프라인을 필수적인 부분만 남겨 실용성을 극대화한 대안이다. HippoRAG(오하이오 주립대)는 인간 기억의 작동 방식에서 착안하여 커뮤니티 탐지 대신 개인화된 페이지랭크(Personalized PageRank)를 사용한다. fast-graphrag(circlemind)는 군더더기 없이 가볍고 커스텀하기 쉬운 베이스라인이다.
2025~2026년에 등장한 새로운 주자들로는 CatRAG(고정된 전이 확률 대신 쿼리 인식 탐색 사용), ParallaxRAG(4홉 이상의 추론에 최적화), Deep GraphRAG(강화학습 기반 동적 보상 가중치를 통해 소형 모델로 프론티어 모델 수준 성능 달성), 그리고 TrustGraph의 OntologyRAG(도메인 온톨로지 기반 추출로 규제 환경에 적합) 등이 있다.
레이어 2: 그래프 데이터베이스 (Graph Databases)
Neo4j는 가장 깊은 생태계를 보유한 시장의 리더다. 65개 이상의 알고리즘을 갖춘 GDS 라이브러리, 공식 neo4j-graphrag 파이썬 패키지, LangChain 파트너 연동 등을 제공하는 안전한 엔터프라이즈 기본값이다.
Memgraph는 성능에 올인한 선택지다. 인-메모리 C++ 기반으로 서브 밀리초 단위의 탐색을 지원하며, 전체 검색 파이프라인(검색, 확장, 랭킹, 프롬프트 조합)을 단 하나의 Cypher 쿼리로 실행하는 ’원자적(atomic) GraphRAG’를 내세운다. NASA가 10년간 사용하던 Neo4j를 버리고 Memgraph로 전환하기도 했다. Memgraph의 자체 벤치마크는 최대 41배 낮은 지연 시간을 주장한다.
FalkorDB(RedisGraph의 후속작)는 초저지연을 위해 GraphBLAS 희소 행렬을 사용한다. ArcadeDB는 가장 관대한 라이선스(Apache 2.0)를 제공하는 멀티모델 옵션이다. AWS 네이티브 환경이라면 완전관리형인 Amazon Neptune Analytics가 대안이 될 수 있다.
레이어 3: 오케스트레이션 (Orchestration)
LlamaIndex는 가장 빠른 프로토타이핑 경로다. 10개 이상의 그래프 스토어 백엔드를 지원하는 PropertyGraphIndex를 통해 50줄 미만의 코드로 구현이 가능하다. LangChain은 Text-to-Cypher 패턴을 위한 GraphCypherQAChain을 제공한다. 둘 다 GraphRAG 엔진 자체라기보다는, 선택한 엔진을 감싸는 래퍼에 가깝다.
레이어 4: 메모리 레이어 (Memory Layer)
Graphiti(Zep)는 흥미로운 아웃라이어다. 문서 GraphRAG가 아니라 에이전트 메모리를 위한 ‘시간적 지식 그래프(temporal knowledge graph)’ 인프라다. 모든 엣지(edge)에 유효 기간(validity interval)이 부여되어 있어 변경되거나 대체된 사실을 정확하게 처리한다. 문서 검색이 아니라 에이전트의 장기 기억을 구축하고 있다면 이것이 올바른 도구다. 반면 SOP나 CAPA 문서를 인덱싱하는 용도로는 적합하지 않다.
모두가 묻는 질문: “GraphRAG가 Neo4j를 대체하는가?”
아니다. 둘의 관계는 대체가 아니라 상호보완이다.
GraphRAG는 검색 ’패턴’이다. Neo4j는 스토리지 ’엔진’이다. “GraphRAG가 Neo4j를 대체한다”고 말하는 것은 “마이크로서비스가 PostgreSQL을 대체한다”고 말하는 것과 같다. 패턴은 인프라 위에서 실행된다.
마이크로소프트의 레퍼런스 구현체는 NetworkX와 Parquet 파일을 사용한다. 연구 환경에서 수천 건의 문서를 다루기에는 문제가 없다. 하지만 10만 건의 엔터프라이즈 문서를 NetworkX로 인-메모리에서 처리하려 들면 서버는 다운된다. 프로덕션 환경의 GraphRAG는 영구 저장소, 동시성 제어, 실시간 업데이트, 그리고 서브초 단위의 탐색 성능을 필요로 한다. 그것이 바로 그래프 데이터베이스의 역할이다.
엔터프라이즈의 지배적인 아키텍처 패턴은 명확하다. LLM으로 엔티티와 관계를 추출하고, 이를 Neo4j나 Memgraph에 저장하며, 임베딩에 벡터 인덱스를 생성한 뒤, 쿼리 시점에 하이브리드 리트리버를 실행하는 것이다. GraphRAG는 그래프 데이터베이스를 대체하기는커녕, 오히려 그 수요를 크게 끌어올리고 있다.
아무도 이야기하지 않는 난제들
GraphRAG에서 가장 어려운 부분은 아키텍처나 데이터베이스 선택이 아니다. 검색이 일어나기 ‘이전’ 단계에서 발생하는 문제들이다.
엔티티 해소(Entity Resolution). LLM은 정규화된 엔티티가 아니라 표면적 표현(surface form)을 그대로 추출한다. “LabVantage”, “Lab Vantage”, “LabVantage LIMS”, “the LIMS system” — 현실에서는 하나의 동일한 대상이지만 그래프에서는 4개의 서로 다른 노드가 된다. 2025년의 한 연구에 따르면, LLM 추출 결과 실제로는 312개여야 할 엔티티가 847개나 생성되었다. 단순히 엔티티 해소를 적용하여 그래프 크기를 약 40% 줄였을 뿐인데 전반적인 성능이 일관되게 향상되었다. 노드를 제거하는 것이 오히려 그래프의 질을 높인 것이다.
추출 품질. LLM은 엔티티를 누락하고, 관계 라벨을 잘못 붙이며, 없던 관계를 환각해 낸다. 스키마 기반 추출(Schema-guided extraction)이 도움이 되며, 인간의 검토(Human-in-the-loop)를 거치면 더욱 좋다. 하지만 대부분의 튜토리얼은 이 골치 아픈 과정을 건너뛰고 오직 장밋빛 시나리오만 보여준다.
유지보수와 증분 업데이트. GraphRAG 인덱스에 새 문서를 추가하는 것은 벡터 스토어에 청크 하나를 추가하는 것과는 차원이 다르다. 새로운 엔티티를 추출하고, 기존 그래프와 병합하며, 중복을 제거하고, 잠재적으로 커뮤니티를 다시 탐지해야 한다. DRIFT(마이크로소프트의 증분 모드)와 LightRAG의 증분 업데이트 기능이 이를 다루고 있지만, 여전히 벡터 스토어 업데이트보다 훨씬 복잡하고 까다롭다.
변경 통제(Change Control). 제약 바이오나 금융 같은 규제 환경에서는 LLM이 생성한 커뮤니티 요약 하나하나가 사실상 새로운 ’관리 대상 문서(controlled document)’가 된다. 요약을 다시 생성할 때마다 새로운 버전이 생겨난다. GxP 환경에서 이는 대부분의 구현체가 미처 고려하지 못한 거대한 감사(audit) 리스크가 된다.
나라면 실제로 어떻게 구축할 것인가
위의 모든 현실을 고려할 때, 프로덕션 환경을 위한 스택은 다음과 같아야 한다.
대부분의 엔터프라이즈 Q&A (레벨 1~2): 시맨틱 진입점을 찾기 위한 벡터 검색. 구조적 맥락을 파악하기 위한 그래프 탐색. 그래프 스토어로 Neo4j 또는 Memgraph 사용. LlamaIndex 또는 자체 오케스트레이션 파이프라인. 커뮤니티 탐지도, 계층적 요약도 불필요하다. 그래프가 멀티홉 맥락을 제공하고, 벡터 검색이 진입점을 찾아준다. 이것으로 충분하다.
말뭉치 전반의 주제별 분석 (레벨 3): 마이크로소프트 스타일의 커뮤니티 탐지 및 요약을 도입하되, 오직 그것이 반드시 필요한 특정 유스케이스에만 한정한다. 단순 쿼리는 벡터 전용 또는 그래프 전용 경로로 라우팅한다. LazyGraphRAG의 지연 요약(deferred summarization)을 활용하여 조회되지도 않을 요약에 비용을 쓰는 일을 방지한다. 커뮤니티 요약은 버전 관리가 적용되는 규제 대상 문서로 취급한다.
에이전트 기반 시스템 (레벨 4): 에이전트가 직접 경로를 판단하게 한다. Memgraph 아키텍처를 활용하거나 자체 라우팅 레이어를 구축한다. 에이전트가 질문의 의도에 따라 벡터 검색, 그래프 탐색, 커뮤니티 요약, SQL 중 최적의 도구를 선택한다. 이것이 장기적인 미래 방향이지만, 구축과 평가의 난이도가 가장 높다.
결론
GraphRAG는 단일 기술이 아니다. 계층적 위계다. 어떤 레벨을 선택해야 할지는 마이크로소프트 논문이 무엇을 말하는지가 아니라, 당신의 시스템이 어떤 쿼리를 처리해야 하는지에 달려 있다.
쿼리의 대부분이 단순 사실 확인이라면 레벨 0(벡터 RAG)이 정답이다. 멀티홉 관계 추적이 필요하다면 레벨 1이나 2만으로도 20%의 비용으로 80%의 효과를 누릴 수 있다. 말뭉치 전체에 걸친 거시적 분석이 진정으로 필요할 때 비로소 레벨 3의 복잡성이 정당화된다. 다중 데이터 소스에 걸쳐 동적으로 추론해야 하는 에이전트를 만들고 있다면 레벨 4로 향해야 하겠지만, 그것은 파이프라인 하나를 만드는 것이 아니라 복잡한 인프라를 구축하는 일이다.
데이터베이스 선택(Neo4j vs Memgraph vs FalkorDB)은 중요한 엔지니어링 결정이다. 하지만 그것은 더 중요한 질문의 하위 결정일 뿐이다.
“당신이 풀려는 문제는 과연 위계의 몇 번째 레벨을 요구하고 있는가?”
대부분의 사람들은 유명한 논문이 레벨 3을 다룬다는 이유만으로 레벨 3을 짓고 있다. 정작 그들이 해결하려는 문제는 레벨 1에 불과한데 말이다.