Cron 표현식 해석기 & 빌더
Unix, Spring, Quartz, AWS의 cron 표현식을 해석하고, 원하는 시간대로 다음 실행 시각을 확인하거나 필드별로 표현식을 만듭니다.
일정
필드별 해석
| 필드 | 표현식 | 값 |
|---|
다음 실행 시각
비주얼 빌더
필드마다 반복 방식을 고르세요. “특정 값”에는 1,15나 MON,WED 같은 목록을, “범위”에는 9-17처럼 시작-끝을, “N마다”에는 간격을 입력합니다.
특수문자
| * | 필드의 모든 값. |
| , | 값 목록. 예: 1,15,30 |
| - | 범위. 예: 9-17, MON-FRI |
| / | 간격. 예: */15 = 15마다, 5/15 = 5부터 15마다 (Unix cron에서는 지원 안 함) |
| ? | 지정 안 함. Quartz와 AWS는 일 또는 요일 중 한 필드에 반드시 필요합니다. |
| L | 마지막: 일 필드의 L = 말일, L-3 = 말일 3일 전, 요일 필드의 5L = 마지막 목요일(Quartz 번호 기준). |
| W | 가장 가까운 평일: 15W = 15일에 가장 가까운 평일, LW = 그달의 마지막 평일. |
| # | 그달의 N번째 요일: Quartz/AWS에서 6#3 = 셋째 금요일(1 = 일요일), Spring에서는 5#3(0 = 일요일). |
| @daily … | 매크로: @yearly, @monthly, @weekly, @daily, @hourly. @reboot는 시작할 때 한 번 실행됩니다. |
사용 방법
- "Cron 표현식"에 일정을 입력하거나 붙여넣으세요. 예시 중 하나를 눌러도 되며, 이때 "형식"도 "자동 감지"로 바뀝니다. 입력하는 동안 요약과 실행 시각이 갱신됩니다.
- "형식"을 "자동 감지"로 두거나 표현식을 쓸 시스템을 선택하세요. 자동 감지는 필드 5개를 Unix로, 7개를 Quartz로 읽습니다. 필드가 6개이면 "?"의 위치를 보고 AWS나 Quartz를 고르고, 마지막 필드에 1970~2199년의 연도가 있으면 AWS로, 그 밖에는 Spring으로 봅니다. @weekly 같은 매크로는 Unix로 읽습니다. 표현식이 올바르면 상태 줄에 사용한 형식이 표시됩니다.
- "일정"과 "필드별 해석"에서 각 필드가 무엇과 일치하는지 확인한 다음, "다음 실행 시각"의 날짜를 확인하세요. "시간대"는 처음에 브라우저의 시간대로 설정되어 있으니 필요하면 다른 시간대를 고르고, "표시할 실행 횟수"에서 5, 10, 20 중 하나를 선택하세요. UTC가 아닌 시간대에서는 각 실행 시각에 UTC 시각도 함께 표시됩니다.
- 표현식을 직접 만들려면 "비주얼 빌더"를 열고 형식을 고른 뒤 필드마다 반복 방식을 선택하고, 값이 필요한 필드에는 값을 입력하세요. "이 표현식 사용"을 누르면 "만들어진 표현식"이 "Cron 표현식"에 들어가고 "형식"이 빌더의 형식으로 바뀐 뒤 해석되므로, 실행 시각을 확인할 수 있습니다.
자주 묻는 질문
입력한 표현식이 어딘가로 전송되나요?
아니요. 표현식 해석과 실행 시각 계산은 브라우저에서 JavaScript로 이루어지며, 표현식은 LeedyBox로 업로드되지 않습니다.
0 0 13 * 5가 13일의 금요일에만 실행되지 않고 매주 금요일에 실행되는 이유는 무엇인가요?
Unix cron에서는 일(day of month)과 요일(day of week)이 모두 제한되어 있으면(둘 다 *로 시작하지 않으면) 둘 중 한 필드만 맞아도 실행되므로, 이 표현식은 매월 13일과 매주 금요일에 실행됩니다. 이 도구는 Unix 표현식에 이 규칙을 적용하며, 이때 "일정"에 "둘 중 하나만 맞으면 실행"이라고 표시됩니다. Spring 표현식은 두 필드가 모두 맞아야 실행되는 것으로 보고, Quartz와 AWS는 두 필드 중 하나에 반드시 "?"를 쓰게 해서 이 문제를 피합니다. Unix cron에서는 매주 금요일로 일정을 잡고 작업 안에서 날짜를 확인하는 방법이 흔히 쓰입니다.
일요일은 0인가요, 1인가요, 7인가요?
형식에 따라 다릅니다. Unix와 Spring 표현식에서는 0과 7이 모두 일요일이고 1이 월요일입니다. Quartz와 AWS에서는 1이 일요일, 7이 토요일이므로 1-5는 일요일부터 목요일까지를 뜻합니다. Spring, Quartz, AWS에서는 MON-FRI처럼 요일 이름을 쓰면 이런 차이를 피할 수 있습니다.
crontab 줄이나 AWS cron( ) 표현식을 넣으면 왜 오류가 나나요?
일정 필드만 입력하세요. crontab 줄 끝의 명령과 /etc/crontab의 사용자 이름은 추가 필드로 세어지므로, 잘못된 필드나 필드 개수 오류가 표시됩니다. AWS는 cron( )을 빼고 괄호 안의 필드 6개만 붙여넣으세요.
Unix 표현식을 Spring, Quartz, AWS용으로 바꾸려면 어떻게 하나요?
Spring은 맨 앞에 초 필드가 붙으므로 0 9 * * 1-5는 0 0 9 * * 1-5가 됩니다. Quartz는 여기에 더해 일 필드와 요일 필드 중 하나에 "?"가 필요하고 일요일을 1로 세므로, 같은 일정은 0 0 9 ? * MON-FRI입니다. AWS는 초 필드가 없고, Quartz처럼 일 필드와 요일 필드 중 하나에 "?"가 필요하며, 끝에 연도가 붙어 0 9 ? * MON-FRI *가 됩니다. Unix 표현식이 일과 요일 필드를 모두 제한한다면 앞에서 설명한 '둘 중 하나' 규칙에 기대는 것인데, 이 형식들은 그 규칙을 쓰지 않으므로 보통 일정을 두 개로 나눠야 합니다. 바꾼 결과는 대상 형식을 선택한 상태에서 확인하고 다음 실행 시각을 비교해 보세요.
실행 시각을 찾지 못했다고 나오는 이유는 무엇인가요?
표현식은 올바르지만, 이 도구가 찾아보는 앞으로 약 8년 안에 맞는 시각이 없다는 뜻입니다. 흔한 원인은 0 0 30 2 *(2월 30일)처럼 존재하지 않는 날짜, 31일을 30일까지만 있는 달과만 조합한 경우, 이미 지난 연도를 적은 연도 필드입니다. 8년보다 더 먼 연도를 지정해도 같은 메시지가 나오지만, 그 일정은 나중에 실행될 수 있습니다. 전통적인 Unix cron을 비롯한 일부 스케줄러는 존재하지 않는 날짜를 경고 없이 받아들이며, 작업은 실행되지 않습니다.
어떤 시간대를 쓰며, 서머타임은 어떻게 처리되나요?
실행 시각은 "시간대"에서 선택한 시간대를 기준으로 계산합니다. 스케줄러가 쓰는 시간대를 고르세요. crontab은 보통 서버의 시간대를 따르고, AWS EventBridge의 예약 규칙은 UTC를 쓰며, EventBridge Scheduler는 시간대를 지정할 수 있습니다. 메뉴에는 브라우저의 시간대, UTC, 자주 쓰는 시간대 몇 가지가 있습니다. 스케줄러의 시간대가 메뉴에 없으면 UTC 오프셋과 서머타임 적용 날짜가 같은 시간대를 고르세요. 시계를 앞당길 때 건너뛰는 시각의 실행은 목록에서 빠지고, 시계를 되돌릴 때 두 번 오는 시각은 한 번만 표시됩니다. cron 데몬마다 이런 시각을 처리하는 방식이 다르며, 예를 들어 cronie는 건너뛴 시간의 작업을 시간이 바뀐 직후에 실행할 수 있습니다. 사용하는 스케줄러의 동작을 확인하거나, 서머타임이 없는 UTC를 쓰세요.