팔란티어 용어집

플랫폼과 리소스

Foundry

데이터 수집과 가공, 온톨로지 구성, 분석 및 업무 애플리케이션 개발을 지원하는 플랫폼입니다. 데이터 계층에서 준비한 자료를 객체와 관계로 표현하고, 사용자가 애플리케이션과 액션을 통해 업무에 활용하도록 연결합니다. AIP는 이 데이터와 기능에 AI를 연결하고, Apollo는 플랫폼 소프트웨어의 배포와 운영을 관리합니다.

관련 문서: 통합 플랫폼, 데이터 계층과 객체 계층

AIP

조직의 데이터와 업무 기능에 AI를 연결하는 플랫폼입니다. AIP Logic으로 AI 함수를 구성하고, AIP Chatbot Studio에서 문맥과 도구를 사용하는 챗봇을 만들며, AIP Evals로 결과를 평가할 수 있습니다. 사용할 수 있는 모델과 기능은 플랫폼 인스턴스의 제공 범위, 활성화 설정과 권한에 따라 달라집니다.

관련 문서: AIP의 역할과 운영 기반

Apollo

소프트웨어 제품을 여러 배포 환경에 전달하고, 버전과 구성을 운영하는 플랫폼입니다. 목표 설정과 보고된 상태의 차이를 바탕으로 변경 계획을 만들고, 제약 조건을 충족하면 에이전트가 실행합니다. Foundry 리소스를 묶어 설치하는 Marketplace와는 배포 대상과 관리 단위가 다릅니다.

관련 문서: 통합 플랫폼, Apollo 용어집

플랫폼 인스턴스(Enrollment)

하나 이상의 조직을 포함하는 Foundry 실행 환경입니다. 한 회사가 하나의 조직을 사용할 수도 있고, 여러 회사가 같은 플랫폼 인스턴스 안에서 조직별로 사용자와 리소스를 구분할 수도 있습니다. 플랫폼 인스턴스 전체에 적용하는 설정과 개별 조직의 설정은 관리 범위가 다릅니다.

관련 문서: Control Panel과 관리 범위

조직(Organization)

사용자 집단과 리소스 집단 사이에 강제적 접근 경계를 설정하는 단위입니다. 개인 사용자는 기본 조직 하나에 속하고 다른 조직의 게스트가 될 수 있습니다. 프로젝트에 적용된 조직 중 하나의 구성원이나 게스트이면 조직 요건을 충족하지만, 실제 작업에는 역할과 다른 접근 요건도 필요합니다.

관련 문서: 보안 용어와 접근 판단

공간(Space)

프로젝트를 묶고 공통 온톨로지, 파일시스템이나 사용량 추적 계정 등의 설정을 공유하는 상위 단위입니다. 과거에는 Namespace라고 불렀습니다. 사용자가 앱과 리소스를 탐색하는 작업 공간(Workspace)과는 다른 개념입니다.

프로젝트(Project)

특정 업무의 리소스와 사용자를 모으는 협업 단위이며, 역할을 부여하는 기본 경계입니다. 프로젝트 안에서는 폴더로 리소스를 더 세분화할 수 있습니다. 같은 프로젝트에 참여하더라도 열람, 편집과 관리 권한은 역할에 따라 달라질 수 있습니다.

관련 문서: 프로젝트와 리소스

리소스(Resource)

Foundry가 고유하게 식별하고 권한과 메타데이터를 관리하는 대상입니다. 데이터셋, 코드 저장소, 분석과 애플리케이션 구성이 포함됩니다. 리소스 안에 다시 데이터 파일이나 소스 파일이 들어갈 수 있으므로 일반 파일 하나와 항상 대응하지는 않습니다.

관련 문서: 프로젝트와 리소스

리소스 식별자(Resource Identifier, RID)

애플리케이션 전반에서 특정 리소스를 참조하는 고유 식별값입니다. 사람이 읽는 표시 이름이나 폴더 경로와 역할이 다릅니다. 같은 이름의 리소스가 여러 개 있어도 RID와 리소스 유형으로 대상을 구분할 수 있습니다.

관련 문서: 리소스의 공통 정보

리소스 참조(Reference)

다른 위치의 리소스를 현재 프로젝트 범위에 포함하는 링크입니다. 다른 프로젝트의 데이터셋을 파이프라인 입력으로 사용할 때 활용합니다. 원본 데이터를 복사하거나 원본의 접근 요건을 없애는 기능은 아닙니다.

관련 문서: 리소스와 데이터 읽기

작업 공간(Workspace)

사용자가 애플리케이션과 리소스 사이를 이동하고 업무를 수행하는 화면 환경입니다. 탐색 사이드바에서 파일, 앱, 최근 작업과 다른 작업 공간을 열 수 있습니다. 사용자 정의 작업 공간은 필요한 앱과 대시보드를 함께 제공하며, 공간(Space)의 프로젝트 관리 범위와는 구분합니다.

데이터 계층과 객체 계층

데이터 계층(Data layer)은 원천 자료의 수집, 저장과 가공을 다룹니다. 객체 계층(Object layer)은 자료를 업무 대상과 관계로 표현하고 허용할 변경을 정의하는 온톨로지 계층입니다. 데이터셋을 변환하는 실행과 액션으로 객체를 편집하는 실행은 서로 다릅니다.

관련 문서: 데이터 계층과 객체 계층

데이터 자산, 처리와 연결

데이터셋(Dataset)

파일 집합을 기반으로 권한, 스키마와 변경 이력을 관리하는 데이터 리소스입니다. 화면의 행과 열은 파일을 스키마에 따라 해석한 결과이며, 데이터셋에는 스키마가 없는 비정형 파일도 저장할 수 있습니다. 미디어 처리에 특화된 미디어 집합이나 낮은 지연으로 행을 제공하는 스트림과는 저장 및 처리 방식이 다릅니다.

관련 문서: 데이터셋과 파일, 트랜잭션 및 스키마

스키마(Schema)

데이터셋 뷰의 파일을 어떻게 읽을지 정하는 메타데이터입니다. 파일 형식의 해석 방법과 필드 이름, 자료형 등을 포함하며 시간에 따라 바뀔 수 있습니다. 스키마를 지정하는 것만으로 기존 파일의 형식이나 내용이 그 스키마에 맞게 변환되지는 않습니다.

트랜잭션(Transaction)

데이터셋 파일의 변경을 하나로 확정하거나 중단하는 원자적 단위입니다. OPEN 상태에서 파일을 쓰고, COMMITTED가 되면 변경을 뷰에 반영하며, ABORTED이면 반영하지 않습니다.

SNAPSHOT은 파일 집합을 교체하고, APPEND는 새 파일을 추가합니다. UPDATE는 파일 추가와 기존 파일 덮어쓰기를 허용하며 행 단위 갱신을 뜻하지 않습니다. DELETE는 뷰에서 파일 참조를 제거하고, 실제 파일 제거는 보존 정책과 구분합니다.

관련 문서: 트랜잭션과 변경 확정

데이터셋 뷰(Dataset view)

특정 브랜치의 특정 시점에 유효한 파일 집합입니다. 가장 최근의 SNAPSHOT을 시작점으로 이후 트랜잭션을 순서대로 적용하여 구성합니다. 사용자의 행 접근 범위를 정하는 제한 뷰(Restricted view)와는 다른 개념입니다.

변환(Transform)

