먼저 결론부터 말씀드리겠습니다. "GraphRAG가 Vector RAG보다 우수하다"는 이야기는 거의 정확도 측면만의 이야기입니다. 저는 1만 건의 문서로 GraphRAG의 그래프 구축 시간과 LLM API 비용, 그리고 쿼리 지연(Latency)을 실측했습니다. 결과적으로 구축 비용은 Vector RAG의 수십 배, 구축 시간은 수백 배였습니다. 정확도는 확실히 올라갑니다. 하지만 돈과 시간 측면에서 보면, 많은 현장에서는 수지타산이 맞지 않습니다.

"GraphRAG가 대단하다"는 말은 사실입니다. 다만, 대단한 것은 나오는 답변의 질이지, 그곳에 도달하기까지의 비용이 아닙니다. 솔직히 말하면 저도 처음에는 "정확도가 올라간다면 쓸 수밖에 없다"라고 생각하던 쪽이었습니다. 청구서를 보기 전까지는 말이죠. 이 기사는 그 보이지 않는 비용을 숫자로 나타내는 이야기입니다.

먼저 선을 그어두겠습니다. 저는 GraphRAG 관련 기사를 이전에도 쓴 적이 있습니다. 하나는 "GraphRAG는 우수한가"를 1만 건으로 비교한 기사로, 이는 답변 정확도의 비교였습니다. 다른 하나는 코드베이스를 지식 그래프(Knowledge Graph)화하는 기사로, 이는 리뷰 정확도에 관한 이야기였습니다.

이 기사는 그 어느 쪽도 아닙니다. 다루는 것은 구축 비용, 구축 시간, 운영 비용입니다. 즉 돈과 시간입니다. 정확도가 아무리 높더라도 구축에 며칠과 수만 엔이 걸린다면, 채택 여부의 판단은 정확도만으로 결정되지 않습니다. 보는 것은 바로 그 지점입니다.

추측은 섞지 않았습니다. 조건을 먼저 제시합니다.

• 데이터: 사내 문서를 모사한 1만 건, 1건당 평균 약 800 토큰
• 그래프 DB: Neo4j (Community Edition, 로컬)
• 추출 모델: GPT-4o-mini 상당 (엔티티/리레이션 추출 및 커뮤니티 요약)
• 임베딩 모델: text-embedding-3-small 상당
• GraphRAG 구현: Microsoft GraphRAG의 기본 설정 준수
• Vector RAG: 동일한 1만 건을 청크(Chunk) 단위로 분할하여 임베딩 후 pgvector에 저장
• 측정 대상: 구축 시간, 구축 API 비용, 1쿼리당 지연 시간 및 토큰

GraphRAG는 1청크마다 LLM을 호출하여 엔티티(Entity)와 관계(Relation)를 뽑아냅니다. 1만 건이라면 추출에만 1만 회 전후의 LLM 호출이 실행됩니다. 여기에 더해 Leiden 클러스터링(Clustering)으로 커뮤니티를 만들고, 각 커뮤니티를 LLM으로 요약합니다. Vector RAG는 임베딩을 1회 통과할 뿐입니다. 이 구조의 차이가 그대로 비용의 차이가 됩니다.

실측한 운영 비용의 대비표입니다. GraphRAG vs Vector RAG를 동일한 1만 건으로 나열합니다.

항목	Vector RAG	GraphRAG	배율
구축 시간	약 4분	약 11시간	약 165배
...

숫자의 내용을 보충하겠습니다. GraphRAG의 구축 API 비용 약 14달러의 내역은 엔티티 추출이 대부분이며, 나머지는 커뮤니티 요약입니다. 추출은 1청크당 1회, 요약은 커뮤니티 수만큼 실행됩니다. 구축 시간 약 11시간은 LLM API의 레이트 리밋(Rate Limit)과 순차 처리의 영향이 있습니다. 병렬화를 하면 단축되겠지만, 그만큼 레이트 상한에 걸리게 됩니다.

비용 내역을 조금 더 자세히 나누어 보겠습니다. 1만 청크의 엔티티 추출에서 입력과 출력을 합치면 수천만 토큰이 움직입니다. GPT-4o-mini 상당의 단가로 이것이 약 11달러. 커뮤니티 요약이 약 3달러. 합쳐서 약 14달러였습니다. 여기서 강조하고 싶은 점은 추출에 사용한 모델이 GPT-4o-mini 상당이라는 저렴한 쪽이라는 점입니다. 추출 정확도를 높이기 위해 GPT-4o 상당으로 전환하면 단가가 한 자릿수 올라가며, 구축 비용은 100달러 이상으로 치솟습니다. 정확도를 챙길수록 비용이 커지는 구조입니다.

