Delta Uniform Multi Platform Serving

과거 직장에서 미국 기관 고객에게 온체인·시장 데이터를 제공하는 일을 했습니다. 실시간 지표는 API로 제공했지만, 백테스팅 등을 위해 방대한 히스토리 데이터를 필요로 하는 고객도 있었습니다. 이 데이터는 테이블 포맷 없이 Hive 파티셔닝 방식의 S3 경로에 Parquet 파일로 쌓아 두고, 고객에게 경로의 읽기 권한을 주는 방식으로 제공했습니다. SQL로 바로 조회하려는 고객을 위해서는 Query-as-a-Service 용도로 같은 데이터를 BigQuery 테이블에도 복제해 두고, 테이블 조회 권한을 주었습니다.

이 방식에는 처음부터 안고 있던 문제가 있었습니다. 파일만 쌓아 두는 구조라서, 읽는 도중에 쓰기가 일어나거나 스키마가 바뀌면 고객이 어긋난 데이터를 볼 수 있었습니다. Delta Lake나 Iceberg 같은 Open Table Format이 풀려는 바로 그 문제입니다.

고객이 늘면서는 다른 문제가 커졌습니다. AWS를 직접 쓰는 고객도 있었지만 BigQuery, Databricks, Snowflake를 쓰는 고객도 꽤 있었고, 데이터 자산의 규모가 크다 보니 플랫폼이 늘 때마다 복제본을 하나씩 더 둘 수는 없었습니다. 그래서, Open Table Format으로 옮기면서 같은 사본을 여러 플랫폼에서 읽을 수 있게 하는 방법이 필요했습니다. 데이터를 소비하는 쪽이 회사 내부가 아닌 외부 고객이다 보니, 테이블 포맷을 고르는 일이 곧 고객 플랫폼과의 호환성을 고르는 일이기도 했습니다.

이 글에서는 S3 Parquet과 BigQuery로 이중 운영하던 구조를 Delta Lake 한 벌로 합치고, Delta Sharing과 UniForm으로 네 가지 플랫폼의 고객에게 제공한 과정을 살펴보겠습니다. 각 플랫폼 기능의 동작은 2026년 10월 기준 공식 문서를 함께 참고했습니다. 운영하던 시기와 세부 동작이 다를 수 있다는 점을 미리 밝혀 둡니다.

기존 구조와 문제

파일 직접 제공의 한계

파일을 그대로 넘기는 방식에는 세 가지 문제가 있었습니다.

• schema evolution: 스키마를 기록해 두는 곳이 없어서, 읽는 쪽이 파일마다 스키마를 추론해야 했습니다. 컬럼을 추가하면 예전 파일과 새 파일의 스키마가 달라지고, 엔진마다 이를 합치는 방식이 달라 고객 쪽에서 컬럼이 보이지 않을 수 있었습니다.
• 트랜잭션 부재: 고객이 파일을 읽는 도중 같은 경로에 쓰기가 일어나면, 일부만 바뀐 상태를 읽을 수 있었습니다.
• 이중 보관: S3와 BigQuery에 같은 데이터가 두 벌 있었습니다.

앞의 두 문제는 테이블 포맷을 도입하면 풀립니다. Iceberg나 Delta Lake 같은 테이블 포맷은 스키마와 파일 목록을 메타데이터로 관리하고, 커밋 단위로 원자적인 쓰기를 보장하기 때문입니다. 하지만, 당시 테이블 포맷이나 데이터 처리 엔진을 선택하는 데는 다음과 같은 다른 문제가 있었습니다.

기관 고객 플랫폼의 다양성

기관, 특히 금융권 기관 고객들은 Databricks, BigQuery, Snowflake와 같은 SaaS 형태의 클라우드 데이터 플랫폼을 쓰는 경우가 많았습니다. 그래서, 테이블 포맷을 고른다는 것은 기술적인 점만 고려하는 것이 아닌, 고객의 읽기 편의성도 생각해야 했습니다.

