💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며 — Hadoop은 죽었다, 그리고 Hadoop은 어디에나 있다

2026년 5월, "Hadoop은 죽었나?"라는 질문은 헤드라인으로는 매력적이지만 현장에서는 잘못된 질문이다. 정확한 답은 **"HDFS는 줄어들었고, MapReduce는 사실상 사라졌으며, Cloudera/Hortonworks 시대의 풀스택 디스트리뷰션은 끝났다. 그러나 YARN은 살아있고, Hive Metastore는 Iceberg/Delta로 옷을 갈아입었고, '저렴한 객체 스토리지 + 메타데이터 카탈로그 + 분산 처리 엔진'이라는 레이크하우스 패턴은 Hadoop이 만든 유산이다"** 이다.

이 글은 단일 도구의 자랑이 아니라, 2026년 5월 기준 데이터 엔지니어가 실제로 만지는 모든 레이어 — 스토리지, 테이블 포맷, 처리 엔진, 쿼리 엔진, 오케스트레이션, 변환, 웨어하우스, 분석 — 를 한 번에 본다. 클라우드(EMR, Dataproc, HDInsight, Synapse), 풀-매니지드(Snowflake, Databricks, BigQuery, Redshift), 그리고 한국·일본의 온프레미스 운영 사례까지 정직하게 짚는다.

데이터 엔지니어링 2026 스택 — 8개 레이어로 분해하기

먼저 큰 그림. 2026년의 표준 데이터 엔지니어링 스택은 다음 8개 레이어로 나뉜다.

1. **스토리지(storage)**: HDFS, S3, GCS, ABFS, MinIO

2. **테이블 포맷(table format)**: Iceberg, Delta Lake, Hudi

3. **카탈로그(catalog)**: Hive Metastore, Unity Catalog, Polaris, Nessie, AWS Glue

4. **배치 처리(batch)**: Spark, Trino-on-Spark, Dremio

5. **스트리밍(streaming)**: Flink, Spark Structured Streaming, Kafka Streams, Materialize

6. **쿼리/페더레이션(query)**: Trino, Presto, Dremio, StarRocks

7. **변환(transform)**: dbt, SQLMesh, Coalesce

8. **오케스트레이션(orchestration)**: Airflow 3.0, Dagster, Prefect, Mage, Kestra

여기에 분석/OLAP 레이어로 **ClickHouse, DuckDB, Pinot, Druid**가 붙고, 풀-매니지드 웨어하우스로 **Snowflake, Databricks SQL, BigQuery, Redshift**가 붙는다. 모든 레이어가 한 회사 디스트리뷰션 안에 묶여있던 Cloudera 시대는 끝났고, 지금은 **OSS 컴포넌트를 본인이 조합**하는 시대다.

Hadoop이 죽지 않은 이유 — YARN과 Hive Metastore의 끈질긴 생존

"Hadoop이 죽었다"는 주장의 출처는 보통 두 가지다. 첫째, Cloudera + Hortonworks의 2018년 합병 이후 신규 라이센스 매출 감소. 둘째, S3/GCS 같은 객체 스토리지가 HDFS를 압도하면서 "HDFS = Hadoop"이라는 등식이 무너진 것. 둘 다 사실이지만, "Hadoop 생태계"가 의미하는 범위는 훨씬 넓다.

2026년 현재 살아있는 Hadoop 컴포넌트는 다음과 같다.

- **YARN**: 자원 매니저로 여전히 온프레미스 Spark/Flink 클러스터의 기본. Kubernetes에 점진적으로 밀리고 있지만, 금융권/통신사는 YARN 비중이 크다.

- **Hive Metastore (HMS)**: Iceberg, Delta, Trino, Spark, Flink가 모두 HMS를 카탈로그로 쓴다. "Hive는 죽었지만 HMS는 살아있다"가 정확한 표현이다.

- **Hive LLAP**: Hive 4.0과 함께 ACID 테이블 + Iceberg 백엔드로 재포지셔닝.

- **Ozone**: HDFS 후속 객체 스토리지. 온프레미스 S3 호환을 노리고 있다.

- **Tez**: Hive 실행 엔진. MapReduce는 사실상 폐기됐지만 Tez는 살아있다.

반면 **MapReduce는 신규 워크로드에서 거의 사라졌다**. 모든 사람이 Spark로 옮겼고, 남은 MapReduce는 레거시 Sqoop, 일부 Oozie 배치, 그리고 마이그레이션 대기 중인 코드뿐이다.

HDFS 대 객체 스토리지 — 누가 이겼나

2026년 5월 기준, **신규 빅데이터 워크로드의 90% 이상이 객체 스토리지 위에 올라간다**. AWS S3, Azure ADLS Gen2, GCP GCS, 온프레미스라면 MinIO나 Cloudian. HDFS는 다음 세 경우에만 살아남는다.

1. **금융권 데이터 주권**: 데이터가 절대 외부 클라우드로 못 나가는 환경. 이 경우 온프레미스 HDFS 클러스터 + Spark/Trino.

2. **레거시 ETL 자산**: 수천 개의 Hive 테이블과 Oozie 잡이 HDFS 경로에 박혀있고, 마이그레이션이 다년간 프로젝트인 경우.

3. **초저지연 셔플**: 일부 그래프/조인 워크로드에서 객체 스토리지의 PUT/GET 레이턴시가 병목인 경우. 이때는 HDFS나 Alluxio 같은 캐시 레이어.

S3가 이긴 이유는 단순하다. **저장 가격이 1/3 수준이고, 운영 부담이 거의 없고, 컴퓨트와 스토리지를 분리할 수 있어서 동일 데이터를 Spark, Trino, Snowflake, Athena 같은 여러 엔진이 동시에 본다**. 이게 레이크하우스의 핵심 전제다.

레이크하우스 시대 — 데이터 웨어하우스와 데이터 레이크의 통합

