온톨로지, Knowledge Graph, Graph RAG

🏷️ 정보 LLM 머신러닝 headliner

그래프, 그래프 DB, Knowledge Graph, 온톨로지, Graph RAG, Second Brain. 이름은 비슷한데 실제로는 결이 꽤 다른 개념들입니다. 각자 무엇이고, 어디가 다르고, 어디에 쓰는지를 한 번 줄세워보겠습니다.

그래프

먼저 가장 기본은 자료구조로서의 그래프입니다.

노드(vertex)와 엣지(edge)로 이루어진 수학적 객체. 그게 전부입니다. 의미도, 제약도, 추론도 없습니다. 페이스북 친구 관계도 그래프이고, 도로망도 그래프이고, 함수 호출 그래프도 그래프입니다.

그래프 자체에는 이 노드는 사람이다, 이 엣지는 친구관계다 같은 의미가 없습니다. 그저 점과 선뿐입니다. 의미는 그래프를 다루는 쪽이 따로 정의해야 합니다.

그래프 DB

Neo4j, Amazon Neptune, ArangoDB 같은 그래프 데이터베이스는 그래프 형태의 데이터를 저장하고 쿼리하기 위한 시스템입니다.

관계형 DB가 JOIN으로 관계를 표현한다면, 그래프 DB는 관계 자체를 일급 시민(first-class citizen)으로 다룹니다. "친구의 친구의 친구"같은 다단계 관계 쿼리가 매우 빠릅니다. 관계형이라면 JOIN을 3~4번 걸어야 하는 쿼리가 그래프 DB에서는 인덱스 한 번 타고 끝납니다.

쿼리 언어로는 Cypher(Neo4j), Gremlin(Apache TinkerPop), SPARQL(RDF 계열) 등이 있습니다.

MATCH (p:Person {name: "Alice"})-[:FRIEND*1..3]-(friend)
RETURN friend

여기서 중요한 점, 그래프 DB 자체는 의미 체계를 강제하지 않습니다. 노드에 Person이라는 라벨을 붙이든 Banana라고 붙이든 DB는 신경 쓰지 않습니다. 의미는 사용자가 알아서 챙기는 겁니다. 라벨은 그냥 문자열이고, 관계 타입도 그냥 문자열입니다.

Knowledge Graph

Knowledge Graph(KG)는 그래프에 의미를 입힌 것입니다.

노드는 실세계의 개체(entity)를 나타내고, 엣지는 의미 있는 관계(relation)를 나타냅니다. 예를 들면 이런 식이죠.

(Albert Einstein) --[born_in]--> (Ulm)
(Ulm) --[located_in]--> (Germany)
(Albert Einstein) --[discovered]--> (General Relativity)

Google Knowledge Graph, Wikidata, DBpedia가 대표적입니다. 구글 검색창에 "아인슈타인"이라고 치면 오른쪽에 뜨는 정보 박스 같은 것이 KG가 일하는 모습입니다.

KG는 보통 다음을 포함합니다.

엔티티 타입 (Person, Place, Concept 등)
관계 타입 (born_in, located_in 등)
메타데이터 (출처, 시간, 신뢰도 등)

KG는 의미를 입혔지만, 얼마나 엄밀하게 입혔는지는 천차만별입니다. 위키데이터처럼 비교적 형식적인 것도 있고, 회사 내부 KG처럼 느슨한 것도 있습니다. 이 얼마나 형식적인가의 끝판왕이 바로 온톨로지입니다.

온톨로지

온톨로지(Ontology)는 한마디로 형식 논리로 기술된 개념 체계입니다. 컴퓨터 과학에서는 Tom Gruber가 1993년에 내린 정의가 자주 인용됩니다.

An ontology is an explicit specification of a conceptualization.

KG와 비교했을 때 온톨로지의 결정적 차이는 세 가지입니다.

1. T-Box와 A-Box의 분리

Description Logic에서 나온 개념입니다.

