OntoBricks로 이해하는 온톨로지 ① 개념 — 온톨로지와 지식 그래프 첫걸음

📚 시리즈
① 개념 — 온톨로지와 지식 그래프 첫걸음 (현재 글)
② 이해 — OntoBricks란
③ 구성 — 설정부터 공개까지
④ 데모 — GraphQL·자연어·MCP 질의

온톨로지(Ontology)는 이름부터 철학 용어처럼 낯섭니다. 이 시리즈는 온톨로지가 무엇이고 어디에 쓰는지를, Databricks 위에서 동작하는 OntoBricks로 직접 만들어 보며 이해하는 것이 목표입니다. 가상 금융그룹 데이터로 온톨로지를 설계하고, 지식 그래프를 만들고, 자연어로 질의하는 데까지 따라갑니다.

이 글에서는 다음 세 가지를 다룹니다.

1. 온톨로지는 어떤 질문에 필요한가
2. 시맨틱 레이어, 온톨로지, 지식 그래프는 무엇이고 어떤 관계인가
3. 온톨로지의 구성 요소와 실제 모습

ℹ️ 이 시리즈의 회사·인물·상품은 모두 가상입니다.

---

 

1. 온톨로지는 어떤 질문에 필요할까요

LLM이 사내 데이터로 답하게 하려면 먼저 근거를 찾아야 합니다. 근거를 찾는 방법은 데이터의 형태와 질문의 성격에 따라 달라집니다.

데이터와 질문	주로 쓰는 도구	예
📄 비정형 문서에서 의미가 비슷한 내용 찾기	벡터 검색 (Vector Search)	"이 펀드의 환매 수수료 규정은?"
🧮 정형 테이블에서 조회·필터·집계	Text-to-SQL (Genie 등)	"지난달 판매액 상위 5개 상품은?"
🔗 테이블 사이의 관계를 여러 단계 따라가거나, 관계의 규칙이 중요한 질문	지식 그래프 (의미는 온톨로지로 정의)	"도토리홀딩스가 직·간접적으로 지배하는 회사가 판매하는 1등급 상품은?"

 

벡터 검색은 "비슷한 것"을 찾는 데 알맞고, Text-to-SQL은 테이블을 조합해 계산하는 데 알맞습니다. 관계를 따라가야 하는 질문은 성격이 다릅니다. 답하려면 테이블에 적혀 있지 않은 다음 세 가지를 알아야 합니다.

알아야 할 것	쉽게 말하면
관계의 뜻	control 테이블의 한 줄(홀딩스 → 증권)은 "홀딩스가 증권을 지배한다"는 뜻입니다
관계를 이어 가는 규칙	홀딩스가 증권을 지배하고 증권이 자산운용을 지배하면, 홀딩스는 자산운용도 지배합니다. "직·간접"은 이렇게 끝까지 이어 간다는 뜻입니다
반대 방향	"증권은 누구의 지배를 받나?"는 같은 관계를 거꾸로 읽은 질문입니다. 답은 홀딩스입니다

 

이것이 테이블 밖에 있는 관계의 의미와 규칙입니다. 이 의미를 한 번 정의해 두고 프로그램이 그대로 쓰게 하는 것이 온톨로지입니다. 이 시리즈는 이런 관계 질문을 다룹니다. 정형 테이블에서 출발해, 그 위에 온톨로지로 관계의 의미를 입히고, 지식 그래프로 만들어 질의합니다.

 

1.1 시맨틱 레이어, 온톨로지, 지식 그래프는 어떤 관계일까요

비슷한 말이 섞여 쓰이므로 먼저 정리합니다. 범위가 넓은 것부터 보면 다음과 같습니다.

개념	한 줄 정의	도토리금융그룹 예
시맨틱 레이어	원천 데이터와 이를 쓰는 도구(SQL, 대시보드, AI) 사이에서 테이블·컬럼 같은 기술 구조를 업무 용어·지표·관계로 정의해 두는 층 전체. 정의가 한 곳에 있으므로 어떤 도구로 조회하든 같은 뜻으로 쓰입니다	"계열사 = 도토리홀딩스가 직·간접 지배하는 회사", "위험등급 1 = 가장 낮은 위험"
온톨로지	그중 개념(클래스)·관계·규칙을 표준 형식(OWL)으로 정의한 것. 무엇이 있을 수 있는지를 정하는 설계도입니다	"회사(Company)라는 클래스가 있다", "controls는 회사 → 회사 관계이고 전이된다"
지식 그래프	온톨로지에 실제 데이터를 채운 것. 지금 무엇을 알고 있는지를 담습니다	"도토리홀딩스 controls 도토리증권"

 

