Day 2 - 배치 vs 스트리밍

같은 데이터라도 "언제, 얼마씩" 처리하느냐에 따라 시스템 설계가 완전히 달라진다. 매일 밤 하루치 주문을 모아 정산 리포트를 만드는 것과, 결제가 일어나는 순간 이상거래를 잡아내는 것은 같은 결제 데이터를 다루지만 전혀 다른 기계가 필요하다. 전자가 배치(batch), 후자가 **스트리밍(streaming)**이다.

오늘은 이 두 처리 패러다임의 본질, 각각이 적합한 사례, 그리고 둘을 가르는 핵심 트레이드오프인 지연(latency)과 처리량(throughput)을 본다. 데이터 엔지니어가 새 파이프라인을 설계할 때 가장 먼저 내리는 판단이 "이건 배치인가 스트림인가"다.

두 패러다임의 본질

차이는 데이터를 묶음으로 처리하느냐, 도착하는 대로 처리하느냐다.

배치 (Batch)
  [····· 모은다 ·····] → 한 번에 처리 → 결과
  경계가 있는(bounded) 데이터, 정해진 주기로 실행

스트리밍 (Streaming)
  → 도착 → 처리 → 도착 → 처리 → 도착 → 처리 →
  경계가 없는(unbounded) 데이터, 끊임없이 흐름

배치는 "지난 한 시간/하루 동안 쌓인 것"이라는 유한한 묶음을 다룬다. 시작과 끝이 분명하다. 스트리밍은 "지금부터 영원히 들어오는 이벤트"라는 무한한 흐름을 다룬다. 끝이 없으므로, 결과를 내려면 "최근 5분"처럼 시간 창(window)으로 흐름을 잘라야 한다.

💡 관련 이론: 스트리밍에서 가장 중요한 개념이 **윈도잉(windowing)**이다. 무한한 흐름에서 집계를 내려면 흐름을 시간 단위로 잘라야 한다. 텀블링 윈도우(겹치지 않는 고정 구간), 슬라이딩 윈도우(겹치며 이동), 세션 윈도우(활동 간격으로 구분)가 대표적이다. 또한 "이벤트가 발생한 시각(event time)"과 "시스템이 받은 시각(processing time)"의 차이를 다루는 것이 스트리밍 설계의 핵심 난제다.

각각 언제 쓰는가

선택의 기준은 단 하나, 얼마나 신선한 결과가 필요한가다.

배치가 적합한 경우:

• 월말 정산, 일일 매출 리포트처럼 주기가 정해진 작업
• 대용량 과거 데이터 재처리(backfill)
• 결과가 몇 분~몇 시간 늦어도 무방한 분석
• 머신러닝 모델의 대규모 학습 데이터 준비

스트리밍이 적합한 경우:

• 실시간 이상거래·사기 탐지
• 라이브 대시보드, 실시간 모니터링·알람
• IoT 센서 데이터의 즉각적 처리
• 추천·개인화처럼 사용자 행동에 즉시 반응해야 하는 경우

# 배치: 하루치 로그를 모아 한 번에 집계 (Glue/Spark)
df = spark.read.parquet("s3://logs/date=2026-06-25/")  # 하루치 전체
daily = df.groupBy("region").agg(sum("amount"))
daily.write.parquet("s3://reports/daily/2026-06-25/")
 
# 스트리밍: 5분 윈도우로 흐르는 이벤트를 집계 (Flink/KDA)
events.window(TumblingWindow.of(minutes=5)) \
      .key_by("region") \
      .aggregate(SumAggregator())  # 끝없이 5분마다 결과 방출

핵심은 **"실시간이 비싸다"**는 점이다. 스트리밍은 상시 가동되는 인프라와 더 복잡한 운영을 요구한다. 그래서 "정말 실시간이 필요한가, 5분 늦어도 되는가"를 따지는 것이 비용 최적화의 출발점이다. 막연히 "최신 데이터가 좋으니 다 스트리밍"으로 가면 비용과 복잡도가 폭증한다.

