검색 증강 생성에 GraphRAG가 필요한 순간: 원리와 도입 기준

2026년 10월 26일 문서 확인 완료. Microsoft GraphRAG 문서와 저장소, Neo4j 및 LlamaIndex 문서를 기준으로 확인했습니다. 아래 비교는 문서에 명시된 작동 방식을 분석한 결과이며, 성능 테스트 결과는 아닙니다. 제품 피드백 사례는 이해를 돕기 위한 예시입니다.

GraphRAG란 무엇인가요?

Microsoft GraphRAG는 사용자가 요청하기 전에 문서 집합의 전체 윤곽을 미리 만들어 둡니다. 대규모 언어 모델(LLM)로 문서에서 엔터티와 관계를 추출하고, 서로 연결된 엔터티를 커뮤니티로 묶은 뒤 커뮤니티별 요약을 생성합니다. 이후 쿼리 엔진은 이 구조를 활용해 질문에 답합니다. Microsoft 개요 문서에서 이 방식과 주요 검색 모드를 설명합니다.

엔터티는 데이터에 이름이 등장하는 고객, 제품, 사람, 프로젝트 같은 대상입니다. 관계는 엔터티 사이의 연결입니다. 고객이 제품을 사용하거나 프로젝트가 서비스에 의존하는 것이 그 예입니다. 엔터티와 관계를 함께 표현하면 지식 그래프가 됩니다. 커뮤니티는 서로 연결된 엔터티의 묶음이며, 커뮤니티 요약은 문서 집합의 해당 영역에서 어떤 일이 일어나는지 설명합니다.

문서 집합을 캠퍼스라고 생각해 보겠습니다. 벡터 검색은 질문과 비슷한 내용이 담긴 방을 찾습니다. 그래프의 관계는 방들을 연결합니다. 커뮤니티 요약은 위층의 연결 통로에서 전체를 내려다보는 역할을 합니다. 캠퍼스 전반에서 무슨 일이 벌어지는지 물었는데 비슷한 방 몇 개만 둘러본다면, 건물의 한쪽 구역 전체를 놓칠 수 있습니다.

익숙한 검색 실패도 여기서 비롯됩니다. 검색 증강 생성 앱은 모델이 답하기 전에 검색한 근거를 제공하는 방식으로 작동합니다. 이런 앱이 내보내기 정책은 정확히 찾아 주면서도, “이 인터뷰 전체를 보면 고객들이 어떤 점에서 불편을 겪고 있나요?”에는 피상적으로 답할 수 있습니다. 후자의 질문에는 문서 집합을 폭넓게 살펴봐야 합니다. 답을 직접 적어 둔 구절이 아예 없을 수도 있습니다.

“Graph RAG”는 그래프를 활용하는 검색 시스템 전반을 가리키는 표현이기도 합니다. 이 글은 Microsoft의 구현을 중심으로 설명합니다. 다른 프레임워크로 그래프 기반 앱을 만들었다고 해서 Microsoft 방식의 커뮤니티 보고서가 자동으로 생성되거나 글로벌 검색 방식이 적용되는 것은 아닙니다.

GraphRAG는 어떻게 작동하나요?

핵심 변화는 인덱싱 단계에서 일어납니다. GraphRAG는 데이터를 바탕으로 설명 자료를 생성해 두고 이후 쿼리에서 재사용합니다. Microsoft의 표준 인덱싱 방식은 추출과 요약에 LLM을 사용하고, 커뮤니티 구조는 그래프 클러스터링으로 만듭니다.

각 단계는 다음 순서로 이어지며 앞 단계의 결과에 의존합니다.

1. 문서를 텍스트 단위로 나눕니다. 원문을 나눈 청크가 텍스트 단위입니다. 원본 문서와의 연결을 남겨 두면 추출한 항목이 어디에서 나왔는지 출처를 추적할 수 있습니다.
2. 엔터티와 관계를 추출합니다. LLM이 각 텍스트 단위를 읽고, 그 안에서 찾은 엔터티와 연결 관계를 기술합니다.
3. 그래프를 통합합니다. 같은 엔터티와 관계에 대한 설명을 합치고 요약합니다. 문서에 명시된 병합 규칙은 엔터티의 이름과 유형, 관계의 출발점과 도착점을 기준으로 합니다.
4. 커뮤니티를 찾습니다. 그래프 클러스터링 알고리즘인 Hierarchical Leiden이 연결된 엔터티들을 여러 세부 수준으로 묶습니다.
5. 커뮤니티 보고서와 임베딩을 생성합니다. LLM이 커뮤니티를 요약합니다. 검색 대상 산출물에는 유사도 검색에 쓰이는 수치 표현인 임베딩도 생성합니다.

