언제 Spark 배치, 언제 Structured Streaming인가 — 실무 판단 체크리스트
Batch vs Stream Processing: The Plain-English Guide (2026) — (블로그, 발행처 미상) Batch vs Stream Processing: The Plain-English Guide (2026) — freshness/failure handling/cost/output nature 및 When to Use 체크리스트 구간(7~10페이지)을 Spark 파이프라인 맥락으로 재구성
이 모듈을 다 읽으면
- 가이드의 '배치를 쓸 때/스트리밍을 쓸 때' 체크리스트를 Spark로 구현되는 실제 파이프라인 의사결정으로 옮겨 설명할 수 있다
- Trigger.AvailableNow()가 왜 '배치처럼 실행되는 스트리밍'이라는 절충안이 되는지, 그리고 그것이 대체하는 Trigger.Once()와 어떻게 다른지 설명할 수 있다
- 가이드가 강조하는 '비용은 서버비만이 아니라 재실행·백필 같은 운영 부담도 포함한다'는 관점을 Spark 배치 잡의 실무 사례로 설명할 수 있다
가이드는 결과가 즉시 갱신될 필요가 없고 안정적·재현 가능한 숫자가 중요하면 배치를, 최신 이벤트에 따라 즉시 반응해야 하면 스트리밍을 쓰라고 조언한다. Spark로 구현할 때 이 판단은 흑백이 아니라 스펙트럼에 가깝다 — 많은 팀이 먼저 Airflow로 스케줄링되는 Spark 배치 잡으로 시작했다가, 특정 지표의 지연 요구사항이 배치 주기보다 짧아질 때만 그 파이프라인을 Structured Streaming으로 옮긴다. Spark 3.3부터는 Trigger.AvailableNow()가 도입되어, 스트리밍 코드를 그대로 두고도 현재 쌓여 있는 데이터까지만 처리한 뒤 종료하는 '배치처럼 실행되는 스트리밍'을 실행할 수 있는데, 이는 이전에 쓰이던 Trigger.Once()보다 큰 백로그를 여러 마이크로배치로 나눠 처리할 수 있어 권장되는 방식이다. 가이드가 강조하는 비용 관점, 즉 배치 시스템은 잡을 감시하고 재실행하고 백필하는 사람의 운영 부담이 시스템 규모가 커질수록 조용히 커진다는 지적도 Spark 배치 파이프라인에 그대로 적용된다.
가이드의 체크리스트를 Spark 파이프라인 맥락으로 번역하기
가이드는 '이미 일어난 일을 설명하면 되고, 결과가 즉시 갱신될 필요가 없고, 리포트·감사·재무 요약을 만들고 있고, 신선도보다 안정성·재현성이 중요하면' 배치를 쓰라고 하고, '변화에 실시간으로 반응해야 하고, 최신 이벤트에 의사결정이 좌우되고, 다음 배치 실행을 기다리면 잘못된 결과로 이어지면' 스트리밍을 쓰라고 한다. Spark로 옮기면 이는 '이 지표를 하루 한 번 Airflow가 트리거하는 Spark 배치 잡으로 계산해도 되는가, 아니면 이벤트가 도착하는 즉시 Structured Streaming 쿼리로 갱신해야 하는가'라는 구체적인 질문이 된다. 대부분의 리포팅·정산 파이프라인은 전자로 충분하고, 사기 탐지나 실시간 알림처럼 다음 배치까지 기다리는 것 자체가 리스크인 경우에만 후자가 필요하다.
핵심 포인트
- 가이드의 배치/스트리밍 판단 기준은 Spark에서 '배치 잡으로 충분한가, Structured Streaming 쿼리가 필요한가'라는 구체적 질문으로 옮겨진다
- 리포팅·정산류는 대부분 배치로 충분하고, 다음 배치까지 기다리는 것 자체가 리스크인 경우에만 스트리밍이 필요하다
실무에서는 배치로 시작해 필요한 파이프라인만 스트리밍으로 옮긴다
가이드도 언급하듯 실제 시스템에서는 배치와 스트리밍이 함께 쓰이는 경우가 흔하고, 팀은 배치로 시작해 시스템이 커지면서 필요한 부분만 스트리밍을 도입한다. Spark는 이 전환을 코드 재작성 없이 지원하기 위한 절충 지점을 제공하는데, 바로 Trigger.AvailableNow()다. Spark 3.3부터 도입된 이 트리거는 Structured Streaming 쿼리를 스트리밍 코드 그대로 실행하되, 현재 소스에 쌓여 있는 데이터까지만 처리하고 자동으로 종료한다 — 사실상 '배치처럼 실행되는 스트리밍'이다. 이전에 같은 목적으로 쓰이던 Trigger.Once()는 아무리 큰 백로그라도 단 한 번의 마이크로배치로 전부 처리하려 해 대량 백로그에서 메모리 문제를 일으키기 쉬웠던 반면, Trigger.AvailableNow()는 그 백로그를 여러 개의 마이크로배치로 나눠 처리해 더 안전하다. 이 때문에 공식 문서도 신규 파이프라인에는 Trigger.Once() 대신 Trigger.AvailableNow()를 권장한다.
핵심 포인트
- Trigger.AvailableNow()(Spark 3.3+)는 스트리밍 코드를 그대로 두고 현재 쌓인 데이터까지만 처리한 뒤 종료하는 '배치처럼 실행되는 스트리밍'이다
- 이전 방식인 Trigger.Once()는 백로그 전체를 한 번의 마이크로배치로 처리하려 해 대량 데이터에서 취약했고, AvailableNow()는 여러 마이크로배치로 나눠 처리해 더 안전하다
- 배치로 시작해 지연 요구사항이 엄격해지는 파이프라인만 스트리밍으로 옮기는 점진적 전환이 실무에서 흔하다
비용은 서버비만이 아니다 — 재실행·백필의 운영 부담 관점
가이드는 비용을 서버 비용만이 아니라 사람의 운영 부담으로 봐야 한다고 강조한다. 배치 시스템은 잡을 감시하고, 실패하면 재실행하고, 늦게 도착한 데이터 때문에 백필을 수행하고, 숫자가 왜 바뀌었는지 설명하는 작업이 시스템이 커질수록 조용히 쌓인다는 것이다. 이는 Spark 배치 파이프라인에도 그대로 적용된다 — Airflow로 스케줄링된 Spark 잡이 실패하면 특정 파티션만 재처리하는 백필 로직을 별도로 관리해야 하고, 소스에서 늦게 도착한 데이터를 반영하려면 이미 끝난 날짜의 daily 테이블을 다시 계산해야 한다. 스트리밍으로 전환하면 이런 재실행·백필의 상당 부분이 체크포인트 기반의 자동 재개로 대체되지만, 그 대가로 상태 저장소 운영이라는 새로운 부담이 따라온다는 점도 함께 고려해야 한다.
핵심 포인트
- 가이드가 말하는 '비용'은 서버비가 아니라 잡 감시·재실행·백필 같은 운영 인력의 부담을 포함한다
- Airflow로 스케줄링된 Spark 배치 잡은 실패 시 특정 파티션 재처리, 늦은 데이터 반영을 위한 daily 테이블 재계산 같은 운영 부담을 그대로 진다
- 스트리밍 전환은 재실행·백필 부담을 줄이는 대신 상태 저장소 운영이라는 새로운 부담을 가져온다는 트레이드오프로 이해해야 한다