필사 모드: 문서에서 지식 그래프로 — 정직한 구축 파이프라인

• 들어가며 — 데모는 호출 한 번, 프로덕션은 파이프라인
• 스키마가 먼저다 — 온톨로지 없이는 노이즈만 쌓인다
• 추출 — 전통적 NER인가, LLM인가
• 엔티티 해소 — 진짜 어려운 곳
• 그래프 스토어에 적재 — 그리고 모든 엣지에 출처를
• 증분 업데이트와 스키마 드리프트 — 한 번으로 안 끝난다
• 품질과 증거 — 평가할 수 없으면 배포하지 마라
• 정직한 비용 — 어디서 깨지는가
• 마치며
• 참고 자료

들어가며 — 데모는 호출 한 번, 프로덕션은 파이프라인

"문서를 넣으면 지식 그래프가 나온다." 데모에서는 이게 LLM 호출 한 번처럼 보입니다. LangChain의 LLMGraphTransformer나 LlamaIndex의 PropertyGraphIndex에 문서 몇 개를 넣으면, 노드와 엣지가 그려진 근사한 그림이 나옵니다. 시연은 5분이면 끝납니다.

문제는 그다음입니다. 고객의 문서 수만 페이지를 쿼리 가능한 그래프로 바꾸는 일 — Forward Deployed Engineer가 실제로 하는 일 — 은 호출 한 번이 아니라 여섯 단계의 파이프라인입니다. 그리고 비용과 고통의 대부분은 모두가 주목하는 단계(추출)가 아니라, 아무도 데모에서 보여 주지 않는 단계(엔티티 해소)에 있습니다.

이 글은 그 파이프라인을 정직하게 따라갑니다 — 어디에 돈이 들고, 어디서 깨지는지까지.

문서
  │  (1) 스키마 / 온톨로지 먼저 — 노드·엣지 타입을 정한다
  ▼
청크 ──(2) 추출──▶ 원시 트리플   ← 청크 수만큼의 LLM 호출, 예측 가능
  │      LLM 기반, 스키마 제약
  ▼
(3) 엔티티 해소   ← 같은 엔티티, 수많은 표기 · 진짜 어려운 곳
  │   블로킹 → 스코어링 → 클러스터링(정규화)
  ▼
(4) 그래프 스토어에 적재   (+ 모든 엣지에 출처)
  │
  ├─(5) 증분 업데이트 & 스키마 드리프트  ← 한 번으로 안 끝난다
  └─(6) 품질 / 평가   ← 정밀도(맞나?) · 재현율(빠졌나?)

노력이 실제로 몰리는 곳 (대략적인 감):
  추출        ~20%   (눈에 보이고 예측 가능)
  엔티티 해소  ~50%   (긴 꼬리, 수작업)
  평가 + 출처  ~30%   (없으면 못 믿을 그래프를 배포하는 셈)

스키마가 먼저다 — 온톨로지 없이는 노이즈만 쌓인다

추출부터 시작하고 싶은 유혹이 큽니다. 하지만 무엇을 뽑을지 정하지 않고 뽑으면, 결과는 그래프가 아니라 노이즈 더미입니다. 같은 개념이 회사, 기업, 조직으로 제각각 나오고, 관계 이름은 문장마다 달라집니다. 이런 그래프는 그릴 수는 있어도 쿼리할 수는 없습니다.

그래서 첫 단계는 코드가 아니라 결정입니다 — 어떤 노드 타입과 엣지 타입이 존재하는가. 이것이 곧 도메인 온톨로지이고, 왜 이걸 먼저 해야 하는지는 도메인 지식을 온톨로지로 만드는 법에서 따로 다뤘습니다. 여기서 중요한 것은 그 결정이 파이프라인 전체를 좌우한다는 점입니다. 다음 단계의 추출기는 이 스키마를 제약 조건으로 받아, 스키마에 없는 것은 뽑지 않습니다. 스키마가 곧 그래프의 문법이 됩니다.

추출 — 전통적 NER인가, LLM인가

두 번째 단계는 텍스트에서 엔티티와 관계를 실제로 뽑는 일입니다. 길게 보면 두 계보가 있습니다.

