팔란티어 기업분석 완전 가이드 (총 9편) | 2회 Foundry·Gotham·AIP·Apollo: 팔란티어 4대 제품의 역할과 연결 구조

시리즈: 팔란티어 기업분석 완전 가이드 (총 9편) | 2회

Foundry·Gotham·AIP·Apollo: 팔란티어 4대 제품의 역할과 연결 구조

팔란티어 제품이 4개나 되는데 뭐가 뭔지 헷갈리지? Foundry, Gotham, AIP, Apollo가 각각 어떤 역할이고, 왜 하나의 연속체로 설계됐는지 이 글에서 완전히 정리해줄게.

Summary

• 팔란티어 스택은 Foundry(데이터 운영) → Gotham(고보안 작전) → AIP(운영형 AI) → Apollo(배포/운영)로 연결되는 하나의 연속체야
• 각 제품은 "따로 파는 모듈"이 아니라, 데이터 → 의사결정 → 실행 → 환류라는 운영 폐쇄 루프를 완성하기 위한 역할 분담이야
• Apollo가 있어서 에어갭·온프레·엣지 같은 까다로운 환경에서도 배포가 가능하고, 이게 정부/규제 산업 확장의 핵심이야

이 글의 대상

• 팔란티어 제품이 각각 뭔지 깔끔하게 정리하고 싶은 사람
• "Foundry랑 AIP가 뭐가 다른 거야?" 같은 궁금증이 있는 투자자/IT 담당자
• 팔란티어의 기술 구조를 이해해서 경쟁력을 판단하고 싶은 사람

목차

1. 4개 제품의 전체 그림
2. Foundry: "쓰기 가능한" 운영 데이터 모델
3. Gotham: 국방에서 검증된 작전 OS
4. AIP: 모델이 아니라 "운영 연결 계층"
5. Apollo: 어디든 배포하는 운영 레이어
6. 폐쇄 루프: 왜 4개가 하나여야 하는가

1. 4개 제품의 전체 그림

팔란티어의 제품을 한 눈에 보면 이래:

제품	한줄 역할	핵심 사용 환경
Foundry	데이터를 운영 가능한 형태로 만든다	민간·정부 공통
Gotham	고보안 환경에서 실시간 작전을 운영한다	국방·정보기관
AIP	AI를 운영 액션에 연결한다	민간·정부 공통
Apollo	어떤 환경에든 배포·관리한다	모든 환경 (클라우드/온프레/에어갭)

이 4개가 "독립 제품 4개"가 아니라 "하나의 운영 루프를 완성하는 4개 역할"이라는 게 중요해. 마치 자동차로 치면 엔진(Foundry), 조종석(Gotham), 자율주행 시스템(AIP), 그리고 차체·섀시(Apollo)에 해당하는 거지.

2. Foundry: "쓰기 가능한" 운영 데이터 모델

Foundry를 "데이터 통합 플랫폼"이라고만 이해하면 절반만 본 거야.

일반 데이터 플랫폼과 다른 점

Foundry는 커넥터·파이프라인·모델 관리·앱 구축까지 포함하는 엔드투엔드 플랫폼이야. 하지만 진짜 차별점은 1편에서 다뤘던 Ontology 기반의 앱-온-데이터 모델 구조에 있어.

• OSDK(Ontology SDK): 개발자가 Ontology 타입을 곧바로 애플리케이션 객체로 사용할 수 있어. "대시보드 만들기"가 아니라 "운영 앱 만들기"에 가까운 개발 경험이지
• Marketplace: 조직 내부에서 데이터 제품과 파이프라인이 재사용 가능한 형태로 누적돼. 이게 쌓일수록 전환비용이 급증해

비용도 현실적으로 봐야 해

팔란티어 문서가 재밌는 게, Ontology 인덱싱/쿼리의 컴퓨트 사용량을 별도로 다루고 있어. 대규모 도입 시 TCO(총 보유 비용)가 이 지점에서 결정될 수 있다는 걸 팔란티어도 인식하고 있다는 뜻이야.

3. Gotham: 국방에서 검증된 작전 OS

Gotham은 국방/정보기관에서 실시간 상황 인식과 의사결정을 지원하도록 발전해 온 플랫폼이야.

Gotham의 핵심 역할

