스트리밍 vs 배치의 재정의: Flink·RisingWave·Materialize, CDC, Streaming SQL, 실시간의 실용주의 (2025)

Season 5 Ep 2 — Ep 1이 "데이터가 어디에 저장되는가"였다면 Ep 2는 "데이터가 얼마나 빠르게 흐르는가". 2020–2023의 실시간 광풍, 2024–2025의 실용주의로 돌아오기.

Prologue — "실시간은 기본이 아니라 옵션이다"
1장 · 신선도 계층 (Freshness Tiers)
2장 · Lambda·Kappa 아키텍처의 2025년 버전
3장 · 스트리밍 엔진 4대 비교
4장 · CDC (Change Data Capture)
5장 · Iceberg v3와 실시간 Upsert
6장 · Streaming SQL의 부상
7장 · 비용·지연 트레이드오프
8장 · 관측성과 디버깅
9장 · 장애·복구·SLA
10장 · 스트리밍 + Lakehouse 실전 패턴
11장 · 실전 케이스 3
12장 · 한국 기업의 스트리밍
13장 · 안티패턴 10선
14장 · 체크리스트 — 스트리밍 런칭 전 12가지
15장 · 다음 글 예고 — Season 5 Ep 3: "OLAP 엔진 2025 비교"

Prologue — "실시간은 기본이 아니라 옵션이다"

2019–2022년 데이터 컨퍼런스의 모든 키노트는 "모든 데이터는 실시간이 되어야 한다"였다. 2025년 현실은 다르다:

실시간 파이프라인은 배치 대비 3–10배 비싸다
대부분의 BI 대시보드는 15분–1시간 지연이어도 아무도 불평 안 한다
진짜 실시간이 필요한 건 전체 데이터의 5–15%

2025년의 정답:

"데이터별·지표별 SLA 기반으로 신선도 계층을 나누고, 각 계층에 맞는 도구를 쓴다."

이 글은 그 계층과 도구 선택을 구체화한다.

1장 · 신선도 계층 (Freshness Tiers)

1.1 5계층 프레임워크

계층	지연	예시	도구
Real-time	ms–초	거래 모니터링·이상탐지·fraud	Flink, Kafka Streams
Near-real-time	1–5분	운영 대시보드·alert	Flink, RisingWave, Materialize
Fresh	5–60분	재고·광고 최적화	Streaming append + rollup
Daily	24시간	BI, 리포트	Spark, dbt, SQL warehouse
Historical	주/월	분석·ML 학습	Batch 연/월

1.2 각 지표·테이블을 계층에 매핑

재고 지표: Fresh
로그인 이상탐지: Real-time
월별 매출: Daily
모델 학습용 피처: Fresh + Daily 혼합

1.3 의사결정 원칙

비즈니스 질문: "지표가 1시간 늦으면 무슨 일이 생기나?"
답이 "아무 일도" → Daily 또는 Fresh
답이 "10만원 손실" → Near-real-time
답이 "사람이 다친다/법적 문제" → Real-time

2장 · Lambda·Kappa 아키텍처의 2025년 버전

2.1 Lambda (2014)

Batch layer + Speed layer + Serving layer
같은 로직을 두 번 구현 → 유지 부담
2015–2020 지배적

2.2 Kappa (2014, Jay Kreps)

스트리밍 로그(Kafka) 하나로 통일
재처리도 스트리밍으로
이론적 단순함, 실무적 어려움

2.3 2025년: Unified on Lakehouse

Iceberg/Delta 테이블 위에 배치와 스트리밍이 동시에 쓴다
Flink + Iceberg, Spark Structured Streaming + Delta
Serving은 OLAP 엔진이나 materialized view

2.4 "Streaming + Materialized" 패턴

소스 → 스트리밍 파이프라인 → Lakehouse
자주 쓰는 쿼리는 Materialized view로 프리컴퓨트
ad-hoc은 OLAP 엔진이 직접 쿼리

3장 · 스트리밍 엔진 4대 비교

3.1 Apache Flink

진짜 이벤트 시간(Event time) 기반, watermark, exactly-once
상태(Keyed state) 풍부, 대규모 프로덕션 검증
학습 곡선 가파름, 운영 복잡
2024–2025 Flink CDC 2.x, Flink SQL 성숙

3.2 Spark Structured Streaming

