그래프는 하나가 아니다 — GraphRAG의 다변화, 거대 지식 그래프 하나에 종속되지 않기 (RAG 특집 5편)

들어가며 — 저장소에 적힌 한 문장

크게 보기

2024년 여름, Microsoft Research가 공개한 GraphRAG는 RAG의 다음 단계처럼 보였다. 문서를 청크로 자르는 대신 LLM으로 엔티티와 관계를 뽑아 지식 그래프를 만들고, 커뮤니티를 찾아 요약하고, 질문이 오면 그 그래프 위를 걷는다. "이 문서들의 핵심 주제가 뭐야?"처럼 기본 RAG가 답하지 못하던 질문에 답했다. 이 블로그도 완전 가이드, 네 가지 검색 모드, LangChain으로 구축하기를 차례로 썼다.

2026년 9월, 그 저장소의 README에는 이런 문장이 있다.

"GraphRAG는 질의응답을 위한 표적 문맥을 구성하는 데 그래프를 기능적으로 활용하는 방법을 탐구하는 연구 프로젝트다. (…) 이 프로젝트는 대부분 유지보수 모드(maintenance mode)에 있으며, 새 PR을 받거나 새 기능을 구현하지 않을 것이다. 업데이트는 버그 수정과 의존성 갱신, 특히 CVE 대응에 집중한다."

같은 페이지에는 원래부터 있던 경고도 그대로 남아 있다. 제공되는 코드는 "시연용이며 공식 지원 Microsoft 제품이 아니다." "GraphRAG 색인은 비용이 큰 작업일 수 있으니 문서를 전부 읽고 작게 시작하라." 그리고 자기 데이터에 맞게 프롬프트를 튠하라는 강한 권고.

이 글은 이 문장들을 "GraphRAG는 죽었다"로 읽지 않는다. 그렇게 읽으면 틀린다. 이 글이 읽어 내는 것은 다른 것이다. 끝난 것은 그래프가 아니라, 하나의 공식이 무조건적 기본 선택이던 시대다. 그 공식은 이것이다.

2026년 상반기에 이 공식의 네 마디가 하나씩 흔들렸다. "모든 문서"가 아니라 관계 질문이 나오는 문서만. "LLM으로 추출"이 아니라 임베딩 각도만으로. "전역 그래프 구축"이 아니라 질의 시점에 SQL 조인으로. "모든 질의"가 아니라 라우터가 고른 질의만. 그래서 이 특집의 제목이 그래프는 하나가 아니다다.

1. 2024~2025년의 공식 — 왜 매력적이었나

크게 보기

공식이 매력적이었던 이유를 먼저 정직하게 적어야 한다. 그래야 무엇을 버리고 무엇을 남길지가 보인다.

기본 RAG는 청크 단위로 검색한다. 그래서 답이 한 청크에 들어 있는 질문에는 강하고, 여러 문서에 흩어진 정보를 엮어야 하는 질문에는 약하다. "A를 인수한 회사의 CEO가 이전에 창업한 회사는?" 같은 다중 홉 질문, "이 300개 보고서의 공통 주제는?" 같은 전역 요약 질문이 그렇다. 지식 그래프는 두 문제에 구조적인 답을 준다. 엔티티가 노드고 관계가 엣지라면 다중 홉은 그래프 탐색이고, 커뮤니티 요약이 있으면 전역 질문은 요약들의 요약이다.

그리고 이것이 실제로 작동했다. 이 블로그가 ICLR 2026 GraphRAG-Bench 논문을 분석한 글에서 정리한 대로, 복잡한 추론 질문에서는 그래프 방식이 기본 RAG를 이긴다. HippoRAG 2는 기억 시스템으로서의 RAG라는 관점을 열었고, LightRAG는 같은 발상을 훨씬 가볍게 구현했다.

