데이터가 아니라,
의사결정을 연결합니다

오늘 순서는 세 가지입니다. 먼저 고객사가 겪는 문제를 온톨로지가 어떻게 푸는지, 그다음 실제 제품이 어떤 앱으로 구성되고 어떻게 쓰는지 화면으로 보여드리고, 마지막으로 어떻게 시작하면 좋은지 제안드리겠습니다.

• 관계형 DB는 관계를 조인한 뒤에야 복원합니다테이블 수십 개를 오가며 키를 맞추는 일이 분석의 절반
• 벡터 DB는 의미는 잡지만 숫자 집계·권한 제어에 약합니다“비슷한 문서”는 찾아도 “이번 달 결품 금액”은 못 냅니다
• 그래프 DB는 연결은 보이지만 현업 업무 앱과 단절돼 있습니다보는 사람과 결정하는 사람이 다른 화면을 씁니다

SALES POINT고객의 문제는 데이터 부족이 아니라, 데이터·로직·액션이 서로 연결된 맥락의 부족입니다. 담당자는 오늘도 5개 화면을 열어놓고 결정합니다.

먼저 문제부터 짚겠습니다. 대부분의 고객사는 이미 RDB, 데이터 레이크, 최근엔 벡터 DB까지 갖고 계십니다. 그런데 현장 담당자는 여전히 여러 화면을 오가며 결정합니다. 데이터가 부족한 게 아니라, 데이터·로직·액션이 서로 연결된 '맥락'이 없기 때문입니다.

“The Ontology represents the decisions in an enterprise, not simply the data.”palantir.com/docs — Why create an Ontology?

• Data — ERP·MES·IoT·문서·지리공간 + 결정 과정에서 생기는 ‘결정 데이터’
• Logic — 업무 규칙, ML 모델, 최적화 로직을 사람과 에이전트가 같은 방식으로 호출
• Action — 승인·발주·알림 같은 실행을 시나리오로 검토 후 원천 시스템에 기록(writeback)
• Security — 역할·마킹·목적 기반 정책을 런타임에 계산, 사람·에이전트에 동일 적용

팔란티어가 정의하는 온톨로지는 '데이터 모델'이 아니라 '결정 모델'입니다. 모든 결정은 데이터, 로직, 액션으로 이뤄지고, 이를 보안이 감쌉니다. 온톨로지는 이 네 요소를 한 레이어에서 관리해 사람과 AI 에이전트가 같은 지도를 보고 일하게 만듭니다.

Dataset (기존)	Ontology (Foundry)
Dataset→	Object type 객체 타입
Row→	Object 객체(인스턴스)
Column→	Property 속성
Field→	Property value 속성 값
Join→	Link type 링크(관계)
(없음)+	Action type 객체를 바꾸는 규칙

SALES POINT기존 DW 팀의 지식이 그대로 이어집니다. 새로 배우는 것은 “객체를 어떻게 바꿀 수 있는가”를 정의하는 Action 하나입니다.

어렵게 들리지만 개념 매핑은 단순합니다. 데이터셋은 객체 타입, 행은 객체, 컬럼은 속성, 조인은 링크입니다. 여기에 '객체를 어떻게 바꿀 수 있는가'를 정의한 액션 타입이 더해지면, 항공사의 공항·항공편·기체·지연이 서로 연결된 살아있는 모델이 됩니다.

공식 문서의 백엔드 구성: OMS(메타데이터) · Object DB(인덱싱/쿼리) · OSS(객체 집합) · Actions · Data Funnel · Functions on Objects가 마이크로서비스로 온톨로지를 구동합니다.

Foundry(데이터 운영) + Ontology(결정 모델) + AIP(AI) = 하나의 운영체제

제품 전체를 한 장으로 보면 이렇습니다. 왼쪽에서 데이터를 연결하고 정제해 온톨로지에 매핑하고, 오른쪽의 앱과 AI가 그 위에서 일합니다. 중요한 건 화살표가 오른쪽으로만 가지 않는다는 점입니다. 현장의 결정이 액션으로 다시 온톨로지와 원천 시스템에 기록됩니다. 이제 왼쪽부터 하나씩 실제 화면으로 보겠습니다.

