비 DevOps를 위한 Cron 표현식 파서 설명

작은 기능을 출하하고, 평일 오전 9시에 실행해야 하고, cron에 손을 뻗습니다. 세 번의 실패한 시도와 하나의 프로덕션 사건(작업이 주말 내내 매분 실행) 후에, 이제 이번 달 네 번째로 cron 표현식 구문 참조를 상담하고 있습니다. Wikipedia 테이블은 빽빽하고, StackOverflow 답변은 서로 모순되고, AI 도우미가 제공한 답변이 스케줄러가 실제로 받아들인 것과 완전히 일치하지 않습니다.

이 가이드는 cron을 매일 작성하지 않는 사람들을 위한 첫 원칙에서 cron 표현식을 설명합니다 —— 매년 cron을 몇 번 사용하고 비밀스러운 것을 암기하지 않고 올바르게 하기를 원하는 제품 관리자, 창립자, 디자이너, 분석가 및 백엔드 개발자. 평이한 영어로 모든 표현식을 시각화하기 위한 Ai2Done Cron Parser 외에도 경험 많은 엔지니어조차 물어뜯는 함정을 다룰 것입니다.

TL;DR

• cron 표현식은 5개 필드: 분 시 일 월 요일 —— 공백으로 구분됩니다.
• 가장 까다로운 함정: 일과 요일이 모두 지정되면 고전 Unix cron은 OR로 처리(둘 중 하나가 일치하면 실행)하며, 거의 원하는 것이 아닙니다.
• 모든 표현식을 평이한 영어로 번역하고 배포 전에 다음 5-10개의 실행 시간을 보려면 Ai2Done Cron Parser 사용.
• 시간대가 중요: 대부분의 cron 스케줄러는 UTC에서 실행됩니다; 호출 시스템(Kubernetes CronJob, AWS EventBridge 등)에서 시간대를 명시적으로 지정하십시오.
• 특수 문자 * / , - L W ? #은 고전 cron vs Quartz cron에서 다른 것을 의미합니다 —— 스케줄러에 맞는 방언을 선택하십시오.

이것이 보이는 것보다 어려운 이유

1975년의 원본 Unix cron은 5개 필드를 사용했습니다. 현대 스케줄러(Quartz, Kubernetes CronJobs, AWS EventBridge, GitLab 일정, GitHub Actions)는 호환되지 않는 방식으로 구문을 확장하거나 수정합니다. 최소 4개의 널리 사용되는 방언이 있습니다:

1. 고전 Unix cron(5개 필드, Linux/macOS의 crontab이 사용)
2. Vixie cron(일부 확장이 있는 사실상의 Linux 구현)
3. Quartz cron(초와 연도를 포함한 7개 필드, Java 스케줄러와 AWS EventBridge가 사용)
4. Kubernetes CronJob(5개 필드이지만 ? 없음 및 약간 다른 DST 처리)

한 시스템에서 완벽하게 작동하는 cron 표현식은 다른 시스템에서 검증에 실패하거나, 예상치 못한 시간에 실행되거나, 조용히 절대 발사되지 않을 수 있습니다. "이 표현식이 유효합니까?" 질문은 진정으로 방언에 따라 다릅니다.

혼란의 두 번째 소스: "5개 필드" 프레임은 순서를 기억한다고 가정합니다. 압박을 받는 대부분의 엔지니어는 "분과 시가 있고... 일이나 월이 먼저였나?"를 기억합니다. 올바른 순서는 분, 시, 일, 월, 요일입니다.

세 번째 소스: 특수 문자가 비명백한 방식으로 상호 작용합니다. 0 0 1,15 * 1-5는 매월 1일과 15일에 실행되거나 월요일부터 금요일에 실행됩니다(고전 cron이 일과 요일을 OR하기 때문에). "1일과 15일이지만 평일인 경우에만"을 얻으려면 Quartz cron의 ? 자리 표시자가 필요합니다.