그러나 같은 벤치마크는 두 가지를 함께 보였다. 단순한 질문에서는 기본 RAG가 이긴다. 그리고 그래프 방식의 토큰 비용은 기본 RAG의 수백 배에 이를 수 있다(그 글의 제목 그대로 “377배”). 이 두 문장이 이 특집 전체의 출발점이다. 공식이 틀린 것이 아니다. 공식을 모든 문서, 모든 질의에 적용하는 것이 틀렸다.

2. 왜 무조건적 기본 선택이 아닌가 — 다섯 가지 비용

크게 보기

Microsoft 저장소가 유지보수 모드에 들어간 것은 연구 프로젝트의 자연스러운 수명이다. 문제는 그 방법론이 운영 시스템의 기본값으로 쓰일 때 드러나는 다섯 가지 비용이다.

②와 ③은 눈으로 보는 것이 빠르다. 아래 시뮬레이터는 진짜 엔티티 18개, 언급 54개로 만든 작은 합성 그래프다. 중복률과 관계 오류율을 올려 보라.

중복률 15%에서도 2홉 도달률이 눈에 띄게 떨어지고, 30%를 넘으면 그래프가 여러 조각으로 쪼개진다. 이것이 정적 지식 그래프 운영의 숨은 일거리다. 엔티티 해소(entity resolution) 를 계속 손봐야 하고, 새 문서가 들어올 때마다 병합을 다시 판단해야 한다. Microsoft가 “데이터에 맞게 프롬프트를 튠하라”고 강하게 권한 이유도 여기 있다 — 추출 품질이 그래프 품질이고, 그래프 품질이 답 품질이다.

①은 두 논문이 같은 코퍼스 계열에서 기준선들의 색인 비용을 함께 측정해 두었다.

두 탭을 서로 비교하면 안 된다(모델·하드웨어가 다르다). 그러나 각 탭 안에서 보이는 것은 같다. 색인 비용과 성능이 비례하지 않는다. G³RAG 실험에서 LightRAG는 8,680만 토큰을 쓰고 F1 23.09, G³RAG는 토큰 0으로 52.28이다(단, G³RAG 저자들의 실험이라 기준선 튠이 최적이 아닐 수 있다 — 9장). SAG 실험에서 HyperGraphRAG는 2억 1,611만 토큰을 쓴다.

이 다섯 비용이 “그래프를 쓰지 말라”는 뜻은 아니다. “LLM이 추출한 전역 그래프를 모든 것의 기본으로 두지 말라”는 뜻이다. 그러면 무엇을 두는가. 세 가지 방향이 있다.

3. 살아 있는 쪽 — LightRAG의 2026년, 그리고 관리형

크게 보기

3.1 LightRAG는 활발하게 확장된다

Microsoft 저장소가 조용해진 것과 대조적으로, 홍콩대 HKUDS의 LightRAG는 2026년에 가장 활발하게 움직인 오픈소스 그래프 RAG다(MIT, 스타 약 4만). README의 2026년 항목만 옮겨도 방향이 보인다.

세 가지가 이 특집의 논지와 맞닿는다. 역할별 LLM은 색인 비용 ①을 줄이는 직접적 장치다. 로컬 임베딩·리랭킹 배포는 추출 비용을 API 밖으로 꺼낸다. 그리고 PostgreSQL 하나로 네 저장 유형을 다 담는다는 권고는 5장 SAG와 같은 방향 — 그래프 DB 없이 관계형 DB 위에서 그래프 RAG를 한다 — 을 가리킨다.

그러므로 오픈소스 그래프 RAG를 실험할 때 Microsoft GraphRAG를 그대로 서비스 기반으로 삼기보다는 다음을 비교하는 편이 좋다.

3.2 관리형 — Bedrock Knowledge Bases GraphRAG

