Zima Cron은 일반 Docker 컨테이너로 추가되는 대신 ZimaOS용으로 직접 게시된 몇 안 되는 일정 관리 도구 중 하나입니다. IceWhale의 2026년 1월 튜토리얼에서는 다음과 같이 설치하는 방법을 보여 줍니다. zpkg간격 기반 작업 또는 cron 표현식 작업을 생성하고, 로그를 통해 실행을 확인하며, 스크립트·백업 또는 정기적인 유지 관리에 사용할 수 있습니다.
소스 스레드에는 또 다른 중요한 내용이 있습니다. 이 글의 이전 짧은 버전에서는 지나치게 축약했던 내용으로, 시스템에 따라 재부팅 후 지속성이 일관되지 않았습니다. 일부 ZimaOS 1.5.3 및 1.5.4 사용자는 예약된 작업을 모두 잃거나 다음과 같은 문제를 발견했습니다. zima-cron.service 재시작 후 비활성 상태가 되었지만, 깨끗한 테스트 환경에서는 작업이 재부팅 후에도 유지되었습니다. 따라서 올바른 결론은 단순히 “설치하고 잊어버리면 된다”가 아니라 “버전에 따라 지속성에 유의해야 하는 공식 스케줄러”입니다.
공식 zpkg 패키지 관리자로 Zima Cron 설치
IceWhale의 튜토리얼은 ZimaOS 터미널에서 시작하며 다음 명령을 사용합니다.
zpkg install zima_cron소스에서는 설치 후 재부팅이 필요하지 않다고 명시합니다. 그러면 ZimaOS 웹 인터페이스의 앱 목록에 Zima Cron이 표시됩니다.
zpkg.중요한 작업을 예약하기 전에 안전한 테스트 작업 생성
공식 튜토리얼에서는 파괴적인 유지 관리 명령 대신 안전한 1분 간격 로그 작업을 의도적으로 사용합니다. 이는 모든 스케줄러에 적용할 수 있는 좋은 방식입니다. 백업이나 서비스 재시작을 자동화하기 전에 백엔드가 실행되는지, 일정이 올바르게 해석되는지, 출력이 예상한 위치에 기록되는지 먼저 확인해야 합니다.
공식 예제에서는 로그 파일에 타임스탬프를 추가합니다.
bash -c 'echo "$(date "+%Y-%m-%d %H:%M:%S") zima cron works" >> /DATA/zima_cron_test.log'이 명령은 텍스트를 추가하기만 하므로 애플리케이션 상태를 수정하지 않고 일정 실행을 확인하는 데 적합합니다.
간단한 반복에는 간격 일정 사용
정확한 시계 시간이 중요하지 않을 때는 간격 일정이 적합합니다. 몇 분마다 실행하는 가벼운 상태 확인이나 몇 시간마다 실행하는 정리 작업이 그 예입니다.
중요한 작업에서는 “24시간마다”가 항상 “매일 오전 4시”와 같은 의미는 아니라는 점을 기억하세요. 특히 서비스가 재시작된 후에는 더욱 그렇습니다. 특정 시각이 중요하다면 cron 표현식을 사용하세요.
달력 기준 일정을 위해 표준 cron 표현식을 사용하세요
공식 튜토리얼에서는 표준 cron 구문도 보여 줍니다. 예를 들면 다음과 같습니다.
*/5 * * * *5분마다 실행됩니다. 일반적인 cron 표현식은 매일, 매주, 매월 또는 특정 요일별 일정을 나타낼 수 있으므로 Zima Cron은 고정 간격만 사용하는 것보다 유연합니다.
복잡한 표현식을 배포하기 전에 무해한 로깅 명령으로 테스트하고, 최소 두 번 성공적으로 실행되었는지 확인하세요.
Zima Cron과 출력 파일에서 실행을 확인하세요
완전한 테스트에서는 스케줄러 UI와 예상되는 결과를 모두 확인해야 합니다. 예를 들어, /DATA/zima_cron_test.log. 이 방법은 UI에는 작업이 존재하지만 권한, 경로, 인용 부호 또는 바이너리 누락으로 인해 명령이 실패하는 경우를 포착합니다.
앱 재시작을 예약하려면 올바른 명령 경계를 설정해야 합니다
한 사용자가 매일 오전 4시에 Home Assistant를 재시작하는 방법을 물었습니다. 해당 스레드에는 특정 설치 앱을 관리하기 위한 공식 IceWhale 명령이 안내되지 않았으므로, 이 글에서 임의로 명령을 만들어서는 안 됩니다. Zima Cron은 셸 명령을 실행할 수 있지만, 정확한 명령은 해당 앱이 ZimaOS에서 어떻게 관리되는지와 앱 관리 계층 외부에서 재시작해도 안전한지에 따라 달라집니다.
수동으로 이미 검증한 명령에 스케줄러를 사용하세요. 첫 테스트를 운영 애플리케이션 재시작으로 진행하지 마세요.
주요 주의 사항: 일부 사용자는 재부팅 후 작업을 잃었습니다
1월 26일, 한 ZimaOS 1.5.3 사용자는 재부팅 후 저장된 작업이 사라졌다고 보고했습니다. 777-Spider는 IceWhale에서 해당 문제를 확인하겠다고 답변했습니다. 이후 추가 사용자들도 유사한 동작을 재현하면서, 이는 단순한 오해가 아닌 실제 안정성 문제로 여겨지게 되었습니다.
이후 한 보고에 따르면, 통제된 클린 설치에서는 정상적으로 작동했습니다. zima-cron.service 활성 상태가 유지되고, 재부팅 후에도 작업이 계속 표시되었으며, 로깅도 계속되었습니다. 이는 고무적으로 보였지만, 이야기는 여기서 끝나지 않았습니다.
깔끔한 테스트와 실제 환경 테스트에서 서로 다른 결과가 나왔습니다
이후 한 참여자는 다음을 통해 Zima Cron을 설치했습니다. zpkg그 후 작업을 생성했으며, 재부팅 후 작업이 사라지고 새 작업을 생성할 수 없었다고 보고했습니다. 해당 서비스 상태는 다음과 같았습니다.
zima-cron.service
Loaded: loaded
Active: inactive (dead)이는 서비스가 자동으로 시작되고 작업이 유지된 정상 시스템의 결과와 정면으로 배치됩니다. 올바른 해석은 지속성 문제가 환경이나 빌드에 따라 달랐으며 모든 사용자에게 결정적으로 해결된 것은 아니라는 것입니다.
재부팅 후 확인할 사항
스레드에서는 서비스가 여전히 활성 상태인지, 그리고 설치가 정상적으로 수행되었는지 확인하라고 권장했습니다. zpkg. 중요한 배포의 경우 재부팅 후 최소 QA는 다음과 같아야 합니다.
- ZimaOS 시스템을 의도적으로 재시작하세요.
- Zima Cron이 계속 표시되는지 확인하세요.
- 저장된 작업이 계속 표시되는지 확인하세요.
- 백엔드 서비스가 활성 상태인지 확인하세요.
- 다음 예약 실행을 기다리세요.
- UI 상태만 확인하지 말고 작업의 실제 출력도 검증하세요.
지속성 문제는 공개적으로도 보고되었습니다
Zima Cron 프로젝트에는 재부팅 후 작업이 사라지고 서비스가 비활성 상태가 되는 현상을 설명하는 공개 이슈가 있습니다. 무인 유지 관리에 의존하기 전에 재부팅 후 지속성 보고서의 현재 상태를 확인하세요.
테스트하지 않은 스케줄러를 유일한 백업 트리거로 사용하지 마세요
Zima Cron은 자동화에 유용하지만, 재시작 후 예약된 백업이 아무런 알림 없이 사라진다면 실행되지 않았다는 사실을 알고 있는 수동 백업보다 더 위험합니다. 작업이 중요하다면 스케줄러 테스트를 독립적인 백업 상태 확인 및 복원 검증과 함께 진행하세요.
Zima Cron FAQ
Zima Cron 설치 명령은 공식 명령인가요?
예. zpkg install zima_cron IceWhale 튜토리얼에서 777-Spider가 게시했습니다.
일반적인 cron 표현식을 사용할 수 있나요?
예. 공식 튜토리얼은 간격 기반 일정과 표준 cron 표현식을 모두 지원합니다.
작업이 재부팅 후에도 확실히 유지되나요?
소스 스레드만으로는 보편적인 보장을 할 수 없습니다. 일부 정상 환경의 테스트는 성공했지만, 다른 1.5.x 시스템에서는 작업이 반복적으로 사라지거나 서비스가 비활성 상태로 남았습니다.
중요한 작업을 맡기기 전에 무엇을 해야 하나요?
실제로 재부팅 테스트를 수행하고, 작업이 계속 정의된 상태인지 확인한 다음 재부팅 후 명령이 성공적으로 실행되는지 확인하세요.
