[RAG] Vector RAG vs Graph RAG 비교 (1)

1. Vector RAG vs Graph RAG 개요

LLM 기반의 RAG(Retrieval-Augmented Generation) 시스템을 구현하면서, 보통 Vector Store 기반의 RAG로 시작하게 됩니다. 저도 마찬가지고요. 문서를 임베딩하고, FAISS나 Chroma 같은 벡터 데이터베이스를 이용해 관련 정보를 빠르게 찾아주는 방식으로 간단하고 효과적입니다.
 
하지만 프로젝트가 복잡해지고 문서 간 관계성이나 구조적 연결성이 중요해질수록, 단순한 벡터 유사도 기반의 검색이 한계를 드러내기 시작했습니다. 예를 들어, "A와 관련된 B, 그리고 그로 인해 파생된 C"처럼 지식 간의 연결 고리를 파악해야 하는 경우, 벡터 기반 검색은 그 관계를 자연스럽게 드러내지 못했습니다.
 
간단한 챗봇 시스템을 구축할 때, 대부분은 Vector DB 기반의 RAG를 사용합니다. 상담 지식 문서를 임베딩하고, 고객의 질문에 유사한 문서를 찾아 답변을 생성하는 방식이죠. 이 방식은 단일 질문-답변 형태의 간단한 상담에는 꽤 효과적입니다.
 
하지만 상담 흐름이 복잡해지고, 고객 상황에 따라 분기되는 질의가 이어지는 경우에는 벡터 기반 검색의 한계가 드러납니다.
예를 들어, 고객이 아래처럼 말한 경우를 가정해보겠습니다.

“저는 기존에 자동차 보험에 가입돼 있었고, 지난달 사고가 났는데, 아직 보상금이 안 들어왔어요. 혹시 처리 상태를 확인할 수 있을까요?”

 
이 질문에는 다음과 같은 복합적인 정보가 숨어 있습니다:

1. "기존 보험" → 고객의 가입 이력 정보
2. "사고" → 사고 접수 여부, 일자
3. "보상금 상태" → 지급 프로세스 단계, 심사 여부 등

Vector 검색은 이처럼 여러 개념이 연결된 문맥을 단순히 "유사도"로만 매칭합니다.
결국 문서 조각 하나(여러개 일 수 있음)만 찾아와서 LLM에 넘기기 때문에, 흐름을 파악하지 못하거나 엉뚱한 답변을 하게 될 수 있습니다.
 
이런 배경에서 자연스럽게 Graph RAG 방식에 흥미가 생겼고, 그 가능성을 직접 실험해보고 싶다는 생각이 들었습니다.
Graph RAG는 앞선 고객 질문은 다음처럼 그래프 탐색으로 자연스럽게 해석할 수 있습니다.

"고객 A → 보험 상품 B → 사고 C → 보상 상태 D"
처럼 엔터티와 관계를 명시적으로 표현합니다.

• 고객의 보험 가입 이력을 확인하고
• 사고 접수 이력을 따라가며
• 현재 보상금 처리 상태를 조회
• 그 정보를 기반으로 답변 생성

이처럼 Graph RAG는 "노드를 타고" 상황을 따라가는 질의에 훨씬 강하며,
복잡한 업무 프로세스를 따라야 하는 콜센터 문의에 있어선 사람 상담원과 유사한 대응이 가능해집니다.
 

---

 
Graph RAG가 모든 상황에서 정답은 아닙니다. "문서를 얼마나 잘 알고 있느냐"보다는, "상황을 얼마나 잘 이해하느냐"가 중요한 상담 영역에서는 분명 고려해볼 만한 가치가 있습니다. 다만 그만큼 속도나 구현 복잡도 측면에서 부담이 있을 수 있으므로, 도메인과 목적에 따라 적절한 방식을 선택하는 것이 중요합니다.
 
저 역시 실제 프로젝트에서 Vector 기반 RAG로 간단한 챗봇부터 AI Agent까지 구현해보았고, Graph RAG 방식을 활용하거나, 두 방식을 혼합한 하이브리드 형태로도 적용해보며 해결하고자 하는 과제의 특성에 맞춰 가장 적절한 방법을 선택해 개발하고 있습니다.
 
그럼 지금까지 Vector based RAG vs Graph RAG의 개요 글이였고...ㅋㅋㅋ 다음 글부터는 본격적으로 Vector 기반 RAG와 Graph 기반 RAG의 비교, 그리고 Graph와 벡터 검색이 결합된 LightRAG, 최근 공개된 NodeRAG 논문에 대해서도 함께 소개드리겠습니다.