crontab 생성기 & cron 표현식 빌더

cron 표현식이란 무엇인가요?

# Linux crontab entry — runs every 15 minutes
*/15 * * * *  /usr/local/bin/poll-api.sh

# Kubernetes CronJob — weekdays at 9:00 AM UTC
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-report
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "UTC"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: report
              image: report-runner:1.0
          restartPolicy: OnFailure

# GitHub Actions workflow — hourly
on:
  schedule:
    - cron: '0 * * * *'

# AWS EventBridge — first of each month
ScheduleExpression: cron(0 0 1 * ? *)
# (Note: AWS uses the Quartz 6-field form with '?' for day-of-week)

주요 기능

cron 변종과 스케줄러

cron 표현식 예시

*/15 * * * *

0 9 * * 1-5

0 0 1 * *

*/5 9-17 * * 1-5

0 0 1 JAN,APR,JUL,OCT *

0 0 1 * 5

30 2 * * *

@daily

cron 표현식 만드는 방법

1. 1

   cron 표현식을 입력하거나 붙여넣기

   상단 입력란에 다섯 필드 cron 표현식(예: `*/15 * * * *`)을 입력하십시오. 본 도구는 입력하는 동안 파싱과 검증을 수행합니다. 유효하면 녹색 체크, 유효하지 않으면 필드 이름이 표시된 적색 오류가 나타납니다. `@daily`, `@hourly` 등의 매크로도 받아들입니다.

2. 2

   또는 다섯 필드 입력을 조정

   필드 순서를 외울 필요가 없습니다. 라벨이 붙은 입력으로 분, 시, 일, 월, 요일을 개별적으로 편집할 수 있습니다. 상단의 전체 표현식이 자동으로 갱신됩니다. 와일드카드에는 `*`, 단계에는 `*/N`, 범위에는 `a-b`, 목록에는 `1,3,5`를 사용하십시오.

3. 3

   프리셋으로 출발점 잡기

   프리셋 칩(15분마다, 평일 오전 9시 등)을 눌러 자주 쓰는 스케줄을 불러온 뒤 필요에 맞게 필드를 다듬으십시오. 열한 개의 프리셋이 실제 운영에서 쓰는 패턴을 모두 다룹니다.

4. 4

   다음 실행 미리보기 확인

   예정된 다섯 개의 실행 날짜·시간을 보십시오. 로컬과 UTC를 전환해 의도한 시각에 스케줄이 실행되는지 확인하십시오. POSIX의 일·요일 OR 함정이 운영에서 문제를 일으키기 전에 잡아내는 가장 확실한 방법입니다.

5. 5

   복사해 스케줄러에 붙여넣기

   복사를 눌러 표현식을 클립보드에 담으십시오. crontab, systemd 타이머, GitHub Actions `cron:`, AWS EventBridge, Kubernetes CronJob `schedule` 또는 cron 호환 스케줄러에 붙여넣을 수 있습니다. 대상 스케줄러의 시간대도 잊지 말고 확인하십시오. 아래 모범 사례 섹션을 참고하십시오.

흔한 cron 실수

# 의도: "매월 첫째 금요일"
0 0 1-7 * 5
# 실제: 매월 1-7일 OR 매주 금요일 — 두 조건 모두

# 진짜 AND 의미를 위해 래퍼 사용
0 0 * * 5  [ $(date +\%d) -le 7 ] && /your-script
# 또는 한 조건을 떨어내고 더 느슨한 스케줄을 수용

# 미국 동부 개발자가 작성, UTC 서버에 배포
0 9 * * *  /your-report.sh
# 오전 9시 UTC = 미국 동부 오전 4시에 실행 — 개발자의 의도와 다름

# 시간대 고정, 또는 명시적으로 UTC로 작성
CRON_TZ=America/New_York
0 9 * * *  /your-report.sh

# 의도: 15분마다
15 * * * *
# 실제: 매시간 분 15에 한 번 (의도보다 시간당 4회 적음)

# 올바른 표현
*/15 * * * *
# 15분마다: 매시간 분 0, 15, 30, 45