• 연결 방식 Batch(주기 동기화) · Streaming(실시간) · Webhook(이벤트) · Export(외부로 내보내기)
• 핵심 개념 Source(연결 정의) · Sync(동기화 작업/모니터링) · Schema(구조 매핑) · Credential(인증)
• 견고성 실패 시 자동 재시도, 소량 배치 쿼리, 데이터 헬스 모니터링·알림 내장공식 문서 “Robustness / Extensibility / Ease of use” 3원칙
• 원본 그대로 외부 전처리 없이 raw로 적재 → 이후 모든 변경 이력이 Foundry 안에 남습니다

첫 단계는 Data Connection입니다. SAP, Oracle, Salesforce, 파일 시스템, IoT 스트림까지 배치·스트리밍·웹훅으로 가져오고, 반대로 외부 시스템에 내보내기도 합니다. 팔란티어의 철학은 '원본을 그대로 넣어라'입니다. 그래야 이후 모든 가공 이력이 플랫폼 안에서 추적됩니다.

• 그래프·폼 UI 조인 키, 컬럼 타입 캐스팅을 제안 — 코드 몰라도 변환 정의
• 타입 안전 · 엄격한 출력 검사 빌드 전에 스키마 오류를 잡고, 기대 출력 불일치 시 빌드 차단
• Spark(배치) · Flink(스트리밍) 지연시간·처리량·비용에 따라 모드 선택, 백엔드가 코드 생성
• Git 브랜치 · Use LLM 변환 변경 이력 추적, 요약·키워드·임베딩 등 미디어 데이터 고급 변환

SALES POINT데이터 엔지니어 병목을 풉니다. 현업 분석가가 직접 파이프라인을 만들고, 엔지니어는 리뷰와 코드 노드에 집중합니다.

두 번째, Pipeline Builder입니다. 데이터 엔지니어는 코드로, 현업 분석가는 클릭으로 같은 파이프라인을 만듭니다. 백엔드가 변환 코드를 대신 쓰고 스키마 오류를 빌드 전에 잡아주기 때문에, 파이프라인이 깨져서 새벽에 전화받는 일이 줄어듭니다.

입력

정형 테이블 · 반정형 JSON/XML/CSV · 비정형 이미지(png/jpeg/dicom) · 비디오 · 문서(pdf/docx) · 오디오 · 시계열/스트리밍

처리

파싱 · 정규화 · 조인 · 집계 · 임베딩 생성 · LLM 변환(요약, 분류, 추출) — 배치/스트리밍 모드 선택

출력

Dataset · Media set · Virtual Table · 그리고 Ontology 객체 타입으로 직접 출력 — 다음 단계로 바로 연결

입출력을 보면 이 제품의 폭이 보입니다. 테이블뿐 아니라 이미지, 영상, PDF, 오디오 같은 비정형 데이터를 그대로 받아 임베딩이나 LLM 변환을 거쳐, 데이터셋이나 미디어셋, 그리고 온톨로지 객체로 바로 출력합니다.

• 포인트앤클릭 분석 필터 → 집계 → 시각화 → 대시보드 동기화, 파라미터로 즉시 전환
• 결과 저장 분석 결과를 새 Dataset으로 저장·공유해 다음 단계 입력으로 사용
• 대규모 처리 Spark SQL 기반 고성능 조인·집계 — 화면 예시는 140만 행 택시 데이터
• 역할 Ontology 매핑 전 데이터 탐색과 임시 분석, 전처리 도구

온톨로지로 올리기 전에 데이터를 빠르게 훑어보는 도구가 Contour입니다. 화면은 뉴욕 택시 140만 건 데이터를 파라미터로 필터링한 대시보드입니다. 분석가가 SQL 없이 정제와 집계를 끝내고, 그 결과를 그대로 다음 단계의 데이터셋으로 넘깁니다.