Spark 생태계의 micro-batch 스트리밍
Databricks 표준
지연 목표 1–60초 이상, 진짜 ms급은 아님
SQL/Python 쉬움

3.3 Kafka Streams / ksqlDB

Kafka 내장 라이브러리, JVM 기반
가벼움, Kafka 데이터에 집중할 때 최적
분산 운영은 자체 구현

3.4 RisingWave

2022 오픈소스, Streaming SQL 특화
Postgres 호환 SQL + Materialized view
상태는 별도 스토리지(S3) — 운영 간편
Flink 대안으로 급부상

3.5 Materialize

Streaming + Incremental view maintenance
복잡 조인·집계 자동 최신화
엔터프라이즈 SaaS 중심

3.6 비교표

엔진	지연	복잡도	SQL	한국 사용	특징
Flink	ms–초	높음	O	많음	업계 표준, 상태 관리 강함
Spark SS	초–분	중	O	매우 많음	Databricks 친화
Kafka Streams	초	중	ksqlDB	보통	Kafka 내장
RisingWave	초	낮음	Postgres	증가	운영 간편, SaaS/OSS
Materialize	초	중	O	드묾	Incremental view 강점

3.7 선택 가이드

이벤트 시간·복잡 상태: Flink
Databricks 생태계: Spark SS
Kafka 중심·단순 로직: Kafka Streams / ksqlDB
SQL만으로 스트리밍 앱: RisingWave 또는 Materialize

4장 · CDC (Change Data Capture)

4.1 왜 CDC가 핵심인가

운영 DB(Postgres/MySQL)의 변경을 분석 시스템으로 실시간 복제
배치 덤프 대비 지연·부하 대폭 감소
Lakehouse의 Silver 레이어를 자동 유지

4.2 구현 방식

Log-based: Postgres WAL, MySQL binlog — 가장 효율적
Trigger-based: DB 트리거로 변경 이벤트 생성 — DB 부하 큼
Query-based: updated_at 컬럼 기반 polling — 쉽지만 삭제 못잡음

4.3 도구

Debezium (OSS): Postgres/MySQL/SQL Server/Oracle/Mongo → Kafka
Fivetran, Airbyte: 관리형 ELT, 수백 개 소스 커넥터
Striim, HVR: 엔터프라이즈 CDC
Flink CDC: Debezium 위에 Flink 통합

4.4 CDC → Iceberg 패턴

Postgres → Debezium → Kafka → Flink → Iceberg

Kafka에서 이벤트 보관 → 재처리 가능
Flink가 MERGE INTO로 Iceberg에 upsert
Iceberg v2/v3 row-level delete 활용

4.5 실무 함정

Schema change 처리(컬럼 추가·삭제·타입 변경)
초기 스냅샷 + 증분(Incremental snapshot)의 조화
Exactly-once 보장(중복·누락 모두 방지)
백필·재처리 전략

5장 · Iceberg v3와 실시간 Upsert

5.1 Iceberg 버전 히스토리

v1: Append-only
v2: Row-level delete(position/equality), MERGE INTO
v3 (2024–2025): Deletion vectors, row lineage, V3 partition transforms

5.2 Row-level delete 방식 2가지

Position delete: 행의 파일·위치를 가리키는 삭제 파일
Equality delete: 조건 기반 삭제(UPDATE 구현에 유용)

5.3 실시간 Upsert 워크플로우

Flink가 CDC 이벤트를 읽음
PK 기반으로 Equality delete + insert 생성
Iceberg가 스냅샷에 반영
주기적 compaction으로 delete 파일 정리

5.4 성능 주의

Delete 파일이 쌓이면 읽기 성능 저하
Compaction 주기 중요(분–시간 단위)
Copy-on-Write로 변환하는 백그라운드 job 병행 권장

6장 · Streaming SQL의 부상

6.1 왜 SQL인가

Flink Java API는 배우기 힘듦
데이터 엔지니어 + 분석가가 같이 다룰 수 있는 공통 언어
dbt·Dagster 같은 도구와 통합 쉬움

6.2 Flink SQL

2023–2024 안정화
이벤트 시간·윈도우·상태 모두 SQL로
UDF·UDAF 가능

6.3 ksqlDB

Kafka 위 Streaming SQL
Table과 Stream 개념 명확
단순 ETL·집계에 적합

6.4 RisingWave의 Postgres 호환

