모던 Hadoop & 빅데이터 생태계 2026 완벽 가이드 - Hadoop 3.4 · Spark 4 · Hive 4 · Kafka 4 · Flink 2 · Iceberg · Trino 심층 분석

프롤로그 — 2026년, Hadoop은 죽지 않았다. 재배치되었다

"Hadoop은 죽었다(Hadoop is dead)"는 말은 2020년대 초반부터 매년 반복되어 왔다. 하지만 2026년 현재의 풍경은 그 슬로건보다 훨씬 미묘하다.

• HDFS·YARN·MapReduce 클러스터를 새로 짓는 사람은 거의 없다. 그건 사실이다.
• 그러나 Spark, Hive, Iceberg, Kafka, Flink — Hadoop이 낳은 도구들은 그 어느 때보다 강력하다. 다만 그것들이 도는 무대가 HDFS에서 S3/GCS/ADLS로, YARN에서 Kubernetes로 옮겨갔다.
• Cloudera Data Platform 7은 살아있고, 온프레미스 금융·공공·통신 영역에서 여전히 큰 부분을 차지한다. MapR은 HPE에 흡수돼 HPE Ezmeral이 됐다.
• 레이크하우스(Lakehouse) 아키텍처가 Hadoop이 약속했던 "데이터의 단일 저장소" 비전의 진짜 후계자다.

이 글은 그 전체 풍경을 한 번에 펼친다. Hadoop 3.4와 그 후계 컴포넌트들, Spark 4·Hive 4·Kafka 4·Flink 2의 진짜 2026년 사양, Iceberg vs Delta vs Hudi의 테이블 포맷 전쟁, Trino·Presto C++·DuckDB·ClickHouse·StarRocks·Druid·Pinot의 OLAP 풍경, 그리고 한국·일본 기업들의 실제 도입 사례까지.

한 줄 요약: "Hadoop은 인프라가 아니라 어휘가 됐다." HDFS/YARN/MR 같은 구체 컴포넌트는 빠져나가고, 분산 처리·테이블 포맷·스트림·카탈로그 같은 개념만 남아 클라우드 위에서 다시 조립된다.

1장 · 큰 그림 — Hadoop 생태계 25년의 궤적

2006년 Doug Cutting이 Hadoop을 시작했다. 2026년 기준, 그 위에서 자라난 도구들은 다음 표로 압축된다.

흔히 "Hadoop = HDFS + YARN + MapReduce"로 정의하지만, 현장 대화에서 "Hadoop 생태계"는 그것들과 연결돼 발전해온 모든 분산 데이터 도구를 묶는 어휘로 굳었다. 그래서 본 글도 그 넓은 의미를 따른다.

핵심 변화 세 가지를 꼽으면:

1. 저장소가 HDFS에서 객체 스토리지(S3/GCS/ADLS)와 Ozone으로 갈라졌다.
2. 자원 관리자가 YARN에서 Kubernetes로 빠르게 이동했다.
3. 테이블 추상화가 Hive Metastore에서 Iceberg·Delta·Hudi 같은 오픈 테이블 포맷으로 진화했다.

이 세 축이 2026년 데이터 플랫폼 설계의 거의 모든 의사결정을 지배한다.

2장 · Hadoop 3.4와 3.5 — 핵심은 Erasure Coding과 Ozone

Apache Hadoop의 현재 안정 라인은 3.4.x이며, 3.5는 2026년 상반기 베타로 돌고 있다. 새 클러스터를 구축하지는 않더라도 기존 온프레미스 클러스터 운영팀에게는 여전히 중요한 라인이다.

3.x 라인의 가장 큰 변화는 두 가지다.

첫째, Erasure Coding(EC). HDFS는 전통적으로 데이터를 3중 복제(3x replication)해서 신뢰성을 얻었다. 1PB 데이터를 저장하려면 실제로 3PB가 필요했다. EC는 데이터를 k개 블록과 m개 패리티로 쪼개 저장한다. RS-10-4(10 데이터 + 4 패리티)를 쓰면 약 1.4PB만 있어도 같은 신뢰도를 얻는다. 약 40% 저장 공간 절약. 단, 부호화·복호화에 CPU가 더 들고, 작은 파일에는 부적합하다. 그래서 EC는 콜드 데이터 영역에 우선 적용한다.

둘째, Apache Ozone. Hadoop의 서브 프로젝트로 시작된 객체 스토리지다. 핵심은 "S3 API를 제공하면서도 HDFS의 처리량과 강한 일관성을 유지"하는 것. NameNode 단일 병목 문제를 분산형 Ozone Manager + Storage Container Manager 구조로 풀었다. 수십억 개 파일을 다뤄야 하는 온프레미스 환경에서 HDFS의 후계자로 자리잡고 있다.

3.4 라인의 그 외 주요 변경:

• YARN의 GPU·FPGA 자원 모델 안정화. 머신러닝 워크로드를 YARN 위에서도 자연스럽게.
• HDFS Router-based Federation 성숙. 여러 NameNode를 라우터 뒤에 숨겨 수평 확장.
• Java 17/21 런타임 정식 지원.

여전히 "Hadoop을 새로 까는" 시나리오는 드물지만, 통신사·금융·공공기관·연구소의 기존 클러스터가 3.4로 이주하는 흐름은 명확하다.

