같은 데이터라도 "언제, 얼마씩" 처리하느냐에 따라 시스템 설계가 완전히 달라진다. 매일 밤 하루치 주문을 모아 정산 리포트를 만드는 것과, 결제가 일어나는 순간 이상거래를 잡아내는 것은 같은 결제 데이터를 다루지만 전혀 다른 기계가 필요하다. 전자가 배치(batch), 후자가 **스트리밍(streaming)**이다.
오늘은 이 두 처리 패러다임의 본질, 각각이 적합한 사례, 그리고 둘을 가르는 핵심 트레이드오프인 지연(latency)과 처리량(throughput)을 본다. 데이터 엔지니어가 새 파이프라인을 설계할 때 가장 먼저 내리는 판단이 "이건 배치인가 스트림인가"다.
차이는 데이터를 묶음으로 처리하느냐, 도착하는 대로 처리하느냐다.
배치 (Batch)
[····· 모은다 ·····] → 한 번에 처리 → 결과
경계가 있는(bounded) 데이터, 정해진 주기로 실행
스트리밍 (Streaming)
→ 도착 → 처리 → 도착 → 처리 → 도착 → 처리 →
경계가 없는(unbounded) 데이터, 끊임없이 흐름
배치는 "지난 한 시간/하루 동안 쌓인 것"이라는 유한한 묶음을 다룬다. 시작과 끝이 분명하다. 스트리밍은 "지금부터 영원히 들어오는 이벤트"라는 무한한 흐름을 다룬다. 끝이 없으므로, 결과를 내려면 "최근 5분"처럼 시간 창(window)으로 흐름을 잘라야 한다.
| 구분 | 배치 | 스트리밍 |
|---|---|---|
| 데이터 | 경계 있음(bounded) | 경계 없음(unbounded) |
| 실행 | 주기적(시간/일 단위) | 연속적(상시) |
| 지연 | 분~시간 | 밀리초~초 |
| 처리량 | 매우 높음 | 건당 처리 |
| AWS 예시 | Glue, EMR, Batch | Kinesis, MSK, Flink |
💡 관련 이론: 스트리밍에서 가장 중요한 개념이 **윈도잉(windowing)**이다. 무한한 흐름에서 집계를 내려면 흐름을 시간 단위로 잘라야 한다. 텀블링 윈도우(겹치지 않는 고정 구간), 슬라이딩 윈도우(겹치며 이동), 세션 윈도우(활동 간격으로 구분)가 대표적이다. 또한 "이벤트가 발생한 시각(event time)"과 "시스템이 받은 시각(processing time)"의 차이를 다루는 것이 스트리밍 설계의 핵심 난제다.
선택의 기준은 단 하나, 얼마나 신선한 결과가 필요한가다.
배치가 적합한 경우:
스트리밍이 적합한 경우:
# 배치: 하루치 로그를 모아 한 번에 집계 (Glue/Spark)
df = spark.read.parquet("s3://logs/date=2026-06-25/") # 하루치 전체
daily
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
경계가 없는(unbounded) 데이터 흐름을 다루는 스트리밍 처리에서, 무한한 흐름으로부터 집계 결과를 내기 위해 반드시 필요한 개념은?
문제 2
"매일 밤 하루치 거래를 모아 정산 리포트를 생성"하는 작업에 가장 적합한 처리 패러다임과 그 이유는?
문제 3
배치 처리가 스트리밍보다 단위 시간당 처리량(throughput)이 높은 근본적인 이유는?
문제 4
스트림 데이터를 받아 별도 소비자 코드 운영 없이 S3나 Redshift로 거의 즉시 자동 적재하길 원할 때 가장 적합한 AWS 서비스는?
문제 5
배치 레이어(정확하지만 느림)와 스피드 레이어(빠르지만 근사)를 함께 운영해 지연과 정확성의 트레이드오프를 푸는 고전적 아키텍처는?
핵심은 **"실시간이 비싸다"**는 점이다. 스트리밍은 상시 가동되는 인프라와 더 복잡한 운영을 요구한다. 그래서 "정말 실시간이 필요한가, 5분 늦어도 되는가"를 따지는 것이 비용 최적화의 출발점이다. 막연히 "최신 데이터가 좋으니 다 스트리밍"으로 가면 비용과 복잡도가 폭증한다.
💡 관련 이론: 마이크로배치(micro-batch)는 둘의 중간 지점이다. Spark Structured Streaming처럼 아주 짧은 주기(수 초)로 작은 배치를 반복 실행해 "준실시간"을 만든다. 진짜 이벤트 단위 스트리밍보다 운영이 단순하면서 초 단위 지연을 달성하므로, 많은 현실 파이프라인이 이 절충안을 택한다.
배치와 스트리밍의 차이를 정량적으로 가르는 두 지표다.
배치 : 지연 높음 ↑ 처리량 매우 높음 ↑↑↑
스트림 : 지연 낮음 ↓ 건당 처리 → 누적 처리량은 낮음
배치는 데이터를 모아 한 번에 처리하므로 건당 오버헤드가 분산되어 처리량이 압도적으로 높다. 대신 모으는 시간만큼 지연이 생긴다. 스트리밍은 이벤트가 오는 즉시 처리하므로 지연이 매우 낮지만, 건마다 처리·전달 비용이 들어 같은 인프라로 낼 수 있는 누적 처리량은 배치보다 낮다.
여기에 **정확성(correctness)**이라는 축이 더해진다. 스트리밍은 늦게 도착하는 데이터(late-arriving data)나 순서가 뒤섞인 이벤트를 다뤄야 하므로, "정확한 최종 결과"와 "빠른 근사 결과" 사이에서 타협해야 한다. 배치는 모든 데이터가 도착한 뒤 처리하므로 이 문제에서 자유롭다.
정확성 ↑
│
배치 ● │
│ ● 마이크로배치
│
│ ● 스트리밍
└──────────────────→ 신선도(낮은 지연) ↑
💡 관련 이론: 이 트레이드오프를 아키텍처 수준에서 푼 고전이 **람다 아키텍처(Lambda Architecture)**다. 배치 레이어(정확하지만 느림)와 스피드 레이어(빠르지만 근사)를 동시에 돌려 서빙 레이어에서 합친다. 코드를 두 벌 유지해야 하는 부담 때문에, 스트리밍 엔진 하나로 배치까지 처리하는 **카파 아키텍처(Kappa Architecture)**가 대안으로 등장했다. AWS에서는 Kinesis/MSK + Flink 조합이 카파에 해당한다.
시험에서 자주 묻는 "이 시나리오에 어떤 서비스를 쓸 것인가"의 기준선이다.
| 패러다임 | 수집 | 처리 | 대표 시나리오 |
|---|---|---|---|
| 배치 | S3 적재, DataSync | Glue, EMR, AWS Batch | 일일 리포트, 대용량 ETL |
| 스트리밍 | Kinesis Data Streams, MSK | KDA(Flink), Lambda | 실시간 탐지, 라이브 대시보드 |
| 준실시간 | Kinesis Data Firehose | Firehose 변환, Lambda | 로그를 S3/Redshift로 거의 즉시 적재 |
특히 헷갈리기 쉬운 둘을 구분해두자. Kinesis Data Streams는 낮은 지연과 다중 소비자가 필요한 진짜 스트리밍용이고, Kinesis Data Firehose는 스트림을 받아 S3·Redshift 등으로 자동 적재하는 "관리형 준실시간 배달부"다. 직접 코드로 소비자를 운영할 필요 없이 목적지에 떨궈주길 원하면 Firehose다.
오늘 잡은 판단 기준은 세 가지다. 첫째, 배치는 경계 있는 데이터를 주기적으로, 스트리밍은 경계 없는 흐름을 연속적으로 처리한다. 둘째, 선택 기준은 "얼마나 신선한 결과가 필요한가"이며, 실시간은 비싸므로 막연히 스트리밍으로 가면 안 된다. 셋째, 배치는 처리량·정확성에 강하고, 스트리밍은 낮은 지연에 강하다 — 마이크로배치가 그 절충안이다.
다음 글에서는 이 처리 패러다임들을 실제로 구현하는 AWS 데이터 서비스 전체 지도를 수집·저장·처리·분석·거버넌스 카테고리로 펼쳐본다.