크론 표현식 예제 정리 — crontab 치트시트와 자주 쓰는 10가지

솔직히 고백하자면, 나는 크론 표현식을 아직도 못 외운다. 서버에 배치 작업 하나 걸 때마다 분 시 일 월 요일 순서가 맞나 싶어 손이 멈추고, 결국 crontab.guru 창을 또 연다. 리눅스 서버를 몇 년째 만졌는데도 그렇다. 비슷한 분들 꽤 있을 거다.

그래서 매번 검색하는 수고를 덜려고 자주 쓰는 패턴만 한곳에 모았다. 이 페이지 하나 북마크해두면 다음부터는 복붙으로 끝난다.

크론탭, 왜 아직도 이걸 쓰나

크론(cron)은 리눅스·유닉스 계열에서 "정해진 시간에 명령을 자동으로 돌려주는" 오래된 스케줄러다. 1970년대부터 있었으니 나이가 상당하다. 백업을 새벽에 돌리고, 로그를 매일 비우고, 인증서를 주기적으로 갱신하는 일 — 사람이 매번 터미널 앞에 앉아 있을 수 없는 반복 작업은 거의 다 크론이 맡는다.

그 작업 목록을 적어두는 표가 크론탭(crontab, cron table)이다. 사용자마다 자기 크론탭을 하나씩 가진다. 결국 핵심은 한 줄, "언제" 돌릴지를 적는 다섯 칸짜리 시간 표현식이다. 이게 헷갈려서 다들 고생한다.

다섯 칸의 의미부터

크론 한 줄은 공백으로 구분된 다섯 개의 시간 필드와 실행할 명령으로 이뤄진다.

* * * * *  실행할_명령
│ │ │ │ │
│ │ │ │ └─ 요일 (0-7)
│ │ │ └─── 월 (1-12)
│ │ └───── 일 (1-31)
│ └─────── 시 (0-23)
└───────── 분 (0-59)

표로 보면 이렇다.

요일 칸의 함정부터 짚자. 0도 일요일이고 7도 일요일이다. 대부분의 시스템이 둘 다 받아준다. 월요일이 1, 토요일이 6. 여기서 "일요일이 1 아니었나?" 하고 틀리는 경우가 정말 많다.

특수문자 네 개만 알면 된다

시간 칸에는 숫자 말고 아래 네 기호를 섞어 쓴다.

/ 는 오해가 많은 기호다. /10 은 "10분 지날 때마다"가 아니라 허용 범위의 시작(0)부터 10 간격, 그러니까 0·10·20·30·40·50분에 실행된다. 분 칸이면 매시 0분부터 센다. /5 면 0·5·10…55. 이 규칙만 잡으면 */N 은 안 헷갈린다.

바로 복붙하는 예제 10가지

현업에서 90%는 아래 열 개 안에서 끝난다.

마지막 @reboot 처럼 자주 쓰는 주기엔 별칭도 있다. @daily(=0 0 ), @hourly(=0 *), @weekly, @monthly, @yearly. 가독성은 좋은데 다른 사람이 볼 땐 정확한 시각이 안 보여서, 중요한 작업엔 나는 숫자로 적는 편이다.

편집하고 확인하는 명령

표현식을 알아도 어디다 적는지 모르면 소용없다. 명령은 세 개면 충분하다.

crontab -e   # 내 크론탭 편집 (기본 에디터로 열림)
crontab -l   # 현재 등록된 목록 출력
crontab -r   # 전부 삭제 — 확인도 안 묻고 지운다, 조심

crontab -r 은 진짜 위험하다. 확인 절차 없이 크론탭을 통째로 날린다. -l 이랑 키가 바로 옆이라 오타 한 번에 전부 사라진 적이 있다(두 번 당했다). 삭제가 겁나면 crontab -l > backup.txt 로 먼저 백업해두자.

여기서 다들 한 번씩 당한다

표현식이 맞는데도 작업이 안 돌면, 십중팔구 아래 중 하나다.

