*/15 9-18 * * 1-5 를 보고 바로 '평일 오전 9시부터 오후 6시까지 15분마다'라고 읽어 내는 사람은 많지 않습니다. 크론 표현식은 다섯 개(초 단위를 쓰면 여섯 개)의 필드가 공백으로만 구분되어 있어 눈으로 검증하기 어렵고, 잘못 쓰면 배치 작업이 하루에 한 번이 아니라 1,440번 돌아가는 사고로 이어집니다.
이 도구는 표현식을 입력하는 즉시 한국어 설명으로 풀어 주고, 앞으로의 실행 시각 10개를 실제 달력에 맞춰 계산해 보여 줍니다. 요일과 날짜가 함께 나오므로 '매월 1일'과 '매주 월요일'을 헷갈려 쓴 경우처럼 미묘한 실수도 눈으로 잡을 수 있습니다. 필드별 빌더로 값을 클릭하며 만들 수도 있고, 자주 쓰는 스케줄은 프리셋 버튼 한 번으로 불러옵니다.
사용 방법
- 표현식 입력 또는 프리셋 선택 — 상단 입력창에 크론 표현식을 직접 입력하거나, 빌더 아래의 프리셋 버튼(
0 0 * * *,30 9 * * 1-5등)을 눌러 시작합니다. 입력하는 즉시 아래에 사람이 읽는 설명이 나타납니다. - 필드 단위로 다듬기 — 빌더 영역에서 분·시·일·월·요일을 각각 조정합니다. 각 필드 옆의 예시 버튼(
*,*/5,1-5등)을 누르면 해당 값이 바로 반영됩니다. 필드 오른쪽의 회색 숫자는 그 필드에 허용되는 범위입니다. - 다음 실행 시각 확인 — 오른쪽 패널에 앞으로 열 번의 실행 시각이 요일과 함께 표시됩니다. 브라우저의 시간대를 기준으로 계산하므로, 서버가 UTC로 동작한다면 시차를 감안해 읽어야 합니다. 서머타임이 있는 지역도 자동 반영됩니다.
- 초 단위가 필요하면 6필드로 전환 — Spring Scheduler나 Quartz처럼 초 필드를 먼저 받는 환경이라면 상단에서 6 fields (sec) 로 전환합니다. 기존 5필드 표현식 앞에 초 필드가 자동으로 붙습니다.
자주 묻는 질문
표시되는 실행 시각은 어느 시간대 기준인가요?
이 페이지를 연 브라우저의 시간대를 그대로 씁니다. 옵션 줄 오른쪽에 현재 적용 중인 시간대(예: Asia/Seoul)가 표시됩니다.
실제 서버의 크론은 대부분 UTC로 동작합니다. 한국에서 0 9 * * * 를 보고 '아침 9시'라고 생각했지만 서버가 UTC라면 실제로는 한국 시간 오후 6시에 실행됩니다. 배포 전에 서버의 TZ 환경변수나 cron 데몬 설정을 반드시 확인하고, 필요하면 UTC 기준으로 표현식을 다시 계산하세요.
일(day-of-month)과 요일(day-of-week)을 동시에 지정하면 어떻게 되나요?
표준 crontab에서는 두 필드가 AND가 아니라 OR로 동작합니다. 이 부분이 크론에서 가장 자주 오해받는 규칙입니다.
예를 들어 0 0 1 * 1 은 '매월 1일이면서 월요일'이 아니라 '매월 1일 또는 매주 월요일'로 해석되어 생각보다 훨씬 자주 실행됩니다. 둘 중 하나만 쓰고 나머지는 * 로 두는 것이 안전합니다. 실행 시각 목록을 보면 이런 실수가 바로 드러납니다.
`@daily` 같은 별칭이나 `L`, `#` 같은 확장 문법도 되나요?
@yearly, @monthly, @weekly, @daily, @hourly 별칭은 해석됩니다.
L(마지막 날), W(가장 가까운 평일), #(N번째 요일) 같은 확장 문법은 Quartz나 Spring 계열에서만 지원하는 비표준 문법입니다. 이 도구는 해석을 시도하지만, 대상 스케줄러가 실제로 지원하는지는 해당 문서에서 반드시 확인하세요. 표준 Linux crontab은 이들을 지원하지 않습니다.
알아두면 좋은 개념
다섯 개 필드의 의미
표준 크론은 분 시 일 월 요일 순서입니다. 각 필드에는 숫자, 범위(9-18), 목록(1,15), 간격(*/5), 전체(*)를 쓸 수 있고 이들을 섞을 수도 있습니다(0,30 9-18/2 * * *).
요일은 0부터 6까지이며 0이 일요일입니다. 시스템에 따라 7도 일요일로 받아들이고, MON·FRI 같은 영문 약어를 허용하는 구현도 있습니다. 월 필드 역시 JAN~DEC 약어를 쓸 수 있지만, 이식성을 생각하면 숫자를 쓰는 편이 안전합니다.
크론이 보장하지 않는 것들
크론은 '이 시각에 프로세스를 시작한다'만 보장합니다. 이전 실행이 끝났는지는 확인하지 않으므로, 5분마다 도는 작업이 7분 걸리면 인스턴스가 겹쳐 쌓입니다. flock 같은 파일 잠금이나 애플리케이션 레벨의 분산 락으로 중복 실행을 직접 막아야 합니다.
서버가 꺼져 있던 동안의 실행도 건너뜁니다. 놓친 작업을 나중에 따라잡아야 한다면 anacron 이나 마지막 성공 시각을 기록해 두고 처리하는 방식이 필요합니다.
짧은 주기 스케줄과 몰림 현상
*/5 * * * * 처럼 정각 배수에 맞춘 표현식은 여러 서버가 정확히 같은 순간에 일제히 실행됩니다. 인스턴스가 수십 대라면 매 5분마다 DB나 외부 API에 트래픽 스파이크가 생깁니다.
실무에서는 3,8,13,18,23,28,33,38,43,48,53,58 * * * * 처럼 오프셋을 주거나, 작업 시작 시 무작위로 몇 초를 지연시켜 분산합니다. 서비스가 커질수록 이 작은 차이가 장애 여부를 가릅니다.