좋은 cron 파서는 시간대에서 다음 5-10개의 실제 실행 시간을 보여주므로, 프로덕션에 배포하기 전에 표현식이 실제로 무엇을 하는지 정상 점검할 수 있습니다.

5개 필드 설명

*   *   *   *   *
│   │   │   │   │
│   │   │   │   └── 요일 (0-6 또는 SUN-SAT; 일부 방언은 1-7 사용)
│   │   │   └────── 월 (1-12 또는 JAN-DEC)
│   │   └────────── 일 (1-31)
│   └────────────── 시 (0-23)
└────────────────── 분 (0-59)

각 필드는 될 수 있습니다:

• 특정 숫자: 5("이 정확한 값"을 의미)
• 목록: 1,15,30("이러한 값 중 어느 것"을 의미)
• 범위: 1-5("이부터 저까지"를 의미)
• 단계: */15("0부터 시작하여 N번째 값마다"를 의미) —— 그래서 분 필드의 */15는 "0, 15, 30, 45"입니다
• 와일드카드: *("모든 값"을 의미)

구문을 알면 일반적인 패턴:

• * * * * * —— 매분(새벽 3시에 깨우는 유명한 "일정을 지정하는 것을 잊었습니다" 표현식)
• */5 * * * * —— 5분마다
• 0 * * * * —— 매시간, 정시에
• 0 9 * * * —— 매일 오전 9:00
• 0 9 * * 1-5 —— 평일 오전 9:00(교과서적 "업무 시간" 작업)
• 0 0 1 * * —— 매월 첫째 날 자정
• 0 0 * * 0 —— 일요일 자정(주 경계)
• 15 14 1 * * —— 매월 1일 오후 2:15
• 0 */6 * * * —— 6시간마다(0, 6, 12, 18)

방법 1: Ai2Done Cron Parser(배포 전 시각적 검증)

**Ai2Done Cron Parser**는 모든 표현식을 평이한 영어로 번역하고 다음 10개의 실제 발사 시간을 보여줍니다. 흐름:

1. 어떤 브라우저에서든 /tools/cron_parser를 엽니다.
2. 표현식 붙여넣기 —— 예: 0 9 * * 1-5.
3. 즉시 보기:
   • 평이한 영어: "오전 09:00, 월요일부터 금요일까지"
   • 로컬 시간대에서 다음 10개의 발사 시간
   • 각 부분이 일치하는 것을 보여주는 필드별 분석
   • 불가능한 표현식에 대한 검증 오류(예: 0 9 32 * * —— 한 달의 32일은 없습니다)
4. 스케줄러가 비표준 변형을 사용하는 경우 고전 cron, Quartz, AWS EventBridge 및 Kubernetes 사이에서 방언 전환.

도구는 사람이 읽을 수 있는 번역을 위한 cronstrue 라이브러리와 다음 발사 계산을 위한 cron-parser를 사용하여 완전히 클라이언트 측에서 실행됩니다. 표현식은 서버를 만지지 않습니다.

프로 팁: cron 구동 작업을 프로덕션에 배포하기 전에 표현식을 파서에 붙여넣고 적어도 다음 3개의 발사 시간이 의도한 것과 일치하는지 확인하십시오. 이것은 고전적인 "6시간마다라고 의미했지만 하루에 한 번 오전 6시를 의미하는 0 6 * * *를 입력했습니다" 오류를 5초 만에 잡습니다.

방법 2: crontab.guru 웹사이트

이미 브라우저에 있는 경우 crontab.guru는 cron 설명의 비공식 표준입니다. 동일한 핵심 기능 —— 표현식 붙여넣기, 영어 보기 —— 가 있는 단일 페이지 웹 도구입니다. Ai2Done 파서와의 차이점:

• 서버 측 실행(표현식이 액세스 로그에 로깅됨)
• 필드별 분석을 보여주지 않음
• 고전 cron만 지원(Quartz 없음, AWS EventBridge 방언 없음)
• ~10년 동안 무료이고 우수했습니다