3장 · "Hadoop은 죽었나" — 사실관계

이 질문에 답하려면 무엇이 "Hadoop"인지부터 좁혀야 한다.

좁은 의미의 Hadoop(HDFS + YARN + MapReduce 코어):

• 신규 채택: 사실상 정체. 신규 SaaS·스타트업은 거의 모두 클라우드 객체 스토리지를 첫날부터 쓴다.
• 기존 운영: 여전히 거대하다. CDP 7 기반의 대형 클러스터 수천 개가 전 세계에서 돌고, 한국에서도 통신·금융·공공·게임사들이 운영 중이다.
• 신규 기능 추가: 느려졌다. 코어보다는 Ozone·Erasure Coding 같은 보완 컴포넌트 위주.

넓은 의미의 Hadoop 생태계(Spark/Hive/Kafka/Flink/Iceberg/...):

• 폭발적으로 성장 중. Spark 다운로드는 매년 사상 최고. Iceberg는 표준화 중. Kafka는 KRaft로 모드 전환 완료.
• 다만 그것들이 HDFS 위에서 돌 필요는 없다. 같은 컴포넌트가 S3/GCS/ADLS 위에서, Kubernetes 위에서, EMR/Dataproc/HDInsight/Databricks/Snowflake 위에서 돈다.

기업 사정:

• Cloudera + Hortonworks 합병 후 CDP(Cloudera Data Platform) 7로 통합. 2021년 KKR·CD&R에 약 53억 달러로 인수되어 비상장 전환. 여전히 큰 매출.
• MapR은 2019년 HPE에 인수, 2024년 시점 HPE Ezmeral Data Fabric으로 재브랜딩.
• Pivotal의 Hadoop 라인은 사라졌다. 분리된 Greenplum 라인만 잔존.
• DataStax·Confluent·Databricks 같은 "포스트-Hadoop" 회사들이 시가총액 측면에서 더 큰 영향력을 갖는 상태.

결론: HDFS/YARN/MR 신규 채택은 줄었지만, "Hadoop이 만든 어휘 위에서 도는 분산 데이터 도구"는 그 어느 때보다 활발하다. 슬로건과 현실의 거리에서 본 글의 출발점이 잡힌다.

4장 · HDFS + Ozone — 객체 스토리지로 가는 다리

HDFS는 블록 기반·강한 일관성·POSIX-like 시맨틱을 가진 분산 파일 시스템이다. S3는 객체 기반·결과적 일관성(2020년 이후 강한 일관성으로 개선)·HTTP API다. 두 모델의 거리가 멀어 보이지만, 2020년대 중반의 큰 사건은 HDFS 사용자가 S3 호환 API로 자연스럽게 넘어가는 통로가 열렸다는 것이다.

대표적 도구 세 가지:

• Apache Ozone — Hadoop 서브 프로젝트. S3 호환 객체 스토리지 + HDFS-스러운 처리량.
• MinIO — S3 호환의 자체 호스팅 객체 스토리지. 쿠버네티스 네이티브.
• JuiceFS — 객체 스토리지 위에 POSIX 호환 파일 시스템을 얹는 메타데이터 레이어.

이들은 모두 같은 흐름의 산물이다. "파일 시스템 처럼 보이지만 안쪽은 객체 스토리지." Spark/Hive/Trino 같은 컴퓨트 엔진이 hdfs://, s3a://, ofs://, jfs:// 같은 다양한 URI 스킴 뒤에 추상화돼 같은 코드가 작동한다.

한국에서 이 흐름의 대표는 카카오의 Kakao i Cloud Object Storage, 네이버 클라우드의 Object Storage, NHN의 NCP Object Storage 같은 자체 객체 스토리지로의 이주다. 일본에서는 NTT 도코모, KDDI, SoftBank 모두 자체 객체 스토리지를 가지고 있다.

5장 · Apache Spark 3.5와 4.0 — ANSI 모드, Spark Connect, English SDK

Spark는 2026년에도 여전히 분산 데이터 처리의 사실상 표준이다. 안정 라인은 3.5.x, 4.0은 2024년 6월 정식 출시 후 안정화되며 2026년에는 4.x가 본격 보급되는 시기다.

4.0의 핵심 변화 다섯 가지.

1. ANSI 모드 기본 ON. 그동안 Spark의 SQL은 PostgreSQL/Snowflake에 비해 너그러운(forgiving) 동작을 했다. 오버플로우·잘못된 캐스팅이 묵묵히 NULL을 반환하는 식이었다. 4.0부터 ANSI 모드가 기본이라서, 명시적으로 끄지 않는 한 SQL 표준에 맞는 강한 검사를 한다. 마이그레이션 시 가장 흔한 깨짐 원인이다.

2. Spark Connect 안정화. 클라이언트와 서버를 gRPC로 분리하는 아키텍처. 노트북에서 거대한 Spark Driver JVM을 띄울 필요 없이, 가벼운 클라이언트가 원격 클러스터에 연결한다. Databricks Connect, JetBrains의 Big Data Tools 등이 이 위에서 돈다.

3. PySpark의 Python UDF 안정화와 Pandas API on Spark. Koalas로 시작된 작업이 Pandas API on Spark로 통합, 4.0에서는 Pandas 2.x와 호환된다.