AWS 종속을 받아들일 수 있고 운영 인력이 적다면 관리형이 답일 수 있다. Amazon Bedrock Knowledge Bases는 Amazon Neptune Analytics와 결합한 완전 관리형 GraphRAG를 제공한다. 공식 문서의 작동 방식은 세 단계다. 벡터 검색으로 관련 노드를 먼저 찾고, 그 청크에 연결된 그래프 노드·청크 식별자를 가져오고, 그래프를 순회해 관련 청크를 확장한다. 문서에 따르면 엔티티 사이의 관계뿐 아니라 절 제목 같은 구조 요소 사이의 관계도 자동으로 식별한다.

제약도 공식 문서가 명시한다.

• 그래프 구축을 커스터마이즈하는 설정이 없다.
• Neptune Analytics 그래프는 오토스케일링을 지원하지 않는다.
• 데이터 소스는 Amazon S3만.
• 데이터 소스당 파일 1,000개(요청 시 최대 1만). 폴더로 나누면 폴더당 1,000개.
• 계층적 청킹을 쓰면 검색은 자식 청크만 돌려주고 부모 청크로 바꿔 주지 않는다.
• 그래프 구축용 파운데이션 모델을 고르는데, 모델이 수명 종료될 수 있다(문서는 Claude 3 Haiku가 레거시로 옮겨 간 예를 든다).
• 지식 베이스를 지워도 그래프는 자동으로 지워지지 않아 과금이 계속될 수 있다.

리전은 2026년 9월 기준 프랑크푸르트·런던·아일랜드·오리건·버지니아 북부·도쿄·싱가포르 일곱 곳이다. 서울은 없다.

관리형의 요점은 “그래프를 안 만들어도 된다”가 아니라 “그래프를 만드는 결정을 AWS에 위탁한다”는 것이다. 2장의 다섯 비용 중 ①④는 청구서로, ②③은 블랙박스로 바뀐다. 그것이 받아들일 만한 거래인지는 팀마다 다르다.

4. 연구 ① G³RAG — LLM 없이, 토큰 0으로 문서 그래프를 짓는다

크게 보기

2026년 9월 17일, 화남이공대학(South China University of Technology) 연구진이 arXiv에 올린 「Beyond Similarity through Zero-Token Geometric Graphs for Multi-Hop RAG」— 저자들이 G³RAG(Geometric Gain Graph RAG)라 부르는 방법 — 는 공식의 두 번째 마디, “LLM으로 추출”을 통째로 뺀다.

4.1 관련성과 새로움을 한 식에

문제 설정이 명료하다. 다중 홉 검색은 “관련 있되 새로운” 문서를 연쇄적으로 찾는 일이다. 유사도만으로 이웃을 고르면 비슷한 문서만 줄줄이 걸리는 ‘유사성의 함정(similarity trap)’에 빠진다. 논문의 표현으로, "토폴로지 제약이 없으면 검색 사슬은 국소적으로 고도로 동질화된 중복 문서들만 연결하려 들고, 그래서 핵심 문서를 놓친다."

G³RAG의 답은 두 문서 임베딩 사이의 각도 θ 하나로 관련성과 새로움을 동시에 재는 것이다.

여기에 밀도 패널티를 얹는다. 코퍼스 어디서나 비슷하게 보이는 문서 — 개요, 요약, 반복되는 보일러플레이트 — 는 밀도 ρ가 높은 허브다. 허브로 들어가는 엣지 가중치를 exp(−β·ρ)로 지수 감쇠시켜, 그래프가 “더 희귀하고 주변적인 노드”로 연결되게 강제한다. 대칭이던 가중치가 이 패널티로 비대칭 방향 엣지가 된다.

크게 보기

이 두 식이 오프라인 색인의 전부다. LLM 호출 0회, 생성 토큰 0. 질의 시점에는 밀집 검색으로 후보 10개를 뽑고, LLM 필터로 시드 2개를 고르고, 전이 행렬을 한 번 곱하는 단일 스텝 확산으로 상위 5개 문서를 고른다. 반복적인 Personalized PageRank를 쓰지 않는 이유도 적혀 있다 — 반복하면 가중치 분포가 과평활(over-smoothing)되어 “정성껏 만든 가중치 분포를 파괴한다.” 실제로 PPR로 바꾸면 MuSiQue F1이 52.28에서 51.02로 떨어졌다.

