저는 Palantir Foundry를 몇 주 동안 직접 다뤄보았습니다. 왜냐하면 제가 찾을 수 있었던 Foundry의 온톨로지(Ontology)에 대한 모든 설명이 답답할 정도로 모호했기 때문입니다. "엔터프라이즈 시맨틱 레이어 (enterprise semantic layer)", "조직의 디지털 트윈 (digital twin of the organization)" 같은 말들 말이죠. 이 중 틀린 말은 없지만, 저는 이 글들을 많이 읽었음에도 불구하고 그것이 실제로 무엇인지 말할 수 없었습니다. 개념은 도처에 널려 있지만, 실체는 어디에도 없었습니다.

그래서 저는 세 가지 공식 학습 코스 — 엔드 투 엔드 입문, 온톨로지 구축, 애플리케이션 구축 — 를 수강했고, 마침내 안개가 걷혔습니다. Foundry의 온톨로지는 소프트웨어 엔지니어들이 이미 알고 있는 어휘만으로 완전히 설명될 수 있습니다. 새로운 것은 개념이 아닙니다. 그것은 바로 단계의 순서 (order of the steps) 입니다. 즉, 일반적인 비즈니스 애플리케이션 개발을 역순으로 실행하는 것입니다.

그리고 그 역전 과정 속에 독자적인 이름이 필요한 뚜렷한 아키텍처 패턴이 숨겨져 있는데, 그것이 바로 운영 온톨로지 (operational ontology) 입니다. 왜냐하면

1. 데이터 파이프라인 (Data pipelines) — 회사 전반에 흩어져 있는 기존 시스템으로부터 데이터를 수집(ingest)하고, 변환(transform)하며, 통합(integrate)합니다 (Data Connection, Pipeline Builder, Code Repositories).
2. 온톨로지 (The Ontology) — 통합된 데이터를 *비즈니스 관점에서의 의미 (what it means to the business)*를 기준으로 모델링합니다 (Ontology Manager).
3. 애플리케이션 (Applications) — 사람들이 모델링된 객체들을 확인하고 조작할 수 있는 화면을 구축합니다 (로우코드 빌더인 Workshop 및 SDKs).

데이터를 수집하고, 의미를 부여하고, 사용합니다. 분해(decomposition) 과정 자체에는 놀라운 점이 없습니다. 흥미로운 부분은 바로 이 순서 (sequence) 입니다. 우리가 보통 따르는 순서와 비교해 볼 때 비로소 왜 이것이 흥미로운지 알 수 있습니다.

우리가 보통 구축하는 순서

일반적인 비즈니스 애플리케이션 개발은 대략 다음과 같은 과정을 거칩니다: 요구사항 수집 → 워크플로우 분석 → 도메인 모델링 → 물리적 데이터 계층 (physical data layer) 설계 → 애플리케이션 구축.

도메인 모델링 단계는 비즈니스 세계가 소프트웨어 구조로 전사(transcribe)되는 지점입니다. 이커머스 주문 시스템의 경우, 등장인물은 Order (주문), Customer (고객), Inventory (재고)와 같은 엔티티 (entities)입니다. 엔티티에는 관계 (relationships)가 있습니다: 하나의 주문은 정확히 하나의 고객에게 속합니다. 또한 엔티티에는 작업 (operations)이 있습니다: 주문 취소, 재고 할당. 작업에는 비즈니스 규칙 (business rules)이 포함됩니다: 배송된 주문은 취소할 수 없으며, 재고는 결코 음수가 될 수 없습니다. 엔티티, 관계, 작업, 규칙을 포함한 이 전체 그림이 바로 도메인 모델 (domain model)입니다.

모델이 확정된 후에야 비로소 이를 저장할 물리적 데이터 계층을 설계합니다. 그리고 대부분의 프로젝트에서 데이터는 제로 상태에서 시작합니다: 테이블은 빈 상태로 생성되어 비즈니스가 운영됨에 따라 채워집니다. 이해를 먼저 하고, 물리적 데이터는 나중에 처리합니다. 이 순서의 또 다른 특징은 다음과 같습니다: 결과물로 얻게 되는 애플리케이션은 하나의 도메인만을 서비스합니다. 주문 관리 시스템은 주문 관리용 애플리케이션입니다.

Foundry는 동일한 단계를 역순으로 실행합니다

Foundry는 다른 현실에서 시작합니다. 기업은 이미 시스템을 보유하고 있습니다. 조달(Procurement), 생산(Production), 재고(Inventory), 판매(Sales), 지원(Support) — 가치 사슬(Value Chain)의 모든 단계에는 각자의 ERP 모듈, SaaS 도구 또는 스프레드시트가 있으며, 이는 수년 전 누군가가 "하나의 도메인, 하나의 앱" 플레이북을 실행하여 축적된 결과물입니다. 데이터는 이미 존재합니다. 단지 흩어져 있을 뿐입니다.

