GraphRAG 알아보기: 지식 그래프가 벡터 검색보다 뛰어난 경우

GraphRAG는 개체와 관계로 구성된 지식 그래프를 활용해 LLM에 필요한 맥락을 찾는 검색 증강 생성 방식이에요. 답변이 서로 연결된 사실이나 자료 모음 전반의 패턴에 달려 있을 때 테스트해 볼 만해요. 단지 적절한 문단을 찾으면 되는 경우까지 무조건 테스트할 필요는 없어요. 벡터 RAG는 여전히 합리적인 출발점이며, 두 방식을 결합한 설계를 검토해 보는 것이 더 유용한 경우가 많아요.

핵심 요약: 유사도는 구절을 찾고, 그래프는 사실을 연결해요

벡터 검색은 이렇게 질문해요. 이 질문과 의미가 비슷한 구절은 무엇일까요? 그래프 검색은 여기에 또 다른 질문을 더해요. 이 질문에서 다루는 것들과 연결된 것은 무엇일까요?

프로젝트 워크스페이스를 떠올려 보세요. “서비스는 어떻게 배포하나요?”라는 질문은 운영 절차서 하나로 답할 수 있을지도 몰라요. “어떤 출시가 이 장애를 처리하는 팀이 담당하는 서비스에 의존하나요?”라는 질문에 답하려면 장애, 팀, 서비스, 출시 사이의 연결을 따라가야 해요.

이것이 그래프 RAG와 벡터 RAG의 실질적인 차이예요. “똑똑한 검색과 멍청한 검색”의 차이가 아니에요. 필요한 근거를 모으는 데 어떤 구조가 도움이 되는지를 선택하는 문제예요.

한 문단으로 이해하는 RAG와 벡터 검색의 한계

검색 증강 생성은 모델이 답변하기 전에 관련 정보를 검색해 LLM에 맥락으로 제공해요. 기존 벡터 RAG는 문서를 청크로 나누고, 각 청크를 수치 벡터로 임베딩한 뒤, 질문과의 벡터 유사도를 기준으로 검색해요. 그러면 답변 모델이 선택된 텍스트를 바탕으로 답변해요. Meilisearch의 비교 글에서는 두 방식의 근본적인 차이를 설명해요. 하나는 유사도 기반 검색이고, 다른 하나는 서로 연결된 엔터티를 통한 검색이에요.

“우리 환불 정책에는 취소에 관해 어떤 내용이 있나요?” 같은 질문에는 관련 정책 내용을 찾는 것만으로 충분할 수 있어요. 이 워크플로를 테스트하기 위해 모든 고객, 정책, 제품을 노드로 모델링할 필요는 없어요.

필요한 맥락이 여러 곳에 흩어져 있으면 이러한 한계는 더욱 흥미로운 양상을 보여요:

• 여러 관계를 따라가야 하는 질문: 답을 찾으려면 일치하는 구절 하나를 찾는 것이 아니라 여러 관계를 따라가야 해요.
• 전체를 아우르는 질문: “우리 프로젝트 회고 전반에서 반복되는 주제는 무엇인가요?”는 가장 유사한 내용만이 아니라 자료 전체에 대한 질문이에요.
• 흩어진 사실: 답을 구성하는 정보가 서로 다른 페이지에 나뉘어 있고, 일부 정보는 원래 질문과 유사하지 않을 수도 있어요.

이 사건 사례에서는 출시 페이지에 해당 사건이 전혀 언급되지 않을 수도 있어요. 질문과 표현이 비슷한 구절을 검색하는 것은 문서에 기록된 의존 관계를 따라 해당 출시까지 추적하는 것과는 다른 작업이에요.

그렇다고 벡터 검색으로 답을 찾을 수 없다는 뜻은 아니에요. 첫 번째 결과가 관련 있어 보이는지만으로 판단하지 말고, 필요한 정보를 모두 검색해 내는지 확인해야 한다는 뜻이에요.

단계별로 살펴보는 Microsoft GraphRAG의 작동 방식

Microsoft GraphRAG는 오픈 소스 그래프 기반 RAG 시스템이에요. 추출, 커뮤니티 구성, 요약으로 이어지는 파이프라인은 이 접근 방식을 이해하는 데 유용한 참고 자료가 돼요. 작업을 자료 모음을 준비하는 단계와 이를 바탕으로 질문에 답하는 단계로 나누세요.

인덱싱: 텍스트를 서로 연결된 맥락으로 바꿔요

