필사 모드: Graph RAG란 무엇인가 — 벡터 RAG가 막히는 곳, 그리고 이게 값을 하는 순간

• 들어가며 — 벡터 RAG를 복습하고, 어디서 막히는지 보기
• 벡터 RAG가 못 푸는 두 가지 질문
• GraphRAG란 무엇인가 — 그래프 색인을 만드는 과정
• 로컬 검색 vs 글로벌 검색
• 구체적인 예 — 인시던트 코퍼스
• 정직한 트레이드오프 — 값이 싸지 않다
• 그래서, 당신은 써야 하나
• 마치며
• 참고 자료

들어가며 — 벡터 RAG를 복습하고, 어디서 막히는지 보기

RAG(검색 증강 생성)의 표준 레시피는 이미 프로덕션 RAG 패턴 편에서 정리했습니다. 요약하면 이렇습니다 — 문서를 청크로 자르고, 임베딩해서 벡터 DB에 넣고, 질문과 의미가 가장 가까운 상위 k개 청크를 뽑아 프롬프트에 붙인다. 하이브리드 검색과 리랭킹까지 얹으면, "이 문서 어디에 X가 적혀 있나" 류의 질문은 대부분 이걸로 충분히 풀립니다.

그런데 이 파이프라인에는 구조적인 사각지대가 있습니다. 벡터 검색은 결국 "질문과 의미가 가까운 조각"을 찾는 일이고, 답이 어느 한 조각 안에 통째로 들어 있을 때 가장 잘 작동합니다. 문제는 답이 여러 조각에 흩어져 있거나, 아예 어떤 조각에도 명시돼 있지 않을 때입니다.

벡터 RAG가 못 푸는 두 가지 질문

첫째, 멀티홉 질문. "가장 큰 장애들에 관여한 팀이 소유한 다른 서비스 중 Postgres에 의존하는 것은?" 이 답은 여러 단계의 연결을 따라가야 나옵니다 — 장애 → 팀 → 서비스 → 의존성. 어떤 청크도 이 사슬 전체를 담고 있지 않습니다. 상위 k개를 아무리 잘 뽑아도, 서로 다른 문서에 흩어진 고리를 이어 붙이는 일은 검색이 아니라 추론입니다.

둘째, 글로벌 "센스메이킹" 질문. "우리 포스트모템 전체를 관통하는 반복 주제는 무엇인가?" GraphRAG 논문이 든 정확한 예가 이것입니다 — "What are the main themes in the dataset?". 이건 검색 문제가 아니라 요약 문제입니다. 논문의 표현으로는 쿼리 중심 요약(query-focused summarization)이고, 답은 특정 청크가 아니라 코퍼스 전체에 퍼져 있습니다. 상위 k개를 뽑는 순간 이미 진 게임입니다 — k개는 전체가 아니니까요. 그렇다고 "전부 다 컨텍스트에 넣기"는 100만 토큰짜리 코퍼스에서는 불가능하고, 가능해도 lost-in-the-middle로 무너집니다.

GraphRAG란 무엇인가 — 그래프 색인을 만드는 과정

Microsoft의 GraphRAG(Edge 등, arXiv:2404.16130)는 이 두 사각지대를 정면으로 겨냥합니다. 핵심 아이디어는 "검색하기 전에, LLM으로 코퍼스에서 지식 그래프를 미리 뽑아 두자"입니다. 논문의 표현으로는 LLM이 두 단계로 그래프 색인을 만든다 — 먼저 엔티티 지식 그래프를 뽑고, 그다음 밀접하게 연결된 엔티티 그룹마다 커뮤니티 요약을 미리 생성한다.

색인 파이프라인은 이렇게 흐릅니다.

1. 청킹. 코퍼스를 TextUnit이라 부르는 분석 단위로 자른다. (여기까지는 보통 RAG와 같습니다.)
2. 추출. 각 TextUnit에서 LLM이 엔티티, 관계, 그리고 핵심 주장(claim)을 뽑는다. 예컨대 "결제서비스 —(소유)→ 앨리스팀", "결제서비스 —(의존)→ Postgres" 같은 트리플이 쌓입니다.
3. 그래프 구축. 뽑은 엔티티를 노드로, 관계를 엣지로 이어 코퍼스 전체를 하나의 지식 그래프로 만든다.
4. 커뮤니티 탐지. Leiden 알고리즘으로 그래프를 계층적으로 클러스터링한다. 촘촘히 연결된 노드들이 한 커뮤니티로 묶이고, 커뮤니티는 다시 상위 커뮤니티로 계층을 이룹니다. (Leiden은 Louvain을 개선해 "잘 연결된 커뮤니티"를 보장하는 커뮤니티 탐지 알고리즘입니다 — Traag 등, 2019.)
5. 커뮤니티 요약. 각 커뮤니티에 대해 아래에서 위로(bottom-up) LLM이 요약을 생성한다. "이 커뮤니티는 결제 인프라와 그 장애 이력에 관한 것" 같은 요약이 계층마다 만들어집니다.