이 단계는 Microsoft의 인덱싱 데이터 흐름을 따릅니다. 주장 추출은 선택적으로 추가하는 워크플로이며 기본적으로 꺼져 있습니다. 표준 그래프와 보고서를 만들기 위해 반드시 주장을 추출할 필요는 없습니다.

제품 피드백 문서라면 한 인터뷰에 Atlas 프로젝트, 내보내기 실패, 승인 절차가 등장할 수 있습니다. 다른 대화에서는 Atlas와 공유 워크스페이스의 연결이 드러날 수 있습니다. 추출 과정에서 이런 연결을 포착하면 문서마다 표현이 달라도 커뮤니티 보고서에서 관련 문제를 한데 모을 수 있습니다.

취약점도 이 단계에서 드러납니다. 추출 과정에서 관계를 놓치거나, 서로 다른 엔터티를 합치거나, 같은 엔터티를 가리키는 별칭을 따로 분리하면 이후 요약에도 왜곡된 구조가 그대로 반영됩니다. 깔끔하게 연결된 그래프도 결국 텍스트에 대한 해석입니다.

Microsoft의 기본 구성은 인덱스 결과를 열 지향 파일 형식인 Parquet 테이블로 저장하고, 임베딩은 설정된 벡터 저장소에 기록합니다. 이 기본 구조에는 별도의 그래프 데이터베이스가 필요하지 않습니다. 인덱싱 개요.

글로벌·로컬·DRIFT·Basic 검색은 어떻게 다른가요?

답변에 어떤 근거가 필요한지에 따라 쿼리 모드를 선택합니다. 글로벌 검색은 문서 집합 전반의 패턴을 다루고, 로컬 검색은 관련 엔터티 주변에서 출발합니다. 나머지 모드는 탐색 범위를 넓히거나 벡터 검색 기준선을 제공합니다.

글로벌 검색: 문서 전체에 걸친 주제 파악

“이 문서 전체의 핵심 주제는 무엇인가요?”라는 질문 때문에 Microsoft GraphRAG를 검토한다면 글로벌 검색이 핵심입니다. 계층에서 선택한 수준의 커뮤니티 보고서를 답변의 재료로 사용합니다.

방식은 **맵 리듀스(map-reduce)**입니다. 여러 배치를 따로 처리한 뒤 결과를 합칩니다. 맵 단계에서는 보고서 배치별로 점수가 매겨진 논점들을 포함한 부분 답변을 생성합니다. 리듀스 단계는 유용한 논점을 골라 최종 답변으로 구성합니다. 더 상세한 커뮤니티 보고서를 사용하면 답변도 구체적일 수 있지만 필요한 자원도 늘어날 수 있습니다. 글로벌 검색 문서.

고객 피드백을 검토하는 제품 책임자에게 기대되는 효과는 더 넓은 범위를 다루는 답변입니다. 온보딩, 승인, 협업에 관한 내용이 모두 답변에 반영될 수 있습니다. 비슷한 구절을 더 많이 가져오는 것만으로는 서로 다른 영역이 빠짐없이 포함된다고 보장할 수 없습니다.

한계도 분명히 알아야 합니다. 글로벌 검색은 보고서를 종합합니다. 각 문제를 언급한 고객이 몇 명인지 정확히 세는 방식은 아닙니다. 의사결정에 빈도 순위가 필요하다면 집계 단위와 중복 제거 기준을 명확히 정해 수를 센 뒤, 모델이 그 결과를 설명하도록 해야 합니다.

로컬 검색: 특정 엔터티와 주변 관계 탐색

로컬 검색은 “Atlas 프로젝트는 내보내기 문제와 어떻게 연결되나요?” 같은 질문에 맞습니다. 의미상 관련된 엔터티를 찾고, 연결된 그래프 정보와 관련 원문 구절을 모은 뒤, 답변에 사용할 컨텍스트 윈도에 맞게 자료를 추립니다. 로컬 검색 문서.

