기술기업 분석

팔란티어 해부: 온톨로지, AIP, 아폴로 — 기술로 읽는 PLTR

들어가며

팔란티어(PLTR)를 설명하는 글은 대부분 비슷한 궤도를 돈다. 피터 틸이 2003년에 세웠고, 이름은 반지의 제왕의 수정구에서 왔고, CIA·FBI로 시작해 이제는 대기업에 AI를 팔고, 제품은 고담·파운드리·AIP·아폴로 네 개다. 다 맞는 얘기지만 여기서 멈추면 **“그래서 대체 뭘 파는 회사인가”**에는 답이 안 된다. 데이터 통합이라면 스노우플레이크도 하고, 대시보드라면 태블로도 있고, LLM 연결이라면 랭체인도 있다.

차이는 제품 목록이 아니라 아키텍처에 있다. 이 글은 투자 논리를 기술 레이어에서 다시 세워본다. 온톨로지가 왜 단순한 시맨틱 레이어가 아닌지, AIP가 LLM에게 무엇을 허용하고 무엇을 구조적으로 금지하는지, 그리고 가장 과소평가된 아폴로가 왜 경쟁사를 수년 늦추는지 순서대로 본다.

1. 온톨로지: 팔란티어가 실제로 파는 것

팔란티어의 제품을 하나만 꼽아야 한다면 고담도 파운드리도 아니고 **온톨로지(Ontology)**다.

전통적인 데이터 스택의 흐름은 이렇게 끊겨 있다.

소스 시스템 → ETL → 웨어하우스(테이블) → BI 대시보드
   → 사람이 눈으로 보고 판단
      → 다른 시스템에 로그인해서 수동으로 실행  ← 여기서 단절

대시보드는 “어제 3번 라인 수율이 떨어졌다”까지만 알려준다. 그래서 무엇을 할 것인가, 그리고 그 실행이 어떻게 원래 시스템에 반영되는가는 사람과 이메일과 ERP 화면의 몫이다. 데이터 분석과 실제 운영 사이에 늘 사람이라는 어댑터가 끼어 있다.

온톨로지는 이 간극을 타입 시스템으로 메운다. 구성 요소는 네 가지다.

요소 의미 예시
Object 비즈니스 실체 고객, 화물, 생산 라인, 항공기 정비 지시
Property 객체의 속성 화물의 현재 위치, 라인의 가동률
Link 객체 간 관계 이 화물 ↔ 저 선박 ↔ 그 항구
Action 허가된 조작 「출하 일정 재배정」, 「정비 오더 발행」

앞의 셋은 다른 제품에도 있다. dbt의 시맨틱 레이어, 데이터브릭스 Unity Catalog, 스노우플레이크 시맨틱 뷰 모두 테이블에 비즈니스 의미를 입힌다. 결정적 차이는 네 번째, Action이다.

Action Type은 단순한 UPDATE 문이 아니다. 여기에는 검증 규칙(재고보다 많이 출하할 수 없다), 권한(이 역할만 실행 가능), 감사 로그(누가 언제 왜), 그리고 원본 시스템으로의 쓰기 경로(writeback)가 함께 묶여 있다. 즉 온톨로지는 읽기 전용 의미 모델이 아니라, 조직이 수행할 수 있는 동작의 집합까지 포함한 실행 가능한 모델이다.

팔란티어가 온톨로지를 “데이터·로직·액션을 의사결정의 구성 요소로 통합한 조직의 근본 표현”이라고 설명하는 건 마케팅 수사가 아니라 아키텍처 서술이다. 회사를 컴파일해서 API로 노출한 것에 가깝다.

2. 기반 레이어: 데이터의 git

온톨로지가 성립하려면 그 아래 파이프라인이 신뢰 가능해야 한다. 파운드리의 기반 레이어는 이렇게 구성된다.

  • Data Connection — 소스 시스템 연결 계층
  • Pipeline Builder — 스파크 기반 비주얼 변환. 비개발자가 파이프라인을 만든다
  • Code Repositories — PySpark / SQL / Java. 개발자용 경로
  • 불변(immutable) 트랜잭션 — 데이터셋의 모든 변경이 버전으로 쌓인다

여기서 중요한 게 데이터셋 브랜칭이다. 파운드리는 데이터를 git처럼 다룬다. 브랜치를 따서 파이프라인을 고치고, 결과를 검증하고, 머지한다. 프로덕션 데이터를 깨뜨리지 않고 스키마를 바꿀 수 있다는 뜻이다.

