GraphRAG 인덱싱 비용은 질의를 받기 전에 문서를 그래프 구조로 미리 정리해 두는 1회성 준비 비용을 가리킨다. 벤더가 내세우는 절감 수치는 대부분 baseline이 공개되지 않은 자가채점이고, config가 드러난 독립 실측을 보면 비용은 사라진 게 아니라 인덱싱과 질의 사이를 오갈 뿐이다.
인덱싱 비용을 1000배 줄였다는 그 헤드라인

AI 검색 도구를 소개하는 벤더 블로그를 읽다 보면, "인덱싱 비용을 1000배 줄였다" 같은 헤드라인과 한 번쯤 마주친다. 큰 수가 순식간에 무너지는 그림이라, 무슨 뜻인지 따져보기도 전에 "요즘 기술은 이렇게 싸지는구나" 하고 넘어가기 쉽다.
그런데 배수 하나만 떼어 놓으면 아무 숫자나 진짜처럼 읽힌다. "1000배 줄었다"가 성립하려면 줄기 전의 값이 있어야 한다. 그게 baseline이다. baseline이 무엇이었는지 — 어떤 모델로 어떤 문서를 인덱싱한 값이었는지 — 가 빠지면 "1000배"는 방향만 가리키는 화살표일 뿐, 크기는 알 수 없다. 이 글은 그 화살표를 거꾸로 되짚는다. 헤드라인의 출처를 열고, config가 드러난 실측과 나란히 놓고, 비용이 정말 사라졌는지 아니면 그저 자리를 옮겼을 뿐인지 확인한다.
GraphRAG 인덱싱 비용이란 무엇인가
먼저 용어부터 맞추자. GraphRAG에서 인덱싱이란, 질의를 받기 전에 문서 전체를 미리 그래프 구조로 정리해 두는 1회성 준비 작업이다. 사용자가 질문을 던지기도 전에 문서를 잘게 자르고, 그 안에서 개체와 관계를 뽑아 그래프를 세우고, 덩어리마다 요약을 미리 구워 둔다. 이 준비가 끝나야 질의를 빠르게 받을 수 있다.
벡터 RAG도 인덱싱은 한다. 다만 그쪽 인덱싱은 문서 조각을 임베딩 벡터로 바꿔 저장하는 데서 끝난다. GraphRAG 인덱싱은 여기에 더해 언어모델로 개체·관계를 추출하고 커뮤니티 요약까지 만든다 — 준비 단계에 LLM 호출이 훨씬 많이 들어간다는 뜻이다.
비용은 이 준비 과정 어딘가에서 쌓인다. 그런데 한 덩어리로 뭉뚱그린 값이 아니다. 다섯 단계로 쪼개 보면 비용이 어디서 몰리는지가 드러난다.
그림 1을 보면 비용이 특정 단계에 몰린다는 게 눈에 들어온다. 문서를 자르고(1단계) 인덱스를 저장하는(5단계) 일 자체는 싸다. 값을 끌어올리는 건 언어모델을 부르는 두 단계 — 개체·관계 추출(2단계)과 커뮤니티 요약 생성(4단계)이다. 특히 네 번째 요약 단계를 기억해 두자. 이 글 뒤편에서, 바로 이 단계가 통째로 자리를 옮기는 장면이 나온다.
"$33,000이 $33이 됐다"는 이야기, 열어보니
그 장면으로 가기 전에, 인덱싱 비용을 둘러싸고 인터넷에 도는 유명한 숫자 하나를 먼저 열어 보자. "18개월 만에 $33,000이 $33이 됐다"는 코스트 클리프다. 배수로 치면 딱 1000배 — 서두의 그 헤드라인과 판박이다. 그 출처를 따라가면 그림이 사뭇 달라진다.
숫자는 한 Medium 글에서 나온다. 글쓴이는 "2024년 초에 5GB짜리 법률 판례 데이터셋을 인덱싱하는 데 $33,000이 들었다"고 적는다. 그런데 딱 거기까지다. 어떤 모델을 썼는지, 토큰 단가가 얼마였는지, 어떤 config로 돌렸는지, 그 $33,000이 어느 청구서에서 나온 값인지 — 아무것도 없다. baseline이 공개되지 않은, 검증할 길이 없는 일화 하나다.
남은 건 "$33"이라는 숫자의 출처다. 놀랍게도 본문에는 $33이라는 절대값이 아예 없다. 제목에만 있는 수사다. 산술로 거슬러 오르면 $33은 $33,000의 0.1%이고, 그 0.1%는 Microsoft가 자기 제품 LazyGraphRAG의 인덱싱 비용을 스스로 보고한 비율이다. 그러니 이 숫자의 정체는 뻔하다 — 검증 안 된 일화 baseline에 벤더가 매긴 비율을 곱해 뽑아낸 파생값, 그게 "$33"이다.
이러면 "1000배"는 데이터가 아니다. 비공개 일화 하나에 자가보고 비율 하나를 곱한 결과일 뿐이다. 그렇다면 config를 실제로 밝힌 사람들이 잰 값은 얼마였을까.
진짜 실측 비용은 얼마인가
microsoft/graphrag 저장소에는 "각자 인덱싱에 얼마 썼나"를 서로 묻는 토론 스레드가 있다. 여기 올라온 값들은 밈과 결이 다른데, 쓴 모델과 코퍼스를 함께 밝힌 실측치이기 때문이다. 이제 세 사람의 인덱싱 비용을 한 줄에 세워 보자.
그림 2에서 먼저 걸리는 건 highlight된 맨 위 막대다. DeepSeek로 100만 단어, 약 120만 토큰을 인덱싱한 값이 $8.20. 코퍼스가 셋 중 가장 큰데도 값은 데모 규모의 $5와 같은 한 자릿수다. 반대로 GPT-4-turbo-preview로 1000쪽 PDF를 돌린 값은 $120이다. 같은 GraphRAG 인덱싱인데 열 배를 훌쩍 넘게 벌어진다.
무엇이 이 차이를 만들었을까. 그래프를 얼마나 정교하게 세웠느냐가 아니다. 앞서 그림 1에서 값을 끌어올리는 단계가 언어모델을 부르는 두 곳이라고 했다. 그 언어모델을 무엇으로 고르느냐가 인덱싱 비용을 좌우하는 가장 큰 단일 레버다.
물론 모델이 전부는 아니다. 같은 gpt-4-turbo 계열 안에서도 데모 규모의 $5와 1000쪽 PDF의 $120이 스무 배 넘게 벌어지니, 코퍼스 크기와 규모도 분명한 레버다. 그래도 $8.20이냐 $120이냐를 처음 가르는 손잡이는 그래프 구조가 아니라 어떤 모델을 얹느냐다.
비용은 사라지지 않는다 — 자리를 옮길 뿐
모델을 싼 것으로 고르면 인덱싱 값은 내려간다. 그런데 인덱싱을 아무리 깎아도 사라지지 않는 게 하나 있다. 인덱싱에서 덜 쓴 만큼, 그 일은 대개 질의 쪽으로 넘어간다.
가장 뚜렷한 사례가 Microsoft의 LazyGraphRAG다. 이름 그대로 "게으른" GraphRAG인데, 그림 1의 네 번째 요약 단계 — 언어모델로 커뮤니티를 요약하는 그 비싼 작업 — 를 인덱싱 때 미리 하지 않는다. 두 번째 개체·관계 추출도 마찬가지다. 언어모델이 하던 두 몫을 모두 질문이 들어온 순간까지 미뤄 둔다. 값을 끌어올리던 언어모델 단계 두 곳이 인덱싱에서 다 빠지니, 인덱싱은 거의 공짜에 가까워진다. 벤더는 이 비용을 이렇게 적는다.
LazyGraphRAG의 인덱싱 비용은 "0.1% of the costs of full GraphRAG"이며, 이는 벡터 RAG와 "identical to vector RAG" 수준이다. 글로벌 질의에서는 "more than 700 times lower query cost"를 보고한다.
출처: Microsoft Research, “LazyGraphRAG: setting a new standard for quality and cost”숫자는 화려하다. 다만 이 값들은 전부 만든 쪽이 스스로 잰 자가보고치다. 독립된 제3자가 확인한 값이 아니다. 게다가 인덱싱을 0.1%로 깎았다는 말과, 그 언어모델 작업을 질의 시점으로 옮겼다는 말은 같은 동전의 양면이다. 준비 단계에서 덜 낸 비용이 허공으로 증발한 게 아니라, 질문이 들어올 때마다 조금씩 나눠 내는 구조로 바뀌었을 뿐이다.
그러니 자가보고 배수는 잠시 접어 두자. 대신 이 글이 이미 손에 쥔 실측 두 숫자만으로 따져 본다. 인덱싱은 한 번에 $120이 든다(1000쪽 PDF, mystvearn 케이스). 질의는 한 번에 약 $0.40이 든다(GPT-4-Turbo, zanderjiang 케이스). 인덱싱 한 번을 몇 번의 질의가 따라잡을까. 답은 나눗셈 한 번이면 나온다.
# 인덱싱은 한 번만, 질의는 매번 비용이 든다.
# 누적 질의 비용이 1회 인덱싱 비용을 따라잡는 질의 횟수를 구한다.
index_cost = 120.0 # 1회 인덱싱 ($, mystvearn: 1000쪽 PDF, GPT-4-turbo-preview)
query_cost = 0.40 # 질의당 ($, zanderjiang: 1MB txt, GPT-4-Turbo)
breakeven_queries = index_cost / query_cost
print(f"손익분기 질의 횟수: {breakeven_queries:.0f}회")손익분기 질의 횟수: 300회약 300번이다. 질의를 300번쯤 받고 나면, 그 지점부터 누적 질의 비용이 1회 인덱싱 비용을 넘어선다. 두 비용이 어디서 만나는지는 그림으로 보면 더 분명하다.
그림 3이 말하는 건 단순하다. 인덱싱을 아무리 깎아도, 질의가 쌓이면 비용은 결국 그쪽으로 흘러간다. 그러니 "인덱싱 얼마"라는 한 숫자만으로는 비교가 성립하지 않는다. 인덱싱 비용과 질의 비용을 갈라 놓고, 이 시스템이 앞으로 질의를 몇 번이나 받을지까지 함께 얹어야 한다.
한 가지만 덧붙이자. 질의 쪽으로 옮겨간 비용은 돈만이 아니다. 시간이기도 하다.
그럼 코퍼스가 바뀌면 처음부터 다시 인덱싱해야 하나
비용이 자리를 옮긴다는 그림에는 흔한 반문이 하나 따라붙는다. 문서가 하나 바뀌거나 새로 들어오면, 그 비싼 인덱싱을 전부 처음부터 다시 돌려야 하는 것 아니냐는 물음이다. 한동안은 맞는 말이었다. 지금은 아니다.
"코퍼스가 바뀌면 전체 재구축"은 낡은 통념이다. microsoft/graphrag는 v0.4.0(2024-11-06)부터 증분(delta) 재인덱싱을 지원한다. 새로 들어오고 빠진 입력의 차이(delta)만 계산해 갱신하는 방식이고, 뒤이은 릴리스에는 update 명령이 붙었다. 다만 이 증분 갱신이 전체 재구축 대비 비용을 몇 분의 몇으로 줄이는지는 공식적으로 측정된 값이 없다. "지원된다"는 사실까지가 확인된 전부이고, 절대 비용비는 아직 아무도 공개된 숫자로 재지 않았다.
그래서 이 대목은 조심스럽게 남겨 둔다. 재구축의 공포는 근거가 약해졌지만, "그래서 얼마나 아끼나"에 답하려면 같은 코퍼스로 증분 갱신과 전체 인덱싱을 각각 돌려 청구서를 맞대 보는 수밖에 없다. 벤더도, 릴리스 노트도 그 숫자만큼은 아직 내놓지 않았다.
벤더 수치를 읽는 법
여기까지 왔으면 ‘N배 절감’ 헤드라인을 다시 만났을 때 무엇을 해야 할지 감이 잡힌다. 숫자를 믿을지 버릴지 정하기 전에, 네 가지만 물어보면 된다.
첫째, 이 숫자를 누가 쟀나. 만든 쪽이 스스로 매긴 자가보고인가, 이해관계 없는 제3자가 잰 값인가. LazyGraphRAG의 0.1%도, KET-RAG의 10배도 만든 쪽이 스스로 잰 값이었다.
둘째, baseline이 공개돼 있나. "1000배 줄었다"는 줄기 전 값이 무엇이었는지 밝혀야 비로소 크기를 갖는다. $33,000처럼 출처 없는 일화가 baseline이라면, 그 배수는 방향만 가리키는 화살표에 지나지 않는다.
셋째, 절대값인가 비율인가. 비율은 비공개 baseline만 곱하면 어떤 숫자든 만들어낸다. 실측 $5~$120 같은 절대값이 함께 있어야 손에 잡힌다.
넷째, 인덱싱 비용인가 질의 비용인가. 인덱싱을 0.1%로 깎았다는 말은, 그 일이 질의로 넘어갔다는 말과 나란히 읽어야 한다.
헤드라인을 검증하는 가장 빠른 길은 스스로 한 번 재 보는 것이다. 벤더 수치를 믿기 전에, 자기 문서 100~200개로 작은 파일럿 인덱스를 한 번만 돌려 보라. 실제 청구서에 찍히는 몇 달러가, 남이 잰 어떤 배수보다 정확한 baseline이 되어 준다.
이제 서두의 그 헤드라인으로 돌아가 보자. "인덱싱 비용을 1000배 줄였다" — 같은 문장인데, 여기까지 온 눈으로 다시 읽으면 뜻이 달라진다. 설령 1000배가 사실이어도 그 비용은 사라지지 않았다. 인덱싱에서 아낀 만큼 질의 쪽으로 자리를 옮겼을 뿐이고, 무게중심이 어디 놓이는지는 어떤 모델을 골랐는지와 앞으로 질의를 몇 번 받을지에 달려 있다. 헤드라인의 배수가 아니라 바로 그 두 가지를 손에 쥔 사람만이 진짜 비용을 안다.
더 읽기
- Microsoft Research (2024). "LazyGraphRAG: setting a new standard for quality and cost". https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/
- GitHub Discussion #440. "How much did each run cost you?". microsoft/graphrag. https://github.com/microsoft/graphrag/discussions/440
- Huang, Zhang, & Xiao (2025). "KET-RAG: A Cost-Efficient Multi-Granular Indexing Framework for Graph-RAG". arXiv:2502.09304. https://arxiv.org/abs/2502.09304