Chaos and Order

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

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

프롤로그 — 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년 기준, 그 위에서 자라난 도구들은 다음 표로 압축된다.

| 시기 | 키워드 | 대표 도구 |

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

| 2006~2012 | HDFS + MapReduce | Hadoop 1.x, Hive 0.x, Pig |

| 2013~2016 | YARN + 인메모리 | Hadoop 2, Spark, Tez, Impala |

| 2017~2020 | 클라우드 이주 | EMR, Dataproc, HDInsight |

| 2021~2024 | 레이크하우스 | Iceberg, Delta, Hudi, Trino, dbt |

| 2025~2026 | 모듈러·스트리밍 우선 | Kafka 4, Flink 2, Polaris, Lakekeeper |

흔히 "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년에 이렇게 정리된다.

| 도구 | 모델 | 강점 |

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

| Flink SQL | DataStream 위의 SQL | 정확히-한-번, 풍부한 상태 처리 |

| ksqlDB | Kafka Streams 위의 SQL | Kafka 통합, 가벼움 |

| Materialize | 외부 시스템 위의 SQL view | OLTP 친화, Differential Dataflow |

| RisingWave | 새 스트리밍 DB | PostgreSQL 호환 |

| Arroyo | 새 Rust 스트리밍 SQL | 클라우드 네이티브 |

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

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

| 항목 | YARN | Kubernetes |

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

| 대상 워크로드 | 빅데이터 위주 | 범용(웹·ML·데이터) |

| 컨테이너 | 자체(LXC/cgroups) | OCI |

| 자원 모델 | CPU/메모리/GPU | 풍부, 확장 가능 |

| 다중 테넌시 | 큐 기반 | 네임스페이스 기반 |

| 생태계 | Hadoop 중심 | CNCF 전체 |

| 학습 곡선 | 빅데이터 팀에 익숙 | 플랫폼 팀에 익숙 |

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 메달리온 아키텍처**:

| 레이어 | 형태 | 도구 |

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

| Bronze(원시) | CDC/이벤트 그대로 | Kafka, Iceberg, S3 |

| Silver(클렌징) | 표준화·중복제거 | Spark, Flink, dbt |

| Gold(서빙) | 집계·도메인 모델 | dbt, Spark, Trino |

저장소는 객체 스토리지 + 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](https://hadoop.apache.org)

- Apache Ozone documentation · [https://ozone.apache.org](https://ozone.apache.org)

- Apache Spark 4.0 release notes · [https://spark.apache.org/releases/spark-release-4-0-0.html](https://spark.apache.org/releases/spark-release-4-0-0.html)

- Apache Hive 4.0 announcement · [https://hive.apache.org](https://hive.apache.org)

- Apache Kafka 4.0 release announcement · [https://kafka.apache.org/blog](https://kafka.apache.org/blog)

- Apache Flink 2.0 release · [https://flink.apache.org/news](https://flink.apache.org/news)

- Apache Iceberg specification · [https://iceberg.apache.org/spec](https://iceberg.apache.org/spec)

- Apache Iceberg REST catalog · [https://iceberg.apache.org/docs/latest/rest-catalog](https://iceberg.apache.org/docs/latest/rest-catalog)

- Apache Polaris · [https://polaris.apache.org](https://polaris.apache.org)

- Lakekeeper Iceberg catalog · [https://github.com/lakekeeper/lakekeeper](https://github.com/lakekeeper/lakekeeper)

- Apache Gravitino · [https://gravitino.apache.org](https://gravitino.apache.org)

- Delta Lake project · [https://delta.io](https://delta.io)

- Apache Hudi · [https://hudi.apache.org](https://hudi.apache.org)

- Trino documentation · [https://trino.io/docs](https://trino.io/docs)

- Presto C++ on Velox · [https://prestodb.io/blog](https://prestodb.io/blog)

- DuckDB documentation · [https://duckdb.org/docs](https://duckdb.org/docs)

- dbt documentation · [https://docs.getdbt.com](https://docs.getdbt.com)

- Apache Airflow 3 release notes · [https://airflow.apache.org/blog](https://airflow.apache.org/blog)

- Dagster documentation · [https://docs.dagster.io](https://docs.dagster.io)

- Apache Druid · [https://druid.apache.org](https://druid.apache.org)

- Apache Pinot · [https://pinot.apache.org](https://pinot.apache.org)

- ClickHouse documentation · [https://clickhouse.com/docs](https://clickhouse.com/docs)

- StarRocks documentation · [https://docs.starrocks.io](https://docs.starrocks.io)

- Debezium project · [https://debezium.io](https://debezium.io)

- Apache Pulsar · [https://pulsar.apache.org](https://pulsar.apache.org)

- Redpanda documentation · [https://docs.redpanda.com](https://docs.redpanda.com)

- Cloudera Data Platform · [https://www.cloudera.com/products/cloudera-data-platform.html](https://www.cloudera.com/products/cloudera-data-platform.html)

- HPE Ezmeral Data Fabric · [https://www.hpe.com/us/en/software/ezmeral.html](https://www.hpe.com/us/en/software/ezmeral.html)