2026년에는 이게 Global Branching으로 확장됐다. transforms, Pipeline Builder, 온톨로지, Workshop, AIP Logic, Object Views가 하나의 브랜치로 묶인다. 파이프라인 수정 → 온톨로지 스키마 변경 → 그 위에 올라간 앱과 AI 에이전트 로직까지, 연쇄적으로 영향받는 전체 스택을 한 브랜치에서 바꿔보고 통째로 머지할 수 있다. 데이터 플랫폼에서 이 수준의 원자적 변경 관리는 흔치 않다.

계보(lineage) 그래프도 문서화용 장식이 아니다. 다음 절에서 보듯 보안의 실행 기반이다.

3. 보안 모델: 가장 모방하기 어려운 부분

기술 해자를 하나만 꼽으라면 나는 온톨로지보다 보안 모델을 꼽겠다.

파운드리의 접근 제어는 두 층이다.

강제 제어(mandatory) — Markings

Marking은 리소스에 붙는 자격 요건이다. 리소스에 접근하려면 거기 붙은 모든 Marking의 조건을 충족해야 한다. 핵심은 여기다 — Marking은 데이터 계보를 따라 자동 전파된다.

「기밀」로 표시된 데이터셋 A를 조인해서 파생 데이터셋 B를 만들면, B는 자동으로 「기밀」을 물려받는다. 개발자가 잊어서, 또는 일부러 우회해서 민감 데이터를 세탁하는 경로가 아키텍처 차원에서 막힌다.

임의 제어(discretionary) — Granular Policies

행·열 수준 보안이다. restricted views, object security policies, property security policies가 granular policy를 참조해 사용자별로 어떤 행을 볼 수 있는지 결정한다. 단 이쪽은 읽기 필터링이며 다운스트림 출력이나 익스포트까지 따라가지는 않는다. 이 구분을 아는 게 중요하다 — 전파가 필요하면 Marking을, 뷰 단위 필터링이면 granular policy를 쓴다.

그리고 PBAC(Purpose-Based Access Control). 「이 데이터는 허가된 목적에만 사용한다」를 기술적으로 강제하는 프리미티브다. 권한이 있는 사용자라도 승인된 목적 범위 밖에서는 접근이 거부된다.

이게 왜 해자인가. 정부·의료·금융 계약에서는 “데이터로 무엇을 했는지 증명”이 계약 조건이다. 대부분의 경쟁 스택은 이 요구를 애플리케이션 레이어에서 구현한다. 그러면 파생 데이터가 새어나가고, 감사는 사후 로그 대조가 된다. 팔란티어는 계보 그래프 자체에 이걸 심었다.

4. AIP: LLM에게 무엇을 허용하지 않는가

엔터프라이즈 AI의 병목은 모델 성능이 아니다. 컨텍스트와 책임이다. 최고 성능 모델을 사내에 붙여도 실무에 못 쓰는 이유는 모델이 멍청해서가 아니라, 사내 데이터의 의미를 모르고 실수했을 때 책임 소재를 추적할 수 없기 때문이다.

AIP의 설계는 이 두 문제를 정면으로 겨눈다.

AIP Logic의 도구(tool) 3종

LLM에게 온톨로지를 도구로 준다. 도구는 세 범주다.

  1. Data — 객체 쿼리. “지금 지연된 화물 목록”
  2. Logic — 함수 실행. “이 경로의 예상 도착 시간 재계산”
  3. Action — 온톨로지 액션 적용. “출하 일정을 재배정하라”

그리고 결정적인 설계 하나 — LLM은 도구에 직접 접근하지 못한다. LLM이 할 수 있는 건 도구 호출을 요청하는 것뿐이고, 실제 실행은 AIP Logic이 호출한 사용자의 권한 범위 안에서 수행한다.

이 한 줄이 엔터프라이즈 AI의 난제 대부분을 해소한다.

  • 프롬프트 인젝션으로 모델을 속여도 권한 상승이 일어나지 않는다. 모델이 요청할 수 있는 최대치가 그 사용자가 원래 할 수 있는 일이다
  • LLM 출력이 자유 텍스트가 아니라 타입 체크·검증 규칙·권한 체크를 통과한 액션으로 제한된다. 환각이 곧바로 운영 사고로 번지지 않는다
  • 모든 액션에 감사 기록이 남는다. 3절의 Marking·PBAC가 AI 경로에도 그대로 적용된다

여기에 AIP Evals로 배포된 에이전트의 성능을 지속 평가하고 회귀를 잡는다. 에이전트를 소프트웨어처럼 테스트하는 도구다.

모델 중립성

