온톨로지

온톨로지(Ontology)

단어를 처음 들으면 철학 교재에서나 볼 것 같은 단어처럼 들립니다. 실제로 그렇습니다.

이 오래된 개념이 지금 팔란티어의 핵심 제품 아키텍처가 됐고, 옵시디언 커뮤니티에서 가장 많이 논의되는 주제가 됐으며, LLM의 환각률을 63%에서 1.7%로 낮추는 도구가 됐습니다.

어떻게 그렇게 됐는지를 처음부터 따라가봅니다.

1. 철학에서 컴퓨터로

그리스어 ontos(존재)와 logos(학문)의 합성어입니다. 17세기 초 라틴어 ontologia로 문자화됐고, 철학에서는 "존재하는 것들의 분류 체계"를 다루는 형이상학의 한 분야였습니다. 아리스토텔레스의 범주론(Categories)이 원점입니다. 동물은 생물이고, 생물은 물질이고 — 이런 계층 구조로 세상을 분류하는 방식입니다.

이것이 컴퓨터 과학에 들어온 건 1970~80년대입니다. AI 연구자들이 지식을 기계가 처리할 수 있는 형태로 표현하는 방법을 찾으면서, 개념과 개념 사이의 관계를 명시적으로 기술하는 이 방식을 가져왔습니다.

Stanford의 Tom Gruber가 1993년 정의를 확립합니다. "An explicit specification of a conceptualization." — 개념화의 명시적 명세. 지금도 인용되는 컴퓨터 과학 분야 온톨로지의 표준 정의입니다. 철학적 의미와 다른 점은 "목적을 위해 설계된 인공물"이라는 점입니다. 세상을 이해하기 위한 것이 아니라 기계가 처리하기 위한 것.

2. Cyc — 상식을 코딩하려는 10년 프로젝트

1984년 7월, Doug Lenat이 MCC(Microelectronics and Computer Technology Corporation)에서 Cyc 프로젝트를 시작합니다. 일본의 5세대 AI 프로젝트에 대한 미국의 대응이었습니다. 목표는 단순했습니다. 인간의 상식 전체를 컴퓨터에 인코딩한다.

10년을 작업했습니다. 6,000만 달러와 600인년(person-years)이 투입됐습니다. 성과물:

• 1994년: 온톨로지 항목 약 10만 개, 지식 베이스 약 100만 어서션
• 2002년: OpenCyc 공개 (개념 6,000개, 사실 6만 개)
• 2012년: OpenCyc 4.0 — 개념 239,000개, 사실 209만 개
• 2017년: 전체 Cyc — 약 150만 항목, 2,450만 어서션

그리고 실패했습니다. ML 과학자 Pedro Domingos는 이를 "catastrophic failure"라고 표현했습니다. 왜 실패했을까요?

수작업으로 공리(axiom)를 작성하는 방식의 근본적인 한계입니다. 언어는 컨텍스트에 따라 의미가 달라집니다. "나는 은행에 갔다"에서 '은행'이 강변인지 금융기관인지를 기계에게 가르치려면 수천 개의 추가 규칙이 필요합니다. 새로운 도메인이 생길 때마다 새 공리를 써야 합니다. 자가진화가 불가능합니다. 세상은 Cyc가 코딩할 수 있는 속도보다 빠르게 변했습니다.

3. WordNet — 다른 방향의 시도

같은 시기, 심리학자 George A. Miller가 Princeton에서 다른 접근을 시도합니다. 1985년 시작된 WordNet은 인간의 의미 기억을 심리언어학 이론에 기반해 구축하는 프로젝트였습니다.

Cyc가 세상의 모든 지식을 코딩하려 했다면, WordNet은 언어 자체의 의미 구조를 포착하려 했습니다. 단어를 "synset"(동의어 집합)으로 묶고, 이 집합들 사이에 hypernymy(is-a 관계) 계층을 구축합니다. 자동차 is-a 탈것, 탈것 is-a 물체.

