Cron은 UTC로 볼까 로컬 시간으로 볼까
크론 스케줄을 설계할 때 가장 많이 놓치는 부분은 표현식보다 시간대입니다. 문법은 맞는데 실행 시간이 엉뚱한 경우는 대개 UTC와 로컬 시간대를 다르게 이해해서 생깁니다. 운영 관점에서는 “사용자에게 보여주는 시간”과 “시스템이 저장하고 계산하는 시간”을 분리해서 보는 것이 중요합니다.
1) UTC 기준의 장점
UTC는 서머타임 영향을 받지 않고, 지역마다 달라지지 않습니다. 여러 리전에 걸친 시스템이나 글로벌 서비스에서는 UTC를 기준으로 로그, 스케줄, 모니터링을 통일하는 것이 훨씬 안정적입니다. 장애 분석도 단순해집니다.
2) 로컬 시간 기준의 장점
반면 사용자 약속 시간이 중요한 작업은 로컬 시간이 더 자연스럽습니다. 예를 들어 “매일 한국 시간 오전 9시에 발송” 같은 요구는 UTC보다 로컬 시간으로 표현하는 편이 이해하기 쉽습니다. 다만 시스템 내부가 UTC인데 운영 문서만 로컬 시간이라면 사고가 생기기 쉽습니다.
3) 언제 UTC가 더 적합한가
- 로그 수집, 백업, 동기화 작업
- 글로벌 시스템 공통 배치
- 리전이 여러 개인 서비스
- 사람이 직접 시각을 보지 않는 내부 유지 작업
이런 작업은 사용자 체감 시간보다 시스템 안정성이 중요합니다.
4) 언제 로컬 시간이 더 적합한가
- 사용자 알림 발송
- 지역별 오픈/마감 스케줄
- 영업일 기준 정산
- 특정 국가 기준 리포트 집계
이런 작업은 실제 비즈니스 시간대가 기준이므로 로컬 시간을 무시하기 어렵습니다.
5) 가장 좋은 운영 원칙
실무에서는 내부 저장과 로그는 UTC로 통일하고, 사용자 의미가 있는 스케줄만 로컬 시간대 정보를 함께 명시하는 방식이 가장 안전합니다. 즉 “기준은 UTC, 해석은 필요 시 로컬”이 일반적으로 덜 위험합니다.
6) 흔한 실패 사례
서버는 UTC인데 운영 문서에 “매일 오전 9시”라고만 적혀 있어서, 크론에 0 9 * * *를 넣었다가 실제로는 한국 시간 오후 6시에 실행되는 사례가 많습니다. 반대로 로컬 시간을 의식해 수동 보정 값을 더했다가 DST 시점에 두 번 실행되거나 누락되는 경우도 있습니다.
7) 문서화가 중요한 이유
같은 표현식도 시간대 설명이 없으면 팀원마다 다르게 이해합니다. 크론 정의 옆에는 가능하면 “UTC 기준”, “KST 기준” 같은 설명을 같이 적어야 합니다. 운영 문서, 로그, 알림, 모니터링이 서로 다른 시간대를 보면 장애 대응이 매우 느려집니다.
8) 디버깅 순서
- 서버와 런타임 시간대 확인
- 크론 파서가 어느 시간대를 기준으로 해석하는지 확인
- 로그와 모니터링 대시보드 시간대 확인
- 사용자에게 보여주는 시각과 시스템 내부 시각 분리
이 네 단계만 맞춰도 대부분의 “왜 이 시간에 돌았지?” 문제는 해결됩니다.
9) 체크리스트
- 크론 표현식 옆에 기준 시간대를 명시했는가
- 서버, 컨테이너, 모니터링 시간대가 일치하는가
- 사용자 기준 스케줄인지 내부 시스템 스케줄인지 구분했는가
- UTC 저장과 로컬 표시를 혼동하지 않았는가
10) 관련 도구
표현식 해석은 Cron Expression Helper, 실제 시각 변환과 비교는 Unix Timestamp Converter가 도움이 됩니다. 스케줄 오류는 문법보다 시간대에서 더 자주 시작된다는 점을 기억해 두는 것이 좋습니다.