전통적 방식은 개체명 인식(NER)과 관계 추출(relation extraction)을 파이프라인으로 잇습니다. 성숙하고, 값싸고, 대량 처리에 강합니다. 대가도 분명합니다 — 도메인마다 라벨링된 학습 데이터가 새로 필요하고, 개체 인식 단계의 오류가 관계 추출로 전파되며(파이프라인의 고질병), 문장을 넘는 맥락을 잘 잡지 못합니다.

LLM 기반 추출은 반대편의 트레이드오프입니다. 라벨 없이 제로샷/퓨샷으로 시작하고, 맥락을 유지한 채 결과를 스키마에 매핑합니다. 대신 두 가지 새 문제가 생깁니다 — 환각(없는 관계를 지어냄)과 표기 변이(같은 것을 매번 다르게 부름). 앞의 것은 뒤의 4번 단계를, 뒤의 것은 3번 단계를 어렵게 만듭니다.

실무 도구 셋을 보면 트레이드오프가 손에 잡힙니다.

• LangChain LLMGraphTransformer. convert_to_graph_documents가 문서를 노드와 관계로 바꿉니다. allowed_nodes와 allowed_relationships로 타입을 제약하는데(둘 다 기본값은 빈 리스트 = 전부 허용), allowed_relationships는 (출발타입, 관계, 도착타입) 튜플까지 받습니다. 아직 experimental 모듈이고, 모델에 따라 빈 결과가 나오기도 합니다.
• LlamaIndex 추출기. 같은 작업을 세 갈래로 제공합니다. SimpleLLMPathExtractor는 스키마 없이 자유롭게 뽑아 "may produce a larger number of diverse relationships"지만 "might lack consistency in entity and relation naming". SchemaLLMPathExtractor는 미리 정한 스키마로 "produces a more structured graph"지만 "might miss a lot of relationships that don't fit the predefined schema". DynamicLLMPathExtractor는 그 사이 — 초기 스키마의 안내를 받되 필요하면 확장해 "a balance between diversity and consistency"를 노립니다. 트레이드오프가 클래스 이름으로 박제돼 있는 셈입니다.
• Microsoft GraphRAG. 텍스트 단위마다 엔티티와 관계를 뽑고 각각에 설명을 붙인 뒤, 같은 엔티티의 여러 설명을 "coherent, non-redundant descriptions"로 합칩니다.

비용은 예측 가능합니다. 추출은 본질적으로 청크 수만큼의 LLM 호출입니다. 문서가 늘면 선형으로 늘고, 배치로 돌릴 수 있고, 캐시가 듣습니다. 파이프라인에서 가장 다루기 쉬운 단계입니다. 어려운 곳은 따로 있습니다.

엔티티 해소 — 진짜 어려운 곳

추출이 끝나면 트리플 수십만 개가 생기는데, 그중 상당수가 같은 것을 가리키는 다른 이름입니다. 김민수, 민수 김, Kim, M.가 한 사람일 수도 있고, 아닐 수도 있습니다. 이걸 정리하는 일이 엔티티 해소(entity resolution)이고, 지식 그래프 구축에서 품질이 갈리는 지점입니다.

정석은 세 단계입니다.

1. 블로킹(blocking). 후보를 좁힙니다. 모든 엔티티 쌍을 비교하면 비용이 n²으로 폭발하므로(엔티티 10만 개면 비교가 100억 쌍), 임베딩 기반 근사 최근접 탐색 등으로 "그나마 비슷한 것들"만 같은 블록에 모읍니다. 현장의 격언대로 블로킹이 매칭보다 중요합니다 — 여기서 놓친 쌍은 뒤에서 절대 만나지 못합니다.
2. 스코어링(scoring). 블록 안의 쌍에 유사도를 매깁니다 — 문자열 유사도, 관계적 근접성, 임베딩, 행동 신호 등.
3. 클러스터링/정규화(canonicalization). 점수를 근거로 같은 엔티티끼리 묶고, 각 묶음을 하나의 정규 노드로 만듭니다.