지금도 살아있는 프로젝트입니다. 155,000개 이상의 단어, 117,000개 이상의 synset. NLP 연구의 기반 데이터셋으로 수십 년째 사용됩니다. Cyc와 달리 WordNet이 살아남은 이유는 범위를 제한했기 때문입니다. 세상 전체가 아니라 언어만 다뤘습니다.

4. 시맨틱 웹 — 웹 전체를 온톨로지로 만들려는 시도

2001년 5월, Scientific American에 논문 하나가 실립니다. Tim Berners-Lee, James Hendler, Ora Lassila의 "The Semantic Web". 인터넷을 발명한 사람이 쓴 논문이었습니다.

비전은 거대했습니다. "A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities." 소프트웨어 에이전트가 웹을 돌아다니며 여행 예약, 의료 정보 취합, 복잡한 법률 분석을 자동으로 수행하는 세상. 모든 웹 페이지가 기계가 읽을 수 있는 의미 정보를 담은 세상.

이를 위한 기술 스택이 만들어졌습니다.

RDF(Resource Description Framework): 데이터와 관계를 주어-서술어-목적어의 트리플로 표현하는 언어. <고양이> <is-a> <포유류>.

OWL(Web Ontology Language): W3C 표준. 공통 어휘를 정의하고 추론 규칙을 기술합니다. OWL에서는 "고양이 is-a 포유류, 포유류 is-a 동물"을 정의하면 "고양이 is-a 동물"을 자동으로 추론할 수 있습니다.

SPARQL: RDF 데이터를 쿼리하는 언어. SQL과 유사하지만 그래프 데이터에 특화.

그리고 이것도 실패했습니다. 문화유산 분야 등 일부 틈새에서 살아남았지만, 웹 전체를 바꾸겠다는 원래 비전은 달성되지 못했습니다.

왜 실패했는가?

Cory Doctorow가 2001년 "Metacrap"이라는 에세이에서 미리 예언했습니다. "A world of exhaustive, reliable metadata is a pipe-dream, founded on self-delusion, nerd hubris." 사용자가 자발적으로 정확한 메타데이터를 입력할 것이라는 가정이 틀렸습니다. HTML <meta> 태그를 검색엔진들이 이미 포기했던 전례가 있었습니다. 스팸 목적으로 메타데이터를 조작하는 건 항상 가능했으니까요.

기술 자체도 너무 복잡했습니다. XML 기반 표준이 개발자들을 멀어지게 했습니다. JSON 같은 실용적인 포맷이 RDF보다 훨씬 빠르게 채택됐습니다. 표준이 실제 애플리케이션보다 먼저 만들어진 역설이었습니다. 개발자 입장에서 복잡한 RDF 표준을 쓸 이유가 없었습니다.

5. 팔란티어 온톨로지 — 다시 살아난 이유

2004년 창업한 팔란티어는 2010년대 중반부터 "Foundry 온톨로지"를 제품의 핵심에 놓습니다. 그런데 이것은 RDF/OWL 방식의 온톨로지가 아닙니다. 이름만 같고 다른 개념입니다.

팔란티어 공식 문서의 정의: "The Ontology sits on top of the digital assets integrated into the Palantir platform (datasets, virtual tables, and models) and connects them to their real-world counterparts."

조직의 모든 데이터를 비즈니스 관점의 개념으로 표현하는 운영 계층입니다. 학술적 추론이 아니라 실제 업무를 돌리는 것이 목적입니다.

팔란티어 온톨로지의 구성 요소

Link Type은 1-to-1, 1-to-many, many-to-many를 지원합니다.

3계층 아키텍처

팔란티어 온톨로지를 전통적 방식과 다르게 만드는 건 계층 구조입니다.

Semantic Layer: Objects, Properties, Links를 정의합니다. 이 부분만 보면 전통적 온톨로지와 비슷합니다.

Kinetic Layer: Actions와 Functions. 실세계 액션을 시맨틱 기반에 연결합니다. 객체를 조회하는 게 아니라 변경합니다. 여기가 핵심 차이입니다.