입력 자료를 처리하여 출력을 만드는 로직입니다. 필터, 조인과 집계 등을 코드로 작성하거나 Pipeline Builder에서 구성할 수 있습니다. 데이터 파이프라인의 변환과 앱에서 호출하는 온톨로지 함수는 실행 위치, 입출력 계약과 배포 방식이 다릅니다.

관련 문서: 데이터 처리와 함수 실행 선택

파이프라인과 Pipeline Builder

파이프라인(Pipeline)은 입력 자산, 변환과 출력을 연결한 처리 구성입니다. Pipeline Builder는 이를 그래프와 폼으로 작성하는 도구이며, 데이터셋뿐 아니라 지원되는 미디어 집합, 가상 테이블과 온톨로지 출력도 다룹니다. 작성 중의 미리보기와 전체 데이터를 처리하는 빌드는 별도의 실행입니다.

관련 문서: Pipeline Builder 개요, 핵심 개념

빌드(Build)와 실행 작업(Job)

빌드는 지정한 출력 집합의 새 버전을 계산하는 실행 단위이며, 여러 실행 작업으로 구성됩니다. 실행 작업 하나는 같은 로직으로 하나 이상의 출력을 계산합니다. 빌드가 중간에 실패하더라도 앞서 성공한 작업이 쓴 출력은 남을 수 있으므로, 빌드 전체가 하나의 원자적 트랜잭션인 것은 아닙니다.

증분 처리(Incremental processing)

이전 처리 이후의 지원되는 변경분을 계산에 반영하는 방식입니다. 전체 입력을 다시 처리하는 비용을 줄일 수 있지만 입력 변경, 스키마 변경과 재계산 조건을 관리해야 합니다. 배치 파이프라인도 증분 처리할 수 있으며, 증분이라는 말 자체가 스트리밍을 뜻하지는 않습니다.

관련 문서: 배치, 증분과 스트리밍, 트랜잭션 유형

배치(Batch)와 스트리밍(Streaming)

배치는 정해진 입력 범위를 한 번의 실행으로 처리하고, 스트리밍은 계속 들어오는 데이터를 낮은 지연으로 처리합니다. 배치에서는 전체 재계산과 증분 처리 중 적합한 방식을 사용할 수 있습니다. 처리 지연과 지원 연산은 실제 실행 엔진과 구성에 따라 달라집니다.

스트림(Stream)

들어온 행을 낮은 지연으로 후속 시스템에 제공하는 정형 데이터 리소스입니다. 최근 레코드는 핫 버퍼에, 아카이빙한 데이터는 파일시스템 기반 콜드 버퍼에 보관합니다. 파이프라인 안에서 정확히 한 번 처리 보장을 선택하더라도 수집과 외부 내보내기 경계까지 같은 보장이 적용되지는 않습니다.

관련 문서: 스트림의 저장과 일관성 보장

미디어 집합(Media set)

공통 미디어 스키마를 가진 파일들의 모음입니다. 문서, 이미지, 오디오와 동영상 등의 미디어 항목(Media item)을 다루며, 미디어 작업에 맞는 저장과 변환 기능을 제공합니다. 스키마 없는 데이터셋에 파일을 보관하는 방식과 달리 미디어의 형식과 처리 특성을 함께 관리합니다.

지리 시계열(Geotemporal series)

하나의 대상이 시간에 따라 어디에 있었는지 나타내는 위치와 시각 관측의 순서입니다. Series ID로 시계열을 구분하며, 개별 위치 및 시각 기록을 관측(Observation)이라고 합니다. 지리 시계열 동기화는 관측을 전용 데이터베이스에 색인하고, 지리 시계열 참조(GTSR)는 온톨로지 객체에서 특정 시계열을 가리키는 속성 유형입니다.

관련 문서: 지리공간 및 시공간 데이터 유형

가상 테이블(Virtual table)

지원되는 외부 데이터 플랫폼의 테이블을 가리키는 Foundry 리소스입니다. 데이터를 먼저 Foundry 데이터셋으로 수집하지 않고 조회하며, 연결 정보와 원천 테이블의 식별 정보인 Locator를 사용합니다. 읽기, 쓰기와 원천 시스템으로의 연산 위임은 소스와 테이블 종류별 지원 범위를 따릅니다.

관련 문서: 가상 테이블과 외부 데이터 활용

데이터 계보(Data lineage)

데이터가 어떤 입력과 처리 로직으로 만들어졌고 어디에 사용되는지 나타내는 의존 관계입니다. 상류를 따라 결과의 원천을 조사하고, 하류를 따라 변경이 미칠 영향을 확인할 수 있습니다. Data Lineage는 이 관계를 그래프로 탐색하는 애플리케이션입니다.

관련 문서: 데이터 계보의 의미, 데이터 통합 도구

스케줄(Schedule)과 트리거(Trigger)

스케줄은 빌드를 반복 실행하는 구성이고, 트리거는 빌드를 시작할 조건입니다. 시각이나 주기뿐 아니라 상위 리소스의 갱신 상태를 조건으로 사용할 수 있습니다. 스케줄 실행 이력의 Succeeded는 빌드를 성공적으로 시작했다는 뜻이므로, 데이터 갱신 완료 여부는 빌드 결과에서 따로 확인합니다.

Data Connection

외부 시스템의 연결 설정과 수집, 내보내기 및 대화형 요청을 관리하는 도구입니다. 연결 대상은 소스, 구현 유형은 커넥터, 연산 위치는 워커, 통신 경로는 네트워크 설정으로 나누어 구성합니다. 연결이 가능하더라도 모든 수집 방식이나 코드 호출을 사용할 수 있는 것은 아닙니다.

관련 문서: Data Connection 핵심 개념

소스(Source)

외부 시스템으로 연결하는 개별 연결 리소스입니다. 대상 주소와 인증 설정, 연결 기능을 실행할 워커 등을 담습니다. 같은 커넥터를 사용하더라도 대상 시스템이나 인증 구성이 다르면 별도의 소스로 관리할 수 있습니다.

커넥터(Connector)

소스를 구성하는 구현 유형이며, 소스 유형(Source type)이라고도 합니다. 대상 시스템에 맞는 연결 방법과 기능을 제공하고, 선택한 워커에 따라 사용 가능한 기능이 달라집니다. 개별 연결 설정을 담은 소스와 커넥터 자체는 구분합니다.

관련 문서: 커넥터와 연결 기능

워커(Worker)

Data Connection의 연결 기능을 어디에서 실행할지 결정하는 구성입니다. Foundry 워커는 플랫폼의 컨테이너 실행 환경에서 연산하고, 에이전트 워커는 고객이 준비한 호스트에서 연산합니다. Foundry 워커가 에이전트 프록시를 사용하더라도 연산 위치는 Foundry이며, 에이전트 워커는 기존 기능 유지 단계입니다.

관련 문서: 워커와 연산 위치, 워커 비교

Data Connection 에이전트

조직 네트워크 안에 설치하여 외부 시스템 연결에 사용하는 프로그램입니다. Foundry 워커의 에이전트 프록시 경로를 제공하거나, 기존 에이전트 워커 방식에서 연결 기능을 실행합니다. 언어 모델이 도구를 사용하는 AI 에이전트나 소프트웨어 배포 계획을 실행하는 Apollo 에이전트와 역할이 다릅니다.

관련 문서: Data Connection 에이전트

외부 통신 정책(Egress policy)

