들어가며: Foundry는 무엇을 위한 플랫폼인가
Palantir Foundry는 "데이터로 현실의 문제를 푸는 것"을 목표로 설계된 플랫폼입니다. 사용 대상이 특정 직군에 한정되지 않습니다. IT 관리자, 소프트웨어 엔지니어, 데이터 과학자뿐 아니라 간호사, 현장 기술자, 운영 담당자까지 폭넓게 상정하며, 스타트업부터 다국적 기업과 정부까지 다양한 조직을 염두에 둡니다. 이 글은 Foundry의 공식 Getting Started 문서를 따라가며, 플랫폼의 멘탈 모델과 핵심 용어, 로그인부터 유스케이스 전달까지의 흐름, 그리고 어떤 애플리케이션이 어떤 일을 하는지를 한국어로 정리한 입문 노트입니다.
플랫폼에 접근하는 경로는 두 가지가 안내됩니다. 혼자 체험해보는 AIP Developer Tier(무료 체험 계정)와, Palantir 엔지니어의 안내를 받는 AIP Bootcamp입니다. 학습을 돕는 도구로는 LLM 기반 도우미인 AIP Assist, 솔루션 아키텍처를 시각화하는 Solution Designer, 그리고 코스와 인증을 제공하는 Palantir Learning portal이 함께 제시됩니다.
두 개의 층위: 데이터 레이어와 오브젝트 레이어
Foundry를 이해하는 출발점은 데이터가 두 개의 층(layer)에 산다는 모델입니다. 하나는 데이터 레이어(data layer), 다른 하나는 오브젝트 레이어(object layer)입니다.
데이터 레이어에서 데이터는 dataset에 저장됩니다. 보통 스프레드시트처럼 표 형태(행과 열)지만 규모에 제한은 없습니다. dataset은 조직의 데이터 소스를 동기화해 들여오거나, 승인된/예시 데이터를 업로드해 만듭니다. 이 레이어의 중요한 성질은 데이터 계보(Data Lineage)입니다. 문서의 표현을 빌리면, 플랫폼의 모든 dataset은 자신이 어떻게 만들어졌는지를 기록으로 유지해 데이터의 기원을 항상 보존하고 추적할 수 있게 합니다. 입력 dataset, 출력 dataset, 그리고 그 사이에 적용된 필터·변환 같은 로직이 모두 계보로 남습니다.
오브젝트 레이어에서 데이터는 object(오브젝트)와 link(링크)로 저장됩니다. object는 비행기·차량·고객 주문 같은 현실 세계의 개념이고, link는 그 개념들 사이의 관계입니다. 문서는 이 변환을 이렇게 설명합니다. 오브젝트 레이어는 표 형태 dataset의 행과 열을 가져와, 조직의 누구나 이해할 수 있는 일련의 개념으로 바꿉니다. 여기에 Action이 더해지는데, Action은 구성원이 object를 어떻게 바꿀 수 있는지를 정의합니다. object·link·action의 정의를 한데 모은 것이 바로 Ontology이며, 문서는 이를 "조직의 디지털 표현"이라 부릅니다. (Ontology 자체의 구성요소와 설계는 별도의 글에서 더 깊이 다룹니다.)
플랫폼 접근과 로그인
로그인 방식은 SSO 인증과 passkey(패스키) 기반 비밀번호 없는(passwordless) 로그인을 지원합니다. 패스키 설정은 "Set up your Palantir account and log in" 메일을 받는 데서 시작해, 이메일과 임시 비밀번호 입력, 이름·전화 인증(SMS 또는 음성), 6자리 코드 입력, 약관 동의를 거쳐 패스키를 추가하고 저장 위치를 고르는 순서로 진행됩니다. 저장 위치는 iCloud Keychain, Windows Hello, Chrome 프로필, Samsung Pass 같은 자격 증명 저장소나 물리 보안 키, QR 코드로 연결한 모바일 기기가 될 수 있습니다. 계정당 패스키는 최대 4개까지 등록할 수 있습니다.
인증의 바탕에는 두 가지 모델이 있습니다. 기존 신원 시스템을 연동하는 Custom Identity Provider Integration과, 플랫폼에 내장된 Palantir Self-Service User Directory입니다. 후자는 AIP Developer Tier·Bootcamp 가입자를 위한 것으로, FIDO2 passkey 기반의 비밀번호 없는 인증을 씁니다. FIDO2 패스키는 기기의 내장 보안 기능(예: 얼굴 인식)과 암호학을 결합한 방식으로, 서비스마다 고유한 공개키·개인키 쌍을 만들어 개인키로 챌린지에 서명하면 서비스가 공개키로 검증합니다. 개인키가 기기를 떠나지 않으므로 비밀번호와 피싱을 함께 제거할 수 있다는 것이 핵심 이점입니다.
화면 둘러보기: 오리엔테이션과 내비게이션
문서는 플랫폼을 "조직 데이터를 위한 운영체제(operating system)"로 비유합니다. 내비게이션은 접을 수 있는 사이드바(Cmd+O / Ctrl+O)를 중심으로 합니다. 사이드바는 크게 다섯 영역으로 나뉩니다. 상단 컨트롤(Home·Search·Notifications·What's New), 기본 리소스(Recent·Files· Applications), 즐겨찾기한 애플리케이션, 즐겨찾기한 파일, 그리고 지원·계정 영역입니다.
검색은 Quicksearch라 불리며 두 모드를 가집니다. 개인화된 결과를 빠르게 보여주는 "jump-to" 모드와, 고급 필터로 탐색하는 "full results" 모드입니다(⌘+J / Ctrl+J). 별표 아이콘으로 애플리케이션·리소스·개별 object까지 즐겨찾기할 수 있고, AIP Assist는 Cmd+U / Ctrl+U로 바로 엽니다. 관리자용 Control Panel과 큐레이션된 최종 사용자 경험인 Carbon Workspaces도 이 내비게이션에서 접근합니다.
Project와 Resource: 작업의 단위와 경계
Foundry에서 작업의 기본 단위는 Resource(리소스)입니다. dataset은 물론 코드 저장소, 분석, 리포트, 애플리케이션 같은 산출물이 모두 리소스입니다. 문서의 비유를 빌리면, 리소스는 전통적 시스템의 "파일"에 해당합니다. 모든 리소스는 애플리케이션 전반에서 통용되는 표준 식별자인 Resource Identifier(RID)를 가지며, 최종 수정자·접근 권한·댓글·즐겨찾기 같은 공통 메타데이터와 이동·공유·휴지통 같은 공통 동작을 공유합니다.
리소스는 Project(프로젝트) 안에 살며, Project는 관련 리소스들을 묶는 경계이자 협업의 단위입니다. Project는 Compass 애플리케이션으로 관리되고, 권한은 사용자나 그룹에 부여하는 역할로 통제됩니다. Project 문서에 명시된 역할은 Viewer·Editor·Owner입니다. 다만 플랫폼을 한 장으로 요약한 LLM 요약 문서에서는 여기에 Discoverer를 더한 네 가지 재량 역할 (Owner·Editor·Viewer·Discoverer)을 들고 있어, 맥락에 따라 역할 집합이 조금 다르게 소개된다는 점을 함께 알아두면 좋습니다. 사용자마다 개인 Project가 하나씩 주어져 Files > Projects에서 접근할 수 있습니다.
유스케이스를 전달한다는 것
문서는 유스케이스(use case)를 "특정 의사결정 과정을 지원하기 위해 전담 팀이 수행하는 시간 제한적 노력"으로 정의합니다. 운영 알림을 만들고 조사·해결하기, 공급망 회복력을 위해 여러 시설에 걸쳐 재고를 최적화하기, 지역 시장에 영업 자원을 배분하기 같은 것이 예시입니다.
유스케이스 전달은 결과(Outcome)·데이터(Data)·도구(Tools)라는 세 요소의 틀로 안내됩니다. 가장 먼저 오는 것은 결과입니다. 방법론("대시보드를 만들자")이 아니라 목표("지역별 자원 배분에 대한 의사결정을 가능하게 하자")를 우선하라는 것입니다. 이 결과 지향적 프레이밍이 있어야 작업을 논리적 단계로 분해할 수 있습니다. 데이터는 결과에서 거꾸로 거슬러 탐색합니다. 큐레이션된 dataset을 보는 Data Catalog와 ontology의 object·link를 탐색하는 Object Explorer가 출발점이고, 필요하면 관리자에게 Ontology 확장을 요청합니다. 도구는 단계별로 매핑됩니다. 프로토타이핑·탐색에는 Contour, 빠른 피드백에는 Dashboards, 프로덕션 규모 로직에는 Code Repositories, UX 커스터마이징에는 Object Views·Workshop·Slate, 예약 갱신에는 Pipelines입니다.
애플리케이션 지도
Foundry의 애플리케이션은 수가 많아 처음에는 압도적으로 보입니다. 문서는 이들을 기능별 범주로 묶어 안내합니다. 자주 마주치는 핵심을 범주별로 정리하면 다음과 같습니다.
| 범주 | 대표 애플리케이션 | 역할 |
|---|---|---|
| 데이터 연결·통합 | Pipeline Builder, Code Repositories, Data Connection, Data Lineage, Data Health | 소스에서 최종 산출까지의 파이프라인 구축과 품질·계보 관리 |
| 모델 개발 | Model Assets, Modeling Objectives | 다양한 모델 타입의 통합과 ML 모델 협업·배포 |
| Ontology 구축 | Ontology Manager, Object Views, Object Explorer, Vertex, Map | Ontology 정의·시각화·관계 탐색·시뮬레이션·지리공간 분석 |
| 개발자 도구 | Ontology SDK(OSDK), Code Workspaces, Palantir MCP, Ontology MCP | Ontology에 대한 코드 수준 접근과 외부 AI 도구 연동 |
| 애플리케이션 구축 | Workshop, Slate, Pilot, OSDK React | 코드리스/코드 기반/AI 기반 최종 사용자 앱 제작 |
| 분석 | Contour, Quiver, Insight, Fusion, Notepad | 대규모 데이터·object·시계열 분석과 문서화 |
| 보안·거버넌스 | Approvals, Checkpoint, Cipher, Sensitive Data Scanner | 변경 승인, 민감 작업 정당성 요구, 암호화, 민감정보 탐지 |
이름이 비슷해 보여도 역할이 다릅니다. 예를 들어 Pipeline Builder는 LLM과 내장 변환으로 소스에서 산출까지 파이프라인을 만드는 도구이고, Code Repositories는 버전 관리와 협업을 지원하는 웹 기반 코드 작성 환경입니다. 분석 쪽에서 Contour는 dataset 위에서 대규모 하향식 분석을, Quiver는 object와 시계열 분석을, Insight는 단계별 분석 경로로 object를 다룹니다.
역할별 다음 단계
문서는 사용자를 여섯 역할로 나누되 "역할 사이의 경계는 이동할 수 있다"고 덧붙입니다. Data Engineer는 파이프라인을 만들고 유지하며 Pipeline Builder·Code Repositories·Data Lineage를 씁니다. Application Builder는 Ontology와 커스텀 인터페이스로 앱을 만들며 Ontology Manager·Workshop·OSDK를 쓰는데, 문서는 Ontology를 "애플리케이션 빌더가 데이터 엔지니어와 협업하는 계층"이라 표현합니다. Data Scientist는 재현성과 계보를 유지하며 코드 분석·ML을 하고 Code Workbook·Code Workspaces·Model Catalog를 씁니다. Analyst는 dataset을 탐색하고 대시보드·리포트를 만들며 Contour·Quiver·Notepad를 씁니다. Platform Administrator는 설정·접근·보안·상태를 관리하고, Data Governance 담당자는 보호·투명성· 접근 검증을 맡아 Project와 Marking을 기초 보안 장치로 활용합니다.
학습 리소스: Training application과 Examples
플랫폼 안에는 학습을 돕는 두 장치가 있습니다. Training application은 Palantir Learning 포털(learn.palantir.com)의 코스를 큐레이션해 보여주고, 조직 자체 교육 자료를 붙일 수도 있습니다. Training application이라는 태그 카테고리를 만들고 그 아래 태그를 Notepad 문서에 달면 해당 문서가 교육 앱 인터페이스에 노출됩니다.
Examples는 빌더·개발자를 위한 학습 라이브러리입니다. "Bring your own data"로 태그된 예시는 사용자가 자신의 dataset으로 워크플로를 설치해볼 수 있게 하고, Walkthroughs는 특정 워크플로가 AIP Assist로 어떻게 만들어졌는지를 단계별로 보여줍니다. 워크스페이스 내비게이션의 Support > Explore Examples에서 접근합니다.
Foundry를 한 장으로: 아키텍처 요약
문서 중 가장 밀도가 높은 "Foundry platform summary for LLMs" 페이지는 플랫폼 전체를 한 장으로 요약합니다. Palantir의 제품은 세 개의 통합 플랫폼으로 이뤄집니다. 무중단 업그레이드를 오케스트레이션하는 지속적 배포 시스템 Apollo, 데이터 운영의 핵심인 Foundry, 그리고 생성형 AI 계층인 AIP입니다.
핵심 데이터 아키텍처는 Datasets(파일 묶음을 감싸며 버전·전체 이력 보존), Transforms (입력을 출력으로 처리, Python·SQL·Java, 단일 노드 또는 분산 Spark), Connectors(DB·API· 클라우드 스토리지 등 사전 구축 연동), 그리고 Apache Iceberg를 기본 테이블 포맷으로 삼아 Databricks·Snowflake 등을 데이터 복제 없이 통합하는 Multimodal Data Plane(MMDP)로 구성됩니다. 데이터 처리 모드는 batch·incremental·streaming(Flink) 세 가지이고, Data Expectations는 위반 시 빌드를 막으며 Health Checks는 Foundry·이메일·PagerDuty·Slack으로 경보를 보냅니다.
보안·거버넌스의 접근 통제는 네 축으로 정리됩니다. 기본 보안 경계인 Projects, 사용자 사일로인 Organizations, 재량 역할인 Roles(Owner·Editor·Viewer·Discoverer), 그리고 민감 데이터에 대한 강제 통제인 Markings입니다. 여기에 저장·전송 암호화, SSO·MFA, 감사 로깅, 행·열 수준 보안이 더해집니다. 상호운용성 면에서는 Iceberg·Parquet 같은 개방 표준, REST/JDBC/S3 접근, Databricks·Snowflake·BigQuery를 가리키는 Virtual Tables, 그리고 Power BI·Tableau·Jupyter·RStudio 커넥터를 제공합니다.
마치며
Foundry 입문의 뼈대를 다시 정리하면 다음과 같습니다.
- 데이터는 두 층에 산다 — 표 형태의 데이터 레이어(dataset, 계보 보존)와 현실 개념으로 바꾼 오브젝트 레이어(object·link·action = Ontology).
- 작업의 단위는 Resource(RID로 식별), 경계는 Project(Compass로 관리, 역할 기반 권한).
- 유스케이스는 결과 → 데이터 → 도구 순으로 거꾸로 설계한다.
- 애플리케이션은 데이터 통합·Ontology 구축·앱 제작·분석·거버넌스 범주로 나뉘며, 비슷한 이름이라도 역할이 다르다(Pipeline Builder vs Code Repositories, Contour vs Quiver).
- 전체 스택은 Apollo(배포)·Foundry(데이터)·AIP(생성형 AI)로 나뉘고, 보안은 Projects· Organizations·Roles·Markings 네 축으로 작동한다.
Foundry는 단일 도구가 아니라, dataset을 현실의 개념(Ontology)으로 끌어올리고 그 위에서 의사결정 워크플로를 짜도록 설계된 운영 플랫폼입니다. 입문 단계에서 가장 중요한 감각은 "데이터를 어디에 두느냐"가 아니라 "어떤 결과를 위해 어떤 개념과 도구를 엮느냐"입니다.
이 글에서 다루지 못한 세부 주제
분량상 다음은 개략적으로만 짚었습니다. Examples 라이브러리의 구체적 스타터킷·튜토리얼 목록 (Start with examples 페이지가 개별 항목을 열거하지 않음), Functions의 런타임별 세부(TypeScript v1/v2·Python·Ontology SQL)와 Function-backed Actions/Columns, Automate의 트리거·효과 구성, Developer Console과 REST API·Palantir MCP(70+ 도구)의 상세, 그리고 관측성 도구(Data Health 모니터링 뷰, Metrics, Workflow Lineage, Log Export)의 구체적 설정입니다.