Airflow·Flink·Iceberg·Lakehouse 완전정복: 데이터 엔지니어링을 하나의 흐름으로 이해하는 풀코스

이 글의 목표: 기술 이름이 아니라 하나의 데이터 흐름을 이해하기

Airflow, Flink, Iceberg, Lakehouse라는 단어를 처음 보면 서로 비슷한 빅데이터 도구처럼 보입니다. 하지만 실제로는 역할이 완전히 다릅니다.

가장 먼저 아래 네 문장부터 기억하시면 됩니다.

이 네 가지는 경쟁 관계가 아닙니다. 하나의 데이터 플랫폼 안에서 서로 다른 층을 담당합니다.

이 글은 이 구조를 독학할 수 있도록 개념 → 핵심 원리 → 실습 → 활용 → 판단 기준 순서로 구성한 풀코스입니다.

전체 커리큘럼

학습 순서는 중요합니다. Flink부터 설치하거나 Iceberg SQL부터 외우면 기술은 만져봤지만 왜 필요한지 이해하지 못할 가능성이 높습니다.

0강. 먼저 알아야 할 것: 데이터 엔지니어링은 '데이터를 이동시키는 일' 이상이다

0-1. 데이터 파이프라인이란 무엇인가

가장 단순한 형태는 다음과 같습니다.

실제 시스템에서는 여기에 어려운 문제가 붙습니다.

• 데이터가 늦게 들어오면 어떻게 할 것인가?
• 같은 데이터가 두 번 들어오면 어떻게 할 것인가?
• 중간 작업이 실패하면 처음부터 다시 할 것인가?
• 과거 데이터가 수정되면 다시 계산할 수 있는가?
• 컬럼이 추가되면 기존 데이터가 깨지지 않는가?
• 1억 건의 파일 중 필요한 데이터만 빠르게 찾을 수 있는가?
• 서버가 죽어도 실시간 집계값을 복구할 수 있는가?

Airflow, Flink, Iceberg, Lakehouse는 각각 이 문제의 다른 부분을 해결합니다.

0-2. Batch와 Streaming

중요한 점은 실시간이 항상 우월한 것이 아니라는 것​입니다. 하루 한 번이면 충분한 통계를 Kafka와 Flink로 만들면 기술적으로 화려하지만 운영 비용과 장애 지점만 늘어날 수 있습니다.

0-3. OLTP와 OLAP

웹 서비스의 PostgreSQL 같은 운영 DB는 보통 OLTP 성격이 강합니다.

반면 분석은 다릅니다.

운영 DB 하나에 모든 분석 부하를 넣으면 서비스와 분석이 서로 싸우기 시작합니다. 그래서 분석용 데이터 플랫폼이 등장합니다.

1강. Apache Airflow: 데이터 작업의 공정 관리자

Apache Airflow 공식 문서는 Airflow를 batch-oriented workflow를 개발·스케줄·모니터링하는 오픈소스 플랫폼​으로 설명합니다. 워크플로는 Python 코드로 정의되고, DAG 안에 여러 Task와 의존성이 들어갑니다.

1-1. Airflow가 없으면 어떤 문제가 생기는가

예를 들어 매일 새벽 아래 작업을 수행한다고 가정합니다.

처음에는 cron으로 충분해 보입니다.

하지만 운영이 시작되면 질문이 생깁니다.

Airflow가 바로 이 문제를 다룹니다.

1-2. DAG

DAG는 Directed Acyclic Graph입니다.

핵심은 작업과 작업의 의존 관계를 코드로 표현한다는 것​입니다.

Airflow 공식 문서에서도 DAG는 스케줄, Task, Task Dependency 등을 포함하며, DAG 자체는 Task 내부에서 무슨 계산을 하는지보다 언제 어떤 순서와 조건으로 실행하는지​를 관리한다고 설명합니다.

1-3. 핵심 개념

1-4. 가장 중요한 원리: Idempotency

Airflow 문법보다 중요한 개념입니다.

같은 작업을 두 번 실행해도 결과가 망가지지 않아야 합니다.

나쁜 예:

좋은 설계:

재시도 가능한 데이터 파이프라인을 만들려면 중복 처리 정책을 먼저 설계해야 합니다.