4. Streaming 강화. Structured Streaming의 상태 저장 처리(stateful processing) API가 정리됐다. transformWithState라는 통합 API를 통해 RocksDB·인메모리 등 상태 저장소를 동일한 추상으로 다룬다.

5. English SDK 프리뷰. "자연어로 PySpark 작성"을 시도. 실험 단계지만, LLM과의 통합이 4.x 라인의 큰 방향성을 보여준다.

Databricks의 Photon 엔진은 별개 이야기다. Spark API 호환의 C++ 벡터화 실행기로, Databricks Runtime에만 들어간다. 오픈소스 Spark와는 다른 트랙.

6장 · Apache Hive 4.0 — 죽지 않은 SQL 표준, Iceberg를 끌어안다

Hive는 한때 "Hadoop의 SQL"이었다. 2010년대 후반에는 Spark SQL과 Presto에 밀려 사라지는 듯 보였지만, Hive 4.0(2023년 4월 GA)을 기점으로 명확한 부활 신호를 보내고 있다.

Hive 4.0의 핵심 변화:

• Iceberg 네이티브 통합. CREATE TABLE ... STORED BY ICEBERG 한 줄로 Iceberg 테이블이 만들어진다. 기존 Hive 테이블 ↔ Iceberg 테이블 간 마이그레이션도 SQL로 지원.
• LLAP(Live Long And Process) 안정화. 데몬 프로세스를 살려둬 쿼리 시작 지연을 크게 줄였다. 짧은 인터랙티브 쿼리에 적합.
• Tez를 기본 실행 엔진으로. 옛 MapReduce 엔진은 deprecated. Tez DAG가 표준.
• ACID 트랜잭션 v2. Merge·Update·Delete가 안정화. 컴팩션이 자동.

여전히 Hive를 쓰는 영역은 분명하다. 대규모 배치, 메타데이터가 거대한 데이터 웨어하우스, 기존 Hive UDF 자산이 큰 곳. 2026년 한국·일본·중국의 통신사·금융·게임사 다수가 Hive를 핵심 SQL 엔진으로 유지하고 있다.

7장 · Apache Kafka 4.0 — Zookeeper의 시대를 끝내다

Kafka는 2026년 빅데이터 생태계에서 가장 강력한 단일 컴포넌트 중 하나다. Kafka 4.0(2025년 3월 GA)은 그 위치를 굳혔다.

핵심 변화:

• KRaft 모드 GA, Zookeeper 제거 완료. Kafka는 그동안 Zookeeper를 의존성으로 요구했다. KRaft(Kafka Raft Metadata mode)가 2023년부터 점진 도입되다 4.0에서 Zookeeper 모드 완전 deprecated. 운영이 압도적으로 단순해졌다.
• Tiered Storage 안정화. 핫 데이터는 로컬 디스크, 콜드 데이터는 S3 같은 객체 스토리지로 자동 이동. 보존 기간이 긴 토픽의 저장 비용을 크게 낮춘다.
• Queue 시맨틱 도입. 기존 토픽은 publish-subscribe였다. KIP-932로 "Share Group" 개념이 도입돼 진정한 큐 패턴이 가능해졌다. RabbitMQ 같은 워크로드 일부가 Kafka로 옮겨갈 가능성.
• Kafka Streams와 ksqlDB도 같이 발전. Confluent가 ksqlDB의 오픈소스 라인을 정리하면서 Confluent Cloud 쪽으로 무게추를 옮겼다.

Kafka의 라이벌도 강해졌다.

• Apache Pulsar 4.0 — BookKeeper 기반의 분리 저장 아키텍처. 멀티 테넌시와 지오 복제가 강함.
• Redpanda 24.x — C++로 다시 쓴 Kafka 호환 브로커. Zookeeper도 JVM도 필요 없음. 카프카 API 100% 호환을 유지하면서 단일 바이너리.
• WarpStream — Confluent에 인수된 "S3 위의 Kafka" 변형.

2026년에 새로 큐/스트림 백본을 고른다면 "Kafka + KRaft + Tiered Storage" 또는 "Redpanda 단일 바이너리" 둘 중 하나가 가장 흔한 선택이다.

8장 · Apache Flink 2.0 — Disaggregated State와 ForSt

Flink는 한때 Spark Streaming에 밀리는 듯 보였지만, "스트림이 일급 시민(stream-first)"이라는 철학으로 진정한 저지연·정확히-한-번(exactly-once) 처리가 필요한 곳을 가져갔다. Flink 2.0(2025년 3월 GA)은 그 강점을 한 단계 더 밀어붙였다.

Flink 2.0의 핵심:

• Disaggregated State Storage. 전통적으로 Flink는 작업 매니저(Task Manager)에 붙은 로컬 디스크에 RocksDB 상태를 두었다. Kubernetes·클라우드 환경에서는 노드 교체 시 상태 복원이 비싸다. 2.0은 상태를 객체 스토리지(S3 등)에 두고, 그 위에 캐시·로컬 SSD를 두는 분리 아키텍처를 정식 도입.
• ForSt — Flink 전용으로 만들어진 RocksDB 기반 상태 저장 엔진. 객체 스토리지 친화적으로 LSM 트리를 튜닝.
• Materialized Tables. SQL로 "이 결과를 실시간으로 유지하라"고 선언하면 Flink가 백그라운드 스트림 잡으로 그것을 유지. dbt 스타일의 선언적 모델링 + Flink 스트리밍.
• Flink CDC 가 별도 서브 프로젝트로 안정화. Debezium 대안.

