배치 실패 알림이 슬랙에 올라온 시각은 새벽 3시 12분이었다. 근데 그걸 누가 봤겠는가. 온콜 당번은 해당 알림을 "정보성"으로 분류해뒀고, 아침에 출근한 PM이 "어제 정산 데이터 왜 안 나왔어요?"라고 물었을 때야 사태를 파악했다. 8시간 동안 아무도 몰랐다.
크론잡 기반 배치를 운영해본 사람이라면 이 시나리오가 익숙할 것이다. Jenkins crontab으로 돌리는 야간 배치는 성공하면 조용하고, 실패해도 조용하다. 바로 그게 문제다.
크론은 "실행"만 알고, "성공"은 모른다
Jenkins에서 크론 트리거를 거는 건 간단하다. 빌드 트리거에 H 3 * * * 한 줄 넣고, 쉘 스크립트 물리면 끝이다. 5년 전에도 이랬고 지금도 똑같다. 설정 3분이면 배치 하나 등록된다.
문제는 실패 이후의 시나리오에서 드러난다. 크론은 "이 시각에 이걸 실행하라"만 안다. 작업이 터지면? 다음 스케줄까지 아무 일도 일어나지 않는다. 재시도 로직, 의존성 확인, 부분 성공 이어가기 — 이런 개념 자체가 존재하지 않는다.
여기에 가시성 부재가 겹친다. Jenkins 빌드 히스토리가 있긴 하지만, 여러 잡이 체인으로 엮인 전체 흐름을 보여주진 않는다. A 배치가 끝나야 B가 돌아야 하는 구조에서, A가 실패하면 B는 빈 데이터를 물고 정상 완료된다. 에러 하나 안 뱉는다. 결과물만 이상하다. 그리고 그 이상함을 발견하는 건 사람이다 — 보통 한참 뒤에.
2026년 2월 무신사 테크블로그에 올라온 글이 정확히 이 고통을 묘사했다. 출고지시 파이프라인에서 스케줄이 반복적으로 씹혔고, 원인 추적을 위해 여러 잡의 로그를 하나하나 뒤져야 했다고 한다. 누구나 겪어봤을 법한 이야기다.
워크플로 엔진이 해결하려는 것
Temporal, Apache Airflow, Prefect. 이름은 다르지만 해결하려는 핵심은 동일하다 — 작업의 흐름을 코드로 정의하고, 실패와 재시도와 상태 관리를 플랫폼 레벨에서 책임진다.
크론과의 결정적 차이는 durable execution이다. 워크플로 도중에 워커가 죽어도 재시작하면 마지막 체크포인트부터 이어간다. Netflix가 이걸 도입한 뒤 배포 과정의 일시적 실패율이 4%에서 0.0001%로 내려갔다는 수치는 유명하다.
다만 도구마다 성격이 꽤 다르다:
| Temporal | Airflow | Prefect | |
|---|---|---|---|
| 강점 | Durable execution, 코드 퍼스트 | DAG 기반 파이프라인, 넓은 생태계 | Python 네이티브, 간결한 API |
| 러닝커브 | 높음 (SDK 학습 필수) | 중간 | 낮음 |
| 적합 케이스 | 트랜잭션, 장기 실행 워크플로 | 데이터 ETL 파이프라인 | 중소규모 데이터 워크플로 |
| 운영 부담 | 클러스터 직접 운영 or Cloud | Scheduler+Worker+메타DB | 클라우드 버전이면 거의 없음 |
"뭐가 제일 좋냐"고 묻는 건 의미가 없다. 정산 배치처럼 한 건 실패가 돈으로 직결되는 워크플로라면 Temporal의 내구성이 빛난다. 하루 한 번 리포트 뽑는 잡이라면 Airflow로 충분하고, 데이터팀이 3명이면 Prefect가 현실적이다.
전부 갈아엎지 않아도 된다
무신사 팀이 현명했던 건 점진적으로 움직였다는 점이다. 출고지시 파이프라인 전체가 아니라 "트리거 + 특정 화주 주문수집" 구간만 Temporal로 옮겼다. 나머지는 Spring Batch와 Jenkins를 그대로 유지했다.
이 접근이 합리적인 이유는 세 가지다. 하나, 비교 대상이 생긴다. 같은 도메인에서 구 방식과 신 방식을 병행하면 체감 차이를 수치로 뽑을 수 있다. 둘, 폭발 반경이 작다. 새 시스템에 버그가 있어도 전체 파이프라인이 서지 않는다. 셋, 학습 비용을 분산시킨다. Temporal SDK를 팀 전원이 한꺼번에 익히는 건 비현실적이다. 한 파트에서 먼저 경험을 쌓고 전파하는 편이 낫다.
2026년 현재 Temporal은 Nexus GA, 멀티리전 복제 GA(99.99% SLA), GCP 클라우드 런칭까지 끝낸 상태다. .NET과 Ruby SDK도 프리릴리즈에 들어갔고, Stripe·Datadog·HashiCorp 등이 프로덕션에서 돌리고 있다. 더 이상 "써봐도 될까?" 단계는 아니다.
결국 가시성 싸움이다
크론잡이 죽었을 때 그걸 몇 분 안에 알 수 있는가. 실패 지점에서 자동으로 재시도가 걸리는가. 부분 성공분은 살릴 수 있는가.
Temporal을 깔든, Airflow DAG를 짜든, 심지어 Jenkins를 계속 쓰더라도 — 이 세 질문에 "예"라고 답할 수 있으면 그 시스템은 괜찮다. 반대로 도구를 아무리 바꿔도 실행 상태를 실시간으로 못 보면 똑같다. 모니터링 없이 워크플로 엔진만 들여놓으면, 새벽 3시에 죽는 주체가 크론잡에서 워크플로로 바뀔 뿐이다.