이 14달러는 1만 건을 1회 구축했을 때의 숫자입니다. 문서가 업데이트되면 재구축이나 차분 업데이트가 필요합니다. 원본 데이터가 움직이는 현장에서는 이 비용이 매달 추가됩니다. 한 번 내고 끝나는 것이 아닙니다.

Vector RAG의 구축은 임베딩 1회로 끝나기 때문에 4분과 0.2달러였습니다. 임베딩 모델은 토큰 단가가 LLM보다 훨씬 저렴하며, 게다가 호출은 1청크당 1회의 편도입니다. LLM처럼 입력과 출력 모두 토큰을 소비하는 것이 아닙니다. 쿼리 시에도 벡터 근방 검색(Vector Similarity Search)으로 청크를 가져오기만 하므로, 지연 시간과 토큰 사용량도 작게 유지됩니다. 이 비대칭성이 양자를 가르는 근본 원인입니다.

이유는 단순합니다. 구축 시에 LLM을 대량으로 사용하기 때문입니다.

GraphRAG의 처리는 4단계입니다. 엔티티/관계 추출 (Entity/Relation Extraction), Leiden 클러스터링 (Leiden Clustering), 커뮤니티 요약 (Community Summarization), 그래프 확장 검색 (Graph-Augmented Retrieval). 이 중 추출과 요약 단계에서 LLM 호출이 발생합니다. 1만 개의 청크(Chunk)라면 추출에만 1만 번이 필요합니다. 커뮤니티 요약 또한 계층 구조에 따라 여러 번 실행됩니다.

비유하자면, Vector RAG는 책장에 번호 스티커를 붙이는 작업과 같습니다. 반면 GraphRAG는 모든 책을 읽고 등장인물의 상관도를 직접 손으로 그려내는 작업입니다. 후자가 더 똑똑한 검색을 할 수 있는 것은 당연하지만, 상관도를 그리는 인건비가 그대로 API 비용으로 전가됩니다.

쿼리(Query) 시에도 차이가 발생합니다. GraphRAG는 관련 있는 커뮤니티 요약을 여러 개 모아서 LLM에 전달하므로, 1회 쿼리당 토큰 사용량이 늘어납니다. 제가 측정한 바로는 Vector RAG의 약 15배에 달하는 토큰을 사용했습니다. 쿼리 단가 또한 운영이 지속됨에 따라 큰 영향을 미치게 됩니다.

그래프 구축은 문서량에 비례합니다. 우선 100페이지 정도의 작은 데이터로 구축 비용과 정확도를 측정하고, 비용 대비 효과를 확인한 뒤에 1만 건 규모로 확장하는 것이 안전합니다. 처음부터 전체 데이터를 흘려보내면, 정확도를 확인하기도 전에 비용부터 확정되어 버립니다.

구축 비용은 청구서에 찍히기 때문에 아직은 알아차릴 수 있습니다. 제가 현장에서 정말 뼈저리게 느낀 것은 그 뒤에 숨겨진 운영 비용이었습니다. 솔직히 고백하자면, 첫 프로젝트에서 저 역시 이 부분을 완벽히 간과했습니다. 구축 비용인 14달러만 보고 "생각보다 저렴하네"라며 안일하게 생각했다가, 운영 단계에 들어서면서 매달 추가되는 재구축 비용과 그래프 DB 관리의 번거로움 때문에 조용히 머리를 싸매게 되었습니다. 이 부분은 겉으로 잘 드러나지 않기 때문에 초기 견적에서 누락되기 쉽습니다.

첫 번째는 재구축입니다. 사내 문서는 멈춰 있지 않습니다. 주 단위로 문서가 추가되거나 업데이트되는 현장이라면 그래프도 이를 따라가야 합니다. 전체를 재구축한다면 매번 14달러가 추가로 들 것이고, 차분 업데이트 (Incremental Update)를 구성하더라도 업데이트된 청크와 연결된 엔티티 및 관계를 다시 그려내는 수고가 필요합니다. Vector RAG라면 늘어난 만큼 임베딩 (Embedding)을 추가하기만 하면 됩니다. 차분의 무게가 완전히 다릅니다.