스트리밍 SQL의 풍경은 2026년에 이렇게 정리된다.

9장 · YARN vs Kubernetes — 자원 관리자의 세대 교체

Hadoop YARN은 2013년 등장 이후 "분산 데이터 워크로드의 자원 관리자"의 사실상 표준이었다. 2020년대에 그 자리는 Kubernetes가 빠르게 가져갔다.

K8s 위에서 빅데이터를 도는 표준 패턴:

• Spark on Kubernetes — 정식 지원. Spark Operator(Google)와 native scheduler 두 길.
• Flink Kubernetes Operator — Flink 1.15+에서 공식.
• Kafka는 Strimzi Operator로.
• YuniKorn — Apache YuniKorn은 K8s 위에서 큐·자원 공유·일정 정책 같은 YARN-스러운 기능을 제공.

여전히 YARN의 자리는 있다. CDP를 운영 중인 곳, 거대한 단일 클러스터에 빅데이터만 도는 곳, 보안·격리 요구가 매우 강한 곳. 그러나 신규 플랫폼 설계의 첫 선택지는 거의 모두 K8s다.

10장 · 테이블 포맷 전쟁 — Iceberg, Delta, Hudi

데이터 레이크에 ACID 트랜잭션·스키마 진화·시간 여행 같은 데이터 웨어하우스 기능을 더하는 게 오픈 테이블 포맷의 약속이다. 2026년 풍경은 세 후보로 압축된다.

Apache Iceberg 1.7과 1.8

• 가장 빠르게 표준화 중. AWS·Snowflake·Databricks·Google·Cloudera 모두 지원.
• REST 카탈로그 명세 표준화. 엔진 독립성을 진짜 보장.
• Iceberg-Rust — Rust 구현이 안정화. DuckDB·Polars·Trino C++ 같은 가벼운 엔진이 직접 Iceberg를 읽음.
• Apache Polaris(Snowflake 기증), Lakekeeper(Rust 기반), Apache Gravitino(데이터 카탈로그) 같은 카탈로그 선택지가 풍부.

Delta Lake 4.0

• Databricks가 만든 포맷. 2022년 Linux Foundation으로 이관.
• Delta Universal Format(UniForm) — Delta로 쓰면 Iceberg·Hudi로도 읽힐 수 있게.
• Delta Sharing — Delta 테이블을 안전하게 공유.
• 강점: Databricks 통합, 가장 성숙한 ACID 구현.

Apache Hudi 1.0

• Uber에서 시작. 업서트·CDC에 특화.
• Merge-on-Read와 Copy-on-Write 두 모드.
• 카탈로그 통합·인덱스가 강함.

선택 가이드:

• 엔진 독립성이 최우선이면 Iceberg.
• Databricks 중심이면 Delta.
• 잦은 업서트·실시간 CDC가 핵심이면 Hudi.

세 포맷은 점점 수렴 중이다. 2026년 기준 같은 데이터를 Iceberg와 Delta 둘 다로 읽을 수 있게 만드는 변환·미러 도구가 흔하다.

11장 · 카탈로그의 시대 — Polaris, Lakekeeper, Gravitino, Unity

테이블 포맷이 표준이 되자 다음 전선은 카탈로그다. 카탈로그는 "어떤 테이블이 어디에 있고 어떤 스키마이며 누가 접근 가능한가"를 관리하는 서비스다.

• Apache Polaris — Snowflake가 2024년 기증한 Iceberg REST 카탈로그 구현. 클라우드 중립을 표방.
• Lakekeeper — Rust로 작성된 Iceberg REST 카탈로그. 라이트하고 K8s 친화적.
• Apache Gravitino — Datastrato가 만든 메타-카탈로그. Iceberg·Delta·Hudi·Hive를 한 인터페이스로.
• Unity Catalog — Databricks의 카탈로그. 2024년 오픈소스로 일부 공개. 데이터·AI 자산을 통합 관리.
• Nessie — Dremio가 시작한 Git 같은 데이터 카탈로그. 브랜치·태그·머지로 데이터 버전 관리.
• AWS Glue Data Catalog, Google Dataplex — 클라우드 사업자의 카탈로그.

선택 시 핵심 질문 세 가지:

1. Iceberg REST 스펙을 따르는가?
2. 권한 관리(RBAC/ABAC)가 충분한가?
3. 데이터 자산을 넘어 AI 자산(모델·피처·노트북)까지 포함하는가?

2026년에 새로 카탈로그를 정한다면 Polaris·Lakekeeper·Unity 중 자기 인프라에 맞는 것을 고르는 흐름이다.

12장 · Trino, Presto, DuckDB — 쿼리 엔진의 3계급

레이크 위에서 SQL을 도는 엔진은 2026년 기준 세 계급으로 나뉜다.

Trino 460+ — 옛 PrestoSQL 분기. Starburst가 상업화. 페타바이트 규모 페더레이션 SQL.

• Fault-tolerant execution(FTE) — 큰 쿼리에서 노드 실패 시 부분 재시작. Exchange 데이터를 외부 스토리지에 둠.
• Pinot/Druid/Iceberg/Delta/Hudi 등을 한 SQL에서 묶음.
• Velocity가 매우 빠름. 460대를 2025년 안에 넘김.

