배치 스케줄링, 사람 판단을 얼마나 덜어낼 수 있나?
결론부터 말하면, 배치 스케줄링 자동화의 목표는 "사람을 없애는 것"이 아니라 반복·검증 가능한 판단을 스케줄러와 작업 코드로 고정하고, 예외와 정책 변경만 사람에게 남기는 것이다. 2025년 공개된 의료 데이터 플랫폼 DeltaTrace는 Airflow로 작업 예약·자원 모니터링·오류 알림·실패 재시작을 자동화하면서도, 업무 규칙 변경이나 데이터 품질 기준 확정은 여전히 사람이 맡았다 출처. 수치는 조건부다 — 서버·코어·입력량이 다르면 그대로 적용되지 않는다.
- 반복적·검증 가능한 판단(실행 시각, 재시도, 동시 실행 수)은 스케줄러에 맡긴다.
- 예외 승인, 정책 변경, 법적·재무적 확정은 사람이 유지한다.
- 코어 증설보다 병목(CPU/I/O/외부 대기) 분리가 먼저다.
- 배치 크기는 처리 지연 허용시간과 재처리량을 함께 봐야 한다.
- 비용은 스케줄러 라이선스·인스턴스·재처리 비용을 각각 따로 기록한다.
흔히 빠지는 함정은 "일단 전부 자동 스케줄로 돌리고 나중에 조정하자"는 접근이다. 실행 조건과 실패 정책을 먼저 정의하지 않고 작업부터 붙이면, 재시도 횟수와 실패 시 중단 범위가 작업마다 제각각이 되고, 나중에 어떤 작업이 왜 멈췄는지 추적하기 어려워진다. DeltaTrace 사례에서도 실행 주기, 선행 데이터 조건, 재시도 횟수, 실패 시 중단 범위를 작업별 필드로 분리해 두는 방식이 전제였다 출처.
코어를 늘리면 배치가 빨라질까?
늘 그런 것은 아니다. DeltaTrace의 측정에서 초당 50건 요청 조건일 때 8코어 서버의 평균 처리시간은 5.1분, 24코어 서버는 4.9분이었다. 코어를 3배로 늘렸지만 차이는 0.2분에 그쳤다 출처. 즉 병목이 CPU가 아니라면 코어 증설은 비용만 늘리고 처리시간은 거의 바뀌지 않는다.
배치 스케줄링을 설계할 때 흔한 함정 중 하나가 "느려지면 일단 인스턴스를 키운다"는 반응이다. 실제로는 CPU 연산이 느린 것인지, 디스크·네트워크 I/O 대기인지, 외부 시스템(DB, API) 응답 대기인지 구분하지 않으면 증설 효과를 가늠할 수 없다. 같은 데이터를 코어 수만 바꿔 재현해 보고, 처리시간 변화가 거의 없다면 병목은 다른 곳에 있다고 보는 편이 맞다. 이 구분 작업 자체가 비용이고, 생략하면 나중에 인프라 비용만 누적된다.
작업을 쪼갤까, 묶을까 — 배치 크기는 어떻게 정하나?
배치 크기는 무조건 키우는 것이 아니라 처리 지연 허용시간, 작업당 메모리, 실패 시 재처리량을 함께 따져 정해야 한다. 2025년 데이터 오케스트레이션 플랫폼 연구에서는 AI 워크플로 1회 실행시간이 약 38초, 평균 자원 사용량은 CPU 2개와 메모리 50MB였는데, 스마트미터 이벤트를 10~300개로 늘려가며 300개 워크플로를 실행하자 큰 배치에서 실행시간이 최대 약 60초까지 늘었다 출처.
같은 연구에서 중앙집중형 클라우드 대비 제안 플랫폼은 평균 지연시간 250ms→175ms, 실행시간 45초→36초, CPU 사용률 80%→60%, 네트워크 사용량 100MB→70MB로 측정됐다. 다만 이는 특정 플랫폼·실험 조건의 비교이며 Airflow·Dagster·Prefect 전체에 일반화할 수 없다 출처. 배치를 크게 묶으면 처리량은 늘어도, 실패했을 때 다시 계산해야 할 데이터량도 함께 커진다는 점이 실무에서 자주 빠지는 함정이다. ActiveBatch 공개 사례에서는 Cincinnati Bell이 100개 작업을 4개 플랜으로 통합해 비용과 파일 전송 오류를 줄였고, ASM 사례는 하드코딩된 작업 120개를 매개변수화된 작업 1개로 대체했다 출처. 다만 이는 제품 공급업체가 공개한 사례이므로 독립 검증 연구로 보기보다 참고 사례로 다루는 편이 맞다.
스케줄러·작업 코드·사람, 판단을 어떻게 나누나?
네 층위로 나누면 역할이 명확해진다. 스케줄러는 실행 시각, 의존성 충족, 재시도, 동시 실행 수, 우선순위를 결정한다. 작업 코드는 입력 검증, 멱등성, 체크포인트, 오류 분류, 결과 저장을 맡는다. 모니터링은 지연시간 초과, 실패율 상승, 입력 누락, 자원 포화를 감지해 알린다. 사람은 업무 규칙 변경, 예외 승인, 데이터 품질 기준, 법적·재무적 영향이 있는 결과 확정만 남긴다.
DeltaTrace는 이 분리를 데이터 특성으로도 구현했다. 웨어러블 연속 데이터는 즉시 처리하고, 불규칙하게 들어오는 설문 데이터는 Airflow 작업으로 묶어 배치 처리했다. "즉시 처리해야 하는 데이터"와 "정해진 시점에 처리해도 되는 데이터"를 입력 단계에서 구분한 것이다 출처. 처리 지연은 데이터 수집·시각화 평균 4.9~7.5분, 집계 평균 5.6분 미만, 이상 탐지 평균 10.5분 미만이었고 전체 종단 간 지연은 10분 이내로 유지됐다. 이 분리 기준이 없으면 모든 데이터를 즉시 처리 경로로 몰아넣어 불필요하게 자원을 쓰거나, 반대로 급한 데이터까지 배치 주기에 묶여 지연이 커지는 두 방향의 실패가 모두 가능하다.
배치 자동화 = 무인 운영이라는 오해, 맞을까?
틀린 전제다. 2025년 사례들은 배치·실시간 처리를 Airflow로 분리하고 작업 성공·지연·재시작을 수치로 관리하는 방향을 보여주지만, 어느 사례도 사람 개입을 완전히 제거했다고 보고하지 않는다. ActiveBatch 사례의 RelayHealth는 월 300만 건의 작업을 처리하며 99% 성공률을 기록했지만 출처, 나머지 1%는 여전히 예외 처리와 사람의 검토 대상으로 남는다. 건수가 크면 1%도 매달 3만 건에 가까운 작업이라는 뜻이다.
오해가 생기는 지점은 "자동 재시작 = 실패 해결"로 착각하는 경우다. 재시도는 일시적 오류(네트워크 끊김, 일시적 자원 부족)에는 유효하지만, 입력 스키마가 바뀌었거나 업무 규칙 자체가 틀렸을 때는 몇 번을 재시도해도 같은 실패가 반복된다. 이럴 때 실패 정책에 "N회 재시도 후 격리 큐로 보내고 사람에게 알림"이라는 조건이 없으면, 로그만 쌓이고 아무도 알아채지 못하는 상태가 이어진다. 격리 큐와 알림 조건을 미리 정의해 두는 것이 재시도 횟수를 늘리는 것보다 운영 안정성에 더 직접적으로 기여한다.
배치 스케줄링 도입 비용, 뭘 따로 계산해야 하나?
Airflow·Dagster·Prefect를 동일 조건에서 비교한 신뢰할 만한 비용 벤치마크는 2026년 기준으로도 확인되지 않았다. 따라서 제품별 비용을 단정하기보다 항목을 쪼개 계산하는 편이 안전하다: 스케줄러 라이선스, 실행 인스턴스, 스토리지, 로그 보관, 재처리 비용, 운영 인력.
여기서 자주 빠뜨리는 항목이 재처리 비용이다. 배치 크기를 키우면 평시 처리량은 늘지만, 실패 시 재처리해야 할 데이터량도 커진다는 점은 앞서 본 워크플로 실행시간 연구에서도 확인된다 출처. 버전을 바꿀 때마다 작업 성공률, 재시도율, 평균·p95 처리시간, 스케줄 지연시간, 중복 실행률, 실패 후 복구시간, 작업당 CPU·메모리, 재처리 데이터량, 월간 인프라 비용을 함께 기록해야 비교가 가능하다. Airflow·Spark 버전, 코어 수, 입력량을 적어두지 않으면 다음 분기에 수치를 재현할 수 없다.