시맨틱 레이어 (업무 의미 전체)
 └─ 온톨로지 (개념·관계·규칙의 설계도)
      └─ 지식 그래프 (설계도에 실제 데이터를 채운 것)

이 글에서는 2장에서 지식 그래프를, 3장에서 온톨로지를 차례로 봅니다. 설계도와 건물에 비유하면, 온톨로지가 설계도이고 지식 그래프가 그 설계도대로 지은 건물입니다.

Databricks에서는 이 층을 기능별로 나눠 맡습니다. 이름이 비슷해 헷갈리기 쉬우니 함께 정리해 둡니다.

층	Databricks 기능	하는 일
시맨틱 레이어 중 지표 정의	UC Metric Views (GA)	매출 같은 지표와 차원을 한 번 정의해 대시보드·Genie가 같이 씁니다
자연어 질의를 위한 맥락	Genie Ontology (Public Preview)	테이블·쿼리·대시보드에서 업무 맥락을 자동으로 모아, Genie가 어떤 정의를 믿을지 고릅니다
관계·규칙의 형식 정의(온톨로지)와 지식 그래프	OntoBricks (Databricks Labs)	클래스·관계·규칙을 OWL로 정의하고, 테이블을 그래프로 만들어 추론·검증·질의합니다

 

이름에 '온톨로지'가 들어가도 Genie Ontology는 형식 온톨로지(OWL)가 아니라 맥락을 모으는 계층입니다. 이 시리즈가 다루는 것은 OntoBricks로 만드는 온톨로지와 지식 그래프입니다.

⚠️ OntoBricks는 Databricks 공식 제품이 아닙니다. Databricks Labs 프로젝트(github.com/databrickslabs/ontobricks)로, 탐색과 실험을 위해 공개된 오픈소스입니다. Databricks의 공식 지원(SLA)과 지원 티켓 대상이 아니며, 문제가 생기면 GitHub 이슈로 대응합니다. 버전도 빠르게 바뀝니다. 이 시리즈는 v0.8.1 기준입니다. 운영 환경에 쓰려면 이 점을 고려해야 합니다.

---

 

2. 지식 그래프: 사실을 주어·관계·대상으로 나누기

1장의 질문에 필요한 사실은 지배구조, 상품 마스터, 임원 명부 같은 테이블에 들어 있습니다. 이 사실을 관계 중심으로 다시 적으면 지식 그래프가 됩니다. 테이블의 행을 어떻게 그래프로 바꾸는지는 ②편에서 원리를, ③편에서 실제 화면으로 봅니다.

지식 그래프(Knowledge Graph)는 사실을 주어 – 관계 – 대상 세 조각으로 쪼개 저장합니다. 이 세 조각을 트리플(Triple)이라고 부릅니다.

#	주어 (Subject)	관계 (Predicate)	대상 (Object)
1	🏢 도토리홀딩스	controls (지배한다)	🏢 도토리증권
2	🏢 도토리증권	controls (지배한다)	🏢 도토리자산운용
3	🏢 도토리자산운용	sells (판매한다)	📦 도토리글로벌테크펀드
4	📦 도토리글로벌테크펀드	riskGrade (위험등급)	🔢 1
5	👤 전유성	executiveOf (임원이다)	🏢 도토리증권

 

🏢 회사 · 👤 사람 · 📦 금융상품 · 🔢 값(숫자·문자) 1·2·3·5번은 대상이 다른 엔티티(노드 ↔ 노드)이고, 4번만 대상이 값(노드 ↔ 숫자)입니다. 이 구분은 3.1에서 객체 속성(Object Property)과 데이터 속성(Datatype Property)으로 다시 나옵니다.

이 표에서 쓰는 용어를 정리하면 다음과 같습니다.

용어	뜻	표에서
트리플	주어 – 관계 – 대상 한 줄 = 사실 하나	1~5번 행 각각
엔티티	이름(URI)을 가진 "것". 그래프의 노드	주어 자리 전부, 대상 자리 중 값이 아닌 것
값	숫자·문자·날짜. 엔티티가 아닙니다	4번 행의 1
관계	주어와 대상을 잇는 이름. 그래프의 엣지	controls, sells, riskGrade, executiveOf

 