Presto/PrestoDB

• 원조 Presto. 2019년 Linux Foundation으로. Meta가 주로 기여.
• 2024년 이후 Presto C++(Velox 기반) 가 주력. Meta는 같은 회사 내에서 Presto C++로 데이터를 도는 중.

DuckDB 1.x

• 임베디드 분석 DB. 단일 바이너리. Pandas·Polars·R·CSV·Parquet·Iceberg를 모두 SQL로.
• 노트북 안에서, Lambda 안에서, Edge에서 도는 새로운 카테고리.
• "쿼리 엔진은 더 이상 거대한 클러스터일 필요가 없다"는 패러다임의 대표.

MotherDuck — DuckDB를 클라우드 호스팅으로 묶는 회사. 로컬 + 클라우드 하이브리드.

Velox — Meta가 만든 C++ 벡터화 실행 엔진. Presto C++·Spark Gluten·Verdict 등이 그 위에 도는 공통 엔진을 노린다.

선택은 데이터 규모와 실행 모델에 따른다.

• 거대한 페더레이션 SQL → Trino
• Meta·일부 빅테크의 사내 표준 → Presto C++
• 단일 노드·임베디드·노트북 → DuckDB

13장 · OLAP 풍경 — Druid, Pinot, ClickHouse, StarRocks

실시간 분석(OLAP) 카테고리의 2026년 풍경.

Apache Druid — 시계열·이벤트 분석. 2011년 Metamarkets 시작. 실시간 인제스트 + 사전 집계.

Apache Pinot — LinkedIn에서 시작. 실시간 인제스트 + 사용자 대면 분석. Uber·LinkedIn·Stripe 같은 거대 트래픽에서 검증.

ClickHouse 24.x — Yandex(이제 ClickHouse Inc.)가 만든 컬럼 OLAP DB. 단일 노드 성능이 압도적. ClickHouse Cloud가 2022년 출시 후 빠르게 성장.

StarRocks — Apache Doris의 상용 분기. MPP OLAP DB. Iceberg·Hudi·Delta 직접 쿼리.

Apache Doris — Baidu에서 시작한 MPP OLAP. 중국·동아시아에서 강함.

이들의 공통점은 다음 세 가지를 동시에 추구한다는 것이다.

1. 밀리초~초 단위 응답.
2. 수십억 행 스캔.
3. 사용자 대면 대시보드에 직접 붙음(BI 도구가 아니라 앱 백엔드).

선택 가이드:

• 단일 클러스터·복잡한 쿼리 → ClickHouse
• 실시간 인제스트·사용자 대면 → Pinot, Druid
• Iceberg/레이크 위에서 쿼리 → StarRocks, Trino
• 한 노트북·임베디드 → DuckDB

14장 · dbt 1.9와 dbt Mesh — 변환 레이어의 표준

dbt(data build tool)는 "SQL로 데이터 모델링을 한다"는 단순한 아이디어로 모던 데이터 스택의 변환 레이어 표준이 됐다.

dbt 1.9의 핵심:

• dbt Mesh — 큰 조직에서 dbt 프로젝트를 도메인별로 쪼개고, 서로의 모델을 contract로 노출.
• Group/Access — 모델을 그룹화하고 외부 노출 여부를 명시.
• Semantic Layer가 dbt Cloud의 핵심 상품으로 자리잡음. 메트릭 정의를 한 곳에서.
• dbt Fusion(2025년 발표) — 기존 Python 기반 컴파일러를 Rust로 다시 씀. 실행 속도가 큰 폭으로 개선.

dbt의 라이벌:

• SQLMesh — Tobiko Data. dbt의 한계(Jinja, 실행 모델)를 다시 설계.
• Coalesce — GUI 기반 데이터 변환.
• dbt Cloud, dbt Core의 라이선스 분리가 2024년 화제가 되었지만, 핵심은 여전히 오픈.

15장 · 오케스트레이션 — Airflow 3.0, Dagster, Prefect, Argo

데이터 파이프라인을 스케줄링·관리하는 오케스트레이터의 풍경.

Apache Airflow 3.0(2025년 4월 GA)

• 가장 큰 변화: 태스크 격리(task isolation) 안정화. 작업이 별도 컨테이너에서 도는 게 표준.
• Task SDK가 분리돼 워커 의존성이 가벼워짐.
• 다중 DAG 버전 같은 핵심 운영 기능 정리.
• 여전히 가장 큰 커뮤니티.

Dagster 1.9

• Software-Defined Assets — DAG의 노드가 "어떤 데이터를 만들 책임"인지로 정의됨. Airflow와 다른 멘탈 모델.
• 자산 catalog, 데이터 품질, 백필이 일급 시민.
• 점차 데이터 플랫폼 일급 도구로.

Prefect 3.x

• "Pythonic"한 사용성. 데코레이터 한 줄로 함수가 태스크가 됨.
• 동적 워크플로우에 강함.

Argo Workflows

• Kubernetes 네이티브. CI/CD 같은 컨테이너 워크플로우에 강함.
• 데이터 파이프라인용으로도 쓰임.

Mage — 노트북 + 오케스트레이션. 노코드/로우코드.

