LabHub

블로그

데이터 레이크하우스 & 모던 데이터 엔지니어링 2026 — Iceberg / Delta / Hudi / Paimon / Tabular (Databricks 인수) / Trino / Spark 4 / Flink 2 / DataFusion 심층 가이드

2026-05-16 · 48 분 읽기 · #data-engineering#data-lakehouse#apache-iceberg#delta-lake#apache-hudi#apache-paimon#tabular#databricks#snowflake#bigquery#dbt#trino#presto#spark#flink#clickhouse#duckdb#apache-arrow#apache-parquet#apache-orc#datafusion#onehouse#deep-dive

한국어English日本語

프롤로그 — "데이터 웨어하우스"라는 단어가 늙어버린 자리

2010년대 초반, "데이터를 어디에 두느냐"는 단순했다. 정형 데이터는 데이터 웨어하우스(Teradata·Oracle Exadata·Vertica), 로그·반정형 데이터는 Hadoop HDFS에 던졌다. 그 사이의 다리는 ETL 도구(Informatica·Talend)가 놓았고, 분석가는 SQL을, 데이터 엔지니어는 MapReduce·Spark를 썼다.

2026년의 풍경은 완전히 다르다.

이 글은 그 풍경을 — 테이블 포맷 3대장(Iceberg·Delta·Hudi)과 도전자 Paimon, 엔진(Spark 4·Flink 2·Trino·DuckDB), 클라우드 데이터 플랫폼(Databricks·Snowflake·BigQuery·ClickHouse), 그리고 한국·일본 회사들의 실제 구성까지 — 한 호흡으로 정리한다.

1장 · 2026년 데이터 레이크하우스 지도 — 3개의 축

먼저 그림 한 장으로 시작하자. 2026년의 데이터 레이크하우스는 3개의 직교 축으로 이해할 수 있다.

                        [ 카탈로그 / 거버넌스 ]
                  Unity Catalog · Polaris · BigLake
                   Glue · Nessie · Snowflake Horizon
                                |
                                |
   [ 처리 / 쿼리 엔진 ] --------+--------- [ 테이블 포맷 / 스토리지 ]
   Spark 4 · Flink 2 · Trino   |          Iceberg · Delta · Hudi · Paimon
   Presto · DuckDB             |          Parquet · ORC · Avro
   ClickHouse · DataFusion     |          S3 · GCS · ADLS
                                |
                                |
                       [ 변환 / 오케스트레이션 ]
                       dbt · SQLMesh · Coalesce
                       Airflow · Dagster · Prefect

이 세 축이 분리될 수 있다는 게 레이크하우스의 핵심이다. 테이블 포맷은 Iceberg를 쓰면서, 엔진은 Spark/Trino/DuckDB를 골라 쓰고, 카탈로그는 Unity를 쓴다 같은 조합이 자연스러워졌다.

전통 웨어하우스(Snowflake·BigQuery)는 이 세 축이 모두 한 회사 안에 잠겨 있었다. 레이크하우스는 그 잠금을 푼다. 그래서 Snowflake도 Polaris를 만들었고, BigQuery도 BigLake로 외부 Iceberg를 읽도록 했다. 잠금을 푼다는 것 자체가 2026년의 기본값이 되었다.

2장 · Apache Iceberg — 테이블 포맷 전쟁의 승자

2.1 왜 "테이블 포맷"이라는 게 필요한가

Parquet 파일은 좋다. 컬럼형, 압축, 통계 푸시다운. 하지만 그것만으로는 부족하다.

테이블 포맷은 이걸 푸는 메타데이터 레이어다. Parquet 파일들 위에 "이 테이블의 현재 스냅샷은 X, 스키마는 Y, 다음 트랜잭션은 Z" 같은 정보를 JSON·Avro 파일로 들고 있다.

Iceberg·Delta·Hudi가 모두 이 문제를 푸는 서로 다른 방식이다.

2.2 Iceberg의 데이터 모델