"데이터 레이크 vs 데이터 웨어하우스"의 양분 구도는 2026년에는 거의 의미가 없다. 모두 **레이크하우스(lakehouse)**라는 패턴으로 수렴했다. 핵심 아이디어는 다음과 같다.

- 스토리지: 객체 스토리지(S3/GCS/ABFS) — 싸고, 무제한, 컴퓨트와 분리

- 파일 포맷: Parquet/ORC — 컬럼 기반, 압축, 프루닝

- 테이블 포맷: Iceberg/Delta/Hudi — ACID, 스키마 진화, 시간여행, 파티셔닝

- 카탈로그: Hive Metastore / Glue / Unity Catalog / Polaris / Nessie

- 컴퓨트 엔진: Spark, Trino, Flink, Dremio, StarRocks — 같은 데이터에 여러 엔진

웨어하우스(Snowflake, Redshift, BigQuery)는 자체 포맷에 잠가두었던 데이터를 점차 Iceberg로 열기 시작했다. 2026년 5월 기준 Snowflake와 Databricks 모두 **Iceberg 테이블을 1급 시민으로 지원**한다. 이 변화가 의미하는 바는 "벤더 락인 시대의 종료"다.

테이블 포맷 3강 — Iceberg vs Delta Lake vs Hudi

레이크하우스의 심장은 테이블 포맷이다. 2026년 5월 기준 3강 구도가 굳어졌다.

| --- | --- | --- | --- |

| 스키마 진화 | ✅ 강력(컬럼 ID 기반) | ✅ | ✅ |

| 파티션 진화 | ✅ | 제한적 | 제한적 |

| MERGE/UPDATE | ✅ | ✅ | ✅ (CoW/MoR) |

| 시간여행 | ✅ | ✅ | ✅ |

2026년 흐름은 **Iceberg의 점진적 표준화**다. Snowflake가 Iceberg 외부 테이블 + Polaris Catalog를 적극 밀고, Databricks도 Unity Catalog를 Iceberg와 호환되게 만들었으며, Confluent의 Tableflow는 Kafka 토픽을 곧장 Iceberg 테이블로 머티리얼라이즈한다. Delta는 Databricks 생태계 안에서는 여전히 최강이지만, "범용 OSS 표준"의 자리는 Iceberg가 가져갔다.

Hudi는 CDC(Change Data Capture)와 incremental write 패턴에서 여전히 강하지만, 신규 채택은 줄어드는 추세다.

Iceberg DDL과 실제 사용 — REST 카탈로그가 표준

Iceberg를 실제로 쓰면 다음과 같은 DDL이 나온다. Spark SQL 기준이다.

CREATE TABLE iceberg_catalog.analytics.events (

event_id BIGINT,

user_id BIGINT,

event_type STRING,

occurred_at TIMESTAMP,

payload MAP<STRING, STRING>

)

USING iceberg

PARTITIONED BY (days(occurred_at), bucket(16, user_id))

TBLPROPERTIES (

'format-version'='2',

'write.parquet.compression-codec'='zstd',

'write.delete.mode'='merge-on-read',

'write.update.mode'='merge-on-read'

);

ALTER TABLE iceberg_catalog.analytics.events

ADD COLUMN device_type STRING AFTER event_type;

MERGE INTO iceberg_catalog.analytics.events t

USING staging.events_delta s

ON t.event_id = s.event_id

WHEN MATCHED THEN UPDATE SET *

WHEN NOT MATCHED THEN INSERT *;

SELECT count(*) FROM iceberg_catalog.analytics.events

FOR SYSTEM_TIME AS OF '2026-05-01 00:00:00';

Iceberg의 강점은 **카탈로그가 분리되어 있다는 점**이다. 같은 테이블을 Spark에서 쓰고, Trino에서 읽고, Flink에서 스트리밍으로 쓰고, Snowflake에서 외부 테이블로 조회할 수 있다. REST 카탈로그 스펙이 굳어지면서 벤더 종속이 약해졌다.

Delta Lake와 Databricks 생태계의 결속

Delta Lake는 OSS이지만 사실상 Databricks의 컨트롤이 강한 포맷이다. 2026년 5월 기준 Delta Lake 4.x 라인업의 핵심은 다음과 같다.

- **Liquid Clustering**: 파티션 대신 다차원 클러스터링. ZORDER의 후계자.

- **Predictive Optimization**: 통계 기반 자동 OPTIMIZE/VACUUM.

- **Delta Sharing**: 데이터 공유 프로토콜. 동일 데이터를 다른 조직이 읽게 한다.

- **UniForm**: Delta 테이블을 Iceberg 클라이언트가 그대로 읽게 하는 호환 레이어.

Delta 머지의 전형은 다음과 같다.

MERGE INTO delta.`s3://datalake/customers` AS t

USING (SELECT * FROM staging_customers) AS s

ON t.customer_id = s.customer_id

WHEN MATCHED AND s.updated_at > t.updated_at THEN

UPDATE SET *

WHEN NOT MATCHED THEN

INSERT *

WHEN NOT MATCHED BY SOURCE AND t.is_active = true THEN

UPDATE SET is_active = false;

OPTIMIZE delta.`s3://datalake/customers`

WHERE updated_at >= current_date() - INTERVAL 7 DAYS;

VACUUM delta.`s3://datalake/customers` RETAIN 168 HOURS;

Delta가 Databricks 밖에서 약한 이유는 **운영 도구(OPTIMIZE, Z-Order, Predictive Optimization)가 Databricks 안에서만 자동화**되기 때문이다. OSS Delta로도 쓸 수 있지만, 운영 자동화 측면에서 Databricks 안의 경험과 격차가 크다.

Apache Hudi — CDC와 incremental의 챔피언

Hudi는 Uber에서 만들어진 만큼 **stream-to-batch CDC**에 최적화돼 있다. 2026년 현재 Hudi 1.0이 GA됐고, 다음 두 가지 테이블 타입이 핵심이다.

- **Copy-on-Write (CoW)**: 매 업데이트마다 파일을 재작성. 읽기 빠름, 쓰기 비쌈.