Kestra — YAML/JS 기반 오케스트레이터. 자바 백엔드.

선택 가이드:

• 큰 조직·기존 자산 → Airflow 3
• 자산 중심·데이터 플랫폼 → Dagster
• 가벼운 동적 워크플로우 → Prefect
• 컨테이너·K8s 중심 → Argo

16장 · CDC 풍경 — Debezium 3, Flink CDC, Estuary

운영 DB에서 데이터 레이크/웨어하우스로 실시간 동기화하는 Change Data Capture(CDC) 의 2026년 풍경.

Debezium 3

• Red Hat이 주도. PostgreSQL·MySQL·MongoDB·Oracle·SQL Server·Db2 같은 DB의 로그를 읽어 Kafka로 송출.
• 3.x에서 운영성·메모리·스키마 진화가 크게 개선.

Flink CDC

• Debezium 코어를 Flink 안으로 가져옴. Kafka 없이 DB → Flink → Iceberg 직결.

Estuary Flow — SaaS CDC.

Airbyte — 오픈소스 ELT. CDC도 지원하지만 강점은 배치 커넥터.

Fivetran — 가장 성숙한 상용 CDC/ELT.

Sequin — PostgreSQL 전문 CDC. Webhook·Kafka 출력.

전형 아키텍처:

[PostgreSQL] → [Debezium] → [Kafka] → [Flink/Spark] → [Iceberg] → [Trino/Spark SQL]
                    또는
[PostgreSQL] → [Flink CDC] → [Iceberg]

운영 DB의 변화가 1~30초 안에 레이크에 반영되는 게 2026년 표준이다.

17장 · 레이크하우스 아키텍처 — 단일 진실 저장소의 부활

레이크하우스는 "데이터 레이크(저렴한 원시 저장소) + 데이터 웨어하우스(ACID, 스키마, 성능)"의 결합이다. 2026년 기준의 표준 아키텍처는 이렇게 정리된다.

Bronze · Silver · Gold 메달리온 아키텍처:

저장소는 객체 스토리지 + Iceberg/Delta/Hudi 테이블이다. 컴퓨트는 Spark/Flink/Trino/DuckDB 같은 엔진들이 같은 테이블을 공유한다. 카탈로그(Polaris/Unity/Gravitino)가 어떤 테이블이 어디 있는지·누가 볼 수 있는지를 관리한다.

이 아키텍처의 약속은 단순하다. 하나의 데이터, 여러 엔진, 통일된 권한. Hadoop이 약속했지만 실제로는 어려웠던 그 비전이, 2026년 클라우드 객체 스토리지 + 오픈 테이블 포맷 위에서 진짜로 작동한다.

18장 · 모던 데이터 스택의 진화 — 2020 → 2026

2020년대 초반 "모던 데이터 스택(MDS)"이라는 용어가 유행했다. 그 핵심은 Fivetran(수집) + Snowflake(웨어하우스) + dbt(변환) + Looker(BI) 네 도구의 조합이었다.

2026년에는 그 정의가 흔들렸다.

• 수집 → Fivetran/Airbyte 외에 Flink CDC, Debezium 같은 스트림 CDC가 큰 부분을 차지.
• 저장 → Snowflake 단독이 아니라 Snowflake + Databricks + 셀프 호스팅 레이크하우스가 공존.
• 변환 → dbt 외에 SQLMesh, dbt Fusion, Coalesce.
• BI → Looker 외에 Metabase, Superset, Hex, Mode가 폭발적.
• AI/ML 통합 → 이전엔 별도 트랙이었던 ML이 같은 데이터 위에서 돔. 피처 스토어·벡터 DB·LLM이 추가 레이어.

요약하면 "모던 데이터 스택 → 모던 데이터·AI 스택" 으로 어휘가 옮겨갔다. 데이터 엔지니어와 ML 엔지니어가 같은 카탈로그·같은 테이블을 공유하는 그림이 표준이 됐다.

19장 · 한국 기업의 빅데이터 도입 풍경

한국 시장에는 2026년 기준 다음 패턴이 명확하다.

통신·금융·공공: CDP/Hortonworks 잔존

• KT·SK텔레콤·LGU+·KB·신한·하나·NH 같은 대형 사업자는 여전히 거대한 CDP/HDP 기반 클러스터를 돈다. 2026년에도 그 위에 Spark/Hive 잡 수만 개가 돈다.
• 동시에 자체 클라우드(KT Cloud, NCloud, NHN Cloud) 위에서 Iceberg·Trino 기반 레이크하우스를 새로 구축하는 흐름.

게임·인터넷: 모던 데이터 스택

• 네이버 — 사내 빅데이터 플랫폼이 Spark 중심. 2024년 이후 Iceberg와 Trino를 적극 도입.
• 카카오 — 자체 ML 플랫폼과 데이터 플랫폼. Spark, Flink, Druid를 광범위하게 사용.
• 쿠팡 — 한때 Hadoop을 광범위하게 썼으나, 2020년대 중반부터 AWS 기반 Iceberg/Spark/Trino로 전환하며 Hadoop 의존을 줄임.
• LINE+ — Snowflake와 자체 레이크하우스를 병행. 2024~2025년 사이 일부 도메인을 Snowflake로 이주.
• NCsoft·넥슨·넷마블 — 게임 로그·결제·인게임 이벤트가 거대해, Kafka + Flink + Iceberg/Druid가 핵심.