실패 모드는 두 방향으로 대칭입니다.

• 과병합(over-merge). 서로 다른 두 김민수를 한 노드로 합칩니다. 이제 그래프가 거짓말을 합니다 — 한 사람의 이력에 두 사람의 사실이 섞입니다. 조용하고, 그래서 위험합니다.
• 미병합(under-merge). IBM Corp, International Business Machines, IBM Corporation을 세 노드로 둡니다. 쿼리는 셋 중 하나만 맞히고 나머지 3분의 2를 놓칩니다.

임베딩은 여기서 큰 도움이 됩니다. 밀집 벡터는 문자열이 겹치지 않아도 의미로 잇습니다 — 위 IBM 세 표기를 "without a single explicit rule" 하나로 모을 수 있습니다. 하지만 임베딩만으로는 부족합니다. 규칙 기반도, 순수 LLM도 웹 스케일에서는 혼자 못 버팁니다. 실전은 블로킹 + 유사도 매칭 + 확률/ML 분류 + 전역 일관성 검증의 조합입니다.

여기서 정직해야 할 부분이 하나 있습니다. 많은 도구가 이 단계를 대신해 주지 않습니다. 예컨대 GraphRAG의 기본 파이프라인은 이름이 정확히 같은 멘션을 합치고 설명을 요약할 뿐, IBM Corp와 IBM Corporation을 이어 주지는 않습니다. 진짜 엔티티 해소는 당신 몫입니다. FDE가 고객 프로젝트에서 시간을 가장 많이 쓰는 곳이 바로 여기입니다.

그래프 스토어에 적재 — 그리고 모든 엣지에 출처를

해소된 트리플은 이제 그래프 스토어로 들어갑니다. 프로퍼티 그래프(Neo4j 등)면 노드·엣지에 속성을 붙이고, RDF면 트리플스토어에 넣고 SPARQL로 쿼리합니다. 선택은 팀의 도구 생태계와 쿼리 패턴이 정합니다.

적재에서 절대 빼먹으면 안 되는 것이 **프로벤넌스(provenance)**입니다. 모든 엣지는 "어느 문서, 어느 청크에서 나왔는가"를 함께 실어야 합니다. GraphRAG가 문서 메타데이터를 보존하고 각 문서를 그로부터 생성된 텍스트 단위에 연결하는 것도 이 때문입니다. 출처가 붙은 그래프는 감사할 수 있고, 인용할 수 있고, 틀렸을 때 어디를 고칠지 알 수 있습니다. 출처 없는 그래프는 그럴듯한 주장 더미일 뿐입니다. 그리고 이 출처는 뒤에서 그래프 RAG가 답변에 근거를 다는 재료가 됩니다.

증분 업데이트와 스키마 드리프트 — 한 번으로 안 끝난다

고객의 문서는 멈춰 있지 않습니다. 새 계약서가 들어오고, 조직도가 바뀌고, 제품이 추가됩니다. 그래프도 따라 변해야 합니다.

전량 재구축은 쉽지만 비쌉니다. 그래서 증분 업데이트가 필요합니다. GraphRAG 1.0의 update 명령은 "computes the deltas between an existing index and newly added content and intelligently merges the updates to minimize re-indexing" — 즉 새 내용만 반영하려 애씁니다. 다만 정직한 각주가 있습니다. 새 내용이 커뮤니티 구조 자체를 흔들면 상당 부분을 다시 계산해야 하고, 최악의 경우 전량 재인덱싱과 비슷해집니다. LLM 캐시가 재실행 비용을 크게 줄여 주는 것이 그나마 위안입니다.

더 은근한 문제는 스키마 드리프트입니다. 1번 단계에서 얼려 둔 온톨로지는 시간이 지나면 현실과 어긋납니다. 새로운 엔티티 타입과 관계가 등장하고, 스키마 제약 추출기는 그것들을 조용히 흘려버립니다. 그래서 스키마는 세워 두고 잊는 것이 아니라 거버넌스가 필요한 살아 있는 자산입니다. 구축은 이벤트가 아니라 운영입니다.