여기서 중요한 전환은, 비싼 이해 작업을 질의 시점이 아니라 색인 시점에 미리 해 둔다는 것입니다. 코퍼스를 이해하는 비용을 선불로 치르는 셈입니다.

로컬 검색 vs 글로벌 검색

이렇게 만들어 둔 두 구조(그래프 + 커뮤니티 요약)를 질문 유형에 따라 다르게 씁니다.

글로벌 검색(Global Search) 은 앞의 센스메이킹 질문용입니다. 방식은 맵-리듀스입니다 — 맵 단계에서 각 커뮤니티 요약이 질문에 대한 부분 답변을 하나씩 만들고(각각 유용성 점수와 함께), 리듀스 단계에서 그 부분 답변들을 모아 최종 답변으로 합칩니다. 논문의 문장 그대로 옮기면, 각 커뮤니티 요약으로 부분 응답을 만든 뒤 모든 부분 응답을 다시 요약해 최종 응답을 만드는 것입니다. 코퍼스 전체를 훑어야 하는 질문에, 원본 청크가 아니라 미리 만든 요약을 훑습니다.

로컬 검색(Local Search) 은 특정 엔티티에 관한 질문용입니다. 질문에서 엔티티를 찾아 그래프에서 그 이웃으로 부채꼴처럼 퍼져 나가며(fan-out), 연결된 관계·텍스트 조각·커뮤니티 요약을 모아 컨텍스트를 만듭니다. 멀티홉 질문이 여기서 풀립니다 — 그래프를 따라 걸으면 흩어진 고리가 이어지니까요. (여기에 커뮤니티 맥락까지 더한 DRIFT 검색이라는 변형도 있습니다.)

한 줄 요약: 글로벌은 "숲"을, 로컬은 "나무와 그 이웃"을 봅니다.

구체적인 예 — 인시던트 코퍼스

지난 1년치 장애 포스트모템 수백 건을 색인했다고 해 봅시다.

질문 A (로컬 / 멀티홉): "결제서비스 장애에 관여한 팀이 소유한 다른 서비스는?"
  벡터 RAG:      결제서비스 청크 몇 개를 반환 -> 팀 -> 다른 서비스 연결은 놓침
  GraphRAG(로컬): 결제서비스 노드 -(관여)-> 팀 노드 -(소유)-> 서비스 노드
                 그래프를 몇 홉 걸어 답을 조립

질문 B (글로벌 / 센스메이킹): "작년 포스트모템 전체의 반복 주제는?"
  벡터 RAG:        상위 k개 포스트모템만 반환 -> "전체 주제"는 원리상 안 나옴
  GraphRAG(글로벌): 커뮤니티 요약들을 맵-리듀스
                   커뮤니티1: DB 페일오버 / 커뮤니티2: 배포 롤백 / 커뮤니티3: 인증 만료
                   -> "반복 주제 3가지" 로 리듀스

질문 C (단순 로컬 조회): "ERR_2043 이 무슨 뜻?"
  벡터 RAG:      해당 청크 하나 반환 -> 충분함 (GraphRAG는 과잉)

질문 C가 중요합니다. 모든 질문이 그래프를 필요로 하는 게 아닙니다 — 대부분의 실무 질문은 여전히 C에 가깝습니다.

정직한 트레이드오프 — 값이 싸지 않다

이제 정직해질 부분입니다. GraphRAG는 공짜가 아닙니다.

색인 비용. 추출 단계는 코퍼스의 모든 청크에 LLM을 돌립니다(놓친 엔티티를 줍기 위해 GraphRAG는 여러 번의 gleaning 패스를 돕니다). 그리고 커뮤니티 요약 단계는 계층의 모든 커뮤니티마다 또 LLM을 돌립니다. 즉 색인 비용이 코퍼스 크기에 비례해 붙고, 그 대부분이 LLM 호출입니다. Microsoft가 공개한 자료는 구체적 금액을 제시하지 않으므로 여기서 숫자를 지어내진 않겠지만, "문서를 임베딩만 하면 되는" 벡터 RAG의 색인과는 자릿수가 다른 작업이라는 점은 분명합니다.

지연과 갱신. 색인은 배치 작업이고, 큰 코퍼스에서는 분~시간 단위가 걸립니다. 더 아픈 건 갱신입니다 — 문서가 바뀔 때마다 그래프와 요약을 다시 만들어야 하고(증분 색인이 있지만 복잡도를 더합니다), 그래서 실시간으로 계속 바뀌는 코퍼스와는 궁합이 나쁩니다.