Foundry가 어떤 외부 목적지에 어떤 경로로 접근할 수 있는지 정하는 정책입니다. Foundry 워커 소스는 직접 연결 정책이나 에이전트 프록시 정책을 사용합니다. 네트워크 경로를 허용하는 설정과 대상 시스템의 인증 및 데이터 접근 권한은 별도로 충족해야 합니다.

관련 문서: 외부 통신 정책과 네트워크 경로

동기화(Sync)

외부 원천의 데이터를 Foundry로 가져오는 작업입니다. 배치 동기화는 데이터셋, 스트리밍 동기화는 스트림, 미디어 동기화는 미디어 집합을 출력으로 사용합니다. 동기화라는 이름만으로 양방향 전달을 뜻하지는 않습니다. 가상 미디어는 파일을 복사하는 미디어 동기화와 달리 외부 파일을 미디어 집합의 가상 항목으로 등록합니다.

관련 문서: 연결 기능과 동기화

변경 데이터 캡처(Change data capture, CDC)

데이터베이스의 변경을 변경 로그 메타데이터와 함께 수집하는 방식입니다. Data Connection의 CDC 동기화는 이 정보를 스트림에 전달합니다. 일반적인 스트리밍 동기화가 메시지 피드를 받아들이는 것과 달리, 데이터베이스 변경을 해석할 메타데이터를 함께 다룹니다.

관련 문서: 스트리밍 동기화와 CDC 동기화

내보내기(Export)

Foundry의 데이터를 외부 시스템으로 전달하는 작업입니다. 파일 내보내기는 데이터셋의 기반 파일을, 테이블 내보내기는 스키마가 있는 데이터셋의 행을, 스트리밍 내보내기는 스트림의 레코드를 전달합니다. 목적지의 형식과 기록 방식에 맞는 기능을 선택합니다.

관련 문서: Data Connection의 내보내기

웹훅(Webhook)

Data Connection에서 정의하여 외부 시스템에 보내는 구조화된 요청입니다. 외부 시스템의 기능을 호출하는 데 사용하며 이벤트 알림에만 한정되지 않습니다. 함수에서 웹훅을 사용하는 경로는 함수 언어와 버전에 따라 달라집니다.

관련 문서: 웹훅과 코드 기반 연결

온톨로지, 액션과 함수

온톨로지(Ontology)

조직이 다루는 대상과 사건, 대상의 특성과 관계, 수행할 수 있는 변경을 데이터에 연결한 체계입니다. 객체 유형, 속성, 링크 유형과 액션 유형을 정의하며 함수와 애플리케이션이 이 정의를 활용합니다. 데이터셋의 구조와 업무 대상의 구조를 연결하지만 데이터셋 자체와 동일한 리소스는 아닙니다.

관련 문서: 온톨로지 핵심 개념

객체 유형(Object type)

업무 대상이나 사건을 표현하는 스키마 정의입니다. 속성과 식별 기준, 데이터소스 연결 등을 정하며 실제 객체는 이 유형에 속합니다. 화면의 표시 이름(Display name), 코드에서 사용하는 API 이름(API name), 개별 객체의 기본 키는 각각 역할이 다릅니다.

객체(Object)

객체 유형에 속하는 개별 인스턴스입니다. 해당 유형의 기본 키로 식별하며 속성값과 다른 객체와의 링크를 가집니다. 객체 유형의 정의를 조회할 권한이 있어도 실제 객체 데이터를 읽으려면 데이터 접근 조건을 함께 충족해야 합니다.

관련 문서: 객체 식별과 접근 권한

속성(Property)과 속성값(Property value)

속성은 객체 유형이 가지는 특성의 정의이고, 속성값은 특정 객체에 들어 있는 실제 값입니다. 새 속성을 유형에 추가하는 것은 스키마 변경이며, 기존 속성의 값을 액션으로 바꾸는 것은 객체 데이터 변경입니다. 사용자 계정의 특성(Attribute)과도 구분합니다.

관련 문서: 속성과 속성값, 사용자 특성

기본 키(Primary key)

같은 객체 유형 안에서 객체를 고유하게 식별하는 기준입니다. 객체 편집과 링크가 키에 연결되므로, 기반 데이터소스에서 만드는 키는 실행마다 임의로 바뀌지 않도록 결정적으로 생성해야 합니다. 화면에 표시하는 제목이나 객체 유형의 API 이름을 기본 키와 혼동하지 않습니다.

공유 속성(Shared property)

여러 객체 유형에서 재사용하는 속성 정의입니다. 공통 메타데이터를 한곳에서 관리하지만 각 객체의 실제 속성값은 별도로 존재합니다. 속성 정의의 재사용을 위한 기능이며, 여러 객체 유형을 공통 계약으로 다루는 인터페이스와는 역할이 다릅니다.

객체 집합(Object set)

검색이나 필터 등으로 선택한 여러 객체를 함께 다루는 단위입니다. 애플리케이션에 표시하거나 함수의 입력으로 전달할 수 있습니다. 검색 조건이나 집합의 구성원이 달라지는 것과 새로운 객체 유형을 정의하는 것은 별개의 작업입니다.

관련 문서: 객체 유형과 객체 집합

링크 유형(Link type)과 링크(Link)

링크 유형은 두 객체 유형 사이에 어떤 관계를 둘지 정의하고, 링크는 그 정의에 따른 개별 객체 사이의 연결입니다. 관계의 방향, 카디널리티와 키 등을 설정하며 외래 키나 조인 테이블을 사용할 수 있습니다. 같은 객체 유형들을 연결하더라도 관계의 의미가 다르면 서로 다른 링크 유형으로 표현합니다.

관련 문서: 링크 유형과 링크, 온톨로지 관계의 구성

기반 데이터소스(Backing datasource)

객체를 구성하는 원천 데이터를 제공하는 리소스입니다. 속성 매핑(Property mapping)으로 원천 필드와 객체 속성을 연결하고, 기본 키와 보안 설정을 함께 정합니다. 모든 속성을 액션으로 채우는 객체 유형은 기반 데이터소스 없이 만들 수도 있습니다.

관련 문서: 데이터셋과 객체 유형의 관계

인터페이스(Interface)

여러 객체 유형이 구현할 공통 구조와 기능을 정의하는 온톨로지 유형입니다. 인터페이스 자체의 객체를 직접 생성하는 대신 이를 구현한 구체적인 객체 유형의 객체를 사용합니다. 객체 유형은 여러 인터페이스를 구현할 수 있으며, 인터페이스의 실제 사용 범위는 앱과 SDK 언어별 지원에 따라 다릅니다.

관련 문서: 온톨로지 인터페이스

액션 유형(Action type)

한 번의 액션 제출로 수행할 객체, 속성값과 링크의 변경을 정의합니다. 입력 매개변수, 변경 규칙, 제출 조건과 부수 효과를 구성할 수 있습니다. 정의를 편집하는 일과 그 정의에 입력을 넣어 실제 변경을 요청하는 액션 제출은 구분합니다.

액션(Action)

액션 유형에 대상과 입력을 전달하여 변경을 제출하는 실행입니다. 앱의 버튼이나 다른 지원 경로에서 호출할 수 있으며, 구성된 규칙과 제출 조건이 변경 범위를 정합니다. 화면을 열거나 필터를 바꾸는 것만으로 액션이 제출되는 것은 아닙니다.

관련 문서: 액션과 애플리케이션, 액션 유형의 적용

제출 조건(Submission criteria)