스타트업: 클라우드 매니지드 우선

• BigQuery·Snowflake·Databricks가 첫 선택지. dbt는 사실상 표준.
• 일부는 자체 호스팅 ClickHouse/Trino로 비용 최적화.

한국적 특성:

• 정부·공공 데이터 규제로 인해 온프레미스·자체 클라우드 비중이 글로벌 평균보다 높다.
• 그래서 CDP 같은 온프레미스 빅데이터 플랫폼의 수명이 길다.
• 동시에 게임·이커머스·핀테크는 빠르게 클라우드 레이크하우스로 옮겨가는 중.

20장 · 일본 기업의 빅데이터 도입 풍경

일본 시장은 한국과 비슷하지만 결이 조금 다르다.

Yahoo! Japan / LINE 통합 LY

• 2023년 야후 재팬과 LINE이 LY로 합쳐졌다. 데이터 플랫폼은 통합 진행 중. 양사 모두 거대한 Hadoop/Spark 자산을 가짐.
• 광고·검색·메신저의 거대한 이벤트 스트림을 Kafka + Spark Streaming + Hadoop으로 처리해온 역사가 길다.

Cookpad — 요리 레시피 플랫폼. Redshift와 BigQuery를 중심으로 한 비교적 모던한 데이터 스택. dbt 도입 초기 사례.

Mercari — 거대한 ML 플랫폼. BigQuery + Vertex AI + Feast 피처 스토어 같은 클라우드 네이티브 조합.

Rakuten — Hadoop 기반 거대 인프라가 있지만, 2020년대 중반부터 클라우드 이주 진행. 자체 데이터 메시 모델 시도.

DeNA·CyberAgent·GREE — 모바일 게임·광고 데이터를 BigQuery·Snowflake로.

일본적 특성:

• 통신사(NTT 도코모, KDDI, 소프트뱅크)의 자체 클라우드 비중이 크다.
• 금융권은 온프레미스 + Cloudera 비중이 여전히 높다.
• 광고·게임 영역은 매우 빠르게 클라우드 + 모던 데이터 스택으로 이동.

한·일 모두 "온프레미스 빅데이터 자산이 매우 크고, 그 위에 새 레이크하우스를 얹는 듀얼 트랙"이 현실이다.

21장 · 실전 아키텍처 패턴 5개

자주 등장하는 2026년 패턴을 다섯 개 추린다.

패턴 1 · 클래식 배치 레이크하우스(중간 규모)

[운영 DB] → [Airbyte/Fivetran] → [Iceberg on S3] → [dbt + Spark] → [Trino] → [Metabase]

패턴 2 · CDC 스트리밍 레이크하우스(이벤트 중심)

[PostgreSQL/MySQL] → [Debezium → Kafka] → [Flink → Iceberg] → [Trino/Spark]
                                    ↘ [ClickHouse/Pinot] (실시간 대시보드)

패턴 3 · 게임·광고 이벤트 분석

[클라이언트] → [Kafka] → [Flink] → [Druid/Pinot] → [사용자 대면 대시보드]
                          ↓
                     [Iceberg] → [Spark 배치 분석]

패턴 4 · ML 플랫폼

[데이터 레이크(Iceberg)] → [Spark/Polars 피처링] → [Feast 피처 스토어]
            ↓                       ↓
   [학습(Spark MLlib, Ray)]   [온라인 서빙]
            ↓
    [모델 레지스트리(MLflow)]

패턴 5 · 임베디드 분석(작은 팀·노트북)

[Parquet on S3] → [DuckDB/Polars] → [Streamlit/노트북] → [공유]

같은 데이터 위에서 5개의 다른 아키텍처가 공존하는 게 2026년 풍경이다. 한 회사 안에서 여러 패턴이 동시에 도는 게 흔하다.

22장 · 실전 함정 — 안 하면 무조건 후회하는 것들

1. Small file 문제 — 객체 스토리지에 작은 파일이 수억 개 쌓이면 메타데이터·리스팅 비용이 폭발. Iceberg의 compaction, OPTIMIZE 같은 작업을 정기적으로 돌릴 것.

2. Schema evolution 합의 — Iceberg/Delta는 스키마 진화를 지원하지만, "어떤 변화를 허용할지"는 합의 문제. 컬럼 이름 변경 같은 깨지는 변화를 막을 컨트랙트가 필요.

3. 비용 가시화 — S3 요청 비용, Snowflake 크레딧, BigQuery 슬롯 — 클라우드 빅데이터의 진짜 비용은 컴퓨트와 데이터 이동이다. 처음부터 비용 라벨링을 강제할 것.

4. CDC의 backfill — 새 CDC 파이프라인을 켤 때 과거 데이터 backfill을 어떻게 할지가 가장 까다롭다. Debezium의 snapshot 모드와 incremental snapshot을 미리 검증할 것.

5. 카탈로그·권한 단일화 — 여러 엔진이 같은 테이블을 보면, 권한도 카탈로그 한 곳에서 관리해야 한다. 엔진별로 권한이 흩어지는 순간 거버넌스가 무너진다.