1-5. 첫 실습

목표:

간단한 DAG 예시는 다음과 같은 모양입니다.

코드보다 중요한 것은 다음 질문입니다.

• extract가 두 번 실행돼도 안전한가?
• load 중간에 죽으면 어떻게 복구할 것인가?
• 데이터 건수가 평소보다 90% 감소하면 성공으로 볼 것인가?
• 7일 전 데이터를 다시 실행할 수 있는가?

1-6. Airflow를 쓰지 말아야 할 때

Airflow는 실시간 스트림 자체를 계속 처리하는 엔진이 아닙니다.

이런 문제에는 Flink 같은 스트림 처리 엔진이 더 적합합니다.

Airflow = 일을 실행시키고 관리하는 도구​이지, 대량 데이터를 직접 계산하는 핵심 엔진이라고 생각하면 안 됩니다.

1강 완료 기준

• DAG를 직접 그릴 수 있다.
• Dependency와 Retry를 설명할 수 있다.
• Backfill이 왜 필요한지 설명할 수 있다.
• Idempotency를 예제로 설명할 수 있다.
• cron과 Airflow의 차이를 설명할 수 있다.

2강. Kafka를 짧게 복습해야 하는 이유

Flink를 이해하려면 Kafka를 최소한 알아야 합니다.

Kafka의 핵심 역할은 이벤트를 안정적으로 쌓아두고 여러 소비자가 자신의 속도로 읽을 수 있도록 하는 것​입니다.

반드시 알아야 할 개념

Kafka는 데이터를 운반하고 보관합니다. 하지만 "최근 5분 주문 합계", "현재 사용자별 누적 클릭 수" 같은 상태 있는 계산은 Kafka 자체의 주역할이 아닙니다. 여기서 Flink가 등장합니다.

3강. Apache Flink: 흐르는 데이터를 계산하는 엔진

Apache Flink 공식 문서는 Flink를 bounded 및 unbounded data stream 위에서 stateful computation을 수행하는 분산 처리 엔진​으로 설명합니다.

핵심 단어는 세 개입니다.

Stream / State / Time

3-1. 왜 Flink가 필요한가

이벤트가 계속 들어옵니다.

우리는 다음을 즉시 알고 싶습니다.

이는 단순히 이벤트 하나를 읽고 끝나는 계산이 아닙니다. 과거에 들어온 값을 기억해야 합니다.

그래서 Flink의 핵심이 State입니다.

3-2. State

Flink의 keyed state는 특정 key 기준으로 상태를 분산 저장할 수 있습니다.

이 덕분에 데이터를 병렬 처리하면서도 사용자별·장비별·주문별 상태를 유지할 수 있습니다.

3-3. Streaming에서 가장 어려운 것: 시간

실제 이벤트는 순서대로 들어오지 않습니다.

Flink는 이를 위해 여러 시간 개념을 구분합니다.

정확한 비즈니스 집계에서는 Event Time이 중요합니다.

3-4. Watermark

이 개념이 Flink 초보자에게 가장 낯섭니다.

"10:00~10:01 주문 합계를 계산하라"고 했는데 10:00:59에 발생한 이벤트가 네트워크 문제로 10:01:05에 도착할 수 있습니다.

언제 10:00~10:01 창을 닫아야 할까요?

Watermark는 대략 다음 메시지와 같습니다.

우리는 이벤트 시간이 여기까지 진행했다고 판단합니다. 이보다 오래된 이벤트는 이제 늦은 이벤트로 취급할 준비를 합니다.

Watermark는 완전한 미래 예측이 아니라 지연과 결과 완결성 사이의 정책​입니다.

3-5. Window

무한히 들어오는 스트림은 "전체 합계"를 언제 끝낼지 정의하기 어렵습니다. 그래서 구간을 만듭니다.

예:

• 최근 5분 주문 수
• 1분 단위 장비 오류 건수
• 10분 창을 1분마다 갱신하는 이동 평균

3-6. Checkpoint와 장애 복구

실시간 집계 도중 서버가 죽었다고 가정합니다.

처음부터 다시 계산하면 안 됩니다.

