시간대와 DST를 가로질러 Cron 일정 검증하기

문제 상황

팀은 흔히 눈에 보이는 cron 5필드와 자연어 설명 한 줄만 검토하고 일정이 증명됐다고 생각합니다. 하지만 한 시스템은 초 필드를 요구하고 다른 시스템은 Unix/Vixie 날짜 필드 OR 규칙을 따르며, 컨테이너는 UTC인데 애플리케이션은 지역 IANA 시간대를 쓸 수 있습니다. DST 전환은 로컬 한 시간을 없애거나 반복하고, 티켓의 오프셋 없는 날짜는 또 다른 모호성을 만듭니다. 따라서 하나의 정확한 기준 instant, 실제 스케줄러 계약, 재현 가능한 다음 실행과 parser가 시뮬레이션할 수 없는 중복·catch-up·재시작·배포 동작의 운영 증거를 함께 확보해야 합니다.

이럴 때 사용하세요

• 새 반복 작업, 보고서, 정리 작업, 알림 또는 백업을 첫 운영 배포 전에 검토할 때
• 일광 절약 시간이나 시간대 설정 변경 근처에서 작업이 한 시간 빠르거나 늦게, 두 번 또는 전혀 실행되지 않았을 때
• 서비스를 UTC와 지역 IANA 시간대 사이에서 옮기거나 운영체제 시간대가 다른 호스트로 이전할 때
• 장애 기록에 오프셋 없는 타임스탬프와 cron 표현식이 있고 이를 로그, HTTP date 또는 Unix 값과 비교해야 할 때

단계

1. 1단계

   정확한 스케줄러 방언과 실행 소유자 확인

   작업을 Unix crond, Kubernetes CronJob, cloud scheduler, Quartz, 애플리케이션 라이브러리 중 무엇이 해석하는지 기록합니다. 문서화된 필드 순서, 지원 토큰, day-of-month/day-of-week 규칙, IANA 시간대, clock source와 배포 소유자를 복사합니다. 6필드나 Quartz 표현식에서 초나 문자를 임의로 지우지 마세요. 필드가 맞아도 실행을 바꾸는 동시성, 재시도, catch-up, 누락 실행, 재부팅, 중복 억제 설정도 함께 기록합니다.

2. 2단계

   모든 기준 타임스탬프를 명시적인 instant로 변환

   날짜만 있거나 오프셋 없는 값을 2026-03-06T15:00:00Z 또는 2026-03-07T10:30:00+09:00처럼 Z나 숫자 오프셋을 포함한 ISO 8601로 바꿉니다. 날짜·시간 워크벤치의 Date 모드에서 UTC ISO, 선택 IANA 시간대의 RFC 3339, HTTP date, Unix seconds와 milliseconds를 비교합니다. 두 출처가 같은 이벤트를 뜻한다면 달력 문자가 달라도 Unix milliseconds는 같아야 합니다.

3. 3단계

   자연어 한 문장에 의존하지 않고 5개 필드 검사

   운영 표현식이 5필드 Unix/Vixie 문법임을 확인한 경우에만 Cron 모드에 입력합니다. 명시적인 기준 instant와 스케줄러의 IANA 시간대를 설정하고 다음 5회 또는 10회를 계산합니다. 각 원문 필드와 정규화 값을 비교하세요. 6번째 필드, macro, Quartz ?, L 또는 #, hashed H, 잘못된 범위, 빈 결과가 나오면 수용될 때까지 표현식을 바꾸지 말고 원래 방언을 다시 확인합니다.

4. 4단계

   날짜 필드와 시간대 경고 해결

   day-of-month와 day-of-week가 모두 제한되면 대상이 Unix/Vixie OR 규칙을 쓰는지 확인합니다. 예를 들어 0 0 1 * MON은 흔히 모든 월요일 또는 매월 1일을 뜻합니다. 반환된 RFC 3339 벽시계와 UTC를 나란히 보고 오프셋 변화를 기록합니다. 컨테이너, 프레임워크, scheduler 설정과 infrastructure code가 machine default를 상속하지 않고 같은 IANA 이름을 지정하는지 확인합니다.

5. 5단계

   다음 DST 전환 주변 fixture 만들기

   대상 시간대의 다음 spring-forward와 fall-back 경계 직전 instant를 기준으로 고릅니다. 사라지거나 반복되는 시간 안의 일정과 평일 09:00 같은 인접한 일반 일정을 함께 시험하고 예상 로컬·UTC 실행을 저장합니다. 그 다음 실제 운영 스케줄러의 staging에서 같은 fixture를 돌려 존재하지 않는 시각을 건너뛰는지, 이동·재시도·catch-up하는지, 반복 시각을 한 번 또는 두 번 실행하는지 관찰합니다.

6. 6단계

   관측 증거와 롤백 조건을 갖춰 배포

   표현식, IANA 시간대, 정규화 필드, 기준 instant, 예상 다음 실행, DST fixture, 동시성 정책과 staging 결과를 한 변경에서 검토합니다. 안정적인 run identifier와 UTC ISO를 포함한 구조화 시작·완료 로그, 누락·중복 window 알림을 추가합니다. 관찰 가능한 시간에 배포해 첫 실제 실행을 저장한 UTC 기대값과 비교하고, 되돌릴 수 없는 작업을 활성화하기 전에 rollback 또는 disable 조건을 정합니다.

예시

표현식 0 9 * * 1-5, IANA 시간대 America/New_York, 기준 instant 2026-03-06T15:00:00Z

다음 실행은 월요일 2026-03-09T09:00:00-04:00이며 UTC로 2026-03-09T13:00:00Z입니다. 3월 8일 DST가 시작했으므로 오프셋은 -04:00입니다. 이후 재시도와 누락 실행 설정을 기록한 실제 운영 스케줄러에서 같은 fixture를 실행합니다.

흔한 실수

자주 묻는 질문