# Linux crontab에 복사된 Quartz 6필드
0 0 9 * * 1-5
# Linux 해석: 분=0, 시=0, 일=9, 월=*, 요일=1-5
# = 평일과 일치하는 월의 9일 자정 — 혼돈

# POSIX 5필드, 초 떨어내기
0 9 * * 1-5
# = 평일 오전 9시

# 2월 30일 또는 31일 — 절대 실행되지 않음
0 0 30 2 *
0 0 31 2 *
# 파싱되지만 어떤 스케줄도 실행되지 않음

# 스크립트로 '2월 마지막 평일' 패턴 구현
0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /your-script

# Quartz: '월의 마지막 금요일' — POSIX에서 유효하지 않음
0 0 ? * 6L *

# 마지막 금요일에 대한 POSIX 래퍼 스크립트 방식
0 0 25-31 * 5  /your-script
# 어느 월이든 25-31일 사이의 금요일에 실행

일반 활용 사례

Linux crontab 작업

`/etc/crontab`, `/etc/cron.d/*`, 또는 사용자별 `crontab -e` 파일의 항목을 만들고 검증합니다. 저장 전에 다음 실행 미리보기로 스케줄이 서버의 구성된 시간대 기준으로 올바른 시각에 떨어지는지 확인하십시오.

Kubernetes CronJob 스케줄

Kubernetes CronJob의 `spec.schedule` 필드를 생성합니다. Kubernetes 1.27+는 `spec.timeZone`도 지원합니다. UTC 토글로 UTC 기준으로 스케줄을 설계한 뒤 `timeZone`을 명시적으로 설정해 워커 노드의 로컬 시간을 피하십시오.

GitHub Actions 예약 워크플로

`on.schedule` 아래 `cron:` 항목을 만듭니다. GitHub Actions는 언제나 UTC로 실행됩니다. 미리보기를 UTC로 토글해 스케줄을 확인하십시오. 15분보다 짧은 간격은 피하십시오. GitHub 스케줄러는 부하 상황에서 짧은 간격 작업을 자주 건너뜁니다.

AWS EventBridge 규칙

EventBridge 예약 규칙용 cron 표현식을 구성합니다. 참고: AWS는 요일에 `?`를 쓰는 Quartz 스타일 6필드 문법을 사용합니다. 본 도구는 POSIX 5필드를 생성하므로 초(`0`)를 앞에 붙이고 두 일 필드 중 하나의 `*`를 `?`로 바꿔야 합니다.

GitLab CI 예약 파이프라인

GitLab의 예약 CI 파이프라인용 cron 표현식을 확인합니다. GitLab은 본 도구가 생성하는 POSIX 5필드 문법과 UI 날짜 선택기를 사용하지만, 비표준 간격에 더 세밀한 제어가 필요할 때는 cron 형식이 유리합니다.

Cloudflare Workers Cron Triggers

`wrangler.toml`의 `[triggers.crons]` 항목을 만듭니다. Cloudflare는 POSIX 5필드 문법을 사용합니다. 최소 간격은 1분이며 워커는 UTC로 실행됩니다. 트리거가 예상한 시간 창 안에 실행되는지 미리보기로 확인하십시오.

Node.js node-cron 스케줄

다섯 필드 POSIX와 선택적 선두 초 필드를 모두 지원하는 `node-cron` 라이브러리용 표현식을 만듭니다. 1분 미만 정밀도가 꼭 필요한 경우가 아니라면 다섯 필드를 사용하십시오. 6필드 표현식은 Linux crontab으로 이식되지 않습니다.

코드 리뷰와 문서화

PR이나 런북의 cron 표현식을 붙여넣어 무엇을 하는지 즉시 확인하십시오. 더 이상 `30 7 * * 1-5`를 추측하거나 참조 카드를 꺼낼 필요가 없습니다. 자연어 설명은 인라인 주석이나 README 파일에도 적합합니다.

cron 문법 참조

필드 순서: M H D M W

분(0-59), 시(0-23), 일(1-31), 월(1-12), 요일(0-6, 7도 일요일). 요일 필드는 숫자(0-6)와 이름(SUN-SAT, 대소문자 무시) 토큰을 모두 받습니다.