비민감한 표현식에는 괜찮은 선택입니다. 정보를 누출할 수 있는 표현식(예: 일부 Quartz 방언에서 사용자 정의 필드 이름을 포함하는 표현식)의 경우 로컬 파서가 더 안전합니다.

방법 3: 드라이런 스케줄러에서 테스트

위험이 높은 cron 작업(데이터 파이프라인, 청구 실행, 고객 대면 예약된 작업)의 경우 가장 높은 신뢰도 접근 방식은 먼저 드라이런 환경에 배포하는 것입니다:

• Kubernetes: suspend: true로 CronJob을 배포하고 kubectl describe를 통해 계산된 다음 실행을 검사합니다.
• AWS EventBridge: 타겟 없이 규칙을 생성하고 계산된 NextInvocations을 봅니다.
• Airflow / Dagster: 모든 DAG 일정에 대해 항상 다음 5-20개의 발사 시간을 보여주는 스케줄러의 UI를 사용합니다.

이것은 파서가 잡지 못하는 엣지 케이스(클러스터의 UTC 오프셋, 일광 절약 시간 전환, ?가 있는 6개 필드가 필요한 AWS EventBridge의 cron(0 9 ? * MON-FRI *) 구문과 같은 스케줄러별 특이 사항)를 잡습니다.

고전적인 함정

일과 요일은 AND가 아닌 OR입니다. 0 0 1 * 1은 매월 1일 자정에 실행되고, 그리고 매주 월요일에 실행됩니다. "월요일인 경우에만 1일"이 아닙니다. AND를 얻으려면 Quartz cron의 ?를 사용하여 "특정 값 없음"을 나타냅니다 —— 0 0 1 * ?는 요일에 관계없이 1일에만 실행됩니다.

*/N은 "N단위마다"가 아닙니다. 그것은 "0부터 시작하여 N단위마다"입니다. 그래서 */30 * * * *은 매시간 :00과 :30에 실행되고, "마지막 실행 후 30분"이 아닙니다. 진짜 고정 간격 스케줄링의 경우 작업 큐(Celery, BullMQ, Sidekiq)를 사용하십시오 —— cron은 근본적으로 캘린더 기반이고, 간격 기반이 아닙니다.

시간대 기본값은 신뢰할 수 없습니다. Linux cron은 시스템 시간대에서 실행됩니다. Docker 컨테이너는 일반적으로 UTC로 기본 설정됩니다. AWS EventBridge는 UTC로 기본 설정됩니다. Kubernetes CronJobs는 API 서버의 시간대(종종 UTC)로 기본 설정됩니다. 작업이 "오전 9시 현지 시간"에 실행되어야 하는 경우 시간대를 명시적으로 구성하십시오 —— 기본값을 신뢰하지 마십시오.

일광 절약 시간이 유령 실행을 만듭니다. 시계가 오전 2시에 앞으로 가면, 오전 2:30로 예약된 작업이 그날 실행되지 않습니다. 시계가 뒤로 가면, 두 번 실행됩니다. 대부분의 스케줄러는 이를 처리하는 옵션이 있습니다(Quartz의 미스파이어 정책, Kubernetes의 concurrencyPolicy); 자신의 것에 대한 문서를 읽으십시오.

0 0 31 2 * —— 존재하지 않는 2월 31일에 실행됩니다. 대부분의 스케줄러는 조용히 건너뜁니다. 배포하기 전에 테스트하십시오.

파서를 어떻게 빌드했는지(기술적 심층 분석)

Ai2Done Cron Parser는 다음에 빌드되었습니다:

• 영어 번역을 위한 cronstrue(클래스에서 최고, 모든 주요 방언 지원, ~30 KB gzipped)
• 다음 발사 시간 계산을 위한 cron-parser(DST, 윤일, 범위, 단계를 올바르게 처리)
• AWS EventBridge 구문(cron(0 9 ? * MON-FRI *) —— 6개 필드, 연도 선택적)을 기본 파서의 예상 형식으로 번역하는 작은 방언 어댑터
• Web Crypto / SubtleCrypto는 사용되지 않습니다 —— 여기에는 보안에 민감한 콘텐츠가 없습니다; 파서는 편의 도구일 뿐입니다