AIP는 특정 LLM에 묶여 있지 않다. 여러 모델을 안전하게 연결하는 레이어로 스스로를 정의한다. 투자 관점에서 중요한 지점이다 — 모델이 상품화(commoditize)되면 팔란티어는 손해가 아니라 수혜자다. 모델 값이 싸질수록 그 위 오케스트레이션 레이어의 협상력이 올라간다. 엔비디아가 AI의 곡괭이를 판다면, 팔란티어는 곡괭이를 어느 갱도에 어떤 순서로 박을지 정하는 레이어를 판다.

OSDK: 락인이면서 동시에 개방

Ontology SDK(OSDK)는 온톨로지에서 타입이 있는 클라이언트 SDK를 생성한다. 그리고 이 SDK는 파운드리 밖에서도 쓴다 — React 앱, 파이썬 백엔드, 기존 사내 시스템에서 온톨로지의 데이터·로직·액션을 호출한다. AIP Logic 함수도 외부 앱에서 호출된다.

전략적으로 영리하다. 개방적으로 보이지만, 사내 애플리케이션이 온톨로지 타입에 컴파일 타임으로 의존하게 되면 이탈 비용은 오히려 커진다.

2026년의 변화: AI FDE

팔란티어의 오래된 약점은 FDE(Forward Deployed Engineer) 의존이었다. 사람이 고객사에 들어가야 배포가 되니 확장성에 천장이 있었다. 2026년 GA된 AI FDE는 자연어로 파운드리를 운영한다 — 데이터 변환, 코드 리포 관리, 온톨로지 구축과 유지까지. 4월 GA된 AIP Analyst와 함께, 회사가 자기 비즈니스 모델의 병목을 자기 제품으로 풀려는 시도다. 성공 여부는 아직 검증 중이고, 이게 향후 마진 구조를 좌우한다.

5. 아폴로: 가장 과소평가된 엔지니어링 자산

투자자 대부분이 아폴로를 그냥 “배포 도구”로 넘긴다. 실제로는 팔란티어의 사업 모델 자체를 가능하게 하는 물건이다.

팔란티어가 풀어야 하는 문제를 보자. 동일한 소프트웨어를 다음 환경에 동시에, 지속적으로 릴리스해야 한다.

  • 퍼블릭 클라우드 SaaS
  • 고객사 온프레미스 데이터센터
  • FedRAMP High / DoD IL5·IL6 인증 기밀망
  • 인터넷이 끊긴 완전 격리(air-gapped) 망
  • 잠수함·드론·전방 차량 같은 간헐 연결 엣지

보통 회사라면 여기서 개발 조직이 환경별로 쪼개지고, 기밀망 버전은 한참 뒤처진 채로 굳는다. 아폴로는 이걸 **제약 기반 오케스트레이션(constraint-based orchestration)**으로 푼다.

동작 방식

소프트웨어 자체에 배포 제약을 인코딩한다. “이 서비스는 스키마 버전 N 이상에서만 동작한다”, “유지보수 창구 안에서만 재시작한다”, “이 컴플라이언스 체크를 통과해야 한다”. Orchestration Engine은 분산 시스템의 상호 의존성과 제약을 인식하고, 제약이 충족될 때만 변경을 적용한다.

그리고 방향이 push가 아니라 pull이다.

팔란티어: 선언적 지시를 발행 (desired state)
            ↓
각 환경의 아폴로 에이전트:
  구독 감시 → 제약 충족 확인 → 아티팩트 당겨옴
  → 서명·무결성 검증 → 정책에 따라 자율 배포

엔지니어가 고객 환경에 접속하지 않는다. 모든 아티팩트는 암호학적으로 서명되고, 무결성 검증을 거쳐 전송되며, 종단간 감사가 남는다. 이래서 격리망에서도 자율 배포가 성립한다.

왜 해자인가

인증 환경에서 소프트웨어를 빠르게 업데이트하는 능력은 돈으로 단기에 살 수 없다. 팔란티어는 2024년 12월 Palantir Federal Cloud Service에 대해 FedRAMP High 인증을 받았고, 이 인증 범위에 AIP·Apollo·Foundry·Gotham·FedStart·Mission Manager가 모두 들어간다. 그 전에 이미 FedRAMP Moderate와 DoD IL5·IL6를 확보한 위에 쌓은 것이다. 아폴로는 바로 이 환경들에 배포하기 위한 기반으로 만들어졌다.