흩어져 있다는 것이 반드시 나쁜 것은 아닙니다. 각 부서의 업무는 자체 시스템 내에서 잘 돌아갑니다. 문제가 되는 것은 시스템을 "가로지르는(crosses)" 모든 질문입니다. 이 조달 지연이 생산에 어떤 영향을 미치는가? 재고가 실제 판매 계획과 일치하는가? 이에 답하기 위해서는 시스템 간의 데이터를 조인(Join)해야 하며, 이는 실제로 사람이 엑셀(Excel)에서 작업함을 의미합니다. 즉, 기업이 스스로를 바라보는 관점이 느리고 신뢰할 수 없음을 의미합니다.

Foundry의 해답은 일반적인 순서를 뒤집습니다:

첫째, 물리적 데이터(Physical Data). 파이프라인(Pipelines)이 흩어진 시스템으로부터 데이터를 가져오고 스키마(Schemas)를 통합된 테이블(Tables)로 조정(Reconcile)합니다. 입문 과정의 시나리오는 정확히 이것의 축소판입니다. 사무용품 회사가 경쟁사를 인수했고, IT 통합은 1년 뒤에나 가능하며, 당신에게는 서로 다른 스키마를 가진 두 개의 주문 시스템과 고객 스프레드시트가 남겨진 상황입니다. 당신은 두 개의 주문 피드(Feeds)를 정제하고, 고객 데이터를 조인하며, 하나의 통합된 주문 테이블을 생성합니다.

그 다음, 그 위의 모델(Model). 온톨로지(Ontology)의 구성 요소는 객체(Objects), 링크(Links), 액션(Actions)입니다. 직접 다루어 보면, 이는 이미 알고 있는 어휘와 일대일로 매핑됩니다:

• 객체 (Object) = 엔티티 (Entity) (Order, Customer)
• 링크 (Link) = 엔티티 간의 관계 (Relationship)
• 액션 (Action) = 명령 (Command) — 비즈니스 규칙이 부착된 작업 (Operation)
• 온톨로지 전체 (The Ontology as a whole) = 도메인 모델 (Domain Model)

인수된 두 개의 주문 시스템이 있더라도, 하나의 Order 객체 타입(object type)으로 통합됩니다. IT 환경이 어떤 모습이든, 비즈니스 세계에는 '주문'이라는 하나의 개념이 존재하기 때문입니다. 온톨로지를 구축하는 것은 곧 도메인 모델링 (Domain Modeling)입니다. 동일한 기술과 판단력이 요구됩니다. 소스 테이블 (source tables)이 아니라 실제 비즈니스 세계를 모델링하는 것입니다 (Palantir의 자체 설계 가이드라인에서도 이 점을 명시하고 있습니다). 변화된 점은 시작점입니다. 모델은 다른 시스템이 이미 소유하고 있는 물리적 데이터 (physical data)의 '이후'에, 그리고 그 '위에' 구축됩니다.

마지막으로, 애플리케이션 (applications)입니다. Workshop에서는 테이블이나 SQL을 직접 다루지 않습니다. 화면에 객체 (objects)를 배치하고, 링크를 탐색하며, 버튼에 액션 (actions)을 연결합니다. 앱은 데이터베이스 (database)가 아니라 도메인 모델 (domain model)을 대상으로 구축됩니다. 또한 모델이 전사적으로 공유되기 때문에, 앱마다 데이터 모델을 새로 설계할 필요가 없습니다. 하나의 모델을 기반으로 가치 사슬 (value-chain)을 가로지르는 수많은 앱을 구축할 수 있습니다.

따라서 **요구사항(requirements) → 모델(model) → 물리(physical) → 앱(app)**의 순서가 **물리(physical) → 모델(model) → 앱(app)**으로 변합니다. 저는 이를 **역 도메인 모델링 (reverse domain modeling)**이라고 불러왔습니다. (이 역전 자체가 생소한 것은 아닙니다. 레거시 데이터베이스 위에 앱을 재구축해 본 사람이라면 누구나 물리 우선 모델링 (physical-first modeling)을 해보았을 것이며, 데이터베이스 역공학 (database reverse engineering)은 오래된 연구 분야입니다. 차별점은 이를 쓰기 (writes) 기능이 포함된 제품으로서 엔터프라이즈 규모로 수행한다는 점에 있습니다.)

이것을 '운영적(operational)'으로 만드는 부분: 쓰기 (writes)

이 시점에서 당신은 다음과 같이 이의를 제기할 수 있습니다: "흩어진 데이터를 통합하고 회사 전체에 단일 뷰를 제공한다"는 이미 답이 나와 있으며, 그것은 데이터 웨어하우스 (data warehouse)와 BI라는 점 말입니다.

