알림 재시도 루프를 추적하며 고친 1인 개발 기록

알림 자동화는 실패했을 때보다, 실패한 채로 같은 작업을 반복할 때 더 살피기 어려웠어요. 2026년 9월 29일 기록에는 시간 값의 마이크로초 표현을 Python 3.9가 읽지 못해 알림 소비기가 재시도를 반복한 수정이 남아 있어요. 바뀐 파일은 소비기와 테스트, 2개였어요.

직접 만들어 보니 재시도 로직은 예외 메시지만 보면 원인을 놓치기 쉬워요. 메시지 전송이 문제인지, 큐에서 값을 읽는 과정이 문제인지, 시간 값을 해석하는 단계가 문제인지 순서를 나눠 봐야 했어요. 이번에는 전송 직전이 아니라 시간 문자열을 읽는 경계에서 멈춘 사례로 정리할 수 있었어요.

큐에서 시간 값 읽기→시간 값 해석→알림 전송 또는 재시도

제가 잡은 기준은 3단계였어요. 먼저 입력값의 실제 형태를 확인하고, 다음으로 파서가 받을 수 있는 형태를 맞추고, 마지막으로 같은 값이 다시 들어왔을 때 테스트로 확인하는 방식이에요. 적용해 봤더니 재시도 횟수만 세는 것보다 실패 지점을 구분해 남기는 편이 다음 점검에 도움이 됐어요. 성공 여부를 추측하는 대신, 어디서 멈췄는지를 남기는 데 집중했어요.

테스트해 보면 시간 값은 눈에 보이는 형식이 같아도 소수점 이하 자리 때문에 처리 결과가 달라질 수 있어요. 그래서 정상 형식 1개만 두기보다, 마이크로초가 포함된 형식과 포함되지 않은 형식을 나눠 검증하는 편이 좋아요. 이 글의 수정도 테스트 파일 1개를 함께 바꾼 기록이므로, 코드 변경과 검증 대상을 분리하지 않으려 했다는 흔적으로 볼 수 있어요.

최근 7일 이력에는 모두 19건의 커밋이 있었어요. 그중 알림 문제 하나를 깊게 보면, 자동화는 기능을 이어 붙이는 일만이 아니라 경계값을 다시 확인하는 일이라는 점이 드러나요. 돌려 보니 재시도는 복구 장치이면서 동시에 원인을 가릴 수 있는 장치였어요.

라이프케어로그에서 플랜비(plan-b) 같은 서비스를 운영하며 알림 흐름을 다룰 때도 이 기준을 가져가려 해요. 발송 결과만 보지 않고, 입력·해석·전송의 3단계를 각각 확인하는 쪽이 작은 자동화를 오래 관리하기에 낫다고 생각해요.