팔란티어 온톨로지는 진짜 온톨로지인가

지난 글에서 온톨로지 이야기를 하다가, 이 단어를 아예 제품의 중심에 놓고 파는 회사가 있다는 게 계속 걸렸다. 팔란티어다. 이 회사는 Foundry라는 플랫폼의 핵심을 그냥 Ontology라고 부른다.

그런데 조금만 찾아보면 반론이 만만치 않다. 저건 온톨로지가 아니라 데이터베이스 모델링을 철학 용어로 재포장한 것이라는 비판이 꽤 강하게 나와 있다. 그래서 궁금해졌다. 저건 진짜 온톨로지인가, 아니면 잘 지은 이름인가.

마침 지난 글에서 온톨로지의 고전적 정의랑 네 축을 정리해둔 참이라, 그걸 자로 삼아 한번 재봤다.

1. 일단 그게 뭔지부터

팔란티어의 Ontology는 한 줄로 말하면 조직이 실제로 어떻게 돌아가는지를 소프트웨어가 다룰 수 있는 형태로 옮겨놓은 운영 계층이다. 통합된 데이터셋과 모델 위에 얹혀서, 그 데이터를 현실의 대상과 이어붙인다. 공장이나 장비 같은 물리적 자산부터 고객 주문이나 금융 거래 같은 개념까지.

구성은 셋이다. Object Type(객체)이 명사를 정의하고, Link Type(관계)이 객체 사이를 잇고, Action Type(액션)이 그 객체를 실제로 바꾼다. 여기에 임의의 로직을 담는 Function이 붙는다.

그리고 이게 세 개의 층으로 정리된다.

명사 · 동사 · 문법으로 나눠 보기

대부분의 데이터 플랫폼은 첫 번째 층에서 멈춘다.

팔란티어 자신은 의미(semantic) 요소를 조직의 명사, 운동(kinetic) 요소를 동사라고 설명한다. 그 위에 실행 시점에 권한을 판단하는 동적(dynamic) 층이 얹힌다.

찾다 보면 kinetic 층을 “데이터를 실제 DB에 매핑하는 층”으로 설명한 자료가 종종 보이는데, 공식 문서 기준으로는 그게 아니다. kinetic은 액션·함수·동적 보안, 즉 실행 쪽이다. 데이터 매핑은 의미 층을 떠받치는 backing dataset 이야기다. 이 구분이 흐려지면 이 제품의 핵심을 놓치게 된다.

2. 핵심은 액션이다

이 제품에서 가장 눈여겨볼 부분은 객체가 아니라 액션이다. 팔란티어는 액션을 그냥 함수가 아니라 “통제된 연산”(governed operation)으로 정의한다.

액션은 그냥 함수가 아니다

노란 칸이 붙어 있느냐가 눌러도 되는 버튼과 아닌 버튼을 가른다.

“점검 예약” 액션을 누르면 사용자에게 날짜를 받고, 검증 규칙을 통과시키고, 권한을 확인하고, 실행하고, 원본 시스템에 반영하고, 누가 왜 했는지를 남긴다. 이 전부가 하나로 묶여 있다.

그냥 함수와의 차이가 여기서 나온다. 함수는 “무엇을 할 수 있는가”만 안다. 액션은 “무엇을 해도 되는가”를 함께 들고 있다. 지난 글에서 알레틱과 데온틱을 갈랐던 그 선이 제품 안에 그어져 있는 셈이다.

3. 흔한 오해 두 가지

찾아보다가 자주 마주친 오해가 둘 있었다.

GraphRAG처럼 자동으로 생성되는 거대한 지식 그래프가 아니다. 사람이 직접 설계해야 하고, 그것도 어느 정도 정제된 데이터가 먼저 준비돼 있어야 한다. 원본 데이터를 던져놓으면 알아서 세계가 구성되는 물건이 아니다.

Neo4j 같은 그래프 DB도 아니다. Cypher로 그래프를 탐색하는 데이터베이스가 아니라, 객체를 인덱싱해 올려두는 추상 계층에 가깝다.

4. 그래서, 온톨로지가 맞는가

이제 판정이다. 고전적 기준으로 재보면 결과가 꽤 분명하다.

W3C 표준을 쓰지 않는다. RDF도 OWL도 SPARQL도 쓰지 않고 자체 표현을 쓴다. 그래서 Foundry의 온톨로지를 OWL 파일로 내보내 다른 플랫폼에서 추론시키는 게 불가능하다.

논리 추론이 없다. OWL식 자동 추론을 하지 않는다. 관계는 전부 명시적으로 모델링해야 하고, 플랫폼이 알아서 유추해주지 않는다. “A가 B의 부분이고 B가 C의 부분이면 A는 C의 부분”이라는 걸 선언하면 알아서 따라오는 게 고전 온톨로지의 매력인데, 그게 없다.

그래서 학술적 의미의 온톨로지는 아니다. 여기까지는 비판이 맞다. 더 세게 나가는 쪽은 아예 이렇게 정리한다. Object Type은 테이블이고, Property는 컬럼이고, Link는 외래키고, Action은 저장 프로시저다. 피터 첸이 1976년에 정리한 ER 모델과 개념적으로 다르지 않은데 철학 용어를 입혀 어렵게 만들었다는 것이다.

5. 그런데 잣대를 바꿔보면

그런데 여기서 끝내기엔 좀 찜찜하다. 자를 바꿔 대면 그림이 꽤 달라지기 때문이다.

지난 글에서 심볼릭 월드모델의 네 축을 정리했다. 무엇이 존재하는가, 지금 어떤 상태인가, 어떤 변화가 허용되는가, 무엇이 금지되는가. 이 네 축으로 두 온톨로지를 나란히 재보면 이렇게 된다.