4.2 결과

임베딩 두 종(Nv-embed-v2, Qwen3-8B-embed), 생성 LLM Llama-3.3-70B, 세 다중 홉 벤치마크.

평균 F1은 최강 기준선 HippoRAG 2보다 Nv-embed-v2에서 2%p, Qwen3-8B-embed에서 4.26%p 높고, MuSiQue에서는 차상위 대비 4.68 / 5.76%p 높다. 정답 문서 적중률(HitAns@5)도 전 데이터셋에서 1위다. 2Wiki의 Nv-embed 설정에서는 HippoRAG 2가 앞선다는 점은 표에 그대로 남겨 두었다.

제거 실험은 무엇이 이득의 원천인지 알려 준다. 밀도 패널티를 빼면 MuSiQue 52.28 → 50.65. PPR로 바꾸면 51.02. LLM 필터를 빼면 45.22로 가장 크게 떨어진다 — 시드를 잘 고르는 것이 확산의 전제다. 흥미롭게도 “Naive RAG + LLM 필터”만으로도 50.27이 나온다. 그래프의 순수 기여는 그 위의 +2다.

4.3 이 연구가 시사하는 것

이 논문의 요점은 F1 몇 점이 아니다. GraphRAG가 반드시 “LLM이 추출한 지식 그래프”일 필요는 없다는 것이다. 문서 임베딩만 있으면 — 그리고 대부분의 RAG 시스템은 이미 갖고 있다 — 토큰 0으로 다중 홉에 쓸 만한 그래프가 나온다. 새 문서가 들어오면 기존 문서와의 각도만 계산하면 된다. 엔티티 병합이 없으니 2장의 비용 ②④가 사라진다.

한계도 저자들이 먼저 적었다. “최적 기하 이득의 보편적 수치 임계값을 정하는 것은 여전히 상당한 도전”이며, 이를 “수치가 아니라 방향성이 실용적 의미”라고 재해석한다. 그리고 노드가 문서라서 엔티티 단위 질문(“X와 Y는 어떤 관계인가?”)에는 답이 없다. 관계 자체가 질문인 도메인에서는 여전히 명시적 그래프가 필요하다.

같은 발상을 더 넓게 밀면 이렇게 된다. 문서 유사도, 문서 간 참조, 시간 관계, 작성자·기관·사업·지역 메타데이터만으로도 충분히 유용한 그래프를 만들 수 있다. 공고가 어느 사업의 어느 연도 것인지, 보도자료가 어느 기관의 것인지는 이미 메타데이터에 있다. 그것을 엣지로 쓰면 LLM 추출 없이도 “같은 사업의 전년도 공고”, “같은 기관의 관련 보도”가 그래프 이웃이 된다. 다음 장이 정확히 그 방향이다.

5. 연구 ② SAG — 전역 그래프 없이 질의 시점에 SQL로 잇는다

크게 보기

Zleap AI 연구진의 「SAG: SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges」(arXiv:2606.15971, v1 2026년 6월 14일, v2 8월 25일)는 공식의 세 번째 마디, “전역 그래프를 구축하고”를 뺀다.

5.1 사건 하나 + 엔티티들

SAG는 청크를 트리플로 쪼개지 않는다. 청크마다 의미적으로 완결된 사건(event) 하나와 색인용 엔티티들을 LLM으로 뽑는다. 예를 들어 인수 기사 한 단락은 "A사가 D일에 X원에 B사를 인수했다"라는 사건 하나로 저장되고, 인수자·피인수자·금액·날짜가 엔티티로 붙는다. 트리플로 쪼개면 흩어졌을 정보가 사건 단위로 원자성을 유지한다. 엔티티는 11개 유형(시간·장소·인물·조직·집단·주제·저작물·제품·행위·지표·태그)이다.

