Foundry 데이터 통합 가이드 — 데이터 커넥션부터 파이프라인까지
도입
온톨로지나 AIP 이야기를 하기 전에 먼저 짚어야 할 게 있습니다. 회사 데이터가 애초에 Foundry 안으로 어떻게 들어오고, 어떻게 정제되어 온톨로지의 재료가 되는가입니다. 이 과정을 팔란티어는 “데이터 통합(Data Integration)”이라는 영역으로 묶어서 다룹니다. 흔히 말하는 ETL/ELT와 겹치는 부분도 있지만, 범위는 그보다 넓습니다. 이번 글에서는 데이터가 Foundry에 연결되는 지점부터 파이프라인을 거쳐 정제되는 흐름까지를 정리해보겠습니다.
데이터 연결과 데이터 파이프라인, 두 개의 축
Foundry의 데이터 통합 영역은 크게 두 축으로 나뉩니다.
- 데이터 연결(Data Connection): 외부 시스템(데이터베이스, SaaS, 파일 스토리지, API 등)과 Foundry 사이의 연결을 설정하고, 에이전트·소스·싱크 같은 리소스를 통해 데이터를 들여오거나(ingest) 내보내는(export) 작업입니다.
- 데이터 파이프라인(Data Pipeline): 들어온 원천 데이터를 가공·변환해 온톨로지에 구조화하거나, 분석·머신러닝 워크플로의 기반이 되는 정제된 데이터셋으로 만드는 과정입니다.
파이프라인을 만드는 방식도 사용자 수준에 따라 나뉩니다. 비기술 사용자도 점-클릭으로 구성할 수 있는 로우코드 도구 Pipeline Builder, 복잡한 로직이나 외부 라이브러리가 필요할 때 쓰는 코드 기반 Transforms(Python/SQL/Java), 그리고 SAP 같은 특정 원천 시스템에 대해 동기화부터 온톨로지 매핑까지 자동으로 생성해주는 상위 자동화 계층 HyperAuto입니다. 기술 조직 하나가 모든 파이프라인을 코드로 짤 필요가 없다는 뜻이고, 반대로 복잡한 로직이 필요한 곳에서는 코드로 내려갈 수 있다는 뜻이기도 합니다.
데이터 계층을 이해하는 데 필요한 핵심 개념
Foundry의 데이터 계층에는 파이프라인 도구와 무관하게 공통으로 적용되는 개념들이 있습니다. 전부 나열하기보다 실무에서 자주 부딪히는 것 위주로 짚어보겠습니다.
- 데이터셋(Dataset): 파이프라인의 가장 기본 단위입니다. 파일 모음을 감싸는 래퍼로, 권한·스키마·버전 관리가 통합되어 있습니다. 모든 변경은 트랜잭션 단위로 기록되어 특정 시점의 상태를 재현할 수 있습니다.
- 브랜칭(Branching)과 빌드(Build): 데이터셋의 브랜치·트랜잭션은 각각 Git의 브랜치·커밋과 대응합니다. 빌드는 지정된 브랜치에서만 실행되기 때문에 서로 다른 사용자의 변경을 격리할 수 있습니다 — 코드처럼 데이터도 버전 관리된다는 뜻입니다.
- 스트림(Stream): 데이터셋과 같은 버전 관리·권한 체계를 가지면서도 저지연 뷰를 제공하는 구조입니다. 배치 처리로는 부족한 실시간성이 필요할 때 씁니다.
- 변경 데이터 캡처(CDC): 마지막 실행 이후 새로 생기거나 바뀐 레코드만 처리하는 패턴입니다. 매번 전체 데이터를 다시 훑지 않아도 되는 증분 파이프라인을 만들 수 있습니다.
- 가상 테이블(Virtual Table): 데이터를 Foundry에 먼저 적재하지 않고도 외부 플랫폼의 테이블을 직접 질의할 수 있게 해주는 포인터입니다. 원천마다 다른 저장 형식을 추상화해줍니다.
이 개념들의 공통점은 “데이터도 소스코드처럼 다룬다”는 철학입니다. 버전 관리, 브랜치, 리니지(lineage) 추적 — 개발자에게 익숙한 개념들이 데이터 계층에도 그대로 적용됩니다.
Data Connection의 구조: 제어 평면과 워커
Data Connection은 Foundry와 외부 시스템 사이의 모든 연결을 관장하는 애플리케이션입니다. 구조는 크게 Foundry의 제어 평면(control plane)과 실제 데이터 이동을 수행하는 워커(worker) 계층으로 나뉩니다. 사용자가 소스·싱크를 정의하면 Foundry가 이를 워커에 작업으로 전달하고, 워커가 외부 시스템에 직접 연결해 데이터를 읽거나 씁니다.
워커는 두 종류입니다.
- Foundry Worker(클라우드 호스팅): 팔란티어가 관리하는 환경에서 실행되며, 공개 인터넷이나 사전 승인된 경로로 접근 가능한 시스템에 적합합니다.
- Agent Worker(고객 환경 호스팅): 고객의 온프레미스·사설 VPC 내부에 설치되어, 외부에서 직접 접근할 수 없는 격리된 시스템(내부 데이터베이스, API 등)에 연결할 때 씁니다. 아웃바운드 연결만으로 동작하도록 설계되어 있어, 고객 네트워크의 인바운드 방화벽 정책을 바꿀 필요가 없습니다.
이 구조가 실무적으로 중요한 이유는, “보안팀이 걱정하는 지점”과 “데이터팀이 필요로 하는 지점”을 분리해서 관리할 수 있기 때문입니다. 자격 증명이나 네트워크 접근 같은 민감한 설정은 중앙에서 통제하면서도, 개별 팀에게는 자신들이 쓰는 소스·싱크에 대한 운영 권한만 위임하는 식의 연합(federated) 보안 모델이 가능해집니다.
마무리
정리하면, Foundry의 데이터 통합은 단순히 “데이터를 옮기는 것”이 아니라 데이터가 들어오는 연결 지점(Data Connection)과 그것을 다듬는 파이프라인(Pipeline)을 하나의 체계 안에서 버전 관리·권한 관리와 함께 다루는 계층입니다. 이 위에 온톨로지가 얹히고, 그 위에 AIP 같은 생성형 AI 기능이 다시 얹히는 구조입니다. 결국 AI가 회사 데이터를 “이해”하려면, 그 전에 데이터가 어디서 와서 어떻게 정제되는지가 먼저 정리되어 있어야 합니다 — 이 글이 다루는 데이터 통합이 바로 그 앞단입니다.