모든 고객이 각자 플랫폼에서 편하게 가져가면서, 데이터의 중복 저장을 최대한 줄이는 것이 필요한 상황이었습니다.

대안 검토

Iceberg

업계에서 오픈소스이면서 엔진 중립적인 테이블 포맷의 주류는 Iceberg였습니다. 다행인 것은 위 SaaS 플랫폼들이 자체적으로 최적화된 managed storage(native table)를 넘어 오픈 테이블 포맷을 지원하는 추세였다는 점입니다. Snowflake와 BigQuery, Databricks의 Spark Engine 모두 Iceberg 외부 테이블에 대한 읽기를 지원하므로, 처음에는 Glue 카탈로그에 Iceberg 테이블을 두고 EMR Spark로 쓰는 구성을 유력하게 봤습니다.

그런데 검토할수록 걸리는 점이 있었습니다. 첫째, 원본을 Iceberg로 두면 Databricks를 쓰는 고객에게 Delta 테이블로 제공할 수 없었습니다. Iceberg 테이블은 Spark로 쓰고 읽을 수 있지만, Databricks 고객이 자기 워크스페이스에서 Delta 테이블로 받아 가는 편의는 원본이 Delta일 때만 줄 수 있었습니다. 반면, Delta Lake로 쓴 테이블은 UniForm으로 Iceberg 메타데이터를 함께 만들 수 있어서, Iceberg 클라이언트에서도 읽을 수 있었습니다. 당시에는 그 반대 방향, 곧 Iceberg 테이블을 Delta로도 읽히게 하는 방법이 없었습니다.¹ 둘째, 적은 데이터 엔지니어로 EMR Spark를 운영하는 비용이나 학습하는 비용이 Databricks에 비해 훨씬 높다는 점이었습니다. 분석가가 많은 회사 특성상, Databricks Notebook의 압도적인 사용성은 매력적이었고 job compute mode, warm-up 등을 잘 사용하면 EMR보다 비싸지도 않았기 때문입니다.

Delta Lake와 UniForm

그래서 결론적으로는, Databricks 플랫폼을 사용하는 것으로 결정을 했습니다. Databricks의 Delta UniForm은 Delta 테이블을 쓸 때 Iceberg 메타데이터를 함께 만들어 줍니다. 용량의 대부분을 차지하는 데이터 파일(Parquet)은 한 벌이지만, Delta로도 읽히고 Iceberg로도 읽히는 것이 가능합니다.

고객은 읽기만 하고 쓰기는 내부 파이프라인에서만 일어나므로, Iceberg 쓰기를 포기하는 비용은 작았습니다. 또한, Databricks 고객에게는 플랫폼 내부에서 Delta Sharing을 통해 데이터를 쉽게 제공하는 것이 가능했습니다.

구조

실시간 데이터는 앞단의 Database에 실시간으로 적재되고, 이를 분석 목적으로 활용하기 위해 CDC로 데이터를 적재합니다. 그리고, 각각의 도메인에 맞게 정의된 Spark Job들이 Unity Catalog에 등록된 Delta 테이블에 데이터를 적재합니다(INSERT + UPSERT). 블록체인 데이터 특성상 UPSERT는 sliding window처럼 최근 n개 구간의 데이터만 고쳤고, 테이블이 클러스터링되어 있어서 테이블 전체를 다시 쓰는 일은 없었습니다.

• Delta Sharing: Databricks를 쓰는 고객에게 Delta 테이블을 그대로 공유합니다. 권한은 Databricks의 거버넌스 기능으로 관리했습니다.
• UniForm + Iceberg REST Catalog: AWS를 직접 쓰거나 Snowflake를 쓰는 고객은 Unity Catalog가 제공하는 Iceberg REST Catalog를 이용해 플랫폼에서 Iceberg 테이블을 읽습니다. BigQuery를 쓰는 고객은 BigQuery Omni로 Iceberg 테이블을 읽습니다.

UniForm 설정