저장은 관계형이다. 사건 행과, 사건–엔티티 다대다 행. 벡터 인덱스와 전문 검색 인덱스를 옆에 둔다. 논문 구현은 MySQL + Elasticsearch이고, 밀집 벡터 검색도 Elasticsearch가 맡아 별도 벡터 DB가 없다. 그리고 결정적으로 — 전역 그래프를 만들지 않는다. 엔티티 사이의 관계를 미리 계산하지 않는다.

5.2 질의 시점의 동적 하이퍼엣지

그래프는 질의가 올 때 그 질의를 위해서만 만들어진다. 세 단계다.

공유 엔티티가 JOIN 키다. 같은 엔티티를 가진 사건들이 그 순간 하이퍼엣지 하나로 묶인다. 다른 질의에서는 다른 그래프가 만들어진다. 직접 만져 보는 것이 빠르다. 아래는 지역×사업×기관×연도 축을 가진 가상의 공고·보도자료 8건이다.

‘코어닷투데이’ 하나를 고르면 두 사건이 시드가 되고, 그 사건들의 엔티티(울산시·AI 키오스크 실증·경남도의회·의정지원 AI·2025·2026)가 프론티어가 되어, 그 엔티티를 공유하는 사건들이 1홉 이웃으로 붙는다. 부산시의 키오스크 사건은 ‘AI 키오스크 실증’ 하나로 연결되고, 스마트 관광 공고는 ‘울산시·2026’으로 연결된다. 이 연결은 어디에도 저장되어 있지 않다. 질의가 끝나면 사라진다.

5.3 결과와 비용

리트리버 BGE-Large-EN-v1.5, 리더 Qwen3.6-Flash.

MuSiQue에서 +15.23pt, 2Wiki 93.34% vs 90.35%, HotpotQA 96.50% vs 94.35%. GraphRAG·LightRAG·HyperGraphRAG는 순위 문단이 아니라 생성 답변을 돌려주기 때문에 Recall 비교가 불가능해 표에서 빠졌다 — 이것은 SAG의 유리한 선택이기도 하므로 감안해서 읽어야 한다.

색인 비용은 2장 위젯의 두 번째 탭 그대로다. SAG 2,826만 토큰·4.57시간. HippoRAG 2(1,593만·2.3시간)보다는 비싸고, GraphRAG(1억 2,512만·10.15시간)·LightRAG(1억 314만·25.94시간)·HyperGraphRAG(2억 1,611만·16.21시간)보다는 시간이 55~82% 짧다. 그리고 append-only다. 새 문서는 행을 추가하기만 한다. 논문의 문장으로, “인덱스는 의도적으로 완전한 엔티티 중의성 해소를 피하며 (…) 독립적인 청크 처리와 append-only 수집을 보존한다.”

5.4 한계 — 데모에 이미 보인다

저자들이 적은 두 한계가 위 데모에 그대로 있다. 첫째, 별칭을 해소하지 않는다. 엔티티 문자열을 정규화·중복 제거하지만 "Apple Inc."와 "Apple"을 같은 키로 만들지 않는다. 데모에서 ‘울산시’와 ‘울산광역시’가 섞여 있었다면 조인이 끊어진다. 둘째, 시간에 따라 바뀌는 사실을 다루지 못한다. append-only라 낡은 사건을 폐기·수정하는 장치가 없다. 정적 코퍼스에는 맞지만 동적 에이전트 메모리에는 맞지 않는다고 저자들이 직접 적었다.

5.5 이 접근이 잘 맞는 데이터

축이 분명한 데이터다. 열(column)로 적을 수 있는 것이 엔티티가 되고, 그 열의 값이 JOIN 키가 된다.

