Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 핀이 아니라 지도가 필요하다
큰 갈림길 — 프로퍼티 그래프 vs RDF 트리플스토어
그래프 데이터베이스 — 무엇을 어디에
RDF·온톨로지 스택 — 형식 의미가 필요할 때
그래프 RAG 프레임워크 — 직접 짤까, 배터리 포함일까
벡터 + 그래프 — 임베딩의 자리
그래프를 쓰지 말아야 할 때
결정 흐름
마치며
참고 자료

들어가며 — 핀이 아니라 지도가 필요하다

지식 그래프 도구의 지형은 지난 2년 사이 폭발했습니다. 그래프 데이터베이스만 여섯 개를 진지하게 고려할 수 있고, RDF 스택은 20년 역사가 있고, 그래프 RAG 프레임워크는 매달 새로 나옵니다. 이런 글의 흔한 실패는 링크를 30개 나열하고 끝내는 것입니다. 링크 목록은 이미 충분합니다.

그래서 이 글은 지도를 그립니다. 카테고리마다 무엇에 쓰는지, 대표 도구 두세 개, 그리고 언제 무엇을 고를지를 말합니다. 이 시리즈의 실용적인 마지막 편입니다 — 왜 그래프 RAG인가, 그래프를 어떻게 짓는가, 도메인을 어떻게 온톨로지로 모델링하는가를 지나, 이제 "그래서 무엇을 쓰나"에 답합니다.

한 가지 정직한 전제: 도구는 변합니다. 이 글을 쓰는 동안에도 한 유명 임베디드 그래프 DB가 아카이브됐습니다. 그래서 도구 이름보다 고르는 기준을 오래 남도록 적었습니다.

큰 갈림길 — 프로퍼티 그래프 vs RDF 트리플스토어

무엇을 고르든, 첫 갈림길은 데이터 모델입니다. 두 가족이 있습니다.

프로퍼티 그래프는 라벨 붙은 노드와 엣지에 임의의 키-값 속성을 답니다. 형식 스키마가 필수가 아니고, 개발자 친화적이며, Cypher(그리고 2024년 ISO 표준이 된 GQL), Gremlin, GSQL로 질의합니다.

// 프로퍼티 그래프 (Cypher): 실용적, 스키마 선택적
CREATE (a:Person {name: 'Ada'})-[:WORKS_AT]->(c:Company {name: 'AE Ltd'})

RDF 트리플스토어는 (주어, 술어, 목적어) 삼항으로 저장하고, 전역 IRI로 개체를 식별하며, RDFS/OWL로 형식 온톨로지를 정의하고 논리 추론을 돌릴 수 있습니다. SPARQL로 질의하고, W3C 표준이라 조직 간 상호운용성이 강합니다.

# RDF (SPARQL): 전역 식별자, 형식 어휘, 추론 가능
SELECT ?person WHERE { ?person a :Person ; :worksAt ?org . }

정직한 기준은 이렇습니다. 대부분의 LLM·그래프 RAG 애플리케이션은 프로퍼티 그래프가 맞습니다. 의식(ceremony)이 적고, 추출한 노이즈 섞인 그래프를 다루기에 유연합니다. RDF를 꺼낼 때는 형식 의미가 필요할 때 — 여러 팀·조직이 공유하는 어휘, 논리 추론, 규제·표준 준수, 데이터 통합입니다. 온톨로지를 어디까지 형식화할지는 도메인 온톨로지 편에서 따로 다뤘습니다.

참고로 Amazon Neptune은 둘 다 지원합니다(프로퍼티 그래프는 openCypher/Gremlin, RDF는 SPARQL). 그래서 "AWS에 이미 있다"가 강한 이유가 됩니다.

그래프 데이터베이스 — 무엇을 어디에

여섯 개를 실용 기준으로 갈라 보겠습니다.