품질과 증거 — 평가할 수 없으면 배포하지 마라

"그래프가 좋아 보인다"는 평가가 아닙니다. 구축된 지식 그래프는 트리플 수준에서 측정할 수 있고, 측정해야 합니다.

기본 축은 넷입니다 — 정확성(accuracy), 완전성(completeness), 일관성(consistency), 중복(redundancy). 실무에서 가장 먼저 재는 것은 앞의 둘입니다. 정밀도(precision)로 정확성을 — 뽑은 트리플 중 맞는 것의 비율 — 재고, 재현율(recall)로 완전성을 — 있어야 할 트리플 중 뽑힌 것의 비율 — 잽니다. 골드 표본을 손으로 만들어 엣지 단위로 대조하는 것이 가장 정직한 출발점이고, 링크 예측 기반 지표처럼 골드 없이 자동으로 품질을 재는 방법도 있습니다.

그리고 평가와 신뢰의 접점에 다시 프로벤넌스가 있습니다. 각 값에 출처 스팬을 붙여 두면(attribution) 환각을 걸러 낼 수 있고 — 근거를 못 대는 트리플은 의심하면 됩니다 — 동시에 최종 사용자가 답을 검증할 수 있습니다. 평가 파이프라인과 프로벤넌스는 나중에 붙이는 장식이 아니라, 그래프를 신뢰할 수 있게 만드는 유일한 방법입니다.

정직한 비용 — 어디서 깨지는가

정리하면 비용은 이렇게 분포합니다.

• 추출은 청크 수에 선형입니다. 눈에 보이고, 예산을 세울 수 있고, 캐시가 듣습니다. 가장 쉬운 단계입니다.
• 엔티티 해소는 긴 꼬리입니다. 80%는 자동화되지만 나머지 20%가 도메인 지식과 수작업을 요구하고, 품질의 대부분이 여기서 결정됩니다.
• 커뮤니티 요약(GraphRAG류)은 스케일이 커지면 추출만큼, 때로는 그 이상 비쌉니다. 모든 커뮤니티마다 LLM 리포트를 생성하기 때문입니다.
• 증분 업데이트는 공짜가 아니고, 최악의 경우 전량 재구축으로 퇴화합니다.

데모가 보여 주는 것은 첫 줄뿐입니다. 나머지는 데모에 나오지 않고, 그래서 견적에서 빠지고, 그래서 프로젝트가 늦어집니다.

마치며

FDE의 렌즈로 보면 문서를 그래프로 바꾸는 일은 대략 20%가 추출이고 80%가 해소·평가·프로벤넌스·운영입니다. 실행(추출)은 값싸지는 중이고 — LLM이 대신해 줍니다 — 값이 남는 곳은 판단입니다. 무엇을 노드로 볼지 정하는 스키마, 같은 것을 같다고 판정하는 해소 규칙, 틀렸음을 증명할 수 있는 평가. 이것들은 오늘의 모델이 대신 정해 주지 않는 축입니다.

한 문장으로 남긴다면 이것입니다. 스키마를 먼저, 증거를 항상. 그래프는 목적이 아니라 수단이고, 그 수단이 무엇을 위한 것인지 — 검색과 답변 — 는 그래프 RAG 편에서, 그리고 이 파이프라인을 실제로 굴리는 도구들은 지식 그래프 도구 지형 편에서 이어집니다.

참고 자료

• LlamaIndex — Property Graph Index 소개
• LlamaIndex — LLM Path Extractor 비교 (Simple / Schema / Dynamic)
• Tomaz Bratanic — Building Knowledge Graphs with LLM Graph Transformer
• Neo4j — Creating Knowledge Graphs from Unstructured Data
• Microsoft GraphRAG — Indexing 방법론
• Microsoft GraphRAG — Indexing Pipeline 개념
• Edge et al. — From Local to Global: A Graph RAG Approach (arXiv)
• Microsoft Research — Moving to GraphRAG 1.0 (증분 업데이트)
• Modern Data 101 — Entity Resolution at Scale
• Scientific Reports — 사용자 요구를 반영한 지식 그래프 평가