온톨로지란 무엇인가
AI 시대, 데이터에 의미를 부여하는 구조

온톨로지란 무엇인가

온톨로지는 데이터의 형식(format)이 아니라, 그 안에 담긴 의미(semantics)를 형식 논리로 다루는 구조입니다.

온톨로지는 한 마디로 "세상을 어떻게 쪼개고, 그것들이 서로 어떻게 연결되는가"를 기계가 이해할 수 있는 형태로 적어둔 약속입니다. 단순한 분류표(taxonomy)가 아니라 클래스·인스턴스·관계·제약·추론 규칙까지 함께 다룬다는 점이 핵심입니다.

학습 체크리스트

• 온톨로지가 단순 데이터 모델이 아닌 "의미 구조"라는 점을 이해했다
• LLM 시대에 온톨로지가 다시 주목받는 이유를 한 문장으로 말할 수 있다
• 이 자료가 무엇을 가르치고 무엇을 가르치지 않는지 인지했다

온톨로지가 빛나는 4가지 현장 — 여러분이 합류할 곳

정의는 추상적이지만, 현장은 구체적입니다. 이 자료가 끝날 때 "아, 이건 그래프로 풀어야 하는 문제구나"를 첫 5분 안에 알아채는 사람이 되는 것 — 그것이 이 자료의 목표입니다.

MATCH path = (sender)-[:TRANSFERS*1..6]->(receiver)
WHERE sender.ubo = receiver.ubo     // ① 송금자와 수취자의 실소유주가 같음 (자기 돈 돌리기)
   OR receiver.risk > 0.9            // ② 또는 수취자 위험점수가 0.9 초과 (제재대상·PEP 등)
RETURN path                       // 1~6단계 자금흐름 경로를 통째로 반환

6개 챕터로 보는 학습의 큰 그림

전반부 1~3장에서는 "왜 온톨로지인가, 무엇인가"를 다루고, 후반부 4~6장에서는 "이것으로 무엇을 어떻게 할 것인가"를 풀어갑니다.

LLM의 세 가지 벽 vs 온톨로지의 세 가지 답

기업 환경에서 LLM을 그대로 쓸 때 어떤 한계에 부딪히는지, 그리고 온톨로지 기반 지식그래프가 그 빈자리를 어떻게 메우는지 살펴봅니다.

벡터 RAG만으로는 부족하다

벡터 검색은 임베딩 공간의 유사도(similarity)를 기준으로 답을 찾지만, 그것이 곧 도메인의 의미(semantics)와 일치한다는 보장은 없습니다.

"같은 회사인데 왜 매출 숫자가 다르지?"

조직 내에서 의미가 합의되지 않으면 같은 데이터도 부서마다 다르게 해석돼 결국 데이터가 거짓말을 하게 됩니다. 이 의미 불일치 문제를 푸는 것이 온톨로지의 본질적 역할입니다.

온톨로지는 이런 문제를 푸는 도구입니다. 1993년 컴퓨터과학자 Tom Gruber는 "진짜 작동하는 온톨로지"는 4가지 조건을 동시에 만족해야 한다고 했습니다 — 그 4가지가 어떻게 위 매출 충돌을 해결하는지 봐 보겠습니다.

매출 정의를 "어떻게" 적어둘 것인가 — 4개 빌딩블록

레고 4종류만 있으면 가족·조직·금융·의료 어떤 도메인도 조립할 수 있습니다.

조립 예시 — 매출 한 건을 4 빌딩블록으로 표현

아래는 "Q3 계약 한 건이 매출 1.2억을 만들어내고, 11월 15일에 입금됐다"를 4개 빌딩블록만으로 표현한 모습입니다.

@prefix : <http://pp.com/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# ① Class 선언 — "이런 종류가 있다"
:Contract  a owl:Class .
:Revenue   a owl:Class .
:Payment   a owl:Class .

# ② Instance — "구체적인 한 사례"
:Q3계약001  a :Contract  ;
            :amount "120000000"^^xsd:int ;     # ④ Datatype: 금액
            :contractDate "2026-09-30"^^xsd:date ;
            :generates :Q3매출001 .            # ③ Object: 매출과 연결

:Q3매출001  a :Revenue   ;
            :recognizedAt "2026-09-30"^^xsd:date ;  # ④ 데이터팀 기준(수주)
            :paidBy :Q3입금001 .               # ③ 입금 인스턴스와 연결

