16. cron 시간을 바꿨는데 예전 시각에 계속 돌 때

분명히 “아침 브리핑을 06:30으로 바꿔 달라”고 했는데 실제로는 06:00 기준으로 계속 돌거나, 시간은 맞는 것 같은데 결과물이 안 오면 헷갈리기 쉽다. 이때 핵심은 말로 약속한 시간 변경과 실제로 저장된 cron 스케줄 변경을 분리해서 보는 것이다. 현장에서는 둘이 같다고 생각하다가 원인을 놓치는 경우가 많다.

또 한 가지 자주 섞이는 문제는, 시간은 제대로 맞췄는데 실행 중 한 소스 fetch가 실패하면서 전체 브리핑이 중간에 끝나 버리는 경우다. 그래서 이 문제는 늘 “스케줄이 안 바뀐 것”인지, “제시간에 돌았지만 실행이 실패한 것”인지를 먼저 나눠서 봐야 빨리 풀린다.

30초 핵심 요약

• 대화에서 시간을 바꿨다고 해서 저장된 cron job이 자동으로 바뀌는 건 아니다.
• 먼저 실제 job의 expr와 tz가 무엇으로 저장돼 있는지 확인해야 한다.
• 시간이 맞는데도 결과가 없으면, 다음은 최근 실행 로그와 fetch 실패 여부를 본다.
• 가장 빠른 순서는 list → runs → 필요 시 run → 수정/재등록이다.

칠판 치트시트

1. 원하는 시간과 실제 저장 시간을 분리해서 본다
2. tz=Asia/Seoul이 맞는지 먼저 본다
3. 최근 실행이 06:00에 찍혔는지 06:30에 찍혔는지 확인한다
4. 시간이 맞아도 브리핑이 없으면 실행 실패 로그를 본다
5. 애매하면 기존 job을 제거하고 다시 등록하는 편이 덜 꼬인다

flowchart LR
A[브리핑 시간 변경 요청] --> B{저장된 cron job도 실제로 바뀌었나?}
B -- 아니오 --> C[expr/tz 수정 또는 재등록]
B -- 예 --> D{최근 실행 시각이 기대와 같은가?}
D -- 아니오 --> E[timezone 또는 스케줄 재확인]
D -- 예 --> F{실행 결과물이 생성됐나?}
F -- 아니오 --> G[fetch 실패/중간 에러 점검]
F -- 예 --> H[정상]
C --> H
E --> H
G --> H

이 문제를 먼저 이렇게 해석하면 덜 꼬인다

OpenClaw의 cron은 “언제(schedule)“와 “무엇을(payload)“가 분리되어 있다. 그래서 사용자가 채팅에서 “6시를 6시 반으로 바꿔줘”라고 말한 것과, 실제 gateway host에 저장된 job 정의가 바뀐 것은 같은 일이 아닐 수 있다. OpenClaw cron 문서는 이 스케줄이 영구 저장된 설정으로 동작한다는 점을 전제로 한다.

즉, 이런 상황은 크게 둘 중 하나다.

1. 스케줄 자체가 예전 값으로 남아 있다
2. 스케줄은 맞지만 실행 중 실패해서 결과가 안 보인다

이 둘을 섞어 보면 자꾸 재시작만 하게 되고, 실제 원인 찾기는 늦어진다.

왜 자주 생기나

1) 채팅에서 바꿨지만 저장된 job은 그대로다

가장 흔한 케이스다. 사람 입장에서는 “시간 변경 요청을 했으니 끝났다”고 느끼지만, 실제 job 정의가 갱신되지 않으면 기존 expr로 계속 돈다.

예를 들어 원래 잡이 0 6 * * *였는데, 말로만 06:30을 합의하고 실제 저장본은 그대로 두면 다음날도 06:00에 실행된다.

2) 시간대(tz)는 안 보고 시각 숫자만 본다

07:00, 06:30 같은 숫자만 맞추고 tz를 안 보면, 기대한 서울 시간과 실제 실행 기준이 달라질 수 있다. 반복 잡은 특히 Asia/Seoul 같은 timezone이 맞는지 먼저 보는 편이 안전하다.

3) 스케줄은 맞는데 실행이 중간 실패한다

이 경우가 더 헷갈린다. 로그만 얼핏 보면 “정해진 시각에 안 돌았다”처럼 느껴지지만, 실제로는 제시간에 시작했고 특정 web fetch나 후속 처리에서 에러가 나서 결과가 안 남는다.

즉, “미수신 = 스케줄 실패”로 바로 단정하면 안 된다.

5분 복구 순서

운영자 기준으로는 아래 순서가 가장 빠르다.

1) 먼저 최근 실행 시각부터 본다

openclaw cron list
openclaw cron runs --id <job-id>

여기서 확인할 건 단순하다.

• 내가 생각한 job이 맞는가
• 최근 실행이 몇 시로 찍혔는가
• 정말 06:00에 도는지, 아니면 06:30에 돌았는데 실패한 건지

이 단계만으로도 원인이 절반은 갈린다.

2) expr와 tz를 같이 본다

시간 숫자만 보면 놓치기 쉽다. 반복 잡은 항상 아래 두 개를 한 세트로 봐야 한다.

