Cron 표현식 해석기

Cron 표현식의 5개 필드와 6필드 형식

표준 Cron 표현식은 왼쪽부터 분, 시, 일, 월, 요일 순서로 5개 필드를 공백으로 구분해 씁니다. 각 필드에서는 네 가지 기호를 조합합니다.

• * : 해당 필드의 모든 값
• 1,3,5 : 목록 (쉼표 앞뒤에 공백을 넣으면 안 됨)
• 1-5 : 범위 (양 끝 포함)
• */15 또는 10-40/10 : 간격(step). 시작값부터 step씩 더해 가며 범위를 넘으면 멈춤

Linux의 crontab과 대부분의 CI 도구는 5필드를 쓰지만, Quartz·Spring·node-cron처럼 초 단위 작업이 필요한 라이브러리는 맨 앞에 초 필드를 추가한 6필드를 씁니다. 같은 문자열 0 9 * * 1-5(5필드)와 0 0 9 * * 1-5(6필드)는 모두 "평일 9시 정각"을 뜻하지만, 필드 수를 헷갈려 5필드 식을 6필드 도구에 넣으면 각 값이 한 칸씩 밀려 전혀 다른 시각이 됩니다. 이 도구는 필드가 5개면 5필드, 6개면 6필드(초 시작)로 자동 판별합니다.

구현체마다 다른 점

Cron은 하나의 표준 문서가 아니라 여러 구현의 관습입니다. 아래는 널리 알려진 사양을 정리한 것이며, 버전에 따라 달라질 수 있으니 실제 사용하는 도구의 공식 문서를 최종 확인하세요.

가장 흔한 사고는 요일 번호입니다. Vixie 계열에서 일요일은 0(또는 7)이고 수요일은 3이지만, Quartz와 AWS EventBridge는 1이 일요일이라 수요일이 4입니다. 숫자 대신 MON-FRI 같은 이름을 쓰면 이 차이를 피할 수 있습니다. 이 도구는 Vixie 계열(0과 7이 일요일) 기준으로 해석하며 Quartz 전용 기호 ?, L, W, #를 만나면 지원하지 않는다고 알려 줍니다.

일(day)과 요일(weekday)이 동시에 지정되면?

Vixie 계열 cron과 POSIX 규칙에서는 일 필드와 요일 필드가 둘 다 제한된 값(맨 앞이 *가 아닌 값)이면, 둘 중 하나라도 만족하는 날 실행됩니다(OR). 한쪽이 *로 시작하면 다른 쪽 조건만 적용됩니다. 그래서 "매월 첫째 일요일"은 0 0 1-7 * 0으로 쓸 수 없습니다. 이 식은 1~7일이거나 일요일인 날(매주 일요일 + 매월 1~7일) 모두에서 실행됩니다. 첫째 일요일만 원하면 크론 식은 매주 일요일로 두고 스크립트 안에서 날짜가 7 이하인지 검사하는 방식이 흔합니다.

참고로 이 도구는 Vixie 방식대로 필드가 *로 시작하는지로 제한 여부를 판단합니다. 그래서 */2처럼 별표로 시작하는 일 필드는 "제한 없음"으로 취급되어 요일 조건과 OR가 아닌 AND로 결합됩니다. Quartz처럼 둘을 동시에 지정할 수 없게 하거나 Spring처럼 다르게 처리하는 구현도 있으므로, 같은 식이라도 도구에 따라 결과가 달라질 수 있습니다.

간격(/)의 함정

*/n은 "n 간격으로 반복"이 아니라 "범위의 시작값부터 n씩 더한 값들만 허용"입니다. 범위가 n의 배수로 끝나지 않으면 마지막 간격이 짧아집니다.

• */7 * * * * : 분이 0, 7, 14, 21, 28, 35, 42, 49, 56일 때 실행(시간당 9회). 56분 다음은 같은 시간이 아니라 다음 시간 0분이므로 마지막 간격은 4분입니다.
• 0 */5 * * * : 시가 0, 5, 10, 15, 20일 때 실행. 20시 다음은 다음 날 0시라서 4시간 간격이 됩니다.
• */60 * * * * : 분 범위가 0~59이므로 0분만 맞아 매시 정각과 같습니다. "60분마다"는 0 * * * *로 쓰는 것이 명확합니다.