- **Merge-on-Read (MoR)**: 델타 로그에 변경분 누적, 컴팩션 시점에 머지. 쓰기 빠름, 읽기 비쌈.

Hudi는 또한 **TIMELINE**이라는 메타데이터 구조로 모든 커밋을 시간순으로 정리하고, incremental query로 "최근 1시간의 변경분만" 읽을 수 있게 한다. 이게 CDC 파이프라인에 강력하다.

2026년 채택률은 줄어드는 추세지만, AWS EMR / OneHouse / Onehouse Open Engines 같은 곳에서 여전히 활발하다.

Spark 4.0 — 여전히 데이터 엔지니어링의 중심

"Spark는 죽었나?"라는 질문도 자주 나오지만, 2026년 답은 분명히 "아니다"이다. Spark 4.0이 2025년 말 GA됐고, 데이터 엔지니어링의 중심 처리 엔진 자리를 견고히 지키고 있다. 4.0의 주요 변화는 다음과 같다.

- **Spark Connect**: 클라이언트-서버 분리. 얇은 클라이언트가 원격 Spark 클러스터에 명령. IDE/노트북/CI 통합이 쉬워졌다.

- **ANSI 모드 기본화**: SQL 표준 호환 강화.

- **Variant 타입**: 반정형(JSON) 데이터의 1급 처리.

- **String Collation**: ICU 기반 다국어 정렬.

- **Python UDF 성능**: Arrow 기반 직렬화 + Python 3.13 적극 활용.

Photon은 Databricks 전용 벡터화 엔진이고, 동등한 OSS는 **Apache Gluten** + Velox/ClickHouse 백엔드가 빠르게 따라붙고 있다. EMR Serverless, Dataproc Serverless, Synapse Spark 모두 자체 가속 엔진을 붙이는 흐름이다.

Spark Structured Streaming은 Flink 대비 micro-batch 모델이지만, 2026년 기준 **Continuous Processing 모드의 안정성이 올라와서** Flink의 영역을 일부 가져왔다.

Spark Structured Streaming 예시 — Kafka → Iceberg

Spark Structured Streaming + Iceberg 콤보가 2026년 5월 기준 가장 흔한 실시간 적재 패턴이다. 코드 예시는 다음과 같다.

from pyspark.sql import SparkSession

from pyspark.sql.functions import from_json, col, current_timestamp

from pyspark.sql.types import StructType, StringType, LongType

spark = (SparkSession.builder

.appName("kafka-to-iceberg")

.config("spark.sql.catalog.lakehouse", "org.apache.iceberg.spark.SparkCatalog")

.config("spark.sql.catalog.lakehouse.type", "rest")

.config("spark.sql.catalog.lakehouse.uri", "https://catalog.internal:8181")

.getOrCreate())

schema = StructType().add("event_id", LongType()).add("user_id", LongType()).add("event_type", StringType())

stream = (spark.readStream

.format("kafka")

.option("kafka.bootstrap.servers", "kafka:9092")

.option("subscribe", "user_events")

.option("startingOffsets", "latest")

.load()

.select(from_json(col("value").cast("string"), schema).alias("d"))

.select("d.*", current_timestamp().alias("ingested_at")))

(stream.writeStream

.format("iceberg")

.option("checkpointLocation", "s3://lakehouse/_checkpoints/user_events")

.outputMode("append")

.toTable("lakehouse.analytics.user_events"))

Iceberg 카탈로그가 REST이므로 별도 Hive Metastore 의존이 사라졌고, 체크포인트는 S3에 저장된다. 2024년만 해도 이 패턴은 흔치 않았는데, 2026년에는 거의 표준이다.

Flink — 진짜 스트리밍이 필요할 때

Flink는 진짜 이벤트-타임 스트리밍, exactly-once, 복잡한 윈도잉이 필요할 때 여전히 1순위다. 2026년 5월 기준 Flink 1.20 / 2.0이 흐름을 주도한다.

- **Flink SQL**: SQL로 스트리밍 잡을 쓰는 것이 표준이 됐다. 카탈로그 통합(Hive, Iceberg, Paimon)도 성숙.

- **Apache Paimon**: Flink 진영의 lakehouse 테이블 포맷. Iceberg와 경쟁 + 보완 관계.

- **Flink CDC**: Debezium 대안. PostgreSQL/MySQL CDC를 Flink가 직접 수행.

- **Flink on Kubernetes**: K8s Operator가 표준 배포 방식.

- **Confluent의 Flink SaaS**: Confluent Cloud에 Flink가 통합되어 Kafka + Flink 풀-매니지드 조합.

Flink가 Spark Streaming보다 강한 영역은 **저지연 + 정확한 이벤트-타임 윈도잉 + 백프레셔 처리**다. Spark Streaming은 ETL 친화적이고 배치 코드 재활용이 쉬운 대신, 100ms 미만 레이턴시는 어렵다.

Flink SQL로 같은 Kafka → Iceberg 패턴을 표현하면 다음과 같다.

CREATE TABLE kafka_events (

event_id BIGINT,

user_id BIGINT,

event_type STRING,

occurred_at TIMESTAMP_LTZ(3),

WATERMARK FOR occurred_at AS occurred_at - INTERVAL '5' SECOND

) WITH (

'connector' = 'kafka',

'topic' = 'user_events',

'properties.bootstrap.servers' = 'kafka:9092',

'format' = 'json',

'scan.startup.mode' = 'latest-offset'

);

CREATE TABLE iceberg_events (

event_id BIGINT,

user_id BIGINT,

event_type STRING,

occurred_at TIMESTAMP_LTZ(3)

) PARTITIONED BY (`occurred_at`) WITH (

'connector' = 'iceberg',

'catalog-type' = 'rest',

'uri' = 'https://catalog.internal:8181',

'warehouse' = 's3://lakehouse/'

);

INSERT INTO iceberg_events

SELECT event_id, user_id, event_type, occurred_at

FROM kafka_events;