답변에 필요한 관계가 여러 문서에 흩어져 있을 때 유용합니다. 그래프는 탐색의 시작점과 연결을 제공하고, 원문 구절은 이를 뒷받침하는 세부 내용을 제공합니다. 로컬 검색도 유사도 매칭을 사용하며 컨텍스트 크기에 제약이 있으므로, 관련 관계가 모두 답변에 나타난다고 보장할 수는 없습니다.

DRIFT 검색: 넓은 맥락에서 출발하는 탐색

DRIFT는 관련 커뮤니티 정보에서 출발해 후속 질문을 만들고 로컬 검색으로 이어 갑니다. 처음의 포괄적인 답변에서 더 구체적으로 조사할 방향이 드러나는 탐색형 질문에 적합합니다. DRIFT 문서.

예를 들어 “이 고객들은 왜 협업에 어려움을 겪나요?”라는 질문은 승인 절차, 공동 책임, 내보내기 결과물의 인계 문제를 각각 조사하는 흐름으로 이어질 수 있습니다. 일상적인 질문에 DRIFT를 기본으로 적용하기 전에, 추가 검색에서 실제로 유용한 근거를 얻는지 평가해야 합니다.

Basic 검색: 비교 기준으로 남겨 둘 벡터 검색

Basic 검색은 벡터 검색으로 유사한 텍스트 청크를 가져옵니다. Microsoft는 쿼리 유형 간 비교를 쉽게 하도록 이 모드를 포함했습니다. “내보내기 정책에는 무엇이라고 나와 있나요?”처럼 범위가 좁은 질문의 대조군으로 유용합니다. 쿼리 엔진 문서.

검색 증강 생성 방식 비교: GraphRAG는 어떤 질문에 맞을까요?

질문을 안정적으로 처리하는 가장 단순한 검색 방식을 유지하는 것이 좋습니다. 아래에서는 질문과의 적합성, 인덱싱 작업, 유지·관리를 나누어 비교합니다. 아키텍처에 대한 판단이며, 비용이나 속도를 측정한 순위는 아닙니다.

하이브리드 검색이 해결하는 문제는 문서 전체를 종합하는 문제와 다릅니다. Microsoft의 하이브리드 검색 문서는 전문 검색 결과와 벡터 검색 결과를 결합하는 방식을 설명합니다. 앱이 정확한 제품 코드를 놓친다면 하이브리드 검색부터 검토합니다. 어휘 검색 문제를 글로벌 커뮤니티 요약으로 해결하려는 것은 우회적인 접근입니다.

에이전틱 RAG는 검색 워크플로를 바꿉니다. LangGraph의 에이전틱 검색 튜토리얼처럼 모델이 검색을 선택하고, 관련성을 판단하고, 질문을 다시 작성해 재검색할 수 있습니다. 앱이 다음에 어떤 근거를 모을지 결정해야 한다면 에이전틱 RAG를 사용합니다.

이 방식들은 함께 쓸 수도 있습니다. 에이전트가 그래프 리트리버를 호출할 수 있고, 그래프 기반 리트리버가 하이브리드 검색에서 출발할 수도 있습니다. 판단해야 할 것은 어떤 추가 메커니즘이 실제로 관찰된 실패를 해결하는가입니다. 한꺼번에 모두 도입하면 이를 확인하기가 더 어려워집니다.

GraphRAG 인덱싱에는 왜 더 많은 작업이 필요한가요?

표준 GraphRAG는 기본 벡터 인덱스의 임베딩 작업에 생성형 처리를 더합니다. 문서 수에 일률적으로 곱할 수 있는 타당한 비용 배수는 없습니다. 필요한 작업은 텍스트, 추출 설정, 생성하는 그래프와 보고서에 따라 달라집니다.

계획을 세울 때는 다음과 같이 나누어 보면 유용합니다.

인덱싱 작업 = 청크 처리 + 추출 실행 + 설명 요약 + 커뮤니티 보고서 + 임베딩.

이는 파일럿에서 작업량을 집계하기 위한 틀이며 공급업체의 가격 산식이 아닙니다. 단계별로 작업량을 기록해야 데이터를 추가할 때 무엇이 늘어나는지 알 수 있습니다.

