다섯 개의 필드
표준 크론(POSIX, 그리고 리눅스 배포판에 들어 있는 Vixie 계열 데몬)은 공백으로 구분한 다섯 개 필드 뒤에 명령을 둡니다. 현재 시각의 분이 모든 필드에 동시에 맞을 때마다 작업이 실행됩니다.
각 필드에는 값 하나, 범위, 목록, 스텝, 또는 허용되는 모든 값을 뜻하는 *를 쓸 수 있습니다. 월과 요일은 대부분의 구현에서 영어 약자(JAN, MON)도 받습니다. 일요일은 0이고, 많은 구현이 7도 일요일로 인정합니다.
| 위치 | 필드 | 허용 값 | 비고 |
|---|---|---|---|
| 1 | 분 | 0-59 | |
| 2 | 시 | 0-23 | 24시간제, 서버 로컬 시간 기준 |
| 3 | 일 | 1-31 | 31일 지정 시 30일까지인 달은 건너뜀 |
| 4 | 월 | 1-12 또는 JAN-DEC | |
| 5 | 요일 | 0-6 또는 SUN-SAT | 0이 일요일이며 대부분 7도 일요일 |
# 분 시 일 월 요일 명령
30 2 * * 1-5 /usr/local/bin/backup.sh범위, 목록, 스텝
범위 a-b는 양 끝을 모두 포함합니다. 시 필드의 9-17은 9, 10, ... 17로 아홉 개입니다. 목록은 쉼표로 잇습니다. 1,15는 1일과 15일입니다. 둘은 섞어 쓸 수 있어서 1-5,10은 1, 2, 3, 4, 5, 10입니다.
스텝 */n은 필드의 첫 허용 값부터 세어 n번째마다라는 뜻입니다. 분 필드의 */15는 0, 15, 30, 45입니다. 범위 뒤에도 쓸 수 있어서 10-40/10은 10, 20, 30, 40입니다.
스텝은 n단위 시간마다라는 뜻이 아닙니다. 필드가 한 바퀴 돌면 다시 처음부터 시작합니다. 분 필드의 */7은 0, 7, 14, 21, 28, 35, 42, 49, 56이고 다음 시간에는 다시 0부터 시작하므로, :56과 :00 사이는 7분이 아니라 4분입니다. 0 */5 * * *는 0시, 5시, 10시, 15시, 20시에 실행되고 자정까지는 4시간만 기다립니다. 일정한 간격이 꼭 필요하면 필드 범위의 약수(분은 5, 10, 15, 20, 30, 시는 2, 3, 4, 6, 8, 12)를 쓰거나 다른 스케줄러를 쓰세요.
일·요일 필드의 OR 규칙
크론에서 가장 놀라운 규칙입니다. 일 필드와 요일 필드가 둘 다 제한되어 있으면(둘 다 *가 아니면) 두 조건을 모두 만족할 때가 아니라 둘 중 하나만 맞아도 실행됩니다. POSIX가 정한 동작입니다. 그래서 0 0 13 * 5는 13일의 금요일이 아닙니다. 매월 13일 자정과 매주 금요일 자정에 모두 실행됩니다.
Vixie 계열 데몬에는 한 가지 예외가 있습니다. 어느 한쪽의 일 필드가 */2처럼 제한된 스텝이어도 문자열이 *로 시작하면 두 필드를 AND로 묶습니다. 따라서 0 0 */2 * 1은 홀수 날짜(1, 3, 5, ...)이면서 월요일인 날에만 실행됩니다. 다른 구현은 다를 수 있으므로 대상 스케줄러에서 확인하세요.
이식 가능한 AND나 매월 첫 금요일 같은 조건은 한 필드로 스케줄하고 다른 조건을 명령 안에서 검사하세요. 매월 첫 금요일은 날짜가 7 이하인 금요일입니다. crontab에서 %는 특수 문자이므로 백슬래시로 이스케이프해야 합니다.
# 매월 첫째 금요일 06:00
0 6 * * 5 [ "$(date +\%d)" -le 7 ] && /usr/local/bin/monthly-report.sh
# 매월 말일 23:55: 28~31일에 실행하고, 내일이 1일일 때만 진행
55 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && /usr/local/bin/month-end.sh바로 복사해 쓰는 스케줄 20개
아래 행은 모두 위의 필드 규칙으로 확인한 것입니다. 시각은 데몬이 쓰는 시간대 기준이며, 보통은 서버의 시스템 시간대입니다.
| 표현식 | 의미 |
|---|---|
| * * * * * | 매분 |
| */5 * * * * | 5분마다 (:00, :05, :10 ...) |
| */15 * * * * | 15분마다 (:00, :15, :30, :45) |
| 0 * * * * | 매시 정각 |
| 0 */6 * * * | 6시간마다: 00:00, 06:00, 12:00, 18:00 |
| 0 0 * * * | 매일 자정 |
| 30 2 * * * | 매일 02:30 (쓰기 전에 서머타임 절을 확인하세요) |
| 0 9 * * 1-5 | 평일 09:00 |
| 0 9-17 * * 1-5 | 평일 09:00부터 17:00까지 매시 정각 (하루 9회) |
| */10 9-17 * * 1-5 | 평일 09:00~17:59 사이 10분마다 |
| 0 0 * * 0 | 매주 일요일 자정 |
| 0 8 * * 1 | 매주 월요일 08:00 |
| 0 22 * * 1-5 | 평일 22:00 (야간 배치) |
| 0 12 * * 6,0 | 토요일과 일요일 정오 |
| 0 0 1 * * | 매월 1일 자정 |
| 0 0 1,15 * * | 매월 1일과 15일 |
| 0 0 1 */3 * | 분기 첫날 (1, 4, 7, 10월) |
| 0 0 1 1 * | 매년 1월 1일 |
| 0 0 28-31 * * | 28~31일 (명령 안에서 월말 검사와 함께 사용) |
| 0 0 13 * 5 | 매월 13일과 매주 금요일 모두 (OR 규칙, 13일의 금요일이 아님) |
시간대와 서머타임
크론에는 자체 시간대가 없습니다. 데몬은 머신에 설정된 로컬 시간대의 시계를 읽으므로, 같은 crontab도 시간대가 다른 서버에서는 서로 다른 순간에 실행되고, 컨테이너는 대개 UTC가 기본입니다. cronie 같은 일부 구현은 crontab 안의 CRON_TZ= 변수를 받지만 무시하는 구현도 있으니, 의존하기 전에 사용하는 데몬의 매뉴얼을 확인하세요. 관리형 스케줄러는 또 다릅니다. GitHub Actions의 schedule은 항상 UTC이고, Kubernetes CronJob은 .spec.timeZone을 지정하지 않으면 컨트롤러 매니저의 시간대를 따릅니다. 이 필드는 Kubernetes 1.27부터 stable입니다.
서머타임은 로컬 시간 스케줄을 취약하게 만듭니다. America/New_York에서 2026년 3월 8일(일)에는 시계가 02:00에서 03:00으로 건너뛰므로 그날은 02:30이 존재하지 않습니다. 2026년 11월 1일(일)에는 02:00에서 01:00으로 되돌아가 01:00~01:59가 두 번 나타납니다. cronie 같은 Vixie 계열 데몬은 3시간 미만의 시각 변경에 대한 별도 처리(건너뛴 시간대의 고정 시각 작업은 변경 직후 실행, 반복된 시간대에서는 다시 실행하지 않음)를 문서화하고 있지만 BusyBox나 일부 컨테이너 이미지는 그렇지 않아서, 30 1 * * * 작업이 두 번 실행되거나 30 2 * * * 작업이 건너뛰어질 수 있습니다.
안정적인 방법은 세 가지입니다. 서버를 UTC로 두고 스케줄도 UTC로 쓰거나, 01:00~03:00 구간을 피하거나, 작업을 멱등으로 만들어 두 번 실행되어도 안전하게 하는 것입니다. 표현식이 시간대별로 어떤 시각을 뜻하는지 보려면 시간대 변환 도구로 순간을 바꿔 보고, 에포크 변환기로 실제 실행 시각의 타임스탬프를 비교하세요.
크론, Quartz, systemd 타이머의 차이
서로 다른 세 가지 스케줄 문법이 모두 크론이라고 불리고, 이를 섞어 쓰면 유효해 보이는데 틀린 스케줄이 나옵니다. 아래 표는 세 방식의 비교이며, 표준 크론의 설명이 아닙니다.
Quartz(많은 Java 애플리케이션이 사용)와 Spring의 @Scheduled는 초부터 시작하는 6~7개 필드를 씁니다. Quartz는 일 또는 요일 필드 중 하나에 반드시 ?를 쓰게 하고, 요일은 일요일을 1로 하는 1~7이며 L(마지막), W(가장 가까운 평일), #(n번째 요일)을 추가로 지원합니다. systemd 타이머는 OnCalendar=와 다른 날짜 형식을 쓰며, 요일과 날짜 조건을 OR이 아니라 AND로 결합합니다.
| 항목 | 표준 크론 | Quartz / Spring | systemd 타이머 |
|---|---|---|---|
| 필드 | 5개: 분 시 일 월 요일 | 6~7개: 초 분 시 일 월 요일 [연] | OnCalendar=요일 YYYY-MM-DD HH:MM:SS |
| 요일 숫자 | 0이 일요일 (대부분 7도 일요일) | Quartz는 1~7 = 일~토 | 이름 사용: Mon..Sun |
| 일 + 요일 동시 지정 | 둘 다 *로 시작하지 않으면 OR, 한쪽이 *로 시작하면 Vixie cron은 AND | 불가, 하나는 ? 여야 함 | AND |
| 특수 토큰 | 이름, @daily, @reboot (데몬에 따라 다름) | L, W, #, ? | daily, weekly, Mon..Fri 같은 범위 |
| 평일 09:00 | 0 9 * * 1-5 | 0 0 9 ? * MON-FRI | OnCalendar=Mon..Fri *-*-* 09:00:00 |
| 15분마다 | */15 * * * * | 0 0/15 * * * ? | OnCalendar=*:0/15 |
| 놓친 실행 | 머신이 꺼져 있었으면 건너뜀 | 트리거별 misfire 정책 | Persistent=true면 부팅 후 실행 |
짧은 디버깅 순서
작업이 실행되지 않으면 이 순서로 확인하세요. 먼저 표현식이 의도한 대로 해석되는지, 평문 설명과 다음 실행 시각 다섯 개를 보고 확인합니다. 필드 순서를 잘못 쓴 실수는 바로 드러납니다. 둘째, 노트북이 아니라 데몬의 시간대를 확인합니다. 셋째, 크론은 최소한의 환경으로 실행된다는 점을 기억하세요. 로그인 셸이 없고 PATH가 짧으며 프로필의 변수도 없으므로, 절대 경로를 쓰고 변수는 crontab에 직접 선언합니다. 넷째, 출력을 리다이렉트하세요(>> /var/log/job.log 2>&1). 그렇지 않으면 크론이 로컬 사용자에게 메일로 보내고, 아무도 읽지 않습니다.
단축 문자열과 그 의미
Vixie 계열 데몬은 다섯 필드 대신 몇 가지 @ 단축 표기를 받습니다. 편리하지만 이식성은 없습니다. BusyBox crond, 일부 호스팅 스케줄러, Quartz는 인식하지 못하고, @reboot은 평범한 다섯 필드 표현식으로는 대응되는 것이 없습니다.
| 단축 표기 | 동등한 표현식 | 실행 시점 |
|---|---|---|
| @hourly | 0 * * * * | 매시 0분 |
| @daily 또는 @midnight | 0 0 * * * | 매일 00:00 |
| @weekly | 0 0 * * 0 | 일요일 00:00 |
| @monthly | 0 0 1 * * | 매월 1일 00:00 |
| @yearly 또는 @annually | 0 0 1 1 * | 1월 1일 00:00 |
| @reboot | (없음) | 데몬이 시작될 때 한 번 |
까다로운 표현식 세 가지 읽기
0 0 */2 * *는 격일처럼 보이지만 스텝이 일 필드의 범위 1-31에 적용되므로 1, 3, 5일 식으로 31일까지 실행됩니다. 31일까지 있는 달에는 마지막 실행이 31일이고 다음 실행은 다음 달 1일이라서, 달이 바뀔 때마다 이틀 연속으로 실행됩니다. 엄밀한 48시간 간격이 필요하면 크론으로는 표현할 수 없으니 마지막 실행 시각을 기록하는 타이머를 쓰세요.
0 9-17/2 * * 1-5는 범위에 스텝을 적용한 것으로, 평일 9, 11, 13, 15, 17시에 하루 다섯 번 실행됩니다. 아홉 번 실행되는 0 9-17 * * 1-5와 비교해 보세요. 15,45 8-9 * * 1-5는 목록과 범위를 합쳐 평일 08:15, 08:45, 09:15, 09:45, 모두 네 번 실행됩니다.
중복 실행, 잠금, 서버 여러 대
크론은 이전 실행이 끝났는지와 관계없이 예약 시각에 작업을 시작합니다. 가끔 7분이 걸리는 */5 * * * * 작업은 자기 자신과 겹치고, 같은 파일이나 데이터베이스에 쓰는 사본이 둘이 되면 데이터가 깨지는 전형적인 원인이 됩니다. 명령을 잠금으로 감싸세요. 예를 들어 flock -n /tmp/report.lock /usr/local/bin/report.sh에서 -n은 두 번째 사본이 기다리지 않고 즉시 종료하게 합니다.
서버 백 대가 같은 crontab을 쓰면 0 * * * *는 모두가 같은 초에 데이터베이스를 칩니다. 명령 안에 무작위 지연을 넣거나 호스트마다 분을 다르게 정해 부하를 분산하세요. 일부 스케줄러는 이를 위한 해시 문법을 내장합니다. 예컨대 Jenkins는 H/15 * * * *를 받는데, 작업마다 안정적인 오프셋을 고르는 Jenkins 전용 확장이며 표준 크론에서는 유효하지 않습니다.
마지막으로 크론이 제공하지 않는 것을 기억하세요. 재시도, 실패 알림, 머신이 꺼져 있어 실행을 건너뛰었는지에 대한 기록이 없습니다. 출력을 로그로 리다이렉트하고, 하트비트 확인이나 데드맨 스위치 모니터를 추가하고, 두 번 실행되어도 무해하도록 작업을 멱등으로 만드세요.