Crontab Guru

필드 빠른 참조표

 ┌───────────── 분 (0-59)
 │ ┌─────────── 시 (0-23)
 │ │ ┌───────── 일 (1-31)
 │ │ │ ┌─────── 월 (1-12 또는 JAN-DEC)
 │ │ │ │ ┌───── 요일 (0-6 또는 SUN-SAT; 일요일 = 0 또는 7)
 │ │ │ │ │
 * * * * *

cron 표현식에 쓰는 연산자

읽는 순서가 중요합니다

0 */2 * * 1-5는 왼쪽에서 오른쪽으로 “0분, 2시간마다, 날짜는 무관, 월은 무관, 월요일부터 금요일까지”로 읽습니다. 사람들은 습관적으로 필드를 오른쪽에서 왼쪽으로 읽다가 혼란에 빠지곤 합니다. 항상 ‘분’부터 읽으세요.

“X분마다”의 함정

*/10 * * * *는 0분, 10분, 20분, 30분, 40분, 50분에 실행됩니다. “작업이 생성된 시점부터 10분마다”가 아닙니다. 크론의 스텝은 항상 필드 범위의 시작점을 기준으로 계산됩니다. 작업을 12:03에 배포해도 첫 실행은 12:13이 아니라 12:10입니다.

“마지막 실행 후 N분 뒤”가 정말로 필요한 작업이라면, 영속 타이머를 가진 스케줄러를 사용하세요(OnUnitActiveSec을 쓰는 systemd 타이머, 또는 마지막 실행 시각을 저장하는 애플리케이션 수준 스케줄링 등).

알아 두면 좋은 cron 함정

• ‘일’과 ‘요일’을 모두 지정한 경우: 대부분의 cron 구현은 이를 OR로 처리하므로 원하는 결과가 아닐 가능성이 큽니다.
• 스텝 0: */0은 유효하지 않습니다.
• 범위가 자정을 넘어가는 경우: 시 단위의 22-2는 고전적인 cron에서 동작하지 않습니다. 22-23,0-2로 작성하세요.
• 2월 30일: 0 0 30 2 * 같은 스케줄은 절대 실행되지 않습니다.
• 서머타임(DST) 모호성: 새벽 2시에서 3시 사이로 예약된 작업은 DST 전환일에 두 번 실행되거나 아예 실행되지 않을 수 있습니다.

cron과 최신 스케줄러 비교

Unix의 cron은 지금도 어디에나 쓰이지만, 중요한 작업이라면 다음 중 하나가 필요할 것입니다.

• systemd 타이머: 놓친 실행을 따라잡고, 무작위 오프셋을 지원하며, 유닛 파일에서 설정을 읽습니다.
• Kubernetes CronJob: 선언적이며, 재시도를 지원하고, 1.25 이상에서 타임존을 인식합니다.
• Airflow / Prefect / Dagster: 의존성, 재시도, 백필, 관측 가능성이 필요한 작업용.
• GitHub Actions 스케줄: 5필드 cron, UTC 전용, 최소 5분 간격, 베스트 에포트 방식.

cron 자체는 훌륭한 형식이지만, 절대 놓쳐서는 안 되는 작업의 스케줄러로는 부족합니다.