Ontology 완전 해설
AI의 두뇌가 아니라, AI의 신경계를 만드는 기술
천재 의사가 진료를 못 하는 이유
세계 최고의 의사를 초빙했다고 상상해보세요. 진단 능력은 완벽합니다. 그런데 이 의사가 환자 차트를 읽을 수 없고, 처방전을 작성할 수 없고, 간호사에게 지시를 내릴 수도 없습니다.
이게 Ontology 없이 AI를 도입한 기업의 현실입니다.
AI(LLM)는 "생각하는 능력"입니다. 질문을 이해하고, 패턴을 찾고, 답을 추론합니다. 그런데 생각만 할 수 있고 감각과 행동이 없다면? 환자가 누구인지 모르고, 어떤 약을 먹고 있는지 모르고, 처방 버튼도 누를 수 없는 천재 의사가 됩니다.
Ontology는 이 AI에게 감각(데이터 연결)과 행동(실행 능력)을 부여하는 기술입니다. 팔란티어의 CEO 알렉스 카프는 이렇게 표현했습니다: "Ontology는 AI의 두뇌에 대한 몸체(body)이다."
💡 이 글은 팔란티어(PLTR) 완전 분석 1.1절의 자동차 리콜 사례를 이미 읽었다고 전제합니다. 아직 안 읽으셨다면 먼저 읽고 오시는 것을 추천합니다. 이 글에서는 1.1절보다 훨씬 깊은 기술 구조, 실제 구축 과정, 산업별 차이를 다룹니다.
📥 입력: 자연어 질문
🧠 처리: 추론 (패턴 매칭)
📤 출력: 자연어 답변
❌ 실행: 불가능
📥 입력: 자연어 질문
🗺️ 탐색: Object/Link 매핑
🧠 처리: 맥락 있는 추론
✅ 실행: Action 트리거
1. Ontology의 기술 구조
Ontology는 팔란티어 플랫폼의 "운영 레이어(operational layer)"입니다. 공식 문서의 정의는 이렇습니다:
Ontology는 조직의 디지털 자산(데이터셋, 모델)을 현실 세계의 대응물(공장, 장비, 고객 주문)과 연결하는 운영 레이어다.
💡 핵심: "데이터를 모으는 것"이 아니라 "데이터에 현실 세계의 의미를 부여하는 것". 데이터 웨어하우스가 "창고"라면, Ontology는 "지도"입니다.
출처: Palantir 공식 문서 - Ontology Overview
이 지도는 5개의 빌딩블록으로 구성됩니다. 병원을 예시로 하나씩 살펴보겠습니다.
1.1 다섯 가지 빌딩블록
출처: Palantir 공식 문서 - Core Concepts
이 5가지 빌딩블록은 그래프(graph) 데이터 구조 위에 존재합니다. Object가 노드, Link가 엣지, Action과 Workflow가 그래프 위의 실행 레이어입니다. Ontology는 단순한 데이터베이스가 아니라 "실행할 수 있는 Knowledge Graph"입니다.
Knowledge Graph: Ontology의 그래프 구조 심층 분석이 5가지가 조합되면 어떤 일이 벌어지는지, 병원 사례로 보겠습니다.
병원에서의 Ontology: 환자 중심 연결망
Tampa General Hospital은 7개 시스템의 데이터를 Ontology로 통합했습니다. "환자"라는 하나의 Object를 중심으로, 모든 관련 정보가 연결됩니다.
이 연결망 위에서 AI가 작동합니다. "환자 #12345의 패혈증 위험이 높아지고 있다"는 것을 감지하면, Ontology를 통해 담당 의사(Dr.박)를 찾고, Action(알림 전송)을 실행하고, Workflow(48시간 미응답 시 에스컬레이션)를 자동으로 가동합니다.
결과: 배치 시간 83% 단축, 패혈증 환자 700명+ 생존 기여.
1.2 Ontology 실행 흐름
"환자 #12345의 처방을 변경하려면?" 이 질문이 들어오면 Ontology에서는 이런 일이 벌어집니다:
핵심은 마지막 두 단계입니다. AI가 직접 실행하지 않고, "이렇게 하면 어떨까요?"라고 제안합니다. 사람이 승인하면 그때 실행됩니다. 이 가드레일 구조가 의료·군사 같은 미션크리티컬 환경에서 Ontology가 채택되는 이유입니다.
💡 핵심: Ontology = Object(실체) + Link(관계) + Action(실행) + Workflow(자동화). 이 4가지가 조합되면 "조직 전체의 업무를 코드화한 디지털 트윈"이 됩니다. AI는 이 위에서 작동하는 사용자 인터페이스일 뿐입니다.
2. Ontology는 어떻게 만들어지는가
Ontology 소프트웨어 자체는 팔란티어가 제공합니다. 그런데 소프트웨어만으로는 Ontology가 완성되지 않습니다. "병원의 입퇴원 시스템 코드 A001이 Epic EHR의 환자 ID와 같은 사람을 가리킨다"는 것을 누군가 정의해야 합니다.
이 일을 하는 사람이 FDE(Forward Deployed Software Engineer)입니다. 팔란티어 내부에서는 "Delta"라는 코드명으로 불립니다.
2.1 FDE: 코드도 치고 컨설팅도 하는 사람
FDE는 소프트웨어 엔지니어 + 도메인 컨설턴트 + 데이터 엔지니어를 합친 역할입니다. 고객 현장에 파견되어 Ontology를 구축합니다.
코딩이 30%에 불과합니다. 나머지 70%는 고객의 업무를 이해하고, 데이터 구조를 매핑하고, 결과를 문서화하는 데 쓰입니다. 일반적인 소프트웨어 엔지니어와 완전히 다른 역할입니다.
출처: Glassdoor 리뷰 및 팔란티어 채용 공고 기반 종합
2.2 구축 4단계
최초 PoC(Proof of Concept)는 AIP Bootcamp을 통해 1~5일 만에 만들 수 있습니다. 하지만 전사 도입까지는 수개월에서 수년이 걸립니다. 팔란티어가 20년간 적자를 기록한 핵심 이유가 바로 이 FDE 인건비입니다.
왜 자동화가 안 되는가 (아직은)
"같은 데이터"라도 조직마다 의미가 다릅니다. 코드 "A001"이 A회사에서는 "완제품"이고, B회사에서는 "원자재"입니다. 이런 비즈니스 규칙은 문서화되어 있지 않습니다. 현업 담당자의 머릿속에만 존재합니다.
LLM이 이 스키마를 자동 추론할 수 있을까요? 현재 기술 수준으로는 엔티티 추출 정밀도 98.8%, 관계 추출 정밀도 75%+ 수준입니다. 일반 비즈니스에서는 충분할 수 있지만, 의료·군사처럼 환각(hallucination)이 인명 피해로 직결되는 영역에서는 아직 인간 검증이 필수입니다.
출처: arXiv - LLM-Powered Knowledge Graphs for Enterprise (2025.03)
팔란티어의 현재 전략은 "FDE를 대체하는 것"이 아니라 "FDE를 AIP로 보조하는 것"입니다. AIP가 스키마 초안을 제안하면 FDE가 검증하고 수정합니다. 구축 기간은 줄어들고 있지만, 완전 자동화는 먼 미래입니다.
3. "데이터 웨어하우스 쓰면 안 돼?"
가장 흔한 질문입니다. "Snowflake나 Databricks로 데이터를 모으면 똑같은 거 아니야?" 답은: 아닙니다. 데이터를 "모으는 것"과 데이터에 "비즈니스 의미를 부여하는 것"은 완전히 다른 문제입니다.
3.1 데이터 인프라 5단계 진화
출처: Gartner - Exploring Lakehouse Architecture, Forrester - Data Lakehouse Is The New Data Warehouse
대부분의 기업은 Level 2~4에 있습니다. 데이터를 "모으고 분석"하는 단계입니다. Ontology는 여기에 "의미를 부여하고 실행하는" 레이어를 추가합니다.
3.2 같은 질문, 다른 답
같은 질문을 던졌을 때 무슨 차이가 나는지 비교해 봅시다.
질문: "환자 #12345의 처방을 변경하려면?"
1. SQL 쿼리 작성
2. 테이블 조인으로 결과 추출
3. 사람이 결과 해석
4. 별도 시스템에서 수동 실행
⏱ 수분~수시간 (시스템 전환 필요)
질문: "환자 #12345의 처방을 변경하려면?"
1. Ontology가 환자→담당의 관계 탐색
2. 담당 의사 Dr.박 자동 식별
3. Action 제안: "처방 변경 요청"
4. 승인 시 자동 실행
⏱ 수초 (단일 인터페이스)
Snowflake는 "데이터 관계"를 알지만, Ontology는 "비즈니스 관계 + 실행 권한"을 압니다. 이 차이가 결정적입니다.
경쟁사 기능 비교
| 기능 | Palantir | Databricks | Snowflake | Neo4j |
|---|---|---|---|---|
| 메타데이터 관리 | ✅ | ✅ | ✅ | 부분 |
| 그래프 관계 모델링 | ✅ | 부분 | 부분 | ✅ |
| Action / Write-back | ✅ | ❌ | ❌ | ❌ |
| 운영 워크플로우 | ✅ | ❌ | ❌ | ❌ |
| AI 에이전트 통합 | ✅ AIP | ✅ Mosaic | ✅ Cortex | ✅ GenAI |
| 실시간 센서/운영 데이터 | ✅ | ❌ | ❌ | ❌ |
출처: 각사 공식 문서 (Palantir, Databricks, Snowflake, Neo4j)
보라색으로 강조한 두 행이 핵심입니다. "Action(실행)"과 "운영 워크플로우"는 팔란티어만 제공합니다. 다른 플랫폼은 데이터를 보여주는 것에서 끝나지만, Ontology는 데이터를 보여주고, 제안하고, 실행까지 합니다.
⚠️ 흔한 오해: "Ontology는 그냥 멋진 데이터 웨어하우스"라는 말은, "자동차는 그냥 빠른 마차"라는 말과 같습니다. 데이터를 모으는 것과 데이터에 비즈니스 의미를 부여하고 실행까지 연결하는 것은 완전히 다른 문제입니다.
흥미로운 점은, Databricks는 팔란티어와 경쟁하기보다 2025년 3월 전략적 파트너십을 체결했다는 것입니다. Unity Catalog의 데이터를 Virtual Tables로 Palantir Foundry에 직접 등록하는 zero-copy 통합을 구현했습니다. 서로 다른 레이어에서 작동하기 때문에 보완 관계가 성립합니다.
4. 같은 엔진, 다른 설계도
Ontology 소프트웨어는 모든 산업에서 동일합니다. 하지만 각 산업의 "설계도"(스키마)는 완전히 다릅니다. 의료의 Object Type은 "환자, 병실, 처방"이고, 항공의 Object Type은 "항공기, 부품, 공급업체"이고, 군사의 Object Type은 "센서, 표적, 무기체계"입니다.
세 가지 산업에서 Ontology가 어떻게 다르게 구축되는지 비교해 봅시다.
4.1 항공 제조: Airbus A350
A350 한 대에 들어가는 부품은 수백만 개입니다. 이 부품들은 전 세계 수십 개 공급업체에서 옵니다. Airbus는 2015년부터 팔란티어와 협력하여 "Skywise"라는 플랫폼을 만들었습니다.
10년+ 파트너십 (2015 시작, 2026.02 다년 계약 연장)
4.2 에너지: BP 디지털 트윈
BP는 전 세계에 분산된 유전·정유시설의 센서 200만 개를 Ontology로 통합하여 단일 운영 관점(unified operating picture)을 구축했습니다.
2014년 도입, 2024.09 AIP 포함 5년 계약 연장. 2026년 목표: $2B 절감
4.3 군사: TITAN 시스템
TITAN(Tactical Intelligence Targeting Access Node)은 미 육군의 차세대 표적 지정 체계입니다. 우주, 고고도, 공중, 지상 4개 영역의 센서 데이터를 AI로 융합하여 장거리 정밀 타격을 지원합니다.
전장에서는 인터넷이 없습니다. TITAN은 완전히 분리된 네트워크(에어갭)에서 작동해야 합니다. 팔란티어의 Apollo 인프라가 이 에어갭 환경에 소프트웨어를 자율 배포하고 관리합니다. FedRAMP, IL-5, IL-6 인증을 모두 보유한 상태에서만 가능한 배포 방식입니다.
최종 소요: 100~150대 추정
4.4 산업별 비교: 같은 엔진, 다른 설계도
| 🏥 의료 | ✈️ 항공 | 🎯 군사 | |
|---|---|---|---|
| 핵심 Object | 환자, 병실, 의사 | 항공기, 부품, 공급업체 | 센서, 표적, 무기체계 |
| 핵심 Action | 처방 발행, 배치 최적화 | 납기 재계산, 결함 추적 | 표적 우선순위, 교전 승인 |
| 배포 환경 | 클라우드 | 클라우드 + 온프렘 | 에어갭 (오프라인) |
| 통합 시스템 수 | 7개+ | 수십 개 | 4개 영역 센서 |
| 파트너십 기간 | 5년+ (2021~) | 10년+ (2015~) | $178M 계약 (2024~) |
💡 핵심: Ontology의 "소프트웨어"는 동일하지만, 각 산업의 "설계도"(스키마)는 완전히 다릅니다. 이 설계도가 팔란티어가 20년간 FDE를 파견하며 쌓아온 도메인 지식이며, 이것이 진짜 해자입니다.
5. 왜 따라하기 어려운가
팔란티어 분석글 1.3절에서 해자를 개괄했습니다. 여기서는 3가지 장벽을 정량적으로 분석합니다.
5.1 장벽 1: 축적의 벽
Ontology의 기반 기술인 Knowledge Graph를 구현한 오픈소스 도구(Neo4j, Apache Atlas, LinkedIn DataHub)도 존재합니다. 그래프를 만드는 것 자체는 복제할 수 있습니다. 하지만 복제 불가능한 것이 있습니다: 고객 조직 내부에 5~10년간 축적된 연결 관계, 그리고 그 위에 올라간 실행 레이어(Action/Workflow)입니다.
비유하면 이렇습니다: 구글 검색 알고리즘은 논문에 공개되어 있습니다. 하지만 20년간 크롤링한 인덱스는 복제할 수 없습니다. 알고리즘(소프트웨어)은 복제 가능하지만, 데이터(축적)는 복제 불가능합니다. Ontology도 마찬가지입니다.
5.2 장벽 2: 전환 비용의 벽
Morningstar는 팔란티어의 해자를 "Narrow Moat"으로 평가하며, 전환 비용(Switching Cost)을 1차 원천으로 꼽았습니다.
총 비용: $2.5M ~ $7.5M + 6~9개월 (단순 이전)
복합 도메인 통합 시: 18~36개월
⚠️ 달러 추정치는 독립 애널리스트 추정값이며, 팔란티어 공식 공시가 아닙니다.
NDR(순달러유지율) 추이가 이 전환 비용의 효과를 증명합니다. 고객이 떠나지 않을 뿐 아니라, 해마다 더 많이 지출합니다.
출처: 출처: StockAnalysis (https://stockanalysis.com/stocks/pltr/metrics/), Palantir Q1 2026 IR (https://investors.palantir.com/news-details/2026/Palantir-Reports-Q1-2026-U-S--Revenue-Growth-of-104-Y-Y-and-Revenue-2er5cxji64hm.html)
FY2024 Q1의 111%에서 FY2026 Q1의 150%까지, 2년 만에 +39%p 상승했습니다. 비교하면, Snowflake의 NDR은 같은 기간 178%(피크)에서 126%으로 하락했습니다. Ontology의 전환 비용이 시간이 갈수록 강화되는 구조라는 것을 보여줍니다.
5.3 장벽 3: 인증의 벽 (국방)
국방 시장에는 기술력만으로 진입할 수 없습니다. 보안 인증이라는 벽이 있습니다.
| 인증 | PLTR | Databricks | Snowflake |
|---|---|---|---|
| FedRAMP | High ✅ | High (GovCloud) | High (GovCloud) |
| Impact Level | IL-5 + IL-6 ✅ | IL-5 | IL-4, IL-5 |
| 에어갭 배포 | ✅ Apollo | ❌ | ❌ |
| NATO 계약 | Maven ✅ | 없음 | 없음 |
출처: PLTR FedRAMP High, PLTR NATO Maven, 각사 공식 Compliance 페이지
IL-6(미국 기밀 정보 처리 가능)과 에어갭 배포 능력의 조합은 현재 팔란티어만 보유하고 있습니다. 이 인증을 취득하는 데 2~5년, 비용은 수천만 달러가 소요됩니다.
6. 한계와 미래
Ontology가 완벽한 기술은 아닙니다. 분명한 한계가 있고, 미래의 위협도 있습니다.
6.1 현재 한계
6.2 미래 위협 시나리오
| 위협 | 시기 | 수준 | 현실 체크 |
|---|---|---|---|
| LLM 자동 스키마 추론 | 중기 (3~5년) | 중간 | 엔티티 추출 98.8%이지만 관계 추출 75%, 환각율 6~25%. 미션크리티컬에서는 여전히 인간 검증 필수 |
| Microsoft Fabric IQ Ontology | 단기 (1~2년) | 중간 | 2025 Ignite에서 Preview 발표. OneLake + Azure OpenAI + Teams 생태계와 연동. 일반 엔터프라이즈 고객 기반에서 위협. 단, 국방·미션크리티컬 영역에서는 인증 격차 |
| 오픈소스 KG 도구 | 장기 (5년+) | 낮음 | Neo4j(매출 $200M+, Fortune 100 84% 고객), DataHub(GitHub 11.9k Stars). 같은 Knowledge Graph 기반이지만 '읽기 전용 그래프'에 가까움. Ontology의 핵심인 Action/Workflow 실행 레이어가 부재 |
| Databricks 수직 통합 | 장기 (5년+) | 낮음 | 2025.03 팔란티어와 파트너십 체결. 경쟁보다 보완 관계로 방향 설정 |
출처: Microsoft Fabric IQ, arXiv LLM-KG 2025, Databricks-Palantir PR
가장 주목할 위협은 Microsoft Fabric IQ입니다. 2025년 Ignite에서 Ontology 기능을 Preview로 발표했고, FabCon Atlanta(2026)에서는 MCP(Model Context Protocol) 엔드포인트로 외부 AI 에이전트에 Ontology를 노출하는 로드맵까지 공개했습니다. Azure OpenAI + Teams + Power BI + OneLake 생태계와 연동된다는 점에서, 팔란티어가 접근하지 못하는 일반 엔터프라이즈 고객 기반을 타깃으로 합니다.
다만, 국방·미션크리티컬 영역에서는 인증 격차(IL-6, 에어갭 배포)가 여전히 넘기 어려운 벽입니다. Ontology의 진짜 해자는 "소프트웨어 기능"이 아니라 "축적된 도메인 지식 + 인증 + 전환 비용"의 조합이며, 이 조합을 한 번에 복제하는 것은 불가능합니다.
⚠️ 공식 이탈 사례 0건: 팔란티어 Ontology 도입 후 다른 플랫폼으로 전환한 공개 사례는 검색 결과 발견되지 않았습니다. NDR 150%(FY2026 Q1)이 이를 뒷받침합니다. Sigmoid의 마이그레이션 기술 백서는 "lift-and-shift가 불가능하다"고 명시합니다. 독자적 RID 포맷과 @transform_df 패턴이 이식성을 구조적으로 차단합니다. Forrester Wave Q3 2024 Decision Intelligence 평가에서 팔란티어는 Leader로 선정되었으며, Current Offering 점수 최고점을 기록했습니다.
- Ontology = Object(실체) + Link(관계) + Action(실행) + Workflow(자동화). AI는 이 위에서 작동하는 인터페이스
- 소프트웨어는 복제 가능하지만, 5~10년간 축적된 조직의 연결 관계는 복제 불가
- 전환 비용 $2.5M~$7.5M + NDR 150% = 고객이 떠나기 거의 불가능한 구조
- Action/Workflow 레이어는 경쟁사(Databricks, Snowflake, Neo4j) 중 팔란티어만 보유
- 한계: 구축 비용·시간·인력 의존. Microsoft Fabric IQ가 일반 엔터프라이즈에서 위협 가능
- 국방·미션크리티컬 영역의 인증 격차(IL-6, 에어갭)는 여전히 넘기 어려운 벽