입력값과 사용자 등의 실행 맥락을 판단하여 액션을 제출할 수 있는지 결정하는 조건입니다. 입력 매개변수가 받을 값을 정하고 변경 규칙이 수행할 작업을 정한다면, 제출 조건은 해당 요청을 허용할지를 정합니다.

관련 문서: 액션의 입력과 제출 조건

부수 효과(Side effect)

액션의 데이터 변경과 함께 구성하는 추가 동작입니다. 알림이나 웹훅을 통해 다른 업무 절차와 외부 시스템에 연결할 수 있습니다. 액션이 바꾸는 객체 데이터뿐 아니라 외부 요청과 전달되는 정보도 실행 결과에 포함하여 판단해야 합니다.

관련 문서: 액션과 함수의 연결

함수(Function)

입력을 받아 조회, 계산이나 업무 로직을 수행하는 재사용 가능한 코드입니다. 온톨로지 객체와 객체 집합을 사용하며, 함수의 종류에 따라 온톨로지 편집이나 외부 시스템 호출도 구현할 수 있습니다. 따라서 모든 함수를 부수 효과 없는 순수 계산으로 해석해서는 안 되며, 반환값과 변경 내용 및 호출 경로를 함께 확인해야 합니다.

관련 문서: 온톨로지 함수, 함수 언어와 실행 계약

함수 기반 액션(Function-backed action)

함수가 액션의 변경 로직을 구현하는 구성입니다. 함수가 편집 내용을 계산하는 것과 그 편집을 액션 호출로 실제 적용하는 시점은 구분합니다. 같은 함수를 다른 경로에서 호출한다고 해서 반환한 편집이 자동으로 적용되는 것은 아닙니다.

관련 문서: 액션과 함수의 연결, 함수 편집의 적용

객체 뷰(Object view)

특정 객체의 정보와 관련 업무를 모아 보여 주는 화면입니다. 주요 속성, 연결된 객체, 지표와 분석 또는 애플리케이션을 포함할 수 있습니다. 여러 객체를 검색하는 객체 집합 화면과 달리 선택한 개별 객체를 중심으로 구성합니다.

Ontology Manager

온톨로지의 정의를 만들고 유지하는 애플리케이션이며 OMA라고도 부릅니다. 객체 유형과 액션 유형을 구성하고 데이터소스를 연결하며, 의존 리소스와 데이터 갱신 상태를 조사합니다. 함수의 버전과 사용처를 확인할 수 있지만 코드 함수의 구현을 수정하는 작업은 코드 저장소에서 수행합니다.

온톨로지 색인(Indexing)

기반 데이터소스의 변경을 온톨로지 객체 상태에 반영하는 과정입니다. 여러 데이터소스나 사용자 편집을 함께 사용하는 구성에서는 기본 키와 속성의 해석 규칙도 관련됩니다. 입력 데이터셋의 갱신과 앱에서 조회하는 객체 상태의 갱신을 조사할 때 이 단계를 구분합니다.

관련 문서: 데이터소스와 객체 상태, 정의와 상태 관리

구체화(Materialization)

기반 데이터와 사용자 편집을 합친 객체 상태를 데이터셋이나 지원되는 제한 뷰로 제공하는 기능입니다. 후속 파이프라인에서 편집 결과를 사용하거나 객체 유형의 상태를 다운로드할 때 활용합니다. OSv2에서는 객체 편집을 허용하기 위해 구체화를 반드시 만들 필요가 없으며, 구체화 출력의 갱신 방식과 보존 조건은 별도로 정해집니다.

관련 문서: 온톨로지 상태의 구체화

애플리케이션과 개발 도구

Workshop

온톨로지 위에 위젯을 배치하고 변수와 이벤트를 연결하여 업무 애플리케이션을 만드는 도구입니다. 객체 정보를 표시하고 입력을 받아 정의된 액션을 제출할 수 있습니다. 사용자가 보고 있는 화면의 상태와 액션으로 반영하는 객체 데이터는 구분하여 구성합니다.

관련 문서: Workshop, 애플리케이션 실행 패턴

Workshop에서 위젯은 표, 차트나 입력 화면 등의 구성 요소입니다. 변수는 위젯의 입력과 출력을 연결하는 자료형이 있는 값이고, 이벤트는 사용자 상호작용에 따라 변수 갱신, 화면 이동이나 액션 실행을 연결합니다. 변수의 값을 바꾸는 동작과 온톨로지를 수정하는 액션 실행은 서로 다릅니다.

관련 문서: Workshop의 상태와 상호작용

Slate

화면 배치 도구와 HTML, CSS 및 JavaScript를 결합하는 맞춤형 앱 제작 환경입니다. 온톨로지와 함수 API를 호출하면서 화면과 상호작용을 직접 구성할 수 있습니다. 앱 화면을 만드는 일과 사용자 및 앱의 데이터 접근 권한을 부여하는 일은 별도입니다.

관련 문서: Slate, 앱 제작 방식 비교

Object Explorer

온톨로지의 객체와 관계를 검색하고 탐색하는 애플리케이션입니다. 익숙하지 않은 온톨로지에서 어떤 대상이 있는지 찾고 속성 조건으로 객체 집합을 좁힐 수 있습니다. 객체 유형의 정의를 관리하는 Ontology Manager와는 주된 작업 대상이 다릅니다.

관련 문서: Object Explorer, 애플리케이션 선택

Quiver

온톨로지 객체와 시계열 데이터를 분석하는 도구입니다. 링크를 탐색하고 시계열 수식과 시각화를 구성하며, 분석 결과를 대시보드로 활용할 수 있습니다. 데이터셋 중심으로 분석하는 Contour와 입력 대상 및 분석 방식이 다릅니다.

관련 문서: Quiver, 분석 도구 비교

Contour

데이터셋을 화면에서 탐색하고 필터, 결합과 집계를 구성하는 분석 도구입니다. 분석 결과의 시각화와 대시보드를 만들 수 있습니다. 온톨로지의 객체와 링크를 주로 다루는 Quiver나 Object Explorer와 구분합니다.

관련 문서: Contour, 분석 도구 비교

Code Repositories

변환과 온톨로지 함수 등을 코드로 개발하는 환경입니다. Git 브랜치, 변경 검토와 버전 관리를 사용하여 로직을 관리합니다. 같은 저장소 도구를 사용하더라도 데이터 변환과 앱에서 호출하는 함수는 실행 계약과 사용 API가 다릅니다.

관련 문서: Code Repositories, 데이터와 함수 실행

Code Workspaces

JupyterLab, RStudio Workbench나 VS Code 등의 환경에서 플랫폼 데이터를 사용하여 코드를 작성하는 개발 도구입니다. 데이터 과학, 통계와 탐색 작업에 활용합니다. 반복 실행할 운영 파이프라인의 코드와 변경 검토를 관리하는 Code Repositories와 목적을 구분합니다.

관련 문서: Code Workspaces, 개발 환경 선택

Developer Console

사용자 정의 앱의 온톨로지 리소스, OSDK 생성, OAuth 클라이언트와 호스팅 등을 구성하는 도구입니다. 앱이 선택한 리소스에 맞는 문서를 제공하며 Ontology MCP도 구성할 수 있습니다. 앱의 허용 범위에 리소스를 넣는 설정과 실제 실행 주체의 데이터 권한은 함께 적용됩니다.

관련 문서: Developer Console, 개발 도구 체계

온톨로지 SDK(Ontology SDK, OSDK)