맞습니다 — '읽기 (reading)'의 관점에서는 그렇습니다. DWH 세계에는 스캔과 집계에 최적화된 성숙한 모델링 규율 (차원 모델링 (dimensional modeling), 스타 스키마 (star schemas))이 있고, BI 세계에는 매출이나 재고 회전율에 대한 전사적 정의를 고정하는 "시맨틱 레이어 (semantic layers)"가 있습니다. 만약 당신이 하는 일이 오직 읽기뿐이라면, 그 스택이 정답이며 매우 훌륭한 솔루션입니다.

하지만 그 세계는 일방향입니다. 데이터는 소스 시스템 (source systems)에서 데이터 웨어하우스 (warehouse)로 흐르고, 인간은 대시보드 (dashboards)를 바라봅니다. 예를 들어, 대시보드에 잘못된 주문처럼 보이는 것이 나타났다고 가정해 봅시다. 그 자리에서 바로 무엇을 할 수 있을까요? 그냥 인지하는 것, 그게 전부입니다. 주문을 취소하려면 BI 도구를 닫고, 주문 시스템에 로그인한 다음, 처음부터 다시 주문을 찾아야 합니다. 대시보드에는 "주문 취소" 버튼이 없습니다. 그 누락된 버튼이 바로 읽기 전용 (read-only) 세계와 Foundry가 구축하고 있는 것 사이의 정확한 경계입니다.

Foundry는 대시보드를 만드는 것이 아니라 애플리케이션 (applications)을 만들고 있기 때문입니다. 즉, 단순히 관찰하는 것이 아니라 직접 운영하는 대상입니다. 운영 (Operation)은 쓰기 (writes)를 의미하며, 쓰기에는 비즈니스 규칙 (business rules)이 필요합니다. "배송된 주문은 취소할 수 없다"는 비즈니스 로직 (business logic)이며, 읽기 최적화된 차원 모델 (dimensional model)에는 이를 담을 곳이 없습니다. 도메인 모델 (domain model)에는 그것이 있습니다. 바로 액션 (action)에 말이죠.

실제로 이는 구조적으로 강제됩니다. 객체의 데이터를 직접 쓰는 경로는 존재하지 않습니다. 모든 변경 사항은 액션 (action)을 거쳐야 하며, 액션이 누가 이를 실행할 수 있는지와 무엇이 유지되어야 하는지를 결정합니다. 입문 과정에서 대시보드에 "주문 할당 (Assign Order)" 액션을 추가하게 할 때, 유일한 입력값은 담당자 (assignee)뿐이며 상태는 자동으로 전환됩니다. "진행 중, 담당자 없음"과 같은 불완전한 상태는 권장되지 않는 수준이 아니라, _표현 자체가 불가능 (unrepresentable)_합니다. 그리고 온톨로지 (Ontology)를 통해 기록된 변경 사항은 소스 시스템으로 다시 전달될 수 있으며 (write-back), 이때 기록 시스템 (system of record)은 의도적으로 상류 (upstream)에 머물러 있습니다. 즉, 온톨로지는 교차점 (junction)이지, 제2의 진실의 원천 (second source of truth)이 아닙니다.

읽기 경로: 소스 → 온톨로지 → 앱. 쓰기 경로: 앱 → 온톨로지 → 소스. Palantir의 자체 문서에서는 온톨로지를 "시맨틱 요소 (semantic elements)" (객체, 링크)와 "키네틱 요소 (kinetic elements)" (액션, 함수)로 나눕니다. 이는 그들의 용어이며, 정직한 표현입니다. 시맨틱 부분만으로는 읽기 도구에 불과합니다. 애플리케이션의 기반이 되기 위해서는 두 부분 모두가 필요합니다.

Reads travel from a shared model to agents, apps, and people. Writes enter through an audited action gate and write back to the systems of record that own the state.

바로 이 점 때문에 "온톨로지 (ontology)"라는 단어가 도움이 되지 않게 되었습니다. 형식적 온톨로지 (formal ontologies, OWL/RDF), 지식 그래프 (knowledge graphs), 그리고 최근의 "온톨로지"라는 브랜드가 붙은 AI 컨텍스트 레이어 (context layers)들은 모두 의미론적 (semantic-only) 입니다. 이들은 모두 정당한 도구들이지만, 비즈니스 규칙 (business rules)에 의해 제어되는 쓰기 (writes)를 허용하지는 않습니다. Foundry 스타일의 패턴을 읽기 전용 (read-only) 이웃들과 같은 이름으로 부르는 것은, 해당 레이어가 할 수 있는 일을 변화시키는 단 하나의 속성을 가리는 행위입니다.

