팔란티어 온톨로지 — 데이터 위에 "행동" 을 얹은 운영 계층을 공식 문서로 읽는다

온톨로지라는 말이 가리키는 것

팔란티어 문서에서 온톨로지(Ontology)는 학문 용어가 아니라 제품의 한 층 이다. 개요 문서는 이렇게 정의한다.

The Ontology is an operational layer for the organization. The Ontology sits on top of
the digital assets integrated into the Palantir platform (datasets and models) and
connects them to their real-world counterparts, ranging from physical assets like
plants, equipment, and products to concepts like customer orders or financial transactions.

데이터 레이크에는 테이블이 있고, 모델 저장소에는 모델이 있다. 온톨로지는 그 둘 위에 "공장", "주문", "거래" 처럼 현실의 이름 을 붙이고, 그 이름에 대해 무엇을 할 수 있는지를 정의하는 층이다. 문서가 밝히는 투자 목적은 한 문장이다. "The goal of investing in the Ontology is to facilitate better decision-making in an organization at scale."

이 글은 그 층이 어떻게 구성되는지를 팔란티어 공식 문서(palantir.com/docs/foundry)의 문장으로만 따라간다. 문서에 없는 것은 쓰지 않았다.

여섯 조각 — 의미와 운동

개요 문서는 온톨로지의 구성 요소를 두 무리로 나눈다. 조직의 의미(semantics) 를 정하는 것과 운동(kinetics) 을 정하는 것이다.

Defining the semantics of your organization happens by mapping existing datasources
into objects, properties, and links in the Ontology.

The kinetics of the organization—enabling change while complying with organizational
controls and governance—are defined in the Ontology using action types and functions.

핵심 개념 문서의 정의를 그대로 옮기면 여섯 조각이 된다.

조각	공식 정의
객체 타입(object type)	"the schema definition of a real-world entity or event"
속성(property)	"the schema definition of a characteristic of a real-world entity or event"
링크 타입(link type)	"the schema definition of a relationship between two object types"
액션 타입(action type)	"the schema definition of a set of changes or edits to objects, property values, and links that a user can take at once"
함수(function)	"a piece of code-based logic that takes in input parameters and returns an output"
인터페이스(interface)	"an Ontology type that describes the shape of an object type and its capabilities"

데이터베이스에 익숙한 사람을 위해 문서는 대응표도 준다. 데이터셋은 객체 타입에, 행은 객체에, 열은 속성에, 조인은 링크 타입에 해당한다. 그러니 앞의 세 조각(객체·속성·링크)까지는 "잘 정리된 스키마" 다. 팔란티어가 다른 데이터 플랫폼과 갈라지는 지점은 뒤의 세 조각이다. 스키마 위에 사람이 할 수 있는 행동(액션) 과 코드로 쓴 논리(함수) 를 같은 층에 둔다.

데이터셋이 객체가 되는 길

객체 타입은 어디서 데이터를 받는가. 객체 타입 개요 문서는 두 경로를 말한다.

Objects are created and displayed in user applications by adding backing datasources
or configuring actions that create objects of an object type in Ontology Manager.

즉 (1) 기존 데이터셋을 backing datasource 로 붙이거나, (2) 데이터셋 없이 액션으로만 객체를 만들 수도 있다. 문서는 직원(Employee) 객체 타입에 사내 디렉터리 데이터를 붙이는 예를 들고, 반대로 "모든 객체를 액션으로 만들 것이라면 backing datasource 없이 객체 타입을 만들 수 있다" 고 적는다.

데이터셋이 객체로 색인되는 과정은 Object Storage v2 의 Funnel 이 맡는다.

Funnel reads data from Foundry datasources (such as datasets, restricted views, and
streaming datasources) and user edits (from Actions) and indexes these data into
object databases. Funnel also ensures that indexed data is kept up-to-date as the
underlying datasources update.

여기서 중요한 문장은 "user edits (from Actions)" 가 데이터셋과 나란히 입력이라는 것이다. 원본 테이블에서 온 값과 사람이 화면에서 고친 값이 같은 색인으로 들어간다. 그러면 둘이 충돌하면 누가 이기는가.