Iceberg는 3단 계층의 메타데이터를 갖는다.

   [ Catalog ] ─ 카탈로그 (Glue·Nessie·Polaris·REST)
        |
        v
   [ Metadata file v0.json, v1.json ... ]
        |
        v
   [ Snapshot ] ─── 특정 시점의 테이블 상태
        |
        v
   [ Manifest list ]
        |
        v
   [ Manifest ]  ─ 어떤 데이터 파일이 어디에 있고 통계가 무엇인지
        |
        v
   [ Data files (Parquet/ORC/Avro) ]

핵심 아이디어:

2.3 Iceberg가 이긴 이유

2023년만 해도 "Iceberg vs Delta vs Hudi"는 정말로 경쟁이었다. 2025년 말 시점, 산업의 무게중심은 명확하게 Iceberg로 기울었다. 이유는 단 하나의 문장으로 요약된다.

Iceberg는 표준이고, Delta는 제품이다.

2024년 6월 Snowflake가 Polaris Catalog를 만들고 2025년 Apache에 기증한 것, AWS S3 Tables(2024년 12월)가 Iceberg를 일급으로 지원하는 것 — 모두 같은 흐름이다.

2.4 Iceberg를 직접 써보기 — PyIceberg

PyIceberg(Python 네이티브 Iceberg 클라이언트)로 가장 작은 예제.

from pyiceberg.catalog import load_catalog
from pyiceberg.schema import Schema
from pyiceberg.types import LongType, StringType, TimestampType, NestedField

# 1. 카탈로그 로드 (Glue·REST·SQL·Hive 다 지원)
catalog = load_catalog(
    "my_catalog",
    **{
        "type": "rest",
        "uri": "http://localhost:8181",
        "warehouse": "s3://my-bucket/warehouse",
    }
)

# 2. 스키마 정의
schema = Schema(
    NestedField(1, "event_id", LongType(), required=True),
    NestedField(2, "user_id", StringType()),
    NestedField(3, "event_time", TimestampType()),
    NestedField(4, "event_type", StringType()),
)

# 3. 테이블 생성
table = catalog.create_table(
    identifier="analytics.events",
    schema=schema,
    partition_spec=...  # day(event_time)
)

# 4. 데이터 추가 (Arrow Table로)
import pyarrow as pa
data = pa.table({
    "event_id": [1, 2, 3],
    "user_id": ["u1", "u2", "u3"],
    "event_time": [...],
    "event_type": ["click", "view", "purchase"],
})
table.append(data)

# 5. 읽기 (스캔)
result = table.scan(
    row_filter="event_type == 'purchase'",
    selected_fields=("event_id", "user_id"),
).to_pandas()

# 6. 타임 트래블
old_snapshot = table.history()[-2].snapshot_id
old_data = table.scan(snapshot_id=old_snapshot).to_pandas()

이게 다다. 분산 클러스터 없이, Python 한 줄로 Iceberg 테이블을 만들고 읽고 시점 조회까지 한다. Iceberg는 "엔진"이 아니라 "스펙"이라는 게 여기서 드러난다.

3장 · Delta Lake (Databricks) — 여전히 강한 경쟁자

3.1 Delta는 무엇이 다른가

Delta Lake는 2019년 Databricks가 오픈 소스로 공개한 테이블 포맷이다. 본질은 Iceberg와 같다: Parquet 파일들 위에 트랜잭션 로그를 얹어 ACID·타임 트래블·스키마 관리를 제공한다. 다른 점은 메타데이터 구조와 생태계다.

   [ Delta Table ]
        |
        v
   _delta_log/
       00000000000000000000.json   ← 트랜잭션 로그 (한 줄씩 JSON)
       00000000000000000001.json
       ...
       00000000000000000010.checkpoint.parquet
       _last_checkpoint
        |
        v
   data files (Parquet)

3.2 UniForm — Delta가 Iceberg를 흉내내다