• Discover 홈 최근·즐겨찾기 객체 타입, 타입 그룹, 의존 관계(dependents)를 한눈에
• 객체 타입 뷰 메타데이터 · 속성 · 액션 타입 · 링크 그래프 · 데이터 소스 · 사용량(Usage)
• 변경 관리 Proposals(제안)·브랜치로 검토 후 반영, History로 복원
• 실제 규모 화면 예시: Object types 3,312 · Link types 4,555 · Action types 7,665 · Functions 5,423

SALES POINT“누가 이 객체를 쓰고 있나”가 보이기 때문에, 스키마 변경이 두렵지 않습니다.

세 번째, 온톨로지의 관제탑인 Ontology Manager입니다. 실제 화면을 보시면 객체 타입 3천여 개, 링크 4천여 개, 액션 7천여 개가 한 곳에서 관리됩니다. 누가 어떤 객체를 쓰는지 의존성이 보이고, 변경은 제안과 브랜치를 거쳐 안전하게 반영됩니다.

Object type

실세계 엔티티·이벤트의 스키마. 속성(Property), 공유 속성, 구조체(Struct), 값 타입으로 의미를 정의합니다.

Link type

객체 간 관계. 조인이 아니라 ‘탐색(search around)’으로 연결된 객체를 따라갑니다. 1:1 · 1:N · N:N.

Action type

한 번의 트랜잭션으로 여러 객체·속성·링크를 변경. 파라미터·검증·권한·알림·웹훅 부수효과까지 정의.

Function

TypeScript / Python 서버 로직. Workshop 컬럼·차트, 커스텀 집계, 외부 API 조회, LLM 스트리밍까지.

온톨로지는 네 가지 블록으로 만듭니다. 객체와 링크가 '의미'를, 액션과 함수가 '움직임'을 담당합니다. 특히 액션은 단순 수정이 아니라 검증과 알림, 권한이 포함된 하나의 트랜잭션이라서, 현업이 앱에서 버튼을 누르는 순간 거버넌스가 자동으로 적용됩니다.

모델링

Properties 탭에서 컬럼 자동 매핑(Automap all), 기본키·타이틀키 지정, Object · Link · Property 버전 관리

시계열 · 지리공간

Time Series 속성: 단위·정렬, 센서 데이터 자동 수집 · Geospatial: Raster/Vector, Geohash 좌표계, 위치 기반 분석

보안 · 검증

매핑 단계에서 정책·보안 설정과 유효성 검증을 함께 정의 — 데이터 접근 제어가 모델의 일부

실제 매핑 화면입니다. 공항 데이터셋의 컬럼을 속성으로 끌어와 기본키와 타이틀을 지정하면 끝입니다. 센서 시계열이나 위경도 같은 지리공간 데이터도 같은 화면에서 속성으로 붙습니다. 이 단계에서 보안 정책이 함께 정의되는 것이 팔란티어의 특징입니다.

• 검색 프로젝트·테이블·컬럼명으로 데이터셋을 찾고 그래프에 펼치기
• 시각화 파이프라인 전체 흐름과 관계를 상호작용적으로 확장
• 심층 분석 노드별 스키마 · 빌드 이력 · 코드(Transform) 즉시 확인
• 연결 객체 타입 우클릭 → Ontology Manager로 바로 이동(Configure object type)

SALES POINT감사·규제 대응 시 “이 숫자가 어디서 왔는가”를 5분 안에 증명합니다.

감사나 품질 이슈가 생기면 Data Lineage를 엽니다. 어떤 원천에서 어떤 변환을 거쳐 이 객체가 만들어졌는지 그래프로 보이고, 노드를 클릭하면 코드와 빌드 이력까지 바로 확인됩니다. 규제 산업 고객이 가장 좋아하는 화면입니다.

• Object Explorer 사전 설정 없이 필터 · Search Around · 차트로 탐색, 객체 집합 비교, 일괄 액션·내보내기예: “Bombardier 제조 항공기 중 2018년 3월 운항편”을 클릭 3번으로
• Object Views 객체 하나의 프로필 · 링크된 객체 · 핵심 지표 · 관련 앱을 한 페이지에환자, 공항, 설비, 고객… 타입별로 구성, 전체/패널 두 형태
• 공통 온톨로지가 준비되면 개발 없이 즉시 사용 — 첫 번째 “공짜 앱”

