← munki notes 건축기술 × AI
AI & 바이브코딩 기업별 AI 플랫폼 해부 시리즈 01 2026-05-30

도구를 따라가다 구조를 엎는 이유,
판단 체계가 없어서다

Palantir는 데이터를 모으는 회사가 아니다. 흩어진 데이터가 판단과 실행으로 이어지지 않는 문제를 반복해서 다뤄온 회사다. 그 구조를 개인 AI 운영체계로 번역한다.

Palantir AIP Ontology 운영체계 Airbus Skywise Army Vantage
Key Insight

데이터를 한곳에 모아도 판단이 생기지 않는다. 데이터가 어떤 업무 객체를 뜻하고, 어떤 행동을 가능하게 하며, 누가 볼 수 있는지가 함께 있어야 운영 언어가 된다.

Palantir 4-Layer Architecture
Apollo · 배포·운영 관리 계층 — 여러 환경에서 안정적 배포·운영 Foundry · 데이터 운영 기반 데이터 통합 · 로직 · 워크플로우 · 온톨로지 개발 AIP · AI 운영 플랫폼 LLM · 에이전트 · 자동화 · 평가 · 거버넌스 Ontology · 운영 온톨로지 데이터 · 로직 · 액션 · 보안 — 업무 언어의 중심 Gotham 미션 운영 도구 (정부/국방) 온톨로지가 Foundry와 AIP를 연결하는 공통 운영 언어

제품명이 아니라 역할로 이해한다

🏛️
Gotham
미션 운영 도구
정부·국방·정보 환경에서 복잡한 사건·인물·조직을 연결해 판단을 지원
⚙️
Foundry
데이터 운영 기반
여러 시스템 데이터를 업무에 쓸 수 있는 형태로 정리·연결하는 공장
🔗
Ontology
운영 언어
데이터·로직·액션·보안을 묶어 조직의 업무 언어를 만드는 공통 구조
🤖
AIP
AI 운영 플랫폼
LLM을 조직의 데이터·권한·자동화 안으로 넣어 안전하게 행동하게 하는 계층
🚀
Apollo
배포·운영 계층
다양한 고객 환경에서 소프트웨어를 계속 배포·업데이트·운영하게 하는 층

온톨로지는 지식 그래프가 아니라 운영 언어다

일반 지식 그래프는 개체와 관계만 다룬다. Palantir 온톨로지는 데이터(무엇이 있는가) + 로직(어떤 의미인가) + 액션(무엇을 할 수 있는가) + 보안(누가 볼 수 있는가)이 함께 있어야 운영 언어가 된다고 말한다.

현장 담당자, 데이터 엔지니어, 경영진, AI 에이전트가 모두 같은 대상을 같은 언어로 볼 수 있게 만드는 것이 목표다.

일반 지식 그래프
  • 개체와 관계 표현
  • 검색·추천·의미 연결에 유용
  • 예쁜 관계도에 그칠 위험
  • 첫 단계: 노드/엣지 정의
Palantir 운영 온톨로지
  • 데이터 + 로직 + 액션 + 보안
  • 운영 판단과 실행에 직결
  • 복잡도 과잉 주의 필요
  • 첫 단계: 업무 객체와 액션 정의

"온톨로지는 먼저 만드는 것이 아니라 자라나는 것이다. 처음에는 말로 시작하고, 표가 되고, 관계 지도가 되고, 나중에 필요하면 그래프 DB가 된다."

— Palantir 편, 4장

두 사례: 하나의 질문에서 시작한다

Case 1 · Airbus Skywise
A350 생산 병목에서 항공 산업 플랫폼으로

500만 개 부품, 여러 국가·공장·팀. 시작 질문은 단순했다: "특정 항공기의 지금 남은 일은 무엇인가?"