• 실시간 탐지·상황인식·계획·의사결정
• 분류망/에어갭 같은 고등급 보안 환경 전제
• Europa(브라우저 기반 협업)로 사용성 확장 중

왜 Foundry와의 통합이 중요한가

Foundry Ontology 타입을 Gotham에 매핑/동기화하는 방식이 공식 문서로 제공돼. 이게 의미하는 건 뭐냐면:

정부에서 축적한 운영 체계를 민간으로 "제품 철학" 수준에서 확장하려는 발판

국방에서 "작전 시스템"으로 검증된 것을 민간의 "업무 운영 시스템"으로 전이시키겠다는 전략이야. Gotham의 보안·실시간 의사결정 경험이 Foundry/AIP로 녹아드는 구조지.

Gotham의 락인은 특히 강해

분류망/에어갭/인증 요건과 운영 통합(센서·이벤트·현장 시스템)이 결합되면 대체가 거의 불가능해. "이미 작전에 연결된 시스템"을 바꾸는 건 기술 문제가 아니라 미션 리스크거든.

4. AIP: 모델이 아니라 "운영 연결 계층"

AIP를 "팔란티어의 AI 제품"이라고만 이해하면 본질을 놓쳐.

AIP가 내세우는 3가지 가치

가치	설명
모델 중립(BYOM)	고객이 원하는 LLM을 연동 가능
보안/신뢰	고객 데이터가 제3자 모델 재학습에 안 쓰임
Ontology 결합	LLM 출력이 Ontology 액션과 결합 → 실제 운영 변경

이 중에서 세 번째가 진짜 방어력이야.

"모델을 바꿀 수 있다(BYOM)"는 것은 요즘 누구나 하는 거라 그 자체로 차별점이 안 돼. 팔란티어 AIP의 진짜 힘은 AI가 무엇을 '할 수 있는가'를 Ontology 액션으로 제한·감사·통제하면서도, 실행은 자동화하는 구조에 있어.

AIP 내부 구성요소

• AIP Logic: 노코드로 LLM 함수/워크플로를 만드는 도구
• Agent Studio: AI 에이전트를 설계하고 관리
• Model Studio: 모델 선택·연동·관리
• AIP Analyst: 비개발자도 AI를 사용할 수 있는 인터페이스

비개발자와 개발자 양쪽의 진입장벽을 낮추려는 설계가 잘 보이지.

5. Apollo: 어디든 배포하는 운영 레이어

Apollo는 좀 덜 주목받지만, 팔란티어의 시장 전략에서 결정적인 역할을 해.

Apollo가 지원하는 배포 환경

멀티클라우드 / 온프레 / Private SaaS / 에어갭 / 엣지
→ 전부 동일 툴체인으로 배포·업그레이드·롤백

왜 이게 중요한가

대부분의 소프트웨어 회사는 "클라우드 SaaS" 하나만 잘 하면 돼. 그런데 팔란티어의 고객은 달라:

• 정부/국방: 에어갭·분류망·ATO(운영 인가) 같은 제약이 "도입을 막는 요인"
• 헬스케어·금융: 온프레·데이터 주권·감사 요건이 강해서 SaaS 단일 모델이 안 통해

Apollo는 이런 장벽을 "제품 기능"으로 흡수해버려. 경쟁사가 "우리도 에어갭 배포 됩니다"라고 하려면 엄청난 인프라 투자가 필요한데, 팔란티어는 이걸 이미 만들어놨거든.

정리하면, 팔란티어는 "클라우드 네이티브 SaaS의 확장"이 아니라 하이브리드/고보안 운영 현실을 제품으로 표준화하면서 시장을 만들고 있는 거야.

6. 폐쇄 루프: 왜 4개가 하나여야 하는가

팔란티어가 이 4개를 따로 팔지 않고 하나의 연속체로 묶는 이유가 있어:

단계	담당 제품	하는 일
1. 데이터 통합/정제	Foundry	커넥터·파이프라인 → Ontology 매핑
2. 모델/에이전트 적용	AIP	모델 등록 → 운영형 워크플로 구축
3. 앱/현장 운영	Foundry + Gotham	실행·검토·액션 기록
4. 배포/운영 관리	Apollo	배포·모니터링·롤백

이 루프가 한 시스템 안에서 돌아가는 게 핵심이야. "데이터 플랫폼"과 "업무 운영"이 같은 시스템에서 결합되면:

• 속도: 데이터 → 인사이트 → 실행 사이의 시간이 줄어
• 일관성: 모든 팀이 같은 Ontology(객체·관계·행동)를 공유해
• 거버넌스: 누가 무엇을 왜 했는지 한 곳에서 추적돼

물론 이 구조가 락인도 함께 강화한다는 건 1편에서 다뤘지. 가치와 락인은 동전의 양면이야.

핵심 정리

1. Foundry = 데이터를 "운영 가능한 형태"로 바꾸는 기반
2. Gotham = 국방 작전 OS → 민간으로 철학/역량 전이
3. AIP = AI를 Ontology 액션에 연결하는 "운영 연결 계층"
4. Apollo = 에어갭/온프레/엣지까지 동일 툴체인 배포
5. 4개 제품 = "폐쇄 루프(데이터→결정→실행→환류)" 완성용

FAQ

Q. Foundry 없이 AIP만 쓸 수 있어?

A. 기술적으로 AIP는 Foundry 위에서 동작하는 구조야. Ontology가 AIP의 입출력 기반이기 때문에, Foundry의 데이터 모델이 깔려 있어야 AIP의 "운영 연결" 가치가 제대로 나와.

Q. Gotham은 민간에서도 쓰이나?

A. Gotham 자체는 주로 국방/정보기관용이야. 하지만 Gotham에서 검증된 실시간 의사결정·보안·운영 역량이 Foundry와 AIP에 녹아들어 있어서, 민간 고객도 간접적으로 Gotham의 가치를 누리고 있다고 볼 수 있어.

Q. Apollo가 AWS나 Azure 같은 클라우드 서비스랑 겹치지 않아?

A. 겹치는 부분도 있지만 성격이 달라. AWS/Azure는 "인프라를 제공"하는 거고, Apollo는 "팔란티어 스택 전체를 어디든 배포·관리"하는 거야. 실제로 Apollo는 AWS 위에서도, 온프레에서도, 에어갭에서도 동일하게 작동해.

Q. AIP에서 모델을 자유롭게 바꿀 수 있으면, 모델 회사들이 직접 경쟁자 아냐?

A. 정확한 질문이야. 모델 자체는 교체 가능하니까 모델 회사(OpenAI, Anthropic 등)와는 직접 경쟁이 아니야. 팔란티어의 경쟁 상대는 "모델을 운영에 연결하는 계층"을 만들려는 플레이어들 — 데이터 플랫폼(Snowflake, Databricks)이나 하이퍼스케일러(AWS, Azure)가 더 가까워.

Q. 팔란티어 도입하면 4개 제품 다 써야 해?

A. 꼭 그런 건 아니야. 보통 Foundry + AIP 조합으로 시작하고, 필요에 따라 확장하는 패턴이야. 정부/국방 고객은 Gotham이 중심이 되고, Apollo는 배포 환경에 따라 자동으로 포함되는 구조지.

Q. 이 구조가 경쟁사보다 정말 나은 거야?

A. "나은지"는 상황에 따라 달라. 팔란티어의 강점은 운영 통합의 깊이와 고보안 배포 현실 대응이야. 반면 가격, 도입 복잡도, 유연성 면에서는 컴포저블 스택(Snowflake + 오픈소스 + 클라우드 AI) 조합이 더 나을 수도 있어. 6편에서 이 경쟁 구도를 자세히 다뤄.

참고 자료 (References)

데이터 출처

출처	설명	링크
Palantir Foundry Docs	플랫폼 전체 개요	Platform Overview
Palantir Gotham	Gotham 플랫폼 소개	Gotham
Palantir AIP Docs	AIP 기능 및 보안 설계	AIP Overview
Palantir Apollo	Apollo 배포 플랫폼	Apollo

핵심 인용

"Apollo allows you to deploy software to Multi-cloud, Multi-prem, Private SaaS, even airgapped and edge — use the same advanced tooling to deploy and operate all your applications."
— Palantir Apollo 제품 페이지

다음 편 예고

[3편] AIP 상용화의 실체: Bootcamp, 개발자 제품화, 70개 고객 시연

• AIP Bootcamp가 "1~5일 안에" 뭘 만들어내는지
• 파일럿이 진짜 매출로 이어지는 구조 ($19M 전환 사례)
• "FDE 회사"에서 "제품 회사"로의 전환이 왜 핵심인지