선택한 온톨로지 정의에서 생성하는 타입이 있는 SDK입니다. 사용자 정의 코드에서 객체를 조회하고 링크를 탐색하며 액션과 함수를 사용할 수 있습니다. TypeScript, Python과 Java 등 언어별로 지원 기능이 다르며, SDK 생성이 데이터 접근 권한을 대신하지는 않습니다.

관련 문서: Ontology SDK, 개발 도구 체계

Foundry API와 플랫폼 SDK

데이터셋, 파일시스템, 데이터 연결, 빌드와 관리 설정 등의 플랫폼 리소스를 프로그램에서 사용하는 인터페이스입니다. 온톨로지 객체와 업무 기능을 중심으로 생성하는 OSDK보다 다루는 리소스 범위가 넓습니다. 플랫폼 SDK를 사용하는 경우에도 호출할 API의 인증과 권한 범위를 충족해야 합니다.

관련 문서: Foundry API, OSDK와 플랫폼 API

Compute Modules

기존 코드와 의존성을 컨테이너로 배포하여 Foundry의 함수 호출이나 데이터 처리에 연결하는 기능입니다. 여러 언어로 작성한 코드, 외부 모델과 장시간 연산을 통합하는 데 사용할 수 있습니다. 컨테이너의 실행 자원, 소스 연결과 상태 검사를 구성하며, Apollo의 제품 묶음인 Module과는 다른 개념입니다.

관련 문서: Compute Modules, 컨테이너와 사용자 API

전역 브랜치(Global branch)

여러 지원 애플리케이션의 변경을 같은 개발 문맥으로 묶는 브랜치입니다. Main에서 시작하여 변경을 작성하고 제안, 검토와 승인을 거쳐 배포합니다. 개별 코드 저장소의 브랜치나 가정 분석을 위한 온톨로지 시나리오와는 목적이 다르며, 모든 리소스와 함수 버전이 분기 대상인 것은 아닙니다.

관련 문서: Global Branching, 개발 브랜치의 범위

Automate

데이터 변화나 시간 등의 조건을 감시하고 조건을 충족하면 효과를 실행하는 자동화 도구입니다. 효과에는 액션, 함수와 알림 등이 있으며 선택한 효과의 실행 계약을 따릅니다. 함수 효과가 반환한 온톨로지 편집이 자동 적용되는 것은 아니므로 실제 객체 변경에는 액션 효과 등 적합한 경로를 사용합니다.

관련 문서: Automate, 조건과 효과

Workflow Lineage

애플리케이션과 그 기반 리소스가 서로를 사용하는 관계를 그래프로 조사하는 작업 공간입니다. 객체 유형, 액션과 함수 등의 의존 관계 및 실행 이력을 확인할 수 있습니다. 이전 이름은 Workflow Builder이지만, 트리거와 계산 및 효과의 실행 순서를 정의하는 현재의 Workflow Builder 실행 그래프와는 역할이 다릅니다.

AIP의 모델, 문맥과 평가

대규모 언어 모델(Large language model, LLM)

AIP에서 프롬프트와 제공된 문맥을 사용하여 응답을 생성하거나 도구 사용에 참여하는 모델입니다. AIP는 여러 모델을 연결하는 구성을 지원하며, 모델 선택은 입력과 출력, 도구 사용 방식 및 데이터 처리 조건에 맞춰 정합니다. 같은 입력에도 결과가 달라질 수 있어 모델 변경과 반복 실행을 평가해야 합니다.

관련 문서: 모델 선택과 수명주기, AIP Evals

AI 에이전트(AI agent)

모델이 주어진 지시와 문맥을 사용하면서 연결된 조회나 변경 도구를 호출하여 업무를 수행하는 구성입니다. AIP 챗봇을 앱이나 자동화에 통합하는 방식도 여기에 포함됩니다. 모델의 도구 사용, 외부 시스템 연결을 제공하는 Data Connection 에이전트, 배포 계획을 실행하는 Apollo 에이전트는 서로 다른 역할입니다.

관련 문서: AIP의 업무 연결, 챗봇의 문맥과 도구

블록을 연결하여 온톨로지 데이터와 LLM을 사용하는 함수를 구성하는 도구입니다. 블록은 조회, 계산, 조건 판단, 함수 호출과 모델 상호작용 등을 수행하며 출력을 다음 단계로 전달합니다. 온톨로지 편집을 실제 적용하려면 게시한 Logic 함수를 액션 유형에 연결하고 액션 호출로 제출합니다. 사용자 권한 실행과 프로젝트 권한 실행은 데이터 및 로그 접근 범위가 다릅니다.

관련 문서: AIP Logic의 함수와 실행 맥락

AIP Chatbot Studio

지시문, 애플리케이션 상태, 검색 문맥과 도구를 연결하여 대화형 챗봇을 만드는 도구입니다. 이전 이름은 AIP Agent Studio입니다. 챗봇을 함수로 게시하여 평가나 자동화에 사용할 수 있으며, 호출 경로의 입력과 실행 권한을 함께 구성해야 합니다.

애플리케이션 상태(Application state)

현재 작업이나 화면의 맥락을 챗봇에 전달하는 애플리케이션 변수입니다. 프롬프트에서 사용하여 선택한 대상이나 동적인 입력을 제공하며, 이전 구성에서는 Parameters라고 부르기도 했습니다. 앞서 주고받은 메시지인 대화 이력과는 별도로 관리합니다.

관련 문서: 챗봇의 애플리케이션 상태

프롬프트(Prompt)와 지시문

모델에 수행할 작업과 처리 방법을 전달하는 입력입니다. AIP 챗봇에서는 지시문, 도구 설명과 변수 설명이 시스템 프롬프트에 포함됩니다. 도구 사용을 글로 지시하는 것과 실제 도구를 연결하고 실행 권한을 부여하는 것은 별도 설정입니다.

관련 문서: 챗봇의 지시문과 설명

검색 증강 생성(Retrieval-augmented generation, RAG)

질문에 필요한 외부 정보를 검색하여 모델의 응답 생성에 제공하는 방식입니다. 모델이 학습한 내용 외에 현재 업무에 필요한 자료를 사용할 수 있게 합니다. 관련 자료를 검색했는지와 생성한 답이 사실 및 업무 규칙에 맞는지는 각각 평가해야 합니다.

검색 문맥(Retrieval context)

각 메시지에 대응하여 검색한 구체적인 정보입니다. 구성된 문서, 온톨로지 데이터나 함수 출력에서 관련 내용을 가져와 사용자 메시지와 함께 모델에 제공합니다. 검색 문맥이 응답의 자료를 제공한다면, 도구는 조회나 변경 기능을 실행합니다.

벡터 임베딩(Vector embedding)

텍스트의 의미를 수치 벡터로 표현한 값입니다. 문자열의 정확한 일치만 비교하는 대신 의미가 가까운 내용을 검색하거나 유사성을 비교하는 데 활용합니다. 임베딩은 검색을 위한 수치 표현이며, 응답을 생성할 때에는 검색으로 찾은 실제 정보가 문맥으로 제공됩니다.

도구(Tool)

LLM이 사용할 수 있도록 연결한 외부 기능이나 API입니다. 객체 조회, 함수 호출, 액션 실행과 애플리케이션 변수 갱신 등의 기능을 제공할 수 있습니다. 도구 설명, 실제 입력 및 출력, 데이터 변경 여부와 실행 권한은 함께 정의해야 합니다.

관련 문서: 챗봇 도구의 의미, 도구 유형