1. 엔터티 추출. LLM이 원본 자료에서 다루는 대상을 식별해요. 가상의 엔지니어링 자료 모음이라면 서비스, 팀, 프로젝트, 인시던트 등이 여기에 포함될 수 있어요.
2. 관계 추출. LLM이 엔터티 간의 연결을 식별해요. 예를 들어, 문서에 특정 팀이 어떤 서비스를 책임지고 있다고 나와 있을 수 있어요.
3. 그래프 구축. 엔터티는 노드가 되고 관계는 링크가 되어, 검색에 활용할 수 있도록 자료를 서로 연결된 형태로 표현해요.
4. 엔터티를 커뮤니티로 묶기. 시스템은 각 엔터티를 따로 다루는 대신, 그래프에서 서로 연결된 엔터티들을 그룹으로 묶어요.
5. 커뮤니티 요약 작성. 생성된 요약은 이후 검색과 답변에 활용할 수 있도록 각 그룹의 개요를 제공해요.

중요한 변화는 시스템이 검색 가능한 텍스트 구절만 준비하는 데 그치지 않는다는 점이에요. 각 구절이 무엇을 다루는지, 그 대상들이 어떻게 연결되는지, 서로 연결된 그룹에 무엇이 포함되는지를 나타내는 구조도 함께 준비해요.

질의: 국소적 질문과 전역적 질문

로컬 검색은 엔터티 중심이에요. “청구 서비스에는 무엇이 연결되어 있을까?” 같은 질문을 떠올려 보세요. 관련 맥락은 특정 엔터티와 그 관계를 중심으로 구성돼요.

글로벌 검색은 전체 데이터셋을 대상으로 해요. 예를 들어 “이 프로젝트들 전반에서 반복적으로 나타나는 조율 문제는 무엇일까?” 같은 질문이에요. 질문과 유사한 구절에만 의존하는 것이 아니라, 커뮤니티 요약을 통해 더 폭넓은 종합 분석에 활용할 자료를 얻을 수 있어요.

Microsoft의 GraphRAG 문서에서는 인덱싱, 쿼리 방식, 프롬프트 튜닝을 구분해요. 초기 평가에서 도움이 되는 구분은 간단해요. 특정 대상을 조사하려는 건가요, 아니면 자료 전체를 아우르는 관점을 얻으려는 건가요?

“로컬”을 “내 노트북에서 실행된다”는 뜻으로 혼동하지 마세요. 여기서는 검색 범위를 가리켜요. 또 모든 그래프 쿼리에 커뮤니티 요약이 필요하다고 생각하지 마세요. 명시적인 페이지 관계를 따라가는 것은 범위가 더 좁은 그래프 검색 워크플로예요.

그래프 RAG와 벡터 RAG: 실용적인 비교

아래 그래프 열에는 Microsoft의 추출·요약 방식이 포함되어 있어요. 기존 링크를 활용하는 워크플로는 해당 링크를 추출하는 과정을 건너뛸 수 있으므로 설정 과정이 같지는 않아요.

제가 출발점으로 삼는 원칙: 근거가 하나의 텍스트 구간에 담겨 있다면 텍스트 구간 검색부터 테스트해요. 근거가 연쇄적으로 연결되어 있다면 그 연결 전체를 검색하는 방식을 테스트해요. 질문이 컬렉션에 관한 것이라면 컬렉션 단위의 접근 방식을 테스트해요.

각각 언제 쓰고, 언제 함께 쓰면 좋을까요?

문단 형식의 답변을 얻으려면 벡터 RAG로 시작하세요

정책, 지침, 설명은 기대하는 답변이 특정 텍스트에 담겨 있을 때 유용한 초기 활용 사례입니다. 같은 자료 모음을 다른 방식으로 표현하기 전에 기준선을 먼저 설정하세요.

실패 원인이 검색에 있었는지, 답변 생성에 있었는지 살펴보세요. 올바른 근거가 이미 있었다면, 그래프를 추가해도 실제 문제는 해결되지 않을 수 있어요.

관계 구조를 담은 답변을 위한 그래프 검색을 테스트하세요

어떤 프로젝트가 특정 서비스에 의존하는지, 어떤 결정이 특정 요구사항과 연결되는지, 어떤 연구 노트가 특정 주장을 뒷받침하는지처럼 연결 관계에 실제로 의존하는 질문을 사용하세요. 이는 평가 사례로 제안된 것이며, 정확도 향상을 약속하는 것은 아닙니다.

