[학습] LightRAG vs GraphRAG — 그래프 RAG의 경량화 버전

TL;DR — LightRAG는 GraphRAG에서 비싼 커뮤니티 탐지 단계를 제거하고, 그래프 탐색 + 벡터 유사도를 병행하는(dual-mode retrieval) 경량 RAG다. 500페이지 기준 인덱싱 비용이 약 100배 저렴하고, 증분 업데이트도 지원한다. 대부분의 RAG 케이스에서 LightRAG가 디폴트, 멀티-홉 관계 추론·커뮤니티 레벨 인사이트가 필요할 때만 GraphRAG.

개념 설명

핵심 아이디어

GraphRAG와 LightRAG는 둘 다 "문서를 지식 그래프로 만든 뒤 검색에 활용" 한다는 공통점이 있다. 차이는 그래프를 어떻게 다루느냐다.

```

GraphRAG (Microsoft, 2024.04)

1. 전체 코퍼스 → LLM 호출로 엔티티·관계 추출

2. Leiden 알고리즘으로 커뮤니티(그룹) 탐지

3. 계층별 요약 사전 생성

4. 쿼리 시: 커뮤니티 요약 + 그래프 탐색

LightRAG (홍콩대, 2024.10)

1. 동일하게 엔티티·관계 추출 (KG 구축)

2. 커뮤니티 탐지 없음 (flat graph)

3. 쿼리 시 dual-mode retrieval:

- Low-level: 특정 엔티티/관계 직접 검색 (정밀)

- High-level: 벡터 유사도로 맥락 검색 (광범위)

- 두 결과 merge → LLM에 전달

4. 증분 업데이트: 새 문서를 union으로 추가

```

핵심 제거 단계는 Leiden 커뮤니티 탐지. GraphRAG의 인덱싱 비용 대부분이 여기서 나온다.

왜 중요한가

500페이지 문서 기준:

항목	GraphRAG	LightRAG
인덱싱 LLM 호출 비용	$$$$	$ (~1/100)
인프라 복잡도	배치 파이프라인 + 그룹 요약 저장	KV store + 벡터 DB
증분 업데이트	재빌드 권장	union으로 추가
멀티-홉 관계 추론	강함	보통
커뮤니티 레벨 인사이트	가능	불가

대부분의 실무 RAG는 "문서에서 정답 찾기" 수준이라 LightRAG로 충분하다. GraphRAG가 필요한 케이스는 "이 도메인 전체에서 X 그룹은 어떤 특징을 갖나" 같은 매크로 질의다.

실전 적용

백엔드 엔지니어 관점에서 본 운영 차이

*GraphRAG*: 배치 ETL을 한 번 더 도입하는 셈. 커뮤니티 요약 캐시 무효화 전략, 재빌드 트리거, 계층 그래프 스토리지(보통 Neo4j + 별도 요약 store)가 필요. 데이터 freshness가 낮은 정적 코퍼스에 적합.
*LightRAG*: KV store(엔티티/관계) + 벡터 DB(임베딩) 두 컴포넌트면 끝. 새 문서가 들어오면 추출 → union → 인덱스 갱신. Spring 기준으로 보면 *배치 + 캐시 워밍업*이 사라지고, *서비스 레이어에서 두 store에 fan-out 후 merge* 패턴 하나로 통일된다.

Dual-level retrieval이 왜 영리한가

전통 벡터 RAG는 "이 청크가 답을 가졌나"만 본다. 엔티티 단위 관계는 못 잡는다. 반대로 순수 그래프 RAG는 정확한 엔티티 매칭이 안 되면 빈손이다. LightRAG는 둘을 병행해서 한쪽이 빈손이어도 다른 쪽이 커버한다 — 이 단순한 OR 구조가 GraphRAG의 커뮤니티 요약 없이도 품질을 유지하는 핵심 트릭이다.

예시 / 데이터 흐름

쿼리: "양항승이 다빈치 서클에서 맡은 역할은?" [Low-level path] → 그래프에서 "양항승" 노드 → "다빈치 서클" 노드 간 엣지 탐색 → "engineer", "DAV-29 owner" 같은 정밀 사실 추출 [High-level path] → 쿼리 임베딩 → 벡터 DB에서 유사 청크 top-k → "역할", "책임", "DAV 팀" 관련 맥락 청크 추출 [Merge] → 두 결과를 프롬프트에 동시 주입 → LLM 답변

함정 / 주의점

엔티티 추출 품질이 모든 것을 결정 — LLM이 엔티티를 잘못 뽑으면 dual-mode 둘 다 망가진다. 추출 단계 모델은 절약하지 말 것.
증분 업데이트 = 항상 안전 아님 — 같은 엔티티가 다른 표기로 들어오면 노드 중복이 누적된다. 정기 dedupe 잡 필요.
커뮤니티 레벨 질문은 답 못함 — "이 도메인의 주요 흐름은?" 같은 매크로 요약은 LightRAG의 약점. 벡터 검색이 청크 단위라 전역 시야가 부족하다.
벡터 DB ≠ 진리 — Low-level path가 빈손일 때 High-level이 hallucination 청크를 가져오면 LLM이 잘못된 사실을 그럴듯하게 합성할 수 있다. 출처 표기 필수.

우리 시스템에 쓸 만한 곳

*Pantheon · Jarvis 컨텍스트 검색*: 현재 키워드 검색·MCP search 기반. 페르소나가 "이전 ADR-002에서 X 어떻게 결정했지?" 같은 질의를 할 때, hangman-docs + Notion 코퍼스를 LightRAG로 인덱싱하면 dual-mode가 fit. KV store는 SQLite, 벡터 DB는 chromadb/qdrant 정도로 시작 가능.
*IronCoach 운동 지식 베이스*: 운동 종목·근육군·부상 패턴이 엔티티-관계 구조에 잘 맞는다. 코퍼스가 작아서 GraphRAG는 과잉, LightRAG가 정확히 맞는 사이즈.
*반대로 부적합한 곳*: 일정 DB, 짧은 Slack 스레드 — 그래프화할 만큼의 구조가 없다. 일반 벡터 RAG로 충분.

복습 일정

단계	날짜	완료
Day 0 (초학습)	2026-06-01	☐
Day 7	2026-06-08	☐
Day 37	2026-07-08	☐
Day 127	2026-10-06	☐

참고

원본 영상:
LightRAG 논문: Guo et al., "LightRAG: Simple and Fast Retrieval-Augmented Generation" (2024.10)
GraphRAG (Microsoft):
Slack 원본 분석 스레드: #signal-feed 2026-06-01