문맥 창(Context window)과 토큰(Token)

문맥 창은 모델이 한 번에 처리할 수 있는 텍스트의 범위이며 보통 토큰 단위로 계산합니다. 챗봇에서는 마지막 사용자 메시지뿐 아니라 시스템 프롬프트, 대화 이력, 검색 결과, 애플리케이션 상태와 도구 정보도 문맥에 포함됩니다. 제공할 정보의 관련성과 전체 크기를 함께 관리해야 합니다.

AIP Evals

AI를 사용하는 함수와 프롬프트의 동작을 평가하는 환경입니다. AIP Logic 함수, 함수로 게시한 챗봇과 코드 함수를 공통 사례와 기준으로 비교할 수 있습니다. 모델이나 프롬프트 변경의 영향뿐 아니라 같은 구성을 반복 실행했을 때의 변동도 조사합니다.

관련 문서: AIP Evals와 평가 모음

평가 모음(Evaluation suite)

평가 사례, 평가 대상 함수와 평가 함수를 묶은 구성입니다. 평가 대상 함수는 업무를 수행하고, 평가 함수는 실제 출력과 기대 결과 등을 비교하여 평가 지표(Metric)를 만듭니다. 사례별 결과와 집계 결과를 함께 보아야 일부 입력에서의 실패를 구분할 수 있습니다. 선택적 지표의 No value는 실패 점수나 숫자 0과 다릅니다.

관련 문서: 평가 모음의 구성 요소, 선택적 평가 지표

Autopilot과 워크벤치(Workbench)

Autopilot은 온톨로지 자동화의 상태와 실행을 관리하는 도구입니다. Autopilot의 워크벤치는 객체를 상태별로 표시하는 칸반과 자동화, 액션 및 함수의 의존성 그래프를 제공합니다. 실행 로그를 보는 Automation events와 함께 사용하여 자동화나 사람의 작업이 객체에 미친 영향을 조사합니다.

관련 문서: Autopilot, 워크벤치 시작하기

Palantir MCP와 Ontology MCP

Palantir MCP는 외부 AI 개발 도구에 플랫폼 문맥과 개발 기능을 제공하여 온톨로지 및 앱 제작을 지원합니다. Ontology MCP는 Developer Console 앱의 온톨로지 리소스를 도구로 노출하여 외부 에이전트가 객체를 조회하고 사전에 정의한 액션 등을 실행하게 합니다. 개발 정의를 다루는 경로와 업무 데이터를 사용하는 경로를 구분하며, 실제 노출 범위와 실행 권한은 각 설정을 따릅니다.

관련 문서: Palantir MCP, Ontology MCP, 개발 도구 체계

Foundry 제품 전달과 Marketplace

Marketplace

게시된 Foundry 제품을 찾고 필요한 입력을 연결하여 설치하는 애플리케이션입니다. 설치자는 출력 리소스를 검토하고, 지원되는 설치본의 업그레이드와 릴리스 채널 및 유지보수 시간대를 관리합니다. 제품을 제작하고 패키징하는 도구인 Foundry DevOps와 역할이 다릅니다.

관련 문서: Foundry 제품 제작과 배포

Foundry 제품(Product)

다른 사용자가 설치할 수 있도록 묶은 Foundry 리소스의 집합입니다. 온톨로지, 파이프라인, 모델과 업무 앱 등을 포함할 수 있습니다. 소프트웨어 기능의 배포 단위를 뜻하는 Apollo 제품과 관리 대상이 다릅니다.

관련 문서: 제품과 설치본의 개념, 애플리케이션의 제품 배포

Foundry 제품 버전(Product version)

제품의 특정 내용과 변경을 구분하는 버전입니다. 제작자가 새 버전을 제공하면 설치본을 수동으로 갱신하거나 지원되는 자동 업그레이드를 사용할 수 있습니다. 제품 버전은 배포할 내용의 구분이고 설치본은 그 내용을 특정 입력으로 배치한 결과입니다.

제품 입력(Input)과 출력(Output)

입력은 제품을 설치할 때 연결해야 하는 의존 리소스와 설정입니다. 출력은 설치를 통해 생성하는 리소스이며 Content라고도 부릅니다. 모든 제품이 입력을 요구하는 것은 아니며, 같은 제품도 입력을 달리하여 여러 번 설치할 수 있습니다.

관련 문서: 제품의 입력과 출력

스토어(Store)

목적이 비슷한 Foundry 제품을 모아 제공하는 공간입니다. 같은 플랫폼 인스턴스에서 만든 로컬 스토어와 다른 플랫폼 인스턴스가 제공하는 원격 스토어가 있습니다. Palantir가 관리하는 Foundry Store는 원격 스토어의 예입니다.

설치본(Installation)

Foundry 제품에 필요한 입력을 연결하여 배치한 결과입니다. 같은 제품을 여러 번 설치하면 각 설치본의 리소스와 설정을 따로 관리합니다. 설치 작업(Installation job)은 설치본을 만들거나 변경하는 실행이며, Apollo의 배포 개체(Entity)와는 별도 개념입니다. Marketplace는 설치한 콘텐츠를 직접 편집한 내용도 이후 제품 업그레이드에서 덮어씁니다.

관련 문서: 설치본의 의미, Marketplace 설치본 관리

Foundry DevOps

지원되는 Foundry 리소스를 설치 가능한 제품으로 묶고 버전, 의존 관계와 배포를 관리하는 도구입니다. 제작자는 제품 버전에 릴리스 채널을 지정하고 해당 채널을 추적하는 설치본에 새 버전을 제공합니다. 업무가 사용하는 모든 소스와 파일을 반드시 제품 출력으로 패키징할 수 있는 것은 아니므로 지원 리소스 범위를 따릅니다.

관련 문서: Foundry 제품 제작과 배포

Apollo 배포와 운영

Apollo 제품(Product)

Apollo가 배포하는 소프트웨어 기능의 단위입니다. 버전별 릴리스, 승격 파이프라인, 유지보수 시간대와 소유 팀 등의 정보를 가집니다. Foundry 제품이 업무 리소스의 설치 묶음이라면 Apollo 제품은 소프트웨어 릴리스와 배포 개체를 관리하는 기준입니다.

관련 문서: 제품, 릴리스와 버전, Apollo 용어집

제품 릴리스(Product release)

Apollo 제품의 특정 버전입니다. 릴리스 매니페스트는 제품 유형, 버전과 배포 관련 불변 특성을 정의하며 아티팩트와 의존 관계를 선언합니다. 매니페스트는 불변이지만 릴리스의 채널 소속이나 회수 상태는 운영 중 달라질 수 있습니다.

관련 문서: 제품, 릴리스와 버전, 릴리스와 매니페스트

배포 개체(Entity)

특정 배포 환경에 존재하는 Apollo 제품의 개별 인스턴스입니다. 같은 제품을 여러 환경이나 한 환경의 여러 이름으로 설치하면 개체를 구분하여 관리합니다. 상태가 보고되고 환경 설정에도 선언된 개체가 관리 대상이며, 관리 해제는 소프트웨어 설치 제거와 다릅니다.

관련 문서: 배포 개체, 관리되는 개체와 관리되지 않는 개체

배포 환경(Environment)

같은 인프라에 배치된 배포 개체들을 묶는 Apollo 관리 단위입니다. 환경에는 관리 설정, 연결 정보와 보고된 상태가 있습니다. Foundry 실행 환경을 뜻하는 플랫폼 인스턴스(Enrollment)나 리소스 협업 단위인 프로젝트와 구분합니다.

