기존 BI 툴과 다른 전제
전통적인 BI 툴은 대개 ETL(Extract-Transform-Load) 방식입니다. 원본 데이터를 가져오면서 바로 정제·가공한 뒤, 이미 다듬어진 결과만 저장합니다. 저장 공간이 비싸고 제한적이었던 시절의 관행입니다.
Foundry는 ELT(Extract-Load-Transform)에 가깝습니다. 원본 데이터를 최대한 있는 그대로 먼저 가져와 저장하고, 정제·가공은 그다음 단계(파이프라인)에서 별도로 수행합니다. 클라우드 기반 분산 스토리지 덕분에 원본 데이터를 보관하는 데 드는 비용 부담이 크게 줄었기 때문에 가능한 접근입니다.
이 순서가 주는 실질적인 이득은, 나중에 “그때 그 원본 데이터로 다시 확인해보고 싶다”는 상황이 생겨도 원본이 그대로 남아있다는 점입니다. 정제 로직에 문제가 있었다는 게 나중에 발견돼도, 원본부터 다시 처리하면 됩니다.
온톨로지에 올라가기 전, 데이터는 어디에 있는가
Ontology에 매핑되기 전까지 데이터는 Foundry의 Dataset이라는 형태로 존재합니다. 다른 시스템에 비유하면, ETL 파이프라인에서 원본을 그대로 받아두는 Staging 테이블·Raw 테이블과 같은 역할을 하는 대상이 Foundry에서는 Dataset입니다. “정제되지 않은 원본 데이터를 담아두는 그릇”이라고 생각하면 가장 가깝습니다.
다만 구현 방식은 일반적인 테이블과 다릅니다. Dataset은 근본적으로 파일들의 집합을 감싸는 래퍼(wrapper)입니다. 구조화된(tabular) 데이터라면 내부적으로 Parquet 같은 오픈소스 파일 포맷으로 저장되고, 그 컬럼 구조는 별도의 스키마로 함께 관리됩니다. 겉에서 보면 컬럼·행·스키마가 있는 익숙한 “테이블”처럼 다룰 수 있지만, 실제로는 파일 시스템 위에 분산 저장된 파일 덩어리라는 점이 핵심입니다.
Dataset은 다음 세 가지 개념으로 관리됩니다.
- Branch(브랜치): Git의 브랜치와 거의 같은 개념입니다. 브랜치는 그 브랜치에서 가장 최근 트랜잭션을 가리키는 포인터일 뿐이고, 보통은
master브랜치 하나에서 시작해 필요시 자식 브랜치를 만듭니다. (단, Git과 달리 브랜치 간 merge는 지원하지 않습니다.) - Transaction(트랜잭션): Git의 커밋과 비슷합니다. Dataset에 변경이 생길 때마다 하나의 트랜잭션이 쌓이고, 이 트랜잭션들의 연속이 곧 Dataset의 버전 기록이 됩니다.
- 트랜잭션 유형: SNAPSHOT(전체 새로 씀), APPEND(추가만), UPDATE, DELETE 등이 있습니다. DELETE는 실제로는 파일을 그 자리에서 지우는 게 아니라 “이후 조회 시 안 보이게” 처리하는 방식이고, 실제 스토리지에서 제거하려면 별도의 Retention 정책이 필요합니다.
이 구조 덕분에 Dataset은 일반 테이블에는 없는 것들을 기본으로 갖습니다 — 권한 관리, 스키마 관리, 버전 관리(브랜치별로 과거 시점 데이터 조회 가능)가 Dataset 자체에 통합되어 있습니다. “테이블처럼 보이지만 Git처럼 버전 관리되는 파일 묶음”이라고 이해하면 이후 파이프라인 설계에서 헷갈릴 일이 줄어듭니다.
파일 기반이라는 점은 장점과 동시에 제약도 만듭니다. RDB처럼 행 단위로 즉석 INSERT·UPDATE·DELETE를 하는 구조가 아니라, 트랜잭션 단위로 “이번엔 통째로 새로 썼다”(SNAPSHOT) 또는 “이번엔 추가된 것만 썼다”(APPEND/incremental)는 식으로 데이터가 쌓입니다.
온톨로지의 실제 저장소 — OSv2
정제된 Dataset이 Ontology의 Object Type에 매핑되면, 그 데이터는 Palantir 고유의 저장 방식인 OSv2(Object Storage V2)로 관리됩니다. 예전에는 OSv1(내부 명칭 Phonograph)이 쓰였지만, OSv1은 2026년 6월 30일부로 사용이 중단되었고 이후로는 OSv2가 온톨로지의 표준 저장소입니다.
OSv2는 온톨로지 데이터를 빠른 인덱싱과 검색(Search Around), 사용자 편집(writeback)에 최적화된 형태로 저장합니다. OSv1 시절에는 사용자 편집을 가능하게 하려면 별도의 writeback dataset을 따로 만들어야 했지만, OSv2에서는 이 과정 없이 Actions를 통한 편집이 바로 반영됩니다.
정리하면
| 단계 | 저장 형태 | 특징 |
|---|---|---|
| 원본 수집 | Dataset (파일 기반, Parquet 등) | 타 시스템의 Staging/Raw 테이블과 유사한 역할. ELT 방식, Branch·Transaction으로 버전 관리, SNAPSHOT/APPEND 트랜잭션만 가능 |
| 온톨로지 매핑 후 | OSv2 | 빠른 인덱싱·검색, Actions로 즉시 편집 반영 |
Foundry를 SQL 기반 RDB처럼 다루려고 하면 이 지점에서 계속 어긋납니다. “행 하나를 즉시 고친다”는 개념이 아니라 “전체를 다시 쓰거나, 변경분만 얹는다”는 개념으로 접근해야 파이프라인 설계가 자연스러워집니다.