surface check 뒤 조용한 실패, deadman으로 잡기

surface check가 통과했는데도 자동화가 멈춘 날이 있어요. 혹시 결과물은 없는데 대시보드만 초록인 적 없나요? 이럴 때는 surface check 1개만으로는 부족하고, 조용히 멈춘 자율 루프를 따로 보는 deadman이 필요해요.

왜 surface check만으로는 부족할까요

직접 만들어 보니 surface check는 false-green을 잘 잡아줘요. 다만 cron이 안 돌거나 프로세스가 죽은 경우는 다른 실패모드였어요. 돌려 보니 "실행 성공" 로그가 있어도 실효과가 0인 채로 2주를 지나갈 수 있었고, 그동안 모델·프롬프트·워크플로우는 계속 정상처럼 보였어요.

surface check 통과→semantic success 확인→last_success 기록

deadman은 무엇을 봐야 할까요

제가 적용해 봤더니 기준은 3개면 충분했어요.

• 결과물이 실제로 생긴 뒤에만 성공으로 봐요.
• 그 직후에만 last_success를 atomic 하게 기록해요.
• 알림은 원래 워크플로우와 다른 경로에서 보내요.

30분 주기 잡은 1개는 3시간, 하루 1회 잡은 루프는 26시간, 2시간 주기 러너는 8시간처럼 stale 기준을 따로 줬어요. 테스트해 보면 이 숫자는 정답이라기보다, 얼마나 늦게 죽음을 알아차릴지 정하는 운영값에 가까워요.

• ✓실제 결과물
• ✓마지막 성공 시각
• ✓독립 경보 경로

AI 자동화에서 특히 중요한 이유

AI 루프는 "작업 없음"과 "수집기 고장"을 섞는 순간 더 위험해져요. 직접 만들어 보니 둘을 합친 날부터 다음 프롬프트는 빈 입력으로도 조용히 돌아갔어요. 적용해 봤더니 모델을 더 바꾸는 것보다, 실패를 다른 이름으로 숨기지 않는 편이 훨씬 도움이 됐어요.

라이프케어로그에서 플랜씨(plan-c)처럼 로그인 없이 바로 쓰는 작은 도구를 운영할 때도, 결국 믿을 건 모델 응답보다 실제 산출물과 마지막 성공 시각이었어요. 작은 도구라도 오래 돌릴 생각이라면 surface check 1개와 deadman 1개를 같이 두세요. 직접 만들어 보니 자동화의 품질은 똑똑한 프롬프트보다 멈췄을 때 바로 들키는 구조에서 더 많이 갈렸어요.