T-Box (Terminological Box) : 개념과 관계의 정의. "Person이라는 개념이 존재한다", "born_in이라는 관계는 Person을 Place로 매핑한다". 스키마에 해당합니다.
A-Box (Assertional Box) : 실제 인스턴스 데이터. "Albert Einstein은 Person이다", "Albert Einstein은 Ulm에서 태어났다".

KG에서는 이 둘이 종종 뒤섞입니다. 그냥 한 그래프 안에 클래스 노드와 인스턴스 노드가 함께 들어가 있는 경우가 많죠. 하지만 온톨로지에서는 명확하게 분리합니다. 왜냐하면 T-Box는 추론의 근거가 되고, A-Box는 추론의 대상이 되기 때문입니다. 이 둘이 섞이면 무엇이 정의이고 무엇이 데이터인지 알 수 없어서 추론이 망가집니다.

2. 관계마다 domain과 range가 정의됨

born_in이라는 관계가 있다고 합시다. 온톨로지에서는 이렇게 씁니다.

:born_in rdf:type owl:ObjectProperty ;
         rdfs:domain :Person ;
         rdfs:range :Place .

이 말은 "born_in의 출발지는 반드시 Person이고, 도착지는 반드시 Place다"라는 제약입니다. 만약 누가 (Banana) --[born_in]--> (Sky)라는 데이터를 넣으면, Reasoner가 이 데이터로부터 "그러면 Banana는 Person이고 Sky는 Place다"라고 추론합니다. 도메인 정의와 모순되면 일관성 위반으로 잡아냅니다.

KG는 이런 제약을 강제하지 않는 경우가 많습니다. 그냥 데이터로 들어가버리고 끝. "당신이 알아서 잘 넣으세요"인 거죠.

3. Reasoner로 추론과 일관성 검사가 가능

Reasoner는 온톨로지의 형식 정의를 보고 논리적으로 따라오는 결론을 자동으로 도출하는 도구입니다. 대표적으로 HermiT, Pellet, FaCT++ 등이 있습니다.

가장 단순한 예 — 하위 클래스 추이성(transitivity):

:Mammal rdfs:subClassOf :Animal .
:Human rdfs:subClassOf :Mammal .

<!-- -->
# Reasoner가 자동 추론:
:Human rdfs:subClassOf :Animal .

좀 더 복잡한 예 — 역관계(inverse):

:hasParent owl:inverseOf :hasChild .
:Alice :hasParent :Bob .

<!-- -->
# Reasoner가 자동 추론:
:Bob :hasChild :Alice .

함수형 속성(functional property)도 있습니다.

:hasBiologicalMother rdf:type owl:FunctionalProperty .
:Alice :hasBiologicalMother :Carol .
:Alice :hasBiologicalMother :Diana .

<!-- -->
# Reasoner의 추론: Carol과 Diana는 동일 인물 (owl:sameAs)

핵심은 LLM이 그럴듯하게 말하는 게 아니라, 정의된 규칙에 따라 항상 같은 결론이 나온다는 점입니다. 결정가능(decidable)한 OWL DL 같은 프로파일을 쓰면, 무엇이 참인지 알고리즘적으로 판정할 수 있습니다. 같은 입력에는 항상 같은 출력이 나옵니다.

이게 KG와 온톨로지를 가르는 진짜 선입니다. KG는 사실의 모음이고, 온톨로지는 '사실 + 사실에서 새로운 사실을 끌어내는 규칙'입니다.

Graph RAG: 그래프와 LLM의 결합

Graph RAG는 비교적 최근에 뜬 개념입니다. Microsoft GraphRAG가 2024년에 공개되며 본격적으로 화제가 됐죠.

구성은 대략 이렇습니다.

문서에서 LLM으로 엔티티와 관계를 추출
추출한 것을 그래프로 구성 (보통 Neo4j 같은 그래프 DB에 저장)
사용자 질문이 들어오면 그래프에서 관련 노드·엣지를 찾음
찾은 컨텍스트를 LLM에 넘겨 답변 생성

