LabHub

블로그

지식 그래프 도구·프레임워크 지도 — 무엇을 언제 고르나

2026-07-15 · 18 분 읽기 · #tools#knowledge-graph#graph-rag#ontology#frameworks

한국어English日本語中文

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

지식 그래프 도구의 지형은 지난 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에 이미 있다"가 강한 이유가 됩니다.

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

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

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

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

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

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

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

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

직접 짜기 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 패턴까지 곁에 두면 지도는 충분합니다.

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

참고 자료

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다