도서 제작 상태와 봉사 인정 상태를 확인하려고 개인용 모니터 두 개를 만들었다. 웹페이지의 표를 읽어 직전에 저장한 상태와 비교하고, 변화가 있으면 텔레그램으로 알려 주는 작은 프로그램이다. 그런데 알림이 없다는 사실만으로는 상태가 그대로인지, 점검이 시작되지 않았는지, 전송이 실패했는지 알 수 없다.
그래서 이 작업에서는 바뀐 상태를 찾는 규칙만큼이나 실행과 전송의 흔적을 남기는 방식이 중요했다. 2026년 5~6월 실행 기록과 코드에는 조회 시작, 변경 없음, 오류를 나누어 기록한 부분이 남아 있다. 지금도 같은 환경에서 계속 가동한다는 뜻은 아니다.
먼저, 점검이 시작됐는지
예약 실행을 등록했다고 매번 코드가 실행되는 것은 아니다. 함께 작성한 설정 안내에는 15분 간격의 점검뿐 아니라 노트북의 AC 전원 조건도 적어 두었다. 배터리 사용 중 실행을 막는 조건이나 절전 상태가 있으면 프로그램 안의 변경 감지까지 도달하지 못할 수 있다.
프로그램은 목록을 조회하기 시작할 때 로그를 남긴다. 따라서 알림이 없는 날에는 마지막 조회 시작 시각부터 확인하고, 실행 기록 자체가 비어 있으면 예약 조건과 컴퓨터 상태를 따로 살펴야 한다. 반대로 ‘변경 없음’이 기록됐다면 적어도 그 점검에서 비교 단계까지 진행했다는 뜻이다. 다만 프로그램이 남긴 로그만으로 예약 시각마다 정상 실행됐다고 보증할 수는 없다.
전송 실패가 ‘확인한 변화’로 지워지지 않도록
상태 비교에는 직전 기록이 필요하다. 문제는 새 상태를 저장한 뒤 알림 전송에 실패하면 다음 점검에서 이미 본 변화로 취급할 수 있다는 점이다. 이 경로를 막기 위해 전송에 실패한 기존 항목은 저장 전에 상태값을 직전 값으로 되돌리도록 구성했다. 다음 실행에서도 차이가 남아 다시 알림 대상이 되게 한 것이다.
전송 함수도 HTTP 요청이 끝났다는 사실만으로 성공 처리하지 않는다. 응답 상태와 텔레그램의 성공 표시를 확인하며, 실패하면 기본 세 번까지 시도한 뒤 호출한 쪽에 오류를 돌려준다. 그 오류를 받아 실패 항목을 남기는 코드가 두 모니터에 있다. 다만 통신 응답이 성공했다는 것과 내가 메시지를 읽었다는 것은 별개다.
이 복구 규칙에는 범위가 있다. 직전 기록이 있던 항목은 예전 상태로 돌릴 수 있지만, 처음 등장한 항목에는 돌아갈 값이 없다. 도서 모니터의 코드는 이런 새 항목의 전송 실패까지 다음 점검으로 확실히 넘기는 구조는 아니다. 모든 알림 유실을 해결했다고 말하기보다, 보완한 경로와 남은 빈틈을 나누어 보는 편이 정확하다.
중간 상태를 못 봤어도 완료를 알리기
주기적으로 페이지를 읽으면 두 점검 사이의 변화는 직접 볼 수 없다. 도서 모니터에서는 상태를 작업 중, 검토 대기, 완료, 재제작처럼 분류하고, 완료나 재제작 범주에 들어온 항목을 알리도록 했다. 중간에 ‘완료요청’을 보지 못했어도 최종 상태를 확인할 수 있게 한 선택이다.
이미 기준 기록을 만든 뒤라면 새로 나타난 항목이 처음부터 완료·재제작 상태여도 알림 대상에 넣는다. 반면 프로그램의 최초 실행은 현재 목록을 기준점으로 저장할 뿐이다. 이 규칙을 다른 봉사 상태 모니터까지 똑같이 적용한 것은 아니며, 그쪽은 이전 목록에 있던 항목의 상태가 달라졌을 때 알린다.
봉사 인증을 기다리는 별도 감시 분기에는 대기 항목이 모두 정리되면 스스로 꺼지는 조건도 넣었다. 2026년 6월 25일 로그에서 이 종료가 확인된다. 계속 켜 두는 것만이 정상 동작은 아니었던 셈이다.
남아 있는 것은 개인 작업에 맞춘 코드와 실행 기록이다. 2026년 9월 7일 현재 가동 여부나 지속적인 알림 성공률은 다시 측정하지 않았다. 나는 이 기록에서 알림을 더 붙이는 방법보다, 조용한 상태를 서로 다른 원인으로 나누어 확인하는 방식을 남기고 싶었다.