네 축으로 두 온톨로지를 나란히 재보면

학술 기준으로는 온톨로지가 아니지만, 에이전트가 필요로 하는 축은 오히려 더 채워져 있다.

고전 온톨로지는 ①번 축에서 압도적으로 강하다. 클래스 계층을 세우고 자동으로 추론까지 한다. ②번도 ABox로 다루긴 하는데 대체로 정적이다.

그런데 ③번과 ④번으로 가면 사정이 달라진다. OWL에는 행동이라는 개념이 아예 없다. “결제 완료에서 배송 중으로 갈 수 있다”를 표현할 방법이 없어서, 그걸 하려면 PDDL이나 상황 계산법 같은 완전히 다른 형식론을 가져와야 한다. ④번도 논리적 무결성 제약까지는 가지만, “이 사람이 이 목적으로 이걸 조회해도 되는가” 같은 규범적 판단은 다루지 않는다.

팔란티어는 정확히 그 반대다. ①번이 약한 대신 ③번과 ④번을 제품의 중심에 뒀다.

이걸 이렇게 읽을 수 있다고 본다. 고전 온톨로지는 세계를 이해하려고 만들어졌고, 팔란티어의 것은 세계를 운영하려고 만들어졌다. 전자는 추론이 목적이고 후자는 집행이 목적이다. 그래서 같은 이름을 쓰는 게 혼란스럽긴 한데, 둘 중 하나가 가짜라기보다 목적이 다른 물건이라고 보는 게 맞을 것 같다.

6. 단점은 분명하다

좋은 소리만 늘어놓으면 곤란하니 단점도 짚어둔다. 도입을 검토한다면 이쪽이 오히려 더 중요할 것이다.

벤더 락인이 심하다. 비즈니스 로직이 Foundry 안으로 들어갈수록 이탈 비용이 폭증한다. 표준을 쓰지 않으니 내보낼 방법도 마땅치 않다. 회사의 운영 규칙이 특정 벤더의 자체 포맷 안에 잠기는 구조다.

데이터를 끌어와야 한다. 기존 운영 DB를 그대로 참조하는 게 아니라 Foundry로 데이터를 가져와야 한다. 통합 작업이 선행되어야 하고, 그 파이프라인이 부실하면 온톨로지도 같이 부실해진다. 쓰레기를 넣으면 잘 구조화된 쓰레기가 나온다.

배울 게 많다. Object, Link, Action, Function, Interface, OSDK까지 익혀야 할 개념이 계속 늘어난다.

외부와의 상호운용이 어렵다. 다른 플랫폼의 AI 에이전트와 공유할 수 있는 형식적 추론 기반이 없다.

그리고 한 가지 더. 팔란티어의 진짜 경쟁력은 온톨로지라는 기술이 아니라 현장에 엔지니어를 밀어 넣는 서비스 모델과 정부·기관 관계라는 지적도 있다. 나도 이쪽이 상당 부분 맞다고 생각한다.

7. 개인적인 견해

이름 논쟁은 사실 별로 중요하지 않다고 본다. 온톨로지라고 부르든 운영 모델이라고 부르든, 실무에서 중요한 건 “무엇을 해도 되는가”가 시스템 안 어딘가에 적혀 있느냐다.

그리고 이 관점에서 보면 팔란티어가 한 일이 뭔지가 좀 더 선명해진다. 기술적으로 새로운 건 별로 없다. 대신 데이터·로직·실행·보안 이 넷을 한 곳에 두지 않으면 자동화가 안 된다는 주장을 제품 구조로 강제했다.

대부분의 회사에서 이 넷은 흩어져 있다. 데이터는 웨어하우스에, 로직은 서비스 코드에, 실행은 각 업무 시스템에, 권한은 IAM에. 그동안은 사람이 그 사이를 뛰어다니며 메꿔왔다. 그런데 에이전트는 그 사이를 못 뛰어다닌다. 붙일 데가 없기 때문이다. 에이전트에게 버튼을 쥐여주려면 그 버튼에 검증과 권한과 감사가 이미 붙어 있어야 하는데, 그런 버튼이 회사 어디에도 없는 경우가 대부분이다.

그러니까 이 제품의 시의성은 기술이 아니라 타이밍에서 온다. 읽기만 하던 AI가 쓰기를 시작하면서, 흩어져 있던 넷을 모아둔 구조가 갑자기 필요해진 것이다.

마지막으로 지난 글의 결론을 하나 수정하고 싶다. 그때 LLM이 명세를 생성해주면 온톨로지의 명세 비용이 낮아질 거라고 썼는데, 조사하면서 중요한 단서를 하나 발견했다. LLM에게 스키마를 자동 생성하게 맡기면 기존 데이터의 혼란이 그대로 구조화된다는 것이다. 부서마다 다르게 부르던 것들, 정합성이 깨진 상태값, 아무도 안 쓰는 컬럼까지 그대로 객체가 되어버린다.

명세를 쓰는 데 진짜 드는 비용은 문법을 맞추는 게 아니라 무엇을 하나로 볼지 결정하는 판단이었던 셈이다. 그건 여전히 도메인을 아는 사람의 몫이고, 아마 한동안 계속 그럴 것이다.

함께 보면 좋은 글:

참고 자료

본 글은 2026년 8월 1일 기준 공개 문서와 자료를 바탕으로 작성했다. 나는 Foundry를 직접 운영해본 적이 없고, 공개 문서와 외부 분석을 읽고 정리한 것이다. 실제 도입 경험이 있는 분의 반론은 언제든 환영한다. 시중에 도는 도입 성과 수치는 대체로 벤더 자료 기준이라 그대로 받아들이기는 어렵다.