6. 스트림과 배치의 의미 차이 — "정확히-한-번"의 정의가 시스템마다 다르다. Flink·Kafka·Spark Streaming의 시맨틱을 정확히 이해해야 한다.

7. 테스트 환경의 데이터 — 운영 데이터를 그대로 쓰면 GDPR/PIPA 위반. 마스킹·합성 데이터 도구를 처음부터 설계할 것.

23장 · 학습 로드맵 — 어디서부터 시작할까

2026년에 새로 데이터 엔지니어가 된다면 다음 순서를 추천한다.

0단계 · SQL과 Python을 깊게. 모든 도구의 공통어다.

1단계 · Spark와 dbt. Spark로 "분산 처리가 어떻게 도는지"를 익히고, dbt로 "모델링을 SQL로 한다"는 어휘를 익힌다.

2단계 · Kafka와 Flink. 스트림 처리의 시맨틱을 익힌다. 정확히-한-번·워터마크·체크포인트.

3단계 · 테이블 포맷. Iceberg를 직접 만지고, Delta/Hudi와 비교한다.

4단계 · 오케스트레이션. Airflow나 Dagster 중 하나를 깊게.

5단계 · 운영 시점. 비용·관찰성(observability)·데이터 품질·거버넌스. 이 단계가 진짜 시니어를 결정한다.

6단계 · ML과 결합. 피처 스토어, 벡터 DB, LLM 파이프라인.

이 순서로 가면 2~3년 안에 "현대 데이터 플랫폼"의 전 영역을 다룰 수 있다.

24장 · 5년 후, 빅데이터는 어디로 가는가

향후 5년의 흐름을 다섯 줄로 압축하면.

1. 테이블 포맷 통일. Iceberg가 사실상 표준으로 굳고, Delta/Hudi와의 호환이 자연스러워진다.
2. 카탈로그 표준화. Iceberg REST 카탈로그 스펙이 확정되고, 누가 호스팅하든 같은 인터페이스.
3. 컴퓨트의 분리. 거대 단일 클러스터에서 "필요한 만큼만 띄우는" 서버리스 컴퓨트로. DuckDB·MotherDuck·Snowflake·Databricks SQL·Athena가 같은 길.
4. AI 통합. 데이터 카탈로그와 AI 자산 카탈로그가 통합된다. 모델·피처·노트북이 모두 같은 거버넌스 안.
5. 자연어 인터페이스. SQL을 짜는 대신 LLM에 묻고 데이터 엔지니어가 검증하는 워크플로우가 표준이 된다. dbt·Looker·Snowflake 모두 그 방향.

Hadoop의 어휘는 25년이 지나도 살아남는다. 그러나 그 위에 도는 도구는 계속 진화한다. 이 흐름의 한가운데 있다는 것은 2026년에도 여전히 흥미로운 자리다.

에필로그 — 죽음의 슬로건과 진짜 풍경

"X is dead" 라는 슬로건은 거의 항상 너무 강하다. 2020년에 "Hadoop is dead"였다면, 2024년에는 "Spark is dead, DuckDB가 모든 것을 한다"였고, 2026년에는 "데이터 엔지니어는 LLM에 대체된다"가 새 슬로건이다. 그러나 현장은 더 미묘하고 더 흥미롭다.

Hadoop은 죽지 않았다. 그것이 만든 어휘는 2026년에도 여전히 모든 데이터 시스템의 뼈대다. 다만 그 단어들이 도는 무대가 바뀌었을 뿐이다. 그 변화의 한가운데 서 있다면, 지금이 빅데이터 엔지니어로서 가장 흥미로운 시기다.

References

• Apache Hadoop project · https://hadoop.apache.org
• Apache Ozone documentation · https://ozone.apache.org
• Apache Spark 4.0 release notes · https://spark.apache.org/releases/spark-release-4-0-0.html
• Apache Hive 4.0 announcement · https://hive.apache.org
• Apache Kafka 4.0 release announcement · https://kafka.apache.org/blog
• Apache Flink 2.0 release · https://flink.apache.org/news
• Apache Iceberg specification · https://iceberg.apache.org/spec
• Apache Iceberg REST catalog · https://iceberg.apache.org/docs/latest/rest-catalog
• Apache Polaris · https://polaris.apache.org
• Lakekeeper Iceberg catalog · https://github.com/lakekeeper/lakekeeper
• Apache Gravitino · https://gravitino.apache.org
• Delta Lake project · https://delta.io
• Apache Hudi · https://hudi.apache.org
• Trino documentation · https://trino.io/docs
• Presto C++ on Velox · https://prestodb.io/blog
• DuckDB documentation · https://duckdb.org/docs
• dbt documentation · https://docs.getdbt.com
• Apache Airflow 3 release notes · https://airflow.apache.org/blog
• Dagster documentation · https://docs.dagster.io
• Apache Druid · https://druid.apache.org
• Apache Pinot · https://pinot.apache.org
• ClickHouse documentation · https://clickhouse.com/docs
• StarRocks documentation · https://docs.starrocks.io
• Debezium project · https://debezium.io
• Apache Pulsar · https://pulsar.apache.org
• Redpanda documentation · https://docs.redpanda.com
• Cloudera Data Platform · https://www.cloudera.com/products/cloudera-data-platform.html
• HPE Ezmeral Data Fabric · https://www.hpe.com/us/en/software/ezmeral.html