Cron 표현식 해석기

다섯 개의 필드

표준 cron 표현식은 공백으로 구분된 다섯 개 필드입니다.

분  시  일  월  요일
*   *   *   *   *

| 필드 | 범위 | 비고 | |---|---|---| | 분 | 0–59 | | | 시 | 0–23 | 24시간제 | | 일 | 1–31 | | | 월 | 1–12 | JAN~DEC도 가능 | | 요일 | 0–6 | 0이 일요일. SUN~SAT도 가능 |

요일에 7을 쓰면 대부분의 구현이 일요일로 해석합니다.

도구 사용법

표현식을 넣으면 각 필드가 어떤 값으로 풀리는지, 사람이 읽는 설명, 그리고 앞으로의 실행 시각이 나옵니다. 프리셋 버튼(5분마다, 매시 정각, 매일 오전 9시, 평일 오전 9시, 매월 1일 자정, 매주 일요일 새벽 2시 30분)을 누르면 그 표현식이 채워지므로 거기서 숫자만 고쳐 쓰는 방식이 빠릅니다.

@daily, @hourly 같은 별칭은 받지 않습니다. crontab에서는 쓸 수 있지만 지원하지 않는 환경도 많아, 아래 표의 5필드 형태로 바꿔 넣으면 어디서든 통합니다.

| 별칭 | 같은 뜻의 표현식 | | ---------- | ---------------- | | @hourly | 0 * * * * | | @daily | 0 0 * * * | | @weekly | 0 0 * * 0 | | @monthly | 0 0 1 * * | | @yearly | 0 0 1 1 * |

@reboot는 시각이 아니라 "시스템 시작 때 한 번"이라 표현식으로 바꿀 수 없습니다.

자주 쓰는 표현식

| 원하는 일정 | 표현식 | | ------------------------------ | ---------------------- | | 평일 아침 9시 | 0 9 * * 1-5 | | 월·수·금 아침 9시 | 0 9 * * 1,3,5 | | 업무시간(9~18시) 30분마다 | */30 9-18 * * 1-5 | | 매일 새벽 3시 백업 | 0 3 * * * | | 매월 1일과 15일 정오 | 0 12 1,15 * * | | 분기 첫날 자정 | 0 0 1 1,4,7,10 * | | 매년 1월 1일 0시 | 0 0 1 1 * | | 15분마다 (정각 기준) | */15 * * * * |

매월 말일은 표준 cron으로 표현할 수 없습니다. 달마다 마지막 날이 다르기 때문입니다. 0 0 28-31 * *로 걸어 두고 스크립트 안에서 "내일이 1일인지" 확인해 아니면 종료하는 방식이 관례입니다.

31일과 2월 29일

일 필드에 31을 넣으면 31일이 있는 달에만 실행됩니다. 2월·4월·6월·9월·11월은 건너뜁니다. "매월 31일"이라고 생각하고 걸어 둔 작업이 1년에 일곱 번만 도는 셈입니다. 0 0 29 2 *는 4년에 한 번, 윤년 2월 29일에만 실행됩니다. 이 도구의 다음 실행 시각 목록에서 건너뛴 달이 바로 보이므로 확인해 보세요.

특수 문자

* — 해당 필드의 모든 값. * * * * *는 1분마다입니다.

, — 목록. 0,30 * * * *는 매시 0분과 30분입니다.

- — 범위. 0 9-18 * * *는 오전 9시부터 오후 6시까지 매시 정각입니다.

/ — 간격. */15 * * * *는 15분 간격입니다.

*/5가 정확히 언제인지

0분부터 시작하는 5분 간격입니다. 0, 5, 10, 15 … 55분에 실행됩니다. 서버가 켜진 시점부터 5분마다가 아닙니다.

여기서 함정은 60의 약수가 아닌 값입니다. */7은 0, 7, 14, 21, 28, 35, 42, 49, 56분에 실행된 뒤 다음 정시까지 4분만 남습니다. 간격이 일정하지 않습니다.

간격을 정확히 유지하려면 60의 약수(1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30)를 쓰세요.

일과 요일을 함께 쓰면 OR입니다

이것이 cron에서 가장 헷갈리는 부분입니다.

0 0 1 * 1

이 표현식은 "매월 1일이면서 월요일"이 아닙니다. 표준 cron은 두 필드가 모두 제한되어 있으면 OR로 동작합니다. 즉 매월 1일 그리고 매주 월요일 자정에 모두 실행됩니다. 한 달에 5~6번 돌게 됩니다.

