GraphRAG는 벡터 검색의 대체제가 아니라 “관계까지 찾는 검색”이다

GraphRAG를 설명할 때 “지식 그래프와 RAG의 결합”이라고만 말하면 별로 도움이 안 됩니다. 실무자가 궁금한 건 이겁니다.

기존 RAG로 안 되는 문제가 뭔데, GraphRAG를 쓰면 뭐가 좋아지나?

짧게 말하면 GraphRAG는 문서 조각 하나를 잘 찾는 기술이 아닙니다. 여러 정보가 서로 어떻게 연결되는지 따라가며 답을 찾는 방식입니다.

벡터 RAG가 잘하는 것

일반적인 RAG는 질문과 비슷한 문서 조각을 찾는 데 강합니다.

예를 들어 사용자가 묻습니다.

환불 정책 알려줘.

벡터 검색은 “환불 정책”과 비슷한 문단을 찾아옵니다. 이건 잘합니다. FAQ, 가이드, 정책 문서처럼 질문과 답이 같은 문서 안에 있으면 꽤 잘 맞습니다.

벡터 RAG가 약한 것

문제는 답이 한 문단에 없을 때입니다.

예를 들어 이런 질문입니다.

VIP 고객이 지난달 구매한 상품을 배송 완료 후 10일 뒤 반품하면 전액 환불돼?

이 질문에 답하려면 여러 정보를 같이 봐야 합니다.

• VIP 고객 정책
• 구매일
• 배송 완료일
• 반품 가능 기간
• 상품 카테고리
• 프로모션 적용 여부
• 환불 제외 조건

벡터 검색은 이 중 가장 비슷한 문단 몇 개를 가져옵니다. 그런데 관계를 따라가지는 못합니다. “이 고객이 어떤 주문을 했고, 그 주문의 상품이 어떤 정책에 걸리고, VIP 규칙이 일반 규칙을 덮어쓰는지”를 연결해야 합니다.

이런 질문에서 GraphRAG가 쓸모 있습니다.

GraphRAG의 핵심 아이디어

GraphRAG는 정보를 노드와 엣지로 봅니다.

고객 A --등급--> VIP
고객 A --주문함--> 주문 123
주문 123 --포함--> 상품 X
상품 X --카테고리--> 전자제품
주문 123 --배송상태--> 배송완료
전자제품 --반품규칙--> 개봉 시 반품 불가
VIP --혜택--> 반품 수수료 면제

질문이 들어오면 단순히 비슷한 문단만 찾는 게 아니라, 관련 노드에서 시작해 주변 관계를 따라갑니다. 그래서 답변에 필요한 근거를 더 잘 모을 수 있습니다.

언제 GraphRAG가 필요한가

아래에 해당하면 GraphRAG를 고려할 만합니다.

1. 답이 여러 문서에 흩어져 있다.
2. 사람, 조직, 제품, 정책, 사건 사이의 관계가 중요하다.
3. “A와 B가 어떤 관련이 있나?” 같은 질문이 많다.
4. 단순 요약보다 원인, 영향, 경로, 의존성을 묻는다.
5. 최신 문서 하나보다 누적된 맥락이 중요하다.

예시는 많습니다.

• 법무: 조항, 판례, 계약서, 예외 조건 연결
• 금융: 고객, 계좌, 거래, 리스크 이벤트 연결
• 고객지원: 고객, 주문, 상품, 정책, 상담 이력 연결
• 개발조직: 서비스, API, DB 테이블, 장애, 담당자 연결
• 연구조직: 논문, 저자, 개념, 실험 결과 연결

언제 쓰면 안 되나

GraphRAG가 항상 좋은 건 아닙니다. 오히려 처음부터 쓰면 망하기 쉽습니다.

다음 상황이면 일반 RAG가 낫습니다.