2023년 Databricks가 발표한 Delta UniForm은 시장이 어디로 가는지 보여준 사건이었다.

같은 Parquet 파일을 두고, Delta 로그와 Iceberg 메타데이터를 동시에 쓴다. 외부에서 보면 "그 테이블은 Iceberg 테이블이기도 하다."

Snowflake·Trino·BigQuery에서 Iceberg로 읽고, Databricks 안에서는 Delta로 쓰는 게 가능해진다. "Delta 진영"이라는 진영이 무의미해지는 길을 Databricks가 스스로 열었다.

2024년 6월 Tabular 인수 이후 이 전략은 더 진해졌다. 2025년에는 "Delta와 Iceberg를 별도 포맷으로 다루지 말고 같은 메타데이터로 보자"는 방향이 굳어졌다.

3.3 그래도 Delta가 살아남는 이유

요약하면: "Iceberg가 표준이 된 세계에서, Delta는 Databricks의 내부 최적화 포맷으로 자리잡았다." 이게 2026년의 그림이다.

4장 · Apache Hudi (Uber) — niche한 매력

4.1 Hudi의 정체성

Hudi는 2016년 Uber가 만들고 2019년 Apache로 기증한 테이블 포맷이다. "upsert-first" 가 정체성이다.

처음부터 "데이터 레이크에 어떻게 자주 업데이트를 적용할까"를 풀었다. CDC(Change Data Capture)로 들어오는 변경을 분 단위로 반영해야 했던 Uber의 요구가 그 출발점이었다.

   Hudi 테이블의 두 가지 스토리지 타입
   
   [Copy-on-Write (CoW)]
     쓰기: 영향받은 Parquet 파일 전체를 다시 쓴다
     읽기: 빠르다 (그냥 Parquet)
     적합: 읽기가 많고 쓰기가 드문 분석
   
   [Merge-on-Read (MoR)]
     쓰기: 변경분을 별도 로그 파일(Avro)에 쌓는다
     읽기: Parquet + 로그를 머지 (실시간 뷰)
     적합: 빈번한 업데이트·삭제 (CDC)

4.2 Hudi의 강점 — 인덱싱과 증분 쿼리

Iceberg·Delta가 못 따라가는 두 가지가 있다.

이 두 가지는 Iceberg가 v3 명세에서 따라잡으려고 하는 영역이다. Iceberg v3는 row-level deletes·equality deletes·merge-on-read를 강화하고 있고, 2026년에 따라잡을 가능성이 높다. 그래서 Hudi는 "niche한 강자"의 자리를 지키는 중이다.

4.3 Onehouse — Hudi의 상용 길

Hudi 공동 창시자 Vinoth Chandar가 2021년 만든 회사. "Universal Data Lakehouse" 라는 캐치프레이즈로 Hudi·Iceberg·Delta를 모두 다루는 매니지드 서비스를 판다. Hudi 회사가 Hudi만 팔지 않는다는 점이 흥미롭다.

2024-25년 Onehouse가 푼 두 도구가 의미가 컸다.

5장 · Apache Paimon (Flink team) — 새로운 도전자

5.1 왜 또 새로운 테이블 포맷인가

Iceberg·Delta·Hudi 모두 출발이 "배치 분석"이다. 스트리밍은 그 위에 얹어 쓰는 식이었다.

Paimon은 출발이 "스트리밍"이다. Apache Flink 팀에서 2022년에 시작해 2024년 Apache Top Level Project로 졸업했다. 핵심 차이는 LSM 트리(Log-Structured Merge Tree)다.

   Paimon = "LSM 트리 위에 만든 테이블 포맷"
   
   - LevelDB·RocksDB가 쓰는 그 구조
   - 메모리 → L0 → L1 → L2 ... 점진적 머지
   - 빠른 쓰기 + 효율적인 읽기 + 자연스러운 컴팩션
   - Flink의 체크포인트와 자연스럽게 결합

5.2 Paimon이 푸는 문제