두 번째는 그래프 DB의 운영입니다. GraphRAG는 Neo4j와 같은 그래프 DB를 상시 가동하는 것을 전제로 합니다. 인스턴스 비용, 백업, 버전 관리, 스키마 관리 등 신경 쓸 것이 많습니다. Vector RAG 역시 당연히 벡터 스토어 (Vector Store)가 필요하지만, pgvector처럼 기존의 PostgreSQL에 얹어서 사용할 수 있는 선택지가 있어 운영 부담이 가벼운 경우가 많습니다.

세 번째는 사람의 손길입니다. 엔티티 추출은 완벽하지 않습니다. 동일 인물이 별개의 엔티티로 중복 등록되거나, 관계의 방향이 뒤바뀌는 등의 오차가 반드시 발생합니다. 정확도를 유지하려면 추출 결과를 사람이 리뷰하고 온톨로지 (Ontology)를 수정하는 공정이 필요합니다. 이 인건비는 청구서에 나타나지 않지만, 확실한 비용입니다.

GraphRAG의 비용은 '구축 1회'로 끝나지 않습니다. 재구축, 그래프 DB 운영, 추출 결과 리뷰. 이 세 가지가 운영 단계에서 매달 발생합니다. 구축 비용만 보고 채택 여부를 결정하면, 운영 단계에서 큰 타격을 입게 됩니다.

지금까지는 풀(Full) GraphRAG를 전제로 작성했습니다. 하지만 구축 비용의 전제 조건은 지난 1~2년 사이 크게 변했습니다.

Microsoft Research는 2024년 11월에 LazyGraphRAG를 발표했습니다. 커뮤니티 요약을 구축 시점에 미리 만들지 않고, 쿼리 시점까지 미루는 방식입니다. Microsoft의 보고에 따르면, 인덱스 구축 비용은 풀 GraphRAG의 약 0.1%, 즉 1,000분의 1 수준까지 낮아진다고 합니다. 10만 달러급의 구축 비용이 수백 달러로 줄어드는, 차원이 다른 이야기입니다.

또 다른 계열로는 LightRAG가 있습니다. 커뮤니티 요약을 사전 계산하지 않고, 그래프 상에서 국소적(Local) 영역과 전체(Global) 영역을 직접 2단계로 검색하는 방식입니다. 풀 GraphRAG가 100만 토큰당 20~40달러를 소모할 때, LightRAG는 1달러 미만이라는 비교 결과도 보고되었습니다. 인덱스의 토큰 비용이 자릿수 단위로 줄어드는 계산입니다.

시간 축을 조금 더 길게 놓고 보면 변화의 크기를 알 수 있습니다. 풀 GraphRAG 등장 초기에는 데이터셋 하나를 인덱싱하는 데 수만 달러가 들었다는 사례가 보고되었습니다. 하지만 LazyGraphRAG, LightRAG, Fast GraphRAG와 같은 경량 구현 방식들이 등장하면서, 1~2년 사이에 인덱스 비용이 수십 배에서 수천 배까지 낮아졌습니다. 같은 'GraphRAG'라는 이름을 사용하더라도, 2024년 초의 수치와 2026년의 수치는 완전히 다른 것입니다.

즉 "GraphRAG는 구축 비용이 높다"는 말은, 풀 구현(Full Implementation)에 한해서는 지금도 맞지만, 설계를 잘 선택한다면 비용을 자릿수 단위로 낮출 수 있는 시대에 진입했습니다. 제가 언급한 14달러라는 수치도 구현 방식을 바꾸면 달라집니다. 채택 여부를 결정하기 전에, 이것이 풀 GraphRAG인지 아니면 경량화 버전인지 반드시 확인하십시오. 이름만 보고 "비싸다" 혹은 "싸다"를 결정하면, 1~2년 전의 전제를 바탕으로 판단하게 됩니다.

비용 이야기만 하고 "그러니 쓰지 마라"라고 말하려는 것이 아닙니다. GraphRAG가 효과적인 상황은 명확합니다.

GraphRAG가 빛을 발하는 지점은 "문서 전체의 경향은 무엇인가", "A와 B에 공통된 과제는 무엇인가"와 같이 문서를 가로질러 연결하는 질문입니다. Vector RAG는 가까운 문서를 찾는 데는 능숙하지만, 떨어진 점과 점을 연결하는 추론에는 서툽니다. 이 부분은 GraphRAG가 명확하게 우위에 있습니다. 실제로 LinkedIn은 지원 티켓을 KG+RAG로 구조화하여 문제 해결 시간의 중앙값을 28.6% 단축했다고 보고했습니다. 관계를 추적하는 가치가 큰 업무라면, 비용을 지불할 의미가 있습니다.

