バッチとストリーミング — 何を基準に選ぶのか

한 줄 요약

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

왜 이게 필요했나

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

어떻게 동작하나

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

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

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

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

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

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

무엇을 기준으로 고르나

"실시간이 좋다" 는 기준이 아닙니다. 네 가지를 따져 보면 대개 답이 정해집니다.

질문	배치가 맞다	스트리밍이 맞다
결과가 언제 필요한가	시간·일 단위	초·분 단위
늦게 온 데이터를 어떻게 하나	다음 배치에 자연히 포함	워터마크·재처리 설계 필요
전체를 다시 계산할 수 있나	쉽다	어렵다(상태 복원)
운영 부담	실패하면 다시 돌리면 된다	항상 떠 있어야 한다

되돌릴 수 있는가 가 가장 중요합니다. 배치는 로직을 고치고 어제 것을 다시 돌리면 끝입니다. 스트리밍에서 같은 일을 하려면 오프셋을 되감고 상태를 초기화하고 하류의 중복을 감당해야 합니다.

그래서 실무의 흔한 답은 둘 다 입니다. 스트리밍으로 빠른 근사값을 내고, 배치로 정확한 값을 나중에 덮어씁니다(람다 아키텍처). 요즘은 같은 코드로 둘 다 처리하는 쪽(카파, Flink·Beam)이 늘었지만, 운영 복잡도는 여전히 스트리밍 쪽이 큽니다.

시간에 관한 세 가지

스트리밍에서 어긋나는 것의 절반이 시간 정의입니다.

• 이벤트 시각 — 실제로 일어난 때. 분석의 기준은 언제나 이것입니다.
• 수집 시각 — 시스템에 들어온 때.
• 처리 시각 — 계산한 때. 재처리하면 달라지므로 기준으로 쓰면 안 됩니다.

모바일 앱은 비행기 모드였다가 몇 시간 뒤 이벤트를 보냅니다. 이벤트 시각으로 집계하면 이미 마감한 창(window)에 늦은 데이터가 들어옵니다. 워터마크 는 "이 시각 이전 데이터는 더 안 온다고 보겠다" 는 선언이고, 그 선을 넘어 도착한 것은 버리거나 별도 경로로 처리합니다.

워터마크 = 지금까지 본 최대 이벤트 시각 − 허용 지연(예: 10분)

허용 지연을 늘리면 정확해지지만 결과가 그만큼 늦게 나옵니다. 정확도와 지연을 맞바꾸는 손잡이 가 이것 하나입니다.

배치도 증분으로 돌린다

배치라고 매번 전체를 읽을 필요는 없습니다. 마지막으로 처리한 지점을 기록하고 그 뒤만 읽습니다. 다만 경계를 겹치게 잡습니다.

-- 워터마크를 그대로 쓰면 경계에 걸친 것을 놓친다
where updated_at >= :last_watermark - interval '10 minutes'
  and updated_at <  :now

겹치는 구간은 다시 읽지만, 적재가 멱등하면 아무 해가 없습니다. 멱등성이 있으면 겹쳐 읽기가 공짜 라는 원리가 여기서도 같습니다.

현장에서 만나는 모습

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

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

다음 실습에서 할 것

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