2025년 시점, Paimon은 중국 알리바바·바이트댄스 안에서 가장 많이 쓰이고 서구권으로 확산 중이다. Iceberg가 배치의 표준이라면, Paimon은 "스트리밍 레이크하우스"의 표준 자리를 노린다.

5.3 Iceberg와 Paimon은 경쟁인가, 보완인가

지금까지의 흐름을 보면 보완에 가깝다.

2026년에는 두 포맷을 같은 데이터 플랫폼 안에 함께 두는 구성이 표준이 될 것이다. Flink가 Paimon에 쓰고, 큐브·집계가 만들어지면 Iceberg로 굳히는 식.

6장 · Tabular 인수 (Databricks 2024.6, $1B+) — 의미

6.1 무엇이 있었나

2024년 6월, Databricks가 Tabular를 $1B 이상에 인수했다. Iceberg 공동 창시자 Ryan Blue·Daniel Weeks·Jason Reid가 만든 회사로, Iceberg 기반 매니지드 데이터 플랫폼을 팔고 있었다.

같은 시기 Snowflake도 Tabular를 사려고 했다는 소문이 강하게 돌았다. 결국 Databricks가 가져갔고, 인수가는 Tabular의 ARR 대비 매우 높았다. Databricks가 본 것은 매출이 아니라 사람과 표준이었다.

6.2 무엇이 바뀌었나

이 사건은 "테이블 포맷의 전쟁이 끝났다"는 신호였다. Iceberg가 표준이 되고, 카탈로그·엔진·서비스 층에서 진짜 경쟁이 시작된다.

6.3 Ryan Blue가 가져간 메시지

인수 후 첫 컨퍼런스(Iceberg Summit 2024)에서 Ryan Blue가 한 말이 인상적이다.

"테이블 포맷은 표준이어야 한다. 표준이 정해지고 나면, 진짜 경쟁은 그 위에서 시작된다."

이 말 그대로다. 2026년의 데이터 엔지니어링은 "어느 포맷을 고르느냐"가 아니라, "Iceberg 위에서 어떤 엔진·카탈로그·UX를 고르느냐" 의 문제가 되었다.

7장 · Onehouse — Hudi 진영의 상용화

Onehouse는 다윗과 골리앗의 싸움에서 다윗 쪽이다. Databricks·Snowflake가 수십억 달러를 굴리는 데 비해, Onehouse는 시리즈 B를 마친 작은 회사다. 하지만 자기 자리를 분명히 가졌다.

Onehouse의 가설은 단순하다.

"한 회사에 한 포맷이라는 시대는 끝났다. 회사 안에 Iceberg·Delta·Hudi가 동시에 존재할 것이다. 그 사이를 매끄럽게 잇는 자가 이긴다."

2026년 시점 이 가설은 점점 맞아 들어가고 있다. 실제 엔터프라이즈에서 "Databricks는 Delta, Snowflake는 Iceberg, 자체 분석은 Hudi"가 한 회사 안에 공존하는 풍경이 흔해졌다.

8장 · dbt — 변환의 표준

8.1 dbt가 무엇을 바꿨는가

dbt(data build tool)는 2016년 Fishtown Analytics(현 dbt Labs)가 시작했다. 핵심 아이디어는 단순하다.

"SQL로 모델을 짜라. 의존성은 우리가 푼다. 테스트도 SQL이다. 문서도 SQL에서 뽑는다."

이전에는 분석가가 SQL을 직접 짜서 BI 도구에 박았다. 변환 로직이 어디에 있는지, 의존성이 무엇인지, 테스트는 어떻게 하는지 — 다 흩어져 있었다.

dbt가 정리한 것:

   models/
     staging/
       stg_orders.sql      ← 원본 → 정제
       stg_customers.sql
     marts/
       core/
         dim_customers.sql
         fct_orders.sql    ← stg_orders, dim_customers 참조
   
   tests/
     not_null_dim_customers_id.sql
   
   dbt_project.yml         ← 프로젝트 설정