RDF/OWL은 지식을 표현하고 추론하는 도구입니다. SPARQL로 쿼리하면 결과가 나오고 끝입니다. 시스템이 데이터를 읽습니다. 쓰지 않습니다. "항공기 #A350-007의 엔진 교체 이력을 알려줘"라는 쿼리를 던지면 결과를 돌려주는 것까지가 전부입니다. 그 결과로 무언가를 실행하는 건 온톨로지 밖의 일입니다.

팔란티어의 Action Type은 다릅니다. Semantic Layer에 정의된 Object를 직접 변경하는 트랜잭션입니다. 예를 들어 DispatchTechnician이라는 Action은 다음을 한 번에 처리합니다.

1. Aircraft 객체에서 결함 코드를 읽고
2. Technician 객체 중 자격 조건이 맞고 현재 가용한 사람을 찾고
3. WorkOrder 객체를 새로 생성하고
4. 해당 기술자에게 알림을 발송하고
5. Aircraft.status를 under_maintenance로 업데이트

이 Action이 실행되면 온톨로지 안의 데이터가 실제로 바뀝니다. 외부 시스템에 사이드이펙트가 발생합니다. RDF/OWL은 이 루프 자체가 없습니다.

Function은 한 단계 더 나아갑니다. Python이나 TypeScript로 작성된 코드가 온톨로지 객체를 입력받아 계산을 수행합니다. calculateMaintenanceRisk(Aircraft) → RiskScore 같은 식입니다. 온톨로지 위에서 돌아가는 비즈니스 로직입니다.

결과적으로 팔란티어 온톨로지의 데이터 흐름은 단방향이 아닙니다. 읽기(OSS) → 판단(Function) → 쓰기(Action) → 다시 읽기의 루프입니다. 온톨로지가 정적인 지식 저장소가 아니라 운영 시스템의 심장이 되는 이유가 여기 있습니다.

Dynamic Layer: AI 주도 의사결정, 멀티스텝 시뮬레이션, 지속 학습. 온톨로지가 AI 에이전트의 컨텍스트 공급원이 됩니다.

백엔드 아키텍처

마이크로서비스로 구성됩니다.

• OMS(Ontology Metadata Service): Object Type, Link Type, Action Type의 메타데이터 정의 관리
• OSS(Object Set Service): 온톨로지 읽기(read) 처리
• Object Data Funnel: 데이터 쓰기 오케스트레이션. Foundry 데이터소스와 Action에서 오는 사용자 편집을 인덱싱

데이터는 이렇게 흐릅니다. 외부 데이터소스(데이터베이스, API, 파일) → Foundry 데이터셋 → 온톨로지 Object Type으로 매핑 → OMS 인덱싱 → 애플리케이션/LLM에서 쿼리.

RDF/OWL과 어떻게 다른가

팔란티어 공식 문서도 인정합니다. "data types in Foundry are inspired by similar concepts in RDF, OWL and XSD." 영감은 받았지만 다른 방향으로 갑니다.

결정적인 차이: 시맨틱 웹은 지식을 표현하고 추론하려 했습니다. 팔란티어는 지식을 기반으로 행동하려 합니다.

실제 고객 사례

Airbus: A350 항공기는 약 500만 개 부품이 여러 유럽 국가와 공장, 공급업체에 걸쳐 생산됩니다. 부품 지연이나 품질 이슈 데이터가 분산되어 항공기 완성 전까지 전체 가시성이 없었습니다. Foundry 온톨로지로 이 데이터를 통합한 결과, A350 납기를 33% 단축했습니다. Skywise 플랫폼은 100개 이상 항공사가 참여하며, 항공기당 최대 2만 개 센서에서 초당 20~100개 데이터 포인트를 처리합니다.

SOMPO Holdings (일본 보험/헬스케어): SOMPO Care의 요양 부문에서 이용자 건강 상태, 직원 교대, 케어 기록을 온톨로지로 통합해 최적 케어 개입을 위한 프론트라인 의사결정을 지원합니다. 8,000명 이상이 이 플랫폼을 일상 업무에 사용합니다.

BP: 석유·가스 운영 최적화로 10억 달러 절감을 보고했습니다.