Neo4j — 사실상의 표준. Cypher, 가장 큰 생태계, 가장 성숙한 도구. 자체 호스팅 또는 관리형 AuraDB, 벡터 인덱스 내장, 그리고 뒤에 나올 1st-party neo4j-graphrag 패키지까지. 서버형 프로퍼티 그래프의 안전한 기본값입니다.
Memgraph — 인메모리, Cypher 호환. 실시간·저지연 운영 워크로드와 스트리밍 갱신에 강합니다. 2025년 AI 툴킷(SQL2Graph, Unstructured2Graph)으로 온보딩 마찰을 줄였습니다. 자주 바뀌는 데이터에 빠른 순회가 필요하면 여기.
Kùzu — 임베디드(인프로세스), "그래프판 SQLite". 컬럼형·분석 지향, Cypher, 벡터·전문 검색 내장. 노트북·프로토타입·단일 노드 분석에 이상적입니다. 정직한 주의: Kùzu Inc.는 2025년 10월 Apple에 인수(acqui-hire)되고 GitHub 저장소가 아카이브됐습니다. MIT 라이선스라 커뮤니티 포크는 이어지지만, 벤더 로드맵을 전제로 한 장기 프로덕션 의존은 신중히 판단하세요. 기술은 훌륭하되 거버넌스 불확실성을 가격에 넣어야 합니다.
ArangoDB — 멀티모델(그래프 + 문서 + 키-값). 그래프와 문서를 한 저장소에 두고 싶을 때.
Amazon Neptune — AWS 관리형. 프로퍼티 그래프와 RDF를 모두 지원하고, Neptune Analytics와 Bedrock Knowledge Bases의 GraphRAG로 이어집니다. AWS에 있고 관리 부담을 줄이고 싶으면 여기.
TigerGraph — 네이티브 병렬(MPP), GSQL. 대규모 그래프의 딥링크 분석(사기 탐지, KYC/AML, 추천)에 강합니다. 아주 크고 다중 홉 분석이 무거운 경우.

임베디드 vs 서버는 이렇게 가릅니다. 프로토타입·노트북·단일 노드라면 임베디드(Kùzu). 동시성·생태계·프로덕션이라면 서버(Neo4j). 관리형을 원하면 Neptune 또는 AuraDB.

RDF·온톨로지 스택 — 형식 의미가 필요할 때

RDF 길로 들어섰다면 도구 구성은 대체로 이렇습니다.

Protégé — 오픈소스 OWL/RDF 온톨로지 에디터의 표준(스탠퍼드). 온톨로지를 저술하는 곳입니다.
OWL / RDF / RDFS / SPARQL — W3C 표준 자체. RDF는 데이터 모델, RDFS·OWL은 스키마와 논리, SPARQL은 질의 언어.
RDFLib — 파이썬 RDF 라이브러리. 스크립팅, 작은 그래프, ETL에 적합.
Apache Jena — 자바 프레임워크. Fuseki(SPARQL 서버), TDB(트리플스토어), 추론기를 포함한 오픈소스 일꾼.
Ontotext GraphDB — 엔터프라이즈 RDF 트리플스토어. SPARQL, RDF-star, 추론, 그리고 벡터 유사도까지.
TopBraid (TopQuadrant EDG) — RDF 지식 그래프 위의 엔터프라이즈 데이터 거버넌스. EDG 8.0(2025년 2월)은 벡터 DB를 내장해 개체 정합·태깅을 돕습니다. 상업용, 거버넌스 중심.

고르는 기준: 프로토타입·파이썬이면 RDFLib. 오픈소스 프로덕션 RDF 앱이면 Jena(+Fuseki). 추론·규모가 필요한 엔터프라이즈 트리플스토어면 GraphDB(또는 Stardog). 데이터 스튜어드십 조직이면 TopBraid EDG. 온톨로지 저술은 어디서든 Protégé.

그래프 RAG 프레임워크 — 직접 짤까, 배터리 포함일까

여기서 두 축으로 나눠 보면 선택이 쉬워집니다. (1) 배터리 포함 파이프라인이냐 조립 부품이냐, (2) 배치 인덱싱이 무거우냐 가볍냐.