그래프 DB부터 도입하지 않아도 된다. PostgreSQL이면 충분하다.

마지막 두 줄이 SAG 원안에 없는 것이다. 유효기간 컬럼과 별칭 사전. 5.4의 두 한계를 운영에서 메우는 최소 장치다.

6. 위키도 그래프다 — 네 가지 접근을 한 표에

1편 4장에서 본 LLM-Wiki를 여기서 다시 부르는 이유가 있다. 문서를 양방향 링크가 있는 위키 페이지로 컴파일한 것은 노드가 페이지, 엣지가 링크인 그래프다. 다만 그 그래프를 걷는 주체가 그래프 알고리즘이 아니라 에이전트라는 점이 다르다. 그리고 그 위키는 오류를 Error Book으로 스스로 고친다 — 4편의 주제다.

이제 네 가지가 모였다. 한 표에 놓아 보자.

네 카드를 차례로 누르면 한 가지가 또렷해진다. 2026년에 “그래프”라는 말은 무엇이 노드이고, 누가 엣지를 만들고, 새 문서가 들어오면 무슨 일이 생기는지가 전혀 다른 네 구조를 가리킨다.

이 표에서 읽어야 할 것은 어느 열이 이기느냐가 아니다. 어느 행이 내 문제에서 중요한가다. 관계 자체가 질문이면 ①의 “엔티티 질문” 행이 결정적이다. 문서가 매일 들어오면 “새 문서” 행이 결정적이다. 출처 책임이 있으면 “증거의 형태” 행이 결정적이다. 그리고 그 행을 고르는 것이 다음 장이다.

7. 실무 판단 — 내 데이터에 맞는 구조 고르기

크게 보기

판정 규칙은 우선순위가 있다. 순서대로 짚어 두자.

대부분이 단일 문서 사실 조회라면 그래프는 없다. GraphRAG-Bench가 반복해서 보인 결과다. 실패 질의를 모아 다중 홉·관계 질문이 몇 %인지 먼저 세어야 한다. 10% 미만이면 여기서 멈춘다.

축이 분명한 사건 데이터라면 사건·엔티티 테이블이다. 공고·보도자료·회의록·티켓·견적. PostgreSQL 두 테이블로 시작하고, 별칭 사전과 유효기간을 함께 둔다. 증거가 원문으로 남으니 출처 책임이 있는 도메인에 특히 맞는다.

관계 자체가 질문이거나 코퍼스 전체 요약이 필요하면 명시적 KG다. 다만 범위를 좁힌다 — 전체 코퍼스가 아니라 관계 질문이 나오는 문서 집합만. 구현은 활발히 유지되는 LightRAG를 Microsoft GraphRAG보다 먼저 검토한다. 그리고 Microsoft 저장소의 경고 그대로 작게 시작한다. 문서 100건으로 색인 비용과 엔티티 중복률을 먼저 잰다.

보완적 문서를 모아야 하는 다중 홉이고 색인 예산이 빠듯하면 기하 문서 그래프다. 이미 있는 임베딩으로 시작할 수 있다. 첫 실험은 유효 각도 구간을 우리 데이터에서 다시 튠하는 것이다.

사람도 읽는 지식 베이스를 겸하면 위키 구조다. Error Book부터 설계한다.

AWS 위에서 관리형을 원하면 Bedrock GraphRAG다. 3.2의 제약 목록을 먼저 확인한다.

그리고 이 판정은 기본 구조를 정하는 것이다. 실제 시스템에서는 질의별로 다른 경로를 탄다. 관계 질문은 그래프로, 사실 조회는 하이브리드로, 긴 문서 안의 표는 1편의 Agentic Search로. 그 라우팅이 3편의 주제다. 여기서는 “그래프 하나에 전부 태우지 마라”만 확실히 해 두자.

8. 우리 시스템에 넣는 순서

기존 하이브리드 RAG가 돌고 있다는 전제다.