8.2 분석 엔지니어링이라는 직군

dbt가 만든 가장 큰 변화는 "Analytics Engineer" 라는 직군의 등장이다. SQL을 도구 삼아 변환·모델링·테스트·문서까지 책임지는 사람. 데이터 엔지니어와 분석가의 중간이다.

2026년에는 이 직군이 데이터 팀의 다수가 되었다. Python·Spark를 다루는 데이터 엔지니어가 데이터 인입과 인프라를 보고, 분석 엔지니어가 dbt로 모델을 짜고, 데이터 분석가가 그 위에서 BI를 한다.

8.3 dbt의 경쟁자들

dbt가 표준이 된 이후 도전자가 나타났다.

2026년 시점, dbt는 압도적이지만 SQLMesh가 빠르게 따라잡고 있다. 두 도구 모두 핵심 가치는 같다: SQL은 코드다. 그러니까 버저닝·테스트·CI/CD가 있어야 한다.

9장 · Trino (구 PrestoSQL) / Presto — 분산 OLAP 쿼리 엔진

9.1 Presto의 분기점

Presto는 2012년 Facebook이 만든 분산 SQL 엔진이다. 2019년 핵심 개발자 그룹이 회사를 떠나 Trino(처음 이름 PrestoSQL)로 분기했다. Presto Foundation(Linux Foundation)에 남은 쪽이 PrestoDB로, 사실상 Meta 내부 중심.

2026년 시점:

분기한 지 6년이 넘은 지금, Trino가 사실상 Presto의 정통 후계자가 되었다.

9.2 Trino의 자리

Trino는 "연결(federated) 쿼리 엔진"이다. 자기 자신은 데이터를 저장하지 않는다. S3의 Iceberg 테이블, MySQL의 운영 DB, Kafka의 토픽을 같은 SQL 한 줄로 JOIN한다.

-- Iceberg 테이블 ⋈ MySQL 테이블 ⋈ PostgreSQL 테이블
SELECT
    i.user_id,
    m.user_name,
    p.last_login,
    SUM(i.amount) AS total_spent
FROM iceberg.analytics.purchases i
JOIN mysql.app.users m ON i.user_id = m.id
JOIN postgres.crm.profiles p ON i.user_id = p.user_id
WHERE i.event_date >= DATE '2026-05-01'
GROUP BY 1, 2, 3

이게 한 쿼리에서 가능한 게 Trino의 정체성이다. 데이터 레이크하우스의 OLAP 표준으로 자리잡았다.

9.3 누가 Trino를 쓰는가

9.4 Trino vs DuckDB — 단일 노드의 도전

흥미로운 건 DuckDB가 단일 노드에서 Trino보다 빠른 경우가 많다는 것이다. 데이터가 작거나 중간 크기일 때(수십~수백 GB), DuckDB로 충분하고 종종 더 빠르다. Trino는 "분산이 정말로 필요한 큰 쿼리"의 자리로 좁아지고 있다.

10장 · Spark 4 (2024.8) + Apache Flink 2 — 처리 엔진

10.1 Spark 4의 변화

Apache Spark 4.0이 2024년 8월에 정식 출시됐다. 핵심 변화 셋.

Spark는 더 이상 "Hadoop의 다음"이 아니다. "Iceberg·Delta·Hudi 어떤 포맷에든 쓰고 읽는 ETL·배치 엔진의 표준" 이다.

Apache Flink 2.0이 2025년 초 출시됐다. 핵심은 상태 관리의 클라우드 네이티브화다.

Flink 2 + Paimon이 2026년의 "스트리밍 레이크하우스" 표준이 되어가는 중이다.

10.3 Spark vs Flink — 무엇을 언제 쓰는가

축SparkFlink
배치표준가능
스트리밍Structured Streaming (마이크로배치)진짜 스트리밍 (이벤트 단위)
지연초 단위밀리초 단위
상태 관리약함일급
ML / DataFrame매우 강함약함
사람 풀매우 큼중간

