온톨로지(ontology)는 어떤 분야에 무엇이 있고 그것들이 서로 어떻게 이어질 수 있는지를 데이터를 넣기 전에 미리 정해 둔 틀이다. 직전 편의 지식그래프가 점과 선을 적은 자료라면, 온톨로지는 그 점과 선에 어떤 종류가 허용되는지를 정하는 층이다. 같은 말이 검색 마크업과 과학 데이터베이스와 AI 도구에서 서로 다른 폭으로 쓰인다.
표 머리글이 셋으로 갈린다 — 온톨로지, 왜 생겼나

영업팀 표의 머리글에는 ‘고객’이라 적혀 있다. 계약팀 표에서는 같은 사람이 ‘거래처(account)’이고, 개발팀 데이터베이스에서는 ‘client’다. 사람 눈에는 다 같은 존재인데, 프로그램에는 이 셋을 하나로 묶을 방법이 없다. 표 카드 셋 위에 같은 사람 아이콘이 하나씩 놓였다. 카드 사이에는 선이 한 줄도 없다.
오른쪽 패널에 남은 것은 상자 둘과 그 아래 정렬된 아이콘들이다. 위쪽 상자 하나는 사람이고 하나는 조직이다. 둘을 잇는 선에는 어디서 일하는지를 뜻하는 이름표가 붙었다. 세 표가 제각기 적던 사람들은 틀 아래에 한 줄로 늘어서, 위에서 내려온 선에 닿는다. 표를 적기 전에 무엇이 있고 그것들이 어떻게 이어질 수 있는지를 먼저 정해 둔 것, 이것을 온톨로지(ontology)라고 부른다.
낱말 자체는 컴퓨터에서 나오지 않았다. 이 말을 정리한 백과사전 항목에서 Gruber 는 온톨로지가 존재를 다루는 철학 분야에서 온 말이라고 적는다. 컴퓨터·정보 과학에서는 어떤 분야의 지식을 모형으로 만들려고 설계한 인공물을 가리키는 기술 용어가 된다고 같은 글이 덧붙인다.
AI 쪽 정의가 자리 잡은 곳은 1993년 논문이다. 정의 문장은 한 줄이다.
An ontology is an explicit specification of a conceptualization. 온톨로지는 어떤 개념화를 명시적으로 적어 둔 명세다.
출처: Gruber(1993), Knowledge Acquisition 5(2)같은 논문은 왜 그런 것이 필요했는지도 적는다. 여러 AI 시스템이 형식을 갖춰 적은 지식을 서로 나눠 쓰고 다시 쓰려면, 그 지식을 적을 공통 어휘를 먼저 정해 두는 편이 좋다는 것이다. 여기서 어휘(vocabulary)는 그 분야에서 쓸 수 있는 말의 목록이라는 뜻이다. 논문은 클래스와 관계와 함수 같은 것들의 정의를 모아 놓은 그 목록을 온톨로지라 부른다.
웹 표준으로 이어진 계보도 있다. 먼저 W3C 권고 RDF Schema 1.1(2014)은 스스로를 RDF 자료를 위한 데이터 모형 어휘라고 적는다. 그 이상의 선언은 OWL 같은 더 풍부한 웹 온톨로지 언어가 맡는다고 넘긴다. 다음이 OWL 2 프라이머(2012 권고)다. 그 문서는 OWL 2 를 온톨로지를 적는 언어라고 소개하고, 온톨로지를 세상의 어느 부분에 대한 정확한 서술문의 모음이라고 적는다.
그러니 정의가 하나인 것은 아니다. 방금 읽은 두 문서만 놓아도 한쪽은 개념화의 명세라 하고 다른 쪽은 서술문의 모음이라 한다. 만드는 법을 적어 둔 Noy 와 McGuinness 의 안내서는 AI 문헌의 정의가 여럿이고 서로 어긋나는 것도 많다고 적는다. 문장은 저마다 달라도 가리키는 것은 대체로 같다.
무엇으로 이루어지나 — 클래스·인스턴스·속성
OWL 2 프라이머는 그 안에 무엇이 들어가는지를 가족 예 하나로 펼쳐 놓는다. 문서는 사물을 individual 이라 부른다. 사물의 무리는 class, 사물 사이의 관계는 property 다. 이 편에서는 각각 인스턴스(instance)·클래스(class)·속성(property)으로 적는다.
클래스부터다. 클래스는 공통점이 있는 것들을 한데 묶어 가리키려고 만든 무리이고, 문서의 표현으로는 곧 사물의 집합이다. Person 이라는 클래스가 있고 Mary 와 John 이 그 안에 드는데, 이때 Mary 는 사람 하나를 가리키는 인스턴스다.
그림 1의 위층이 클래스이고 아래층이 인스턴스다. 위층 안에도 선이 있다. Woman 에서 Person 으로 올라가는 그 선은 Woman 이 Person 의 하위 클래스라는 뜻이다. 문서는 이 관계를 적어도 되는지 가늠하는 요령을 함께 적어 둔다. “every A is a B”, 그러니까 "모든 A 는 B 다"라는 문장이 말이 되고 사실이면 그때 A 를 B 아래에 둔다. RDF Schema 는 같은 관계를 한 클래스의 인스턴스가 전부 다른 클래스의 인스턴스이기도 하다는 뜻으로 정의한다.
속성은 카드와 카드 사이에 붙거나, 카드와 값 사이에 붙는다. 그림에서 Mary 와 John 을 잇는 hasWife 가 앞쪽이다. 사물을 사물에 잇는 속성이고, 문서가 든 예도 사람과 그 배우자다. 뒤쪽은 사물에 데이터 값을 붙이는 속성이어서, 사람에게 나이(age)를 붙이는 것이 그 예다. 같은 가족 예에서 John 의 나이는 51이다.
마지막 요소는 겹칠 수 없음이다. Woman 과 Man 은 서로 겹치지 않는데, 문서는 클래스 사이의 이 관계를 disjointness 라 부르면서 한 줄을 덧붙인다. 둘이 겹치지 않는다는 것은 사람에게는 배경지식이어서, 추론하는 프로그램이 그것을 쓰게 하려면 명시적으로 적어 두어야 한다는 것이다. 적어 두지 않으면 기계는 모른다. 온톨로지를 만드는 일이 무슨 일인지가 이 한 줄에 들어 있다.
다섯 가지를 다 짚었다. 무엇이 있고(클래스), 무엇의 예이고(인스턴스), 무엇을 가지고(속성), 무엇 아래이고(하위 클래스), 무엇과 겹칠 수 없는지(겹치지 않음)다. 그 안내서는 같은 것을 다른 낱말로 적는다. 어떤 분야의 개념(클래스)과 각 개념의 성질(안내서는 슬롯이라 부른다)과 그 성질에 걸리는 제한을 형식을 갖춰 적어 둔 것이 온톨로지다.
그 다음 문장이 직전 편과 이어진다. 안내서는 온톨로지에 클래스의 인스턴스들을 더한 것을 knowledge base 라 부른다. 직전 편에서 지식그래프라 부른 것이 이 문서에서는 그 이름으로 나온다. 그러면서 그 경계가 뚜렷하지 않다고 곧바로 덧붙인다.
In reality, there is a fine line where the ontology ends and the knowledge base begins. 실제로는 온톨로지가 끝나고 지식 베이스가 시작되는 자리의 경계가 희미하다.
출처: Noy & McGuinness, Ontology Development 101경계가 왜 희미한지는 같은 문서의 와인 예가 보여 준다. 와인 클래스의 인스턴스는 병 하나하나가 아니라 특정 와이너리가 만든 특정 와인들이다. 그런데 식당의 재고를 관리하려 들면 선반의 병 하나하나가 인스턴스가 된다. 무엇을 인스턴스로 볼지가 만드는 목적을 따라 움직인다.
어떻게 만드나 — 일곱 단계
그 목적을 정하는 일이 만드는 절차의 첫 칸이다. 같은 안내서는 순서를 꺼내기 전에 규칙 셋을 먼저 박아 둔다. 첫째, 한 분야를 모형으로 만드는 올바른 방법이 하나만 있는 것은 아니다. 쓸 만한 대안이 늘 있다. 어떤 해법이 알맞은지는 그 온톨로지를 어디에 쓸 생각인지와 앞으로 무엇을 덧붙일지에 달렸다.
둘째, 온톨로지를 만드는 일은 한 번에 끝나지 않고 되짚어 고치기를 되풀이한다. 셋째, 온톨로지의 개념은 그 분야의 실제 사물과 관계에 가까워야 한다. 대개 그 분야를 설명하는 문장의 명사와 동사가 그것이다.
그 위에서 안내서가 든 단계가 일곱이다. 그림 2이 그 순서다.
- 범위와 목적을 정한다. 이 온톨로지가 어느 분야의 무엇을 다루는지 먼저 못 박는다.
- 기존 온톨로지를 다시 쓸 수 있는지 본다. 남이 만들어 둔 것을 가져다 쓸 여지가 있는지 확인한다.
- 중요한 용어를 나열한다. 그 분야를 설명할 때 쓰는 말을 일단 늘어놓는다.
- 클래스와 계층을 정한다. 늘어놓은 말 가운데 무리가 될 것을 고르고, 무엇이 무엇 아래인지 정한다.
- 속성을 정한다. 클래스마다 어떤 성질을 갖는지 붙인다. 안내서가 슬롯이라 부르는 것이 이것이다.
- 속성의 제한을 정한다. 각 속성에 어떤 값이 올 수 있는지 정한다.
- 인스턴스를 만든다. 정해 둔 클래스에 실제 개체를 채워 넣는다.
강조된 칸은 네 번째다. 앞의 셋은 무엇을 만들지 정하는 준비이고, 틀의 뼈대가 실제로 서는 곳은 이 칸이다. 그리고 데이터가 들어오는 것은 일곱 번째 칸에 가서다. 틀이 먼저이고 데이터가 나중이라는 순서가 절차에도 그대로 있다. 이 일을 하는 편집기도 있다. Protégé는 무료로 공개된 OWL 온톨로지 편집기다.
어디서 이 말을 만나나 — 검색과 과학
편집기로 직접 만드는 쪽만 있는 것은 아니다. 그렇다면 우리가 이 말을 실제로 만나게 되는 자리는 어디인가. 먼저 매일 쓰는 검색이다.
schema.org 는 웹페이지에 다는 표시의 타입 모음이다. 공식 안내는 이것을 웹마스터가 페이지에 표시를 달 수 있도록 함께 쓰는 어휘 모음이라 적는다. 구글·마이크로소프트·얀덱스·야후가 그 표시를 읽는다고 덧붙인다. 정작 schema.org 는 자기 문서에서 스스로를 schemas 나 vocabularies 라 부르지, 온톨로지라 부르지 않는다.
이름이 다를 뿐 안은 같은 모양이다. 가장 넓은 타입은 Thing 이고 name·description·url·image 네 속성을 갖는다. Place 는 Thing 의 더 구체적인 타입이다. LocalBusiness 는 그 아래로 한 칸 더 내려간다.
아래쪽 항목은 위쪽 타입의 속성을 물려받는다 — 앞 절의 하위 클래스가 서 있던 자리다. 마크업 예도 그렇다. 영화의 director 가 Person 타입이고, 그 Person 이 name 과 birthDate 속성을 갖는다고 적는 식이다.
과학 쪽에는 이름에 온톨로지가 들어간 자료가 있다. Gene Ontology(GO)는 생물학 지식을 구조를 갖춰 표준화한 표현이다. 공식 소개는 GO 가 개념을 기술한다고 적으면서, 그 개념을 용어(term)라 부르기도 하고 형식을 갖춰 말하면 클래스라 부른다고 덧붙인다. 개념끼리는 뜻이 정해진 관계로 이어진다. 계층이 있되 엄격한 계층은 아니어서, 한 용어가 부모를 둘 이상 가질 수 있다.
GO 에서 눈여겨볼 것은 갈라져 있는 두 덩어리다. 하나는 ontology 로, 클래스와 그 사이의 논리 구조다. 다른 하나는 annotations 로, 특정 유전자 산물을 특정 용어에 잇는 서술이며 과학 논문을 근거로 단다. 소개 문서는 이 둘이 함께 있어야 생물학 계의 온전한 모형이 된다고 적는다. 틀과 데이터가 이름부터 갈라져 있는 실물이다.
어디서 이 말을 만나나 — AI 도구 둘
이제 AI 도구 쪽이다. 같은 낱말이 여기서 두 번 나오는데, 가리키는 폭이 서로 다르다. 그림 3가 지금까지 나온 세 자리를 한 장에 모은 것이고, 강조된 가지가 이 절이다.
첫째는 팔란티어 파운드리(Palantir Foundry)의 Ontology 다. 공식 문서는 이것을 세계를 분류한 것이라 적는다. 파운드리 안에서는 조직의 디지털 트윈이라고도 한다. 조직을 디지털로 본뜬 짝이라는 뜻이다. 데이터셋과 모델을 네 가지에 대응시켜 조직의 전체 그림을 만든다는 것이다. 그 넷은 오브젝트 유형(object type)·속성·링크 유형(link type)·액션 유형(action type)이다.
네 낱말의 뜻은 문서가 그대로 적어 둔다. 오브젝트 유형은 조직 안의 개체나 사건을 정한 것이다. 링크 유형은 오브젝트 유형 둘 사이의 관계를 정한 것이고, 액션 유형은 오브젝트 유형이 어떻게 바뀔 수 있는지를 정한 것이다. 같은 문서가 이것을 표 비유로 푼다. 오브젝트 유형 하나가 데이터셋 하나에 해당하고, 오브젝트 하나는 데이터셋의 행 하나에 해당한다. 데이터셋의 열이 오브젝트의 속성에 해당하고, 데이터셋끼리 여러 방식으로 조인하듯 오브젝트도 속성 값을 근거로 서로 링크를 갖는다.
앞 절까지의 온톨로지에 견줘 보면 칸이 하나 더 있다. 클래스·인스턴스·속성·관계까지는 자리가 맞는데, 액션 유형은 W3C 계보의 문서에 없던 것이다. 파운드리 문서 자신도 이 Ontology 가 의미 요소(오브젝트·속성·링크)와 운동 요소(액션·함수·동적 보안)를 함께 담는다고 적는다. 같은 낱말이 더 넓은 것을 가리킨다.
둘째는 GraphRAG 다. 직전 편에서 LLM 이 문서를 읽어 개체와 관계를 뽑는 대목을 봤는데, 그 뽑기가 시작되기 전에 사람이 주는 설정값이 하나 있다. entity_types, 곧 개체 유형 목록이다. 공식 문서는 이 값을 찾아낼 개체 유형들이라고 한 줄로 적는다. 기본값은 넷이다 — organization, person, geo, event.
공식 추출 프롬프트는 문서 하나와 이 목록을 함께 준다. 목록에 있는 유형의 개체를 문서에서 모두 찾고, 찾아낸 개체들 사이의 관계도 모두 찾으라고 시킨다. 목록에 없는 유형은 뽑히지 않는다. 뽑기 전에 무엇이 있을 수 있는지를 먼저 정한다는 점에서, 이 목록이 하는 일은 앞 절의 클래스 목록과 같은 자리에 있다.
다만 폭이 다르다. 이름 넷이 늘어선 목록일 뿐 계층도 속성도 제한도 없다. 그래서 이 목록을 온톨로지의 가장 얇은 형태라 부를 수 있는데, 이 호칭은 이 편의 해석이다. GraphRAG 공식 문서에 온톨로지라는 낱말은 나오지 않는다. 목록을 사람이 주지 않고 모델이 스스로 찾게 하는 선택지도 문서에 있다.
여기까지 나온 다섯 문서를 한 표에 놓으면 같은 구도가 드러난다. 낱말만 각자 다를 뿐이다.
| 문서 | 틀 쪽 낱말 | 데이터 쪽 낱말 |
|---|---|---|
| OWL 2 | class, property | individual |
| Noy & McGuinness | ontology(클래스·슬롯·제한) | instances(온톨로지와 합쳐 knowledge base) |
| Palantir Foundry | object type, property, link type, action type | object |
| Gene Ontology | ontology(term, class) | annotations |
| GraphRAG | entity_types | 뽑힌 개체와 관계 |
왜 만들고 무엇을 치르나
이 일을 왜 하는지는 Noy 와 McGuinness 의 안내서가 첫머리에 다섯 가지로 적어 둔다. 사람이나 소프트웨어 에이전트 사이에 정보 구조의 공통 이해를 나누기 위해서, 그리고 어느 분야의 지식을 다시 쓸 수 있게 하기 위해서다. 나머지 셋은 이렇다. 그 분야에 대해 깔고 있던 가정을 겉으로 드러내기 위해서, 분야 지식과 운영 지식을 갈라 두기 위해서, 그 분야의 지식을 분석하기 위해서다.
치르는 것은 여기까지 오면서 이미 다 나왔다. 아래 표의 두 열은 서로 짝지은 것이 아니라 나란히 놓은 목록이다.
| 얻는 것 | 치르는 것 |
|---|---|
| 사람과 프로그램이 정보 구조를 같은 방식으로 이해한다 | 올바른 방법이 하나가 아니어서, 만들어 놓고도 되짚어 고친다 |
| 한 분야의 지식을 다시 쓸 수 있다 | 배경지식을 전부 적어 두어야 기계가 그것을 쓴다 |
| 깔고 있던 가정이 겉으로 드러난다 | 틀이 끝나고 데이터가 시작되는 경계가 희미하다 |
| 분야 지식과 운영 지식이 갈라진다 | 같은 낱말이 도구마다 다른 폭을 가리킨다 |
| 그 분야의 지식을 분석할 수 있다 | — |
목적을 따로 적어 둔 문서도 있다. 파운드리 문서는 Ontology 에 투자하는 목적을 조직의 의사결정을 규모 있게 개선하는 것이라고 적는다. 도구를 만드는 쪽이 적은 문장이니 그대로 옮긴다.
표의 마지막 줄이 물음 하나를 남긴다. 온톨로지라는 말을 만나면 그 도구가 이 말로 어디까지를 가리키는지부터 확인하면 된다. W3C 계보의 문서에서는 클래스와 속성과 계층까지이고, 파운드리에서는 액션까지 들어가며, GraphRAG 에서는 유형 이름 목록만 남는다.
이제 이 말은 안다
- 온톨로지는 어떤 분야에 무엇이 있고 그것들이 어떻게 이어질 수 있는지를 데이터를 넣기 전에 정해 둔 틀이다.
- 그 틀이 정하는 것은 다섯 가지다. 클래스, 클래스의 인스턴스, 속성, 무엇이 무엇 아래인지, 무엇과 무엇이 겹칠 수 없는지.
- 직전 편의 지식그래프는 이 문서들의 말로 온톨로지에 인스턴스를 더한 지식 베이스이고, GO 에서는 데이터 쪽이 annotations 다. 틀이 온톨로지이고 그 안을 채운 것이 데이터인데, 둘의 경계는 희미하다.
- 같은 낱말의 폭이 도구마다 다르다. 액션까지 담은 쪽이 있고, 유형 이름 목록만 남은 쪽이 있다.
여덟 낱말은 아래 표에 있다.
| 용어 | 한 줄 뜻 | 그림 어디에 |
|---|---|---|
| 온톨로지 | 무엇이 있고 어떻게 이어질 수 있는지를 데이터보다 먼저 정해 둔 틀 | 히어로 오른쪽 패널의 틀 · 세 자리 그림의 중심 |
| 클래스 | 공통점이 있는 것들을 묶은 무리. 인스턴스의 집합 | 가족 그림 위층 카드 셋 |
| 인스턴스 | 클래스에 드는 개체 하나 | 가족 그림 아래층 Mary·John |
| 속성 | 사물을 사물에 잇거나 사물에 데이터 값을 붙이는 것 | 가족 그림의 hasWife 이름표 |
| 하위 클래스 | "모든 A 는 B 다"가 성립할 때 A 를 B 아래에 두는 관계 | 가족 그림의 강조된 선 |
| 어휘(vocabulary) | 그 분야에서 쓸 수 있는 말의 목록 | 히어로 오른쪽 패널의 틀 카드 이름표 |
| 오브젝트 유형(object type) | 팔란티어 파운드리가 조직의 개체·사건을 정할 때 쓰는 이름 | 세 자리 그림의 AI 도구 가지 |
| 개체 유형(entity types) | GraphRAG 가 뽑기 전에 받는 유형 이름 목록 | 세 자리 그림의 AI 도구 가지 |
더 읽기
- OWL 2 Web Ontology Language Primer (Second Edition) — W3C 권고(2012-12-11). 클래스·인스턴스·속성·하위 클래스·disjointness 의 정의와 가족 예가 여기 있다.
- RDF Schema 1.1 — W3C 권고(2014-02-25). RDF 자료를 위한 데이터 모형 어휘와 하위 클래스 정의.
- A Translation Approach to Portable Ontology Specifications — Gruber, Knowledge Acquisition 5(2), 1993. 인용한 정의 문장의 출처.
- Ontology — Encyclopedia of Database Systems 항목 — Gruber. 철학에서 온 낱말과 기술 용어로서의 뜻.
- Ontology Development 101: A Guide to Creating Your First Ontology — Noy & McGuinness, Stanford. 이유 다섯·규칙 셋·일곱 단계·와인 예.
- schema.org Getting started — 공식 안내(2026-09-12 확인). 어휘라는 자기 호칭·타입 계층·마크업 예.
- About the GO — Gene Ontology Consortium(2026-09-12 확인). ontology 와 annotations 의 구분.
- Ontology documentation — Gene Ontology Consortium(2026-09-12 확인). 구조를 갖춰 표준화한 표현·term/class·부모 둘 이상의 출처.
- Foundry Ontology — Core concepts · Overview — Palantir 공식 문서(2026-09-12 확인). 오브젝트 유형·속성·링크 유형·액션 유형의 정의와 데이터셋 비유는 Core concepts, 의미 요소/운동 요소와 투자하는 목적은 Overview.
- GraphRAG 설정 문서 · 자동 프롬프트 튜닝 — Microsoft(2026-09-12 확인). entity_types 항목과 목록을 모델이 스스로 찾게 하는 선택지. 기본값과 추출 프롬프트 문장은 공식 레포 커밋 f40e9a26ce62 기준.