Flink는 State와 입력 스트림의 위치를 함께 checkpoint​하여 복구할 수 있도록 설계되어 있습니다. 공식 문서에서는 checkpoint를 이용해 state와 stream position을 복원함으로써 장애가 없었던 것과 동일한 의미론을 유지할 수 있다고 설명합니다.

Kafka 같은 rewind 가능한 소스와 조합하면 마지막 정상 checkpoint 시점부터 이벤트를 다시 읽을 수 있습니다.

3-7. Exactly Once의 정확한 뜻

"Exactly Once"를 이벤트가 네트워크를 딱 한 번만 지나간다는 뜻으로 이해하면 안 됩니다.

핵심은 장애와 재처리가 있어도 최종 상태가 각 이벤트를 정확히 한 번 반영한 것과 동일하도록 유지하는 처리 의미론​입니다.

이 차이는 중요합니다.

3-8. Flink SQL 예시

문법을 외우기보다 아래 흐름을 이해해야 합니다.

3강 완료 기준

• Kafka와 Flink의 역할 차이를 설명할 수 있다.
• State가 왜 필요한지 설명할 수 있다.
• Event Time과 Processing Time 차이를 설명할 수 있다.
• Watermark가 왜 필요한지 설명할 수 있다.
• Window를 직접 설계할 수 있다.
• Checkpoint와 Exactly Once를 설명할 수 있다.

4강. Iceberg 전에 알아야 할 S3·Parquet·Partition

Iceberg를 이해하려면 "데이터가 DB가 아니라 파일로 존재할 수 있다"는 관점부터 익혀야 합니다.

4-1. Object Storage

S3나 MinIO 같은 저장소에는 파일을 매우 많이 저렴하게 저장할 수 있습니다.

그러나 파일 저장소 자체는 PostgreSQL 테이블이 아닙니다.

4-2. Parquet

분석 데이터에서는 CSV보다 Parquet 같은 columnar format이 자주 사용됩니다.

분석에서 특정 컬럼 몇 개만 읽을 때 효율적이며 압축에도 유리합니다.

4-3. Partition

예를 들어 날짜 기준으로 파일을 분리할 수 있습니다.

8월 27일 데이터만 조회한다면 전체 파일을 읽지 않아도 됩니다.

그런데 시간이 지나면 문제가 생깁니다.

• 파티션 기준을 변경하고 싶다.
• 컬럼 이름을 변경하고 싶다.
• 특정 행을 삭제하고 싶다.
• 동시에 여러 엔진이 데이터를 쓰고 있다.
• 어제 상태로 되돌리고 싶다.
• 수십만 개 파일 중 어떤 파일이 현재 테이블에 포함되는지 알고 싶다.

단순한 "S3 + Parquet 파일 더미"만으로는 관리가 어려워집니다.

여기서 Iceberg가 등장합니다.

5강. Apache Iceberg: 파일 더미 위에 '테이블의 질서'를 만든다

Apache Iceberg 공식 설명은 Iceberg를 huge analytic datasets를 위한 open table format​이라고 정의합니다. Spark, Trino, Flink, Hive 등 여러 엔진이 동일한 테이블을 안전하게 다룰 수 있도록 SQL 테이블과 비슷한 신뢰성을 제공합니다.

중요합니다.

Iceberg는 데이터베이스 서버가 아닙니다.

그리고 Parquet의 대체 파일 포맷도 아닙니다.

관계를 표현하면 다음과 같습니다.

5-1. 왜 필요한가

S3에 아래 파일이 있다고 합시다.

어떤 파일이 현재 테이블의 정식 데이터인지, 어떤 파일이 삭제 대상인지, 어떤 Schema를 사용하는지, 어느 시점의 데이터인지 관리할 계층이 필요합니다.

Iceberg가 이 역할을 합니다.

5-2. Snapshot

Iceberg에서 매우 중요한 개념입니다.

파일을 매번 모두 복사하는 개념이 아니라 테이블의 특정 시점 상태를 메타데이터로 추적​합니다.

이 구조가 Time Travel, Rollback 같은 기능의 기반이 됩니다.

5-3. Metadata → Manifest List → Manifest → Data File

Iceberg 내부 구조를 가장 단순화하면 다음과 같습니다.