청크가 반복 추출 작업량을 결정합니다. 청크가 많을수록 분석할 텍스트 단위도 많아집니다. 청크 크기와 겹침 정도에 따라 추출기가 반복해서 읽는 맥락의 양이 달라집니다. Microsoft 설정에는 추가 추출 주기를 제어하는 max_gleanings도 있습니다. 모든 청크가 언제나 LLM 호출 한 번으로 처리된다고 가정해서는 안 됩니다. 설정 레퍼런스.

그래프 크기가 후속 처리할 자료의 양을 결정합니다. 서로 다른 엔터티와 관계가 많은 문서 집합은 크기가 비슷해도 주제가 좁은 문서 집합보다 통합할 설명이 더 많이 생길 수 있습니다. 반복 언급에서는 병합할 설명이 생기고, 다양한 연결은 보고서가 필요한 커뮤니티의 구성을 좌우합니다. 이는 문서 수만으로 결정되는 것이 아니라 추출과 요약 단계의 특성에서 비롯됩니다.

보고서는 별도의 생성 작업을 더합니다. 커뮤니티 내용을 요약해야 하며, 계층마다 서로 다른 수준의 개요가 만들어집니다. 임베딩도 여전히 인덱스의 일부입니다. 이러한 작업량의 원인을 파악하려면 표준 방식의 작업 목록부터 살펴보는 것이 좋습니다.

캐시를 재사용하면 모델의 반복 작업을 줄일 수 있습니다. Microsoft는 이후 인덱싱 실행에 활용하도록 LLM 호출 결과를 캐시에 저장합니다. 최초 구축과 갱신은 따로 측정해야 합니다. 캐시를 사용하는 재실행으로는 새 문서 집합에 필요한 작업량을 알 수 없습니다. 캐시 설정.

쿼리 처리에 드는 자원은 별도로 산정해야 합니다. 인덱싱이 끝난 뒤에도 글로벌 검색의 맵 리듀스와 DRIFT 탐색에서 모델이 여러 차례 동작할 수 있습니다. 인덱싱 파일럿이 성공했다고 답변 지연 시간까지 허용 범위에 든다는 뜻은 아닙니다.

문서는 최신이어도 전체 주제 요약은 오래된 상태일 수 있습니다

새 문서가 저장소에 들어왔다고 글로벌 검색이 사용하는 보고서까지 최신이 되는 것은 아닙니다. 최신 상태를 유지할 대상을 정할 때는 쿼리가 실제로 읽는 파생 인덱스까지 포함해야 합니다.

Microsoft는 graphrag update를 제공합니다. 현재 CLI 문서에 따르면 새 인덱스는 기본적으로 update_output에 기록됩니다. 설정에서도 기존 출력을 보존할 수 있도록 별도의 갱신용 저장소를 제공합니다. 증분 갱신은 가능하지만, 갱신 명령 하나만으로 동기화 정책이 완성되지는 않습니다. CLI 레퍼런스, 갱신용 저장소.

Atlas에 관한 이전 주장을 바로잡는 고객 지원 대화를 생각해 보겠습니다. 새 문서가 존재해도 운영 중인 커뮤니티 보고서는 여전히 예전 상황을 설명할 수 있습니다. 직접 검색으로 정정 내용을 찾을 수 있더라도 이는 유지·관리의 실패입니다.

실제로 배포하는 버전과 설정에서 추가, 수정, 삭제를 테스트합니다. 원문 청크와 추출된 관계, 로컬 및 글로벌 답변을 모두 확인합니다. 인용한 CLI 문서만으로는 모든 변경이 앱에 필요한 의미를 유지하며 자동 전파된다고 단정할 수 없습니다.

운영에 필요한 것은 확인 가능한 인덱스 버전과 명확한 원본 반영 기준 시점입니다. 서로 일관된 산출물 묶음을 배포하고, 쿼리가 해당 버전을 사용하도록 연결합니다. 빠르게 바뀌는 기록에 대해 즉시 답해야 하는 업무라면, 보고서 갱신 과정을 평가하는 동안 직접 검색할 경로도 유지합니다.

그래프 기반 RAG를 구성하는 다른 두 가지 접근법