UniForm은 Delta 테이블의 TBLPROPERTIES로 켤 수 있습니다. 테이블은 Unity Catalog에 등록되어 있어야 하고, Databricks Runtime 14.3 LTS 이상이어야 합니다.

CREATE TABLE market.history.exchange_flows (
  asset STRING,
  exchange STRING,
  ts TIMESTAMP,
  value DOUBLE
)
TBLPROPERTIES (
  'delta.columnMapping.mode' = 'id',
  'delta.enableIcebergCompatV2' = 'true',
  'delta.universalFormat.enabledFormats' = 'iceberg'
);

UniForm은 column mapping이 켜진 테이블에서만 동작합니다. 새 테이블은 만들 때 UniForm을 켜면 column mapping도 함께 켜지고, Databricks는 호환성을 위해 위 예시처럼 id 모드를 권장합니다. 이미 있는 테이블에 켤 때는 Databricks Runtime 15.4 LTS 이상에서 column mapping을 name 모드로 함께 설정합니다 (Databricks, 2026).

ALTER TABLE market.history.exchange_flows SET TBLPROPERTIES (
  'delta.columnMapping.mode' = 'name',
  'delta.enableIcebergCompatV2' = 'true',
  'delta.universalFormat.enabledFormats' = 'iceberg'
);

받아들인 제약

읽기 전용 Iceberg

UniForm을 켠 Delta 테이블은 Iceberg 클라이언트에서 읽기만 할 수 있습니다. 고객이 데이터를 쓸 일은 없었기 때문에 문제가 되지 않았습니다.

신선도 지연

Delta Sharing 고객은 커밋이 끝나면 바로 새 데이터를 관찰할 수 있습니다. 하지만, Iceberg로 읽는 고객이 새 데이터를 보기까지는 지연이 두 번 생깁니다.

첫 번째로 지연이 발생하는 지점은 UniForm 변환입니다. Iceberg 메타데이터는 Delta 커밋을 마친 compute가 커밋 뒤에 비동기로 생성합니다. 한 compute에서 변환 작업이 한 번에 하나만 돌기 때문에, 메타데이터 변환 중에 들어온 커밋은 다음 변환에서야 묶여 반영됩니다. 따라서, Delta 버전과 Iceberg 스냅샷이 하나씩 대응한다는 보장도 없습니다 (Databricks, 2026).

두 번째는 소비처에서의 카탈로그 갱신 방식입니다. Spark처럼 Iceberg REST Catalog에 직접 붙는 클라이언트는 테이블을 열 때 카탈로그에서 최신 메타데이터 위치를 받아 갑니다. 다만, Iceberg의 Spark catalog는 불러온 테이블을 기본 30초 동안 캐시하므로, 한 세션 안에서는 새 스냅샷이 그만큼 늦게 보일 수 있습니다 (Apache Iceberg, 2026). 반면, Snowflake와 BigQuery는 테이블 정의를 자기 쪽에 등록해 두기 때문에 메타데이터를 다시 읽어야 새 스냅샷이 보입니다. Snowflake는 테이블을 만들 때 AUTO_REFRESH를 켜 두면 카탈로그를 기본 30초 간격으로 확인합니다. 이 옵션은 기본값이 꺼져 있어서, 켜지 않은 테이블은 ALTER ICEBERG TABLE ... REFRESH로 직접 갱신해야 합니다 (Snowflake, 2026c, 2026b, 2026a). BigQuery는 BigQuery Omni에서 S3의 Iceberg 테이블을 BigLake 테이블로 등록해 읽었습니다 (Google Cloud, 2026). 이렇게 등록한 테이블은 정의가 특정 metadata.json 파일을 가리키기 때문에, 새 스냅샷이 생겨도 이 경로를 바꿔 주기 전까지는 이전 스냅샷을 읽습니다 (Google Cloud, 2026b). 그래서, 최신 metadata.json 경로를 주기적으로 찾아 BigQuery의 테이블 정의에 반영하는 작업을 따로 돌렸고, BigQuery를 통해 데이터를 조회하는 경우 이 주기만큼 데이터가 늦게 보이게 됩니다.²

