34. heartbeat에서 완료한 작업이 다시 미완료로 보일 때

heartbeat가 정상으로 들어오고 작업도 이미 끝났는데, 다음 heartbeat에서 같은 항목이 다시 [ ]처럼 보이면 사람 입장에서는 “아까 한 일이 왜 또 뜨지?”가 된다. 이때 원인을 세션 문제로만 보면 자꾸 빗나간다. 실제 운영에서는 실행은 끝났는데 체크 상태와 로그 상태가 서로 다른 파일에서 어긋난 경우가 더 흔하다.

특히 OpenClaw는 세션을 gateway 기준으로 관리하고, cron은 fresh session per run, daily reset은 gateway host 기준 오전 4시에 일어난다. 그래서 heartbeat/cron이 여러 번 들어오는 환경에서는 “실행 기록은 남았는데, 다음 판정이 읽는 파일 쪽 상태가 덜 반영된” 장면이 반복될 수 있다. 핵심은 세션을 의심하기 전에 체크박스 원본 파일과 완료 로그의 source of truth를 한 번에 맞추는 것이다.

이런 증상이면 이 문서부터 보면 된다

• 11:00 작업을 이미 했는데 11:30 heartbeat에서 또 미완료처럼 보인다.
• 실행완료 로그는 있는데 오늘 계획 체크박스는 [ ]로 남아 있다.
• 재실행은 하면 안 되는데 상태 보고만 반복된다.
• 하루 동안 같은 task를 여러 번 “재동기화”하게 된다.

flowchart LR
A[heartbeat 수신] --> B[오늘 계획 읽기]
B --> C{항목이 [ ] 인가?}
C -- 아니오 --> D[다음 항목 확인]
C -- 예 --> E{같은 task-key 실행완료 로그 존재?}
E -- 아니오 --> F[실제 미완료로 보고 실행]
E -- 예 --> G[재실행 금지]
G --> H[체크박스 원본 파일 재동기화]
H --> I[update-only 로그 기록]
I --> J[다음 heartbeat에서 재검증]

칠판 치트시트

1. 먼저 실행완료 로그가 있는지 본다
2. 완료 로그가 있으면 재실행하지 않는다
3. 체크박스가 [ ]면 상태 드리프트로 보고 파일만 다시 맞춘다
4. source of truth를 한 파일로 정하지 않으면 같은 문제가 반복된다

왜 이런 일이 반복되나

공식 Session Management 문서 기준으로 OpenClaw는 메시지를 세션 단위로 라우팅하고, cron은 fresh session per run, daily reset은 gateway host 로컬 시간 기준 4:00 AM에 일어난다. 또 세션 상태의 기준점은 gateway다.

이 말은 곧, heartbeat가 여러 번 들어오는 운영에서는 “지금 어떤 세션이냐”보다 다음 heartbeat가 읽는 파일 상태가 무엇이냐가 더 중요할 수 있다는 뜻이다. 예를 들어 아래처럼 상태가 갈라지면 반복 오판이 생긴다.

• memory/오늘.md는 [x]로 반영됨
• memory/YYYY-MM-DD.md는 여전히 [ ]로 남음
• 다음 heartbeat가 두 파일 중 뒤쪽 상태를 더 신뢰하거나, 사람이 둘 다 번갈아 읽음
• 실제 실행은 끝났는데 계속 “미완료처럼 보이는” 장면이 반복됨

공식 openclaw status 문서에서도 status는 현재 세션 스냅샷이 비어 있으면 transcript usage를 fallback으로 보강할 수 있다고 설명한다. 즉 운영 전반에서 “실시간 상태”와 “기록 기반 상태”가 섞일 수 있다는 점은 자연스러운 구조다. 작업 체크도 같은 식으로 흩어지면 판단이 흔들린다.

가장 빠른 복구 순서

1) 먼저 완료 로그가 있는지 본다

가장 먼저 볼 것은 체크박스가 아니라 task-key 완료 로그다.

• task-key=YYYY-MM-DD|HH:MM|작업명
• 같은 key의 [실행완료]가 이미 있으면 그 작업은 끝난 것이다.
• 이 경우 heartbeat는 재실행이 아니라 update-only로 처리해야 한다.

즉, [ ]만 보고 다시 실행하면 안 된다. 먼저 완료 로그부터 본다.

2) 체크박스 원본 파일을 다시 맞춘다

완료 로그가 있는데 체크박스가 [ ]라면, 이건 실행 누락이 아니라 상태 드리프트다. 이때는 작업을 다시 하지 말고 아래 둘 중 실제 운영에서 기준으로 삼는 파일을 바로 맞춘다.