:Q3입금001  a :Payment   ;
            :paymentDate "2026-11-15"^^xsd:date .   # ④ 재무팀 기준(수금)

가족 관계도로 이해하는 온톨로지

익숙한 도메인으로 클래스·관계·상속·추론을 한눈에 — 토글하며 확인하세요.

초록 화살표 = 명시한 사실 / 노란 점선 = OWL 공리(transitive·symmetric)에 의해 자동 도출된 사실.

# 가족 관계 (그림과 일치)
:Sue  a :Female .
:Mia  a :Female ; :hasParent :Sue .
:Tom  a :Male   ; :hasParent :Mia ; :isMarriedWith :Yuna .
:Yuna a :Female .
:Ken  a :Male   ; :hasParent :Tom ; :hasParent :Yuna .

# 공리(axiom) — 추론 엔진이 점선 화살표를 자동으로 만들어냄
:isMarriedWith a owl:SymmetricProperty .   # 양방향 자동 도출
:hasAncestor   a owl:TransitiveProperty .  # A→B, B→C ⇒ A→C 자동 도출
:hasParent     rdfs:subPropertyOf :hasAncestor .

RDF Triple — 지식의 최소단위

모든 사실은 (Subject, Predicate, Object) 한 줄로 표현된다.

하나의 Triple = (:Tom, :worksAt, :PinetreePartners) — 사실 한 줄의 최소 단위

@prefix : <http://pp.com/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# (S, P, O) 트리플들
:Tom :worksAt :PinetreePartners ;
     :age "34"^^xsd:int ;
     :hasSkill :Python , :Cypher .  # 한 주어에 여러 객체

분류는 시작일 뿐 — 관계와 제약이 들어와야 진짜 모델

Taxonomy에서 Ontology로 진화하는 흐름은, 거의 모든 지식그래프 프로젝트가 실무에서 거치는 표준적인 발전 경로입니다.

@prefix : <http://x/> .
:Mammal rdfs:subClassOf :Animal .
:Tiger  rdfs:subClassOf :Mammal .
:Deer   rdfs:subClassOf :Mammal .
:Rabbit rdfs:subClassOf :Mammal .
:Eagle  rdfs:subClassOf :Bird .

@prefix :    <http://x/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
# (위 Taxonomy의 subClassOf 트리플은 그대로 유지)
:preysOn a owl:ObjectProperty .
:Tiger :preysOn :Deer .
:Eagle :preysOn :Rabbit .

RDB는 왜 한계에 부딪히는가

RDB에서는 관계를 추적할 때마다 JOIN이 누적되기 때문에, "3홉 관계"를 묻는 순간 쿼리 비용이 기하급수적으로 폭발합니다.

Q. 거래 A → B → C → … → A 처럼 3홉 안에 자기 자신으로 돌아오는 자금세탁 패턴을 찾으려면?

-- RDB: 3홉 self-loop 탐지 (다중 JOIN)
SELECT t1.src
FROM transfers t1
JOIN transfers t2 ON t1.dst = t2.src
JOIN transfers t3 ON t2.dst = t3.src
WHERE t3.dst = t1.src;

// Graph DB (Cypher): 가변 길이 경로 한 줄
MATCH (a)-[:TRANSFERS*1..3]->(a)
RETURN a;

Graph DB — 관계를 노드처럼 직접 다루는 모델

그래프 DB에서는 노드와 엣지 자체가 데이터의 기본 단위이며, 관계 질의는 JOIN이 아니라 그래프 탐색(traversal)으로 처리됩니다. 엣지가 노드와 동등하게 속성·타입을 가질 수 있어, 관계 자체에 정보를 매달 수 있습니다.

// 커피를 산 사용자
MATCH (u:User)-[:PURCHASED]->(p:Product {category:'Coffee'})
RETURN u.name, p.name;

// 친구의 친구가 산 상품 (2홉)
MATCH (me:User {id:'tom'})
      -[:FRIEND]->(:User)
      -[:FRIEND]->(:User)-[:PURCHASED]->(p)
RETURN DISTINCT p.name LIMIT 10;

RDF (시맨틱 그래프) vs LPG (속성 그래프)

RDF와 LPG는 서로 경쟁하는 모델이 아니라 보완 관계에 있으며, 의미 표현력과 분석 효율 사이의 트레이드오프를 각각 다른 방향에서 해결합니다.

@prefix : <http://example.org/> .
@prefix schema: <http://schema.org/> .

:Tom  a            schema:Person ;
      schema:name  "Tom Lee" ;
      :worksAt     :Pinetree .