Manifest에는 단순 파일 경로뿐 아니라 partition 정보와 column-level statistics 등이 포함될 수 있어, 쿼리 시 읽지 않아도 되는 파일을 빠르게 제외하는 데 활용됩니다.

5-4. Atomic Commit과 Optimistic Concurrency

여러 작업이 동시에 테이블을 수정한다고 생각해 봅시다.

Iceberg spec은 새로운 metadata를 만들고 테이블의 현재 metadata를 atomic하게 교체하는 방식을 기반으로 table state를 관리합니다. 이를 통해 optimistic concurrency와 serializable isolation을 구성할 수 있습니다.

즉 "S3에 파일을 쓰는 것"과 "그 파일을 테이블의 공식 상태로 commit하는 것"을 구분합니다.

5-5. Schema Evolution

초기:

나중:

Iceberg는 column ID를 이용해 Schema를 관리하며 add/drop/rename/reorder 등의 evolution을 지원합니다.

수년 동안 데이터가 쌓이는 분석 플랫폼에서 이는 매우 중요합니다.

5-6. Partition Evolution

처음에는 하루 데이터가 적어서 월 단위 partition이면 충분했다고 가정합니다.

데이터가 폭증해서 일 단위가 필요해졌습니다.

전통적인 파일 레이아웃에서는 변경이 골칫거리입니다. Iceberg는 partition spec 자체를 versioned metadata로 관리하여 새로운 partition 전략으로 발전할 수 있도록 설계되어 있습니다.

5-7. Hidden Partitioning

사용자가 실제 디렉터리 구조를 일일이 알아야 하는 방식보다 Iceberg는 테이블 수준의 partition 표현을 제공합니다.

사용자는:

처럼 비즈니스 컬럼에 조건을 걸고, 엔진과 Iceberg가 필요한 파일을 선택합니다.

5-8. Time Travel

Iceberg는 이전 snapshot을 기준으로 조회할 수 있습니다.

활용:

• 잘못된 ETL 결과 조사
• 데이터 재현
• 과거 보고서 검증
• 배포 전후 비교
• 실수 복구

5-9. Iceberg를 쓰면 PostgreSQL이 필요 없는가?

아닙니다.

둘은 경쟁하기보다 함께 쓰이는 경우가 많습니다.

5강 완료 기준

• Iceberg와 Parquet의 차이를 설명할 수 있다.
• Iceberg와 DB의 차이를 설명할 수 있다.
• Snapshot과 Manifest 구조를 그릴 수 있다.
• Schema Evolution이 왜 필요한지 설명할 수 있다.
• Partition Evolution을 설명할 수 있다.
• Time Travel의 실제 용도를 설명할 수 있다.

6강. Lakehouse: 도구가 아니라 전체 아키텍처다

Lakehouse는 Apache 제품 하나의 이름이 아닙니다.

AWS, Microsoft, Databricks의 현재 설명은 공통적으로 Data Lake와 Data Warehouse의 장점을 결합한 통합 데이터 아키텍처​라는 방향을 갖습니다.

6-1. Data Warehouse

장점:

• 정돈된 Schema
• SQL
• BI 친화적
• 높은 데이터 품질
• 관리/거버넌스

단점:

• 원본/비정형 데이터 수용이 제한적일 수 있음
• 스토리지와 컴퓨팅 비용이 커질 수 있음
• 다양한 ML/데이터 과학 워크로드와 분리되기 쉬움

6-2. Data Lake

장점:

• 매우 유연함
• 다양한 데이터 저장
• 저렴한 Object Storage
• 대규모 확장

그러나 관리되지 않으면 다음 문제가 생깁니다.

Data Lake가 Data Swamp가 되는 순간입니다.

6-3. Lakehouse

Lakehouse는 단순화하면 다음 아이디어입니다.

Iceberg 같은 open table format이 여기에서 중요한 역할을 합니다.

데이터 파일은 저렴한 storage에 있지만 테이블 수준의 transaction, schema, snapshot 같은 기능을 추가합니다.

7강. Medallion Architecture: Bronze → Silver → Gold

Lakehouse를 공부하다 보면 거의 반드시 만나게 되는 패턴입니다.

