감시 스크립트가 과거 에러 한 줄로 영구 DOWN 되던 문제

자동화 파이프라인을 돌리다 보면 "죽었는지 살았는지"를 알려주는 감시 장치가 꼭 필요해집니다. 저도 로그를 읽어서 상태를 판정하는 heartbeat 스크립트를 하나 두고 쓰는데, 최근 사흘 동안 이 파일 하나만 3번 고쳤어요. 2026년 9월 14일 하루에만 세 커밋이 전부 같은 파일을 건드렸습니다.

에러 패턴만 보면 생기는 일

처음 만든 판정 로직은 단순했습니다. 로그 파일을 읽어서 에러 문자열이 있으면 DOWN, 없으면 UP. 직접 돌려 보니 처음 며칠은 잘 작동하는 것처럼 보였어요.

문제는 로그가 append-only라는 점이었습니다. 어느 시점에 에러가 한 줄 찍히면, 그 뒤로 정상 동작이 수백 줄 쌓여도 그 한 줄은 파일에 그대로 남아 있어요. 그래서 판정이 영원히 DOWN에 고정됩니다. 실제로는 복구됐는데 대시보드는 계속 빨간색인 상태죠.

로그에 에러 1줄 기록→이후 정상 동작 누적→에러 문자열은 파일에 잔존→판정 영구 DOWN

이게 왜 위험하냐면, 거짓 경보가 반복되면 사람이 알림을 무시하게 되거든요. 진짜 장애가 났을 때 못 알아채는 상태로 가는 겁니다. 감시 장치가 오히려 감시를 망가뜨리는 셈이에요.

success 패턴을 함께 보기로

고친 방향은 "에러가 있냐"가 아니라 "마지막 신호가 뭐냐"로 질문을 바꾸는 것이었습니다. success를 뜻하는 패턴도 같이 등록해 두고, 에러와 성공 중에 더 최근 것을 기준으로 판정하게 했어요.

적용해 봤더니 판정이 바로 정상으로 돌아왔습니다. 과거 흔적이 현재 상태를 덮어쓰지 않게 된 거죠.

여기서 배운 건 두 가지예요.

• ✓시간 개념 없는 판정은 과거에 갇힌다
• ✓부정 신호만으로는 복구를 표현할 수 없다
• ✓감시 항목은 배포 창에 맞춰 단계적으로 켠다

감시 항목은 한 번에 켜지 않았어요

같은 날 나머지 두 커밋은 새 감시 항목을 준비하는 작업이었습니다. 특이한 점은 코드를 넣되 주석 처리된 상태로 커밋했다는 거예요. 커밋 제목에도 "배포 창에서 주석 해제", "merge 후 주석 해제"라고 적어 뒀습니다.

처음엔 저도 이게 좀 어정쩡해 보였어요. 그런데 테스트해 보면 이유가 명확합니다. 아직 대상 시스템이 배포되지 않았는데 감시부터 켜면, 존재하지 않는 대상을 못 찾아서 DOWN이 뜹니다. 그럼 위에서 말한 거짓 경보가 또 시작되는 거죠.

그래서 코드는 미리 넣어 두되 활성화 시점만 분리했습니다. 작업 순서를 잊어버리지 않으면서도 알림은 조용한 상태를 유지하는 방법이었어요.

로그 기반 판정을 만들 때 체크할 것

며칠 만져 보고 정리한 기준입니다.

• 판정 근거에 시간 개념이 들어가 있나요? 파일 전체를 통째로 읽는다면 과거에 갇힐 수 있어요
• 부정 신호(에러)만 보고 있진 않나요? 복구를 인식할 긍정 신호가 짝으로 필요합니다
• 감시 대상이 아직 없는데 감시부터 켜고 있진 않나요? 순서를 맞춰야 알림이 신뢰를 얻어요

세 가지를 확인하는 데 몇 분이면 충분한데, 안 하면 며칠씩 잘못된 상태를 보게 됩니다.

1인 개발에서 감시가 중요한 이유

혼자 만들다 보면 서비스가 조용히 멈춰도 알려줄 사람이 없습니다. 제가 플랜씨 같은 계산기 도구나 플랜엘 법령 검색 같은 걸 운영하면서 가장 신경 쓰는 게 이 부분이에요. 사용자가 먼저 알아채는 상황은 피하고 싶으니까요.

그래서 감시 장치 자체의 정확도에 시간을 쓰는 게 아깝지 않다고 생각합니다. 거짓 경보를 내는 감시는 없는 것보다 나쁠 수도 있거든요. 이번처럼 success 패턴 하나 추가하는 작은 수정이 신뢰도를 크게 바꾸기도 하고요.

다음엔 주석 처리해 둔 감시 항목들을 실제로 켜면서 겪은 이야기를 써 볼게요.