놀라움을 일으키지 않는 Cron 표현식 작성하기
다섯 필드와 범위, 이름 대 숫자, 일-요일 OR 함정, 일요일은 0인가 7인가, 서머타임의 공백과 중복, 그리고 배포 전 다음 실행 미리보기로 검증하는 방법.
다섯 필드, 왼쪽에서 오른쪽으로 읽기
고전적인 cron 표현식은 공백으로 구분된 다섯 필드입니다. 분(0–59), 시(0–23), 일(1–31), 월(1–12), 요일(0–7). 각 필드는 단일 값, 쉼표로 구분된 목록, 하이픈 범위, 슬래시 뒤의 스텝, 또는 모든 값을 뜻하는 별표를 받습니다.
cron 버그의 대부분은 희귀한 문법이 아니라 평범한 필드를 부주의하게 읽은 것입니다. 범위 경계에서 리셋되는 스텝이나, 23까지 세는 시스템에서 12시간제로 쓰인 시 필드 같은 것입니다.
- 목록목록은 이산 값을 고릅니다. 분 필드의 0,30은 매시 정각과 30분에 발화합니다.
- 범위와 스텝범위는 구간을 고릅니다. 시 필드의 9-17은 업무 시간을 커버하고, 스텝은 그것을 성기게 합니다. 9-17/2는 구간 안에서 두 시간마다 발화합니다.
- 별표는 전부 일치별표는 “이 필드를 무시”가 아닙니다. 모든 값에 능동적으로 일치하며, 두 날짜 필드가 상호작용하는 순간 중요해집니다.
이름은 문서가 붙은 숫자
월과 요일 필드는 세 글자 영문 이름——JAN부터 DEC까지, SUN부터 SAT까지——을 숫자의 별칭으로 받습니다. 0 9 * JAN MON과 0 9 * 1 1은 같은 스케줄이지만, 이름 버전은 다음 독자에게 스스로를 설명하고 오프바이원 수정에도 견딥니다.
- 대소문자 무관이름 파싱은 대소문자를 구분하지 않습니다. mon, Mon, MON 모두 되지만, 대문자가 의도적으로 읽히는 관례입니다.
- 범위 안의 이름이름은 범위와 목록 안에서도 쓸 수 있습니다. MON-FRI가 표준 평일 구간이고, JAN,APR,JUL,OCT는 분기 월을 고릅니다.
- 설명 읽기Cron 작성 및 설명 도구는 표현식을 정규화하고 각 필드를 따로 설명합니다. “month: every value”, “weekday: 1, 2, 3, 4, 5”처럼요. 파서가 이름을 의도대로 읽었는지 확인할 수 있습니다.
일과 요일 두 필드의 관계
이 도구는 Vixie 방식의 날짜 규칙을 따릅니다. 일과 요일 필드가 둘 다 *로 시작하지 않으면 어느 쪽이 일치해도 실행됩니다. 0 9 13 * FRI는 “13일의 금요일”이 아니라 매월 13일과 매주 금요일을 뜻합니다.
설명 도구의 출력은 이 점을 명시합니다. 의미론을 dom-dow-or로 표시해 계산된 실행과 함께 보여주므로, 의도보다 훨씬 자주 발화할 표현식은 crontab에 들어가기 전에 정체를 드러냅니다.
- 와일드카드 스텝에도 제한 적용일 또는 요일 필드가 */2 같은 스텝을 포함해 *로 시작하면 이 도구는 두 날짜 필드 모두 일치할 것을 요구합니다. 스텝 제한도 그대로 적용됩니다.
- 앞에 *가 없으면 OR두 날짜 필드가 모두 *로 시작하지 않을 때 이 도구는 OR 규칙을 적용해 일이나 요일 중 하나만 일치해도 실행합니다.
- AND는 우회가 필요진짜 “13일의 금요일”을 맞히려면 cron이 13일을 고르게 하고 명령 자체가 요일을 확인하게 하세요. 아니면 AND 의미론을 가진 스케줄러를 써야 하는데, 고전 cron은 그것이 아닙니다.
일요일은 0, 보통은 7이기도 하다
요일 필드는 일요일을 0, 월요일을 1로 매기고 토요일 6까지 갑니다. 대부분의 구현은 월요일부터 세는 사람들을 위해 7도 두 번째 일요일로 받습니다. Toolars 파서는 내부적으로 7을 0으로 정규화합니다. 하지만 둘 중 하나만 받는 시스템도 있고, 월요일을 1로 시작하는 ISO식 번호 매기기도 다른 곳에 존재합니다.
- 0과 77이 받아들여지는 곳에서 0과 7은 둘 다 일요일입니다. 0으로 쓰는 것이 스케줄러 간 이식성 있는 선택입니다.
- 조용한 오프바이원7을 거부하는 시스템에서 요일 7은 배포 시점에 요란하게 실패하지만, “월요일부터 센 일곱 번째 날”로 잘못 읽힌 요일은 엉뚱한 요일에 조용히 실패합니다.
- 플랫폼별 재확인표현식이 구현 사이를 옮길 때——시스템 crontab, 컨테이너 플랫폼, CI 스케줄러——번호 매기기가 여정을 무사히 넘겼다고 가정하지 말고 요일 번호를 다시 확인하세요.
서머타임은 스케줄을 휘게 한다
서머타임 전환에는 존재하지 않거나 반복되는 현지 분이 생깁니다. 이 미리보기는 봄철 건너뛴 02:30을 제외하고, 가을철 겹친 일치 시각은 두 번 표시합니다. 실제 스케줄러는 누락분을 보충하거나 중복 실행을 억제할 수 있으니 자체 규칙을 확인하세요.
- 사라지는 한 시간봄철 공백: 미리보기에는 일치하는 02:30이 없습니다. 일부 스케줄러는 전환 후 놓친 작업을 실행합니다.
- 두 배가 되는 한 시간가을철 중복: 미리보기는 일치하는 두 시각을 표시할 수 있지만 실제 스케줄러는 두 번째 실행을 억제할 수 있습니다.
- UTC에는 DST가 없다깔끔한 탈출구는 UTC입니다. 서머타임 전환이 없어서 30 2 * * *는 1년 내내 매일 같은 순간을 뜻합니다. 설명 도구는 UTC, 기기의 로컬 시간대, 그리고 America/New_York, Europe/London 같은 명명된 시간대를 제공합니다.
희망이 아니라 다음 실행으로 검증하기
올바른 표현식과 그럴듯해 보이는 표현식의 차이는 구체적인 발화 시각 목록입니다. Cron 작성 및 설명 도구는 선택한 시간대에서 지금부터 다음 10회 실행을 계산하며 최대 366일 앞까지 탐색하고, 백그라운드 워커에서 평가하므로 무거운 표현식도 탭을 멈추게 할 수 없습니다.
- 실행 읽기처음 몇 회 실행을 의도와 대조하세요. “평일 09:00”이면 월요일부터 금요일 9시가 나와야 하고, 목록에 토요일이 있으면 OR 함정이 자수하는 것입니다.
- 전환 한 번 건너기이름이 있는 시간대를 선택하고 다음 서머타임 전환이 366일 미리보기 안에 있다면 전후 실행 시각을 확인하세요. 작업 영역은 현재 시각부터 시작하며 임의의 시작 날짜는 선택할 수 없습니다.
- 명시적 오류잘못된 식은 오류를 보고합니다. 366일 안에 일치 항목이 0개면 검색 한도 오류가 나고, 1–9개면 빈 목록 대신 부분 결과를 반환합니다.
자주 묻는 질문
예상하지 않은 요일에 cron이 동작한 이유는 무엇인가요?
cron에서 일요일은 0과 7 중 무엇인가요?
일광절약시간의 영향을 받지 않는 스케줄을 만들려면 어떻게 하나요?
스케줄과 패턴은 같은 규율을 공유합니다.
둘 다 파괴 반경이 큰 작은 문자열입니다. 정규 표현식을 위한 작성-테스트-리팩터링 루프를, 타임아웃이 있는 로컬 워커에서 배워 보세요.