흥미로운 디자인 선택: "Google 캘린더 스타일 선택기에서 cron 구성"을 의도적으로 제공하지 않습니다. 그런 종류의 UI는 초보자에게 훌륭하지만, 사람들에게 기본 구문이 아니라 선택기를 가르치는 경향이 있습니다. Cron은 빽빽하지만 20분 안에 배울 수 있습니다; 그것을 숨기기보다 읽도록 돕고 싶습니다.

FAQ

Q: 일부 스케줄러에 5개 필드가 있고 다른 스케줄러에 6개 또는 7개가 있는 이유는 무엇입니까? A: 고전 Unix cron에는 5개 필드(분 시 일 월 요일)가 있습니다. Quartz는 2개를 더 추가합니다: 앞에 초와 끝에 연도(* * * * * * *). AWS EventBridge는 요일/일이 ?이어야 하는 6개 필드를 사용합니다. 스케줄러와 일치하는 방언을 선택하십시오.

Q: cron 표현식에서 ?는 무엇을 의미합니까? A: "특정 값 없음"을 의미하는 Quartz / AWS EventBridge 확장입니다. 둘 중 하나만 일치해야 할 때 모호성을 해결하기 위해 일과 요일에 사용됩니다. 고전 Unix cron에서는 지원되지 않습니다.

Q: cron 표현식에서 L은 무엇을 의미합니까? A: "last"에 대한 Quartz 확장. 일의 L은 "월의 마지막 날"(28일/29일/30일/31일에 따라)을 의미합니다. 요일의 5L은 "월의 마지막 금요일"을 의미합니다. 28/29/30/31을 하드 코딩하지 않고 월말 작업에 유용합니다.

Q: cron 표현식에서 W는 무엇을 의미합니까? A: "weekday"에 대한 Quartz 확장. 일의 15W는 "15일에 가장 가까운 평일"을 의미합니다 —— "월간 급여, 그러나 절대 주말에는 아님"에 유용합니다.

Q: 업무 시간 동안에만 5분마다 작업을 실행하는 방법은? A: */5 9-17 * * 1-5 —— 5분마다, 시간 9-17, 평일. 파서로 검증하십시오; 다음 10개의 발사 시간이 기대와 일치해야 합니다.

Q: 일광 절약 시간 전환 동안 작업이 두 번 실행되었습니다. 어떻게 수정합니까? A: 이것은 스케줄러별입니다. Kubernetes CronJob의 concurrencyPolicy: Forbid는 겹치는 실행을 방지합니다. Quartz에는 미스파이어 정책이 있습니다. AWS EventBridge는 항상 UTC에서 실행하여 DST를 처리합니다(따라서 일광 절약은 애플리케이션의 문제입니다).

Q: cron에서 "매월 첫 번째 월요일"을 표현할 수 있습니까? A: 고전 Unix cron에서는 안됩니다 —— 애플리케이션 수준 논리가 필요합니다. Quartz cron에서는 예: 0 0 0 ? * MON#1(매월 1번째 월요일 자정에 실행).

지금 시도

프로덕션에서 실행되기 전에 모든 cron 표현식을 검증하십시오:

Cron Parser 열기 →

붙여넣고, 보고, 배포하십시오. 업로드 없음, 가입 없음, 표현식이 브라우저에 남아 있습니다.

관련 읽기

• 토큰을 절대 보내지 않는 프라이버시 안전 JWT 디버거 —— 같은 아키텍처, JWT에 적용
• JSON, YAML, XML, CSV —— 하나의 툴박스로 라운드 트립 —— cron 작업이 소비할 가능성이 있는 구성 파일용
• WASM 측 처리: 왜 브라우저에서 모든 것을 실행하는지
• 모든 개발자 도구 둘러보기

최종 업데이트 2026-06-14. Cron Parser는 브라우저에서 100% 실행됩니다 —— 표현식은 기기를 떠나지 않습니다. 테스트한 것의 서버 로그가 없습니다.