• expr: 실제 반복 시각
• tz: 그 시각을 어느 시간대 기준으로 해석하는지

서울 기준 아침 브리핑이라면, 보통은 tz: Asia/Seoul이 같이 맞아 있어야 한다.

3) 스케줄이 맞는지 헷갈리면 강제 실행으로 분리한다

openclaw cron run <job-id>

강제 실행의 목적은 “시간 문제”와 “실행 내용 문제”를 자르는 것이다.

• 강제 실행도 실패하면 → payload/소스/fetch 쪽 문제일 가능성이 높다
• 강제 실행은 되는데 정시 실행만 이상하면 → schedule/tz 저장 상태를 다시 봐야 한다

4) 최근 실행은 맞는데 결과가 없으면 에러 원인을 본다

이 단계에서는 “왜 안 돌았지?”가 아니라 **“왜 끝까지 못 갔지?”**라고 질문을 바꾸는 게 좋다.

특히 브리핑류 잡은 아래처럼 섞여 실패하기 쉽다.

• 특정 외부 소스 fetch 실패
• 저장 파일명/저장 경로 불일치
• 일부 단계 예외가 전체 종료로 이어짐

그래서 스케줄 조정과 별개로, 한 소스 실패가 전체 실패가 되지 않게 **실패 내성(fallback)**을 넣는 편이 재발 방지에 효과적이다.

5) 애매하면 기존 job을 제거하고 다시 등록한다

부분 수정 상태가 불명확하면, 기존 job을 믿고 가는 것보다 다시 만드는 편이 낫다.

openclaw cron remove --id <job-id>
# 이후 원하는 expr/tz로 다시 add

장점은 단순하다.

• 지금 저장된 값이 무엇인지 헷갈리는 상태를 끝낼 수 있다
• 예전 메시지/설정과 새 설정이 섞이지 않는다

현장 미니 사례 2개

사례 A) 06:30으로 바꿨다고 생각했는데 다음날도 06:00에 돌았다

• 상황: 사용자는 시간 변경이 끝났다고 생각함
• 실제 원인: 대화상 합의만 있었고, 저장된 job의 expr는 기존 06:00 그대로였음
• 해결: 기존 job id를 기준으로 실제 스케줄을 다시 맞추고, 이후 최근 실행 시각으로 검증
• 포인트: “약속된 시간”과 “저장된 시간”은 다를 수 있다

사례 B) 06:30으로는 돌았는데 브리핑이 안 왔다

• 상황: 스케줄은 맞춘 것 같은데 사용자 입장에선 미수신
• 실제 원인: 외부 소스 하나가 실패하면서 전체 브리핑 생성이 에러 종료
• 해결: 최근 실행 기록과 실패 구간을 확인하고, 일부 fetch 실패 시에도 전체 작업은 계속되도록 실패 내성 규칙 추가
• 포인트: 시각 문제가 아니라 실행 중단 문제였다

재발 방지 원칙

1) 시간 변경 후엔 항상 “최근 실행 시각”으로 검증한다

말로 바꿨다고 끝내지 말고, 다음 실행 또는 runs --id 기록으로 실제 반영 여부를 확인한다.

2) timezone은 옵션이 아니라 필수다

특히 반복 잡은 expr만 맞추지 말고 tz까지 함께 고정해야 한다.

3) 브리핑류는 실패 내성을 넣는다

외부 소스가 하나라도 흔들릴 수 있으므로, 한 fetch 실패가 전체 결과 누락으로 이어지지 않게 설계하는 편이 좋다.

복구 확인 체크리스트

아래 4개가 맞으면 대부분 복구된 상태다.

• cron list 기준 실제 job의 시간과 tz를 설명할 수 있다.
• cron runs --id <job-id>에서 최근 실행 시각이 기대와 맞다.
• 강제 실행 시 브리핑이 정상 생성된다.
• 일부 소스 실패가 있어도 전체 작업이 중단되지 않도록 보완했다.

한 줄 결론

cron 시간이 안 바뀐 것처럼 보일 때는, 먼저 “정말 시각이 안 바뀐 건지”와 “제시간에 돌았지만 실행이 실패한 건지”를 분리해야 한다.
list → runs → run → 필요 시 재등록 순서로 보면, 불필요한 추측 없이 훨씬 빨리 복구된다.

같이 보면 좋은 문서

1. OpenClaw-06 CronJob
2. OpenClaw-31 Quota 리셋 안 됨 해결
3. OpenClaw-32 HEARTBEAT_OK 반복응답 해결
4. OpenClaw-33 gateway 무응답 해결
5. OpenClaw-35 예약 리마인더 중복발송 해결
6. OpenClaw-36 quota exceeded 해결
7. OpenClaw-37 Scheduled reminder 떴는데 액션 안 이어질 때
8. OpenClaw-38 14시 할일 자동 실행 안 될 때
9. OpenClaw-41 gateway token mismatch 해결
10. 🚀 OpenClaw 인덱스

다음 추천 읽기: 35. 예약 리마인더 중복발송 해결

---

안내: 이 문서는 생성형 AI를 활용해 작성되었습니다.