Python 3.9 마이크로초 파싱 오류를 고친 알림 큐 기록

알림 기능을 만들 때 어려운 지점은 메시지를 보내는 코드만이 아니었어요. 큐에 쌓인 항목이 어떤 시간 형식으로 저장되고, 소비하는 쪽이 그 값을 끝까지 읽을 수 있는지도 함께 맞아야 했습니다.

2026년 9월 29일 기록에는 데이터베이스가 잘라낸 마이크로초 표현을 Python 3.9에서 읽지 못해 알림 소비기가 재시도를 반복한 수정이 남아 있어요. 변경 범위는 소비 스크립트와 테스트, 2개 파일이었습니다. 직접 만들어 보니 시간 값은 겉으로는 평범한 문자열처럼 보여도, 저장소와 실행 환경 사이에서 해석 규칙이 달라질 수 있었습니다.

이번에는 문제를 크게 포장하기보다 재현 경로를 좁히는 데 집중했어요. 먼저 큐 항목의 시간 값이 어디서 만들어지는지 확인하고, 그 값을 소비 코드가 어떤 방식으로 파싱하는지 따라갔습니다. 그다음 실패한 항목이 재시도 흐름에서 어떤 상태로 남는지 봤어요. 기록에는 만료 갱신 179건이 unknown 상태에 머물렀다는 맥락도 남아 있었습니다.

시간 값 저장→Python 파싱→알림 소비 결과 기록

적용해 봤더니 이런 종류의 수정은 파서 한 줄만 바꾸고 끝내기보다, 실패 입력을 테스트에 남기는 편이 훨씬 중요했어요. 같은 형태의 시간 값이 다시 들어왔을 때 소비기가 어떤 결과를 내는지 자동으로 확인할 수 있기 때문입니다. 테스트해 보면 정상 입력만 통과하는지보다, 잘린 정밀도의 입력을 어떻게 다루는지가 더 선명하게 드러납니다.

최근 7일간 개발 사실 시트에는 19건의 커밋이 기록돼 있었고, 그중 이 수정은 알림 전달 이전 단계의 데이터 해석을 다룬 작업이었어요. 라이프케어로그처럼 여러 플랜 시리즈를 운영하는 1인 개발 환경에서는 작은 자동화도 상태 기록과 테스트를 같이 남겨야 나중에 원인을 다시 찾을 수 있습니다.

돌려 보니 알림 자동화는 “보냈다”는 한 문장으로 판단하기 어렵다는 점도 분명했어요. 큐 적재, 시간 해석, 재시도, 최종 결과 기록은 각각 따로 확인해야 합니다. 다음에 비슷한 오류를 만나도 시간 문자열 자체와 소비기의 파싱 규칙, 그리고 실패 입력을 담은 테스트부터 차례로 확인하려고 해요.