Microsoft와 Databricks의 현재 문서에서도 Bronze, Silver, Gold를 데이터 품질이 점진적으로 높아지는 계층으로 설명합니다.

Bronze

원본을 최대한 보존합니다.

목적은 "나중에 다시 처리할 수 있는 원본"을 확보하는 것입니다.

Silver

품질을 높입니다.

Gold

사용 목적에 맞게 만듭니다.

왜 한 번에 Gold를 만들지 않는가

원본 → 최종 결과만 있으면 문제가 발생했을 때 중간 과정이 사라집니다.

계층을 두면 추적이 쉬워집니다.

8강. Airflow + Flink + Iceberg + Lakehouse를 연결한다

이제 각 기술이 한 그림에 들어갑니다.

여기에서 역할을 다시 정리합니다.

9강. 예제로 이해하는 제조·현장 데이터 플랫폼

전자상거래 예제 대신 실제 제조/현장 시스템을 가정해 보겠습니다.

이벤트:

실시간 영역

저장 영역

배치 영역

매일 새벽 Airflow가 실행됩니다.

최종 활용

이 시점부터 데이터 플랫폼은 단순 CRUD 웹앱과 다른 성격을 갖기 시작합니다.

10강. 진짜 중요한 것은 Data Quality다

기술을 모두 설치했다고 좋은 데이터 플랫폼이 되는 것은 아닙니다.

더 중요한 질문이 있습니다.

오늘 100,000건이 들어와야 하는데 72,314건만 들어왔다면 시스템이 스스로 알아차릴 수 있는가?

품질 체크 예시

Airflow 성공 표시가 초록색이라고 해서 데이터가 정상이라는 뜻은 아닙니다.

시스템 성공과 데이터 성공을 구분해야 합니다.

11강. 운영에서 반드시 공부해야 하는 개념

Retry

일시적인 네트워크 오류는 다시 실행할 수 있어야 합니다.

Backfill

지난 7일 데이터 로직에 버그가 있었다면 수정 후 과거 구간을 다시 계산해야 합니다.

Dead Letter Queue

처리할 수 없는 이벤트를 버리지 말고 별도 저장하여 조사합니다.

Schema Evolution

시스템은 시간이 지나면서 반드시 변합니다.

Lineage

"이 숫자가 어디서 왔는가"를 추적할 수 있어야 합니다.

Observability

최소한 다음을 모니터링합니다.

12강. 흔한 오해 8가지

오해 1. Airflow가 데이터를 직접 처리한다

주 역할은 orchestration입니다. 실제 대량 계산은 SQL, Python, Spark 등 다른 실행 엔진에 맡길 수 있습니다.

오해 2. Kafka와 Flink는 비슷하다

Kafka는 이벤트 운반/로그 저장 인프라, Flink는 계산 엔진입니다.

오해 3. Flink는 무조건 빠른 Spark다

둘은 겹치는 영역도 있지만 Flink의 핵심 강점은 stateful streaming, event time, continuous processing입니다.

오해 4. Iceberg는 Parquet 대체품이다

Parquet은 파일 format, Iceberg는 table format입니다.

오해 5. Iceberg는 데이터베이스다

DB 서버라기보다 여러 데이터 파일과 metadata를 하나의 분석 테이블로 관리하는 규격/계층입니다.

오해 6. Lakehouse는 제품 이름이다

아키텍처 패턴입니다. Iceberg, Delta Lake, Hudi 같은 table technology와 다양한 compute engine으로 구현할 수 있습니다.

오해 7. 실시간이 Batch보다 좋다

비즈니스가 실시간을 요구하지 않는다면 Batch가 훨씬 단순하고 저렴할 수 있습니다.

오해 8. 기술을 많이 넣을수록 시스템이 좋아진다

작은 서비스에 Kafka + Flink + Spark + Kubernetes + Iceberg를 전부 넣으면 학습에는 좋지만 운영에는 과도할 수 있습니다.

13강. 어떤 규모에서 무엇을 도입할까

단계 A: 일반적인 업무 시스템

이것만으로 충분할 수 있습니다.

단계 B: 반복 Batch 자동화

Airflow 도입을 검토합니다.

단계 C: 분석 데이터가 크게 증가