Trino & Presto — 페더레이션 SQL의 표준

Trino(이전 PrestoSQL)는 "여러 소스에 걸친 SQL 페더레이션"이라는 한 가지에 집중해 표준이 됐다. 2026년 5월 기준 Trino 450+ 커넥터가 있고, 다음 패턴이 흔하다.

- 데이터 레이크 SQL: Iceberg/Delta/Hudi 위에 ad-hoc 쿼리

- 페더레이션: Postgres + MySQL + Iceberg + Kafka에 걸친 조인

- BI 백엔드: Tableau/Superset이 Trino를 통해 lakehouse에 붙음

Presto는 Meta가 만든 원본이고, Trino는 fork다. 2026년 현재 OSS 활성도는 Trino가 압도적이고, Meta는 자체 인프라용으로 Presto를 계속 발전시킨다. Starburst가 Trino의 상용 디스트리뷰션을 제공한다.

페더레이션 쿼리의 전형은 다음과 같다.

WITH iceberg_orders AS (

SELECT order_id, user_id, total, ordered_at

FROM iceberg.sales.orders

WHERE ordered_at >= date '2026-05-01'

pg_users AS (

SELECT id AS user_id, email, country

FROM postgres.public.users

kafka_clicks AS (

SELECT user_id, count(*) AS clicks

FROM kafka.events.clickstream

WHERE timestamp_kafka >= timestamp '2026-05-01 00:00:00'

GROUP BY user_id

)

SELECT u.country, sum(o.total) AS revenue, sum(c.clicks) AS clicks

FROM iceberg_orders o

JOIN pg_users u USING (user_id)

LEFT JOIN kafka_clicks c USING (user_id)

GROUP BY u.country

ORDER BY revenue DESC;

Trino는 같은 쿼리 안에서 Iceberg, PostgreSQL, Kafka를 한꺼번에 조인한다. 별도 ETL 없이 ad-hoc 분석이 가능하다는 점이 BI/데이터 분석가에게는 큰 가치다.

dbt 1.9 + Iceberg — 모던 ELT 스택의 결합

dbt는 SQL 기반 변환의 표준이 됐다. 2026년 5월 기준 dbt Core 1.9 / dbt Cloud가 다음 변화를 가져왔다.

- **Microbatch incremental strategy**: 시간 기반 점진적 빌드.

- **dbt Mesh**: 프로젝트 간 의존성 관리.

- **dbt Semantic Layer + MetricFlow**: 메트릭 정의 중앙화.

- **Iceberg 1급 지원**: Snowflake/Databricks/Spark/Trino 어댑터 모두 Iceberg 테이블을 머티리얼라이즈 타깃으로 인식.

전형적인 dbt 모델은 다음과 같다.

{{ config(

materialized='incremental',

incremental_strategy='microbatch',

event_time='occurred_at',

batch_size='day',

file_format='iceberg',

partition_by=['days(occurred_at)']

) }}

SELECT

event_id,

user_id,

event_type,

occurred_at,

date_trunc('day', occurred_at) AS event_date

FROM {{ source('raw', 'events') }}

{% if is_incremental() %}

WHERE occurred_at >= (SELECT max(occurred_at) FROM {{ this }})

{% endif %}

SQLMesh가 dbt의 대안으로 부상 중인데, 가상 환경(virtual environments), 차원 모델링 강화, semantic version 등으로 차별화한다. Coalesce는 UI 기반 SQL 변환 도구로 비기술 사용자 친화적이다.

오케스트레이션 — Airflow 3.0이 다시 일어섰다

오랫동안 "Airflow는 무겁고 옛스럽다"는 비판을 받았지만, 2025년 말 GA된 **Airflow 3.0**이 판을 바꿨다.

- **Task SDK**: 작업 정의가 Airflow 인프라와 완전히 분리. 원격 워커에서 실행.

- **Multi-version DAG**: 같은 DAG의 여러 버전이 공존.

- **DAG Versioning**: 코드 변경 이력을 Airflow가 직접 관리.

- **Asset-centric scheduling**: 데이터셋(asset) 기반 트리거. Dagster를 의식한 변화.

대안 오케스트레이터들의 현재 위치는 다음과 같다.

| 도구 | 강점 | 채택 패턴 |

| --- | --- | --- |

| Airflow 3.0 | 범용성, 생태계, 커넥터 | 모든 곳 |

| Dagster | Asset-centric, 타입 안전, 데이터 가시성 | 신규 데이터 플랫폼 |

| Prefect 3 | 동적 DAG, 파이썬 친화 | 데이터/ML 워크플로 |

| Mage AI | 노트북 + 파이프라인 통합 | 분석가/스타트업 |

| Kestra | YAML 기반, 멀티-언어 | 엔터프라이즈 |

| Argo Workflows | K8s 네이티브, 컨테이너 단위 | 인프라/플랫폼 팀 |

Airflow의 전형적 DAG는 이렇게 생겼다.

from airflow.sdk import dag, task

from datetime import datetime, timedelta

@dag(

schedule="@daily",

start_date=datetime(2026, 5, 1),

catchup=False,

tags=["lakehouse", "iceberg"],

)

def daily_iceberg_compaction():

@task

def list_partitions(target_date: str) -> list[str]:

return [f"event_date={target_date}"]

@task

def compact(partition: str) -> str:

subprocess.run([

"spark-submit", "/opt/jobs/compact.py",

"--table", "iceberg.analytics.events",

"--partition", partition,

], check=True)

return partition

partitions = list_partitions("{{ ds }}")

compact.expand(partition=partitions)

daily_iceberg_compaction()

Airflow 3.0의 `Task SDK` 덕분에 워커는 Airflow 의존성 없이 동작하고, 다이내믹 태스크 매핑(`expand`)으로 파티션별 컴팩션을 병렬화한다.

Dagster — 자산 중심 오케스트레이션의 대표

Dagster는 "DAG of tasks"가 아니라 "DAG of assets"이라는 철학을 가진다. 데이터셋이 1급 시민이고, 태스크는 자산을 만드는 함수다.

2026년 Dagster의 위치는 다음과 같다.

- **신규 데이터 플랫폼**에서 강세. 데이터 카탈로그, 리니지, dbt 통합이 처음부터 자연스럽다.

- **dbt와의 통합**이 가장 매끄럽다. `load_assets_from_dbt_project` 한 줄로 dbt 모델이 자산이 된다.

- **Software-defined assets** 패턴이 데이터 메시 운동과 잘 맞다.

Dagster Cloud(엔터프라이즈 SaaS)와 OSS Core가 명확히 갈라져 있어, 비즈니스 모델이 안정적이다.

Prefect는 동적 워크플로 강점이 있고, 2024년 Prefect 3.0 이후 perf/UX가 크게 개선됐다. Mage는 노트북-네이티브 + 데이터-네이티브 포지셔닝으로 분석가 친화. Kestra는 YAML DSL + Java 기반으로 엔터프라이즈 환경에 적합하다.

ClickHouse, DuckDB, Pinot, Druid — 분석 컨버전스

OLAP 레이어에서 2026년 흐름은 분명하다. **"하나의 DB가 모든 분석을 한다"**는 시대가 끝나고, 각자 잘하는 영역이 굳어졌다.

- **ClickHouse**: 대규모 컬럼나 OLAP의 정석. 로그/이벤트 분석, observability. 2026년 ClickHouse 24.x 라인업이 벡터 검색(Vector Search) + Iceberg/Delta 외부 테이블을 추가했다.

- **DuckDB**: 로컬/임베디드 OLAP. "노트북 안의 Snowflake". 1.0 GA 이후 폭발적 성장. MotherDuck가 클라우드 버전.

- **Apache Pinot**: 실시간 사용자-대면 분석. LinkedIn Feed, Uber 가격, 슈퍼셋 인터랙티브 대시보드.

- **Apache Druid**: 시계열 + 실시간 OLAP. Pinot와 유사 영역이지만 운영 도구가 더 성숙.

- **StarRocks/Doris**: MPP OLAP. 중국 진영 강세, Iceberg 호환 강화.

DuckDB가 2026년 가장 빠르게 성장한 이유는 **로컬에서 S3 Parquet/Iceberg을 직접 쿼리할 수 있고, Python/CLI/SQL 모두 지원하며, 단일 바이너리**이기 때문이다. 데이터 분석가의 노트북에 Snowflake 대신 들어가는 일이 흔해졌다.

Snowflake, Databricks, BigQuery, Redshift — 풀-매니지드 4강

풀-매니지드 데이터 웨어하우스/레이크하우스의 4강 구도는 다음과 같다.

- **Snowflake**: SQL 우선, 사용 편의성, 단순 가격모델. 2026년 들어 Iceberg 외부 테이블 + Polaris Catalog + Snowpark Container Services로 lakehouse 방향. AI/LLM 컴퓨트(Cortex)도 강화.

- **Databricks**: Spark/Delta 모회사. Unity Catalog + Photon + Mosaic AI. ML/LLM/엔지니어링 통합 가장 강함.

- **Google BigQuery**: 서버리스 + 페타바이트 스케일. BigQuery Studio가 노트북 통합. Iceberg 외부 테이블도 지원.

- **AWS Redshift**: Spectrum이 Iceberg 지원 강화. Redshift Serverless가 점차 주류.

전통적인 "Snowflake vs Databricks" 양자 대결 구도가 2026년에는 흐려졌는데, 이유는 **두 회사 모두 같은 방향으로 수렴**하기 때문이다. Snowflake는 Iceberg + 컨테이너로 lakehouse를 흡수했고, Databricks는 Databricks SQL로 웨어하우스 영역에 들어왔다.

BigQuery는 Google Cloud 기본 옵션이고, Redshift는 AWS 사용자 중 비용 최적화가 중요한 기업이 선택한다.

EMR · Dataproc · HDInsight — 클라우드 매니지드 Hadoop의 현재

3대 클라우드 모두 매니지드 Hadoop 서비스를 가지고 있다.

- **AWS EMR**: 가장 성숙. EMR on EC2, EMR Serverless, EMR on EKS 3가지 폼팩터. Spark/Hive/Presto/Trino/Flink/HBase 등 거의 모든 OSS 컴포넌트.

- **GCP Dataproc**: Spark + Hadoop 중심. Dataproc Serverless가 빠르게 성장.

- **Azure HDInsight**: 2026년 새 워크로드는 거의 없고, **Synapse + Fabric**으로 흡수되는 흐름.

- **Azure Synapse / Microsoft Fabric**: Azure 데이터 플랫폼의 주류로 자리잡음. OneLake가 사실상 Iceberg/Delta 위의 통합 스토리지.

EMR Serverless는 2026년 "Spark Job을 잠깐 돌리고 사라지는" 패턴에 적합해 채택률이 높다. Lambda 대신 EMR Serverless로 batch ETL을 돌리는 패턴이 흔해졌다.

Cloudera + Hortonworks 시대의 유산 — CDP의 현재

Hadoop의 상업적 중심이었던 Cloudera와 Hortonworks는 2018년 합병 후 **CDP(Cloudera Data Platform)** 단일 제품으로 통합됐다. 2026년 현재 CDP의 위치는 다음과 같다.

- **신규 채택은 거의 없다**. 클라우드 매니지드(EMR/Dataproc) 또는 풀-매니지드(Databricks/Snowflake)가 신규 워크로드를 가져갔다.

- **온프레미스 금융권/통신사 갱신** 위주로 매출. 데이터 주권, 컴플라이언스가 큰 환경.

- **CDP Public Cloud**: 클라우드 호환을 시도했지만 EMR/Dataproc/Databricks 대비 차별화 약함.

Apache Bigtop, Apache Ambari, Apache Ranger 같은 OSS 운영 도구는 살아남았다. 특히 Ranger는 lakehouse 시대에도 데이터 거버넌스/접근 제어 표준으로 쓰인다.

한국 빅데이터 운영 — 네이버 · 카카오 · KT · 쿠팡 · 우아한형제들

한국 빅테크는 OSS Hadoop 생태계를 깊이 운영해온 곳이다.

- **네이버**: 자체 클러스터로 페타바이트급 Hadoop/Spark 운영. 검색 로그, 광고, 클로바 LLM 학습 데이터까지. 2026년 들어 자체 K8s + Spark 플랫폼으로 점진 전환. 네이버 Search Tech 블로그에서 Iceberg 도입기 공개.

- **카카오**: KEMI(Kakao Enterprise Machine Intelligence) 데이터 플랫폼이 표준. Hadoop + Spark + Hive를 거쳐 Iceberg + Trino 조합으로 이동 중. Tech 블로그에서 다년간 변천사 공개.

- **KT**: 통신 BSS/OSS 데이터를 위한 온프레미스 Hadoop 클러스터. KT GiGA Genie 음성 데이터 분석에도 활용. CDP 라이센스 사용자.

- **쿠팡**: AWS EMR + Iceberg + Trino + Airflow 중심. 클라우드 네이티브 데이터 스택의 한국 대표 사례.

- **우아한형제들 (배민)**: Spark + Airflow + Snowflake 조합. 배달 데이터의 실시간/배치 분석에 Kafka + Flink + Spark Streaming 혼용.

- **NHN, LG CNS, 삼성SDS**: 대형 SI/플랫폼 사업자도 자체 데이터 플랫폼 운영. Hadoop 기반에서 lakehouse 전환 진행.

채용 시장에서도 "Hadoop, Spark, Hive 경험"보다 "Iceberg, dbt, Airflow, Snowflake/Databricks"가 명시된 포지션이 늘었다. 2024년만 해도 한국 데이터 엔지니어 채용 공고에 Iceberg가 드물었는데, 2026년 5월 기준 대형 IT/금융권에 보편화됐다.

일본 빅데이터 운영 — LINE · ZOZO · NTT · 라쿠텐 · 메루카리

일본 시장은 한국보다 더 보수적이고 온프레미스 비중이 크지만, 2026년 들어 변화 속도가 빨라졌다.

- **LINE Yahoo**: Hadoop 클러스터를 수년간 운영. 검색, 광고, 메시지 분석. LINE Engineering 블로그에서 Spark/Hive 운영기 다수. 2025년부터 Iceberg + Trino 도입 단계.

- **ZOZO**: Spark on Kubernetes의 일본 대표 사례. ZOZO TECH BLOG에서 EKS + Spark + Iceberg 운영기 공개. CDC, 멀티테넌트 패턴까지.

- **NTT データ**: 엔터프라이즈/금융/공공 데이터 플랫폼 SI. CDP 라이센스 사용자. 일본 빅데이터 벤치마크/백서 다수 발행.

- **楽天 (Rakuten)**: 자체 데이터 플랫폼 RIDE 운영. Hadoop + Spark + Hive 기반. AI 통합 진행.

- **メルカリ (Mercari)**: GCP BigQuery + dbt + Looker 중심. 클라우드 네이티브 일본 대표 사례.

- **CyberAgent**: 광고 데이터 플랫폼. Spark/Flink/Kafka 운영. AI Lab의 데이터 파이프라인 사례 공개.

- **DeNA, GREE, グリー**: 게임/엔터테인먼트 데이터 플랫폼. Athena, Glue, EMR 활용.

일본 시장의 특징은 **온프레미스 비중이 한국보다 높다**는 점이다. 금융, 통신, 제조업이 데이터 주권 이슈로 클라우드 마이그레이션을 신중하게 진행한다. 그러나 lakehouse 패턴 자체는 빠르게 채택되고 있다.

Kafka와 스트리밍 백본 — 데이터의 동맥

데이터 엔지니어링 스택의 한 가운데에는 **Kafka**가 있다. 2026년 5월 기준 Kafka의 위치는 다음과 같다.

- **Apache Kafka 4.0**: KRaft 모드가 표준. ZooKeeper 의존성 완전 제거.

- **Confluent Cloud**: 풀-매니지드 SaaS. Tableflow로 Kafka 토픽을 Iceberg 테이블로 머티리얼라이즈.

- **AWS MSK**: AWS 네이티브. Serverless 옵션 인기.

- **Redpanda**: C++ 재작성한 Kafka 호환 브로커. 저지연 + 단순한 운영.

- **WarpStream**: Kafka 호환 + S3 백엔드. 비용 최적화.

스트리밍 SQL 레이어는 Flink SQL과 ksqlDB로 갈라지는데, 2026년 트렌드는 **Flink가 더 표준**이라는 쪽이다. ksqlDB는 Confluent 안에서 강하지만, OSS 활성도는 Flink가 압도적이다.

CDC(Change Data Capture)는 **Debezium**이 표준이고, Flink CDC가 빠르게 따라잡는다. Airbyte와 Fivetran 같은 ELT SaaS도 CDC를 지원하지만, 대규모 트래픽에는 Debezium + Kafka가 일반적이다.

Airbyte, Fivetran, Stitch — ELT 자동화

ELT의 입수(ingestion) 부분은 SaaS 도구가 표준이 됐다.

- **Fivetran**: 가장 많은 커넥터(500+). 가격은 높지만 안정성/관리 부담 적음.

- **Airbyte**: OSS + 클라우드 양쪽 제공. 커넥터 약 350개. 셀프 호스팅 가능.

- **Stitch**: Talend 산하. 단순한 SQL DB 입수에 가성비.

- **Meltano**: Singer 기반 OSS. 코드 우선 사용자.

- **Hevo Data**: 노코드 + 변환 통합. APAC 시장 인기.

- **Estuary Flow**: 실시간 CDC + SQL. 신규 도전자.

Airbyte는 2024년 Connector Builder + Low-Code CDK로 커넥터 작성 진입장벽을 크게 낮췄고, 2026년에는 LLM 기반 자동 커넥터 생성도 시도 중이다.

dbt + Airbyte/Fivetran + Snowflake/BigQuery + Looker/Mode/Hex라는 **모던 데이터 스택(Modern Data Stack)** 조합은 2020-2022년 시기 정점을 찍었고, 2026년에는 lakehouse 트렌드와 결합되어 dbt + Iceberg + Trino/Databricks가 더 흔하다.

데이터 카탈로그와 거버넌스 — Unity, Polaris, Nessie, OpenMetadata

데이터 자산이 폭증하면서 카탈로그가 1급 인프라가 됐다.

- **Unity Catalog**: Databricks 출신, 2024년 OSS 전환. Iceberg + Delta 모두 지원하는 멀티-포맷 카탈로그로 확장.

- **Apache Polaris**: Snowflake가 만든 Iceberg REST 카탈로그. ASF로 기증.

- **Project Nessie**: Dremio 후원. Git-like 브랜칭/머지 가능한 카탈로그.

- **OpenMetadata**: 메타데이터/리니지/거버넌스 통합 OSS.

- **DataHub**: LinkedIn 출신 OSS. 자산 검색, 리니지, ownership 추적.

- **Atlan, Alation, Collibra**: 엔터프라이즈 카탈로그 SaaS.

2026년 핵심 화두는 **"Iceberg REST 카탈로그 표준"**이다. Snowflake Polaris, Databricks Unity Catalog, Nessie, AWS Glue가 모두 REST 카탈로그 스펙을 따르면, 한 카탈로그로 여러 엔진이 같은 데이터에 접근하는 그림이 완성된다. Lakehouse 시대의 멀티-엔진 약속이 비로소 실현된다.

데이터 품질과 옵저버빌리티 — Monte Carlo, Great Expectations, Soda

데이터 파이프라인의 품질을 보장하는 도구가 별도 카테고리가 됐다.

- **Monte Carlo**: 데이터 옵저버빌리티 SaaS 1세대. SLA, 데이터 다운타임 개념.

- **Great Expectations**: OSS 데이터 검증. Python 친화.

- **Soda**: YAML 기반 데이터 품질 규칙. OSS + Cloud.

- **Bigeye**: ML 기반 이상 탐지.

- **Elementary**: dbt 네이티브 옵저버빌리티 OSS.

- **Datafold**: 데이터 diff 도구. dbt PR 자동 리뷰.

dbt 안에서 `dbt test`로 NULL/유니크 검증을 하고, 그 위에 Great Expectations/Soda를 얹어 비즈니스 룰을 검증하고, Monte Carlo/Elementary로 운영 SLA를 본다 — 가 2026년의 표준 패턴이다.

데이터 메시와 데이터 컨트랙트 — 조직과 인프라의 결합

2020-2022년 사이 등장한 **데이터 메시(Data Mesh)** 개념이 2026년 들어 점차 현실화됐다. 단순 명료한 정의는 다음과 같다.

- 데이터를 **제품**으로 본다 — 도메인 팀이 데이터 제품을 소유한다.

- 데이터 제품은 **셀프-서비스 인프라** 위에 올라간다 — 데이터 플랫폼 팀이 인프라 제공.

- **연방 거버넌스(federated governance)** — 중앙 표준 + 분산 운영.

이를 실현하기 위해 **데이터 컨트랙트(Data Contract)** 라는 패턴이 부상했다. 스키마 + SLA + 의미를 명시한 계약서다. 도구로는 **dbt contracts, Open Data Product Standard, Data Contract CLI, Soda Contracts**가 있다.

데이터 메시가 어울리는 조직은 (1) 도메인 팀이 독립적이고, (2) 데이터 제품 수요가 많고, (3) 중앙 데이터팀이 병목인 큰 조직이다. 작은 조직에서는 오히려 단일 데이터팀이 더 효율적이다.

OnPrem 빅데이터 현실 — 은행, 통신, 정부, 제조

클라우드의 시대지만, 2026년에도 온프레미스 빅데이터는 여전히 큰 시장이다. 주요 환경은 다음과 같다.

1. **은행/증권**: 데이터 주권, 컴플라이언스(GDPR/PIPA), 감사 추적 요구. Hadoop + Hive + Spark + Ranger.

2. **통신사**: BSS/OSS 데이터 페타바이트급. 망내부 분석. CDP/HDInsight + 자체 OpenStack/K8s.

3. **정부/공공**: 데이터센터 격리, 망분리. 자체 lakehouse 구축. Iceberg + Spark + Trino on K8s.

4. **제조업**: 공장 OT(Operational Technology) + IT 통합. Time-series DB(InfluxDB, TimescaleDB) + Spark.

5. **헬스케어/보험**: 환자 데이터 보호. 자체 HDFS 또는 Ceph + Spark.

온프레미스 빅데이터의 최근 변화는 **Kubernetes로의 점진적 이동**이다. YARN 대신 K8s, HDFS 대신 MinIO/Ceph, Cloudera Manager 대신 ArgoCD + Spark Operator + Flink Operator. 2026년에는 "온프레미스에서도 lakehouse 아키텍처를 쓸 수 있다"가 자연스러워졌다.

Spark Operator 매니페스트는 다음과 같은 형태다.

apiVersion: sparkoperator.k8s.io/v1beta2

kind: SparkApplication

metadata:

name: nightly-iceberg-compaction

namespace: data

spec:

type: Scala

mode: cluster

image: registry.internal/spark:4.0.0

mainApplicationFile: s3a://jobs/compaction.jar

sparkVersion: "4.0.0"

driver:

cores: 2

memory: 4g

serviceAccount: spark

executor:

cores: 4

instances: 8

memory: 8g

deps:

jars:

- "https://repo1.maven.org/maven2/org/apache/iceberg/iceberg-spark-runtime-3.5_2.13/1.6.0/iceberg-spark-runtime-3.5_2.13-1.6.0.jar"

hadoopConf:

"fs.s3a.endpoint": "https://minio.internal:9000"

"fs.s3a.path.style.access": "true"

빌드와 제출은 다음과 같다.

Spark Operator 설치

helm repo add spark-operator https://kubeflow.github.io/spark-operator

helm install spark-operator spark-operator/spark-operator \

--namespace spark-operator --create-namespace \

--set sparkJobNamespaces='{data}'

Iceberg REST 카탈로그 빠른 기동

docker run -d --name iceberg-rest \

-p 8181:8181 \

-e CATALOG_WAREHOUSE=s3://lakehouse/ \

-e CATALOG_IO__IMPL=org.apache.iceberg.aws.s3.S3FileIO \

apache/iceberg-rest-fixture:latest

잡 제출

kubectl apply -f nightly-iceberg-compaction.yaml

kubectl get sparkapplications -n data

데이터 엔지니어링 채용 시장 — 2026년 5월의 풍경

데이터 엔지니어링 채용 시장의 키워드도 빠르게 바뀌었다.

- **2020년**: Hadoop, Hive, MapReduce, Sqoop, Oozie

- **2023년**: Spark, Airflow, Snowflake/BigQuery, dbt, Kafka

- **2026년**: Iceberg/Delta, Trino, Flink, dbt+SQLMesh, Airflow 3.0/Dagster, Spark 4.0, lakehouse 아키텍처

LinkedIn에서 "data engineer" 검색 시 자주 등장하는 도구 빈도(2026년 5월 자체 관측):

| 도구 | 빈도(체감) | 비고 |

| --- | --- | --- |

| Spark | 매우 높음 | 사실상 필수 |

| Airflow | 매우 높음 | 사실상 필수 |

| dbt | 매우 높음 | 신규 포지션 대부분 명시 |

| Snowflake/BigQuery/Databricks | 매우 높음 | 1-2개 경험 요구 |

| Iceberg/Delta | 높음 | 2024 대비 폭증 |

| Trino/Presto | 중간 | 특정 도메인에서 필수 |

| Flink | 중간 | 스트리밍 포지션 |

| Kafka | 매우 높음 | 사실상 필수 |

| Kubernetes | 중간-높음 | 플랫폼 포지션 |

| Hadoop/Hive | 낮음(레거시) | 유지보수 포지션 한정 |

신규 포지션에 "Hadoop 운영 경험"이 필수 요건으로 들어가는 경우는 크게 줄었다. 대신 "S3/Iceberg 위에서 Spark/Trino를 운영한 경험"이 표준이 됐다.

학습 경로 — 2026년 데이터 엔지니어 입문 추천

데이터 엔지니어를 새로 시작한다면 2026년 5월 기준 다음 순서를 추천한다.

1. **SQL을 깊이 익힌다**. PostgreSQL/MySQL 한 가지를 깊이.

2. **Python + pandas/Polars/DuckDB**로 로컬 데이터 처리. DuckDB는 lakehouse 학습에도 직결.

3. **Apache Spark**: PySpark로 시작. RDD부터 가는 게 아니라 DataFrame/SQL부터.

4. **Apache Airflow** + **dbt**: 오케스트레이션 + 변환. 모던 데이터 스택의 핵심.

5. **Apache Kafka** + Flink/Spark Streaming: 스트리밍 기초.

6. **클라우드 1개**: AWS(S3 + EMR + Athena + Glue) 또는 GCP(GCS + Dataproc + BigQuery).

7. **테이블 포맷**: Iceberg를 깊이. Delta는 Databricks 환경에서 자연스럽게 배운다.

8. **Trino**: 페더레이션 쿼리 + ad-hoc 분석.

9. **Kubernetes 기본**: Spark/Flink Operator 수준까지.

10. **데이터 모델링/Kimball**: 차원 모델링은 여전히 중요한 기본기.

책: Designing Data-Intensive Applications (Martin Kleppmann), Fundamentals of Data Engineering (Joe Reis & Matt Housley), The Data Warehouse Toolkit (Kimball).

영상/블로그: Databricks Data + AI Summit, Snowflake Summit, Airflow Summit, Iceberg/Trino Summit 키노트 + 한국 데이터엔지니어링 컨퍼런스(DEvFest, Pycon Korea Data Track).

참고자료 (References)

- Apache Hadoop — https://hadoop.apache.org/

- Apache Spark — https://spark.apache.org/

- Apache Flink — https://flink.apache.org/

- Trino — https://trino.io/

- Apache Iceberg — https://iceberg.apache.org/

- Delta Lake — https://delta.io/

- Apache Hudi — https://hudi.apache.org/

- Apache Airflow — https://airflow.apache.org/

- Dagster — https://dagster.io/

- Prefect — https://www.prefect.io/

- dbt — https://www.getdbt.com/

- SQLMesh — https://sqlmesh.com/

- Databricks — https://www.databricks.com/

- Snowflake — https://www.snowflake.com/

- Google BigQuery — https://cloud.google.com/bigquery

- AWS Redshift — https://aws.amazon.com/redshift/

- Confluent — https://www.confluent.io/

- Apache Kafka — https://kafka.apache.org/

- ClickHouse — https://clickhouse.com/

- DuckDB — https://duckdb.org/

- Apache Pinot — https://pinot.apache.org/

- Apache Druid — https://druid.apache.org/

- Apache Polaris — https://polaris.apache.org/

- Project Nessie — https://projectnessie.org/

- OpenMetadata — https://open-metadata.org/

- DataHub — https://datahubproject.io/

- Monte Carlo — https://www.montecarlodata.com/

- Great Expectations — https://greatexpectations.io/

- Airbyte — https://airbyte.com/

- Fivetran — https://www.fivetran.com/

- NAVER D2 Blog — https://d2.naver.com/

- Kakao Tech Blog — https://tech.kakao.com/

- LINE Engineering — https://engineering.linecorp.com/

- ZOZO TECH BLOG — https://techblog.zozo.com/

- Mercari Engineering — https://engineering.mercari.com/