Study Material

온톨로지 &
지식 그래프

데이터 구조화의 끝판왕
AI가 "이해"하는 데이터를 만드는 법

4단계 온톨로지 스펙트럼
3.4x KG 기반 LLM 정확도 향상
86% GraphRAG 멀티홉 정확도

온톨로지와 지식 그래프란?

데이터에 "의미"를 부여하는 두 가지 핵심 개념

O

온톨로지 (Ontology)

도메인의 개념과 관계를 형식적으로 정의한 체계. "고객은 주문을 하고, 주문은 제품을 포함하고, 제품은 카테고리에 속한다"를 기계가 이해할 수 있는 형태로 표현한다. 온톨로지는 스키마다 — 실제 데이터가 아니라 데이터의 구조와 규칙을 정의한다.

K

지식 그래프 (Knowledge Graph)

온톨로지를 기반으로 실제 데이터를 노드와 엣지로 연결한 그래프 구조. 온톨로지가 "고객은 주문을 한다"라는 규칙이면, 지식 그래프는 "김철수가 주문#1234를 했다"라는 실제 사실이다. 지식 그래프는 인스턴스 데이터다.

쉽게 말하면: 온톨로지는 빈 엑셀의 열 제목(스키마)이고, 지식 그래프는 그 엑셀에 채워진 실제 데이터다. 하지만 엑셀과 달리 행과 열이 아니라 그래프(노드와 엣지)로 표현되기 때문에 복잡한 관계를 자연스럽게 표현할 수 있다.

관계형 DB와 뭐가 다른가?

관계형 DB는 테이블과 JOIN으로 관계를 표현한다. 관계가 깊어지면 JOIN이 복잡해지고 성능이 떨어진다. 지식 그래프는 관계 자체를 일급 시민으로 저장하기 때문에, "3단계 떨어진 관계"를 찾는 것이 자연스럽고 빠르다. AI가 "김철수의 동료가 구매한 제품의 카테고리"를 찾아야 할 때, JOIN 5개보다 그래프 순회가 빠르다.

왜 AI에 중요한가?

벤치마크에 따르면, 지식 그래프 없이 LLM을 사용하면 정확도 16.7%, 지식 그래프를 연결하면 56.2% — 3.4배 향상. 엔티티가 10개 이상인 복잡한 질문에서는 벡터 검색 정확도가 0%로 떨어지지만, 지식 그래프 기반은 70% 이상을 유지한다.

온톨로지 스펙트럼: 단순에서 복잡으로

처음부터 OWL을 만들 필요는 없다 — 단계적으로 깊이를 더한다

Glossary

단어와 정의만 있는 목록

시작점

Taxonomy

계층 구조 (is-a 관계). 예: 동물 > 포유류 > 개

분류

Thesaurus

동의어, 관련어, 상위어/하위어

관계

Ontology

속성, 제약, 논리 규칙, 추론 가능

추론
실전 가이드: 프로덕션 경험에 따르면, 노드 타입 3~7개, 관계 타입 5~15개가 최적이다. 5개 클래스 + 10개 속성의 단순한 온톨로지가, 50개 클래스의 깊은 상속 구조보다 더 정확하게 추출된다. 복잡할수록 좋은 게 아니다.

트리플: 지식 그래프의 기본 단위

모든 지식 그래프는 주어-술어-목적어 트리플로 구성된다

김철수 (Subject)
주문했다 (Predicate)
주문#1234 (Object)
주어(누가) → 술어(무엇을 했다) → 목적어(무엇에 대해)
주문#1234
포함한다
MacBook Pro
MacBook Pro
속한다
노트북 카테고리
트리플을 연결하면 그래프가 된다 — "김철수 → 주문 → MacBook Pro → 노트북 카테고리"
이것이 관계형 DB와 근본적으로 다른 점이다. 관계형 DB에서 "김철수가 주문한 제품의 카테고리"를 찾으려면 고객 테이블 → 주문 테이블 → 주문상품 테이블 → 제품 테이블 → 카테고리 테이블을 JOIN해야 한다. 지식 그래프에서는 노드를 따라가기만 하면 된다. 관계가 깊어질수록 이 차이는 극적으로 커진다.

GraphRAG: 지식 그래프 + RAG

벡터 검색만으로 한계에 부딪혔다면 — 그래프가 답일 수 있다