허브(Hub)와 스포크(Spoke)

허브는 하나 이상의 스포크 환경을 관리하며 설정과 제품 카탈로그를 저장하고 변경 계획을 발행합니다. 스포크는 허브의 관리를 받는 환경으로, 에이전트가 계획을 실행하고 상태를 보고합니다. 스포크 제어 플레인은 인증과 통신, 상태 수집 및 계획 실행을 담당하는 Apollo 서비스 집합입니다.

관련 문서: Apollo 핵심 구성, 스포크 제어 플레인

Apollo 에이전트(Apollo Agent)

스포크에서 허브의 변경 계획을 실행하고 진행 상태와 배포 개체의 상태를 보고하는 프로그램입니다. 소프트웨어 배포와 구성 변경을 담당합니다. AI 모델의 업무 도구 사용이나 Data Connection의 외부 데이터 연결을 수행하는 에이전트와는 별도입니다.

보고된 상태(Reported state)

에이전트가 담당 배포 개체에서 관측하여 스포크 제어 플레인에 보고한 정보입니다. 실제 버전과 실행 상태 등을 나타내며 운영자가 선언한 목표 설정과 구분합니다. 허브는 보고된 상태와 관리 설정의 차이를 계획 계산에 사용합니다.

관련 문서: 배포 개체와 상태, 보고된 상태의 의미

변경 계획(Plan)과 제약 조건(Constraint)

변경 계획은 허브가 에이전트에 전달하는 설치, 버전 변경이나 구성 변경 등의 실행 지시입니다. 제약 조건은 계획 실행 전에 충족해야 하는 요구로, 유지보수 시간대, 의존 제품 버전과 아티팩트 준비 상태 등이 포함됩니다. 목표 설정이 바뀌었다고 해서 모든 계획이 즉시 실행되는 것은 아닙니다.

배포 환경 설정과 배포 환경 구성값

배포 환경 설정(Environment settings)은 어떤 개체를 관리하고 어느 채널과 유지보수 조건을 적용할지 선언합니다. 배포 환경 구성값(Environment Config)은 여러 개체가 공통으로 참조할 환경 수준의 YAML 속성입니다. 개별 개체에서 제품 기본값을 바꾸는 설정 재정의(Config override)도 이 둘과 구분합니다.

관련 문서: 배포 환경 설정, 배포 환경 구성값, 설정 재정의

모듈(Module)

함께 설치할 Apollo 제품들과 각 구성 및 설정을 묶은 단위입니다. 반복되는 환경 구성을 모듈 릴리스로 관리할 수 있습니다. 컨테이너 코드를 Foundry 연산에 연결하는 Compute Modules나 Workshop의 화면 모듈과는 다른 배포 개념입니다.

릴리스 채널(Release channel)

안정성이나 레이블 등 공통 속성으로 Apollo 제품 릴리스를 묶은 집합입니다. 환경이나 개체는 채널을 추적하여 업그레이드 후보를 받습니다. 하나의 릴리스가 여러 채널에 속할 수 있으며 채널 이름 자체가 상하위 순서를 정하지는 않습니다.

릴리스 승격(Release promotion)

릴리스를 다른 채널에 추가하는 과정입니다. 사용자가 수동으로 수행하거나 승격 파이프라인의 조건을 충족하면 자동으로 수행합니다. 승격 파이프라인은 채널 순서와 단계별 조건을 정하며, 특정 개체에 그 릴리스를 실제 적용하는 계획 실행과는 구분합니다.

관련 문서: 릴리스 승격, 승격 조건

릴리스 회수(Recall)

문제가 있는 릴리스를 표시하여 해당 릴리스로의 변경을 제한하는 조치입니다. 이미 사용하는 개체는 정해진 전환 전략과 실행 제약에 따라 다른 허용 릴리스로 옮깁니다. 회수 표시와 모든 개체의 버전 전환 완료는 같은 시점이나 상태를 뜻하지 않습니다.

유지보수 시간대와 변경 억제 시간대

유지보수 시간대(Maintenance window)는 업그레이드, 구성 변경이나 자동 승격을 허용하는 반복 시간 구간입니다. 변경 억제 시간대(Suppression window)는 특정 개체나 환경에 계획을 발행하지 못하도록 하며 일반 유지보수 시간대보다 우선합니다. 계획 발행 억제와 이미 실행 중인 계획의 취소는 별도 동작입니다.

관련 문서: 유지보수 시간대, 변경 억제와 계획 취소

변경 요청(Change request)

Apollo 환경이나 배포 개체의 변경을 적용하기 전에 적절한 승인을 받는 공식 요청입니다. 관리 환경에 영향을 주는 수동 작업 대부분이 이 절차를 거칩니다. 요청 승인과 에이전트의 계획 실행은 구분하여 진행 상태를 확인합니다.

팀(Team)

Apollo로 소프트웨어를 운영하는 사람들의 기본 조직 단위입니다. 권한 부여, 알림 전달과 변경 요청 승인 등에 사용하며 관리자 그룹과 구성원 그룹을 각각 정의합니다. Foundry의 강제적 접근 경계인 조직(Organization)과는 별도 개념입니다.

보안, 거버넌스와 관측

접근 요건(Access requirements)

프로젝트나 리소스에 접근하기 위해 충족해야 하는 조직, 보안 표지 등의 조건입니다. 요건을 충족하는 것과 실제 읽기나 편집 권한을 받는 것은 다릅니다. 파일의 존재를 발견할 수 있어도 상류에서 상속된 데이터 요건을 충족하지 못하면 내용을 읽지 못할 수 있습니다.

권한(Permission)과 역할(Role)

권한은 특정 작업을 수행하게 하는 기능 단위이고, 역할은 한 리소스에서 필요한 권한을 묶은 구성입니다. Owner, Editor, Viewer, Discoverer 등의 기본 역할이 있으며 사용자 정의 역할도 사용할 수 있습니다. 프로젝트의 기본 역할(Default Role)은 접근 요건을 충족한 사용자에게 자동으로 부여하는 역할로, 기본 제공 역할 목록과는 다른 개념입니다.

보안 표지(Marking)

파일, 폴더와 프로젝트 등에 적용하는 강제적 접근 요건입니다. 일반 보안 표지는 적용된 표지를 모두 충족해야 하는 AND 방식입니다. 이름이나 분류용 메타데이터를 붙이는 태그와 달리 실제 접근 판단에 영향을 줍니다.

태그(Tag)

분류와 검색을 위한 구조화된 메타데이터입니다. 범주를 만들어 관리하고 범주의 가시성을 제한할 수 있지만, 태그 자체는 데이터 보안 요건을 부여하지 않습니다. 민감한 데이터의 접근 제한에는 해당 보안 표지나 정책을 사용해야 합니다.

관련 문서: 태그와 보안 표지의 차이

재량적 접근 통제와 강제적 접근 통제

재량적 접근 통제(Discretionary controls)는 역할 등으로 특정 리소스에서 할 수 있는 작업을 허용합니다. 강제적 접근 통제(Mandatory controls)는 조직, 보안 표지나 보안 분류처럼 역할과 관계없이 충족해야 하는 제한입니다. 역할 부여는 가산적이므로 낮은 역할을 추가해 기존 권한을 취소할 수 없습니다.

상속(Inheritance)과 전파(Propagation)

