지식그래프 구축과 AI의 반복 검색, 정확도와 비용을 가르는 조건.
| 지표 | 연구 결과 | 출처 |
|---|---|---|
| 일반 질의응답에서 그래프 기반 검색의 평균 이득 | +0.47점 | [1] |
| 다단계 질의응답에서 평균 이득 | +27.23점 | [1] |
| GraphRAG 지식 구축 비용 | $13.19 / 100만 토큰 | [1] |
| 같은 구축 작업의 소요 시간 | 1.72시간 / 100만 토큰 | [1] |
| 경량 LinearRAG 구축 시간 | 0.68시간 / 100만 토큰 | [1] |
| 구문 분석 기반 그래프의 상대 성능 | 약 94% | [3] |
위 수치는 각 연구의 데이터셋·모델·구현·평가 조건에서 측정됐다. 다른 기업 환경의 성능이나 비용을 그대로 예측하는 수치가 아니다.
1. 문서를 찾는 것과 관계를 이해하는 것은 다르다
기업의 AI에게 질문을 하나 던져 보자.
"해외 법인 A의 공급계약이 변경되면, 어떤 고객과 어떤 생산시설이 영향을 받는가?"
답은 문서 하나에 들어 있지 않다.
계약서에는 공급업체가 있다. 구매 시스템에는 부품이 있다. 생산관리 시스템에는 그 부품을 쓰는 공장이 있다. 영업 시스템에는 영향을 받는 고객이 있다.
AI는 이 정보들을 연결해야 한다.
일반적인 RAG는 질문과 의미가 비슷한 문서를 찾는다. 그것을 언어 모델에 전달한다. 반면 지식그래프는 기업·계약·부품·공장·고객을 개체로 둔다. 그 사이의 관계를 연결선으로 표현한다.
그래프 구조를 검색과 답변 생성에 쓰는 접근을 GraphRAG라고 부른다.
중요한 차이는 저장 방식만이 아니다. 검색할 때 이미 관계가 표현돼 있는가. 아니면 검색한 근거를 바탕으로 관계를 새로 연결해야 하는가.
2. 그래프는 모든 질문에서 이기지 않는다
2026년 4월 뉴욕대 상하이 연구진이 비교 연구를 냈다. 이 차이를 수치로 보여준다[1].
연구진은 의미 검색 기반 RAG와 여러 그래프 방식을 같은 잣대로 비교했다.
일반 질의응답에서 그래프 방식의 평균 이득은 0.47점이었다. 차이가 작았다.
하지만 여러 근거를 단계적으로 연결해야 하는 질문은 달랐다. 평균 27.23점의 이득을 기록했다.
왜 차이가 생겼을까.
"어느 회사의 본사가 어디에 있는가"처럼 묻는 질문이 있다. 하나의 근거로 답이 된다. 복잡한 관계 구조가 필요하지 않다.
반면 "A를 인수한 기업이 보유한 자회사의 주요 사업은 무엇인가"는 다르다. 여러 관계를 거쳐야 답이 나온다. 관계를 미리 표현해 둔 쪽이 유리하다.
다만 27.23점은 연구에서 비교한 평가 점수의 차이다. 그래프가 모든 다단계 질문의 정확도를 27.23% 높인다는 뜻이 아니다.
모든 그래프 구현이 같은 성능을 보인 것도 아니다.
결론은 그래프가 항상 우수하다는 것이 아니다. 질문이 관계를 요구할수록 그래프 구조의 값이 커진다는 것이다.
3. 그런데 AI가 검색을 반복하면 어떻게 될까
최근 AI 에이전트는 한 번 검색하고 바로 답하지 않는다. 질문을 여러 부분으로 나눈다. 첫 검색 결과를 바탕으로 다음 질문을 만든다.
앞의 공급계약 사례를 생각해 보자.
AI는 먼저 계약서를 찾는다. 계약서에서 공급업체와 부품명을 확인한다. 그다음 그 부품을 쓰는 생산시설을 찾는다. 마지막으로 영향을 받는 고객과 납기 정보를 조회한다.
관계를 미리 저장하지 않았어도 된다. 검색과 추론을 반복하면서 답에 필요한 연결을 만들어 간다.
이를 에이전트 기반 반복 검색이라고 부른다. Agentic Search라고도 한다.
뉴욕대 상하이 연구에서 이런 반복 검색이 의미 검색 RAG의 성능을 끌어올렸다. GraphRAG와의 격차도 일부 줄였다[1].
그러나 격차가 사라진 것은 아니다. 복잡한 다단계 추론에서는 그래프 기반 방식이 여전히 강점을 보였다.
그러니 에이전트가 지식그래프를 대체했다고 말하기는 어렵다.
더 정확한 설명은 이렇다. 그래프는 관계를 미리 명시해 저장한다. 에이전트는 질문을 처리하는 동안 필요한 관계를 그때그때 찾아 연결한다.
두 방식은 경쟁할 수도 있고 함께 쓸 수도 있다.
4. 미리 만드는 데는 비용이 든다
지식그래프를 구축하려면 문서에서 개체와 관계를 뽑아야 한다. 같은 회사를 다른 이름으로 부르는 표현도 묶어야 한다. 잘못 연결된 관계를 검증해야 한다. 문서가 바뀌면 기존 그래프도 고쳐야 한다.
2026년 연구가 이 사전 구축 비용을 비교했다[1].
실험 조건에서 GraphRAG의 구축 비용은 100만 토큰당 13.19달러다. 소요 시간은 1.72시간이었다.
HippoRAG2는 2.85달러와 1.19시간이었다. LinearRAG는 측정된 API 비용 0달러와 0.68시간이었다.
여기서 0달러는 전체 운영비가 없다는 뜻이 아니다. 그 연구에서 집계한 구축 비용 항목의 값이다. 인프라와 인력, 유지보수 비용은 따로 봐야 한다.
세 방식은 그래프의 구조와 구축 절차가 다르다. 그러니 이 수치를 가격 순위로 읽어서는 안 된다.
분명한 것은 하나다. 관계를 미리 구축하는 방식은 질문이 들어오기 전에 비용을 치른다.
반면 반복 검색은 질문이 들어온 뒤에 검색과 추론 비용을 치른다. 어느 쪽이 경제적인지는 실제 업무량이 정한다.
5. 그래프를 만드는 방법도 선택할 수 있다
그래프를 미리 만든다고 모든 관계를 LLM으로 뽑아야 하는 것은 아니다. LLM은 대규모 언어 모델(Large Language Model)이다.
SAP 연구진이 구문 분석을 활용한 구축 방식을 제시했다[3]. 구문 분석은 문장의 문법 구조를 분석하는 기술이다. 그것으로 단어와 구절 사이의 관계를 파악한다.
연구진은 이 방법으로 만든 그래프를 LLM 추출 방식과 비교했다. 평가 점수는 각각 61.87과 65.83이었다. 구문 분석 쪽이 LLM 방식의 약 94%를 냈다.
그래프 구축에서 고비용 LLM 추출이 항상 필요한 것은 아니라는 뜻이다.
하지만 주의해야 한다. 이 결과는 특정 기업 데이터셋과 평가 조건에서 나온 것이다.
문법만으로 의미를 파악하기 어려운 영역도 있다. 계약상 권리·의무, 복잡한 인과관계, 암묵적인 업무 규칙이 그렇다. 그런 자리에서는 성능 차이가 달라질 수 있다.
따라서 기업은 두 가지를 따로 정해야 한다. 그래프를 도입할 것인가. 그리고 그래프를 어떻게 만들 것인가.
규칙 기반 추출, 구문 분석, LLM 추출, 그리고 이들을 결합하는 방식이 모두 후보다.
6. 문서가 자주 바뀌면 무엇이 달라질까
기업의 지식은 고정돼 있지 않다. 계약이 변경된다. 조직이 개편된다. 제품이 단종된다. 규정이 개정된다.
문서의 변경이 곧 그래프의 변경으로 이어지는 경우가 있다.
기존 계약서에 공급업체 A가 부품 X를 납품한다고 적혀 있었다고 하자. 새 계약서에서 공급업체가 B로 바뀌면 기존 관계를 고쳐야 한다.
이때 중요한 것은 새 관계를 더하는 일만이 아니다. 더 이상 유효하지 않은 관계를 어떻게 처리할 것인가다.
그래프를 구축한 뒤 갱신하지 않으면 어떻게 되는가. AI가 낡은 관계를 근거로 답한다.
그렇다고 문서가 바뀔 때마다 전체를 다시 만들 필요는 없다. 2025년 EraRAG 연구가 증분 갱신 방법을 제안했다[5]. 늘어나는 문서 집합을 대상으로 한 연구다.
그러니 갱신 비용은 피할 수 없는 단점이 아니다. 구현 방식에 따라 달라지는 설계 변수다.
기업은 구축 비용만 보면 안 된다. 변경 탐지, 부분 갱신, 삭제, 관계 검증, 이력 관리 비용까지 봐야 한다.
7. 어떤 문서에 그래프가 필요한가
질문 유형만으로는 충분하지 않다. 문서 자체가 얼마나 서로 연결돼 있는지도 중요하다.
2025년 통신 규격 문서를 다룬 연구가 있다. 벡터·그래프·결합 검색을 비교했다[4]. 결합 방식은 사실 정확도 0.58을 기록했다. 그래프 단독은 0.50, 벡터 검색은 0.48이었다.
통신 규격처럼 용어와 정의가 서로 연결된 문서가 있다. 그런 자리에서는 관계 구조가 쓸모 있다.
기업에서도 비슷한 상황이 있다. 취업규칙이 인사규정을 참조한다. 인사규정은 별표와 시행세칙을 참조한다. 또는 제품의 부품구성표가 공급업체·생산공정·품질이력과 연결된다.
이런 업무는 문서 한 개를 찾는 것으로 끝나지 않는다. 여러 관계를 따라가며 근거를 결합하는 능력이 중요하다.
그러나 모든 기업 문서가 그렇지는 않다. 독립적인 FAQ나 단순 제품 설명 문서라면 일반적인 검색으로도 충분하다.
그래프가 필요한지는 문서의 양이 아니라 관계의 중요성이 정한다.
8. 기업은 네 가지를 측정해야 한다
GraphRAG 도입을 검토한다면 기술 제품부터 고르지 않는 편이 좋다. 먼저 네 가지를 재야 한다.
첫째, 질문의 복잡도다. 업무 질문 가운데 여러 문서와 관계를 연결해야 답하는 것이 얼마나 되는가.
둘째, 관계의 재사용성이다. 같은 고객·계약·제품·조직 관계를 서로 다른 질문에서 반복해 쓰는가. 반복이 많다면 구축 비용을 여러 질의에 나눠 담을 수 있다.
셋째, 정보의 변경 빈도다. 관계가 얼마나 자주 바뀌는가. 변경 후 얼마나 빨리 검색 결과에 반영해야 하는가.
넷째, 전체 비용과 응답 시간이다. 그래프 구축·검증·갱신 비용과 반복 검색·추론 비용을 함께 견줘야 한다.
이 네 조건에 따라 선택이 달라진다.
단순한 질문이 대부분이고 재사용이 적다면 일반 RAG가 경제적이다. 관계가 복잡하고 반복해 쓰인다면 사전 구축형 GraphRAG가 유리하다. 문서 변경이 잦고 질문마다 필요한 관계가 다르다면 어떤가. 에이전트 반복 검색이나 선택적 그래프 활용을 검토할 수 있다.
이 판단은 설계 가설이다. 실제 결정에는 자사 데이터로 성능과 비용을 검증하는 일이 따로 필요하다.
9. 답은 반드시 둘 중 하나일까
미리 만드는 방식과 물어볼 때 찾아가는 방식이 있다. 둘은 배타적이지 않다.
기업은 중요한 관계만 미리 구축할 수 있다. 나머지 정보는 질문이 들어왔을 때 검색한다.
조직·고객·제품·계약처럼 자주 쓰이는 핵심 개체와 관계는 그래프로 관리한다. 개별 보고서의 세부 내용이나 최신 업무 기록은 벡터 검색으로 찾는다. AI 에이전트는 질문을 분석해 그래프 탐색과 문서 검색을 조합한다.
이런 구조에서는 사전 구축과 실시간 탐색이 역할을 나눈다.
중요한 것은 그래프의 존재 자체가 아니다. 어떤 관계를 반복해 쓸 값이 있는가. 어떤 관계는 필요할 때 찾아도 되는가. 그것을 정하는 일이다.
JK's Take
지식그래프 도입을 검색 정확도 비교로 결정해서는 안 된다.
그래프의 경제성은 관계를 얼마나 자주 재사용하는가에 달려 있다. 한 번 만든 관계를 수많은 질문에서 쓴다면 구축 비용은 자산이 된다. 거의 쓰지 않는 관계를 대량으로 만들어 계속 갱신한다면 유지비가 된다.
문서 갱신 주기도 중요하지만 그것만으로 결정할 수는 없다. 관계가 자주 바뀌어도 반복 사용의 값이 크고 증분 갱신이 잘 돌면 쓸모 있다.
또 하나의 관문은 개체 해소(Entity Resolution)다. 같은 기업이 법인명, 약칭, 영문명으로 등장할 때가 있다. 이를 같은 개체로 묶지 못하면 관계가 끊어진다. 잘못 묶으면 더 위험하다 — 서로 다른 기업의 계약과 거래가 하나로 연결된다.
결국 지식그래프는 연결선을 많이 만드는 기술이 아니다. 기업이 반복해서 신뢰할 수 있는 관계를 식별하고 유지하는 기술이다.
기술을 고르기 전에 질문과 문서를 봐야 한다. 관계가 얼마나 오래 유효하며 얼마나 자주 쓰이는지도 봐야 한다.
What to Watch
— 에이전트 반복 검색의 발전을 보라. 여러 단계의 검색과 추론이 사전 구축된 그래프의 이점을 얼마나 줄이는지가 관건이다.
— 저비용 그래프 구축을 주목하라. 구문 분석과 규칙 기반 추출, 경량 LLM을 결합한 방식이다. 다양한 기업 데이터에서도 성능을 유지하는지 보면 된다.
— 증분 갱신이 얼마나 성숙하는지 살펴보라. 전체를 재구축하지 않고 변경된 개체와 관계만 고치는 기능이다.
— 그래프와 에이전트의 결합을 검증해야 한다. 핵심 관계는 미리 구축하고 나머지는 실시간 검색하는 혼합형 구조다. 운영 비용과 답변 품질에서 어떤 성과를 내는지가 다음 질문이다.
References
[1] Fan, D., Xue, Z., Liu, S., Tan, Q., "Do We Still Need GraphRAG? Benchmarking RAG and GraphRAG for Agentic Search Systems", arXiv, 2026. https://arxiv.org/abs/2604.09666 — 일반 질의 +0.47점, 다단계 질의 +27.23점과 구축 비용·시간이 이 연구의 측정값이다. 에이전트 반복 검색이 격차를 일부 줄인 것도 같은 연구다.
[2] Xiang, Z. et al., "When to use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation", arXiv, 2025(2026년 2월 개정). https://arxiv.org/abs/2506.05690 — 그래프 검색이 유리한 조건과 그렇지 않은 조건을 질의 유형별로 갈라 본 분석이다.
[3] Min, C. et al., "Towards Practical GraphRAG: Efficient Knowledge Graph Construction and Hybrid Retrieval at Scale", arXiv, 2025. https://arxiv.org/abs/2507.03226 — SAP 연구진의 구문 분석 기반 구축이다. 61.87 대 65.83으로 LLM 추출의 약 94% 성능이 나왔다.
[4] Ahmad, S. et al., "Benchmarking Vector, Graph and Hybrid Retrieval Augmented Generation (RAG) Pipelines for Open Radio Access Networks (ORAN)", arXiv, 2025. https://arxiv.org/abs/2507.03608 — 통신 규격 문서에서 결합 0.58, 그래프 0.50, 벡터 0.48의 사실 정확도를 보고했다.
[5] Zhang, F. et al., "EraRAG: Efficient and Incremental Retrieval Augmented Generation for Growing Corpora", arXiv, 2025. https://arxiv.org/abs/2506.20963 — 늘어나는 문서 집합에서 그래프를 전체 재구축하지 않고 증분 갱신하는 방법을 제안했다.