ETL·배치·ML은 Spark, 진짜 스트리밍은 Flink. 2026년에도 이 구도는 유지된다. 다만 Spark의 Structured Streaming이 충분히 좋아져서, "초 단위 지연이면 Spark로 충분"한 경우가 늘어났다.

11장 · Databricks · Snowflake · BigQuery · ClickHouse — 클라우드 데이터 플랫폼

11.1 Databricks — 레이크하우스의 원조

2026년 Databricks의 메시지: "데이터 + AI = 한 플랫폼." 단순한 ETL·BI가 아니라 모델 학습까지 한 곳에서.

11.2 Snowflake — 웨어하우스에서 레이크하우스로

전통 웨어하우스로 시작했지만, 2024-25년에 빠르게 레이크하우스 방향으로 갔다.

Snowflake의 메시지: "Iceberg가 표준이 되어도 우리는 그 표준의 일급 시민이다."

11.3 BigQuery — Google의 답

BigQuery는 GCP 안에 있는 한 가장 매끄러운 선택이다. BigLake로 Iceberg를 받아들인 게 2025년의 큰 변화.

11.4 ClickHouse Cloud — 실시간 OLAP의 강자

ClickHouse는 정통 OLTP/HTAP이 아니라 실시간 분석에 특화된 컬럼형 DB다. 2022년 Yandex에서 분리되어 ClickHouse Inc.로 시작했고, 2024-25년 Cloud가 크게 성장했다.

ClickHouse는 "데이터 레이크하우스의 일부"라기보다 "실시간 OLAP을 위한 별도 엔진" 으로 자리잡았다. Iceberg와는 외부 테이블로 연결한다.

12장 · AWS Athena + Glue — 클라우드 매니지드

12.1 Athena — S3 위의 서버리스 SQL

AWS Athena는 Presto/Trino 기반의 서버리스 쿼리 엔진이다. S3에 있는 Parquet·ORC·Iceberg·Delta 파일을 SQL로 바로 쿼리한다. 클러스터를 띄우거나 관리하지 않는다.

-- Iceberg 테이블 쿼리 (Athena v3 엔진)
SELECT
    event_date,
    COUNT(*) AS events,
    COUNT(DISTINCT user_id) AS dau
FROM iceberg_catalog.analytics.events
WHERE event_date BETWEEN DATE '2026-05-01' AND DATE '2026-05-15'
GROUP BY 1
ORDER BY 1

12.2 Glue — 카탈로그 + ETL

Glue Data Catalog가 Iceberg REST를 흉내내는 어댑터를 2024년에 내놓았다. AWS 안에서 "Iceberg + Athena + Glue Catalog + S3"가 가장 자연스러운 조합이 되었다.

12.3 S3 Tables (2024.12)

2024년 12월 AWS가 발표한 S3 Tables가 큰 변화였다. S3 자체가 Iceberg 테이블을 일급으로 관리한다. 자동 컴팩션·스냅샷 만료·메타데이터 관리까지 S3가 직접.

S3 (객체 저장소)
   ↓
S3 Tables (Iceberg 일급)  ← 컴팩션·만료·통계 자동 관리
   ↓
Athena · EMR · Glue · Redshift · Trino · Spark

이 한 발이 의미가 크다. 클라우드 사업자가 Iceberg를 직접 다루기 시작했다. Iceberg가 표준이라는 마지막 못이 박혔다.

13장 · DuckDB — "Analytics용 SQLite"

13.1 DuckDB의 정체

DuckDB는 2019년 네덜란드 CWI에서 시작된 인-프로세스 OLAP 데이터베이스다. 핵심 슬로건은 "SQLite for analytics." 서버를 띄우지 않고, 라이브러리로 임포트해서 그 프로세스 안에서 SQL을 돈다.

import duckdb