멀티홉 추론 (복잡한 질문) GraphRAG 86% vs Vector 32%
GraphRAG 86%
Vector 32%
수치 추론 GraphRAG 100% vs Vector 50%
GraphRAG 100%
Vector 50%
집계 쿼리 (스키마 기반) GraphRAG 90% vs Vector 0%
GraphRAG 90%
Vector 0%
단순 의미 검색 (문서 찾기) 비슷 — 그래프 오버헤드만 추가
GraphRAG ~동등
Vector ~동등

출처: FalkorDB, TianPan, Lettria

질문 유형 Vector RAG GraphRAG 추천
"X에 대한 문서 찾아줘" 적합 과잉 Vector
"A와 B의 관계가 뭐야?" 부족 적합 Graph
"지난달 X의 총 매출은?" 불가 적합 Graph
"A가 B에게 미친 영향의 경로?" 불가 적합 Graph
"이 주제의 최신 논문 요약해줘" 적합 불필요 Vector
80/15/5 법칙: 2026년 벤치마크 합의에 따르면, 기업 쿼리의 약 80%는 단순 의미 검색(Vector), 15%는 구조화된 추론(Graph), 5%는 완전한 에이전트 처리가 필요하다. 둘 중 하나를 고르는 것이 아니라 하이브리드 라우터가 답이다.

실전 도구 생태계

지식 그래프를 직접 만들어보기 위한 도구들

Graph DB

Neo4j

가장 널리 사용되는 그래프 DB. Cypher 쿼리 언어, 데스크톱 앱으로 빠른 시작 가능. "Ontologies as a First-Class Citizen" 로드맵 (2026).
Cypher · Java · 커뮤니티 최대
Graph DB

FalkorDB

실시간 AI 특화 그래프 DB. 희소 행렬 곱셈 기반 순회로 초저지연. Redis 모듈로 동작. GraphRAG SDK로 자동 온톨로지 생성 지원.
C · Redis Module · Docker 한 줄 시작
Framework

Graphiti (by Zep)

시간 인식 지식 그래프 프레임워크. AI 에이전트 메모리 특화. Neo4j, FalkorDB, Amazon Neptune 등 다양한 DB 지원. GitHub 45k+ 스타.
Python · 멀티에이전트 · 실시간
Framework

LangChain + LangGraph

LangChain 생태계에서 GraphRAG 파이프라인 구축. Neo4j, FalkorDB 통합. 벡터 + 그래프 하이브리드 검색 지원.
Python/JS · 가장 넓은 통합
Platform

TrustGraph

Context Operating System. OntologyRAG 지원 — 온톨로지 기반 컨텍스트 그래프를 자동 구축하고 관리.
오픈소스 · OntologyRAG
Platform

GraphRAG SDK (FalkorDB)

비정형 데이터에서 자동으로 온톨로지를 감지하고 지식 그래프를 생성. 수동/자동 온톨로지 관리 모두 지원.
Python · 자동 온톨로지 · 프로덕션급

실전: 어디서부터 시작할까

온톨로지를 처음 만드는 사람을 위한 단계별 접근

1

DB 스키마에서 시작하라

연구에 따르면, DB 스키마에서 온톨로지를 추출하면 텍스트에서 추출한 것과 성능이 비슷하면서 비용은 훨씬 낮다. DDL(테이블 정의)을 LLM에게 주면 클래스, 속성, 관계를 자동 추출할 수 있다. 이미 있는 데이터의 구조를 활용하라.

2

작게 시작하라

노드 타입 3~7개, 관계 타입 5~15개로 시작. 50개 클래스의 완벽한 온톨로지보다 5개 클래스의 정확한 온톨로지가 낫다. 필요에 따라 점진적으로 확장.

3

하이브리드로 가라

벡터 검색을 버리고 그래프로 갈 필요 없다. 80%의 쿼리는 벡터 검색으로 충분하다. 복잡한 관계 추론이 필요한 15%에 그래프를 쓰고, 나머지는 벡터에 맡겨라.

4

엔티티 해소(Entity Resolution)에 투자하라

초기 GraphRAG 구현에서 가장 큰 문제: "John Doe, 45" vs "John Doe, age 45", "Type 2 Diabetes" vs "T2D". 같은 엔티티를 다른 이름으로 인식하면 그래프가 무너진다. 동의어 사전과 정규화가 핵심.

ROI 참고: 2024~2025년 프로덕션 사례에서 지식 그래프 도입 조직은 300~320% ROI를 달성했다. 단, 이건 데이터가 준비된 조직의 이야기다. 데이터 구조화(AI-Ready Data)가 먼저다.