• memory/오늘.md
• memory/YYYY-MM-DD.md

실무에서는 둘 다 쓰더라도, 최소한 “heartbeat 판정은 어느 파일을 기준으로 할지”를 고정해야 한다. 그렇지 않으면 다음 poll에서 또 같은 어긋남이 보인다.

3) update-only 로그를 남긴다

이 상황은 새 완료가 아니다. 따라서 [실행완료]를 한 번 더 찍지 말고 아래처럼 [업데이트] 한 줄만 남기는 편이 맞다.

• 완료 로그 존재 확인
• 체크박스만 [x]로 재동기화
• 재실행 없음

이렇게 해야 추적할 때도 “실제 작업 1회 + 상태 정리 여러 번”이 구분된다.

4) source of truth를 하나로 고정한다

증상이 반복되면 운영 규칙을 이렇게 바꾸는 게 가장 빠르다.

• heartbeat 판정용 파일 1개를 먼저 정한다.
• 나머지 파일은 보고용 mirror로 취급한다.
• 완료 시에는 기준 파일 → 보조 파일 순서로 반영한다.
• 다음 heartbeat에서는 기준 파일만 보고 집행 여부를 판정한다.

이렇게 하면 “이미 끝난 작업이 또 뜨는” 증상이 크게 줄어든다.

빠른 판별표

보이는 증상	실제 원인 가능성	첫 조치
체크박스는 [ ]인데 완료 로그가 있음	상태 드리프트	재실행 금지 + [x] 재동기화
완료 로그도 없고 체크박스도 [ ]	실제 미완료	즉시 실행
한 파일은 [x], 다른 파일은 [ ]	source of truth 불명확	기준 파일 1개로 고정
heartbeat마다 같은 update-only가 반복	동기화 순서 불안정	완료 반영 순서 재정의

현장 미니 사례

사례 A) 11:00 작업을 이미 했는데 11:30에 또 뜸

• 상황: 실행완료는 이미 기록됨
• 실제 원인: 일일 로그 파일 체크박스가 [ ]로 남음
• 처리: 재실행 없이 [x]로 재동기화 + update-only 기록
• 정리: 작업이 아니라 상태만 어긋난 경우

사례 B) 오늘.md는 [x]인데 날짜별 파일은 [ ]

• 상황: 사람이 heartbeat마다 두 파일을 번갈아 읽음
• 실제 원인: 기준 파일이 정해져 있지 않음
• 처리: 판정 기준을 memory/오늘.md 1개로 먼저 고정
• 정리: 운영 규칙 부재가 반복 오판을 만듦

사례 C) 같은 작업이 하루 종일 재동기화만 반복됨

• 상황: 재실행은 안 하지만 update-only 로그가 계속 쌓임
• 실제 원인: 완료 반영 순서나 파일 동기화 루틴이 안정적이지 않음
• 처리: 완료 시 기준 파일→보조 파일 순서로 강제
• 정리: 작업 문제보다 기록 체계 문제에 가까움

검색형 FAQ

Q1. 체크박스가 [ ]면 무조건 다시 실행해야 하나요?

A. 아니다. 같은 task-key의 [실행완료] 로그가 있으면 먼저 상태 드리프트를 의심해야 한다.

Q2. 왜 세션 문서를 같이 봐야 하나요?

A. heartbeat/cron이 여러 런으로 들어오면 “작업이 여러 번 평가되는 구조” 자체는 정상이다. 그래서 세션 구조를 이해해야 파일 상태 드리프트와 실제 미실행을 구분하기 쉬워진다.

Q3. 가장 안전한 운영 규칙은 무엇인가요?

A. 집행 여부 판정은 한 파일만 기준으로 삼고, 나머지는 mirror로 두는 것이다.

내부링크·다음글 연결 (10)

1. 12. 14시 할일이 자동 실행 안 될 때
2. 11. Scheduled reminder 떴는데 액션이 안 이어질 때
3. 32. HEARTBEAT_OK만 반복될 때 바로 고치는 방법
4. 16. cron 시간 바꿨는데 예전 시각에 계속 돌 때
5. 17. cron은 돌았는데 텔레그램 전달이 안 올 때
6. 23. Quota 리셋됐는데 요청 막힘 복구
7. 28. OpenClaw 예전 세션 계속 붙을 때 정리
8. 10. Quota 리셋 알림 왔는데 quota exceeded 계속 뜰 때
9. 25. 크론·서브에이전트 분산운영
10. 31. Quota 리셋 안 될 때 10분 복구 가이드

다음 추천 읽기: 32. HEARTBEAT_OK만 반복될 때 바로 고치는 방법

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