이 질문을 풀면서 일정·부품·결함·배송 데이터가 연결되고 단일 운영 화면이 만들어졌다. 하나의 문제를 제대로 풀면 인접 문제로 확장할 수 있는 데이터 자산이 생긴다.

A350 병목 데이터 연결 단일 UI 20+ use case 산업 플랫폼
Case 2 · Army Vantage
readiness를 보는 하나의 운영 화면

인력·재정·장비·물류가 각각 다른 시스템에 흩어져 있었다. 필요한 것은 더 많은 보고서가 아니라 연결된 운영 화면이었다.

좋은 운영 화면의 조건: 찾을 수 있어야(태그·카탈로그), 믿을 수 있어야(정책·표준화), 연결할 수 있어야(API), 꺼내 쓸 수 있어야(export) 한다.

personnel + finance + logistics readiness 판단

AI 기능 조립판으로 번역하기

Palantir의 4개 축을 개인 프로젝트로 작게 번역한다. 처음부터 엔터프라이즈를 따라 하지 않는다.

Palantir → 개인 프로젝트 번역
Palantir 개인 번역 첫 버전 Gotham (미션) 중요한 문제 보드 ProjectCase Foundry (데이터) 자료 작업 공간 근거 자료 · 메모 Ontology (언어) 반복 개념의 언어 개체·관계 표 AIP (AI 실행) 산출물 실행 흐름 초안·검토·산출물 Apollo (운영) 작업 이어가기 실행 기록 · 버전

1인 MVP 로드맵: 위험을 낮추는 순서

기능을 늘리는 순서가 아니라, 핵심 흐름이 한 번 돌 때만 다음 단계로 간다.

P0
문서형 조립판
Markdown·CSV·표로 시작. 도구 카드, 판단 기록을 기록한다. 문서만으로도 산출물이 나오면 앱 개발 보류.
P1
로컬 MVP
ProjectCase CRUD, 기능 지도, 도구 카드 상태 관리. 기능보다 기록이 먼저 쌓여야 한다.
P2
근거 + 산출물
근거 자료 목록과 출처 기반 PRD·원고 생성. 출처 없는 자동 생성 금지.
P3
지식 + 기억
반복 개체·관계 추출, 사용자 선호와 실패 패턴 기억. 관계가 반복될 때만 그래프화.
P4
워크플로우 + 실행 안전장치
실행 기록·승인·재시도·오류 기록. 위험 도메인은 자동 실행 제한.
P5
도메인팩
도메인별 질문지·템플릿 추가. 의료·투자·법률은 검토 보조로 제한.

Palantir에서 가져올 것 vs 가져오지 말 것

가져올 것
  • 현장 문제에서 시작
  • 자료와 판단을 연결
  • 반복 관계를 나중에 승격
  • 작은 use case와 평가
  • 실행 기록·승인·중단 조건
  • 위험 경계 명시
가져오지 말 것
  • 기술명에서 시작
  • 모든 자료를 무작정 저장
  • 처음부터 거대한 그래프 설계
  • 자동 실행을 무조건 확대
  • 복잡한 엔터프라이즈 권한 체계
  • 의료·투자·법률 확정 조언

"처음부터 플랫폼을 만들지 말자. 하나의 문제를 끝까지 추적하자. 자료를 붙이고, 판단을 남기고, 작은 산출물을 만들자. 그 흐름이 반복될 때만 구조를 키우자."

— 에필로그

AI 기능 조립판의 핵심 흐름

이 흐름이 한 번 돌면 시스템은 살아 있다. 열 번 돌면 패턴이 보인다.

1
아이디어 선택 → 프로젝트 사례 생성
오늘 하나만 해결할 문제를 고른다
2
근거 자료 3개 연결 → 기능 카드 정의
실제 자료와 권한 경계를 고정한다
3
작은 실험 실행 → 판단 기록 작성
채택·보류·폐기 이유를 남긴다
4
산출물 생성 → 실행 기록 남김
결과물과 다음 행동으로 닫는다