💡 관련 이론: 마이크로배치(micro-batch)는 둘의 중간 지점이다. Spark Structured Streaming처럼 아주 짧은 주기(수 초)로 작은 배치를 반복 실행해 "준실시간"을 만든다. 진짜 이벤트 단위 스트리밍보다 운영이 단순하면서 초 단위 지연을 달성하므로, 많은 현실 파이프라인이 이 절충안을 택한다.

지연과 처리량의 트레이드오프

배치와 스트리밍의 차이를 정량적으로 가르는 두 지표다.

• 지연(latency): 데이터가 발생한 뒤 결과가 나오기까지의 시간. 낮을수록 "실시간"에 가깝다.
• 처리량(throughput): 단위 시간당 처리할 수 있는 데이터의 양. 높을수록 "대용량"에 강하다.

배치    : 지연 높음 ↑   처리량 매우 높음 ↑↑↑
스트림  : 지연 낮음 ↓   건당 처리 → 누적 처리량은 낮음

배치는 데이터를 모아 한 번에 처리하므로 건당 오버헤드가 분산되어 처리량이 압도적으로 높다. 대신 모으는 시간만큼 지연이 생긴다. 스트리밍은 이벤트가 오는 즉시 처리하므로 지연이 매우 낮지만, 건마다 처리·전달 비용이 들어 같은 인프라로 낼 수 있는 누적 처리량은 배치보다 낮다.

여기에 **정확성(correctness)**이라는 축이 더해진다. 스트리밍은 늦게 도착하는 데이터(late-arriving data)나 순서가 뒤섞인 이벤트를 다뤄야 하므로, "정확한 최종 결과"와 "빠른 근사 결과" 사이에서 타협해야 한다. 배치는 모든 데이터가 도착한 뒤 처리하므로 이 문제에서 자유롭다.

        정확성 ↑
          │
   배치 ● │
          │      ● 마이크로배치
          │
          │            ● 스트리밍
          └──────────────────→ 신선도(낮은 지연) ↑

💡 관련 이론: 이 트레이드오프를 아키텍처 수준에서 푼 고전이 **람다 아키텍처(Lambda Architecture)**다. 배치 레이어(정확하지만 느림)와 스피드 레이어(빠르지만 근사)를 동시에 돌려 서빙 레이어에서 합친다. 코드를 두 벌 유지해야 하는 부담 때문에, 스트리밍 엔진 하나로 배치까지 처리하는 **카파 아키텍처(Kappa Architecture)**가 대안으로 등장했다. AWS에서는 Kinesis/MSK + Flink 조합이 카파에 해당한다.

AWS에서의 매핑

시험에서 자주 묻는 "이 시나리오에 어떤 서비스를 쓸 것인가"의 기준선이다.

특히 헷갈리기 쉬운 둘을 구분해두자. Kinesis Data Streams는 낮은 지연과 다중 소비자가 필요한 진짜 스트리밍용이고, Kinesis Data Firehose는 스트림을 받아 S3·Redshift 등으로 자동 적재하는 "관리형 준실시간 배달부"다. 직접 코드로 소비자를 운영할 필요 없이 목적지에 떨궈주길 원하면 Firehose다.

정리하며

오늘 잡은 판단 기준은 세 가지다. 첫째, 배치는 경계 있는 데이터를 주기적으로, 스트리밍은 경계 없는 흐름을 연속적으로 처리한다. 둘째, 선택 기준은 "얼마나 신선한 결과가 필요한가"이며, 실시간은 비싸므로 막연히 스트리밍으로 가면 안 된다. 셋째, 배치는 처리량·정확성에 강하고, 스트리밍은 낮은 지연에 강하다 — 마이크로배치가 그 절충안이다.

다음 글에서는 이 처리 패러다임들을 실제로 구현하는 AWS 데이터 서비스 전체 지도를 수집·저장·처리·분석·거버넌스 카테고리로 펼쳐본다.