Cron 표현식 해석기

다섯 개의 필드

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

분  시  일  월  요일
*   *   *   *   *

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

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

특수 문자

* — 해당 필드의 모든 값. * * * * *는 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 * * *로 써야 합니다.

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

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

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

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

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

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

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

실무에서 주의할 점

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

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

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

함께 확인하면 좋은 것

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