Aiden Kwak Pages
02 · Blog · 기록Palantir Foundry3/7

Palantir Foundry(3) - 온톨로지 Deep Dive, Data

2026-05-13 ·

Palantir Learn 의 파운드리 기초 과정 을 따라가며 공부하고 정리한 기록입니다.

지난 글에서 온톨로지가 시맨틱, 키네틱, 다이나믹 세 레이어로 이루어진다고 했습니다. 이번부터는 이 온톨로지를 어떻게 만드는가에 대한 이야기입니다. 가장 먼저 깔리는 첫 번째 버킷은 데이터입니다.

결론부터 한 줄로:

데이터를 연결하는 것은 어렵지 않습니다. 어려운 건 그 데이터를 조직의 명사 (고객, 매장, 제품) 에 맞는 모양으로 옮기는 일과, 옮긴 다음 그 결과를 신뢰할 수 있게 유지하는 일입니다. Foundry 의 데이터 도구들은 이 두 가지에 집중합니다.

출발점: 무엇이든 연결되어야 한다

Foundry 의 데이터 도구는 정형, 비정형, 테이블, IoT, 지리공간 그리고 SAP, Salesforce, Oracle 같은 상용 시스템까지 기본적으로 연결됩니다.

여기까지는 사실 놀라울 게 없습니다. 요즘 데이터 통합 도구는 대부분 비슷한 커넥터 풀을 가지고 있습니다. 차이가 벌어지는 건 그 다음 단계입니다.

HyperAuto: SAP 같은 괴물에 맞서기

가장 인상적인 예시 중 하나가 HyperAuto 입니다. SAP 데이터를 본 적이 있는 사람이라면 알겠지만, SAP 는 수만 개의 테이블과 수십 년 누적된 워크플로 로직으로 이루어진 시스템입니다. 여기서 데이터를 깔끔하게 추출하는 작업은 사실상 별도의 직군이 있을 정도로 무겁습니다.

HyperAuto - SAP 데이터 수집/정리/변환 자동화

HyperAuto 는 이 과정을 상당 부분 자동화합니다.

  • 소스 시스템의 테이블/모듈을 동기화 전에 미리 탐색할 수 있고
  • 선택한 모듈/워크플로에 필요한 테이블을 자동으로 그룹화해주며
  • 수집 시 적용할 다운스트림 로직까지 함께 준비합니다.

이걸 처음부터 직접 짜는 것과 비교하면 차이가 너무 큽니다. 그리고 더 중요한 건, 결과물이 단순한 raw 테이블이 아니라 이미 온톨로지에 들어갈 수 있는 모양으로 정리되어 나온다는 점입니다.

진짜 어려운 일: 조직의 모양에 맞추기

다양한 소스를 연결하는 것만으로는 부족합니다. 이건 Palantir 의 표현을 그대로 빌리자면 다음과 같습니다.

다양한 소스의 데이터를 조정해 매장 위치, 고객, 창고 등 조직의 온톨로지 표현과 실제로 일치하는 형식으로 데이터를 가져와야 한다.

이게 정말 어려운 부분입니다. 시스템 A 의 고객 ID 와 시스템 B 의 고객 ID 는 같은 사람을 다르게 부르고, 시스템 C 의 매장 코드와 시스템 D 의 지점 번호는 비슷하지만 미묘하게 다릅니다.

온톨로지 파이프라인 빌더 - low-code 구성

온톨로지 파이프라인 빌더 - 변환 단계

Foundry 는 이 단계를 위해 low-code 도구와 pro-code 도구를 동시에 제공합니다. 데이터 엔지니어는 SQL 과 Python 으로 정교한 변환을 짜고, 그렇지 않은 사용자는 시각적 빌더로 파이프라인을 구성합니다. 같은 결과물을 만들 수 있는 두 경로가 같은 시스템 안에 있다는 점이 핵심입니다.

Data Lineage: 신뢰의 인프라

데이터를 옮긴 다음에 따라오는 질문은 항상 비슷합니다.

  • 이 KPI 는 어디서 온 숫자인가?
  • 이 데이터셋은 최신인가?
  • 이 데이터셋은 정상인가?
  • 누가 이 데이터에 접근할 수 있는가?

Data Lineage 가 이걸 다룹니다. 데이터셋에 가해진 각 수정사항이 추적되고, 분석/운영/어플리케이션이 사용하는 데이터를 소스까지 거꾸로 따라갈 수 있습니다. 그 과정에서 적용된 변환도 하나하나 점검 가능합니다.

Data Lineage - 빨간 박스는 오래된 데이터셋, 파란 박스는 최신

여기에 더해 시각적인 신호도 들어 있습니다. 빨간 박스는 파이프라인 안의 오래된 데이터셋, 파란 박스는 최신 데이터셋. 한눈에 어디부터 다시 돌려야 하는지가 보입니다.

별것 아닌 것 같지만, 이런 신뢰 인프라가 없으면 다음 단계인 모델과 분석은 결국 가정 위에 가정을 쌓는 형태가 됩니다. 모델이 학습한 데이터가 어떻게 만들어졌는지 모르면, 그 모델의 예측을 받아들이는 의사결정자는 결국 그냥 믿어달라 는 말을 들을 수밖에 없습니다.

정리

데이터 단계에서 Foundry 가 잡고 있는 것은 결국 다음 세 가지입니다.

  • 연결의 범위 (정형, 비정형, IoT, SAP 등 무엇이든)
  • 조직의 모양으로 옮기는 변환 (low-code + pro-code)
  • 신뢰를 유지하는 추적 (Data Lineage)

이 세 가지가 갖춰져야 비로소 그 위에 모델을 올릴 수 있습니다. 다음 글에서 모델 빌딩과 Modeling Objectives 를 봅니다.

Back toBlog 목록