기존 Vector RAG가 임베딩 유사도로만 검색한다면, Graph RAG는 그래프 구조를 활용해 다단계 관계를 따라가는 검색을 합니다. "X가 누구의 멘토였고, 그 멘토가 어떤 분야에서 일했고..." 같은 다단계 질문에 강합니다. Vector RAG는 이런 질문에서 보통 첫 단계 정보만 끌어오고 끝나는데, Graph RAG는 엣지를 따라 추가 컨텍스트를 끌어올 수 있습니다.

Graph RAG의 "추론"은 LLM의 자연어 추론입니다. 형식 논리 기반 Reasoner가 돌아가는 게 아닙니다. 그래프는 검색 효율을 위해 쓰는 자료구조이고, 의미 해석은 LLM이 합니다.

Graph RAG가 사용하는 그래프는 보통 KG 수준입니다. 가끔 도메인에 따라 가벼운 온톨로지 스키마를 얹기도 하지만, 풀 OWL 온톨로지를 돌리는 경우는 드뭅니다. 무겁고, LLM의 엔티티 추출 정확도가 들쭉날쭉이라 일관성 검사가 무더기로 실패하기 때문이죠. 그래서 Graph RAG는 보통 "느슨한 KG + LLM"의 조합으로 운영됩니다.

Second Brain

Second Brain은 위에서 다룬 것들과는 결이 완전히 다른 개념입니다.

Tiago Forte가 2022년 "Building a Second Brain" 책으로 대중화시킨 개인 지식 관리(Personal Knowledge Management) 방법론입니다. 뿌리는 더 거슬러 올라가 Niklas Luhmann의 Zettelkasten에 닿습니다. 루만은 6만 개가 넘는 종이 카드를 위키링크처럼 서로 참조시키며 평생 70권의 책과 400편 가까운 논문을 썼습니다.

도구로는 Obsidian, Roam Research, Logseq, Notion 등이 자주 쓰입니다. 노트 사이를 [위키링크](059ebd45.html)로 연결하면, 시간이 지나면서 노트들이 그래프처럼 연결됩니다. Obsidian의 그래프 뷰가 보여주는 그것입니다.

Second Brain은 형식 논리가 아닙니다. 노드(노트)와 엣지(링크)에 의미가 있긴 하지만, "domain/range"도 없고, "Reasoner"도 없고, T-Box/A-Box 구분도 없습니다. 목적이 다릅니다. 개인의 학습·창작·기억 보조가 목적이지, 시스템 간 의미 통합이 목적이 아닙니다.

가끔 "내 Second Brain이 내 개인 온톨로지다"라고 표현하는 사람들이 있는데, 비유로는 멋있지만 기술적으로는 부정확합니다. 형식 체계도, 추론기도, 일관성 검사도 없기 때문입니다. Second Brain은 인간의 사고를 보조하는 도구이지, 기계가 추론할 대상이 아닙니다.

한 줄로 비교

개념	본질	형식 논리	추론 방식	대표 도구
그래프	자료구조	없음	없음	—
그래프 DB	저장·쿼리 시스템	없음	그래프 알고리즘	Neo4j, Neptune
Knowledge Graph	의미를 입힌 그래프	부분적	제한적	Wikidata, Google KG
온톨로지	형식 논리 체계	OWL/RDF/DL	Reasoner 기반	Protégé, HermiT
Graph RAG	LLM + 그래프 검색	없음	LLM 자연어 추론	Microsoft GraphRAG
Second Brain	개인 지식 관리	없음	사람의 사고	Obsidian, Roam

어디에 무엇을 쓸 것인가

각자 잘 맞는 자리가 있습니다.

그래프 DB

관계가 핵심인 데이터를 빠르게 다룰 때. 사기 탐지, 추천 시스템, 네트워크 분석, 소셜 그래프 등.

Knowledge Graph