반대로, 질문의 대부분이 "이 제품의 보증 기간은?"과 같은 단일 사실(Single Fact) 검색이라면 Vector RAG로 충분합니다. 여기서 GraphRAG를 도입하면 정밀도(Accuracy)의 향상은 미미한데 구축 비용과 운영 부하만 늘어납니다. 제가 말하고자 하는 핵심은 이것입니다. 정밀도가 올라가는 것 자체는 사실입니다. 문제는 그 정밀도가 올라가는 폭이 자신들의 질문에 대해 비용만큼의 가치가 있느냐 하는 것입니다.

판단 순서는 다음과 같습니다. 먼저 질문의 타입을 봅니다. 횡단적인 질문이 많은지, 단일 사실 질문이 많은지 확인하십시오. 횡단 질문이 주를 이룬다면 경량 GraphRAG부터 검증합니다. 단일 사실이 주를 이룬다면 Vector RAG에서 멈춥니다. 정밀도 벤치마크 표만 보고 결정하면 이 순서를 건너뛰게 됩니다.

마지막으로, 제가 새로운 프로젝트에서 RAG를 설계할 때 사용하는 절차를 적어둡니다.

• 예상 질문을 20개 정도 수집하여, 횡단 질문과 단일 사실 질문의 비율을 산출한다.
• 100페이지 정도의 소규모 데이터로 GraphRAG와 Vector RAG를 모두 구축하여 정밀도와 비용을 실측한다.
• 1만 건으로 확대했을 때의 구축 비용과 월간 재구축 비용을 선형적으로 추정한다.
• 정밀도의 향상 폭을 증가하는 비용으로 나누어 "1포인트당 비용이 얼마인가"를 산출한다.

4번 항목이 효과적이었습니다. 정밀도가 3포인트 올라가더라도 구축과 운영에 월 수만 엔이 추가된다면, 그 3포인트에 가치가 있는지를 팀원들과 논의할 수 있습니다. "우수하니까 도입하자"가 아니라 "이 질문군에 대해 이 비용이 적절한가"로 대화할 수 있게 됩니다. 기술 선정 회의에서 벤치마크 스코어만을 근거로 삼으면 논의가 공중전(실체가 없는 논쟁)이 되기 쉽습니다. 비용을 동일한 단위로 맞추면 논의가 현실적인 지면으로 내려옵니다.

이 절차는 '신장의 야망'에서 말하는 포석(布石)과 비슷한 감각입니다. 소규모 데이터 검증은 수백 엔이면 충분합니다. 거기서 구축 비용과 정밀도의 기울기를 파악해 두면, 1만 건으로 확대했을 때의 청구서를 미리 내다볼 수 있습니다. 나중에 놀라지 않기 위한 저렴한 보험이라고 생각합니다.

지식은 인생의 난이도를 낮춰준다고 저는 믿습니다. GraphRAG의 정밀도 벤치마크만 보고 뛰어들었다가는 구축 단계의 청구서를 보고 놀라게 될 것입니다. 미리 이 구조를 알고 있다면 놀라지 않을 수 있습니다.

• "GraphRAG는 우수하다"는 주로 답변 정밀도에 관한 이야기이며, 구축 비용과 운영 비용은 별개의 축이다.
• 1만 건 실측 결과, 풀 GraphRAG는 구축 시간이 약 165배, API 비용이 약 70배였다.
• 비용이 높은 이유는 구축 시 1청크(Chunk)마다 LLM을 호출하는 구조 때문이다. 쿼리의 토큰량도 약 15배 높다.
• LazyGraphRAG나 LightRAG 등 구축 비용을 자릿수 단위로 낮출 수 있는 선택지들이 2026년에는 갖춰져 왔다.
• 횡단 질문이 많다면 GraphRAG, 단일 사실이 주라면 Vector RAG에서 멈춘다.

마지막으로 하나 더. GraphRAG를 사용할지 말지는 정밀도의 승패로 결정되지 않습니다. 자신들의 질문에 대해 그 정밀도가 비용만큼의 가치가 있는가입니다. 숫자를 내어 비교하십시오. 그것만으로도 벤치마크 표에 휘둘리지 않을 수 있습니다. 즐겁게 임합시다.