• PATH 문제. cron은 로그인 셸이 아니라서 PATH 가 아주 빈약하다(보통 /usr/bin:/bin). 터미널에선 되던 node·python·docker 가 cron에선 "command not found"로 죽는다. 명령을 절대경로로 적거나(/usr/local/bin/node), 크론탭 맨 위에 PATH=... 를 직접 선언하면 된다.
• 환경변수 없음. cron은 .bashrc·.profile 을 읽지 않는다. 셸에서 export 해둔 변수는 cron에 없다. 필요한 변수는 크론탭 상단이나 스크립트 안에서 직접 정의한다.
• 로그를 안 남김. 출력을 어디로도 안 보내면 에러가 조용히 사라진다(원래는 작업 소유자 메일함으로 간다). >> /var/log/myjob.log 2>&1 를 붙여 표준출력과 에러를 파일로 남기면 디버깅이 훨씬 수월하다.
• 실행권한 누락. 스크립트에 chmod +x 를 안 했거나 셔뱅(#!/bin/bash)이 빠지면 돌지 않는다.
• % 문자. 크론탭에서 % 는 개행으로 해석된다. 명령에 % 가 들어가면(date +%Y 같은 것) \% 로 이스케이프해야 한다. date 포맷 쓰다 이것 때문에 한참 헤맨 적 있다.
• 일 + 요일 동시 지정은 OR다. 가장 악명 높은 함정. 30 4 1 5 처럼 날짜(1일)와 요일(금요일)을 둘 다 숫자로 지정하면, cron은 "1일 그리고 금요일"이 아니라 "1일 또는 금요일" 로 돈다. 둘 중 하나만 맞아도 실행된다. 한쪽을 로 두면 다른 쪽만 적용되니 이 함정에 안 걸린다.

그래도 외우지 말고 도구를 쓰자

사실 이걸 다 외울 필요는 없다. crontab.guru 에 표현식을 넣으면 "매일 새벽 3시 30분"처럼 사람 말로 풀어주고, 거꾸로 원하는 주기를 설명으로 찾을 수도 있다. 나는 지금도 중요한 작업을 걸기 전엔 꼭 여기서 한 번 검증한다. 손으로 쓴 표현식을 안 믿는 습관이 사고를 막아준다.

요즘 현장에서는 크론의 자리가 조금씩 바뀌고 있다. 리눅스 배포판이 systemd로 넘어오면서 systemd timer 가 cron을 대체하는 흐름이 생겼고, 애플리케이션 레벨에선 스프링의 @Scheduled, 자바의 Quartz, 파이썬의 APScheduler처럼 코드 안에서 스케줄을 관리하는 쪽이 늘었다. 이유는 분명하다. cron은 서버 한 대에 묶여 있고, 실패해도 자동 재시도가 없고, 실행 이력을 따로 남겨주지 않는다. 서버가 여러 대로 늘어나는 순간 "같은 작업이 세 대에서 동시에 도는" 사고가 나기 쉽다. 그래서 규모가 커지면 분산 환경용 스케줄러(에어플로우 같은)나 중앙 큐로 옮겨간다. 그럼에도 국내 중소 규모 서버 운영, 특히 개인·사내 서버 한 대를 돌리는 상황에선 여전히 cron만 한 게 없다. 설치할 것도 없고, 한 줄이면 끝나고, 어디서나 똑같이 동작한다. 도구가 화려해져도 "새벽에 백업 한 번 돌려줘" 같은 일엔 크론탭 한 줄이 가장 빠른 답인 셈이다.

크론 표현식은 외우는 게 아니라 "구조를 이해하고 필요할 때 찾아 쓰는" 영역이다. 다섯 칸 순서(분·시·일·월·요일), 특수문자 네 개, 그리고 일+요일 OR 함정 — 이 세 가지만 머리에 담고 나머지는 위 표에서 복붙하면 된다.

여러분은 크론 쓰다 어떤 사고를 당해봤는지 궁금하다. 나처럼 crontab -r 로 전부 날려본 분? 아니면 요일 0/7 때문에 엉뚱한 날 돌아간 경험? 댓글로 삽질담 나눠주시면 서로 예방주사가 될 것 같다.