순서의 요점은 싼 것부터다. 메타데이터 엣지(토큰 0) → 기하 엣지(토큰 0) → 사건 테이블(청크당 LLM 1회) → 명시적 KG(청크당 LLM 다수). 각 단계에서 실패 질의가 얼마나 줄었는지 재고, 남은 것이 다음 단계를 정당화할 때만 올라간다.

9. 한계와 반론

9.1 논문과 문서가 스스로 밝힌 것

• G³RAG: 최적 임계값이 데이터마다 다르다. 노드가 문서라 엔티티 질문에는 답이 없다. 화남이공대 연구진의 사전 공개(preprint) 연구다.
• SAG: 별칭 해소를 하지 않는다. append-only라 낡은 사실을 폐기하지 못한다. Zleap AI라는 회사의 연구로, 저장소와 벤치마크 코드가 공개돼 있지만 독립 재현은 아직 없다. GraphRAG·LightRAG와의 Recall 직접 비교가 불가능했다는 점도 결과 해석의 한계다.
• LightRAG: 활발한 개발은 장점이자 위험이다. 2026년 한 해에 저장 백엔드·청킹·역할별 LLM이 모두 바뀌었다. 운영에 올릴 때는 버전을 고정해야 한다.
• Bedrock GraphRAG: 그래프 구축 커스터마이즈 불가, S3 전용, 파일 수 제한, 서울 리전 없음.

9.2 이 특집이 덧붙이는 반론

G³RAG 실험의 기준선 수치가 낮다. 같은 표에서 LightRAG F1 23.09는 다른 논문들의 보고와 거리가 있다. 저자들의 실험 설정에서 기준선 튠이 최적이 아닐 가능성을 배제할 수 없다. “토큰 0으로 HippoRAG 2 이상”이라는 방향은 믿을 만하지만, “LightRAG의 절반 비용에 두 배 성능” 같은 식으로 읽으면 과장이 된다.

SAG의 Recall 비교는 SAG에 유리한 프레임이다. 순위 문단을 돌려주는 방법(HippoRAG 2)과만 Recall을 비교했다. 답을 생성하는 방법들과의 최종 정답률 비교는 논문 다른 표에 있지만 이 글은 Recall만 인용했다. 우리 데이터에서는 최종 답 정확도로 다시 재야 한다.

“LLM 추출 KG는 끝났다”도 과장이다. 관계 자체가 질문인 도메인 — 계보, 조직도, 공급망, 규제 간 참조 — 에서는 여전히 명시적 그래프가 필요하고, 이 글의 대안들은 그 질문에 답하지 못한다. 이 글의 주장은 그것을 기본값으로 두지 말라는 것이지 버리라는 것이 아니다.

그래프의 종류가 늘면 라우팅이 어려워진다. 네 구조를 다 갖춘 시스템은 질의마다 어느 구조로 갈지 정해야 한다. 그 결정 자체가 비용이고 오류 원천이다. 3편에서 다루지만, 여기서도 적어 둔다 — 구조를 늘리기 전에 라우터를 먼저 세워라.

마무리 — “그래프”라는 말을 다시 정의한다

이 글은 저장소에 적힌 한 문장으로 시작했다. 유지보수 모드. 새 기능도 PR도 받지 않는다. 그 문장을 “GraphRAG의 종말”로 읽는 것은 쉽고, 틀렸다.

바뀐 것은 “그래프”라는 말의 뜻이다. 2024년에 그 말은 하나를 가리켰다 — LLM이 모든 문서에서 뽑은 엔티티와 관계로 만든 거대한 전역 지식 그래프. 2026년 9월에 그 말은 네 가지를 가리킨다. 임베딩 각도로 만든 문서 그래프(토큰 0), 질의 시점에 SQL로 잇는 사건 그래프(전역 구조 없음), 에이전트가 걷는 위키 링크 구조, 그리고 여전히 필요할 때 쓰는 명시적 지식 그래프(범위를 좁혀서, 활발히 유지되는 구현으로).