데이터에 해당 관계가 포함되어 있는지 확인해 보세요. 원본 구조나 추출 과정에서 유용한 연결을 제공하지 않으면 그래프도 그 연결을 따라갈 수 없어요.

모두 바꾸기 전에 하이브리드 워크플로를 시도해 보세요

테스트해 볼 만한 실용적인 설계는 의미 기반 진입점과 그래프 확장을 결합하는 방식이에요:

1. 질문과 관련된 텍스트나 노드를 검색해요.
2. 그 시작점에서 선택한 관계를 따라가요.
3. 연결된 항목의 원본 콘텐츠를 가져와요.
4. 답변을 생성하는 모델에 근거와 해당 출처 정보를 제공해요.

사고 사례에서는 검색으로 사고 보고서를 찾을 수 있어요. 그런 다음 그래프 탐색으로 영향을 받은 서비스와 해당 서비스에 의존하는 출시로 이어지는 링크를 따라갈 수 있어요. 이 페이지들을 읽으면 답변의 실제 근거를 확보할 수 있어요.

테스트하기 전에 범위를 정하세요. 어떤 관계 유형이 유용한지, 어디까지 탐색할지, 얼마나 많은 콘텐츠를 반환할지 정해야 해요. “연결된 모든 항목 포함”은 검색 전략이 아니라 선택을 회피하는 방식이에요.

GraphRAG의 실제 비용

문서 집합, 모델 선택, 설정 없이는 보편적으로 적용할 수 있는 가격이나 고정된 비용 배율을 타당하게 제시할 수 없어요. 예산을 세울 때 도움이 되는 질문은 다음과 같아요. 이 파이프라인으로 어떤 작업이 추가되나요?

Microsoft의 추출·요약 방식에서는 개체와 관계를 추출하고 커뮤니티 요약을 생성하는 모델 작업도 포함해야 해요. 이는 기본적인 청크 분할·임베딩 파이프라인에 더해 필요한 준비 단계예요. “오픈 소스”라는 사실을 이 작업의 실행 비용을 충당할 예산으로 간주해서는 안 돼요.

파일럿 운영 시 비용은 따로 기록하세요:

• 초기 준비: 설계상 임베딩, 추출, 요약 생성을 사용하는 모든 부분에서 해당 작업을 수행해요.
• 질문: 검색 작업, LLM에 제공하는 맥락, 답변 생성이 포함돼요.
• 업데이트: 유지 관리하는 데이터 표현에 수정된 원본 자료를 반영하는 데 필요한 작업이에요.
• 운영: 저장, 디버깅, 잘못되거나 누락된 관계 검토가 포함돼요.

업데이트도 별도로 테스트해야 해요. 원본 문장을 수정하고, 선택한 업데이트 워크플로를 다시 실행한 뒤 생성된 답변을 살펴보세요. 원본 콘텐츠와 그래프에 표현된 내용, 그리고 이전 문장을 바탕으로 작성된 모든 요약을 확인하세요. 처음 한 번 인덱싱에 성공했다고 해서 자료 모음이 계속 최신 상태로 유지된다고 생각하지 마세요.

연결이 이미 명시적인 링크로 존재한다면, 해당 연결을 LLM으로 추출하지 않아도 돼요. 그렇다고 콘텐츠 검색, 답변 생성, 유지 관리까지 필요 없어지는 건 아니에요. 특정 단계만 생략하는 것이지, 그래프 기반 RAG와 관련된 모든 비용이 사라지는 건 아니에요.

노트에는 이미 그래프 구조가 담겨 있어요

서로 연결된 워크스페이스는 서로 연결되지 않은 문서들이 담긴 폴더와는 다른 출발점을 제공해요. 노션에는 데이터베이스 관계, 페이지 멘션과 백링크, 상위·하위 페이지를 통해 명시적인 연결이 이미 존재해요. Obsidian 보관함에는 위키링크가 있어요. 이런 링크는 LLM에 연결을 찾아 달라고 요청하지 않아도 그래프의 연결선이 될 수 있어요.

가상의 프로젝트 데이터베이스가 서비스 데이터베이스와 연결되어 있고, 장애 기록에는 서비스 페이지가 언급되어 있다고 가정해 볼게요. 이미 장애 기록에서 서비스로, 다시 관련 프로젝트로 이어지는 경로가 있는 셈이에요. 노션 데이터베이스 관계 가이드에서는 명시적인 연결을 다루고, 더 폭넓은 노션 지식 그래프 가이드에서는 이러한 연결을 전체 맥락 속에서 살펴봐요.