인증을 새로 따고, 그 안에서 지속 배포 파이프라인까지 세우는 작업을 경쟁사가 처음부터 하려면 상당한 시간이 든다. 팔란티어는 그 배관을 이미 깔았고, 파운드리와 AIP가 그 위 서비스 메시(Rubix)에서 돌아간다.

그리고 팔란티어는 이 배관 자체를 상품화했다. FedStart는 제3자 소프트웨어 공급사가 자기 제품을 팔란티어가 이미 보유한 인증 범위 안에 배포하게 해주는 제품이다. FedRAMP Moderate·High와 DoD IL5(일부 워크로드는 IL6)까지 걸치는 환경을 제공한다. 인증 획득에 수년을 쓰는 대신 남의 인증 봉투 안으로 들어가는 선택지를 판다 — 자기 인프라를 플랫폼으로 파는 단계까지 온 셈이다.

6. 고담과 엣지: 대역폭이 없는 곳의 AI

고담은 파운드리의 정부 버전이라기보다, 요구 조건이 다른 형제다. 구조적으로는 정형·비정형 데이터를 사람·조직·장소·문서·사건 같은 객체와 그 관계로 변환하고, 그 위에 링크 분석과 지리공간 레이어를 얹는다.

핵심 기술 난제는 **개체 해결(entity resolution)**이다. 형식이 전혀 다른 소스에서 들어온 데이터 조각들을 비교해 유사도 임계값을 넘는 것들을 병합해서, “이 기록과 저 기록이 동일 인물인가”를 판정한 뒤 하나의 객체로 합친다. 타입이 있는 지식 그래프에 이종 데이터를 매핑하는 문제이며, 중복 제거와 개체 해결에 상당한 엔지니어링이 투입되는 영역이다.

엣지 쪽은 기술적으로 더 흥미롭다. Edge AI의 문제 설정은 이렇다 — 위성 센서는 내려보낼 수 있는 용량보다 더 많은 데이터를 촬영한다. 대역폭이 병목이면 무엇을 내려보낼지 고르는 판단 자체가 가치가 된다.

그래서 데이터를 중앙으로 보내는 대신 모델을 데이터가 있는 곳으로 보낸다. 위성에 탑재된 Edge AI가 현장에서 추론해 가치 있는 데이터를 선별하고, 임무 우선순위가 바뀌면 궤도상에서 모델을 교체한다. 정적 알고리즘을 올려둔 위성은 요구사항이 바뀌는 순간 무용해지는데, 비행 중 알고리즘 갱신이 이 문제를 푼다. 팔란티어는 위성 기업 Satellogic과 협업해 이 방식을 구현했고, 결과는 위성 영상 운영 UI인 MetaConstellation으로 연결된다.

아폴로가 격리·간헐 연결 환경 배포를 해결했기 때문에 성립하는 제품이다. 레이어가 서로를 떠받치는 구조가 여기서 드러난다.

Warp Speed는 이 조합의 제조 버전이다. 온톨로지 기반 AI 네이티브 MES(제조실행시스템)로, 생산 전 단계의 실시간 가시성·추적성·의사결정을 제공한다. 전투기·헬기·미사일·위성을 만드는 지리적으로 흩어진 공장들을 공통 온톨로지로 묶고, 하위 협력사 입력까지 하나의 모델에 통합해 납기를 관리한다. Warp Speed for Warships로 함정 건조까지 확장 중이다.

여기서 온톨로지의 진짜 위력이 보인다. 원청과 수십 개 하청이 서로 다른 ERP를 쓰고 있어도, 공통 온톨로지가 있으면 “이 부품 지연이 최종 납기에 며칠 영향인가”를 계산할 수 있다.

7. 기술 관점의 해자와 반론

해자

  1. 마이그레이션 비용이 데이터 이전이 아니라 의미 이전이다. 온톨로지 구축은 조직의 암묵지를 코드로 옮기는 작업이다. 다른 플랫폼으로 갈아타려면 데이터를 옮기는 게 문제가 아니라 그 모델링 작업을 처음부터 다시 해야 한다.
  2. 액션과 writeback이 운영계에 물려 있다. BI 도구는 꺼도 공장이 돌아간다. 온톨로지 액션으로 정비 오더를 발행하고 있으면 못 끈다. 스위치 코스트의 차원이 다르다.
  3. 인증 + 아폴로 배관. 5절에서 본 대로 신규 진입자를 수년 지연시킨다.
  4. OSDK 컴파일 타임 의존. 사내 앱들이 온톨로지 타입에 묶인다.