Neo4j와 LlamaIndex는 추출, 저장, 쿼리 방식이 서로 다른 그래프 검색 구성 요소를 제공합니다. “GraphRAG”를 서로 대체 가능한 단일 제품처럼 다루기보다 각 문서에 설명된 메커니즘을 평가해야 합니다.

Neo4j로 GraphRAG 구성하기

Neo4j GraphRAG for Python에는 VectorCypherRetriever가 포함되어 있습니다. 먼저 비슷한 노드를 찾은 다음 검색 쿼리를 실행해 추가 맥락을 수집합니다. Cypher는 Neo4j의 그래프 쿼리 언어입니다. 이 패키지는 벡터 인덱스와 전문 검색 인덱스를 사용하는 하이브리드 검색, 그리고 질문을 데이터베이스 쿼리로 바꾸는 Text2Cypher도 제공합니다. Neo4j 리트리버 가이드.

이 접근법은 관련 노드를 찾은 뒤 어떤 관계를 따라갈지 명시적으로 제어하려는 개발자에게 적합합니다. 예를 들어 프로젝트를 검색한 다음, 미리 정의한 그래프 쿼리로 연결된 의존 대상을 가져올 수 있습니다.

Neo4j의 그래프 구축 툴은 LLM으로 엔터티와 관계를 추출하고, 그래프를 저장하며, 중복 엔터티를 정리하는 기능도 지원합니다. 문서에 설명된 추출 오류 처리 방식에서는 설정을 바꾸지 않으면 실패한 청크를 무시할 수 있습니다. 쿼리가 실행되는지만 볼 것이 아니라 데이터가 빠짐없이 수집되었는지도 확인해야 합니다. Knowledge Graph Builder 가이드.

여기에는 경계가 있습니다. 벡터 검색 뒤에 그래프 쿼리를 실행하는 것만으로는 Microsoft 방식의 계층형 커뮤니티 보고서가 만들어지지 않습니다. 폭넓은 주제 요약이 요구 사항이라면 그 계층을 어떻게 구축할지도 구체적으로 정해야 합니다.

LlamaIndex의 속성 그래프 활용하기

LlamaIndex의 PropertyGraphIndex는 그래프 구축과 검색을 조율합니다. 속성 그래프는 레이블이 붙은 엔터티와 각 엔터티의 속성, 관계를 담습니다. 추출기는 청크 단위로 실행되며, SchemaLLMPathExtractor로 허용된 엔터티 및 관계 패턴만 추출하도록 제한할 수 있습니다. VectorContextRetriever는 임베딩된 그래프 노드를 찾고 연결된 경로를 가져옵니다. 검색 옵션을 통해 원문도 함께 가져올 수 있습니다. 속성 그래프 가이드.

이 접근법은 애플리케이션 프레임워크 안에서 추출기와 리트리버를 설정해 쓰려는 개발자에게 적합합니다. 문서에 나오는 삽입, 업서트, 삭제 작업은 그래프를 유지·관리하는 데 쓸 수 있는 구성 요소입니다. 원본 변경과 파생된 사실을 관리할 정책은 앱에서 별도로 마련해야 합니다.

가능한 작업은 그래프 저장소에 따라 달라진다는 점도 고려해야 합니다. 기본 SimplePropertyGraphStore는 그래프 데이터베이스가 아니며 Cypher를 지원하지 않습니다. 저장 방식과 검색 방식을 함께 선택해야 합니다. 속성 그래프 인덱스에 Microsoft의 글로벌 요약 워크플로가 포함되어 있다고 가정해서도 안 됩니다.

GraphRAG 튜토리얼: 실제로 실패한 질문부터 평가하기

범위를 제한한 문서 집합과 답변을 검토할 수 있는 질문에서 시작합니다. Microsoft 저장소는 인덱싱 비용이 많이 들 수 있다고 경고하며, 시작 가이드에서는 큰 작업에 들어가기 전에 작은 데이터셋으로 익히기를 권장합니다.

워크스페이스와 인증 정보를 설정한 뒤에는 현재 문서의 CLI 문법에 따라 다음 명령을 사용할 수 있습니다.

graphrag index --method standard
graphrag query "What are the main themes across these documents?" --method basic
graphrag query "What are the main themes across these documents?" --method global