:Pinetree a        schema:Organization .

// 노드 + 엣지 + 속성 한 번에
CREATE (t:Person {name:'Tom Lee'})
       -[:WORKS_AT {since:2021, role:'Analyst'}]->
       (p:Organization {name:'Pinetree'});

:Tom :worksAt _:b1 .         # ① 트리플1
_:b1 :org    :Pinetree ;     # ② 트리플2
     :since  "2021" ;        # ③ 트리플3
     :role   "Analyst" .     # ④ 트리플4

CREATE (t:Person {name:'Tom', age:35})
       -[:WORKS_AT {since:2021, role:'Analyst'}]->
       (o:Org    {name:'Pinetree', industry:'Cons.'});

SPARQL vs Cypher

트리플 패턴(선언적·집합적) vs 그래프 패턴(시각적·직관적) — 도메인이 선택을 결정합니다.

PREFIX : <http://pp.com/>
SELECT ?name WHERE {
  ?u :purchased ?p .
  ?p :category :Coffee .
  ?u :name ?name .
}

MATCH (u:User)
      -[:PURCHASED]->
      (p:Product {category:'Coffee'})
RETURN u.name;

온톨로지의 진짜 가치 — 추론(Inference)

명시된 사실 + 규칙 = 새로운 사실 (Asserted → Inferred)

# Asserted (입력한 사실)
:Tom :hasParent :Mia .                       ← Mia는 Tom의 부모님
:Mia :hasParent :Sue .                       ← Sue는 Mia의 부모님

# Ontology Rules (규칙)
:hasAncestor a owl:TransitiveProperty .      ← A→B, B→C 면 A→C도 성립 (이행성)
:hasParent rdfs:subPropertyOf :hasAncestor . ← 부모는 조상의 일종

# Inferred (HermiT 자동 도출)
:Tom :hasAncestor :Mia .                     ← 부모는 조상의 일종이므로
:Tom :hasAncestor :Sue .                     ← ★ Tom은 Sue의 자손 자동 추론!
:Mia :hasAncestor :Sue .                     ← 부모는 조상의 일종이므로

OWL과 추론 엔진 (HermiT, Pellet)

OWL은 Description Logic을 기반으로 클래스 정의·제약·동치성을 형식적으로 표현하고, 추론기를 통해 자동으로 검증할 수 있게 합니다.

OWL이 제공하는 6가지 표현력

각 표현력은 "이런 관계가 성립한다"를 공리로 선언하는 도구이며, 선언된 공리는 추론기가 자동으로 새 사실을 도출하는 근거가 됩니다.

# OWL 예시 — Author는 "책을 쓴 Person"
:Author owl:equivalentClass [
  a owl:Class ;
  owl:intersectionOf (
    :Person
    [ a owl:Restriction ;
      owl:onProperty :wrote ;
      owl:someValuesFrom :Book ]
  )
] .

HermiT Reasoner — 4가지 역할

위에서 정의한 OWL 공리들을 입력받아, 추론기는 다음 4가지 작업을 사람이 코드를 짜지 않아도 자동으로 수행합니다.

가변 길이 경로 — 다중 홉 패턴 탐지

Cypher의 (A)-[:REL*1..k]->(B) 패턴 한 줄로 1홉부터 k홉까지의 모든 경로를 한 번에 탐색할 수 있어, RDB의 다중 JOIN을 압축적으로 대체합니다.

// 자기 자신으로 돌아오는 1~3홉 거래 (자금세탁 의심)
MATCH (a)-[:TRANSFERS*1..3]->(a)
RETURN a;

// 친구의 친구가 산 상품 (추천)
MATCH (me:User {id:$me})
      -[:FRIEND]->(:User)
      -[:FRIEND]->(f)-[:PURCHASED]->(p)
WHERE NOT (me)-[:PURCHASED]->(p)
RETURN p, count(*) AS hits ORDER BY hits DESC LIMIT 10;

Enterprise Knowledge Graph (EKG)

EKG(Enterprise Knowledge Graph)는 사일로화된 사내 데이터를 하나의 의미 네트워크로 통합해, 조직의 지식을 일관되게 연결하는 "기업의 두뇌" 역할을 합니다.

Neosemantics — RDF × LPG 듀얼 엔진

의미 모델은 RDF로 정의하고 분석·서빙은 Neo4j(LPG)로 처리하며, 두 모델을 잇는 표준 브릿지가 실무 아키텍처의 핵심이 됩니다.