CREATE MATERIALIZED VIEW → 실시간 유지
Postgres 도구(Grafana, Superset 등) 그대로 사용
운영 복잡도가 낮음 → 2025년 급성장

6.5 Materialize

Incremental View Maintenance (IVM) 연구 기반
복잡 조인도 자동 최신화
SaaS + 셀프호스트 옵션

7장 · 비용·지연 트레이드오프

7.1 비용 구성

컴퓨트(스트리밍 클러스터 24/7)
상태 저장(RocksDB/S3)
Kafka/MSK 운영
네트워크(리전 간)

7.2 대표 비용 비교 (월, 중간 규모 기준)

옵션	월 비용	지연
배치(Airflow + Spark, 일간)	낮음($1–5k)	24시간
Micro-batch(5분)	중($3–10k)	5분
Structured Streaming	중–상 ($5–20k)	초–분
Flink 클러스터	상 ($10–30k+)	ms–초
Managed(RisingWave/Confluent)	중–상 ($7–25k)	초

7.3 절감 기법

실시간 층을 얇게(핵심 지표만)
Near-real-time 층으로 대체 가능한지 검토
비수기 스케일다운
상태는 S3(RisingWave식) vs 로컬 RocksDB(Flink) 트레이드오프

7.4 지연 타깃별 권장 아키텍처

100ms 미만: In-memory stream processor + Redis/RocksDB
초 단위: Flink/RisingWave + Kafka
분 단위: Spark Structured Streaming + Delta/Iceberg
시간 단위: Micro-batch Airflow + dbt
일 단위: Batch Spark

8장 · 관측성과 디버깅

8.1 핵심 지표

End-to-end latency(이벤트 발생 → 결과 반영)
Lag(Kafka consumer lag, Flink checkpoint lag)
Throughput(eps, rps)
Back-pressure(Flink task별)
상태 크기(RocksDB size, checkpoint size)

8.2 관측 도구

Flink UI + Prometheus + Grafana
Kafka Lag Exporter, Burrow, Conduktor
OpenLineage로 스트리밍 파이프라인 계보
Datadog/NewRelic APM + 스트리밍 extensions

8.3 디버깅

체크포인트·세이브포인트 기반 재처리
CEP(Complex Event Processing) 룰 디버깅
샘플링 로그로 이벤트 추적
테스트는 MiniCluster + embedded Kafka

8.4 경보

Lag > 임계치 → Slack/PagerDuty
End-to-end 지연 SLO 위반
체크포인트 실패 연속 발생

9장 · 장애·복구·SLA

9.1 SLA 설계

Availability: 99.9% = 월 43분 다운 허용
Freshness: 이벤트 발생 후 X초 내 쿼리 가능
Correctness: 최종적 정확성(eventual) vs exactly-once

9.2 복구 전략

Flink: 체크포인트(정기), 세이브포인트(수동)
Kafka: Replication factor 3, min.insync.replicas 2
Iceberg: 스냅샷 + 브랜치로 롤백

9.3 재처리

Kafka retention을 재처리 기간만큼 확보(7–30일 흔함)
또는 Iceberg 원본 → 스트리밍 job 재실행
재처리 중 중복 방지(멱등성 설계)

9.4 Multi-region

Kafka MirrorMaker 2 / Confluent Cluster Linking
Iceberg는 스토리지 복제(S3 Cross-region)
스트리밍 잡은 Active-Passive가 일반적

10장 · 스트리밍 + Lakehouse 실전 패턴

10.1 Medallion 위 스트리밍

Bronze: 원본 이벤트 append
Silver: 정제·중복 제거·조인 upsert
Gold: 집계·지표

10.2 CDC → Silver

DB 변경 이벤트 → Flink → Iceberg Silver upsert
Silver는 운영 DB의 "복사본 + 과거" 역할
Gold는 dbt/Spark 배치로 생성

10.3 이벤트 소싱

도메인 이벤트를 Kafka에 영구 보관
상태는 이벤트 재생으로 재구성
Iceberg Bronze에 장기 보관

10.4 실시간 Feature Store

Feast/Tecton + Kafka + Iceberg
Online feature(Redis) + Offline feature(Iceberg)
Online-offline skew 모니터링

10.5 Streaming ETL 파이프라인

소스 → Bronze(append) → Silver(정제) → Gold(집계)
각 단계 Flink/Spark SS 잡으로 구현
재처리는 업스트림 offset만 리셋

