Palantir Ontology 개념 정복: 데이터가 아니라 '결정'을 표현하는 운영 레이어

들어가며: Ontology는 데이터가 아니라 '결정'을 표현한다

대부분의 데이터 플랫폼은 데이터를 잘 모으고 잘 보여주는 데 집중합니다. Palantir Foundry의 Ontology는 한 걸음 더 나아갑니다. 공식 문서의 표현을 빌리면, Ontology는 "기업의 데이터가 아니라 기업의 결정(decisions)을 표현"하며 "데이터 중심이 아니라 결정 중심(decision-centric)" 입니다. 이 글은 Foundry Ontology 문서를 따라가며, Ontology가 무엇이고 왜 필요하며 어떤 구성요소로 이뤄지는지, 그리고 어떤 애플리케이션이 그 위에서 동작하는지를 한국어로 정리한 개념 노트입니다.

Ontology란 무엇인가: 운영 레이어와 디지털 트윈

문서는 Ontology를 "조직을 위한 운영 레이어(operational layer)"로 정의합니다. Ontology는 Foundry에 통합된 디지털 자산(dataset, virtual table, model) 위에 얹혀, 그것들을 현실 세계의 대응물과 연결합니다. 그 결과 Ontology는 "조직의 디지털 트윈(digital twin)" 역할을 하며, 두 종류의 요소를 함께 담습니다. 하나는 의미를 담는 semantic(의미) 요소(object, property, link)이고, 다른 하나는 변화와 실행을 담는 kinetic(운동) 요소(action, function, 동적 보안) 입니다.

이 둘을 나눠 보는 시각이 Ontology를 이해하는 핵심입니다. 의미 레이어에서는 데이터 소스가 세 가지 주요 구성요소로 매핑됩니다. 조직 내 실체를 나타내는 object type, 그 실체의 속성인 property, 그리고 object들 사이의 관계인 link type입니다. 이 레이어는 단순한 데이터 카탈로그를 넘어, 모든 필드에 풍부한 메타데이터를 부여하고 모든 변경에 세밀한 보안·거버넌스를 적용합니다. 운동 레이어에서는 운영자의 입력을 포착하고 의사결정 과정을 오케스트레이션하는 action type과, 임의의 복잡도를 가진 비즈니스 로직을 작성하는 function이 동작을 부여합니다. 여기에 object type의 형태와 능력을 기술하는 interface가 더해져, 공통 형태를 공유하는 object type들을 일관되게 다루는 다형성(polymorphism)을 제공합니다.

왜 Ontology인가: 운영적 결정의 네 구성요소

문서의 "Why create an Ontology?"는 Ontology가 통합하려는 대상을, 모든 운영적 결정을 이루는 네 가지 구성요소로 설명합니다. 데이터(Data), 로직(Logic), 액션(Action), 보안(Security)입니다.

데이터는 결정에 활용되는 정보입니다. Ontology는 이를 "기업의 전체 규모·전체 충실도(full-scale, full-fidelity) 의미 표현"으로 통합합니다. ERP·MES·WMS 같은 운영 데이터 소스, IoT·엣지 스트림, 비정형 저장소, 지리공간 데이터, 그리고 운영자가 일상 업무에서 만들어내는 "결정 데이터"까지 포괄하고, 언제 어떤 데이터 버전 위에서 결정이 내려졌는지를 추적하는 결정 계보(decision lineage)를 끝에서 끝까지 남깁니다.

로직은 결정이 "어떻게" 내려지는지를 규정하는 계산과 프로세스입니다. 핵심 시스템의 비즈니스 로직, 클라우드 데이터 과학 워크벤치의 예측 모델, 최적화 모델처럼 이질적인 추론 자산을 연결하고 맥락화합니다. 문서는 이를 위한 "logic binding" — 이질적 로직 자산을 결합하는 일관된 인터페이스 — 을 제공한다고 말합니다.

액션은 선택된 결정의 오케스트레이션과 실행입니다. 문서는 데이터 요소가 기업의 "명사(nouns)" 라면 액션은 "동사(verbs)"라고 표현합니다. 실시간으로 결정이 내려질 때 그 액션 루프를 닫는 것이야말로 운영 시스템을 분석 시스템과 구분 짓는 지점입니다. 액션은 시나리오로 안전하게 스테이징하고, 세밀한 접근 통제로 거버닝하며, 트랜잭션 시스템·엣지 장치·커스텀 앱 등 모든 기업 기반으로 안전하게 되써질(writeback) 수 있습니다.

보안은 결정이 운영 정책을 준수한다는 보장입니다. marking·목적·역할 기반 정책을 결합하고, 데이터·로직·액션·앱 아티팩트에 걸친 동적 계보를 유지하며, 런타임에 정책을 계산해 행·열 수준 제한을 적용합니다. 도구 사용 권한도 데이터 접근을 통제하는 동일한 보안 아키텍처로 강제됩니다.

Onyx 사례로 보는 결정의 생애주기