🏢·👤·📦 아이콘은 엔티티의 종류를 나타냅니다. 이 종류를 클래스라고 부르며 3.1에서 다룹니다.

트리플을 이어 붙이면 그래프가 됩니다. 앞의 질문은 이제 "도토리홀딩스에서 controls를 한 번 이상 따라간 뒤, sells를 따라가 riskGrade = 1인 노드를 찾아라"라는 경로 탐색이 됩니다(1 → 2 → 3 → 4번 행). 관계 이름을 따라가기만 하면 되므로, 그래프에 사실이 들어 있는 한 답을 놓치지 않습니다.

그런데 트리플에는 사실만 들어 있습니다. "도토리홀딩스가 도토리증권을 controls한다"는 적혀 있지만, controls가 무슨 뜻이고 어떤 성질을 갖는지는 어디에도 없습니다.

• controls를 두 번 따라간 관계도 "지배"로 볼 것일까요?
• controls의 주어로 사람이 올 수 있을까요?
• sells를 하는 회사는 자동으로 "금융회사"일까요?

이런 질문에 답하는 사실에 대한 규칙을 따로 적어 두어야 합니다. 그것이 온톨로지입니다.

---

 

3. 온톨로지: 지식 그래프의 설계도

한 문장으로 정의하면 이렇습니다.

📐 온톨로지는 "이 세계에 어떤 종류의 것이 있고, 그것들이 어떤 관계를 맺으며, 그 관계가 어떤 성질을 갖는지"를 프로그램이 해석할 수 있는 형식으로 정의한 것입니다.

데이터베이스 스키마와 비슷하지만 결정적인 차이가 하나 있습니다. 스키마는 데이터를 담는 틀이고, 온톨로지는 거기에 더해 새로운 사실을 이끌어 내는 규칙까지 담습니다. 추론과 검증은 ③편에서 OntoBricks 화면으로 직접 확인합니다.

 

3.1 온톨로지의 다섯 가지 구성 요소

구성 요소	영문 (OWL 용어)	뜻	예시
클래스	Class	엔티티의 종류	Company, Person, Product
개체	Individual	클래스에 속한 구체적인 하나 (= 엔티티). rdf:type으로 클래스에 연결	도토리증권 rdf:type Company
객체 속성	Object Property	엔티티와 엔티티 사이의 관계. 주어 쪽 클래스(domain)와 대상 쪽 클래스(range)를 정할 수 있음	executiveOf: Person → Company
데이터 속성	Datatype Property	엔티티와 값(문자열·숫자·날짜) 사이의 관계	riskGrade
상하위 관계	rdfs:subClassOf	클래스 사이의 "~의 일종" 관계	FinancialCompany ⊂ Company

 

domain/range는 RDB의 제약 조건과 달리 검사가 아니라 추론 규칙입니다.

📘 RDF (Resource Description Framework): W3C가 정한 데이터 표현 표준입니다. 모든 데이터를 2장에서 본 주어 – 관계 – 대상 트리플로 나타내고, 모든 이름에 URI를 붙입니다. 관계형 모델이 모든 데이터를 표(행·열)로 나타내듯, RDF는 모든 데이터를 트리플로 나타냅니다. rdf:type처럼 rdf:로 시작하는 이름이 RDF 표준 어휘이고, rdfs:subClassOf의 rdfs:는 RDF에 클래스·상속 같은 스키마 어휘를 더한 RDFS(RDF Schema)를 뜻합니다.

📘 OWL (Web Ontology Language): RDF 위에 얹는 W3C 온톨로지 표준 언어입니다. 클래스와 관계, 그리고 관계의 성질(전이, 역관계 등)을 프로그램이 해석할 수 있게 적는 문법과 의미 규칙을 정해 둡니다. SQL이 관계형 데이터베이스의 표준 언어인 것처럼, OWL은 온톨로지의 표준 언어입니다. 위 표의 영문 용어도 OWL에서 쓰는 이름입니다.

 

3.2 TBox와 ABox

1장에서 정리한 설계도와 실제 데이터를 온톨로지 문서에서는 이렇게 부릅니다.