검색·QA·추천 등에서 도메인 지식을 구조화해 활용할 때. 구글 검색의 사이드 패널, 기업 내부 직원·고객·제품 정보 통합, 엔터프라이즈 검색 등.

Graph RAG

LLM 기반 시스템에서 다단계 관계나 글로벌 컨텍스트가 중요할 때. 긴 문서 컬렉션에 대한 QA, 도메인 특화 챗봇, 사례 기반 분석 등.

온톨로지

의미가 절대 흔들리면 안 되고, 시스템 간 의미 통합이 필요하며, 논리적 일관성이 중요한 영역. 의료(SNOMED CT), 생명과학(Gene Ontology), 법률, 항공·국방, 산업 표준 통합 등. 진짜 온톨로지가 돌아가는 곳들은 보통 학계 또는 규제 산업입니다.

Second Brain

개인의 학습·창작·기억 보조. 일하면서 떠오른 생각, 읽은 책의 메모, 프로젝트 아이디어를 연결해두는 용도. 글 쓰는 사람, 연구자, 학생에게 특히 잘 맞습니다.

서로가 서로를 대체하는 관계가 아닙니다. 위계가 있는 것도 아닙니다. 온톨로지가 KG보다 더 좋은 게 아니라, 다른 일을 합니다. 의료 코드 통합에 Second Brain을 쓸 수 없고, 개인 노트에 OWL 온톨로지를 적용할 필요가 없습니다.

요즘 온톨로지라는 단어가 부풀려 쓰이는 데는 몇 가지 이유가 있어 보입니다.

그래프 기반 시스템이 많아졌습니다. LLM 붐과 함께 Graph RAG가 뜨고, 기업들이 너도나도 KG를 만들기 시작했습니다. 그러다 보니 "그래프 = 온톨로지"라는 잘못된 등치가 퍼졌습니다.

온톨로지가 더 있어 보입니다. "Knowledge Graph 구축했다"보다 "온톨로지 구축했다"가 더 학술적·전문적으로 들립니다. gptaku_ai가 정확히 짚었듯이요. 같은 결과물도 이름을 어떻게 부르느냐에 따라 인상이 달라집니다.

진짜 온톨로지 작업이 무엇인지 아는 사람이 줄었습니다. 시맨틱 웹이 2000년대 중반에 한창 떴다가 가라앉았고, 그 시기의 OWL·Description Logic 지식이 산업계에서 휘발됐습니다. 학교에서 가르치는 곳도 줄었고요. 그러다 보니 "이게 진짜 온톨로지냐 아니냐"를 따질 사람도 줄었습니다. 어떤 시스템을 진짜 온톨로지라고 부르고 싶다면 이런 질문에 대답할 수 있어야 합니다.

[ ] 도메인의 개념 체계(T-Box)를 형식적으로 정의했는가? : 클래스 계층, 관계의 종류, 제약조건이 명시되어 있는가.
[ ] T-Box와 A-Box가 분리되어 있는가? : 스키마(개념 정의)와 인스턴스(실제 데이터)가 구분되는가.
[ ] 관계마다 domain과 range가 정의되어 있는가? : 어떤 타입에서 어떤 타입으로 가는 관계인지 명시되어 있는가.
[ ] Reasoner로 일관성 검사와 추론을 돌려봤는가? : HermiT, Pellet, FaCT++ 같은 도구로 실제 추론이 동작하는가.
[ ] Inference 예시를 구체적으로 설명할 수 있는가? : "이 규칙들로부터 이런 새로운 사실이 도출된다"를 말할 수 있는가.

용어를 정확히 쓰는 일은 그 자체로는 사소합니다. 하지만 누적되면 분야 전체의 의사소통이 흐릿해집니다. "온톨로지를 만들었다"는 말을 들었을 때, 그게 OWL 기반 형식 체계인지 그냥 라벨링된 그래프인지를 매번 다시 물어봐야 한다면, 그건 모두에게 비효율입니다.