개발과 AI 도구에 필요한 플랫폼 문맥
Foundry에서 개발할 때는 데이터를 처리하는 계층, 업무 대상을 모델링하는 온톨로지와 사용자가 조작하는 애플리케이션을 구분해야 합니다. AI 개발 도구와 협업할 때도 이 구분과 실제 리소스의 API 이름, 사용 권한 및 원하는 결과를 함께 제공하면 잘못된 도구나 인터페이스를 선택할 가능성을 줄일 수 있습니다.
Palantir MCP를 연결한 AI 도구는 search_foundry_documentation으로 세부 기능을 찾을 수 있습니다. 개발 대상의 실제 스키마와 권한은 별도로 확인해야 합니다.
플랫폼과 데이터 경로
Foundry는 데이터 관리, 온톨로지, 로직과 업무 개발을 담당하고 AIP는 생성형 AI를 연결하며 Apollo는 소프트웨어 전달을 관리합니다. 통합 플랫폼 위의 MMDP는 저장 형식, 연산 엔진과 모델의 접점을 제공합니다.
일반적인 경로는 원천 연결, 데이터셋 수집, 변환, 온톨로지의 객체 및 링크 구성과 애플리케이션 사용으로 이어집니다. 사용자가 판단을 액션으로 기록하면 온톨로지나 외부 시스템에 결과를 반영할 수 있습니다. 앱에 따라 데이터 계층을 직접 읽거나 온톨로지를 사용할 수 있습니다.
데이터 계층의 용어
| 용어 | 의미 |
|---|---|
| 데이터셋 | 파일 모음을 감싸는 리소스. 스키마가 있는 표, 이미지와 동영상 같은 비정형 파일, JSON과 XML 같은 반정형 자료를 다룸 |
| 트랜잭션 | 데이터셋의 파일 및 버전 상태를 기록하는 변경 단위. 이력의 보존은 보존 정책과 함께 관리 |
| 변환 | 입력 자료를 처리해 출력을 만드는 로직. 코드나 Pipeline Builder로 작성 |
| 커넥터 | 데이터베이스, API, 클라우드 저장소와 SAP 같은 기업 시스템에 연결하는 통합 |
| 동기화 | 외부 원천의 데이터를 플랫폼에 가져오는 작업 |
| 데이터 계보 | 데이터가 어떤 입력과 로직으로 만들어졌는지 나타내는 의존 관계 |
| 증분 처리 | 이전 처리 이후의 지원되는 변경분을 계산에 반영하는 방식. 스키마와 입력 변경의 조건을 관리해야 함 |
| 브랜치 | 코드와 지원되는 데이터 및 온톨로지 리소스의 변경을 분리하는 작업 문맥 |
동기화의 출력은 유형마다 다릅니다. 배치 동기화는 데이터셋, 스트리밍 동기화는 스트림, CDC 동기화는 변경 로그 메타데이터가 있는 스트림, 미디어 동기화는 미디어 집합을 대상으로 합니다. 일정에 따라 실행하거나 직접 시작할 수 있습니다.
외부 시스템이 표준 Foundry 인증이나 요청 형식을 사용할 수 없다면 리스너를 검토할 수 있습니다. HTTPS 리스너는 웹훅 입력을 스트림으로 전달합니다. WebSocket 리스너는 Compute Modules와 양방향 실시간 통신을 제공하는 Beta 기능으로, 플랫폼 인스턴스에 따라 사용할 수 없으며 개발 중 기능이 바뀔 수 있습니다. 이메일 리스너는 수신 이메일을 미디어 집합으로 전달하지만 모든 플랫폼 인스턴스에 제공되지는 않습니다. WebSocket 및 이메일 리스너의 사용 가능 여부는 Palantir Support에 문의합니다.
온톨로지의 용어
| 용어 | 의미 |
|---|---|
| 객체 유형 | 업무 대상이나 사건의 스키마. 속성, 기본 키, 표시 제목과 뒷받침 데이터 소스를 정의 |
| 객체 | 객체 유형의 개별 인스턴스. 특정 고객, 주문 또는 항공편이 해당 |
| 속성 | 업무 대상의 특성 정의. 문자열, 정수, 실수, Boolean, 날짜, 타임스탬프, 배열, 구조체와 지리 형상 등을 사용하며 필수 여부를 구성 |
| 기본 키 | 객체 유형 안에서 객체를 고유하게 식별하는 속성 |
| 제목 속성 | 객체의 표시 이름으로 사용하는 속성 |
| 객체 집합 | 검색이나 필터 등으로 선택한 객체 모음. 함수, 앱과 액션에 전달 가능 |
| 링크 유형 | 출발 및 도착 객체 유형과 관계의 카디널리티 및 키를 정의 |
| 인터페이스 | 여러 객체 유형이 구현할 공통 속성과 기능을 정의해 같은 워크플로에서 다형적으로 사용 |
| 액션 유형 | 입력, 규칙, 제출 조건과 부수 효과를 포함한 변경 작업의 정의 |
| 액션 | 정의한 액션 유형을 적용하는 실행. 객체, 속성과 링크를 변경할 수 있음 |
| 함수 | 서버 측에서 조회, 계산, 외부 호출 또는 온톨로지 편집을 정의하는 로직 |
| 구체화 | 뒷받침 데이터와 사용자 편집을 반영한 객체 상태를 데이터셋으로 제공해 후속 처리나 다운로드에 사용 |
온톨로지 색인은 뒷받침 데이터 소스의 변경을 객체 상태에 반영합니다. 단순한 단일 데이터셋 구성에서는 하나의 행을 하나의 객체에 연결하지만, 여러 데이터 소스와 사용자 편집을 결합할 때에는 기본 키 및 속성의 해석 규칙을 함께 설정해야 합니다.
링크는 일대일, 일대다, 다대일과 다대다 관계를 표현합니다. 외래 키와 기본 키 또는 조인 테이블을 사용하며, 다대일 관계를 확장하는 객체 기반 링크에서는 관계에 관한 메타데이터를 별도 객체 유형으로 표현할 수 있습니다. 예를 들어 Order에서 Customer로 이동하거나 한 고객의 여러 주문을 찾을 수 있습니다.
인터페이스의 예로는 Facility를 구현하는 Airport, Manufacturing Plant, Maintenance Hangar가 있습니다. 공통 시설 속성을 사용하는 업무 로직을 시설 유형마다 따로 작성하지 않고 재사용할 수 있습니다.
액션과 함수의 연결
액션 매개변수는 객체 선택, 문자열과 선택지 등의 입력입니다. 규칙은 입력으로 객체 및 링크를 생성, 수정하거나 삭제하는 로직을 정의합니다. 제출 조건은 업무 규칙과 권한을 검사하고, 알림과 웹훅 같은 부수 효과는 다른 절차와 연결합니다. 일정 규칙은 액션 적용 시 스케줄의 빌드를 시작하고 매개변수화 변환에 액션 입력을 전달할 수 있습니다.
함수 기반 액션은 복잡한 편집 로직을 함수로 구현합니다. 함수가 편집을 계산하는 것과 그 편집을 액션으로 적용하는 시점은 구분해야 합니다. 함수 기반 열은 Workshop 표에 표시할 값을 계산하며, 런타임 입력을 사용하면 현재 표에 표시된 객체를 대상으로 처리할 수 있습니다.
개발 브랜치
| 구분 | 범위와 기준 |
|---|---|
| Code Repositories 브랜치 | 하나의 저장소 안에서 변경을 분리. 해당 저장소의 어느 브랜치에서도 새 브랜치를 만들 수 있음 |
| Global branch | Main에서 시작해 여러 지원 애플리케이션의 변경을 같은 문맥으로 관리 |
Global Branching에서는 브랜치를 만든 뒤 변경을 작성하고, proposal을 만들어 검토 및 승인을 거쳐 배포합니다. Python Transforms와 TypeScript v1 저장소를 지원합니다. TypeScript v2 및 Python 함수 자체를 브랜치에서 수정할 수는 없지만 특정 버전을 참조할 수 있습니다. OSDK 자체는 전역 브랜치로 분기하는 리소스 대상에 포함되지 않습니다.
가정 분석을 위한 온톨로지 시나리오는 개발 변경을 관리하는 Global branch와 다른 기능입니다.
후속 개발과 운영
데이터와 함수 실행은 파이프라인, 언어별 함수, API와 운영 관측을 연결합니다. 앱 및 AI 실행 패턴은 Workshop과 Slate, OSDK, 챗봇과 자동화를 구분합니다. 온톨로지 코드 예제는 조회, 파생 열과 편집 및 SDK 호출을 구현합니다.
보안의 기본 구분
프로젝트는 작업과 리소스를 모으는 권한 경계이고, 조직과 마킹은 추가적인 강제 접근 조건을 적용합니다. 역할은 Owner, Editor, Viewer, Discoverer 같은 작업 권한 묶음입니다. PII나 PHI와 관련된 데이터에는 해당 마킹을 적용해 보호할 수 있습니다.
저장 및 전송 암호화, SSO와 다중 요소 인증, 감사 로그, 행과 열 수준 제어를 함께 사용합니다. 데이터 계보, 민감 정보 검사, 보존 정책과 민감한 작업의 Checkpoint 사유 기록은 관리 및 사후 조사에 쓰입니다. 조직과 마킹 같은 강제 접근 조건은 플랫폼이 관리하는 파생 리소스로 전파되지만, 원본 리소스에 부여한 역할까지 파생 데이터에 그대로 이어지지는 않습니다. 외부 평문 사본의 통제는 별도로 설계합니다.