https://lnkd.in/p/g8E2Kk7U팔란티어에서 온톨로지 얘기할 때 철학책 덮어라. 그냥 이거다.

회사를 코드로 만든 디지털 쌍둥이.

데이터를 테이블로 보는 게 아니라, 현장 사람이 쓰는 언어로 바꾸는 작업이다.

1. 온톨로지는 3가지 + 알파로 이루어진다

이게 전부다:

1) Object Type (객체): 현장의 명사
실존하는 것. 주문, 설비, 환자, 트럭, 작업지시서 같은거. 각 객체는 Primary Key, 속성(Properties), 실제 데이터셋이 뒤에 붙어있다.

2) Link Type (관계): 명사들 사이의 동사
고객-주문한다, 주문-포함한다-제품, 환자-진료받는다-의사 이런 관계. 양방향으로 탐색 가능하다.

3) Action Type (액션): 세상을 바꾸는 버튼
읽기만 하는 DB와 가장 큰 차이. 온톨로지에서 정의된 "허용된 변경"이다. 파라미터, 검증규칙, 사이드이펙트가 딸려있다. 이게 있어야 현장에서 쓸 수 있다.

알파: Function, Security - 누가 뭘 볼 수 있고, 어떤 로직을 태울지.
한마디로: Object = 명사, Link = 동사, Action = 동사 버튼
### 2. 현장 예시로 보면 5초 컷

데이터팀이 "ERP 테이블 3개 조인해서 출하 지연 리스트 뽑아왔어요" 하면 현장에선 못 쓴다.

온톨로지로 만들면 이렇게 된다:

Object: [설비: 프레스 101호기], [작업지시서: WO-8831], [부품: 베어링]
Link: 프레스 101호기 - 고장난다 - 베어링, WO-8831 - 사용한다 - 프레스 101호기
Action: [부품 주문하기], [설비 가동중지], [작업 재할당하기]

이제 공장 반장이 Workshop 앱에서 프레스 101호기 객체를 클릭하면, 연결된 고장 이력, 현재 작업, 재고가 다 보이고, 버튼 눌러서 부품 주문하기 액션을 실행하면 SAP로 Write-back 된다. 이게 Palantir가 말하는 operational layer다.

데이터가 아니라 운영을 모델링하는 거다. Foundry 설명에도 "business-aware representation"이라고 하는 이유다.

3. 왜 일반 DB / 데이터웨어하우스랑 다른가?
| 일반 데이터 모델 | 팔란티어 온톨로지 |
| --- | --- |
| Row, Foreign Key | Object, Link |
| View, Stored Procedure | Action Type, Function |
| 읽기 전용 | 읽기 + 쓰기(Write-back). 액션이 유일한 쓰기 경로다 |
| 데이터 분석가가 이해 | 현장 작업자, AI Agent가 이해 |
6f3308650846

DB는 "과거가 어땠나?"를 답하고, 온톨로지는 "지금 뭘 해야 하나? 버튼 눌러"를 답한다.

4. 현장에서 만드는 순서 - 이 순서 아니면 망한다

1) 명사 뽑기: 현장 인터뷰해서 명사 10개만 뽑아라. 100개 뽑으면 망한다.
2) Link 그리기: 화이트보드에 명사들 연결. 현장 사람이 "아 이거 맞아" 할 때까지.
3) Action 정의: "그래서 이 화면 보고 뭐 할건데?" 이 질문에 답이 액션이다. 권한, 검증조건 꼭 넣기.
4) 데이터 매핑: 마지막에 데이터 붙인다. 보통은 반대로 해서 망한다. 데이터부터 붙이면 현장 언어랑 안 맞는다.

5. 망하는 패턴 3개

데이터 사전 만들기: 온톨로지를 ERD처럼 만든다. 현장 용어 안 쓰고 IT 용어로 만든다. 아무도 안 쓴다.
Action 없이 Object만: 대시보드만 화려하다. 현장에서 "그래서 어쩌라고?"가 나온다. 액션이 없으면 그냥 BI다.
너무 거창하게: 전사 온톨로지 1년짜리 프로젝트. Palantir FDE들은 2주 안에 Object 5개, Action 2개로 운영부터 돌린다.

필요하면 네가 하는 도메인 하나 말해줘. 그 도메인으로 Object 5개, Link, Action 2개까지 바로 모델링해서 보여줄게.