한 가지 솔직히 짚고 넘어갈 점이 있어요. 페이지 그래프가 곧 엔티티 지식 그래프인 것은 아니에요. 한 페이지에서 여러 엔티티를 다룰 수 있어요. 멘션은 한 페이지가 다른 페이지를 참조한다는 뜻이지, 반드시 한 서비스가 다른 서비스에 의존한다는 뜻은 아니에요. 부모-자식 링크는 계층 구조를 나타내며, 소유 관계나 인과 관계를 뜻하지는 않아요.

정보를 검색할 때도 이 구분을 유지하세요. 멘션을 따라가며 유용할 만한 근거를 찾되, 그 관계의 의미를 단정하기 전에 해당 페이지를 읽어 보세요.

이는 LLM 위키로 자연스럽게 이어져요. 원본 페이지, 페이지 사이의 링크, 생성된 해석을 각각 구분해서 생각해 보세요. 이 세 층위를 구분해 두면 생성된 모든 연결을 이미 확인된 사실로 받아들이는 대신, 답변을 더 쉽게 검토할 수 있어요.

에이전트가 구조와 콘텐츠에 접근할 수 있도록 하세요

IVGraph는 노션 페이지, 백링크와 멘션, 데이터베이스 관계를 바탕으로 그래프를 만들어요. 읽기 전용 V1 LLM API는 에이전트에게 검색, 노드 상세 정보, 페이지 콘텐츠, 그래프 탐색 기능을 제공해요. 이 그래프와 API만으로도 이미 관리하고 있는 워크스페이스를 기반으로 그래프 정보를 활용하는 정보 검색 워크플로를 구축할 수 있어요.

테스트해 볼 에이전트 워크플로는 간단해요. 프로젝트를 검색하고, 해당 노드를 살펴보고, 관련 링크를 따라가며, 연결된 페이지의 내용을 가져온 뒤, 그 근거를 바탕으로 답변하면 돼요. 더 폭넓은 개인 워크플로를 알아보려면 LLM, 노션, Claude Code로 세컨드 브레인 구축하기를 참고하세요.

이미 명시적으로 관리하고 있는 관계를 추출하는 것부터 시작하지 마세요. 먼저 해당 관계를 드러내면 맥락이 부족한 문제가 해결되는지 확인해 보세요.

작게 시작하는 방법

데이터베이스 마이그레이션이 아니라 질문부터 시작하세요. 이 체크리스트를 활용해 실제로 정보를 찾지 못한 사례에 초점을 맞춰 실험하세요:

1. 범위가 명확한 자료 모음을 하나 선택하세요. 내용과 관계를 직접 검토할 수 있는 프로젝트 영역을 고르세요.
2. 실제로 필요한 질문을 작성하세요. 업무에 중요하다면 직접 조회하는 질문, 연결된 사실을 묻는 질문, 자료 모음 전체에 대한 질문을 포함하세요.
3. 필요한 근거를 파악하세요. 올바른 답변에 반드시 활용해야 할 구절과 관계를 기록하세요.
4. 벡터 검색으로 기준 성능을 측정하세요. 생성된 답변과 검색으로 가져온 맥락을 함께 저장하세요. 아키텍처를 변경하기 전에 누락된 근거를 파악하세요.
5. 기존 연결을 목록으로 정리하세요. 유용한 관계를 부수적인 언급이나 계층 구조 링크와 구분하세요.
6. 빠진 기능만 추가하세요. 연결된 사실을 찾기 위한 탐색을 테스트하거나, Microsoft의 추출·요약 파이프라인을 해당 파이프라인이 처리하도록 설계된 질문으로 테스트하세요.
7. 비교하고 업데이트하세요. 필요한 근거를 얼마나 확보했는지, 근거 없는 주장, 비용, 응답 시간을 검토하세요. 그런 다음 원본 자료를 수정하고 최신 내용이 반영되는지 확인하세요.

그래프 계층이 기본 방식에서 놓치는 필요한 맥락을 감당할 수 있는 비용으로 찾아낸다면 유지하세요. 두 방식이 똑같이 좋은 답변을 제공한다면 더 쉽게 유지 관리할 수 있는 쪽을 선택하세요.

자주 묻는 질문