// Neosemantics 임포트 예시
CREATE CONSTRAINT n10s_unique_uri
FOR (r:Resource) REQUIRE r.uri IS UNIQUE;

CALL n10s.graphconfig.init();
CALL n10s.rdf.import.fetch(
  'https://example.com/ontology.ttl', 'Turtle'
);

GraphRAG — LLM × Knowledge Graph 아키텍처

벡터의 "무엇과 비슷한가"와 그래프의 "무엇과 연결됐는가"를 결합해 답을 합성하는 흐름을, 아래 단계를 클릭하며 따라가 보세요.

자연어 → Cypher 자동변환 + Self-Healing 루프

쿼리 실행 실패도 무의미한 에러가 아니라 하나의 피드백 신호이며, 그 에러 메시지를 다시 LLM에 입력해 쿼리를 자동 수정하는 self-healing 루프가 시스템의 견고함을 만듭니다.

# LangChain — GraphCypherQAChain
from langchain.chains import GraphCypherQAChain
from langchain_neo4j import Neo4jGraph

graph = Neo4jGraph(url, user, pwd)
chain = GraphCypherQAChain.from_llm(
    llm=ChatOpenAI(model='gpt-4o', temperature=0),
    graph=graph,
    validate_cypher=True,
    return_intermediate_steps=True,
)
resp = chain.invoke({'query': '커피를 산 사용자 알려줘'})

케이스 스터디 — 자금세탁 탐지 그래프 (AML)

글로벌 결제사 AML PoC 사례들을 종합한 시나리오 — 한 도메인을 깊게 따라가 보면, 그래프가 어떻게 ROI를 만드는지 명확해집니다.

📎 본 수치는 여러 Neo4j AML 케이스 스터디(BNP Paribas·Citi·HSBC 등 공개 사례)와 일반적인 PoC 보고치를 종합·각색한 학습용 시나리오입니다. 5홉 recursive JOIN의 수십 분대 응답·그래프 변환 후 1-2초 수준의 성능 향상·검출률 개선은 다수 사례에서 보고되지만 실제 수치는 도메인·데이터 규모·튜닝 상태에 따라 큰 폭으로 달라집니다. 외부 보고서 인용 시 원전 사례를 별도 확인해 주십시오.

📐 최소 도메인 모델 — 5 클래스 + 5 관계

# 클래스 (Entity 노드 타입)
:Account · :Person · :Company · :Transaction · :SanctionList

# 관계 (Edge 타입)
(:Person|:Company)-[:OWNS]->(:Account)              # 계좌 소유
(:Account)-[:TRANSFERS {ts, amount}]->(:Account)    # 자금 이체 (메타: 시점·금액)
(:Person)-[:CONTROLS {stake}]->(:Company)           # 25%+ 지분 지배
(:Account)-[:SAME_AS]-(:Account)                    # Entity Resolution 결과
(:Person|:Company|:Account)-[:ON_LIST]->(:SanctionList)  # 제재 대상

🗓 4주 PoC 일정

🔍 핵심 쿼리 3가지

MATCH path = (a:Account)-[:TRANSFERS*1..5]->(a)
WHERE all(t IN relationships(path) WHERE t.amount > 1000)
RETURN a.id,
       length(path) AS hops,
       reduce(s = 0, t IN relationships(path) | s + t.amount) AS total
ORDER BY hops DESC, total DESC
LIMIT 20;

MATCH (s:Entity)-[:ON_LIST]->(:SanctionList),
      path = (s)<-[:CONTROLS*1..3]-(ubo:Person)
WHERE all(r IN relationships(path) WHERE r.stake >= 0.25)
RETURN DISTINCT ubo.name, ubo.id, ubo.nationality;

MATCH (src:Account)-[t1:TRANSFERS]->(mid:Account)
                  -[t2:TRANSFERS]->(dst:Account)
WHERE t1.ts > datetime() - duration('P1D')
  AND t2.ts > t1.ts AND t2.ts < t1.ts + duration('PT1H')
  AND t1.amount >= 9000 AND t1.amount <= 9999
WITH src, dst, count(DISTINCT mid) AS hops_via
WHERE hops_via >= 5
RETURN src.id, dst.id, hops_via
ORDER BY hops_via DESC;

도구 스택 + 5주 학습 로드맵

"데이터에 의미를 부여하는 일은, AI 시대의 가장 인간적인 일이다."

도구 스택

5주 학습 로드맵