# 2:00시와 3:00시 크론 작업을 피하라 (2013) > Clean Markdown view of GeekNews topic #23978. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=23978](https://news.hada.io/topic?id=23978) - GeekNews Markdown: [https://news.hada.io/topic/23978.md](https://news.hada.io/topic/23978.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-10-29T02:33:05+09:00 - Updated: 2025-10-29T02:33:05+09:00 - Original source: [endpointdev.com](https://www.endpointdev.com/blog/2013/04/avoid-200-and-300-am-cron-jobs/) - Points: 5 - Comments: 2 ## Summary 매년 두 번 찾아오는 **일광 절약 시간제(DST)** 전환은 단순한 시계 조정 이상의 문제를 만듭니다. 특히 **크론(cron)** 기반 서버에서는 새벽 2시나 3시에 설정된 작업이 중복 실행되거나 아예 누락되는 등, 자동화 신뢰성을 흔드는 버그가 발생할 수 있습니다. 실제로 **vixie-cron** 환경에서 3:00 작업이 1초 간격으로 60회 반복된 사례도 보고되었죠. 서버를 **UTC로 운영**하거나 해당 시간대를 피하는 것이 가장 현실적인 방어책이며, 장기적으로는 **시간대 인식형 스케줄러**로의 전환이 필요합니다. “시간은 돈”이라지만, 서버에게는 “시간대는 리스크”라는 점을 다시금 상기시켜주는 글입니다. ## Topic Body - 리눅스 서버에서 **일광 절약 시간제(DST)** 전환 시 발생하는 크론(cron) 작업 오류를 경고하는 글 - 매년 두 번, **일요일 새벽 2시 또는 3시**에 시간대가 변경되면서 크론 작업이 중복 실행되거나 누락되는 문제 발생 - 실제 사례로, vixie-cron 환경에서 3:00~3:01 사이 작업이 **1초 간격으로 60회 반복 실행**되어 이메일 혼잡 발생 - 해결책으로 **UTC 시간대 설정** 또는 **해당 시간대 작업 회피**, 더 나은 **오픈소스 스케줄러 개발** 제안 - 서버 운영자와 DevOps 엔지니어에게 **시간대 전환 리스크 관리의 중요성**을 상기시키는 사례 --- ### 일광 절약 시간제와 크론 작업의 충돌 - 일요일 새벽 2시 또는 3시에 크론 작업을 설정하면 **일광 절약 시간제(DST)** 전환 시점과 겹쳐 예기치 않은 실행 오류 발생 - DST 시작 시 시계가 한 시간 앞으로 이동하거나, 종료 시 한 시간 뒤로 이동하면서 **시간 중복 또는 누락** 현상 발생 - 이로 인해 특정 시간대의 작업이 **두 번 실행되거나 아예 실행되지 않는 문제**가 생김 - 특히 매주 일요일 새벽에 실행되는 작업은 **연 2회 DST 전환 시점**에 영향을 받음 - 일반적으로 문제없이 동작하지만, DST 전환일에는 **비정상적인 반복 실행**이 발생할 수 있음 ### 실제 사례: vixie-cron의 반복 실행 문제 - Linux 환경의 **vixie-cron**에서 DST 시작 시 3:00~3:01 사이 작업이 **1초 간격으로 약 60회 실행**된 사례 보고 - 각 작업이 서로 충돌하며 **이메일 알림 폭주**와 같은 혼란 발생 - 다행히 해당 작업이 치명적이지 않아 시스템 손상은 없었음 - 이러한 문제는 **크론의 단순한 시간 기반 스케줄링 구조**에서 비롯됨 - 크론은 시간대 변경이나 DST 전환을 인식하지 못하고, 단순히 지정된 시각에 맞춰 실행 ### 가능한 해결책과 대안 - 가장 간단한 방법은 **일요일 새벽 2시와 3시 시간대에 작업을 설정하지 않는 것** - 해당 시간대를 피하면 DST 전환으로 인한 중복 실행 문제를 완전히 회피 가능 - **서버의 시간대를 UTC로 설정**하는 것도 효과적인 대안 - UTC는 일광 절약 시간제를 적용하지 않으므로 시간 변경이 발생하지 않음 - 더 근본적인 해결책으로는 **보다 지능적인 작업 스케줄러 개발** 제안 - 중복 실행 방지, 실행 시간 제한, 시간대 인식 기능 등을 갖춘 **오픈소스 대체 도구** 필요 ### 장기적 제안: 일광 절약 시간제 폐지 - 글의 저자는 **정부 차원의 DST 폐지**를 가장 바람직한 해결책으로 제시 - 매년 두 번의 시간 변경이 시스템 운영과 인간 생활 모두에 불필요한 복잡성을 초래 - 그러나 현실적으로 DST가 유지되는 한, **시스템 관리자와 DevOps 엔지니어가 예방 조치**를 취해야 함 - 특히 자동화된 배치 작업, 백업, 로그 회전 등 **시간 의존적 작업 관리**에 주의 필요 ### 결론: 안전한 크론 스케줄링 원칙 - DST 전환 시점의 **2:00~3:00 시간대 작업은 피해야 함** - 가능하면 **UTC 기반 서버 운영**으로 시간대 문제를 제거 - 크론의 한계를 인식하고, **보다 견고한 스케줄링 도구 도입** 검토 필요 - DevOps 환경에서 **시간대 관리와 자동화 신뢰성 확보**는 필수 과제 ## Comments ### Comment 45598 - Author: semjei - Created: 2025-10-29T18:14:23+09:00 - Points: 1 저도 새벽2시에 걸어놓은 작업에 문제 (한번은 두번 실행되고 한번은 실행되지 않고) 생긴뒤로는 꼭 피하고 있습니다. ### Comment 45567 - Author: neo - Created: 2025-10-29T02:33:06+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45723554) - **DST(일광 절약 시간제)** 는 완전히 잘못된 제도라고 생각함 아무런 문제도 해결하지 못하고 오히려 불편만 초래함 그냥 **표준시(겨울 시간)** 으로 고정하고, 대신 근무 시간을 여름 시간대처럼 한 시간 앞당기면 됨 예를 들어 가게를 7시 대신 6시에 열고 10시 대신 9시에 닫는 식임 어차피 1년에 두 번씩 적응 기간이 있으니, 한 번만 바꾸면 됨 나는 퇴근 후에 햇빛을 더 보고 싶음. 겨울에는 특히 더 그렇고, 출근길에 해가 떠 있는 건 상관없음 실내에 9시간 갇혀 있을 테니까, 자유 시간이 있을 때 햇빛을 보고 싶음 - 모두가 DST를 싫어하지만, 제안된 대안들은 이미 시도된 적이 있음 예를 들어 **1973~1975년 미국의 연중 DST 실험**이 있었음 처음엔 에너지 절약과 범죄 감소 등의 이유로 찬성 여론이 높았지만, **어두운 아침 통학길 사고**로 여론이 급격히 악화되어 결국 폐지되었음 ([Wikipedia 인용](https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States)) - 시계를 옮기지 말고 영업시간을 바꾸자는 건 결국 같은 효과를 내는 것 아닌가 하는 의문이 있음 결국 더 큰 시간 이동을 원한다는 말처럼 들림 - ‘겨울 시간’이라는 용어는 사실 존재하지 않음 표준시와 일광 절약 시간만 있을 뿐임 ‘겨울 시간’을 항상 유지하자는 표현은 심리적으로 매력적이지 않음 - DST는 단순히 **태양이 뜨는 시각**에 맞추려는 임시방편일 뿐임 사람들은 해가 떠 있을 때 하루를 시작하길 원함 프로그래머들이 DST 때문에 고생하지만, 그건 **엣지 케이스 처리**를 잘 해야 하는 문제라고 생각함 - 표준시냐 일광 절약 시간이냐의 논쟁은 결국 **근무 시간 선택의 자유**가 부족해서 생기는 문제임 사람마다 수면 패턴이 다르니, 각자 맞는 근무 시간을 선택할 수 있으면 갈등이 줄어들 것임 - 예전에 **reddit 서버**를 세팅할 때, 전부 **Arizona 시간대**로 설정했음 Arizona는 DST를 사용하지 않아서, 캘리포니아와 1시간 차이만 있음 UTC를 쓰지 않은 이유는 로그를 읽을 때 ‘8을 빼는 것보다 1을 빼는 게 쉽기 때문’이었음 지금은 글로벌 팀이 생겨서 UTC로 바꾼 상태임 - 비슷한 결정을 한 적이 있는데, 나중에 **정리하느라 고생**했음 처음부터 전부 UTC로 통일하는 게 좋음 - 하지만 Arizona처럼 **시간대 정의가 바뀔 위험**도 있음 전 세계적으로 이런 변경이 자주 일어나서, 캘린더 앱 개발자 입장에서는 정말 골치 아픈 일임 - 로그 뷰어 UI가 **브라우저 언어 설정으로 12/24시간 형식**을 강제하는 게 불만임 UTC를 선택했으면 YYYY-MM-DD 24시간 형식을 이해할 줄 안다고 가정해야 함 - Java에서는 JVM 단위로 기본 시간대를 설정할 수 있는데, 조직 내에서 각자 PST로 바꿔 쓰다 보니 로그마다 시간이 달라지는 혼란이 생겼음 결국 리더가 나서서 **모든 애플리케이션과 DB를 PST로 통일**시킴 - UTC로 로그를 읽을 때 날짜가 바뀌지 않는 점은 여전히 헷갈림 그래도 이제는 본능적으로 UTC를 해석하게 되었음 - 예전에 회사 서버를 **BST(영국 여름 시간)** 으로 설정하고 cron을 많이 썼는데, 매년 두 번씩 **혼란이 반복**되었음 결국 회사가 망할 때까지 고치지 못했음 교훈은 간단함 — **UTC를 써라**, 특별한 이유가 없다면 - 책상 위에 **UTC 아날로그 시계**를 두고 로그를 볼 때 참고함 - 고객이 UTC에 있지 않다는 이유로 현지 시간대를 쓰는 경우도 있음 예를 들어 **사용량 제한 리셋**이나 **청구 배치 작업**은 지역 시간 기준으로 돌아감 - cron 자체를 쓰지 말고, **데이터와 고객 설정을 인식하는 스케줄러**를 쓰는 게 낫다고 생각함 - 어떤 보고서는 **현지 시간 기준**으로 필요함 예를 들어 영국 8시 보고서는 DST에 따라 UTC 기준이 달라짐 따라서 UTC만으로는 해결되지 않으며, **시간대 정보를 함께 저장**해야 함 - 금융권처럼 **시장 개장 시간**이 중요한 경우에는 UTC만으로는 부족함 - 일부 국가(Cuba, Egypt, Lebanon)는 **DST 변경이 자정에 일어남** ([관련 링크](https://mas.to/@mpirnat/115395859892135002)) - DST 변경이 자정이 아닌 곳도 있다는 게 놀라웠음 브라질에서는 00:00~01:00 또는 00:00~23:00에 바뀌는 게 일반적이었음 - 시간대 규칙은 정말 **예측 불가능한 일**을 많이 함 - DST 조정일에는 **사망률과 응급실 방문이 급증**한다는 연구가 있음 ([ScienceAlert 기사](https://www.sciencealert.com/daylight-savings-time-change-kills-people)) 단순히 cron 문제를 넘어서, DST는 **건강에도 해로운 제도**임 - 이 문제는 오래전에 **OpenBSD와 Debian**에서 이미 해결된 적이 있음 Debian의 cron(8) 매뉴얼에는 DST 조정 시 **3시간 미만의 시간 이동 처리 로직**이 설명되어 있음 ([패치 링크](https://sources.debian.org/src/cron/3.0pl1-137/debian/patches/features/Better-timeskip-handling.patch), [매뉴얼](https://manpages.debian.org/unstable/cron/cron.8.en.html), [버그 리포트](https://bugs.debian.org/8499)) - 그렇다면 원문 작성자는 이 **패치가 적용되지 않은 배포판**을 쓴 것 같음 - **자정(00:00)** 에 작업을 예약하지 말라는 조언임 날짜가 헷갈리기 쉬우니 00:01이나 01:45처럼 **어정쩡한 시각**을 쓰는 게 좋음 - 나도 cron 작업을 **XX:13, XX:23, XX:42**처럼 설정함 시스템이 특정 시각에 이상해질 때 원인을 추적하기 쉬움 - 00:00이 문제된 적은 거의 없었음 다만 12시간제 시계를 쓰는 환경에서는 혼란이 생길 수 있음 - 시간대 문제를 겪기 전까지는 몰랐는데, 세상에는 **존재하지 않는 시각**과 **모호한 시각**이 있음 예를 들어 2시에서 3시로 넘어갈 때 2:30은 존재하지 않고, 반대로 시간을 되돌릴 때는 2:30이 두 번 생김 국가마다 DST 조정 시각이 달라서, **Chile처럼 자정이 사라지는 경우**도 있음 ([관련 블로그](https://tanin.nanakorn.com/edgecases-for-timezones/)) Java와 Ruby가 이 상황을 다르게 처리해서, Stripe 근무 초기에 **3번 연속 사고**를 냈던 기억이 있음 - cron 작업은 **정각을 피하고**, 가능하면 **새벽 4시 이후나 자정 이전**에 설정함 공유 인프라에서는 정각에 리소스 경쟁이 심하기 때문임 - systemd의 **RandomizedDelaySec** 옵션을 쓰면 충돌을 줄일 수 있음 - cron 명령 앞에 `sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ;` 같은 코드를 붙여서 **0~59분 랜덤 지연**을 주는 것도 좋은 방법임 - 중요한 예약 작업은 가능하면 **idempotent(중복 실행 안전)** 하게 만들어야 함 특히 큐 시스템이 얽혀 있을 때 이런 설계가 **문제 예방의 핵심**임