온톨로지

실무에서는

온톨로지가 곧 소프트웨어입니다. ObjectStack에서 온톨로지는 호스팅 플랫폼 안의 한 계층이 아니라 애플리케이션 자신의 정의 — 객체와 필드, 관계, 액션, 권한, 플로우, 에이전트와 도구 정의 — 이며, 런타임이 이를 실행합니다. 데이터베이스, REST API, 화면, MCP 도구가 모두 여기서 파생되고, 권한과 감사는 모든 호출에서 강제됩니다. 이 단어에는 네 가지 경계가 따라옵니다. 첫째, 이것은 실행 가능한 온톨로지이지 지식 표현 온톨로지가 아닙니다. 상속도, 공리도, 추론기도 없으며, 정의는 검증된 뒤 실행됩니다. 둘째, 기존 시스템 위에 얹는 시맨틱 레이어가 아닙니다. 이것이 시스템 자체이며, 외부 데이터소스 페더레이션은 기본적으로 읽기 전용이고 아직 초기 단계입니다. 셋째, 뷰, 대시보드, 앱, 번역은 온톨로지의 투영이지 온톨로지의 일부가 아닙니다. 넷째, 코드는 사라지지 않습니다. 훅, 액션 본문, CEL, 제약된 JSX의 형태로 런타임 안으로 옮겨 갈 뿐입니다.

이 단어는 철학에서 왔고, 지식 공학을 거쳐 엔터프라이즈 소프트웨어에 들어왔습니다. 지식 공학에서 온톨로지는 소프트웨어가 추론할 수 있도록 한 도메인을 형식적으로 모델링한 것, 즉 그 도메인의 클래스와 속성, 관계를 뜻합니다. 이 실무적인 의미는 좁지만 유용합니다. 온톨로지는 타입(고객, 작업 지시, 장비)과 각 타입이 지닌 속성, 타입 사이의 연결을 조직 전체를 위해 한 번 명명하며, 바로 이 점이 온톨로지와 데이터베이스 스키마를 가릅니다. 스키마는 한 애플리케이션이 자기 행을 어떻게 저장하는지를 기술하고, 온톨로지는 비즈니스가 말하는 "고객"이 무엇인지를 십여 개의 시스템과 리포팅 도구, 그리고 모델이 모두 같은 방식으로 해석할 수 있게 기술합니다. 2026년에 대부분의 사람이 떠올리는 것은 Palantir Foundry이고, 그 모델링 품질은 실제로 높습니다. Microsoft Fabric IQ와 Google의 엔터프라이즈 지식 그래프도 같은 계층으로 들어오고 있습니다.

대부분의 온톨로지 작업은 위험이 시작되는 지점 바로 한 걸음 앞에서 멈춥니다. 검색(retrieval) 수준의 온톨로지는 읽기 모델입니다. 에이전트가 비즈니스에 대해 조리 있게 말하게 해 주지만, 에이전트가 무언가를 바꿔야 할 때 무슨 일이 일어나는지에 대해서는 아무것도 말하지 않습니다. 이를 완성하는 능력은 선언되고 권한 검사를 거치는 쓰기 작업, 즉 액션(action)이며, 같은 정의에 붙은 권한 및 감사 규칙이 그 곁에 함께 놓입니다. Palantir가 수년 동안 쓰기를 거버넌스가 적용된 액션으로 모아 온 공로는 인정받아야 합니다. 열린 질문은 그 설계가 옳은가가 아니었습니다.

열린 질문은 그 파일을 누가 쥐고 있느냐입니다. ObjectStack에서 이 정의는 곧 여러분의 비즈니스 온톨로지입니다. 개방되어 있고, 버전 관리되며, 여러분의 저장소에 있는 여러분의 것입니다. 프레임워크 곳곳에 흩어진 코드도 아니고, 벤더 시스템 안에 갇힌 그래프도 아닙니다. 읽고, diff하고, 다른 호스트로 옮길 수 있는 정의는, 똑같이 훌륭하더라도 벤더 엔진 안에 살면서 재구축으로만 이전되는 정의와는 다른 자산입니다. 온톨로지가 AI 에이전트를 올바르게 만들어 주지는 않습니다. 비즈니스를 잘 모델링하는 일은 여전히 느리고 이견이 많은 사람의 일이며, 어떤 형식도 그 과정을 건너뛰게 해 주지 않습니다. 형식이 결정하는 것은 그보다 좁습니다. 결과물이 에이전트가 통째로 담을 수 있을 만큼 작은지, 작성 시점에 에이전트의 실수를 거부할 만큼 엄격한지, 처음 작성된 플랫폼보다 오래 살아남을 만큼 이식 가능한지입니다.