단계 D: 파일 기반 분석 테이블 관리가 복잡해짐

단계 E: 실시간 이벤트 처리 필요

단계 F: 통합 분석 플랫폼

즉 기술 도입은 문제 발생 순서대로 하는 것이 좋습니다.

14강. 6주 독학 실전 코스

1주차: Airflow

학습:

• DAG
• Task
• Scheduler
• Retry
• Backfill
• Idempotency

과제:

완료 조건:

• 일부러 Task를 실패시키고 재시도
• 3일 전 데이터를 backfill
• 중복 실행해도 결과 동일

2주차: Kafka + Streaming 기초

학습:

• Event
• Topic
• Partition
• Offset
• Consumer Group

과제:

3주차: Flink

학습:

• State
• Keyed State
• Event Time
• Watermark
• Window
• Checkpoint

과제:

실험:

일부 이벤트를 늦게 보내 Watermark에 따라 결과가 어떻게 달라지는지 확인합니다.

4주차: S3/MinIO + Parquet + Iceberg

학습:

• Object Storage
• Columnar Format
• Partition
• Metadata
• Snapshot
• Manifest

과제:

실험:

• 데이터 추가
• Schema 변경
• Snapshot 확인
• Time Travel

5주차: Lakehouse

구축:

각 계층의 데이터 품질 규칙을 직접 정의합니다.

6주차: End-to-End

최종 구조:

여기에 일부러 장애를 넣습니다.

• Flink 프로세스 종료
• 잘못된 이벤트 전송
• Schema 변경
• Airflow Task 실패
• 데이터 중복 입력

그리고 복구합니다.

장애 없는 데모보다 장애를 복구해본 프로젝트가 훨씬 많이 가르쳐줍니다.

15강. AI 시대에는 무엇을 직접 공부해야 하는가

AI에게 적극적으로 맡겨도 되는 것:

그러나 직접 판단해야 하는 것은 다릅니다.

AI가 코드를 작성할수록 기술 선택과 데이터 의미를 판단하는 능력의 가치가 오히려 커집니다.

최종 정리: 네 기술을 한 문장씩 설명할 수 있다면 절반은 끝났다

그리고 전체 흐름은 이 한 장으로 기억하면 됩니다.

처음부터 모든 기술을 설치하는 것이 목표가 아닙니다.

문제를 이해하고, 그 문제를 해결하기 위해 필요한 기술을 정확히 선택할 수 있는 것.

그것이 이 커리큘럼의 최종 목표입니다.

공식 자료 및 추가 학습 자료

이번 정리는 개념을 쉽게 풀어썼지만 핵심 기술 정의와 동작 원리는 각 프로젝트 및 주요 플랫폼의 공식 문서를 기준으로 확인했습니다.

• Apache Airflow 공식 문서: https://airflow.apache.org/docs/apache-airflow/stable/
• Airflow Architecture: https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/overview.html
• Airflow DAG: https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.html
• Apache Flink 공식 문서: https://nightlies.apache.org/flink/flink-docs-stable/
• Flink Streaming Analytics: https://nightlies.apache.org/flink/flink-docs-stable/docs/learn-flink/streaming_analytics/
• Flink Stateful Stream Processing: https://nightlies.apache.org/flink/flink-docs-stable/docs/concepts/stateful-stream-processing/
• Apache Iceberg 공식 사이트: https://iceberg.apache.org/
• Apache Iceberg Table Spec: https://iceberg.apache.org/spec/
• Apache Iceberg Schema: https://iceberg.apache.org/docs/latest/schemas/
• AWS Data Lakehouse: https://aws.amazon.com/what-is/data-lakehouse/
• Microsoft Medallion Lakehouse Architecture: https://learn.microsoft.com/en-us/azure/databricks/lakehouse/medallion
• Databricks Lakehouse 개념: https://www.databricks.com/blog/what-is-data-lakehouse

공식 문서를 읽을 때 모든 설정값을 처음부터 외우지 마세요. 먼저 DAG → State/Time → Snapshot → Lakehouse​라는 네 개의 사고 모델을 만든 뒤 필요한 세부 문서를 찾아보는 방식이 가장 효율적입니다.