Microsoft GraphRAG — 배터리 포함, 배치 무거움. 전체 파이프라인을 돕니다: LLM 개체·관계 추출 → 그래프 구성 → Leiden 커뮤니티 탐지 → 커뮤니티 요약 → 로컬·글로벌 검색. "이 말뭉치 전체의 주제가 뭐냐" 같은 글로벌 질문에 특히 강하지만, 선행 LLM 인덱싱 비용이 큽니다. LazyGraphRAG(2024년 말)는 요약을 뒤로 미뤄 인덱싱 비용을 벡터 RAG 수준까지 낮추면서 글로벌 질문 품질을 지킵니다. 전체 말뭉치 종합이 필요하고 비용을 감당(하거나 Lazy로 회피)할 수 있으면 여기.
neo4j-graphrag (Python) — Neo4j 1st-party. 엔드투엔드로 KG 빌더(SimpleKGPipeline)와 리트리버(Vector, VectorCypher, Hybrid, Text2Cypher)를 제공합니다. Neo4j에 커밋했고 지원되는 경로를 원하면 여기.
LlamaIndex PropertyGraphIndex — 프레임워크 네이티브. 청크마다 추출기(kg_extractors)를 돌려 개체·관계를 붙이고, 그래프 스토어를 갈아 끼우며, 여러 리트리버를 제공합니다. 이미 LlamaIndex 안이라면.
LangChain LLMGraphTransformer — 조립 부품. 허용 노드·관계 타입을 스키마로 주면 노드·관계를 뽑아 줍니다. 파이프라인을 직접 통제하고 싶을 때.
Cognee — 에이전트 장기 기억. ECL(Extract, Cognify, Load) 파이프라인, 그래프+벡터 하이브리드, 여러 백엔드(Kùzu, Neo4j, NetworkX 등). 문서 QA가 아니라 지속되는 에이전트 메모리가 목표라면.
txtai — 경량 올인원 임베딩 프레임워크. 시맨틱 그래프(5.0, 2022~)가 임베딩으로 엣지를 자동 생성하고 그래프 경로 순회로 RAG를 합니다. 로컬에서 가볍게 주제 탐색을 하고 전용 그래프 DB가 부담이면.
Haystack — 범용 LLM·RAG 파이프라인 프레임워크(deepset). 컴포넌트로 그래프를 끼울 수는 있지만 그래프 전용은 아닙니다. 오케스트레이션 계층으로 보되, 그래프-퍼스트 도구로 기대하지는 마세요.

직접 짜기 vs 배터리 포함의 요령: 개체·관계를 내 그래프에 넣기만 하면 되면 LangChain/LlamaIndex 추출기나 평범한 LLM 호출로 충분합니다. Microsoft GraphRAG는 그 커뮤니티 요약·글로벌 질의 기계가 실제로 필요할 때만 값을 합니다.

벡터 + 그래프 — 임베딩의 자리

흔한 오해는 벡터냐 그래프냐를 양자택일로 보는 것입니다. 현대의 기본값은 하이브리드입니다.

벡터 검색은 흐릿한 의미 회상("이런 문단"), 그래프 순회는 정밀한 다중 홉 관계("X와 Y는 어떻게 연결되나", "Z가 영향을 주는 모든 것")를 담당합니다. 정석 패턴은 이렇습니다 — 노드·청크를 임베딩하고, 벡터 검색으로 진입점을 찾고, 거기서 그래프를 순회해 연결된 맥락을 끌어옵니다. neo4j-graphrag의 VectorCypherRetriever가 정확히 이 모양입니다.

그리고 요즘 그래프 DB 대부분(Neo4j, Kùzu, Memgraph, Neptune Analytics, GraphDB, TopBraid)이 벡터 인덱스를 내장합니다. 그래서 별도의 벡터 DB가 꼭 필요하지 않은 경우가 많습니다. 임베딩은 그래프를 짓는 데도 쓰입니다 — 비슷한 노드를 잇는 개체 정합(entity resolution)이 그 예이고, TopBraid EDG 8.0의 벡터 DB나 txtai의 시맨틱 그래프가 그 일을 합니다.