# Parquet 직접 쿼리. 클러스터·서버 없음.
result = duckdb.sql("""
    SELECT
        user_id,
        COUNT(*) AS events,
        SUM(amount) AS total
    FROM 's3://my-bucket/events/*.parquet'
    WHERE event_date >= '2026-05-01'
    GROUP BY user_id
    ORDER BY total DESC
    LIMIT 100
""").df()  # → Pandas DataFrame

이게 끝이다. PostgreSQL 클라이언트도, Spark 클러스터도, Snowflake 계정도 필요 없다.

13.2 왜 DuckDB가 폭발했나

2024-25년 DuckDB의 GitHub 스타가 4배 가까이 늘었다. 이유는 단순하다.

13.3 DuckDB가 점유한 자리

Spark·Trino가 "분산이 정말로 필요한가"라는 질문을 받기 시작했다. 데이터가 1TB 이하면, DuckDB로 충분한 경우가 많다.

14장 · Apache Arrow / Parquet / ORC / DataFusion — 저수준 표준

14.1 Apache Arrow — 인-메모리 컬럼 표준

데이터를 디스크에 두는 표준이 Parquet라면, 메모리에서 다루는 표준은 Apache Arrow다.

Pandas 2.0(2023)부터 Arrow가 백엔드로 들어왔고, Polars는 처음부터 Arrow 기반. "DataFrame은 Arrow 위에 있다"가 표준이 됐다.

14.2 Parquet vs ORC — 디스크 포맷

차이는 작다. 압축률·스캔 성능에서 시나리오마다 엎치락뒤치락. 하지만 생태계 모멘텀이 Parquet에 압도적이다. 2026년에 새 프로젝트를 Parquet 아닌 다른 걸로 시작할 이유는 사실상 없다.

14.3 Apache DataFusion — Rust 쿼리 엔진

DataFusion은 Apache Arrow 프로젝트의 일부로 시작된 Rust로 짠 SQL 쿼리 엔진이다. Andy Grove가 만들었고 2021년 Apache로 들어갔다.

DataFusion의 자리는 흥미롭다. DuckDB와 직접 경쟁하는 게 아니라, 다른 시스템의 내부 엔진으로 채택되고 있다.

"Rust로 짠 DBMS 만들 때 SQL 엔진은 DataFusion에서 시작하라" 가 2026년의 디폴트가 되었다.

15장 · 한국 / 일본 — 토스, 카카오 KaaP, 메르카리, ZOZO

15.1 토스 데이터 — 단일 데이터 플랫폼

토스(Toss)는 2025년 데이터 플랫폼을 Apache Iceberg + dbt + Trino + Airflow의 조합으로 재구성했다. 인용된 카날리아 컨퍼런스 발표(SLASH 25)에서:

특히 토스가 강조한 건 "데이터 셀프서비스" 였다. 데이터 엔지니어가 인입과 인프라만 책임지고, 분석·모델링은 분석 엔지니어·분석가가 자체적으로.

15.2 카카오 KaaP (Kakao as a Platform)

카카오는 사내 데이터 플랫폼을 KaaP라는 이름으로 운영한다. 핵심은 멀티 테넌트 분석 인프라.

2025-26년 KaaP는 Iceberg 채택을 빠르게 늘리는 중이다. 기존 Hive 테이블에서 Iceberg로 마이그레이션하는 게 큰 과제.

15.3 메르카리(メルカリ) — 일본의 데이터 플랫폼

메르카리(Mercari)는 일본의 대표 C2C 마켓플레이스. 데이터 플랫폼은 BigQuery + dbt + Looker 조합이 중심.

2024년 메르카리 엔지니어링 블로그가 "BigLake로 외부 Iceberg 받아들이기"를 다룬 게 인상적이다. 일본 회사 중에서 가장 빠르게 레이크하우스 방향으로 움직였다.

15.4 ZOZO — 일본 패션 커머스

ZOZOTOWN의 모회사. 데이터 플랫폼은 BigQuery + Dataform 조합이 메인.