• TBox (Terminological Box): 개념의 정의. "Company라는 클래스가 있고, controls는 Company와 Company 사이의 관계다." → 스키마, 1장의 온톨로지(설계도)
• ABox (Assertional Box): 개별 사실. "도토리홀딩스는 도토리증권을 controls한다." → 데이터, 1장의 지식 그래프에 채워진 사실

이 구분은 이 시리즈 전체에서 가장 중요한 기준입니다. ②편에서 보겠지만, OntoBricks에서 LLM은 TBox 설계를 돕고, ABox는 테이블에서 SQL로 만듭니다.

 

3.3 실제 모습: 파일과 그림

온톨로지는 보통 Turtle(.ttl)이라는 텍스트 파일로 저장합니다. 트리플을 주어 관계 대상 .처럼 한 줄에 하나씩 적습니다. 예제 파일의 일부를 보면 다음과 같습니다(a는 rdf:type의 줄임입니다). 2장 끝의 질문(지배의 지배도 지배인가, 반대 방향은 무엇인가)에 대한 답도 이렇게 한 줄씩 적습니다.

# Company는 클래스다
fin:Company        a owl:Class .
# controls는 전이 관계다 (지배의 지배도 지배)
fin:controls       a owl:TransitiveProperty .
# controls의 주어는 회사다
fin:controls       rdfs:domain fin:Company .
# isControlledBy는 controls의 반대 방향이다
fin:isControlledBy owl:inverseOf fin:controls .
# 도토리홀딩스는 도토리증권을 지배한다
fin:DotoriHoldings fin:controls fin:DotoriSecurities .

예제 온톨로지 전체를 도식화하면 다음과 같습니다.

요소	뜻
파란 상자 영역 (TBox)	클래스와, 클래스 사이에 정의한 관계(domain → range)
굵은 빈 화살표	subClassOf (금융회사는 회사의 일종)
노란 영역 (ABox)	실제 엔티티와 값, 그 사이의 사실
엔티티 안의 회색 글씨	rdf:type (이 엔티티는 저 클래스에 속합니다. 예: rdf:type 회사)

 

도토리증권, 도토리자산운용, 도토리글로벌테크펀드에는 rdf:type 글씨가 없습니다. 파일에 적지 않았기 때문입니다. 이런 빈칸은 추론기가 domain/range 같은 규칙으로 채웁니다.

---

 

4. 정리

질문	답
온톨로지는 언제 필요한가요?	테이블 사이의 관계를 여러 단계 따라가거나, 관계의 규칙(전이·역관계)이 중요한 질문에 필요합니다. 문서 검색은 벡터 검색, 단순 조회·집계는 Text-to-SQL이 맞습니다
시맨틱 레이어·온톨로지·지식 그래프의 관계는?	시맨틱 레이어(업무 의미 전체) 안에 온톨로지(개념·관계·규칙의 설계도)가 있고, 온톨로지에 실제 데이터를 채운 것이 지식 그래프입니다
지식 그래프란?	사실을 주어 – 관계 – 대상 트리플로 저장한 그래프입니다
온톨로지란?	지식 그래프의 설계도(TBox)입니다. 클래스, 개체, 객체·데이터 속성, 상하위 관계로 구성되고, 관계의 domain/range와 전이·역관계 같은 성질을 정합니다
스키마와 무엇이 다른가요?	데이터를 담는 틀에 더해, 규칙으로 새 사실을 추론합니다 (예: 지배의 지배는 지배 → 간접 지배)
실제로는 어떤 모습인가요?	RDF·OWL 표준으로 정의하고 Turtle(.ttl) 파일로 저장합니다

 

다음 글 ② 이해에서는 이 과정을 Databricks 위에서 해 주는 OntoBricks를 살펴봅니다. 온톨로지를 설계하고(Design), UC 테이블에 매핑하고(Map), 추론·검증하고(Reason), AI 에이전트에 제공하는(Serve) 네 단계가 어떻게 동작하는지, 그리고 그 가운데 LLM이 맡는 부분은 어디까지인지 확인합니다.

---

 

참고

• OntoBricks: https://ontobricks.org/ · https://github.com/databrickslabs/ontobricks
• W3C OWL 2 Primer: https://www.w3.org/TR/owl2-primer/
• W3C RDF 1.1 Turtle: https://www.w3.org/TR/turtle/