크론 vs 하트비트: AI 자동화는 언제 무엇을 써야 할까
AI 자동화를 설계할 때 가장 자주 부딪히는 질문이 있다. “이 작업, cron으로 돌릴까? heartbeat에서 처리할까?” 둘 다 주기 실행처럼 보이지만 목적이 다르다. 결론부터 말하면 정시·독립 실행은 cron, 문맥 기반·배치 점검은 heartbeat가 기본 축이다.
1) 개념 비교: 같은 자동화, 다른 철학
cron은 “정해진 시각에 정확히 실행”하는 스케줄러다. 9:00 보고서 발행, 매주 월요일 백업, 매달 정산처럼 시간 정확도가 핵심인 업무에 강하다. 작업 단위도 비교적 독립적이라 실패 원인 추적이 쉽다.
반면 heartbeat는 “주기적으로 상태를 확인하며 필요한 행동을 묶어 처리”하는 방식이다. 예를 들어 메일/캘린더/알림을 한 번에 점검해 중요한 변화가 있을 때만 알려주는 식이다. 즉 heartbeat는 이벤트 감시와 컨텍스트 판단에 유리하다.
정리하면, cron은 시계 중심, heartbeat는 상황 중심이다. OpenClaw 기준으로 보면 cron은 정확한 타이밍 작업에, heartbeat는 과도한 잡 분할을 줄이고 운영 피로를 낮추는 데 효과적이다.
2) 실제 사례 5개
매일 09:00 블로그 연재 발행
시간 고정이 핵심이므로 cron이 맞다. heartbeat로 처리하면 실행 시점이 밀릴 수 있다.하루 3회 메일·캘린더·멘션 점검
각각 cron 3개로 쪼개기보다 heartbeat 한 번에서 묶는 편이 효율적이다. 중요 이벤트만 필터링해 알림 과다를 줄일 수 있다.주간 KPI 리포트 생성 + 슬랙 전송
마감 시각이 중요하므로 cron 우선. 단, 전송 전 “데이터 최신 여부 확인”은 heartbeat 성격의 검사 로직을 섞는 하이브리드가 좋다.서비스 장애 감시 후 조건부 알림
단순 정시 실행보다 상태 변화 감지가 본질이라 heartbeat가 유리하다. 정상 구간엔 조용히 지나가고, 임계치 초과 시에만 반응한다.야간 배치(대용량 변환/백업)
리소스 충돌 회피를 위해 cron으로 정확히 제어하는 게 안전하다. heartbeat 단독 운용은 다른 점검 작업과 섞여 야간 소음을 만들 수 있다.
3) 운영비용/안정성 기준으로 고르는 법
판단 기준은 세 가지면 충분하다.
- 시간 정확도 요구: “몇 분 늦어도 되나?” 아니면 cron.
- 문맥 판단 필요성: 여러 신호를 함께 보고 결정해야 하면 heartbeat.
- 실패 복구 단순성: 재실행·중복 방지가 중요하면 작업을 잘게 나눈 cron이 유리.
여기서 자주 생기는 오해도 짚어야 한다.
- 중복 실행: cron 작업 시간이 주기보다 길면 겹친다. 락(잠금)이나 idempotency 키를 넣어야 한다.
- 알림 과다: heartbeat를 “체크마다 무조건 알림”으로 설계하면 사람이 먼저 지친다. 변화 기반 알림으로 줄여야 한다.
- 야간 소음: 23:00~08:00 무해 시간대를 두고, 긴급 등급만 통과시키는 정책이 필요하다.
결국 좋은 AI 자동화는 “많이 돌리는 것”이 아니라 “필요할 때 정확히 반응하는 것”이다. cron으로 시간의 신뢰를 확보하고, heartbeat로 운영 맥락을 흡수하면 OpenClaw 자동화는 훨씬 조용하고 단단해진다.