11장 · 실전 케이스 3

11.1 이커머스 주문 파이프라인

주문 이벤트 Kafka → Flink → 재고 업데이트 + 이상탐지 + 분석
재고: 초 단위 실시간
매출 지표: 5분 near-real-time
월간 리포트: Daily batch

11.2 금융 거래 모니터링

거래 이벤트 Kafka → Flink CEP → Fraud score
지연 100ms 미만 요구
상태: 사용자별 거래 히스토리(Flink keyed state)
결과: Redis + Iceberg 저장

11.3 게임 텔레메트리

클라이언트 이벤트 Kinesis/Kafka → Flink/Spark SS
실시간 분석(동시접속자·DAU)은 Near-real-time
상세 로그는 Iceberg Bronze에 쌓아 나중에 분석
A/B 테스트: Gold 집계

12장 · 한국 기업의 스트리밍

12.1 전통적 패턴

금융: Tibco EMS, IBM MQ, Kafka 혼재
통신: Charging/Billing에 실시간 스트리밍
게임: Kafka + Flink 또는 Kafka Streams
커머스: Kafka + Spark SS + ELK

12.2 최신 동향

Confluent Cloud / MSK 도입 증가
Flink 채택 확대(특히 토스·쿠팡·네이버·카카오)
RisingWave·Materialize는 2024–2025 도입 초기

12.3 규제 고려

금융: 망분리 환경에서 자체 Kafka 클러스터
개인정보: CDC 이벤트의 PII 마스킹 필수
감사 로그: 장기 보관·불변성

12.4 난관

데이터 엔지니어 인력 부족 → 관리형 선호 증가
레거시 DW와 공존
24/7 온콜 문화 정착 중

13장 · 안티패턴 10선

13.1 "모든 걸 실시간"

필요 없는 테이블까지 스트리밍 → 비용·복잡도 폭증.

13.2 Exactly-once 맹신

소스·싱크 양쪽에서 E2E exactly-once 보장이 쉽지 않음. 멱등 설계 필수.

13.3 CDC 초기 스냅샷 생략

누락 발생, 정확성 저하.

13.4 스키마 변경 자동 전파 없음

다운스트림 파이프라인 깨짐.

13.5 Kafka retention 너무 짧음

재처리 불가능.

13.6 체크포인트 주기 너무 김

장애 시 복구 비용·재처리량 폭증.

13.7 상태 무제한 보관

Flink keyed state 무한 증가 → OOM.

13.8 Delete 파일 compaction 없음

Iceberg 읽기 성능 저하.

13.9 메모리·CPU 과소할당

Back-pressure 연쇄.

13.10 관측성·경보 부재

사고를 고객이 먼저 발견.

14장 · 체크리스트 — 스트리밍 런칭 전 12가지

15장 · 다음 글 예고 — Season 5 Ep 3: "OLAP 엔진 2025 비교"

스트리밍과 배치가 저장소를 공유하게 됐다면, 다음 질문은 "그 위에서 누가 가장 빠르게 쿼리하나?".

DuckDB: 단일 노드 OLAP의 혁명
ClickHouse: 실시간 OLAP 표준
Snowflake / BigQuery / Redshift: 관리형 거인들
Databricks SQL / StarRocks / Doris / Pinot / Druid
Trino / Presto의 연합 쿼리
실제 벤치마크의 함정
비용 vs 지연 vs 관리 부담
MPP vs 단일 노드의 경계
한국 기업 선택 가이드
"적재적소" 엔진 배치 패턴

**"하나의 엔진이 모든 걸 하진 못한다"**는 2025년의 현실을 인정한 뒤가 진짜 재미있다.

다음 글에서 만나자.

요약: 2025년 스트리밍은 "모두 실시간"에서 **"SLA 기반 신선도 계층"**으로 재정의됐다. Real-time / Near-real-time / Fresh / Daily / Historical 5계층에 맞춰 Flink·Spark SS·RisingWave·Materialize·ksqlDB를 배치하고, CDC로 운영 DB의 변화를 Lakehouse로 흘리고, Iceberg v3의 row-level delete로 실시간 upsert를 처리한다. **Lambda/Kappa 대신 "Unified on Lakehouse"**가 지배 패턴이며, 비용·지연·복잡도의 트레이드오프를 의식적으로 설계한다. "실시간이 기본이 아니라 옵션" — 이것이 2025년의 실용주의다.