• 문서가 적다.
• 질문 대부분이 FAQ형이다.
• 관계보다 문서 내용 자체가 중요하다.
• 데이터 정리가 안 되어 있다.
• 그래프를 유지보수할 사람이 없다.

GraphRAG는 구축보다 유지보수가 더 어렵습니다. 관계가 틀리면 답변도 자신 있게 틀립니다. “그래프니까 더 정확하겠지”가 아니라 “그래프를 누가 계속 맞게 관리하지?”를 먼저 물어야 합니다.

가장 현실적인 구현 순서

처음부터 Neo4j, RDF, 복잡한 온톨로지로 시작하지 않아도 됩니다. 작은 테이블로도 충분히 실험할 수 있습니다.

1단계: 엔티티를 정합니다

문서에서 중요한 명사를 고릅니다.

고객, 주문, 상품, 정책, 상담, 담당자

2단계: 관계를 정합니다

관계는 동사처럼 적으면 쉽습니다.

고객 -주문함-> 주문
주문 -포함함-> 상품
상품 -적용받음-> 정책
상담 -관련됨-> 주문
담당자 -처리함-> 상담

3단계: 질문 하나를 기준으로 그래프를 만듭니다

전체 회사 그래프를 만들지 마세요. 가장 중요한 질문 하나만 고릅니다.

이 고객에게 어떤 환불 정책을 적용해야 하나?

이 질문에 필요한 노드와 관계만 먼저 만듭니다.

4단계: 벡터 검색과 같이 씁니다

GraphRAG는 벡터 검색을 버리는 방식이 아닙니다. 보통은 같이 씁니다.

1. 질문에서 엔티티를 뽑는다.
2. 그래프에서 관련 노드와 주변 관계를 가져온다.
3. 벡터 검색으로 관련 문서 원문을 찾는다.
4. 둘을 함께 LLM에 넣는다.
5. 답변에는 어떤 관계와 문서를 근거로 썼는지 남긴다.

이 구조가 실무적으로 가장 안전합니다. 그래프는 “어디를 봐야 하는지”를 알려주고, 문서는 “정확한 문장 근거”를 줍니다.

작은 예시 프롬프트

질문: VIP 고객 A의 주문 123은 전액 환불 가능한가?

그래프 근거:
- 고객 A -> 등급 -> VIP
- 고객 A -> 주문함 -> 주문 123
- 주문 123 -> 포함 -> 상품 X
- 상품 X -> 카테고리 -> 전자제품
- 전자제품 -> 규칙 -> 개봉 시 반품 불가
- VIP -> 혜택 -> 반품 수수료 면제

문서 근거:
- 반품 정책 3조: 전자제품은 개봉 후 단순 변심 반품 불가
- VIP 정책 2조: VIP는 반품 수수료 면제, 단 반품 가능 조건은 일반 정책을 따른다

답변 지침:
- 전액 환불 가능 여부를 먼저 말한다
- VIP 혜택과 상품 반품 조건을 구분한다
- 근거 조항을 짧게 제시한다

이렇게 넣으면 LLM이 “VIP니까 전액 환불” 같은 성급한 답을 덜 합니다.

성공 기준

GraphRAG 프로젝트의 성공 기준은 멋진 그래프 시각화가 아닙니다.

아래가 좋아져야 합니다.

• 복합 질문 정답률
• 답변 근거 추적 가능성
• 잘못된 규칙 적용 감소
• 담당자가 답변을 검수하는 시간 감소
• 새로운 정책이 들어왔을 때 수정해야 하는 위치 명확성

지금 할 일

GraphRAG를 도입하고 싶다면 먼저 질문 10개를 모으세요. 그중 벡터 RAG가 자주 틀리는 질문만 고르세요. 그리고 그 질문에 답하기 위해 사람이 실제로 머릿속에서 연결하는 정보를 선으로 그려보세요.

그 선이 많고 중요하다면 GraphRAG가 필요합니다. 선이 별로 없다면 일반 RAG부터 잘 만드는 게 낫습니다.