데이터 레이크를 통해 제공하는 데이터를 소비하는 고객이 원한 것은 실시간성보다는 히스토리 데이터를 백필하는 것이었기 때문에 이 지연은 감내할 수 있었습니다. 변환이 밀렸을 때는 동기적으로 작동하는 MSCK REPAIR TABLE <table> SYNC METADATA로 수동 변환을 걸 수 있습니다.

Databricks 의존성

쓰기와 데이터 거버넌스가 모두 Databricks(Unity Catalog)에 묶입니다. 플랫폼의 사용성이 뛰어나다고 판단하기도 했고, EMR을 직접 운영하는 부담을 줄이는 대가로 받아들인 의존성입니다.

결과

• 수백 개의 테이블을 Delta Lake로 합쳤고, S3와 BigQuery에 이중으로 보관하던 수백 TB의 데이터를 줄일 수 있게 되었습니다.
• 쓰기 트랜잭션, 스키마 변경 등을 추상화된 테이블 포맷 인터페이스(SQL)를 통해 간편하게 Spark SQL로 수행할 수 있게 되었습니다.
• Snowflake와 BigQuery를 쓰는 고객이 자기 플랫폼에서 직접 데이터를 연결할 수 있게 되어, API 외의 데이터 판매 채널이 생겼습니다.

복기

Unity Catalog 기반의 거버넌스 관리, 데이터 중복 제거 등 만족스러운 점은 많았지만 기관 고객들이 중요하게 생각할 데이터 품질 지표인 SLA(Service Level Agreement) 세팅이나, 이를 관리하기 위한 데이터 품질 관리 플랫폼을 동시에 붙이지 못했던 점은 아쉬운 점입니다. 당시 DataHub를 구축하는 것을 계획하고 있었는데, Unity Catalog에도 품질이나 리니지 관련 기능이 꾸준히 추가가 되고 있어 앞으로는 이 기능으로도 충분하지 않을까 하는 생각이 들긴 했습니다.

참고문헌

• Apache Iceberg. (2026). Spark configuration. https://iceberg.apache.org/docs/latest/spark-configuration/
• Databricks. (n.d.). What is Apache Iceberg in Databricks? Retrieved October 22, 2026, from https://docs.databricks.com/aws/iceberg
• Databricks. (2026a). Access Databricks data using external systems. https://docs.databricks.com/aws/en/external-access/
• Databricks. (2026b). Read Delta Lake tables with Iceberg clients. https://docs.databricks.com/aws/en/delta/uniform
• Databricks. (2026c). Unity Catalog credential vending for external system access. https://docs.databricks.com/aws/en/external-access/credential-vending
• Google Cloud. (2026a). About cross-cloud data access. https://docs.cloud.google.com/lakehouse/docs/about-cross-cloud-data-access
• Google Cloud. (2026b). Create Amazon S3 BigLake tables. https://docs.cloud.google.com/bigquery/docs/omni-aws-create-external-table
• Google Cloud. (2026c). Create Apache Iceberg external tables. https://docs.cloud.google.com/bigquery/docs/iceberg-external-tables
• Microsoft. (2026). Access Azure Databricks tables from Apache Iceberg clients. https://learn.microsoft.com/en-us/azure/databricks/external-access/iceberg
• Snowflake. (2026a). ALTER ICEBERG TABLE … REFRESH. https://docs.snowflake.com/en/sql-reference/sql/alter-iceberg-table-refresh
• Snowflake. (2026b). Automatically refresh Apache Iceberg tables. https://docs.snowflake.com/en/user-guide/tables-iceberg-auto-refresh
• Snowflake. (2026c). CREATE ICEBERG TABLE (Iceberg REST catalog). https://docs.snowflake.com/en/sql-reference/sql/create-iceberg-table-rest