네 구조의 차이는 “무엇이 노드이고, 누가 엣지를 만들고, 새 문서가 들어오면 무슨 일이 생기는가”다. 그리고 그 차이가 색인 비용과 엔티티 중복과 최신성이라는, 2장의 다섯 비용을 결정한다. 그러니 다음에 누가 “GraphRAG를 도입하자”고 말하면 되물어야 한다. 어느 그래프를? 노드가 무엇인가? 엣지는 누가 만드나? 내일 문서 100건이 들어오면 무슨 일이 생기나?

그 질문에 답이 있으면 그래프는 여전히 강한 도구다. 답이 없으면 — 아직 그래프를 만들 때가 아니다. 메타데이터 엣지부터.

다음 편은 페이지를 찾는 것에서 시각 토큰을 고르는 것으로 넘어간 멀티모달 문서 RAG다. 표·도표·스캔 문서가 수십 쪽 검색될 때 무엇을 VLM에 넘길 것인가.

참고자료

저장소와 공식 문서

• Microsoft Research. GraphRAG — github.com/microsoft/graphrag README의 “maintenance mode” 및 비용·프롬프트 튜닝 안내 (2026년 9월 열람)
• HKUDS. LightRAG: Simple and Fast Retrieval-Augmented Generation — github.com/HKUDS/LightRAG (MIT) README의 2026년 변경 이력·PostgreSQL 권고
• Amazon Web Services. Build a knowledge base with Amazon Neptune Analytics graphs — Bedrock 사용자 가이드 (리전·제약 목록)

연구 논문

• Li, Z., Xing, X., Guo, K. & Xu, X. Beyond Similarity through Zero-Token Geometric Graphs for Multi-Hop RAG (G³RAG). arXiv:2609.19622 (2026년 9월 17일, 화남이공대학)
• Wu, Y., Li, J., Liang, X., Chen, Y., Liang, Y., Mo, L. & Li, G. SAG: SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges. arXiv:2606.15971 (v1 2026년 6월 14일, v2 8월 25일, Zleap AI) — 코드: Zleap-AI/SAG, 벤치마크: Zleap-AI/SAG-Benchmark. 중복 제출본 arXiv:2608.12129는 철회됨
• Xiang, Z. et al. When to use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation (GraphRAG-Bench). arXiv:2506.05690, ICLR 2026
• Gutiérrez, B. J. et al. From RAG to Memory: Non-Parametric Continual Learning for Large Language Models (HippoRAG 2). arXiv:2502.14802 (2025)
• Guo, Z. et al. LightRAG: Simple and Fast Retrieval-Augmented Generation. arXiv:2410.05779 (2024)
• Edge, D. et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130 (2024)
• Ming, H. et al. Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki. arXiv:2605.25480 (2026) — 1편 4장

함께 읽으면 좋은 코어닷투데이 글

• GraphRAG는 정말 효과적인가? — ICLR 2026 논문이 밝힌 9가지 진실 — 이 글의 출발점: 단순 질문엔 RAG가, 복잡한 추론엔 그래프가, 그리고 토큰 비용
• GraphRAG는 언제 써야 할까? — 그래프가 이기는 순간과 지는 순간
• GraphRAG 완전 가이드 · GraphRAG 검색 4총사 — 2024~2025년 공식의 원형
• From RAG to Memory: HippoRAG 2 완전 해부 — 이 글의 두 논문이 모두 최강 기준선으로 삼은 시스템
• 사건은 문서가 아니라 궤적이다 — Microsoft RAFT — 장비×증상×조치×결과 축과 결합할 수 있는 상태 기반 검색
• 검색은 파이프라인이 아니라 에이전트가 되었다 — RAG 특집 1편 — LLM-Wiki와 Agentic Search