연산자

`*` = 임의의 값; `,` = 목록 구분자(`1,3,5`); `-` = 범위(`1-5`); `/` = 단계(`*/15`, `5/10`); 이름: 월은 JAN-DEC, 요일은 SUN-SAT(대소문자 무시).

매크로(별칭)

`@yearly` = `0 0 1 1 *`; `@annually` = `0 0 1 1 *`; `@monthly` = `0 0 1 * *`; `@weekly` = `0 0 * * 0`; `@daily` = `0 0 * * *`; `@midnight` = `0 0 * * *`; `@hourly` = `0 * * * *`. `@reboot`는 특수한 비스케줄(부팅 시에만 실행)이며 설명과 함께 거부됩니다.

POSIX 일 의미 규칙 (OR 규칙)

일과 요일이 모두 제한되면(둘 다 `*`가 아니면) 스케줄은 둘 중 어느 한쪽이 일치할 때 실행됩니다 — OR 의미입니다. 하나만 제한되면 그 하나가 결정합니다. 둘 다 `*`면 매일 일치합니다. 이 OR 규칙은 vixie cron, BSD cron, 대부분의 POSIX 구현에 적용됩니다. Quartz는 AND와 OR를 구분하기 위해 `?`를 사용합니다.

6필드 모드(Quartz-Lite)

입력에 여섯 개의 공백 구분 토큰이 있으면 본 도구는 첫 번째를 초 필드(0-59)로 처리합니다. Quartz, Spring `@Scheduled(cron=...)`, node-cron에 유용합니다. Linux crontab이나 POSIX 스케줄러로는 이식되지 않습니다. 이들은 사용자의 초를 분으로 취급해 모든 위치를 한 칸씩 밀어 버립니다.

단계 연산자 고정

`*/N`은 필드의 가장 낮은 값에 고정됩니다. 분에서 `*/15` = `0,15,30,45`이지 "지금부터 15마다"가 아닙니다. 와일드카드가 아닌 기준을 쓰면: 분에서 `5/15` = `5,20,35,50`. 필드 범위를 정수로 나누지 못하는 단계 값은 끝에서 다시 시작하는 지점 근처에서 건너뜁니다. 정상 동작이며 버그가 아닙니다.

검증 경계

분 ∈ [0,59], 시 ∈ [0,23], 일 ∈ [1,31], 월 ∈ [1,12], 요일 ∈ [0,7]. 범위를 벗어난 값은 필드 단위 오류를 일으킵니다. 일은 월에 대해 검증되지 않습니다(`0 0 31 2 *`는 정상적으로 파싱되지만 2월에는 31일이 없으므로 절대 일치하지 않으며, 다음 실행 미리보기는 "예정된 실행 없음"을 표시합니다).

Quartz 연산자 거부

POSIX cron은 Quartz의 `?`(특정 값 없음), `L`(last), `W`(가장 가까운 평일), `#`(n번째 요일)을 지원하지 않습니다. 본 도구는 이들을 "Quartz operators not supported"라는 명확한 메시지와 함께 거부합니다. 잘못된 POSIX로 침묵 파싱하지 않습니다. Quartz 스케줄에는 Quartz 인지형 도구나 Spring 스케줄러를 대신 쓰십시오.

다음 실행 탐색의 연도 상한

다음 실행 계산은 앞으로 최대 4년까지 탐색합니다. 그보다 드물게 일치하는 표현식(예: "2월 29일" 패턴)은 "향후 4년 이내에 예정된 실행 없음"으로 표시됩니다. 불가능한 패턴에서 무한 반복을 피하기 위한 의도된 설계입니다.

cron 스케줄 모범 사례

서버는 UTC로, 표시할 때 변환하라

서버를 UTC로 설정하고(`/etc/timezone` 또는 `TZ=UTC`) 모든 cron 표현식을 UTC로 작성하십시오. 로컬 시간으로의 변환은 대시보드와 리포트에서 표시 시점에만 수행합니다. 이렇게 하면 시간대 버그의 한 부류를 통째로 제거할 수 있는데, 특히 일광 절약 시간 전환에서 로컬 시간 스케줄이 조용히 두 번 실행되거나 한 번을 건너뛰는 상황을 막아 줍니다. 본 도구의 UTC 토글로 처음부터 UTC 기준으로 스케줄을 설계하십시오.