편집이 원본과 충돌할 때의 규칙

이 부분이 온톨로지를 "읽기 전용 뷰" 와 다르게 만드는 핵심이고, 문서는 규칙을 명시한다.

the final state of an object is always determined by the user edits applied to it,
regardless of any future datasource updates for edited properties in the same object.

기본 전략에서는 사용자 편집이 항상 이긴다. 사람이 고친 속성은 원본 데이터셋이 뒤에 바뀌어도 덮이지 않는다. 다만 고치지 않은 속성은 원본 갱신을 그대로 받는다("An unedited property receives data update from the input datasource, and it is applied to the object").

삭제는 편집이 아니다. "Deletions are not considered an edit. Once a deletion is applied, the object is no longer visible regardless of datasource state." 그리고 같은 키로 객체가 다시 생기면 이전 편집을 물려받지 않는다("If the object is later recreated, it will not inherit the previous edits").

편집 전용 속성(edit-only property)은 더 강하다. 대안 전략("가장 최근 값 적용")을 골라도 "user edits will always apply regardless of the timestamp on the input datasource" 다.

이 규칙이 왜 있는가. 현장에서 담당자가 "이 설비는 점검 완료" 라고 표시했는데, 밤에 원본 시스템에서 옛 상태가 다시 내려와 표시가 지워지면 온톨로지는 아무도 믿지 않는 화면이 된다. 편집이 이기는 규칙은 그 신뢰를 지키는 장치다. 대신 원본에서 정말로 바뀐 값이 무시될 수 있으므로, 어떤 속성을 편집 가능하게 둘지가 설계의 핵심이 된다.

액션 — 트랜잭션, 검증, 부수 효과

액션 타입 문서는 액션을 이렇게 잡는다.

An Action in Foundry is a single transaction that changes the properties of one or
more objects, based on user-defined logic.

액션 하나는 객체·속성·링크의 변경 묶음이고, 매개변수(parameter)로 입력을 표준화하며, 제출 조건으로 권한을 검사한다. 문서의 예는 "인사 부서처럼 권한 있는 직원만 이 액션을 수행할 수 있게 검증" 하고, 제출 시 "관련 객체 사이의 링크를 자동으로 만드는 규칙" 을 포함하는 것이다. 부수 효과(side effect)로는 알림과 웹훅이 있고, 예시는 "옛 관리자와 새 관리자에게 변경을 알리는 알림" 이다.

그리고 이 문장이 액션이 왜 온톨로지에 있는지를 말한다.

the same action logic and validations can be made available across all user-facing
applications, ensuring consistent edits.

화면마다 따로 짠 "저장 버튼" 이 아니라, 온톨로지에 한 번 정의한 액션을 모든 화면이 같은 검증으로 쓴다. 규모 상한도 문서에 있다. 한 액션이 편집할 수 있는 객체는 기본 10,000개 이고, 더 큰 값은 요청으로 열린다.

함수 — 서버에서 도는 논리

함수 문서는 언어를 둘로 못박는다. "The languages supported by functions are TypeScript and Python." 함수는 온톨로지를 일급으로 다룬다.

This includes support for reading the properties of various object types, traversing
links, and flexibly making Ontology edits.

쓰임새로 문서가 든 것은 넷이다. Workshop(팔란티어의 앱 빌더)에 객체 집합이나 값을 돌려주기, "많은 객체를 갱신하는 복잡한 편집을 함수 기반 액션으로 표현하기", 파생 열에 변환 값 보여 주기, 차트용 집계. 실행 모델은 "executed on the server side in an isolated environment" 이고, 언어 모델과 함께 쓸 때를 위해 "결과를 점진적으로 스트리밍" 할 수 있다.

인터페이스 — 다형성

