하트비트 감시에서 오래된 오류를 분리한 빌드로그

작은 자동화도 시간이 지나면 판단 기준이 흐려져요. 이번 기록은 상태 감시 스크립트를 손본 작업에서 시작합니다. 2026년 9월 14일에 감시 항목 관련 커밋이 3건 있었고, 그중 1건은 과거의 오류 한 줄 때문에 상태가 계속 DOWN으로 남는 경우를 다뤘어요.

커밋 기록을 직접 확인해 보니, 핵심은 오류 문구를 더 많이 찾는 일이 아니었어요. 이후에 정상 처리가 있었는지 함께 확인할 수 있도록 success 패턴을 추가하는 선택이었죠. 오류만 남아 있으면 오래전 실패와 현재 상태를 구분하기 어려워집니다.

오류 기록 확인→이후 정상 기록 확인→현재 상태 판단

제가 변경 파일 목록을 직접 대조해 보니, 이 흐름은 감시 스크립트 1개 파일에 모여 있었어요. 이런 경우 조건을 여러 곳에 흩뜨리기보다, 상태를 결정하는 규칙을 한곳에서 읽을 수 있게 두는 편이 검토하기 편합니다. 특히 감시는 결과를 만드는 코드보다 결과를 해석하는 코드에서 오해가 생기기 쉬워요.

검사 규칙을 적용해 보면 먼저 “실패 기록이 있는가”를 확인하고, 다음으로 “그 뒤 정상 기록이 있는가”를 따져볼 수 있어요. 두 번째 질문이 빠지면 이미 회복한 작업도 계속 문제처럼 보일 수 있습니다. 저는 새 감시 항목을 준비할 때도 이 순서를 기준으로 확인하려고 해요.

• ✓과거 오류
• ✓이후 정상 처리
• ✓현재 상태의 분리

같은 날에는 배포 창에서 켤 항목을 미리 준비한 커밋도 2건 남아 있었어요. 아직 활성화하지 않은 조건과 실제로 동작하는 조건을 구분해 기록하는 방식은, 나중에 상태 화면을 읽을 때 혼선을 줄입니다. 테스트해 보면 감시 규칙은 짧아 보여도 실패·회복·대기 상태를 각각 어떻게 읽을지 먼저 정해야 한다는 점이 드러나요.

라이프케어로그처럼 여러 플랜 시리즈를 만드는 과정에서는 이런 보이지 않는 운영 규칙도 제품 작업의 일부예요. 플랜씨(plan-c)나 플랜비(plan-b)처럼 사용자 기능을 다루는 작업과 별개로, 자동화가 현재 상태를 정직하게 알려 주는 기반도 계속 점검하고 있습니다.