POSIX 일/요일 OR 함정을 피하라

OR 의미를 원하지 않는다면 일과 요일을 둘 다 제한하지 마십시오. "1월의 매주 월요일"을 원한다면 `0 0 * 1 1`(일은 `*`)로 작성하고, "매월 1일"을 원한다면 `0 0 1 * *`(요일은 `*`)로 작성하십시오. POSIX OR 규칙 때문에 `0 0 1 * 1`은 매월 1일 그리고 매주 월요일에 실행되는데, 의도와 거의 다를 것입니다. 배포 전에 다음 실행 미리보기를 확인하면 이 문제를 잡아낼 수 있습니다.

스케줄 시간대를 명시적으로 고정하라

최근의 스케줄러는 스케줄 정의에서 시간대 고정을 지원합니다. vixie cron 3.0+에서는 crontab 상단에 `CRON_TZ=America/New_York`을, Kubernetes CronJobs 1.27+에서는 `spec.timeZone: "America/New_York"`을, AWS EventBridge Scheduler에서는 스케줄 표현식에 `ScheduleExpressionTimezone`을 사용합니다. 서버의 기본값에 의존하지 말고 시간대를 명시적으로 고정하십시오. 서버 시간대는 인프라 마이그레이션 중에 예고 없이 바뀔 수 있습니다.

:00이 아니라 여러 분에 부하를 분산하라

중요하지 않은 작업에 `0 * * * *`(매시간 분 0)는 피하십시오. 규모가 커지면 많은 작업을 정확히 :00에 예약하는 것이 부하 스파이크를 일으킵니다. 각 작업마다 임의의 분 오프셋(`23 * * * *`, `41 * * * *`)을 골라 부하를 분산하십시오. 일간 작업도 마찬가지입니다. `30 3 * * *`는 많은 작업이 3:00에 몰릴 때 `0 3 * * *`보다 데이터베이스에 친화적입니다.

작업을 멱등하게 설계하라

cron에는 내장된 재시도, 중복 실행 방지, 놓친 실행 복구 기능이 없습니다. 작업은 여러 번 실행되어도 안전하도록(멱등하도록) 그리고 스스로 상태를 점검하도록 설계해야 합니다. "오전 9시에 리포트를 보냄" 대신 "오늘 리포트가 아직 발송되지 않았다면 발송"으로 설계하십시오. 이렇게 하면 다운타임, 우발적 중복 스케줄, 동시 실행 이후에도 스스로 복구됩니다. 멱등성은 스케줄러가 아니라 작업의 속성이며, 가장 중요한 신뢰성 관행입니다.

중요한 스케줄에는 하트비트를 추가하라

cron의 침묵 실패 모드가 가장 큰 약점입니다. 스케줄이 실행되지 않아도 아무도 알려 주지 않습니다. 중요한 작업이라면 실행이 끝날 때마다 하트비트 서비스(Healthchecks.io, Cronitor, Dead Man's Snitch)에 핑을 보내고, 예상한 핑이 도착하지 않으면 서비스가 알림을 발송하도록 하십시오. 작업 실패와 스케줄 자체의 오작동을 모두 잡을 수 있습니다. 무료 플랜으로도 개인과 소규모 팀의 요구 대부분을 충당할 수 있습니다.

배포 전에 다음 실행 미리보기로 확인하라

새 cron 스케줄을 배포하기 전에 본 도구의 미리보기에 표시된 다섯 개의 예정 실행 날짜·시간을 살펴보십시오. 로컬과 UTC를 토글하십시오. 의도한 시각에 스케줄이 떨어지는지 확인하십시오. 5분 일찍 실행되거나 잘못된 요일에 실행되거나 신경 쓰던 주말을 건너뛰지 않는지 점검하십시오. 미리보기는 가장 저렴한 운영 테스트입니다.

자주 묻는 질문