Cron 표현식 실수 줄이는 체크리스트

크론은 간단해 보이지만 시간대, 필드 순서, 런타임 환경 차이 때문에 실수가 잦습니다. 문법 자체보다 운영 조건을 놓쳐 장애가 나는 경우가 더 많습니다. 특히 배치, 정산, 알림, 만료 처리처럼 시간을 기준으로 움직이는 작업은 한 번만 잘못 실행돼도 영향이 큽니다.

1) 5필드 순서 확실히 하기

표준 5필드: 분 시 일 월 요일

예: */10 * * * * → 10분마다

일부 라이브러리나 클라우드 서비스는 초 단위를 포함한 6필드 형식을 사용합니다. 문서에서 예제를 그대로 가져왔는데 환경이 다르면 완전히 다른 스케줄로 해석될 수 있습니다. 표현식을 작성하기 전에 "지금 사용하는 파서가 몇 필드인지"부터 확인해야 합니다.

2) 시간대 확인

• 서버 시간대가 UTC인지 로컬인지 확인
• 앱/로그/모니터링 시간대가 일치하는지 점검
• 컨테이너와 DB, 외부 스케줄러의 시간대가 다르지 않은지 확인

3) 빈번한 실수

• 0 0 * * *를 “매 시간”으로 착각
• 월/요일 필드에 0과 7의 의미를 혼동
• 개발/운영 환경 크론 파서 차이
• 배포 중 중복 실행 방지를 고려하지 않음

4) 운영 팁

• 실행 로그를 남겨 실제 동작을 확인
• 배치 실패 시 알림을 반드시 설정
• 중요한 작업은 재시도 전략을 설계
• 동일 작업의 중복 실행을 막기 위한 락이나 idempotency를 고려

5) 바로 써보기

Cron Expression Helper에 표현식을 넣으면 각 필드 의미를 빠르게 확인할 수 있습니다.

6) 자주 쓰는 패턴 예시

• 매일 자정: 0 0 * * *
• 평일 오전 9시: 0 9 * * 1-5
• 매월 1일 03:00: 0 3 1 * *

7) DST(서머타임) 주의

서머타임이 있는 지역에서는 동일한 표현식이 하루에 두 번 실행되거나 실행되지 않을 수 있습니다. 운영 환경의 시간대를 확인하세요.

특정 국가 기준 리포트나 정산 작업이라면 로컬 시간대 요구가 있을 수 있지만, 가능하면 시스템 내부 저장과 계산은 UTC로 유지하는 편이 안전합니다. 표시만 로컬 시간대로 바꾸면 사고를 줄일 수 있습니다.

8) 실무 장애 사례

예를 들어 "매일 오전 9시 사용자 알림" 배치가 있다고 가정하면, 서버는 UTC인데 운영 문서는 한국 시간 기준으로 적혀 있어 0 9 * * *를 적용한 뒤 실제로는 오후 6시에 실행되는 일이 생길 수 있습니다. 또 멀티 인스턴스 환경에서 모든 서버가 동일한 크론을 실행해 같은 메일이 여러 번 발송되는 문제도 흔합니다. 문법보다 실행 위치와 단일 실행 보장이 더 중요합니다.

9) 배치 설계 시 함께 봐야 할 것

• 재실행해도 안전한 작업인가
• 작업 시간이 다음 스케줄과 겹치지 않는가
• 실패 알림이 실제로 사람에게 전달되는가
• 외부 API 호출 제한과 충돌하지 않는가

크론 표현식만 맞다고 끝이 아닙니다. 스케줄은 "언제 시작할지"만 정할 뿐이고, 실제 운영 안정성은 락, 재시도, 타임아웃, 모니터링이 결정합니다.

10) 체크리스트

• 5필드 순서가 맞는가?
• 서버와 모니터링 시간대가 일치하는가?
• 실패 알림/재시도 로직이 준비되었는가?
• 멀티 인스턴스 중복 실행 가능성을 막았는가?

11) 추가 예시

• 매주 월요일 08:00: 0 8 * * 1
• 매일 23:30: 30 23 * * *
• 매 15분: */15 * * * *