배치와 스트리밍 — 무엇을 기준으로 고르는가

한 줄 요약

배치는 경계가 분명한 데이터 묶음을 주기적으로 처리하고 스트리밍은 끝없이 도착하는 이벤트를 계속 처리하며, 둘의 진짜 차이는 속도가 아니라 경계를 누가 정하는가다.

왜 이게 필요했나

"실시간이 좋으니 스트리밍으로 하자"는 결정이 자주 내려지고, 그 대가는 대개 6개월 뒤에 청구된다. 배치는 실패하면 다시 돌리면 되지만, 스트리밍은 상태를 들고 계속 도는 시스템이라 재처리 설계가 훨씬 어렵다.

어떻게 동작하나

배치의 핵심 장치는 워터마크다. 어디까지 처리했는지를 저장해 두고 다음 실행에서 그 이후만 가져온다.

SELECT * FROM ordersWHERE ordered_at > (SELECT last_ordered_at FROM etl_watermark WHERE job_name = 'orders_archive')  AND ordered_at < :batch_end;

이 단순한 패턴에 함정이 여러 개 숨어 있다.

경계값 포함 여부. > 와 >= 를 헷갈리면 매 실행마다 한 건이 중복되거나 누락된다.
동일 타임스탬프. 같은 시각에 여러 행이 들어오면 > 만으로는 일부가 영원히 누락된다. 시각과 기본 키를 함께 비교하거나, 워터마크를 조금 뒤로 물려 두고 중복을 upsert 로 흡수하는 편이 안전하다.
늦게 도착하는 데이터. 원천이 트랜잭션을 늦게 커밋하면 워터마크보다 과거 시각의 행이 나중에 나타난다. 이 경우 시간 기준 워터마크는 그 행을 영원히 놓친다.

스트리밍에서는 이 문제가 더 노골적이다. 이벤트 시각과 처리 시각이 다르므로 "지금 이 창을 닫아도 되는가"를 판단해야 하고, 그래서 워터마크가 지연 허용치와 함께 정의된다. 그리고 늦게 온 이벤트를 버릴지 창을 다시 열지 정책으로 정해야 한다.

전달 보장도 세 종류로 갈린다. 최대 한 번(잃을 수 있음), 최소 한 번(중복될 수 있음), 정확히 한 번이다. 실제 시스템 대부분은 최소 한 번을 제공하고, 중복을 소비 쪽에서 흡수해 결과적으로 한 번처럼 만드는 방식을 택한다. 그래서 다음 모듈의 멱등성이 중요해진다.

현장에서 만나는 모습

배치가 스트리밍보다 나은 상황이 생각보다 많다. 원천이 하루 한 번 갱신되는데 파이프라인만 실시간이면 아무 가치가 없다. 리포트를 보는 사람이 아침에 한 번 본다면 새벽 배치로 충분하다. 소비자가 실제로 얼마나 자주 보는가가 첫 질문이 되어야 한다.

반대로 배치의 대가도 분명하다. 주기가 길수록 한 번 실패했을 때의 지연이 커지고, 한 번에 처리하는 양이 커서 자원 사용이 뾰족해진다. 그래서 큰 배치를 잘게 쪼개 청크로 처리하는 방식이 흔히 쓰인다. 실패한 청크만 다시 돌릴 수 있고 잠금 시간도 짧아진다.

다음 실습에서 할 것

주문 데이터를 CSV 로 추출해 아카이브 표에 적재하고, 워터마크를 기록해 증분 적재를 돌린 뒤, 같은 작업을 두 번 실행해도 결과가 변하지 않는지 확인한다.