반론도 정직하게

  1. 온톨로지 품질은 도입 조직의 데이터 성숙도에 종속된다. 소스 데이터와 업무 정의가 엉망이면 그 위에 좋은 온톨로지가 세워지지 않는다. 더 근본적으로 개체 해결과 온톨로지 모델링은 도메인 지식이 필요한 작업이라, 완전 자동화되지 않고 시간이 걸린다. 도입 기간과 비용이 길어지는 구조적 이유다.
  2. 인적 확장성. FDE 모델은 비싸고 느리다. AI FDE가 이걸 풀려는 시도이며, 아직 결과가 나오지 않았다. 마진 스토리의 핵심 변수다.
  3. 아래에서 올라오는 경쟁. 범용 데이터 플랫폼들이 시맨틱 레이어와 에이전트 기능을 확장하면, 온톨로지의 차별점 중 “데이터·로직” 부분은 잠식될 수 있다. 그때 남는 건 “액션 + 거버넌스 + 인증 환경”인데, 이 부분의 방어력이 얼마나 지속될지가 장기 논점이다.
  4. 온톨로지는 표준이 아니라 독점 기술이다. 개방 표준이 등장하면 락인 논리가 약해진다.

8. 숫자로 확인되는 기술 채택 (2026년 2분기)

기술 얘기를 길게 한 이유는, 최근 실적이 영업을 잘해서 나온 숫자로 보이지 않기 때문이다.

매출+93%19.4억 달러 · YoY
미국 상업 부문+149%7.64억 달러 · YoY
Rule of 40155%성장률 + 마진
미국 상업 고객 수653개+35% YoY
조정 FCF12.2억 달러분기 10억 달러 돌파
FY2026 가이던스+80%81.5~81.6억 달러

GAAP 순이익, 조정 영업이익, 조정 FCF가 모두 분기 10억 달러를 넘겼다. Rule of 40이 155%라는 건 성장률과 마진의 합이 정상 범위를 한참 벗어났다는 뜻이다.

여기서 AIP 부트캠프를 다시 해석할 수 있다. 며칠 만에 고객사의 실제 문제를 풀어 보이는 게 가능한 건 영업 기법이 뛰어나서가 아니다. 온톨로지로 의미 모델을 세우고, OSDK로 타입 있는 앱을 즉시 생성하고, AIP Logic으로 LLM을 권한 안에서 액션에 묶을 수 있기 때문이다. 부트캠프는 영업 전략이 아니라 아키텍처의 결과물이다.

물론 이 숫자들이 밸류에이션 리스크를 없애주지는 않는다. +93% 성장이 주가에 이미 반영돼 있고, 성장률이 정상화되는 국면에서 멀티플 수축은 가혹할 수 있다. 정부 매출의 예산·정치 변수와 내부자 매도 이슈도 그대로 남아 있다. 다만 “실체 없는 AI 테마주”라는 비판에 대해서는, 기술 스택을 들여다보면 반박할 근거가 충분하다.

마치며

팔란티어를 “데이터 분석 회사”로 분류하면 밸류에이션이 설명되지 않는다. 기술 레이어로 다시 보면 이런 회사다.

AIP      — LLM을 타입 시스템 안에 권한째로 묶는 레이어
  ↑
온톨로지 — 조직을 객체·링크·액션의 타입 시스템으로 컴파일
  ↑
파운드리 — 계보와 보안이 자동 전파되는 데이터 기반
  ↑
아폴로   — 어디든(클라우드/온프렘/기밀망/엣지) 배포하는 배관

아래 세 층이 없으면 맨 위 AIP는 그냥 또 하나의 LLM 래퍼다. 반대로 이 스택이 갖춰져 있으면, 모델이 싸지고 좋아질수록 유리해진다. 경쟁사가 따라오기 어려운 건 AI 기능이 아니라 그 아래 10년치 배관이다.

투자 판단은 각자의 몫이지만, 적어도 논쟁의 축은 “AI 버블인가”가 아니라 **“이 배관의 방어력이 하이퍼스케일러의 상향 침투보다 오래 버티는가”**여야 한다고 본다.

참고 자료

본문의 기술 서술은 아래 1차 자료(팔란티어 공식 문서·블로그, SEC 공시, 실적 발표)에 근거했다.

플랫폼 아키텍처

온톨로지 · 개발자 도구

보안 모델

아폴로 · 인증 환경

고담 · 엣지 · 제조

실적

이 글은 위 1차 자료를 기반으로, 사업 개요 중심의 초안을 기술 아키텍처 관점으로 재구성한 것입니다. 출처로 확인되지 않은 일화나 미확인 정보는 의도적으로 제외했습니다. 투자 권유가 아닙니다.

댓글