GraphRAG는 언제 써야 할까?
"GraphRAG 도입했더니 오히려 느려졌어요. 뭐가 문제인가요?"
슬랙 채널에서, 기술 블로그 댓글에서, 개발자 밋업에서 요즘 이런 말을 심심치 않게 듣습니다. GraphRAG라는 단어가 2024년 하반기부터 급격히 유행하면서, 마치 RAG 시스템의 "업그레이드 버전"처럼 소개되는 경우가 많아졌거든요. 그런데 실제로 써보면 기대와 다른 경우가 꽤 많습니다.
오늘은 이 질문에 정면으로 답해보려 합니다. "GraphRAG, 써야 하나요?"
결론부터 말하면: 상황에 따라 다릅니다. 그리고 그 "상황"이 무엇인지를 최근 논문이 꽤 명확하게 정리해줬습니다. EA-GraphRAG (arXiv:2602.03578) 논문을 중심으로, GraphRAG가 진짜 빛나는 순간과 오히려 발목을 잡는 순간을 파헤쳐 보겠습니다.
① 시작은 늘 같은 곳에서 — RAG가 필요했던 이유
잠깐 시간을 되돌려 봅시다.
LLM이 처음 세상에 나왔을 때, 가장 큰 문제 중 하나는 환각(Hallucination) 이었습니다. 모델이 그럴싸하지만 완전히 틀린 답을 자신있게 내놓는 현상이죠. 거기다 학습 데이터에는 시간 제한이 있으니, 최신 정보를 물어보면 당연히 모릅니다.
이걸 해결하기 위해 등장한 게 검색 증강 생성(RAG, Retrieval-Augmented Generation)입니다. 개념은 단순합니다.
모델에게 모든 걸 외우게 하지 말고, 필요할 때 외부 문서에서 찾아오게 하자.
마치 오픈북 시험처럼요. 시험 문제가 나오면 교재를 뒤져서 관련 내용을 찾고, 그걸 바탕으로 답을 쓰는 방식입니다. 이 방법은 실제로 꽤 잘 작동했고, 수많은 기업들이 RAG 기반 챗봇을 구축하기 시작했습니다.
근데 문제가 생겼습니다.
② 전통적인 RAG: 충실하지만 단순한 심부름꾼
전통적인 RAG의 작동 방식을 한 줄로 표현하면 이렇습니다:
질문 → 임베딩 변환 → 벡터 DB 검색 → 유사 문서 k개 반환 → LLM에 넣기 → 답변 생성비유하자면, 이건 굉장히 충실한 심부름꾼 모델입니다. "이 주제랑 비슷한 문서 가져와"라고 시키면 열심히 달려가서 가장 비슷해 보이는 문서들을 들고 옵니다. 빠르고, 구현하기 쉽고, 많은 경우에 잘 작동합니다.
근데 심부름꾼의 한계가 있습니다
케이스 1: 질문 하나에 답이 여러 문서에 흩어져 있을 때
예를 들어 이런 질문을 생각해보세요:
"삼성전자의 2023년 반도체 부문 영업이익이 전년 대비 얼마나 변했고, 그 주된 원인은 무엇인가요?"
이 질문에 답하려면:
1. 2023년 반도체 부문 영업이익 → 문서 A
2. 2022년 반도체 부문 영업이익 → 문서 B
3. 변화 원인 분석 → 문서 C
세 문서의 정보를 연결해야 합니다. 그런데 전통적인 RAG는 질문과 의미적으로 가장 유사한 문서 몇 개를 가져올 뿐, 이 연결 작업을 스스로 하지는 않습니다. 운이 좋으면 세 문서가 다 들어올 수도 있지만, 그건 운이죠.
케이스 2: 간접적인 관계를 추론해야 할 때
"A가 B의 원인이고, B가 C에 영향을 준다면, A는 C와 어떤 관계인가?"
이런 멀티홉(Multi-hop) 추론은 단순한 의미 유사도 검색으로는 잘 잡히지 않습니다. 각 연결고리가 서로 다른 문서에 있고, 그 연결 자체가 명시적으로 적혀 있지 않을 수 있거든요.
케이스 3: 도메인 문서가 비구조적으로 흩어져 있을 때
기업 내부 문서, 의료 기록, 법률 문서 같은 경우는 정보가 굉장히 비구조적으로 퍼져 있습니다. 청크(chunk) 단위로 자르면 맥락이 끊기고, 잘못된 청크를 가져오면 오히려 LLM이 혼란스러워집니다.
이런 한계를 극복하기 위해 등장한 것이 바로 GraphRAG입니다.
③ GraphRAG가 뭔데요? — 관계의 지도를 그리다
GraphRAG의 핵심 아이디어는 간단합니다:
문서를 청크로 자르는 대신, 지식 그래프(Knowledge Graph) 를 만들어서 개체(Entity)와 관계(Relation)를 명시적으로 표현하자.
예를 들어 이런 문서가 있다면:
"일론 머스크는 테슬라의 CEO이다. 테슬라는 전기차를 생산한다. 전기차는 리튬 배터리를 사용한다."
전통적인 RAG는 이 텍스트를 하나의 청크로 저장합니다. 반면 GraphRAG는 이렇게 그래프를 만듭니다:
[일론 머스크] --CEO--> [테슬라]
[테슬라] --생산--> [전기차]
[전기차] --사용--> [리튬 배터리]이제 "일론 머스크가 관련된 배터리는?"이라는 질문이 들어오면, 그래프를 따라가면서 일론 머스크 → 테슬라 → 전기차 → 리튬 배터리 연결을 찾아낼 수 있습니다. 이게 텍스트 유사도 검색만으로는 쉽게 연결되지 않는 정보죠.
Microsoft가 2024년에 공개한 Microsoft GraphRAG가 이 분야를 크게 대중화했습니다. 전체 코퍼스에서 지식 그래프를 구축하고, 커뮤니티 감지 알고리즘(Community Detection)으로 주제 클러스터를 찾아내는 방식을 써서 복잡한 질문에 강력한 성능을 보여줬습니다.
④ 그런데 왜 GraphRAG가 오히려 나빠지는 경우가 생길까?
여기서 오늘 포스트의 핵심으로 들어갑니다.
EA-GraphRAG 논문이 지적하는 문제는 아이러니하게도 이겁니다:
GraphRAG를 모든 쿼리에 적용하면, 오히려 정확도가 떨어지고 지연시간이 늘어난다.
왜 그럴까요?
문제 1: 단순한 질문에 그래프 탐색은 오버킬입니다
"파이썬에서 리스트를 정렬하는 방법은?"
이런 질문에는 그냥 관련 문서 하나 가져와서 보여주면 됩니다. 근데 GraphRAG를 쓰면:
- 쿼리에서 개체를 추출하고 (파이썬, 리스트, 정렬)
- 지식 그래프에서 관련 노드를 찾고
- 그래프 탐색을 수행하고
- 커뮤니티 요약본까지 참조하고
- 그제야 답변을 생성합니다
불필요하게 복잡한 파이프라인을 돌리는 거죠. 결과적으로 응답 시간이 늘어나고, API 비용은 올라가고, 정확도는 오히려 단순 검색보다 못할 수 있습니다.
논문에서도 이를 실험으로 확인했습니다. 단일 홉(Single-hop) QA 벤치마크에서 GraphRAG는 일반 RAG보다 정확도가 낮게 나왔습니다. 반면 멀티홉(Multi-hop) QA에서는 GraphRAG가 확연히 우세했죠.
문제 2: 지식 그래프 구축 자체가 비쌉니다
GraphRAG를 쓰려면 먼저 문서에서 지식 그래프를 만들어야 합니다. 이 과정이 생각보다 무겁습니다:
- 개체명 인식(NER)과 관계 추출(RE) 작업 필요
- LLM을 이용한 그래프 구축 시 API 비용 폭발
- 대규모 문서에서는 구축 시간도 무시 못 함
그래서 작은 문서 수십 개짜리 시스템에 GraphRAG를 무작정 도입했다가 인덱싱 비용만 수백 달러가 나오는 경우도 있습니다.
문제 3: 그래프 품질에 성능이 크게 의존합니다
전통적인 RAG는 임베딩 품질이 좀 떨어져도 어느 정도 동작합니다. 하지만 GraphRAG는 그래프가 잘못 구축되면 그 위에 쌓은 모든 게 흔들립니다. 개체 추출이 틀리거나, 관계가 잘못 연결되면 오답을 더 자신있게 내놓는 결과가 나올 수도 있죠.
⑤ EA-GraphRAG의 해법: "필요할 때만 꺼내라"
EA-GraphRAG 논문이 제안하는 해법은 우아합니다:
모든 쿼리를 GraphRAG로 보내지 말고, 복잡도를 먼저 판단해서 라우팅하자.
이 프레임워크는 세 가지 핵심 컴포넌트로 구성됩니다:
컴포넌트 1: 구문 특성 추출기 (Syntactic Feature Constructor)
쿼리가 들어오면 먼저 그 질문의 구문적 특성을 분석합니다. 예를 들어:
- 질문에 등장하는 개체(Entity)의 수
- 관계를 암시하는 단어의 존재 여부 ("~와의 관계", "~로 인한", "~의 원인")
- 비교나 인과를 나타내는 구조
- 질문의 길이와 복잡도
이런 특성들을 수치화해서 벡터로 만듭니다.
컴포넌트 2: 경량 복잡도 스코어러 (Lightweight Complexity Scorer)
추출된 특성 벡터를 받아서 0~1 사이의 복잡도 점수로 변환합니다. 이 모듈은 의도적으로 가볍게 설계되어 있습니다. 복잡도 판단 자체에 LLM을 쓰면 이미 비용이 발생하니까요.
컴포넌트 3: 점수 기반 라우팅 정책 (Score-Driven Routing Policy)
복잡도 점수에 따라 세 가지 경로 중 하나를 선택합니다:
| 복잡도 점수 | 선택 경로 | 이유 |
|---|---|---|
| 낮음 (Low) | 일반 RAG | 빠르고 저렴하게 처리 |
| 높음 (High) | GraphRAG | 관계 추론이 필요한 쿼리 |
| 경계선 (Borderline) | 복잡도 인식 RRF 융합 | 두 결과를 가중 결합 |
특히 "경계선" 케이스 처리가 흥미롭습니다. 복잡도 인식 역순위 융합(Complexity-Aware Reciprocal Rank Fusion)을 사용해서 RAG와 GraphRAG의 결과를 복잡도 점수에 비례하게 가중 결합합니다. 점수가 높을수록 GraphRAG 결과에 더 높은 가중치가 부여되는 거죠.
전체 흐름을 그림으로 표현하면:
쿼리 입력
│
▼
[구문 특성 추출]
│
▼
[복잡도 점수 계산]
│
├─ 낮음 ──────────────→ [일반 RAG] ──────────┐
│ │
├─ 경계선 ──→ [RAG + GraphRAG 병렬] → [RRF 융합] ─→ [LLM 답변 생성]
│ │
└─ 높음 ──────────────→ [GraphRAG] ───────────┘⑥ 실험 결과가 말하는 것
논문은 4개의 QA 벤치마크에서 실험을 진행했습니다 — 단일홉 2개, 멀티홉 2개.
결과를 단순화하면 이렇습니다:
| 시나리오 | 일반 RAG | GraphRAG | EA-GraphRAG |
|---|---|---|---|
| 단순 단일홉 질문 | ✅ 빠르고 정확 | ❌ 느리고 부정확 | ✅ RAG 경로 선택 |
| 복잡한 멀티홉 질문 | ❌ 관계 놓침 | ✅ 관계 추론 우수 | ✅ GraphRAG 경로 선택 |
| 혼합 시나리오 | △ 중간 | △ 중간 | ✅ 최고 성능 |
EA-GraphRAG는 혼합 시나리오에서 단독 RAG보다도, 단독 GraphRAG보다도 높은 정확도를 보이면서, 동시에 지연시간도 GraphRAG만 쓸 때보다 크게 줄였습니다.
이 결과가 말하는 핵심은 명확합니다:
도구는 용도에 맞게 써야 한다. GraphRAG가 좋은 게 아니라, 복잡한 관계형 질문에 GraphRAG가 좋은 것이다.
⑦ 그래서 실제로 어떤 상황에서 도입을 고려해야 할까?
자, 이제 가장 실용적인 파트입니다. 여러분의 시스템에 GraphRAG를 도입할지 말지 판단하는 기준을 정리해 봤습니다.
🟢 GraphRAG를 진지하게 고려해야 하는 경우
1. 쿼리의 절반 이상이 "관계형"이다
사용자들이 자주 하는 질문이 이런 형태라면 GraphRAG가 유리합니다:
- "A와 B의 관계는?"
- "X가 Y에 미치는 영향은?"
- "이 사건의 원인과 결과는?"
- "C를 통해 D와 연결되는 경로는?"
2. 도메인이 복잡한 관계망을 갖고 있다
- 의료: 약물-질병-부작용 관계
- 법률: 판례-법조항-피고인-판결 관계
- 금융: 기업-자회사-주주-거래 관계
- 학술: 논문-저자-인용-주제 관계
이런 도메인은 관계 자체가 핵심 정보입니다.
3. 멀티홉 추론이 필수적이다
두 단계 이상의 추론이 없으면 답을 못 내는 질문들이 많다면, GraphRAG의 그래프 탐색 능력이 빛을 발합니다.
4. 문서 수가 충분히 많다 (수천 건 이상)
문서가 적으면 지식 그래프 구축 비용 대비 효과가 미미합니다. 어느 정도 규모가 되어야 그래프의 연결성이 의미 있어집니다.
🔴 GraphRAG를 굳이 안 써도 되는 경우
1. 질문이 대부분 단순 사실 조회다
- "이 제품의 가격은?"
- "회사 정책이 어떻게 되나요?"
- "이 API의 파라미터는 뭔가요?"
이런 질문들은 전통적인 RAG가 더 빠르고 정확합니다.
2. 문서 수가 적거나 도메인이 단순하다
FAQ 수십 개, 매뉴얼 몇 개짜리 시스템에 GraphRAG를 도입하면 인덱싱 비용만 쓰고 실익이 없습니다.
3. 응답 속도가 최우선이다
실시간 고객 서비스, 빠른 응답이 생명인 서비스라면 GraphRAG의 추가 지연은 치명적일 수 있습니다.
4. 운영 복잡도를 낮게 유지해야 한다
GraphRAG는 그래프 데이터베이스 관리, 그래프 업데이트 정책, 개체-관계 추출 파이프라인 등 추가로 관리해야 할 컴포넌트가 많습니다. 팀 역량과 운영 여력을 솔직하게 평가해야 합니다.
📊 빠른 자가 진단 체크리스트
아래 항목에서 "예"가 3개 이상이면 GraphRAG 도입을 진지하게 검토해보세요:
- 사용자 질문의 40% 이상이 두 개 이상의 개체 간 관계를 묻는다
- 현재 RAG 시스템의 멀티홉 질문 정확도에 불만족스럽다
- 도메인이 복잡한 관계망을 가지고 있다 (의료, 법률, 금융 등)
- 인덱싱 문서가 수천 건 이상이다
- 지식 그래프 구축/유지 비용을 감당할 수 있다
- 응답 속도보다 답변 품질이 더 중요한 서비스다
⑧ 현실적인 도입 전략: EA-GraphRAG처럼 생각하기
EA-GraphRAG 논문이 주는 가장 실용적인 교훈은 "전부 아니면 전무"로 생각하지 말라는 것입니다.
실제 프로덕션 시스템을 설계한다면, 이런 하이브리드 전략을 추천합니다:
단계 1: 쿼리 로그 분석부터 시작하세요
기존 시스템의 쿼리 로그를 분석해서 질문들을 분류해보세요. 단순 사실 질문이 80%라면 굳이 GraphRAG 전환이 필요 없을 수 있습니다.
단계 2: 복잡도 라우팅 레이어를 먼저 설계하세요
GraphRAG를 전면 도입하기 전에, 어떤 쿼리를 GraphRAG로 보낼지 기준을 먼저 설계하세요. 간단하게는 키워드 기반 룰로도 시작할 수 있습니다:
- "관계", "영향", "원인", "연결", "통해" 같은 단어가 있으면 GraphRAG 경로
- 나머지는 일반 RAG 경로
단계 3: 파일럿 테스트로 효과 검증
전체 시스템에 도입하기 전에, 복잡한 쿼리 샘플 100개를 골라서 GraphRAG와 일반 RAG의 답변 품질을 직접 비교해보세요. 수치가 납득될 때 확장하는 게 맞습니다.
⑨ 아직 해결 안 된 문제들
GraphRAG가 강력한 건 맞지만, 솔직하게 말하면 아직 성숙한 기술은 아닙니다.
그래프 업데이트 문제: 문서가 계속 추가되거나 수정될 때 지식 그래프를 어떻게 효율적으로 업데이트할까요? 전체 재구축은 너무 비싸고, 부분 업데이트는 그래프 일관성이 흔들릴 수 있습니다.
그래프 품질 평가 문제: 만들어진 지식 그래프가 잘 만들어진 건지 어떻게 평가하나요? 아직 표준화된 평가 방법이 없습니다.
환각의 다른 형태: 일반 RAG에서 텍스트 환각이 있다면, GraphRAG에서는 "잘못된 관계 환각"이 있습니다. 존재하지 않는 관계를 그래프에 추가하거나, 있는 관계를 잘못 해석하는 경우죠.
비용 예측 어려움: 일반 RAG는 비용 예측이 비교적 쉽지만, GraphRAG는 그래프 구축 비용, 탐색 비용, LLM 호출 비용이 복잡하게 얽혀서 예산 계획이 어렵습니다.
마무리
GraphRAG는 분명히 강력한 도구입니다. 복잡한 관계를 추론해야 하는 질문 앞에서는 일반 RAG가 범접하기 어려운 성능을 보여줍니다.
하지만 좋은 도구를 모든 상황에 쓰는 것은 좋은 엔지니어링이 아닙니다.
EA-GraphRAG 논문이 실험으로 보여준 것처럼, GraphRAG를 모든 쿼리에 적용하면 오히려 정확도가 떨어지고 비용은 올라갑니다. 핵심은 "이 질문이 관계 추론을 필요로 하는가?" 를 먼저 판단하는 것입니다.
마케팅 키워드에 끌려다니지 말고, 여러분의 실제 쿼리 패턴을 먼저 분석해보세요. 그 다음에 도구를 고르는 게 맞는 순서입니다.
🔑 핵심 한 줄 요약: GraphRAG는 복잡한 관계형 질문의 해결사지, 모든 RAG 시스템의 만능 업그레이드가 아니다.
독자에게 남기는 생각거리: 여러분이 지금 운영 중인 RAG 시스템에서, 사용자들이 가장 자주 불만을 표하는 실패 케이스는 어떤 유형인가요? 그 케이스가 "관계형 질문"이라면 GraphRAG가 답일 수 있고, 그게 아니라면 다른 접근이 필요할 겁니다. 도구보다 문제를 먼저 정의하는 것 — 이게 결국 좋은 시스템 설계의 출발점 아닐까요?
참고 논문: "Use Graph When It Needs: Efficiently and Adaptively Integrating Retrieval-Augmented Generation with Graphs" (arXiv:2602.03578)
