원문: Streaming vs Batch: Two Philosophies of Data Processing 발신: ByteByteGo 수신일: 2026-07-10
데이터를 처리하는 모든 시스템은 결국 하나의 질문에 답해야 합니다. 데이터가 컴퓨팅 단계로 넘어가기에 충분히 완료되었는가?
하루의 매출을 합산하는 프로그램은 오늘의 모든 매출이 실제로 도착했는지 알아야 합니다. 파일에 저장된 데이터의 경우, 파일에 끝이 있기 때문에 답은 간단합니다. 그러나 지속적으로 도착하며 절대 멈추지 않는 데이터의 경우, 명확한 답이 없습니다. 그 간극을 시스템이 어떻게 해결하느냐가 바로 배치 처리와 스트리밍의 차이입니다.
**배치 처리(Batch Processing)**는 완전성을 기다립니다. 자연스러운 경계, 마감 시간, 또는 완료된 파일까지 데이터를 수집한 다음 전체 집합을 한꺼번에 처리합니다.
**스트리밍(Streaming)**은 속도를 위해 완전성을 양보합니다. 아직 도착 중인 데이터에서 지속적으로 답을 생성하는데, 이는 충분한 데이터가 들어왔는지 추정해야 하며 그 추정이 틀릴 경우를 처리해야 함을 의미합니다.
완전성과 지연 시간(latency) 사이의 이 트레이드오프가 스트리밍과 배치를 다룰 때 핵심 고려 사항입니다.
이 글은 양쪽의 전략과 각각의 비용을 다룹니다:
- 배치 측: 전체 로드(full load), 증분 로드(incremental load), 대형 윈도우 집계(large-window aggregation), 그 중간에 마이크로배치(micro-batch)
- 스트리밍 측: 텀블링 윈도우(tumbling), 슬라이딩 윈도우(sliding), 세션 윈도우(session window), 워터마크(watermarks)와 늦은 데이터(late data), 람다 아키텍처(lambda)와 카파 아키텍처(kappa), 그리고 종종 오해되는 exactly-once 처리의 의미
(본 뉴스레터는 이메일 미리보기 버전으로, 전문은 구독자 전용입니다)
핵심 요약 (20줄)
- 모든 데이터 처리 시스템의 핵심 질문: 데이터가 처리 단계로 넘어갈 만큼 충분히 완료되었는가?
- 배치 처리 — 데이터의 완전성(completeness)이 확보될 때까지 기다렸다가 한꺼번에 처리
- 스트리밍 — 데이터가 계속 들어오는 중에도 지속적으로 답을 생성, 완전성 대신 속도 선택
- 파일 기반 데이터: 끝이 있으므로 완전성 판단 쉬움
- 무한 스트림 데이터: 명확한 끝이 없으므로 완전성 추정 필요
- 핵심 트레이드오프: 완전성(completeness) vs 지연시간(latency)
- 배치 전략: 전체 로드(full load) — 모든 데이터를 매번 재처리
- 배치 전략: 증분 로드(incremental load) — 변경된 데이터만 처리, 효율적
- 배치 전략: 대형 윈도우 집계 — 일/주/월 단위 집계
- 마이크로배치(micro-batch) — 배치와 스트리밍의 중간: 매우 짧은 간격으로 배치 실행
- 스트리밍 윈도우 전략 1: 텀블링 윈도우 — 고정 크기의 비겹치는 시간 구간
- 스트리밍 윈도우 전략 2: 슬라이딩 윈도우 — 겹치는 시간 구간으로 연속적 집계
- 스트리밍 윈도우 전략 3: 세션 윈도우 — 활동 간격 기반의 동적 윈도우
- 워터마크(watermark) — 스트리밍에서 "이 시점 이전 데이터는 모두 도착했다"고 선언하는 메커니즘
- 늦은 데이터(late data) — 워터마크 이후 도착하는 데이터 처리 전략 필요
- 람다 아키텍처 — 배치 레이어(정확성) + 스트리밍 레이어(속도)를 병행 운영
- 카파 아키텍처 — 스트리밍만으로 배치도 처리, 람다의 복잡성 제거
- Exactly-once 처리 — 가장 오해받는 개념: 실제로는 중복 없는 결과 보장(idempotency)
- 스트리밍은 추정과 보정의 연속 — 완벽한 정확성보다 빠른 근사치가 목표
- 시스템 설계 시 지연 허용 수준과 데이터 완전성 요구사항을 먼저 정의해야 함