미국 국방부: 2025년 단일 연도 계약 8억 달러 이상.

AIP와 LLM 통합

팔란티어의 최근 방향은 온톨로지를 AI의 컨텍스트 공급원으로 쓰는 것입니다. AIP Logic은 온톨로지와 LLM을 연결하는 노코드 환경입니다. Ontology Object를 컨텍스트로 쿼리하고, LLM 출력에 기반해 Ontology를 편집하는 루프입니다. 지원 LLM: xAI, OpenAI, Anthropic, Meta, Google.

팔란티어 MCP도 출시됐습니다. 외부 AI IDE와 에이전트가 Palantir 플랫폼에 연결해 온톨로지와 애플리케이션 컨텍스트를 얻어 데이터를 쿼리할 수 있습니다.

이 흐름이 의미하는 바: 온톨로지가 AI의 "사실 기반"이 됩니다. LLM은 언어를 잘 다루지만 조직의 실제 데이터 구조와 관계를 모릅니다. 온톨로지가 그 격차를 채웁니다. 실제 임상 연구에서 온톨로지 기반 LLM이 할루시네이션을 63%에서 1.7%로 낮춘 사례가 보고됐습니다.

6. 옵시디언에서 소규모로 구현하기

팔란티어는 기업 인프라 위에 구축한 온톨로지입니다. 개인이 비슷한 개념을 옵시디언에서 구현하려면 어떻게 해야 할까요?

먼저 현실적인 기대치를 설정해야 합니다. 옵시디언은 온톨로지 도구가 아닙니다. OWL의 자동 추론, Protégé의 스키마 강제, Neo4j의 완전한 타입 링크는 불가능합니다. 옵시디언 커뮤니티의 진단: "One simple missed feature that could turn Obsidian into a full-scale Personal Knowledge Graph is typed Links." — 링크 자체에 타입과 메타데이터를 붙이는 기능이 없다는 게 핵심 한계입니다.

그러나 핵심 아이디어 — 개념을 명시적으로 정의하고, 관계의 종류를 구분하고, 이를 쿼리할 수 있게 만드는 것 — 는 구현 가능합니다.

YAML 프론트매터로 타입 정의

옵시디언의 Properties 기능을 활용합니다.

---
type: concept          # 이 노트가 무엇인가
is-a:
  - "[Machine Learning](091fa912.html)"
part-of:
  - "[AI Systems MOC](160e9ba3.html)"
causes:
  - "[Gradient Vanishing](4038ee65.html)"
related:
  - "[Deep Learning](6a68b641.html)"
  - "[Neural Networks](6b347be0.html)"
---

type, is-a, part-of, causes, related — 관계의 종류를 명시적으로 구분합니다. 단순히 [링크](ee49a62e.html)를 다는 것과 다릅니다. 어떤 관계인지가 기록됩니다.

Dataview로 쿼리하기

이 메타데이터가 쌓이면 Dataview 플러그인으로 쿼리할 수 있습니다.

TABLE is-a, causes, related
FROM "concepts/"
WHERE type = "concept"
SORT file.name ASC

특정 개념의 원인 관계만 모아보거나, 특정 상위 개념의 하위 개념을 모두 나열하는 것이 가능합니다.

LIST FROM "concepts/"
WHERE contains(is-a, [Machine Learning](091fa912.html))

타입 링크 플러그인들

Juggl: 링크에 타입을 붙이는 문법을 제공합니다.

- painted [The Night Watch](138e9d2d.html)
- collaboratedWith [Jan Lievens](f1f1e0b4.html)

단, 핵심 제한이 있습니다: linkType은 단일 단어만 허용됩니다. has painted처럼 복합 관계 타입은 파싱이 안 됩니다.

Graph Link Types: Dataview API와 PIXI.js를 활용해 그래프 뷰에 링크 타입을 시각적으로 표시합니다.

obsidian-wikilink-types: 24개의 정의된 관계 타입 어휘를 제공합니다. @ 입력 시 자동완성됩니다. - prerequisite_for, parent_of, supports, contradicts, references 등