ZOZO는 데이터 메시를 일찍 시도한 일본 회사 중 하나로 알려져 있다. 2024년 ZOZO 테크 블로그에서 "도메인별 책임 분산"을 강조한 글이 자주 인용된다.

16장 · 누가 무엇을 골라야 하나 — SMB / 엔터프라이즈 / 스트리밍 / 분석

규모와 요구사항별로 정리.

16.1 SMB · 스타트업 (월 비용 $5,000 이하)

영역추천
스토리지S3 + Parquet
테이블 포맷시작은 그냥 Parquet, 커지면 Iceberg
엔진DuckDB + (선택) Athena
변환dbt-core
오케스트레이션dbt 스케줄 + GitHub Actions
BIMetabase · Lightdash

핵심: 클러스터를 띄우지 마라. DuckDB가 100GB까지 충분하다. Athena는 SQL만 던지면 된다. Snowflake·Databricks는 데이터가 정말 커지고 분석가가 5명 넘기 전까지는 비싸다.

16.2 미드사이즈 (월 5,000 5,000 ~ 50,000)

영역추천
스토리지S3 / GCS / ADLS
테이블 포맷Iceberg
엔진Trino (Starburst Galaxy) · Spark (managed)
변환dbt Cloud 또는 SQLMesh
카탈로그Glue · Polaris · Unity Catalog
BILooker · Hex · Mode

여기서부터 Iceberg가 의미를 갖는다. 데이터 엔지니어가 2-3명 있고, 분석가가 10명 이상, 비용이 데이터 인프라의 큰 비중이 되는 구간.

16.3 엔터프라이즈

영역추천
스토리지멀티 클라우드 (S3 + GCS)
테이블 포맷Iceberg (Delta UniForm 병행 가능)
엔진Databricks (전사) + Snowflake (특정 부서) + Trino (셀프서비스)
변환dbt + 분석 엔지니어 조직
카탈로그Unity Catalog 또는 Polaris (조직 표준 잡기)
거버넌스Atlan · Collibra · OpenMetadata

엔터프라이즈에서 가장 어려운 건 거버넌스다. 카탈로그가 표준이 되어야 100개 이상의 팀이 같은 데이터를 보는 게 가능하다.

16.4 스트리밍 중심

영역추천
인입Kafka
처리Flink 2
테이블 포맷Paimon (또는 Hudi)
다운스트림 분석Iceberg + Trino

스트리밍 머티리얼라이즈드 뷰는 Paimon, 거대 분석 테이블은 Iceberg. 두 포맷을 같은 플랫폼 안에서 운영.

16.5 실시간 OLAP (제품 분석·관측성)

영역추천
엔진ClickHouse Cloud
인입Kafka → ClickHouse 직접
데이터실시간 + 일별 집계

데이터 레이크하우스의 일부라기보다, 별도 엔진. 밀리초 응답이 필요한 곳.

17장 · 마무리 — 표준이 되고 나서 시작되는 것들

2010년대 후반 "데이터 레이크 vs 데이터 웨어하우스" 논쟁이 있었다. 2020년대 초반 "Iceberg vs Delta vs Hudi" 전쟁이 있었다. 2026년 시점, 둘 다 끝났다.

Tabular 인수 후 Ryan Blue가 한 말을 다시 인용한다.

"표준이 정해지고 나면, 진짜 경쟁은 그 위에서 시작된다."

이건 2026년 데이터 엔지니어링의 한 줄 요약이다. Iceberg가 표준이라는 사실은 더 이상 논의거리가 아니다. 이제 진짜 일은 그 위에서 일어난다 — 카탈로그·거버넌스·UX·AI 통합·실시간 동기화·멀티 클라우드.

우리가 지금 짓는 데이터 플랫폼은, 5년 뒤에도 같은 Iceberg 메타데이터를 들고 있을 것이다. 그게 표준이라는 단어가 의미하는 바다.

참고 / References

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다