시작점이 있는 5/15(5부터 15 간격) 같은 표기는 구현마다 허용 여부가 갈립니다. 이 도구는 5-59/15와 같게 5, 20, 35, 50으로 해석하지만, 이식성을 위해서는 범위를 명시한 5-59/15를 쓰는 편이 안전합니다.

시간대와 서머타임

Cron의 시각은 실행 환경의 시간대로 해석됩니다. 서버가 UTC라면 한국 시간(UTC+9) 오전 9시에 돌리려면 0 0 * * *이어야 합니다(UTC 0시 = KST 9시). GitHub Actions의 schedule은 UTC 기준이므로 한국 시간 오전 9시는 0 0 * * *입니다. 위 도구에서 시간대를 UTC로 바꾸면 UTC 기준 다음 실행 시각을 확인할 수 있습니다. 한국에는 서머타임이 없지만 서머타임이 있는 지역의 시간대를 쓰는 서버에서는 해당 시각이 건너뛰어지거나 두 번 나타날 수 있고, 처리 방식은 구현마다 다릅니다. 이 도구는 현지 시간 모드에서 존재하지 않는 시각(시간이 앞당겨져 사라진 구간)은 건너뜁니다.

검산 예시

예시 1 (OR 규칙): 0 0 1 * 0을 2026년 10월에 적용하면 10월 1일(목요일)과 일요일인 4일, 11일, 18일, 25일, 총 5번 실행됩니다. "매월 1일이면서 일요일"이라는 AND로 오해하면 10월에는 한 번도 실행되지 않는다고 생각하게 됩니다.

예시 2 (실행 횟수): */15 9-17 * * 1-5는 하루에 시 9~17(9개) × 분 0·15·30·45(4개) = 36번, 평일 5일 동안 180번 실행됩니다. 마지막 실행은 17:45이며 18:00에는 실행되지 않습니다.

예시 3 (존재하지 않는 날짜): 0 0 31 * *은 31일이 있는 달에만 실행되어 1년에 7번입니다. 0 0 30 2 *은 2월 30일이 없으므로 영원히 실행되지 않으며, 이 도구는 이런 식을 만나면 해당 사실을 알려 줍니다.

실무에서 자주 하는 실수

• 매월 마지막 날: 표준 5필드에는 "마지막 날" 표기가 없습니다(Quartz의 L은 확장 기능). 보통 0 0 28-31 * *로 실행한 뒤 스크립트에서 내일이 1일인지 검사합니다.
• 작업이 끝나기 전에 다음 실행: 1분마다 도는 작업이 2분 걸리면 겹쳐 실행됩니다. 잠금(lock)이나 중복 실행 방지 옵션을 두세요.
• 환경 변수와 경로: crontab은 로그인 셸과 환경이 달라 PATH가 짧습니다. 명령은 절대 경로로 쓰고, 출력을 로그 파일로 리다이렉트해 두면 원인 추적이 쉽습니다.
• 퍼센트 기호: crontab 명령줄에서 %는 줄바꿈으로 처리되므로 date +%Y처럼 쓸 때는 \%로 이스케이프해야 합니다.
• 정각 몰림: 모두 0 * * * *로 맞추면 정각에 부하가 몰립니다. 임의의 분(예: 7분)을 고르면 분산됩니다.

이 도구가 하지 않는 것

• Quartz·AWS 전용 문법(?, L, W, #, 년 필드)은 해석하지 않습니다.
• @reboot처럼 시각이 아닌 이벤트 기반 매크로는 실행 시각을 계산할 수 없습니다.
• 실제 서버의 시간대, 서머타임, 서버 부하로 인한 지연은 반영하지 않습니다. 중요한 작업은 운영 환경에서 실제 로그로 한 번 더 확인하세요.

표현식에 쓸 정규식을 점검하려면 정규식 테스터를, 실행 시각을 숫자 타임스탬프로 다룰 때는 Unix 타임스탬프 변환기를, 작업 ID로 쓸 고유 값이 필요하면 UUID 생성기를, 스케줄러가 호출하는 API 토큰의 만료를 확인하려면 JWT 디코더를 함께 활용해 보세요. 작업 결과 JSON 로그를 정리할 때는 JSON 포맷터가 편리합니다.

자주 묻는 질문