지금까지 벡터 DB 기반 RAG를 배웠습니다. 그런데 RAG를 깊게 공부하다 보면 거의 항상 함께 등장하는 키워드가 있습니다. 바로 GraphRAG(그래프 RAG)입니다. 팔란티어의 '온톨로지'가 주목받고, 지식 그래프 시장이 2024년 11억 달러에서 2030년 69억 달러로 성장할 것으로 전망되면서 실무에서도 빠르게 번지고 있는 기술입니다. 이 레슨에서는 GraphRAG가 왜 필요해졌고, 벡터 RAG와 무엇이 다른지부터 또렷하게 정리합니다.
먼저 복습 — 벡터 RAG는 어떻게 작동했나
벡터 RAG는 '문서를 잘게 쪼개 숫자(벡터)로 바꿔 저장해두고, 질문과 가장 비슷한 조각을 꺼내 LLM에 함께 넣어주는' 방식이었습니다. 구축과 질의를 한 줄로 그리면 이렇습니다.
벡터 RAG 파이프라인 — 구축과 질의
- 문서 로드 (Load) 원본 데이터를 불러온다
- 청킹 (Split) 긴 문서를 작은 조각(청크)으로 자른다
- 임베딩 (Embed) 각 청크를 의미 벡터(숫자)로 변환
- 벡터 저장 (Store) 벡터 DB에 적재
- 질문 임베딩 사용자 질문도 같은 방식으로 벡터화
- 유사도 검색 (Top-K) 가장 가까운 청크 K개를 꺼낸다
- 증강 + 생성 질문 + 검색된 청크를 LLM에 함께 전달해 답변
강력하지만, 이 구조에는 두 가지 구조적 한계가 숨어 있습니다 — 청킹과 Top-K.
한계 1 — 청킹이 문맥을 끊는다
문서를 조각내는 과정에서 '이어져야 할 문맥'이 서로 다른 청크로 흩어질 수 있습니다. 은행 수수료 규정이 세 청크로 나뉜 상황을 봅시다.
- 청크 ① — VIP 고객은 수수료 면제 대상이다.
- 청크 ② — 단, 해외송금 수수료는 면제 대상이 아니다.
- 청크 ③ — 2025년 3월 이후 가입자가 이 정책의 적용 대상이다.
"2025년 4월 가입한 VIP의 해외송금 수수료는 면제되나요?"
벡터 RAG가 검색한 것 — 청크 ①만
- 질문과 가장 유사한 청크 ① 하나만 검색됨
- "VIP는 수수료 면제" → LLM은 "면제됩니다"라고 답변
- 정답에 꼭 필요한 청크 ②(해외송금 예외)를 놓침
잘못된 답변
실제 정답에 필요한 문맥 — ①+②를 함께
- VIP는 면제가 맞지만, 해외송금은 예외
- 따라서 VIP·4월 가입이어도 해외송금 수수료는 면제 아님
- 여러 조각의 조건을 '연결'해야 정답이 나온다
올바른 답변
청크 크기와 경계에 따라, 정답을 뒤집는 예외 조항이 다른 조각으로 밀려나 검색에서 누락될 수 있습니다.
한계 2 — Top-K가 연결고리를 놓친다
Top-K는 '가장 유사한 K개'만 가져옵니다. 그런데 정답에 필요한 문장이 항상 상위 K개 안에 든다는 보장은 없습니다. 세 문장으로 된 예시를 봅시다.
- 문서 ① — 김민수는 결제 시스템 리팩터링을 담당했다.
- 문서 ② — 이 결제 시스템 리팩터링은 장애율을 낮추기 위한 프로젝트였다.
- 문서 ③ — 이 장애율 개선 프로젝트는 보안 팀과 플랫폼 팀이 공동으로 진행했다.
"김민수와 보안 팀은 어떤 관계야?" (K=2)
벡터 RAG — 문서 ①·③만 검색
- 질문 단어와 가장 겹치는 ①(김민수)·③(보안 팀)이 검색됨
- 둘을 잇는 다리 문서 ②가 K 밖으로 밀려 누락
- LLM은 김민수와 보안 팀의 연결을 설명하지 못함
관계 단절
그래프 탐색 — ①→②→③ 경로를 따라감
- 김민수 →담당→ 결제 시스템 리팩터링
- 결제 시스템 리팩터링 →포함→ 장애율 개선 프로젝트
- 장애율 개선 프로젝트 →공동진행→ 보안 팀
관계로 연결됨
여러 홉(hop)을 건너야 답이 나오는 '관계형 질문'에서, 유사도 상위 K개 방식은 중간 연결고리를 놓치기 쉽습니다.
그래서 등장한 RAG 디자인 패턴들
이런 한계를 보완하려 여러 RAG 설계가 등장했습니다. GraphRAG는 그중 '관계'에 특화된 패턴입니다.
| 패턴 | 핵심 아이디어 | 잘 맞는 상황 |
|---|---|---|
| Naive RAG | 검색 후 그대로 LLM에 증강 | 단순 사실 조회 |
| Rerank RAG | 많이 검색한 뒤 재정렬로 정확도↑ | 검색 노이즈가 많을 때 |
| Hybrid RAG | 의미 검색 + 키워드(BM25) 검색 결합 | 고유명사·코드·숫자 검색 |
| Agentic RAG | 에이전트가 스스로 검색 전략을 결정 | 다단계·복합 질문 |
| GraphRAG | 지식 그래프에서 관계를 따라 검색 | 엔티티 간 관계·다중 홉 질문 |
GraphRAG — 관계로 검색한다
GraphRAG는 문서를 '지식 그래프(Knowledge Graph)'라는 개념 지도로 바꿔둡니다. 그리고 질문이 들어오면, 유사한 조각을 꺼내는 대신 지도 위 노드 사이의 관계(엣지)를 따라 여정을 떠나 답을 찾습니다.
GraphRAG 작동 방식
- 문서 → 지식 그래프 구축 엔티티(노드)와 관계(엣지)를 추출해 그래프로
- 질문 입력 예: "김민수와 보안 팀은 어떤 관계야?"
- 그래프 탐색 노드에서 출발해 관계를 따라 경로를 추적
- 관계 컨텍스트 확보 김민수→결제시스템→장애율개선→보안팀 경로를 수집
- 증강 + 생성 이 관계 정보를 LLM에 넣어 최종 답변 생성
"김민수는 결제 시스템 리팩터링을 담당했고, 그 프로젝트에서 보안 팀과 협업한 관계입니다" — 관계를 따라가야 나오는 답을 만들어냅니다.
사실은 이미 쓰고 있다 — 구글 지식 그래프
구글에서 '에펠탑'이나 '크리스토퍼 놀란'을 검색하면 오른쪽에 뜨는 정보 패널(높이·완공연도·건축가, 또는 국적·형제자매·수상작). 이것이 2012년부터 구글이 운영해온 지식 그래프입니다. '에펠탑'이라는 노드와 관계 맺은 이웃 노드들을 즉시 펼쳐 보여주는 것이죠. 방대한 데이터를 그래프로 구축해두면, 규모가 커져도 관계 탐색으로 빠르게 답을 찾을 수 있습니다.
벡터 RAG vs GraphRAG — 언제 무엇을
벡터 RAG
- 검색 단위: 의미가 비슷한 텍스트 조각
- 강점: 개념·주제 유사 검색, 구축이 간단
- 약점: 여러 조각을 잇는 관계형 질문에 취약
- 데이터가 커지면 검색 지연·품질 저하 우려
'비슷한 내용' 찾기
GraphRAG
- 검색 단위: 노드와 노드를 잇는 관계(엣지)
- 강점: 다중 홉 관계 질문, 규모 확장 시에도 빠른 탐색
- 약점: 그래프 구축 비용·설계 노력이 든다
- 관계가 이미 형성돼 있어 지연이 크게 늘지 않음
'어떻게 연결됐나' 찾기
미래에셋증권의 AWS Summit 2024 사례에서도, 데이터 규모가 커질수록 GraphRAG의 검색 지연이 벡터 RAG보다 완만하게 증가한다고 발표했습니다.
둘은 배타적이지 않습니다. 실무에서는 GraphRAG로 관계형 질문을, 벡터 RAG로 개념 유사 질문을 처리하도록 '상호 보완'하는 하이브리드 구성이 흔합니다. GraphRAG를 배웠다고 벡터 RAG를 버릴 필요는 없습니다.
GraphRAG가 항상 정답은 아닙니다. 지식 그래프를 만드는 비용(엔티티·관계 추출, 스키마 설계)이 들고, 단순한 의미 검색에는 오히려 벡터 RAG가 빠르고 저렴합니다. '관계를 따라가야 답이 나오는 질문이 많은가?'가 도입 판단의 기준입니다.
개념을 잡았으니, 다음 레슨에서 지식 그래프의 3요소(노드·엣지·속성)를 뜯어보고 Neo4j와 랭체인으로 실제 그래프를 만들어 질문까지 던져보겠습니다.