쉬운 설명
배치 처리는 데이터를 한 덩어리로 모아 한꺼번에 처리합니다('매일 새벽 어제 매출을 집계한다'). 스트리밍 처리는 데이터가 들어올 때마다 그 순간에 처리합니다. 결과를 분 단위·초 단위로 즉시 받고 싶을 때 자연스러운 선택입니다.
왜 스트리밍이 필요한가 하면, 일부 결정은 미루면 가치가 떨어지기 때문입니다. 신용카드 부정 사용 의심을 한 시간 뒤에 잡아 봤자 이미 결제가 끝났습니다. 라이브 스포츠의 시청률, 주식 시세, 광고 입찰 — 모두 '즉시'가 가치의 핵심인 영역입니다.
기본 구조는 보통 두 부분입니다. ① 이벤트 버스(Kafka·Kinesis·RabbitMQ): 들어오는 이벤트를 모아 두는 통로. 발신자와 수신자가 서로 모르고도 통신할 수 있게 분리해 줍니다. ② 처리 엔진(Apache Flink·Spark Streaming·Apache Beam): 통로에서 이벤트를 읽어 그 자리에서 가공·집계·저장합니다.
스트리밍의 핵심 개념 몇 가지. ① 윈도우(window): 무한히 흘러오는 데이터에서 '최근 5분', '최근 1시간' 같은 시간 창을 잘라 집계. ② 늦은 이벤트(late events): 네트워크 지연으로 늦게 도착하는 데이터를 어떻게 다룰지. ③ 정확히 한 번(exactly-once): 같은 이벤트가 두 번 처리되지 않게 보장. 이런 일들이 배치보다 어렵게 만듭니다.
주의할 점: 스트리밍이 항상 정답은 아닙니다. 늦게 도착하는 이벤트 처리, 정확히 한 번 처리 보장, 백프레셔(처리 속도가 못 따라잡을 때)가 모두 까다롭습니다. 실시간이 진짜로 필요한 영역에서만 도입하는 게 좋습니다. 한 시간 단위 보고서면 충분한 일에 스트리밍을 들이대면 비용·복잡도가 크게 늘어납니다.
비유로 보면
배치 처리가 '하루치 우편을 모아 저녁에 한 번 분류'라면, 스트리밍은 '들어오는 우편을 직원이 그 자리에서 즉시 분류'에 가깝습니다. 즉시성을 얻는 대신 직원을 늘 대기시키는 비용을 치러야 하고, 사람이 잠시라도 자리를 비우면 우편이 쌓여 흐름이 막힙니다.
어디에서 만나나
실시간 부정 탐지(은행·결제), 시세·환율·주문 호가 처리, 광고 입찰 시스템, 실시간 추천 갱신, IoT 센서 모니터링, 라이브 스포츠·게임 통계, 로그·메트릭의 실시간 분석.
작은 예시
신용카드 부정 사용 탐지는 거래가 발생한 순간 결정해야 합니다. 결제 이벤트가 Kafka로 들어오는 즉시 스트리밍 처리 엔진이 사용자의 최근 행동·위치·금액 패턴과 비교해 '의심스러우면 차단'을 1초 안에 결정합니다.
자주 하는 오해
한 줄 정리
스트리밍의 가치는 '즉시성'에 있습니다. 즉시성이 결과 가치에 결정적일 때만 도입하는 게 정답입니다.