문서는 가상의 의료기기 제조사 "Onyx Incorporated"가 공급 차질로 수술용 마스크 생산에 영향을 받는 시나리오로 이 네 요소가 어떻게 맞물리는지를 보여줍니다. 흐름은 네 단계입니다.

먼저 가시성 확보 단계에서, 흩어진 데이터가 비즈니스 언어를 반영하는 의미 object와 link로 종합되고, 민감 요소는 기본적으로 숨겨집니다. 에이전트도 인간과 같은 정책 아래에서 공급사 정보·재고·생산 지표·선적 명세·고객 피드백을 탐색합니다. 다음으로 시뮬레이션·해법 설계 단계에서, 자재 대체 시뮬레이션을 돌리고 그 결과를 샌드박스 부분집합인 ontology scenario로 스테이징하며, "Disruption Bot" 에이전트가 재배분 계획을 시나리오로 올려 사람의 검토를 받습니다. 결정 실행·액션 단계에서는 액션에 엄격한 통제·검증을 걸고, 배치 스테이징과 검토를 거쳐 이벤트별 상세 로깅과 함께 WMS(API)·ERP(네이티브 커넥터)·생산 계획(플랫 파일) 등 여러 시스템에 되씁니다. 문서의 표현대로, Ontology는 액션을 AI 에이전트와 자동화의 도구로 자동 노출하되 AI가 정해진 경계 안에서 안전하게 행동하도록 가드레일을 함께 제공합니다. 마지막 학습 단계 에서는 모든 데이터·로직·액션이 결정 계보로 포착되어, 미세조정의 학습 데이터, 에이전트 프롬프팅의 원칙, 워크플로 틈새에 갇힌 "암묵지(tribal knowledge)"를 드러내는 자료로 쓰입니다.

데이터 카탈로그와 무엇이 다른가

Ontology의 차별점은 세 가지 대비로 분명해집니다. 첫째, 전통적 데이터 아키텍처는 "의사결정에 들어가는 추론이나 그에 따르는 액션을 포착하지 못해 학습과 AI 도입을 제약"합니다. 둘째, 재래식 분석은 "계산을 실제 현실에 맥락화하지 못하고 운영과 단절"됩니다. 셋째, 데이터 중심 접근(예: RAG)은 단편적 검색에 머무는 반면, Ontology는 "상호 연결된 데이터·로직·액션 원시 요소"를 제공해 그 한계를 넘습니다. 요컨대 Ontology는 단순한 데이터 카탈로그가 아니라, 변화하는 조건·목표·결정을 실시간으로 표현해 AI 사용을 기업의 현실에 정박시키는 레이어입니다.

Ontology 안의 모델

문서의 "Models in the Ontology"는 AI/ML을 운영화하는 흐름을 네 단계로 정리합니다. Foundry에서 모델을 만들고, 직접 모델 배포를 구성하며, 모델을 감싸는 간단한 wrapper function을 게시한 뒤, 그 function을 Workshop·Vertex 같은 최종 사용자 앱에서 실시간 추론에 쓰는 것입니다. Ontology object는 Code Repositories dataset을 통해 배치 추론도 활용할 수 있습니다.

모델을 Ontology에 통합할 때의 이점은 세 가지로 제시됩니다. 첫째, 해석 가능성(interpretability) 입니다. 모든 모델링 결과가 object type의 property라는 현실 개념으로 정의되므로, 최종 사용자는 머신러닝을 이해하지 않고도 예측·추정·분류 같은 친숙한 용어로 결과를 다룹니다. 둘째, 규모의 경제입니다. 각 모델링 프로젝트가 특정 유스케이스를 위한 일회성 작업에 그치지 않고 시간이 지나며 서로 위에 쌓여 재사용됩니다. 셋째, 대규모 연결성입니다. 모델이 조직 로직의 단일 진실 소스인 Ontology에 통합되어 기업 전반의 시뮬레이션을 가능하게 합니다.

핵심 개념 정리

문서의 "Core concepts"는 Ontology의 구성요소를 dataset과의 유비로 또렷하게 정의합니다. 각 개념은 "스키마 정의"와 그 "개별 인스턴스"의 쌍으로 이해하면 깔끔합니다.

