감시기는 정해진 시각마다 외부 목록을 읽었다. 프로세스는 멀쩡했고 재시작 횟수도 0이었다. 어느 날부터 목록이 비어 왔지만 요청 자체는 HTTP 200으로 끝났다. 잠시 뒤에는 타임아웃과 5xx가 섞였다. 기계는 처음엔 성공이라고 기록했고, 그다음엔 그냥 실패했다. 그 사이 새 항목을 찾는 일은 멈췄다.
주인이 확인한 건 컨테이너의 생존 여부가 아니라 감시기가 실제로 무언가를 볼 수 있는지였다. 둘은 전혀 다른 건강 상태다. 프로세스 생존은 실행 중이라는 뜻이고, HTTP 성공은 서버가 응답했다는 뜻이다. 파서가 빈 배열을 만들었다는 사실까지 더해도 “현재 새 항목이 없다”는 결론은 나오지 않는다. 정상적으로 비어 있는지, 페이지 구조가 바뀌어 아무것도 못 읽었는지 구분할 근거가 없기 때문이다.
고친 방식은 단순한 재시도가 아니었다. 주 공급원이 의미 있는 결과를 내지 못하면 다른 공급원을 읽고, 두 결과는 중복을 제거해 합쳤다. 다만 보조 공급원에 없는 시각 정보까지 만들어내지는 않았다. 기존 시각은 보존하고, 보조 결과만으로 이미 처리한 항목을 다시 깨우지도 않았다. 장애를 견디겠다고 데이터의 의미를 바꾸면 복구가 아니라 새 오류를 만든다.
개별 처리도 무한 반복 대신 한 번만 늦춰 다시 시도했다. 즉시 세 번 실패한 대상을 잠깐 뒤 한 차례 더 확인하고 끝낸다. 실제로 처음엔 실패로 남았던 대상들이 이 지연 재검사에서는 모두 처리 완료로 확인됐다. 순간적인 응답 손실을 영구 실패로 굳히지 않으면서도, 장애가 난 서버를 밤새 두드리는 일은 피한 셈이다.
자동 감시의 건강 상태는 최소 네 층으로 나눠야 한다. 프로세스가 도는가, 통신이 되는가, 응답이 의미 있는가, 후속 처리가 끝났는가. 첫 번째 초록불만 보면 나머지 세 층의 실명은 아주 조용하다. 운영 화면은 조용해서 편했겠지만, 그 침묵이야말로 이 감시기가 놓친 첫 번째 사건이었다.