프로젝트나 폴더의 요건 및 역할이 내부 리소스에 적용되는 관계와, 데이터 의존 관계를 따라 보안 요건이 하류로 전달되는 관계를 다룹니다. 파일 계층의 역할 상속과 데이터 계보의 보안 전파는 같은 규칙이 아닙니다. 원본 리소스에 부여한 역할이 파생 데이터에 그대로 이어지는 것은 아닙니다.

관련 문서: 상속의 의미, 보안의 기본 구분

사용자(User)와 그룹(Group)

사용자는 개인 사용자 또는 서비스 계정이며, 그룹은 사용자나 다른 그룹을 묶는 단위입니다. 개인 사용자는 외부 신원 제공자에서 정의하는 경우가 많고, Foundry 내부 그룹에 외부 그룹과 사용자를 포함할 수 있습니다. 서비스 계정의 조직 정보와 감사 로그 귀속은 개인 사용자와 동일하다고 가정하지 않습니다.

관련 문서: 사용자와 그룹, 감사 로그의 조직별 귀속

신원 제공자(Identity provider, IdP)

로그인하는 사용자나 서비스를 확인하고 사용자, 그룹과 특성 정보를 제공하는 시스템입니다. Foundry의 인증 영역(Realm)은 사용자의 인증 출처를 나타냅니다. 인증으로 신원을 확인하는 일과 리소스에서 수행할 작업을 권한으로 허용하는 일은 구분합니다.

관련 문서: 사람, 그룹과 인증 출처, 인증 관리

제한 뷰(Restricted view)

기반 데이터셋 위에서 사용자 특성과 데이터 값을 비교하는 정책을 적용하여 읽을 수 있는 행을 제한하는 리소스입니다. 정책은 읽기 시점의 가시성을 정하며 반환된 값에 영구적으로 붙어 따라가는 것은 아닙니다. 제한 뷰를 기반으로 구체화한 출력도 별도의 권한과 보안 전파 조건을 따릅니다.

관련 문서: 리소스와 데이터 읽기, 제한 뷰와 구체화

보안 분류 기반 접근 제어(Classification-based Access Controls, CBAC)

민감한 정부 정보에 보안 분류 요건을 적용하는 강제적 접근 통제입니다. 분류 계층이나 범주 안의 OR 조건을 구성할 수 있으며, 일반 보안 표지의 AND 규칙과 구분합니다. 서로 다른 분류 범주의 조건은 함께 충족해야 하고, 조직과 프로젝트 역할 등의 다른 조건도 적용됩니다. CBAC는 기본 활성화 기능이 아닙니다.

관련 문서: 보안 분류 기반 접근 제어

파일 분류와 데이터 분류

CBAC에서 파일 분류(File classification)는 리소스의 존재를 발견하기 위한 요건입니다. 데이터 분류(Data classification)는 내부 데이터를 읽기 위한 요건이며 해당 리소스의 파일 분류와 상류 데이터 분류를 결합합니다. 이름과 스키마를 볼 수 있어도 데이터 내용은 보이지 않을 수 있습니다. 프로젝트 분류는 프로젝트 접근 요건이며 데이터 계보를 따라 전파되는 데이터 분류와 다릅니다.

관련 문서: 분류의 종류와 전파

Checkpoints

민감한 사용자 작업 전에 목적을 묻거나 정책 확인을 요구하고 그 응답을 기록하는 거버넌스 기능입니다. 사유 확인 설정은 표시 조건과 질문을 정하고, 사유 확인 기록은 제출 당시의 질문과 응답을 보관합니다. 사람의 승인 결정을 관리하는 Approvals나 장애 복구 상태를 저장하는 스트리밍 체크포인트와는 다른 개념입니다.

관련 문서: 사유 확인과 기록, 스트리밍 체크포인트

감사 로그(Audit log)

누가 언제 어떤 리소스에 어떤 작업을 했는지 조사하는 기록입니다. 사고 대응, 접근 검토와 책임 확인에 사용하며, 실행 성능을 조사하는 일반 서비스 로그와 목적이 다릅니다. 감사 로그에도 사용자 이름이나 검색어 등의 민감한 정보가 포함될 수 있어 접근과 보존을 관리해야 합니다.

관련 문서: 감사 로그의 수집, 전송과 보존

데이터 검증 조건(Data expectations)

파이프라인 입력이나 출력 데이터가 충족해야 하는 품질 조건입니다. NULL 금지, 값 범위나 기본 키의 고유성 등을 검사하며 설정과 실행 경로에 따라 빌드를 실패시켜 잘못된 결과의 전달을 막을 수 있습니다. 샘플을 보는 미리보기나 작업 종료 후의 상태 검사와는 검사 시점 및 범위가 다릅니다.

상태 검사(Health check)

리소스의 실행 상태, 내용, 스키마나 최신성 등을 관찰하는 검사입니다. 실행 작업의 성공, 전체 빌드의 성공과 스케줄 상태는 서로 다른 범위를 확인합니다. 데이터셋의 마지막 갱신 시각이 최근이라는 사실과 그 안의 원천 데이터가 최신이라는 사실도 구분합니다.

관련 문서: 실행 상태와 최신성 검사

모니터링 뷰(Monitoring view)

같은 담당자들이 관심을 갖는 모니터링 규칙과 상태 검사를 모은 파일 리소스입니다. 규칙은 감시할 리소스와 지표, 임계값 및 심각도를 정하고 구독자에게 경보를 전달합니다. 단일 리소스 외에 프로젝트 등의 동적 범위를 사용할 수 있지만 리소스 유형마다 지원 범위가 다릅니다.

관련 문서: 모니터링 뷰의 개념

로그(Log), 지표(Metric)와 추적(Trace)

로그는 실행 중의 메시지와 오류를, 지표는 성공 및 실패 횟수나 실행 시간 같은 측정값을 제공합니다. 추적은 함수, 액션과 LLM 호출을 연결하여 단계별 입력, 출력과 지연을 조사하는 데 사용합니다. 특정 실행의 원인을 찾는 일과 여러 실행의 경향을 보는 일에 맞춰 자료를 선택합니다.

보존 정책(Retention policy)

이전 트랜잭션의 데이터 등 더 이상 필요하지 않은 자료를 제거하는 기준입니다. 파일 나이 등의 조건으로 저장 비용과 데이터 관리 요건을 조정합니다. 데이터셋의 DELETE 트랜잭션이 현재 뷰에서 참조를 제거하는 것과 실제 기반 데이터를 삭제하는 보존 정책은 구분해야 합니다.

관련 문서: 데이터셋 삭제와 보존 정책

Control Panel

조직 또는 플랫폼 인스턴스 수준의 보안, 인증, 자원 사용과 운영 설정을 관리하는 중앙 화면입니다. 같은 관리 화면 안에서도 설정의 적용 범위와 필요한 권한이 다릅니다. 앱을 화면에 보이게 하는 설정과 실제 리소스의 데이터 권한은 별도로 적용됩니다.

Resource Management

계정, 프로젝트와 개별 리소스에 연산 및 저장 사용량을 연결하여 비용과 자원 배분을 관리하는 기능입니다. 사용 현황을 확인하고 필요한 한도를 정할 수 있습니다. 동시 연산 한도처럼 실행을 제한하는 설정과 예산 알림은 서로 다른 통제입니다.

관련 문서: 자원 사용과 플랫폼 관리

Keyboard shortcuts

팔란티어 플랫폼 한국어 해설