• Ontology: Foundry에 통합된 디지털 자산(dataset과 model) 위에 얹힌 풍부한 의미 레이어. 조직의 디지털 트윈.
• Object type: 현실의 실체나 사건에 대한 스키마 정의. 개별 인스턴스는 object, 그 모음은 object set. dataset이 행을 담듯, object type은 dataset 테이블과 유사한 역할.
• Property: 실체나 사건의 특성에 대한 스키마 정의. 개별 object의 특성 값이 그 인스턴스 (dataset의 개별 필드 값에 해당).
• Shared property: 여러 object type에 걸쳐 재사용되는 property. property 메타데이터를 중앙에서 관리해 모델링 일관성을 유지.
• Link type: 두 object type 사이 관계의 스키마 정의. 개별 인스턴스는 link로, dataset의 조인과 유사.
• Action type: 사용자가 한 번에 취할 수 있는 object·property 값·link의 변경 집합에 대한 스키마 정의(부수 효과 포함).
• Function: Ontology와 네이티브로 통합되는 로직. object와 object set을 입력으로 받고 object의 property 값을 읽을 수 있음.
• Interface: object type 다형성을 가능하게 하는 정의. 공통 형태를 공유하는 object type들을 일관되게 모델링·상호작용.
• Role: Ontology의 중심 권한 모델. Ontology 수준과 개별 리소스 수준에서 접근을 부여.
• Object View: 특정 object와 관련된 모든 정보·워크플로의 중심 허브.

Ontology를 아는 애플리케이션

마지막으로 문서는 Ontology 레이어 위에서 동작하는 애플리케이션들을 용도·워크플로 스타일· 구성 모델의 세 차원으로 비교합니다. Object Views는 한 object와 관련된 정보·워크플로의 중심 허브로, 전기적 데이터·연결된 object·관련 지표·임베드된 분석을 모읍니다. Object Explorer는 검색·분석 도구로, 검색 질의를 시각적으로 구성하고 object set을 탐색·비교하며 대량 Action을 취하고 다른 앱으로 내보낼 수 있습니다. 사전 구성이 필요 없어 덜 기술적인 사용자에게 적합합니다.

Quiver는 선형 드릴다운부터 분기·집계가 있는 복잡한 분석, 네이티브 시계열 분석, 읽기 전용 대시보드 템플릿까지 다룹니다. Workshop은 Ontology 위에서 코드 없이 포인트앤클릭으로 앱을 만드는 도구로, 정교한 이벤트 시스템을 갖춰 일반 대시보드보다 동적· 상호작용적입니다. Slate는 기술적 구성이 필요한 유연한 앱 빌더로, Ontology 레이어와 dataset에 직접 접근하며 웹 개발 패러다임 기반의 시각적 커스터마이징을 제공합니다. Map은 object와 데이터를 지리공간 맥락에서 분석합니다.

문서가 제시하는 비교 표를 옮기면 다음과 같습니다.

비교의 틀은 세 축입니다. 주요 용도는 Discovery(큐레이션된 허브·검색으로 정보·워크플로 찾기), Analysis(단순부터 복잡까지 폭넓은 질문에 답하기), Dashboards(주로 읽기 전용으로 소비되는 사전 구성 시각화), Applications(특정 사용자군이 특정 문제를 푸는 상호작용형 운영 인터페이스)로 나뉩니다. 워크플로 스타일은 사용자가 분석 경로를 직접 정하는 Exploratory와 빌더가 미리 구성하는 Workflow-specific으로, 구성 모델은 설정이 거의 필요 없는 Walk-up usable과 상당한 선행 투자가 필요한 Customizable로 갈립니다.

마치며

Ontology 개념의 뼈대를 다시 정리하면 다음과 같습니다.

• Ontology는 데이터가 아니라 결정을 표현하는 운영 레이어이자 조직의 디지털 트윈이다.
• 두 레이어로 본다 — 의미(object·property·link)와 운동(action·function·동적 보안), 그리고 다형성을 주는 interface.
• 모든 운영적 결정은 데이터·로직·액션·보안 네 요소로 이뤄지며, Ontology는 이를 하나로 통합하고 결정 계보로 학습 가능하게 만든다.
• 데이터 카탈로그·재래식 분석·단순 RAG와의 차이는 "추론과 액션까지 포착해 운영에 연결"한다는 점이다.
• 모델을 Ontology에 통합하면 결과가 property로 표현되어 해석 가능하고, 재사용으로 규모의 경제가 생긴다.
• 핵심 구성요소는 dataset 유비로 정의된다 — object type↔테이블, property↔필드, link type↔조인.
• Ontology 위 애플리케이션은 용도·워크플로·구성 모델의 세 축으로 갈린다(Object Explorer는 walk-up, Workshop/Slate는 customizable).

Ontology의 진짜 가치는 "데이터를 어떻게 저장하느냐"가 아니라 "조직의 결정을 어떻게 표현하고 실행 가능하게 만드느냐"에 있습니다. 데이터·로직·액션·보안을 한 레이어로 묶었기에, 인간과 AI 에이전트가 같은 의미·같은 가드레일 위에서 함께 일할 수 있습니다.

이 글에서 다루지 못한 세부 주제

다음은 코어 개념 페이지가 별도 하위 문서로 위임해 이 글에서 깊이 다루지 못했습니다. property의 기본 데이터 타입(base types), link type의 카디널리티(one-to-one/one-to-many/many-to-many), object를 뒷받침하는 데이터소스 backing과 object set 연산의 구체, 그리고 Ontology 설계의 모범 사례·구조적 가이드·안티패턴(별도의 설계 가이드 글에서 다룹니다)입니다.