질의 비용. 글로벌 검색 자체도 싸지 않습니다 — 맵-리듀스가 여러 커뮤니티 요약에 걸쳐 LLM을 여러 번 호출하니까요. 로컬 검색은 훨씬 쌉니다.

추출 품질 의존. 그래프는 추출이 뽑아낸 만큼만 좋습니다. 엔티티를 엉망으로 뽑으면 엉망인 그래프가 나오고, 그래서 도메인마다 추출 프롬프트를 튜닝해야 합니다. 무엇을 엔티티로 볼지, 어떤 관계가 의미 있는지는 결국 도메인 모델링 문제입니다 — 이 이야기는 도메인 지식을 온톨로지로 모델링하기와 지식 그래프를 실제로 구축하기 편에서 따로 다룹니다.

그래서, 당신은 써야 하나

판단 기준은 이렇게 정리됩니다.

써서 값을 하는 경우

• 질문이 글로벌·주제형이다 — "전체 주제", "전반적 경향", "X와 Y가 코퍼스 전반에서 어떻게 얽히나".
• 여러 문서를 가로지르는 멀티홉 추론이 필요하다.
• 코퍼스가 비교적 안정적이고, 색인 비용을 상환할 만큼 자주·오래 질의된다.

과잉인 경우

• 질문이 대부분 로컬 조회다 — "X가 어디 적혀 있나", "이 에러 뜻은".
• 코퍼스가 쉴 새 없이 바뀐다.
• 예산·지연 여유가 빠듯하고, 하이브리드 검색 + 리랭킹이 이미 평가 기준을 통과한다.

현실의 프로덕션은 대개 둘 중 하나를 고르지 않고 섞습니다. 로컬 조회는 값싼 벡터·하이브리드 검색으로 처리하고, 진짜 센스메이킹 질문에만 그래프를 씁니다. GraphRAG 자체가 로컬 검색 모드를 갖고 있다는 사실이 이미 이 하이브리드 성격을 말해 줍니다 — 그래프 대 벡터의 이분법이 아니라, 질문 유형에 맞는 도구를 고르는 스펙트럼입니다. 실제 구현 도구 — microsoft/graphrag 라이브러리부터 Neo4j, LlamaIndex의 그래프 인덱스까지 — 의 비교는 Graph RAG를 굴리는 도구들 편에서 따로 다룹니다.

그리고 프로덕션 RAG 패턴 편의 원칙이 여기서도 그대로입니다 — 벤치마크가 아니라 당신의 질의로 평가하세요. 논문이 보고한 개선(글로벌 센스메이킹 질문에서 답변의 comprehensiveness와 diversity 향상)은 LLM 심사(LLM-as-judge)로 매긴 저자 보고 수치이고, 100만 토큰대 데이터셋 기준입니다. 당신의 코퍼스·당신의 질문에서 같은 이득이 나오는지는 작은 평가 셋으로 직접 확인해야 할 문제입니다.

마치며

정리하면 이렇습니다. 벡터 RAG는 답이 한 조각에 들어 있는 질문에 강하고, 멀티홉과 글로벌 센스메이킹에서 구조적으로 막힙니다. GraphRAG는 그 두 사각지대를 겨냥해, 비싼 이해 작업을 색인 시점으로 옮깁니다 — LLM으로 지식 그래프를 뽑고, Leiden으로 커뮤니티를 찾고, 커뮤니티 요약을 미리 만든 뒤, 글로벌 질문은 요약들의 맵-리듀스로, 로컬 질문은 엔티티 중심 그래프 탐색으로 답합니다.

대신 색인이 LLM 비용을 크게 먹고, 갱신이 번거롭습니다. 그래서 GraphRAG는 "더 좋은 RAG"가 아니라 "다른 질문을 푸는 RAG"입니다. 바닐라·하이브리드로 시작해서, 글로벌 센스메이킹이 실제 실패 지점으로 드러날 때 — 그때 그래프를 꺼내십시오. 도구가 아니라 질문이 먼저입니다.

참고 자료

• From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Edge 등, arXiv 2404.16130)
• microsoft/graphrag — 공식 구현 저장소
• GraphRAG 문서 — 색인 파이프라인과 검색 모드(Global/Local/DRIFT)
• Microsoft Research — GraphRAG: Unlocking LLM discovery on narrative private data
• From Louvain to Leiden: guaranteeing well-connected communities (Traag 등, arXiv 1810.08473)
• 프로덕션 RAG 패턴 — 벡터·하이브리드 검색과 평가(관련 글)