AI시대 일반인을 위한 온톨로지 설명회
온톨로지는 AI 시대에 갑자기 만들어진 개념이 아닙니다. 2,400년 전 아리스토텔레스의 카테고리 분류에서 시작해, 주요 AI 기업이 지금 가장 적극적으로 활용하는 지식 표현 방식입니다.
결론: 온톨로지는 AI 시대의 새 단어가 아니라, 지식을 정의하는 오래된 언어입니다
ChatGPT, Claude, Perplexity 같은 도구를 쓰다 보면 "온톨로지(Ontology)" 라는 단어를 점점 더 자주 마주치게 됩니다. 구글 검색 결과의 지식 패널, 넷플릭스 추천, 팔란티어의 디지털 트윈, AI 에이전트의 도구 사용 모두 그 뒤에 온톨로지가 있습니다.
그런데 온톨로지라는 개념에 대한 이해가 생각보다 어렵습니다. "그냥 카테고리 분류" 정도로 가볍게 이해되거나, 반대로 "AI 시대에 새로 등장한 어려운 개념" 으로 과장되기도 합니다. 둘 다 맞지 않습니다.
온톨로지는 AI 시대의 새 단어가 아닙니다. 2,400년 전 아리스토텔레스에서 시작된, 현실을 정의하기 위한 오래된 언어입니다.
이 글에서는 어원과 철학적 출발, 톰 그루버의 학술적 정의, Taxonomy 와의 결정적 차이, 3요소(Class·Instance·Property), 추론(Reasoning) 의 의미, 그리고 주요 AI 기업의 현실 사례까지 한 번에 정리합니다.
온톨로지의 출발은 2,400년 전 존재론입니다
온톨로지(Ontology) 는 그리스어 두 단어가 합쳐진 말입니다. on 은 "존재(being)" 를, logia 는 "학문(study)" 를 뜻합니다. 두 단어를 이으면 "존재에 대한 연구", 곧 존재론이 됩니다.
이 단어를 처음 본격적으로 사용한 사람이 아리스토텔레스입니다. 그는 "무엇이 존재하는가" 를 알기 위해 세상에 있는 모든 사물을 10가지 카테고리로 정리했습니다. 실체, 양, 질, 관계, 위치, 시간, 장소, 능동, 수동, 소유. 어떤 대상이든 이 10가지 범주 안에서 설명할 수 있다고 본 것입니다.
아리스토텔레스의 10가지 카테고리 분류는 인류 최초의 데이터 모델링이며, 오늘날 데이터베이스 설계의 핵심 원리와 정확히 일치합니다.
지금의 데이터베이스 테이블이 컬럼(속성)으로 행(실체)을 설명하는 방식과 결국 같은 발상입니다. 온톨로지의 뿌리는 컴퓨터과학이 아니라 철학에 있고, AI 가 등장하기 한참 전부터 사람들이 세상을 정리해 온 방법인 셈입니다.
같은 단어를 서로 다르게 부르는 문제
그런데 사람들은 왜 카테고리를 만들고, 굳이 속성까지 정의하려고 했을까요. 가장 큰 이유는 "같은 것을 다르게 부르는 문제" 를 해결하기 위해서입니다.
쉬운 예가 의료 시스템입니다. 같은 환자 "김환자(31세, 남성)" 의 정보를 두 병원이 이렇게 저장한다고 가정해 봅니다.
병원1 DB
PatientName: "김환자"
PatientGender: "Male"
PatientYearsold: "31"
병원2 DB
Client: "김환자"
Type: "M"
Age: "31"같은 사람을 가리키는 데이터지만, 필드명도 다르고 값의 표기(Male vs M) 도 다릅니다. 사람의 눈에는 같은 환자임이 분명해도, 기계 입장에서는 이 둘이 같은 대상이라는 사실을 알 길이 없습니다. 이런 상태로는 시스템 간 데이터를 합치거나, AI 가 두 데이터를 함께 추론하기가 어렵습니다.
같은 문제가 비즈니스 용어에서도 늘 발생합니다. "고객(Customer)" 이라는 단어 하나만 봐도 개발팀은 User, CRM 팀은 Contact, 기획팀은 회원 으로 부르고, 분석팀은 구매자 와 방문자 를 다르게 봅니다. 이름은 비슷하지만 가리키는 대상이 다 다릅니다.
같은 단어를 쓰는 것 같지만 사실은 서로 다른 대상을 가리키고 있다면, 어떤 시스템도 그 데이터를 신뢰할 수 없습니다.
장님 여러 명이 같은 코끼리를 만지면서 누구는 부채, 누구는 기둥, 누구는 뱀이라고 말하는 우화와 똑같습니다. 온톨로지는 이 혼란을 줄이기 위해 "우리가 어떤 단어를, 어떤 의미로, 어떤 관계 안에서 사용한다" 는 합의를 명시적으로 적어 두는 작업입니다.
톰 그루버가 정의한 4가지 조건
학술적으로 가장 널리 쓰이는 정의는 1993년 컴퓨터 과학자 톰 그루버(Thomas Robert Gruber) 가 제시한 것입니다. 그는 온톨로지를 "공유된 개념화에 대한 명시적 명세(an explicit specification of a shared conceptualization)" 라고 정의했습니다.
이 짧은 문장 안에 네 가지 조건이 들어 있습니다.
- 개념화(Conceptualization): 우리가 다루려는 대상에 대한 추상적 모델
- 명세(Specification): 머릿속에 있는 개념을 명확한 언어나 기호로 기록하는 것
- 명시적(Explicit): "알아서 알겠지" 라는 모호함을 없애고, 모든 개념과 관계를 또렷하게 정의
- 공유된(Shared): 나 혼자 쓰는 것이 아니라, 여러 사람 혹은 여러 시스템이 합의한 약속
온톨로지는 머릿속의 모호한 이해를 명시적이고 공유된 약속으로 옮기는 작업입니다. 이 약속이 없으면 데이터도, 추론도 의미를 가질 수 없습니다.
핵심은 "공유" 와 "명시" 입니다. 한 사람이 혼자 정리한 문서는 온톨로지라기보다 메모에 가깝습니다. 여러 사람과 시스템이 같은 규칙을 따를 수 있도록 적어 두는 것이 온톨로지가 갖춰야 할 첫 번째 조건입니다.
Taxonomy 와 Ontology 의 결정적 차이
온톨로지를 처음 접할 때 가장 많이 헷갈리는 것이 분류 체계(Taxonomy) 와의 차이입니다. 둘 다 무언가를 정리하는 도구지만, 본질이 다릅니다.
도서관에서 "총균쇠 같은 책을 추천해 주세요" 라고 부탁했다고 해 봅시다. Taxonomy 기반 시스템은 "국내도서 > 인문 > 인문학" 카테고리에 함께 묶여 있는 책을 그대로 추천합니다. 그래서 "손자병법" 이 추천될 수도 있습니다. 같은 카테고리에 있다는 사실 외에는 추천 근거가 없기 때문입니다.
Ontology 기반 시스템은 다릅니다. "총균쇠" 라는 책 자체의 속성(거시적 역사, 환경결정론, 학제간 융합, 인과관계 추적) 과 다른 책들의 속성을 비교해서 가장 비슷한 책을 찾습니다. 그 결과 "사피엔스", "지리의 힘", "어제까지의 세계" 같은 책이 추천됩니다.
| 항목 | Taxonomy | Ontology |
|---|---|---|
| 추천 근거 | 동일한 카테고리 분류 | 도서의 속성과 속성 간 관계 |
| 설명 가능성 | 없음 | 근거가 정의되어 있어 추론으로 설명 |
| 개인화 | 불가능(분류 기준에 종속) | 가능(속성별 가중치 적용) |
| 추천 실패 시 | 원인 파악 불가 | 어떤 속성 해석이 달랐는지 추적 가능 |
Taxonomy 는 "무엇이 같은 칸에 있는가" 를, Ontology 는 "무엇이 어떤 속성과 관계로 연결되어 있는가" 를 본다. 이 차이가 추천 품질과 설명 가능성을 가른다.
AI 시대에 온톨로지가 부각되는 이유가 여기에 있습니다. 단순한 분류로는 "왜 이 결과가 나왔는가" 를 설명할 수 없지만, 속성과 관계를 명시한 온톨로지 기반 시스템은 모든 답에 근거를 제시할 수 있습니다.
온톨로지의 3요소: Class, Instance, Property
실제 온톨로지는 세 가지 구성 요소로 만들어집니다. 어려운 이론이지만 피자 한 판으로 충분히 풀립니다.
Class(클래스) 는 개념을 정의하는 뼈대입니다. 같은 속성을 가진 대상을 묶는 카테고리입니다. 예를 들어 "피자" 는 "도우 위에 토핑과 치즈를 얹어 구워낸 음식" 이라는 개념을 가진 클래스입니다. "동물", "도시", "한식" 모두 클래스입니다.
Instance(인스턴스) 는 클래스에 속하는 실제 개체입니다. 피자 클래스의 인스턴스로는 "마르게리따", "페퍼로니" 가 있습니다. 도시 클래스의 인스턴스는 "서울", "도쿄", "뉴욕" 이고, 한식 클래스의 인스턴스는 "비빔밥", "닭도리탕", "부대찌개" 입니다.
Property(속성) 는 클래스나 인스턴스의 특성을 설명하거나, 다른 개체와 연결 고리를 만드는 정의입니다. 속성은 두 갈래로 나뉩니다. 객체 속성(Object Property) 은 인스턴스와 인스턴스를 잇고, 데이터 속성(Data Property) 은 인스턴스와 구체적인 값(literal) 을 잇습니다.
피자 클래스를 3요소로 정리하면 이렇게 됩니다.
Class: 피자
Subclass: 토마토 피자 > 마르게리따
Property: 가격, 토핑, 칼로리, 도우
Instance: 마르게리따
(가격 25,000원, 칼로리 2,000Kcal, 토핑: 바질 + 모짜렐라)세상의 모든 클래스는 결국 더 큰 클래스의 인스턴스로 존재한다. 이 재귀적 구조가 온톨로지를 강력하게 만든다.
이 세 가지(Class, Instance, Property) 만 정의되면 그 다음 단계로 추론이 가능해집니다. 추론이 바로 온톨로지의 진짜 가치입니다.
입력하지 않은 사실도 추론하는 능력
온톨로지가 분류 체계나 일반 데이터베이스와 결정적으로 다른 지점은 "추론(Reasoning)" 입니다. 추론은 입력되지 않은 정보를 논리적 규칙에 의해 기계가 스스로 도출해 내는 능력입니다.
가장 직관적인 예가 삼단논법과 전이성(Transitive) 입니다. 다음 두 가지 사실을 시스템에 입력한다고 해 봅니다.
fact A: 강남구는 서울의 일부이다 (partOf).
fact B: 서울은 한국의 일부이다 (partOf).
rule: partOf 속성은 전이적(Transitive)이다.
이 세 줄만 있으면, "강남구가 한국의 일부이다" 라는 사실을 별도로 입력하지 않아도 시스템이 스스로 결론을 만들어 냅니다. 사람이 일일이 모든 관계를 데이터에 적어 둘 필요가 없어지는 것입니다.
조금 더 학술적인 영역으로 들어가면 기술 논리(Description Logic, DL) 가 나옵니다. 대표적으로 ALC 언어가 있는데, 클래스를 대문자, 인스턴스와 속성을 소문자로 표기하고 다음과 같은 연산자를 사용합니다.
A ∩ B: A 와 B 의 교집합. 두 클래스 모두에 속하는 모든 요소A ∪ B: A 와 B 의 합집합. 어느 한쪽 이상에 포함된 모든 요소∀r.C: 관계 r 을 통해 오직 클래스 C 의 인스턴스와만 연결된 대상
예를 들어 Girls ∩ ∀loves.Car 라는 식은 "오직 자동차만 좋아하는 소녀들" 을 뜻합니다. 자연어로 풀어 쓰면 한 문장이 되는 내용을, 이 짧은 식 하나로 정확하게 표현할 수 있습니다. 사람과 기계가 모두 동의할 수 있는 형식이라는 점이 중요합니다.
추론이 없는 데이터는 단순한 기록일 뿐입니다. 추론이 더해질 때 비로소 데이터가 "이해" 가 됩니다.
구글 지식 그래프, 넷플릭스, 팔란티어의 공통점
이론은 충분히 다뤘으니 현실 사례로 넘어가 봅니다. 세 회사 모두 사용자가 매일 쓰는 서비스인데, 그 뒤에는 정교한 온톨로지가 있습니다.
구글: 2012년에 일어난 "Strings 에서 Things 로" 전환
2012년 이전의 구글 검색은 단어(Strings) 를 모아 둔 인덱스였습니다. "레오나르도 다 빈치" 를 검색하면 위키백과 링크와 블로그 글 목록이 나올 뿐이었습니다.
2012년 이후 검색 결과 상단에 지식 패널(Knowledge Panel) 이 등장합니다. 다 빈치의 생애, 대표작, 가족 관계, 연관 인물이 카드 형태로 한눈에 정리되어 표시됩니다. 이것이 가능해진 이유는 구글이 웹상의 텍스트를 단순 수집하는 것을 넘어, 개체(Entity) 를 이해하기 시작했기 때문입니다.
"서장훈 키" 를 검색했을 때 구글이 207cm 라는 숫자를 정확히 화면 상단에 보여주는 메커니즘도 마찬가지입니다. 단어 매칭이 아니라, 온톨로지 그래프에서 "서장훈" 노드를 찾고, hasHeight 속성을 따라가서 그 값을 가져오는 방식입니다.
구글은 수십억 개의 사실(Fact) 을 온톨로지 형태로 연결해 두었다고 공식적으로 밝힌 바 있습니다. 이것이 "Strings 에서 Things 로" 라는 검색 패러다임 전환의 본질입니다.
넷플릭스: 콘텐츠 자체의 속성으로 추천한다
넷플릭스가 사용자의 취향을 잘 맞히는 비결도 온톨로지입니다. 단순한 협업 필터링("이걸 본 사람이 저것도 봤어요") 만으로는 한계가 분명합니다. 신규 가입자나 신작 영화는 데이터가 부족하기 때문입니다. 이른바 콜드 스타트 문제입니다.
넷플릭스는 영화를 "액션", "로맨스" 같은 큰 장르로만 묶지 않습니다. 분위기(어두운, 기괴한, 희망찬), 특징(강한 여전사, 복잡한 플롯, 반전 결말), 배경(1980년대, 디스토피아, 우주) 같은 수천 개의 마이크로 장르(Micro-genres) 태그를 영화마다 부여하고, 이 속성들을 온톨로지로 연결합니다.
내가 "기묘한 이야기" 를 재미있게 봤다면, 시스템은 "1980년대 배경 + 초자연적 현상 + 청소년들의 모험" 이라는 속성 조합을 가진 다른 작품, 예를 들어 "E.T." 나 "구니스" 를 추천할 수 있습니다. 두 작품을 동시에 본 사람이 한 명도 없어도 가능한 추천입니다.
의미적 유사성(Semantic Similarity) 기반 추천은 두 콘텐츠를 같이 본 사용자가 없어도 작동합니다. 속성과 관계를 통한 추론이 협업 필터링의 한계를 풀어 줍니다.
팔란티어: 디지털 트윈과 자동 관계 추적
팔란티어(Palantir) 의 파운드리(Foundry) 플랫폼은 여기서 한 단계 더 나아갑니다. 현실 세계의 물리적 자산, 프로세스, 조직까지 디지털 복제본으로 만드는 "디지털 트윈" 을 지향합니다.
가령 항공사 정비 담당자가 "최근 엔진 진동 이상이 있었던 항공기의 터빈 블레이드 상태를 확인하고 싶다" 고 묻는다고 해 봅시다. 온톨로지 없이 데이터만 있는 환경에서는 사람이 직접 여섯 단계에 걸쳐 SQL 을 짜야 합니다. 센서 테이블에서 vibration_sensor_id 찾고, 항공기 마스터 테이블과 조인하고, 부품 테이블에서 turbine_blade 코드 찾고, 정비 이력 테이블과 또 조인하고, 임계값 기준 테이블을 참조해서 "이상" 을 정의하고, 마지막에 결과 쿼리를 짜는 식입니다.
온톨로지로 모델링된 시스템은 이 흐름을 시스템이 자동으로 따라갑니다. 진동 센서 → 엔진 → 터빈 블레이드 → 정비 이력으로 관계가 이미 명시되어 있기 때문에, 사용자는 자연어로 묻기만 하면 됩니다. 결과적으로 "이 소재의 터빈 블레이드가 12,000시간 이후 진동 증가 패턴을 보인다" 같은 인사이트가 즉시 나옵니다.
데이터만으로는 질문이 분석이 되지 못합니다. 데이터 위에 온톨로지가 얹혀야 비로소 질문이 답이 됩니다.
3줄 요약
- 온톨로지는 AI 시대의 새 단어가 아니라, 아리스토텔레스에서 시작해 톰 그루버가 학술적으로 정의한 "공유된 개념화의 명시적 명세" 다.
- 핵심 구성은 Class·Instance·Property 3요소이며, 분류만 하는 Taxonomy 와 달리 속성과 관계로 추론까지 가능하다.
- 구글 검색, 넷플릭스 추천, 팔란티어 디지털 트윈이 모두 같은 자리에서 출발한다. 도메인을 얼마나 또렷하게 정의해 두었는가가 결과를 가른다.
마무리: 도구를 배우기 전에, 현실을 정의하는 언어를 익히기
AI 시대에 사람들이 가장 자주 묻는 질문은 "어떤 도구를 써야 하나요" 입니다. 그런데 정작 도구가 잘 동작하기 위해 필요한 것은, 그 도구가 다룰 현실이 어떻게 정의되어 있느냐입니다. 데이터의 양이나 모델의 크기가 아니라, "우리는 이 단어를 이 의미로 사용한다" 는 약속이 얼마나 정교하게 적혀 있는가가 결과를 가릅니다.
구글이 검색 결과의 의미를 바꾼 것도, 넷플릭스가 한 번도 보지 않은 작품을 추천하는 것도, 팔란티어가 흩어진 데이터에서 인과를 끌어내는 것도 모두 같은 자리에서 출발합니다. 자기 도메인을 어떻게 정의해 두었는가입니다.
온톨로지는 그 정의를 명시적으로 적어 두는 가장 오래된 방법이고, AI 가 등장한 지금 다시 가장 필요한 방법이 되었습니다. 누군가의 도구를 배우기 전에, 우리가 다루는 현실을 또렷한 문장으로 적어 두는 연습부터 시작해 보면 어떨까 싶습니다.
도구의 역량은 우리가 그 도구에게 건넨 정의의 정교함을 넘지 못합니다. AI 시대를 살아갈 가장 단단한 무기는 결국 자기 도메인을 또렷한 언어로 적어 두는 연습에서 만들어질지 모릅니다.