설계 철학이 명확합니다: "Be specific with types. Don't default to references when supports or contradicts is more precise."

MOC(Map of Content) 패턴

Nick Milo이 대중화한 방식입니다. 특정 주제의 다른 노트들로의 링크를 모은 특수 노트가 MOC입니다.

계층은 이렇게 됩니다.

Home MOC (볼트 전체 진입점)
  ├── AI MOC
  │     ├── Machine Learning MOC
  │     │     ├── Supervised Learning
  │     │     ├── Unsupervised Learning
  │     │     └── Reinforcement Learning
  │     └── NLP MOC
  └── Systems MOC

온톨로지의 계층 구조를 MOC로 근사할 수 있습니다. 단일 노트가 여러 MOC에 링크될 수 있어 폴더 구조보다 유연합니다.

실용적인 구현 원칙

작게 시작합니다. 관계 타입을 처음부터 너무 많이 정의하면 유지가 안 됩니다. is-a, part-of, causes, related 네 가지만으로도 충분히 구조적입니다.

일관성이 핵심입니다. 온톨로지의 가치는 스키마가 일관되게 적용될 때 나옵니다. 옵시디언은 일관성을 강제하는 장치가 없기 때문에, 템플릿을 만들어 새 노트 생성 시 자동으로 프론트매터 구조가 삽입되도록 하는 것이 좋습니다.

Dictionary 노트로 개념을 정의합니다. 각 핵심 개념에 정의 노트를 만들고, 다른 노트들이 이 정의 노트를 참조하게 합니다. 링크가 단순한 연결이 아니라 "이 개념을 사용한다"는 명시적 의미를 갖게 됩니다.

Dataview를 쿼리 언어로 씁니다. SPARQL 대신 Dataview가 옵시디언의 SPARQL입니다. 복잡한 추론은 안 되지만, 특정 속성으로 필터링하고 관계를 집계하는 수준은 가능합니다.

한계를 직시합니다

OWL에서 가능한 자동 추론은 옵시디언에서 불가능합니다. "고양이 is-a 포유류, 포유류 is-a 동물"을 정의해도 "고양이 is-a 동물"을 자동으로 추론해주는 엔진이 없습니다. 스키마 검증도 없습니다. 어떤 노트에 is-a 속성을 넣지 않아도 경고가 없습니다.

대규모로 가면 성능도 문제입니다. 수천 개의 노트에 그래프 플러그인을 돌리면 속도가 급격히 저하됩니다.

옵시디언 온톨로지는 "형식 온톨로지의 근사"입니다. Protégé나 Neo4j를 대체할 수 없습니다. 그러나 수백 개의 개념을 관계와 함께 구조화해두면, Claude 같은 AI와 연동할 때 훨씬 정밀한 컨텍스트를 제공할 수 있습니다. 단순 노트 모음과 온톨로지 구조화된 볼트에서 AI가 답하는 품질의 차이는 실제로 큽니다.

온톨로지가 다시 부상하는 이유

Cyc는 실패했고, 시맨틱 웹은 좌초했습니다. 그런데 온톨로지가 2024~2026년에 다시 주목받고 있습니다. 이유는 LLM이 만든 문제 때문입니다.

LLM은 언어를 잘 다루지만 구조화된 관계를 모릅니다. 조직의 특정 데이터가 어떤 관계인지, 어떤 엔티티가 어떤 속성을 갖는지를 알려주는 시스템이 필요합니다. 온톨로지가 정확히 그 역할입니다.

"Knowledge graphs provide the semantic context, constraints and explicit relationships that LLMs lack, enabling true reasoning like navigating a map of your business instead of just text retrieval."

Open Semantic Interchange Initiative — dbt Labs, Snowflake, Salesforce가 2025년 참여한 이니셔티브 — 의 출발도 같은 인식에서입니다. "AI systems need to understand what things are, how they relate, and what actions are possible."

아리스토텔레스가 존재를 분류한 방식이, 2,500년 뒤 AI에게 세상을 가르치는 핵심 방법이 됐습니다.