온톨로지가 준비되면 현업은 별도 개발 없이 바로 씁니다. Object Explorer에서 '봄바디어 제조 항공기 중 3월 운항편'처럼 클릭으로 검색하고, Object Views에서 객체 하나의 모든 관련 정보를 한 페이지로 봅니다. 이것이 온톨로지 위에서 앱이 공짜로 따라오는 첫 번째 효과입니다.

• 객체가 빌딩 블록 모든 데이터는 온톨로지에서 읽고, Action으로 쓰고, Function·파생 속성으로 계산
• 대표 패턴 인박스·태스크 관리(알림 분류·처리), 상황판(COP), 크로스앱 드래그앤드롭
• 일관된 디자인 시스템 레이아웃·이벤트 시스템으로 “커스텀 React 앱 수준”의 UX (공식 문서 표현)
• 화면 예시 항공편 지연 알림 인박스 — 필터 · 테이블 · 객체 뷰 · De-Escalate 액션 버튼

SALES POINT대시보드가 아니라 업무를 처리하는 앱입니다. 현업 리더가 며칠이 아니라 몇 시간 안에 만듭니다.

Workshop은 팔란티어의 앱 빌더입니다. 화면은 항공편 지연 알림 인박스로, 왼쪽 필터, 가운데 테이블, 오른쪽 객체 뷰와 액션 버튼이 모두 클릭으로 구성됐습니다. 대시보드가 아니라 실제 업무를 처리하는 앱을 현업 리더가 몇 시간 안에 만듭니다.

• 카드 기반 분석 필터 · 집계 · 차트 · 히트맵을 카드로 쌓고 드릴다운, 파라미터로 뷰 전환
• 조인 없는 탐색 링크를 따라(search around) 연결 객체를 가져옵니다 — 키를 몰라도 됩니다
• 시계열 특화 전용 시계열 DB, 센서·신호 처리 함수, Bollinger band·임계값 탐색(화면 예시)
• 확산 Canvas · Graph 모드, 대시보드 템플릿, Workshop·Notepad에 임베드, 온톨로지 writeback

분석가를 위한 Quiver입니다. 실제 화면은 차 생산 배치와 발효 탱크 온도 시계열을 함께 분석하는 모습입니다. 조인을 몰라도 링크를 따라가며 분석하고, 결과는 대시보드로 굳혀 Workshop 앱에 끼워 넣을 수 있습니다.

• 그래프 탐색 객체와 링크를 노드·엣지로, 템플릿 저장·공유, Workshop 임베드
• 시계열 · 이벤트 · 시나리오 노드에 수요·예측 시계열을 붙이고, 모델 기반 시뮬레이션 실행
• 지식 그래프 문서 → Chunk · Entity 추출(LLM) → N:N Join Table → 출처가 붙는 검색·응답
• 화면 예시 창고 → 원재료(Malt·Hops·Corn) → 레시피 → 제품 → 고객 30곳의 생산 라인 그래프

SALES POINT“이 공급사가 멈추면 어느 고객 주문이 영향받나”를 그래프 위에서 바로 시뮬레이션합니다.

Vertex는 온톨로지를 그래프로 보는 앱입니다. 화면은 창고에서 원재료, 레시피, 제품, 고객으로 이어지는 생산 라인 그래프와 수요 예측 시계열입니다. 문서를 청크와 엔티티로 쪼개 지식 그래프를 만들면, 에이전트 응답에 출처가 붙어 할루시네이션을 억제합니다.

• 프로세스 마이닝 로그 객체에 Process ID · State · Timestamp만 있으면 상태 전이를 자동 추출
• 진단 이상 경로 · 병목 · 리드타임 시각화, 기대 경로(Expected path)와 비교, KPI 알림
• 적용 사례(문서) 보험 클레임, 병원 환자 여정, 구매→지급(P2P), 주문→수금(O2C)
• AI 오케스트레이션 다단계 AIP 워크플로에서 여러 에이전트를 순서대로 묶고, 사람이 개입할 지점 정의

