엑셀처럼 셀 하나만 고치려다가 막힌 이유 — Foundry는 SQL UPDATE가 아니다

“행 하나만 고치면 되는데 왜 이렇게 복잡하죠?”

전통적인 DB를 다뤄본 사람이 Foundry를 처음 쓰면 자주 부딪히는 벽입니다. UPDATE table SET value=1 WHERE id=42 같은 감각으로 데이터를 고치려 하면, Foundry에서는 이 방식이 통하지 않습니다. 이건 버그가 아니라 설계 철학이 다르기 때문입니다.

ELT, 순서가 다르다

전통적인 BI 환경은 ETL(추출→변환→적재)입니다. 데이터를 변환까지 마친 뒤에 저장소에 넣습니다. Foundry는 ELT(추출→적재→변환)입니다. 원본을 먼저 그대로 적재하고, 변환은 그 이후 파이프라인 단계에서 처리합니다. 이 순서 차이가 이후 모든 구조에 영향을 줍니다.

Dataset — 온톨로지에 매핑되기 전의 저장소

Dataset은 온톨로지 매핑 이전의 원시·중간 데이터가 머무는 곳입니다. 전통적인 BI의 스테이징 테이블과 비슷한 위치입니다. 실제로는 Parquet 같은 파일들의 묶음이며, 테이블처럼 보이지만 내부적으로는 파일 래퍼입니다. 이 사실이 “행 하나만 고치기”가 안 되는 이유의 시작입니다. 파일 묶음을 부분적으로 수정하는 것보다, 파일 단위로 다시 쓰는 쪽이 구조적으로 자연스럽습니다.

Dataset 관리 단위

Transaction에는 네 가지 유형이 있습니다.

여기서 DELETE가 “논리적” 삭제라는 점이 중요합니다. 실제 데이터를 그 순간 지우는 게 아니라, 삭제되었다는 사실을 다음 Transaction에 기록하는 방식입니다. 이 역시 행 단위 즉시 수정이라는 전통적 DB 감각과는 다릅니다.

OSv2 — 온톨로지 매핑 이후의 저장소

Dataset이 온톨로지 매핑 이전 단계라면, OSv2(Object Storage v2)는 매핑이 끝난 뒤 실제로 온톨로지 객체가 저장되는 팔란티어 자체 저장소입니다. 인덱싱과 주변 탐색(search-around), 사용자 writeback에 최적화되어 있습니다. 참고로 OSv1은 2026년 6월 30일부로 지원이 종료되었으므로, 신규 구축이라면 OSv2를 기준으로 설계해야 합니다.

OSv2의 실무적 장점은 별도의 writeback용 데이터셋을 따로 만들 필요가 없다는 점입니다. Action을 실행하면 그 결과가 즉시 반영됩니다. Workshop에서 사용자가 상태를 변경하는 Action을 실행했을 때 화면에 바로 결과가 보이는 것도 이 구조 덕분입니다.

사고방식의 전환이 필요한 지점

행 단위로 값을 고친다는 SQL적 사고방식을 그대로 가져오면 계속 막힙니다. Foundry에서는 “전체를 다시 쓴다”(SNAPSHOT) 또는 “증분으로 추가한다”(APPEND)는 두 가지 축으로 사고를 바꿔야 합니다. 처음엔 번거롭게 느껴지지만, 이 구조 덕분에 언제든 특정 시점의 데이터 상태로 되돌아볼 수 있는 이력 관리가 가능해집니다.

정리하면

Foundry에서 데이터를 고치는 방식이 낯설게 느껴지는 이유는 저장 구조 자체가 전통적 DB와 다르기 때문입니다. Dataset은 온톨로지 매핑 전 원시 데이터, OSv2는 매핑 후 실제 객체 저장소라는 역할 구분을 먼저 이해하면, “행 하나만 고치기”가 왜 안 되고 대신 무엇을 해야 하는지가 명확해집니다.

자주 묻는 질문

Q. UPDATE Transaction이 있는데 왜 행 단위 수정이 안 되나요? UPDATE Transaction은 지원되지만, 파일 기반 구조이기 때문에 매번 값 하나를 바꾸는 용도로 쓰기보다는 배치 단위의 갱신에 적합합니다. 잦은 개별 행 수정이 필요하다면 설계를 재검토하는 게 낫습니다.

Q. OSv1을 계속 쓰고 있다면 지금 당장 마이그레이션해야 하나요? 2026년 6월 30일부로 신규 지원이 종료되었으므로, 아직 OSv1 기반이라면 가능한 빨리 OSv2로 전환 계획을 세워야 합니다.