인터페이스는 여러 객체 타입이 같은 모양을 공유하게 한다. 문서의 예는 Facility 인터페이스에 위치·이름 같은 공통 속성을 두고, Airport·Manufacturing Plant·Maintenance Hangar 가 그것을 구현하는 것이다. 그러면 "workflows can interact with Airport, Manufacturing Plant, and Maintenance Hangar object types, either in aggregate or independently" 가 되고, 새 타입이 인터페이스를 구현하는 순간 기존 워크플로에 바로 들어온다. 인터페이스 속성은 "defined locally on the interface (recommended) or using shared properties" 로 정의하며, 한 객체 타입이 여러 인터페이스를 구현할 수 있다.

규모와 아키텍처 — 숫자로

Object Storage v2 문서가 밝히는 수치는 이렇다.

항목	문서의 수치
객체 타입 하나의 색인 처리량	"on the order of tens of billions of objects for a single object type"
객체 타입당 속성 상한	2,000개
액션 하나의 편집 객체 수(기본)	10,000개
증분 색인	모든 객체 타입에 기본 활성
OSv1(Phonograph) 폐기	2026년 6월 30일

v2 의 설계 요지는 한 문장이다. "by separating the subsystems responsible for indexing and querying data, Object Storage v2 can scale horizontally more easily to meet future needs." 색인하는 쪽과 질의하는 쪽을 떼어 놓았다는 뜻이다.

모델과 LLM 은 어디에 붙는가

모델 문서는 온톨로지 위에서 모델을 운영하는 순서를 넷으로 적는다. 모델을 만들고, 직접 배포(direct model deployment)를 구성하고, "모델을 감싸는 단순한 래퍼 함수를 공개" 한 뒤, 그 함수를 Workshop 같은 사용자 앱에서 실시간 추론에 쓴다. 모델의 결과는 "real-world concepts (properties of an object type)" 로 정의된다. 예측값이 별도의 기술 산출물이 아니라 객체의 속성이 된다는 뜻이다.

LLM 쪽은 AIP 다. AIP Logic 문서의 정의는 "a no-code development environment for building, testing, and releasing functions powered by LLMs" 이고, 그 함수는 입력으로 "Ontology objects or text strings" 를 받아 "return an output (objects and/or strings) or make edits to the Ontology" 한다. 즉 LLM 이 만든 논리도 결국 함수 라는 같은 조각으로 온톨로지에 들어가고, 편집은 액션과 같은 경로를 탄다. AIP 개요는 이 도구들이 "production-ready AI-powered workflows, agents, and functions on top of the Ontology" 를 만든다고 적는다.

개발자에게는 SDK

Ontology SDK(OSDK) 문서는 지원 경로를 이렇게 적는다. "The OSDK supports npm for TypeScript, pip or Conda for Python, Maven for Java, and OpenAPI spec for any other language." 온톨로지에서 함수와 타입을 생성하고, 토큰은 "scoped only to the ontological entities you want your application to access" 다. 객체 타입이 곧 코드의 타입이 되므로, 온톨로지를 고치면 SDK 를 다시 생성하는 것이 개발 흐름의 일부가 된다.

엔지니어의 눈으로 다시 읽기

팔란티어 온톨로지를 한 줄로 요약하면 "스키마 + 편집 규칙 + 행동 정의 + 논리를 한 층에 둔 것" 이다. 낯설게 들리지만, 대부분의 사내 시스템이 흩어진 채로 갖고 있는 것들이다. 테이블은 창고에, 저장 버튼의 검증은 앱마다, 배치 논리는 스케줄러에, 예측은 노트북에 있다. 온톨로지는 그것을 한 자리에 모으고, "누가 어떤 객체를 어떻게 바꿀 수 있는가" 를 그 자리에서 정의한다.

문서만으로 알 수 없는 것도 적어 둔다. 편집이 이기는 규칙이 실제 운영에서 어떤 충돌을 낳는지, 2,000개 속성이나 10,000개 편집 상한이 어떤 업무에서 걸리는지, Funnel 의 갱신 지연이 얼마인지는 문서에 없다. 이 글은 공식 문서가 말하는 범위에서 멈춘다.

출처

이 글의 인용은 전부 아래 팔란티어 공식 문서에서 가져왔다(2026년 9월 11일 열람, 응답 200 확인).