패턴의 명명: 운영 온톨로지 (operational ontology)

정리하자면 다음과 같습니다: 당신이 제어할 수 없는 시스템들이 소유한 데이터 위에 구축된 공유 도메인 모델 (shared domain model)이며, 읽기 (reads)는 모델을 통과하고, 쓰기 (writes)는 규칙을 포함하고 감사 (audited) 가능한 액션 (actions)에 의해 게이트가 설정되어 기록 시스템 (systems of record)으로 다시 전파됩니다. 이것이 바로 그 패턴입니다. 그리고 이를 명확히 규정하기 위해 서론에서 언급한 참조 구현체 (reference implementation)가 존재하는 것입니다. 이 구현체는 한 번에 읽을 수 있을 만큼 작은 코드베이스 (TypeScript, MIT 라이선스)로 구성되어 있으며, 네 가지 테스트 가능한 속성을 담고 있습니다.

네 가지 속성을 간략히 요약하면 다음과 같습니다: 먼저 존재했던 물리적 데이터 (physical data) 상의 의미론적 객체 (semantic objects)와 링크 (links); 일반적인 업데이트 경로가 없는 액션 게이트 방식의 쓰기 (action-gated writes); 액션 시 전제 조건으로서의 비즈니스 규칙 (business rules) 및 기계가 읽을 수 있는 오류를 통한 위반 거부와 모든 시도에 대한 감사 (audit); 그리고 모든 상태 (state) 조각에 대해 선언된 소유자가 있는 쓰기 역전파 (write-back)입니다. 정확한 문구, 예외 케이스 (edge cases), 그리고 설계 결정 사항들은 저장소(repository)의 README에 담겨 있습니다. 당신이 읽고 있는 이 글은 가이드(walkthrough)이며, 저장소는 정의(definition)입니다. Foundry는 이 패턴의 한 가지 구현체입니다. 해당 저장소는 또 다른 최소한의 구현체이며, 데모는 심지어 인수 후 두 단계가 지난 시스템 시나리오를 재사용합니다. (솔직한 고지: "운영 온톨로지 (operational ontology)"라는 문구는 Vladimir Kozlov의 에세이를 포함하여 이전에도 사용된 적이 있습니다. 여기서의 기여는 단어가 아니라, 테스트 가능한 경계 (testable boundary)와 실행 가능한 앵커 (runnable anchor)를 제공하는 것입니다.)

이 빠른 테스트는 네 가지 속성을 하나의 질문으로 압축합니다: 시맨틱 레이어 (semantic layer)에서 주문을 취소할 수 있는가? 만약 불가능하다면 — 당신은 읽기 레이어 (read layer)를 가지고 있는 것입니다. 만약 가능하지만 소스 시스템 (source-system)의 행이 전혀 변경되지 않는다면 — 당신은 병렬 데이터베이스 (parallel database)를 가지고 있는 것입니다. 만약 아무런 문제 없이 이미 배송된 주문을 취소한다면 — 당신은 도메인 모델 (domain model)이 아니라 쓰기 API (write API)를 가지고 있는 것입니다.

이것이 지금 중요한 이유: 에이전트 (agents)

이 패턴은 Foundry 내부에서 10년 된 것이지만, AI 에이전트 (AI agents)가 이 문제를 시급하게 만들고 있습니다. 오늘날 에이전트에게 쓰기 권한을 부여하는 일반적인 방식은 SQL 도구 (SQL tool)나 얇은 API 래퍼 (thin API wrapper)를 사용하는 것이며, 비즈니스 규칙은 프롬프트 (prompt) 안에 존재합니다. 즉, 규칙이 어디에서도 강제되지 않는다는 뜻입니다.

운영 온톨로지 (operational ontology)는 이러한 기본 설정을 뒤집습니다. 참조 구현 (reference implementation)에서 MCP 도구 표면 (tool surface)은 모델로부터 생성됩니다: 쿼리 형태 (query shape)당 하나의 도구, 액션 (action)당 하나의 도구가 할당되며 — 결과적으로 가공되지 않은 SQL 도구 (raw SQL tool)는 존재하지 않습니다. 에이전트는 도메인 모델이 정의하는 정확한 연산 (operations)만을 부여받습니다. 인간을 제어하는 것과 동일한 전제 조건이 에이전트도 제어합니다: 배송된 주문을 취소하려고 시도하면 { "error": { "code": "SHIPPED_ORDER_CANNOT_BE_CANCELLED", … } }를 받게 됩니다. 이는 에이전트가 파싱(parse)하고, 복구(recover)하며, 설명할 수 있는 기계 판독 가능한 거부 메시지입니다. 규칙은 프롬프트가 아니라 모델 안에 존재합니다.

솔직한 주의 사항