그래프를 쓰지 말아야 할 때

정직한 반대편 추를 답니다. 질문이 단일 홉 유사도로 풀린다면("X에 대한 문서 찾기", "이 정책 요약해 줘") 평범한 벡터 RAG가 더 간단하고, 싸고, 빠르고, 충분합니다. 그래프는 추출 파이프라인, 저장소, 스키마, 순회 로직을 더하고 — 그 하나하나가 틀릴 수 있습니다.

그래프가 값을 하는 건 이 넷 중 하나가 필요할 때뿐입니다: 다중 홉 추론, 관계 인지형 검색, 말뭉치 전반의 글로벌 종합, 설명 가능한 출처 추적. 이 중 무엇이 필요한지 이름 붙일 수 없다면, 아마 벡터 RAG가 답입니다. 검색의 기본기부터 제대로 잡는 이야기는 프로덕션 RAG 패턴에 정리했습니다.

그리고 하나 더 — 엉터리 추출 위에 세운 그래프는 그래프가 없는 것보다 나쁩니다. 구성 품질이 모든 것을 좌우합니다(그래프 구축 편 참고).

결정 흐름

한 장으로 압축하면 이렇습니다.

1. 질문에 관계가 필요한가?
   (다중 홉, "X와 Y는 어떻게 연결되나", 말뭉치 전체의 주제)
   아니오 -> 평범한 벡터 RAG. 여기서 멈춘다. 그래프를 짓지 마라.
   예     -> 계속.

2. 형식 의미가 필요한가?
   (논리 추론, 조직 간 공유 어휘, 표준·규제)
   예     -> RDF 스택: Protege(OWL)로 저술, Jena/GraphDB에 저장, SPARQL로 질의.
   아니오 -> 프로퍼티 그래프 (아래).

3. 그래프 DB 고르기:
   로컬 / 노트북 / 단일 노드       -> Kuzu (주의: 2025년 저장소 아카이브, 커뮤니티 포크)
   프로덕션 서버, 최대 생태계      -> Neo4j
   실시간 / 스트리밍 갱신          -> Memgraph
   AWS 관리형                      -> Amazon Neptune
   그래프 + 문서를 한 저장소에     -> ArangoDB
   초대형 병렬 딥링크 분석         -> TigerGraph

4. 그래프 RAG 계층 고르기:
   "말뭉치 전체의 주제" 종합       -> Microsoft GraphRAG (비용은 LazyGraphRAG로)
   Neo4j 커밋, 1st-party 원함      -> neo4j-graphrag
   이미 프레임워크 안             -> LlamaIndex PropertyGraphIndex / LangChain
   지속되는 에이전트 메모리        -> Cognee
   경량 / 로컬 / 주제 탐색         -> txtai 시맨틱 그래프

마치며

지도이지 핀이 아닙니다. 도구는 흔들립니다 — Kùzu가 올해의 증거입니다. 흔들리지 않는 것은 질문입니다. 프로퍼티냐 RDF냐는 유행이 아니라 의미론의 질문이고, 그래프냐 벡터냐는 하이프가 아니라 관계의 질문입니다. 그 둘에 먼저 답한 뒤에 도구를 고르세요.

이것으로 시리즈의 실용적 끝에 닿았습니다. 왜 그래프 RAG인가로 이유를, 그래프 구축으로 짓는 법을, 도메인 온톨로지로 모델링을, 그리고 이 글로 도구를 다뤘습니다. 그래프가 과할 때를 위한 프로덕션 RAG 패턴까지 곁에 두면 지도는 충분합니다.

가장 정직한 마지막 한 줄: 최고의 그래프 프로젝트는 대개 질문에 답하는 가장 작은 것이고 — 때로는 그게 그래프가 아예 없는 것입니다.