이 동작이 직관에 어긋나기 때문에 관례적으로 둘 중 하나는 *로 둡니다. 일부 구현(Quartz 등)은 사용하지 않는 쪽에 ?를 쓰도록 요구합니다.

시간대 문제

cron은 실행되는 서버의 시간대를 따릅니다.

서버가 UTC로 설정되어 있는데 0 9 * * *를 걸었다면, 실제로는 한국 시각 오후 6시에 실행됩니다. AWS, GCP 같은 클라우드 환경은 기본이 UTC인 경우가 많아 이 차이로 인한 사고가 자주 생깁니다.

한국 시각 오전 9시에 돌리고 싶다면 UTC 서버에서는 0 0 * * *로 써야 합니다.

한국 시각을 UTC 서버용으로 바꿀 때는 9시간을 빼되, 날짜와 요일이 바뀌는지를 함께 봐야 합니다.

| 한국 시각 일정 | UTC 서버 표현식 | 주의 | | --------------------------- | ---------------------- | ------------------------ | | 매일 09:00 | 0 0 * * * | | | 매일 03:00 | 0 18 * * * | 전날 UTC 18시 | | 평일 09:00 | 0 0 * * 1-5 | | | 월요일 03:00 | 0 18 * * 0 | 요일이 일요일로 바뀜 | | 매월 1일 00:00 | 0 15 * * * 만으로는 불가 | 전달 말일 15시라 표현 불가 |

새벽 시간대의 요일 지정 작업은 요일 필드까지 하루 앞으로 당겨야 하고, 매월 1일 자정처럼 날짜 경계에 걸린 일정은 UTC로 옮기면 표현 자체가 안 되므로 서버 시간대를 KST로 두거나 조금 늦은 시각으로 조정해야 합니다.

서머타임이 있는 지역은 더 복잡합니다. 시계를 앞당기는 날에는 특정 시각이 아예 존재하지 않아 그날 작업이 건너뛰어지고, 되돌리는 날에는 같은 시각이 두 번 있어 두 번 실행될 수 있습니다. 한국은 서머타임이 없어 해당하지 않습니다.

이 도구가 보여주는 다음 실행 시각은 현재 브라우저의 시간대 기준입니다.

6개 필드는 다른 형식입니다

0 */5 * * * *   ← 6개 필드

맨 앞에 초 필드가 붙은 확장 형식입니다. Spring의 @Scheduled, Quartz, 일부 Node.js 라이브러리가 이 형식을 씁니다.

반면 리눅스 crontab, Kubernetes CronJob, GitHub Actions는 5개 필드만 받습니다. 6개 필드를 넣으면 오류가 나거나 필드가 하나씩 밀려 엉뚱한 시각에 실행됩니다.

어느 형식인지 문서를 먼저 확인하시기 바랍니다. 이 도구는 표준 5필드를 해석합니다.

GitHub Actions와 Kubernetes에서 쓸 때

GitHub Actions의 schedule은 항상 UTC이고, 지정한 시각에 정확히 시작된다는 보장이 없습니다. 정시에 요청이 몰리면 몇 분에서 수십 분까지 밀리거나 건너뛰기도 하므로, 분 필드를 0 대신 17처럼 어중간하게 두면 밀림이 줄어듭니다. 저장소에 60일간 활동이 없으면 예약 실행이 자동으로 꺼진다는 점도 알아 두세요.

Kubernetes CronJob은 기본이 컨트롤 플레인의 시간대(대개 UTC)이지만 timeZone: Asia/Seoul 필드를 지정하면 한국 시각으로 쓸 수 있습니다. 동시 실행 정책(concurrencyPolicy)을 Forbid로 두면 앞 작업이 끝나기 전에 다음 작업이 겹치는 문제를 막을 수 있습니다.

실무에서 주의할 점

실행이 겹칠 수 있습니다. */5로 걸어 둔 작업이 6분 걸리면 이전 작업이 끝나기 전에 다음 작업이 시작됩니다. 잠금 장치가 없으면 데이터가 꼬입니다.

정각을 피하세요. 0 0 * * *처럼 정각에 몰아 두면 여러 작업이 동시에 실행되어 부하가 튑니다. 7 3 * * *처럼 어중간한 시각으로 흩뜨리는 편이 안전합니다.

실패를 알 수 있어야 합니다. cron은 조용히 실패합니다. 로그를 남기고 실패 시 알림이 오도록 해 두지 않으면 몇 달째 안 돌고 있는 것을 모를 수 있습니다.

함께 확인하면 좋은 것

실행 시각을 타임스탬프로 다루려면 타임스탬프 변환기를, 날짜 간격 계산은 날짜 계산기를 이용하세요.