핵심 인사이트 (3줄 요약)
- 본질: Kafka는 재생 가능한 분산 이벤트 로그를, Flink는 상태 기반 이벤트 시간(Event Time) 처리 엔진을 제공하여 실시간 데이터 흐름을 계산 가능한 시간 모델로 바꾼다.
- 가치: Watermark는 "어느 시점까지의 이벤트가 거의 다 도착했는가"를 표현해, 네트워크 지연과 순서 뒤바뀜이 있어도 Time Window 집계를 일관되게 닫을 수 있게 한다.
- 판단 포인트: 허용 지연, 윈도우 종류, 키 분산, Exactly-Once 보장 수준을 어떻게 잡느냐가 지연시간·정확도·상태 크기의 균형을 결정한다.
Ⅰ. 개요 및 필요성
Kafka + Flink 조합은 "이벤트를 잃지 않고 모으는 계층"과 "그 이벤트를 시간 기준으로 계산하는 계층"을 분리해 실시간 분석과 의사결정을 가능하게 만든다. 클릭 로그, 결제 이벤트, 센서 데이터, 온라인 피처(Feature) 생성처럼 수집은 끊기지 않고 들어오지만 결과는 분·초 단위로 바로 필요할 때 특히 강력하다. 이때 Kafka는 입력을 순서 있는 로그로 보존하고, Flink는 그 로그를 다시 읽어 상태 기반 계산과 재처리를 수행한다.
배치 처리만으로는 이런 요구를 만족하기 어렵다. 하루 뒤 집계로는 이상 거래를 막기 늦고, 몇 분 전 행동으로는 세션 기반 추천이 이미 식어 버릴 수 있다. 반대로 처리 시간(Processing Time)만 믿고 즉시 집계하면 모바일 네트워크 지연이나 파티션 재균형 때문에 늦게 도착한 이벤트가 잘못된 창에 들어가 결과가 흔들린다.
아래 구조는 Kafka가 "이벤트를 보존"하고 Flink가 "시간 의미를 계산"하는 역할을 각각 맡는다는 점을 보여준다. 실시간 파이프라인의 핵심은 빠르게 읽는 것보다, 시간이 뒤엉킨 이벤트를 비즈니스적으로 올바른 결과로 정리하는 데 있다.
┌──────────────────────────────────────────────────────────────┐
│ Kafka + Flink 실시간 파이프라인 │
├──────────────────────────────────────────────────────────────┤
│ App / Sensor / Event Source │
│ │ │
│ ▼ │
│ Kafka Topic (Partitioned Log) │
│ │ │
│ ▼ │
│ Flink Source ─▶ keyBy ─▶ Watermark ─▶ Window / State │
│ │ │
│ ├─▶ Alert / Online Feature │
│ └─▶ Lake / Warehouse Sink │
└──────────────────────────────────────────────────────────────┘
특히 Machine Learning (ML) 파이프라인에서는 이벤트가 언제 처리되었는지보다 "언제 발생했는지"가 더 중요하다. 사용자 클릭이 늦게 도착하더라도 실제 발생 시각 기준으로 세션, 구매 전환, 실시간 피처를 계산해야 모델 입력과 사후 분석이 일치하기 때문이다. 그래서 Kafka + Flink에서 Watermark와 Window는 단순 API가 아니라 시간 정의 자체라고 볼 수 있다.
- 📢 섹션 요약 비유: Kafka는 우편물을 잃지 않고 쌓아 두는 우체국 창고이고, Flink는 도착 순서가 뒤죽박죽이어도 실제 발송 시간 순서로 다시 정리하는 분류 기계와 같다.
Ⅱ. 아키텍처 및 핵심 원리
Kafka + Flink의 핵심은 파티션별로 흘러오는 이벤트에 타임스탬프를 부여하고, Watermark로 시간 진행 정도를 추정하며, Window 안에 상태를 모았다가 적절한 시점에 결과를 내보내는 것이다. 여기서 Kafka는 순서 보장 단위를 파티션으로 나누고, Flink는 각 파티션을 병렬 태스크가 읽으면서 키별 상태와 체크포인트를 관리한다.
| 구성 요소 | 역할 | 실무 포인트 |
|---|---|---|
| Kafka Topic / Partition | 이벤트 보존, 병렬 처리 단위 제공 | 파티션 수가 처리 병렬성과 재처리 속도에 영향 |
| Timestamp Assigner | 이벤트 발생 시각 부여 | 소스 시스템 시계를 신뢰할 수 있는지 확인 필요 |
| Watermark Strategy | 시간 진행 하한선 계산 | 허용 지연과 유휴 파티션 감지가 중요 |
| Window Operator | 일정 시간 구간별 상태 집계 | 창 크기와 상태 크기가 함께 증가 |
| Checkpointed Sink | 장애 시 중복/손실 제어 | 정확한 결과가 필요하면 트랜잭션 싱크 고려 |
Watermark의 핵심 수식은 보통 watermark = 지금까지 본 최대 event time - 허용 지연이다. 그러나 병렬 처리에서는 이 Watermark가 파티션마다 따로 계산된 뒤, 전체 연산자는 보통 "활성 입력 중 최소 Watermark"를 사용한다. 즉 빠른 파티션 하나가 아니라 가장 늦은 파티션이 창 종료를 결정한다.
┌──────────────────────────────────────────────────────────────┐
│ 파티션별 Watermark가 하나로 합쳐지는 방식 │
├──────────────────────────────────────────────────────────────┤
│ 허용 지연 = 1분 │
│ │
│ Partition A : 10:00 ─ 10:02 ─ 10:05 WM_A = 10:04 │
│ Partition B : 10:01 ─ 10:03 ─ 10:04 WM_B = 10:03 │
│ │
│ Global Watermark = min(WM_A, WM_B) = 10:03 │
│ Window [10:00, 10:03) 는 Global Watermark > 10:03일 때 종료 │
└──────────────────────────────────────────────────────────────┘
이 구조 때문에 유휴 파티션(Idleness)을 처리하지 않으면 전체 Watermark가 멈출 수 있다. 예를 들어 한 파티션은 더 이상 이벤트가 없는데 "아직 늦은 데이터가 올지도 모른다"고 간주되면, 다른 파티션이 아무리 앞으로 나아가도 창이 닫히지 않는다. 실무에서 Watermark가 느리다고 느껴질 때는 대개 계산식보다 파티션 편차와 유휴 입력 처리가 원인이다.
윈도우는 Watermark와 함께 작동하는 상태 컨테이너다. 비중첩 집계에는 Tumbling Window, 이동 평균에는 Sliding Window, 사용자 활동 구간 분석에는 Session Window가 잘 맞는다. 중요한 것은 윈도우가 단순한 그룹 함수가 아니라 "언제까지 기다리고, 언제 결과를 닫을지"를 포함한 시간 정책이라는 점이다.
| Window 종류 | 특징 | 잘 맞는 사례 |
|---|---|---|
| Tumbling Window | 고정 길이, 서로 겹치지 않음 | 1분 거래 건수, 분당 오류율 |
| Sliding Window | 고정 길이, 주기적으로 겹침 | 최근 5분 이동 평균, 이상 탐지 |
| Session Window | 활동 공백으로 닫힘 | 사용자 세션 분석, 기기 활동 구간 |
즉 Kafka + Flink의 핵심 원리는 "로그를 읽는 것"이 아니라 "시간의 불완전성을 정책으로 통제하는 것"이다. Watermark, Window, State, Checkpoint가 함께 맞물려야 실시간 파이프라인이 빠르면서도 재현 가능한 결과를 낸다.
- 📢 섹션 요약 비유: Watermark는 시험 답안 마감 시각과 같다. 조금 늦게 들어오는 학생은 받아 주되, 영원히 기다릴 수는 없으니 어느 순간 "이제 채점 시작"을 선언해야 한다.
Ⅲ. 비교 및 연결
Kafka + Flink를 제대로 이해하려면 시간 기준과 엔진 역할의 경계를 함께 봐야 한다. 먼저 Processing Time은 가장 단순하지만 입력 지연이 결과를 바꿀 수 있고, Event Time + Watermark는 더 복잡하지만 실제 비즈니스 시점을 기준으로 재현 가능한 결과를 제공한다. 특히 모바일, 글로벌 네트워크, 사물인터넷(Internet of Things, IoT)처럼 지연 편차가 큰 환경에서는 이 차이가 직접적인 품질 차이로 이어진다.
| 시간 기준 | 장점 | 약점 | 잘 맞는 경우 |
|---|---|---|---|
| Processing Time | 구현 단순, 지연 최소 | 늦은 데이터에 취약, 재현성 약함 | 내부 운영 지표, 극저복잡 집계 |
| Event Time + Watermark | 정확한 시간 의미, 재처리 일관성 | 상태·설계 복잡도 증가 | 결제, 사용자 세션, ML 피처 생성 |
엔진 관점에서도 역할이 다르다. Kafka는 로그 저장과 전송의 중심이고, Kafka Streams는 애플리케이션 안에서 비교적 가벼운 스트림 처리를 수행한다. 반면 Flink는 큰 상태, 복잡한 조인, 정교한 Event Time 제어, Exactly-Once 복구가 필요한 분산 처리에 더 적합하다.
| 기술 | 주 역할 | 강점 | 한계 |
|---|---|---|---|
| Kafka | 이벤트 로그 / 버퍼 | 재생 가능, 파티션 확장성 | 자체적으로 윈도우·상태 계산은 제한적 |
| Kafka Streams | 애플리케이션 내 스트림 처리 | 단순 배포, 로컬 상태 | 대규모 분산 상태·복잡 조인 한계 |
| Flink | 분산 상태ful 스트림 처리 | Event Time, 대규모 상태, 정교한 복구 | 운영 복잡도 높음 |
이 조합은 Machine Learning Operations (MLOps)와도 연결된다. 같은 Kafka 로그를 재생하면 온라인 피처 계산 로직을 과거 데이터에 다시 적용해 검증할 수 있고, Feature Store나 레이크하우스와 연결해 오프라인 학습 데이터와 실시간 추론 입력의 의미 차이를 줄일 수 있다. 즉 Watermark와 Window는 단순 스트리밍 기술이 아니라, 온라인·오프라인 데이터 일관성을 지키는 장치이기도 하다.
- 📢 섹션 요약 비유: Processing Time은 버스 정류장 시계만 보고 출발하는 방식이고, Event Time + Watermark는 승객이 실제 언제 도착했는지까지 반영해 노선을 기록하는 방식과 같다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서는 Window와 Watermark를 "정답 공식"으로 잡는 것이 아니라, 비즈니스 손실과 운영 비용의 균형으로 결정해야 한다. 허용 지연을 길게 잡으면 정확도는 올라가지만 상태가 오래 남아 메모리와 체크포인트 비용이 커진다. 반대로 너무 짧게 잡으면 결과는 빨리 나오지만 늦은 데이터가 많아 보정 로직이나 재처리 비용이 증가한다.
| 시나리오 | 권장 설계 | 이유 |
|---|---|---|
| 실시간 대시보드 | 1분 Tumbling Window + 짧은 허용 지연 | 빠른 가시성이 우선, 소폭 오차 허용 가능 |
| 결제/정산 집계 | Event Time + Exactly-Once Sink + 보정 경로 | 중복·누락 비용이 매우 큼 |
| 모바일 세션 분석 | Session Window + 비교적 긴 허용 지연 | 네트워크 지연과 앱 백그라운드 복귀 고려 |
| IoT 센서 모니터링 | Event Time + 유휴 파티션 감지 + 큰 상태 관리 | 연결 불안정과 파티션 편차가 흔함 |
늦은 데이터 처리 정책도 미리 정해야 한다. 허용 지연 안에 들어오면 기존 결과를 업데이트하고, 조금 더 늦은 데이터는 사이드 출력으로 보내 보정 배치에 합류시키며, 매우 늦은 데이터는 감사 로그만 남기고 버리는 방식이 흔하다. 이 정책을 명시하지 않으면 운영 중 "왜 숫자가 뒤늦게 바뀌었는가"라는 갈등이 반복된다.
┌──────────────────────────────────────────────────────────────┐
│ 늦은 데이터 처리 경로 │
├──────────────────────────────────────────────────────────────┤
│ Late Event │
│ │ │
│ ├─ 허용 지연 이내 ─▶ Window 재계산 / 결과 갱신 │
│ ├─ 약간 초과 ─▶ Side Output → 보정 파이프라인 │
│ └─ 크게 초과 ─▶ Drop / Audit Log │
└──────────────────────────────────────────────────────────────┘
체크리스트는 다음과 같다.
- 이벤트 타임스탬프가 신뢰 가능한 소스에서 오는가?
- 파티션 키가 특정 고객·디바이스에 치우쳐 상태 편중을 만들지 않는가?
- Watermark 지연의 원인이 허용 지연인지, 유휴 파티션인지, 백프레셔인지 구분되고 있는가?
- 결과 업데이트를 허용할지, 한 번 출력 후 보정 배치로 돌릴지 정책이 정해져 있는가?
- 체크포인트 간격과 Kafka 트랜잭션 시간 제한이 서로 맞는가?
흔한 안티패턴은 Processing Time으로 시작한 뒤, 늦은 데이터가 쌓이자 나중에 수작업 보정을 붙이는 것이다. 또 허용 지연을 과도하게 길게 잡아 상태가 폭증하거나, 한 개의 Hot Key 때문에 특정 태스크만 느려지는 경우도 많다. 기술사 답안에서는 Watermark 정의, Window 종류, Exactly-Once 보장, Late Data 처리까지 한 묶음으로 설명해야 실제 설계 역량이 드러난다.
- 📢 섹션 요약 비유: 실무의 Watermark 설계는 버스를 몇 분까지 기다릴지 정하는 운행 정책과 같다. 너무 오래 기다리면 전체 노선이 밀리고, 너무 빨리 떠나면 승객을 잃는다.
Ⅴ. 기대효과 및 결론
Kafka + Flink 기반 Event Time 처리는 순서가 뒤엉킨 현실 세계의 이벤트를 재현 가능한 숫자로 바꿔 준다. 같은 Kafka 로그를 다시 읽어도 비슷한 Window 결과를 재구성할 수 있고, 실시간 경보와 피처 계산을 배치 재처리와 같은 의미 체계 위에 둘 수 있다. 이는 실시간 분석뿐 아니라 모델 검증, 사후 정산, 장애 복구에도 큰 장점이다.
하지만 이 접근이 공짜는 아니다. 상태 저장소 크기, 체크포인트 비용, Key Skew, 잘못된 타임스탬프, 복잡한 Sink 일관성 문제가 함께 따라온다. 특히 Watermark는 "정확한 진실"이 아니라 "이 정도 늦음까지는 기다리겠다"는 운영 합의이므로, 비즈니스 부서와 데이터 엔지니어가 같은 기준을 공유해야 한다.
결론적으로 기억할 핵심은 단순하다. Kafka가 이벤트를 잃지 않게 해 주고, Flink가 시간을 계산 가능하게 만든다. 그리고 Window와 Watermark는 그 사이에서 "언제 결과를 확정할 것인가"를 정하는 계약이다. 이 계약을 잘 설계할수록 실시간 파이프라인은 빠르면서도 신뢰할 수 있게 된다.
- 📢 섹션 요약 비유: Kafka + Flink는 택배를 모아 두는 창고와 배송 시간을 계산하는 관제실이 함께 움직이는 구조와 같다. 창고만 있어도, 관제실만 있어도 부족하고 둘이 맞물려야 정확한 배송 일정이 나온다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| Kafka Topic / Partition | 이벤트 로그 보존과 병렬성의 기본 단위 |
| Event Time | 실제 비즈니스 발생 시각을 기준으로 계산하는 시간 모델 |
| Watermark | 시간 진행 하한선을 표현해 Window 종료 시점을 정하는 정책 |
| Time Window | 일정 구간의 이벤트를 상태로 모아 집계·조인하는 연산 단위 |
| Checkpoint | 장애 후 상태와 오프셋을 복구해 일관성을 유지하는 장치 |
| State Backend | 키별 상태를 메모리 또는 디스크에 저장하는 계층 |
| Exactly-Once | 재처리 시 중복·누락 없이 결과를 내기 위한 보장 수준 |
📈 관련 키워드 및 발전 흐름도
이벤트 발생
│
▼
Kafka Append Log
│
▼
Timestamp Assign / Watermark 계산
│
▼
Keyed Window State
│
├─▶ 실시간 결과 출력
└─▶ Replay / Backfill 검증
이 흐름은 로그 저장, 시간 진행 추정, 상태 기반 집계, 재처리 가능성이 하나의 파이프라인으로 연결되는 구조를 보여준다.
👶 어린이를 위한 3줄 비유 설명
- Kafka는 편지를 잃어버리지 않게 순서대로 쌓아 두는 큰 우체통이에요.
- Flink는 조금 늦게 온 편지도 원래 보낸 시간대로 다시 정리해 주는 똑똑한 분류기예요.
- Watermark는 "이제 이 시간까지 온 편지는 거의 다 모였어"라고 알려 주는 마감선이에요.