Machinery는 프로세스 마이닝 도구입니다. 로그에 프로세스 ID, 상태, 시각만 있으면 실제 업무 흐름을 그려주고, 어디서 시간이 새는지 보여줍니다. 보험 클레임이나 구매-지급 프로세스를 개선하고, 여러 AI 에이전트를 단계별로 묶는 프레임워크로도 쓰입니다.

• 노코드 LLM 함수 Use LLM · Semantic Search · Control Flow 블록 조합, Chain-of-Thought 옵션
• 도구(Tools) Apply actions(객체 생성·수정) · Call function · Query objects · Calculator — LLM이 온톨로지에 접근하는 통로
• 평가·운영 AIP Evals로 프롬프트 테스트 · 실패 원인 분류 · 회귀 방지, 사용량·비용 추적, 자동화(Automation)
• 보안 사용자의 읽기 권한을 그대로 상속 — 사용자가 못 보는 데이터는 모델도 못 봅니다

SALES POINT“챗봇”이 아니라 액션까지 실행하는 함수입니다. 결과는 사람 검토(staged) 후 반영하도록 설정할 수 있습니다.

이제 AI입니다. AIP Logic은 LLM 함수를 노코드로 만드는 환경입니다. 프롬프트 블록에 온톨로지 객체를 입력으로 넣고, 결과로 액션을 실행하게 할 수 있습니다. 문서의 예시는 공급망 이메일을 읽고 과거 해결 사례를 찾아 조치를 추천하는 함수입니다. 모델은 사용자 권한 범위 안의 데이터만 읽습니다.

• 에이전트에 필요한 세 가지 신뢰할 데이터 · 호출 가능한 도구 · 넘어서면 안 되는 권한 경계
• 온톨로지의 역할 장기 메모리(객체·링크) + 도구 목록(액션·함수) + 보안 정책 — 프레임워크가 무엇이든 공통 기반
• Ontology Augmented Generation 임베딩 기반 의미 검색을 객체와 결합해 출처 있는 응답 생성
• 결정 계보 에이전트의 판단·행동이 어떤 데이터 버전 위에서 이뤄졌는지 자동 기록 → 학습·감사

요즘 고객사마다 에이전트 프레임워크를 검토하십니다. 하지만 어떤 프레임워크를 쓰든 결국 필요한 건 '우리 회사의 맥락'입니다. 온톨로지는 에이전트에게 검증된 데이터, 실행할 수 있는 액션, 그리고 넘어서면 안 되는 권한 경계를 한 번에 제공합니다.

• 동적 정책 역할 · 마킹 · 목적 기반 정책을 런타임에 계산, 사람과 에이전트에 동일 적용
• 세밀한 제어 객체 보안 정책, 속성 단위 보안, 제한 뷰(Restricted views)
• 결정 계보 누가 · 언제 · 어떤 데이터 버전으로 · 어떤 앱에서 결정했는지 자동 기록
• 변경 통제 온톨로지 변경은 Proposals · 브랜치 · History로 검토·복원

SALES POINT보안팀 검토 시간을 줄입니다. 정책이 앱마다 아니라 온톨로지에 한 번 정의되기 때문입니다.

마지막 제품 포인트는 보안입니다. 온톨로지는 객체와 속성 단위로 권한을 계산하고, 모든 결정의 계보를 자동으로 남깁니다. 사람과 에이전트가 같은 정책 아래 움직이기 때문에, 금융·국방·의료처럼 규제가 강한 산업에서 먼저 채택된 이유가 여기 있습니다.

귀사에 적용하면 이런 시작점이 가능합니다. 제조라면 설비 이상 감지와 정비 액션, 물류라면 결품 인박스와 대체 발주, 금융이라면 클레임 프로세스 개선입니다. 공통점은 하나의 유스케이스, 서너 개의 객체 타입으로 시작해 앱과 AI를 얹어간다는 것입니다.

이 자료에 사용된 모든 화면의 출처입니다. 문서 페이지는 오늘 날짜로 직접 캡처했고, 제품 화면은 공개 영상의 프레임을 인용했습니다. 자세한 내용은 각 링크에서 확인하실 수 있습니다. 시청해 주셔서 감사합니다.