현재 CLI 레퍼런스에서 질문은 위치 인수로 전달합니다.

결과는 얼마나 폭넓게 다루는지와 근거가 있는지를 함께 평가합니다. 더 많은 주제를 나열해도 연결 관계를 지어냈다면 문제를 해결한 것이 아닙니다. 검토자가 각 주요 주제의 근거를 추적하고, 기대한 주제 중 빠진 것을 기록하며, 서로 다른 집단을 편의상 하나로 일반화하지 않았는지 확인하도록 합니다.

개발자는 기존 사실 검색의 동작을 허용 가능한 수준으로 유지하면서 실패하던 질문 유형을 해결할 때만 그래프를 도입해야 합니다. 운영자는 수정과 삭제에도 제대로 작동하는 갱신 절차를 요구해야 합니다. 시스템 구축을 의뢰하는 구매자는 그래프 시각화를 답변 개선의 증거로 받아들이기 전에, 대표 문서로 이와 같은 시연을 요청해야 합니다.

근거가 이미 있는데도 모델이 반복해서 잘못된 형식이나 방식으로 답한다면 RAG와 파인튜닝 비교를 다시 살펴봅니다. 더 정교한 인덱스는 근거에 접근하는 문제를 다룹니다. 모든 생성 실패에 자동으로 적합한 해결책이 되는 것은 아닙니다.

GraphRAG, 어디까지가 과장일까요?

확실하게 말할 수 있는 범위는 “그래프를 쓰면 RAG가 좋아진다”보다 좁습니다. 특정 그래프와 쿼리 방식이 특정 유형의 근거 수집을 개선할 수 있다는 정도입니다.

연결되어 있다고 사실로 입증되는 것은 아닙니다. 추출한 관계와 커뮤니티 보고서에도 오류가 있을 수 있습니다. 검색 가능한 해석으로 취급하고 출처 추적 경로를 보존해야 합니다. 그래프 경로 덕분에 검색 과정을 살펴보기 쉬워질 수는 있지만, 그 바탕에 있는 주장이 옳다는 증거가 되지는 않습니다.

연결이 많은 답변이라고 더 빠짐없이 다루는 것은 아닙니다. 폭넓어 보이는 요약도 다른 내용과 연결되지 않은 문제를 놓칠 수 있습니다. 검토용 질문에는 소수 의견에 해당하는 주제와 일반화하기 어려운 예외도 포함해야 합니다. 제품 의사결정에 영향을 줄 수 있다면 특히 중요합니다.

커뮤니티 요약은 빈도표가 아닙니다. 반복 언급, 엔터티의 연결 정도, 모델의 중요도 판단은 고유 고객 수를 세는 것과 다릅니다. 어떤 주제가 가장 흔하다고 주장하기 전에 분석 단위를 정해야 합니다.

저장소의 코드는 Microsoft의 관리형 서비스가 아닙니다. Microsoft의 저장소 안내는 이 코드를 공식 지원 제품이 아니라 방법론을 시연하는 코드로 설명합니다. 배포, 모니터링, 데이터 갱신을 책임질 주체는 별도로 정해야 합니다.

GraphRAG에 관해 자주 묻는 질문

다음 주에 실행할 일

현재 앱이 제대로 답하지 못하는 주제 질문을 골라, 좋은 답변을 만들려면 문서 집합 전반에서 어떤 근거가 필요한지 파악합니다. 그 실패를 중심으로 작은 GraphRAG 평가를 구성하고 기존 리트리버는 대조군으로 유지합니다.

문서 집합 전체를 종합하는 기능이 제품에서 반복적으로 필요하고 파생 인덱스를 맡을 담당자가 있다면 지금 시작합니다. 보고서를 검증하는 속도보다 문서가 더 빨리 바뀌거나 주제 답변에 빠진 내용이 없는지 판단할 사람이 없다면 기다리는 편이 좋습니다. 주된 작업이 이미 안정적으로 처리되는 사실 검색이라면 현재 설계를 유지합니다. 그래프를 최종적으로 쓰든 쓰지 않든, 근거를 갖고 검색 방식을 결정했다면 의미 있는 결과입니다.

AI 시스템 구축에 관한 실용적인 가이드를 받아 보려면 뉴스레터를 구독하세요.