TA 배치 밤새 멈춤 원인 - 타임아웃 없는 외부 호출 2건
밤사이 종목평가 배치가 멈춰 있었던 원인을 찾아 고쳤는데, 재발방지가 충분한지 되짚어보니 같은 유형의 구멍이 하나 더 있었다.
밤사이 배치가 멈춰 있었다
아침 점검에서 지난밤 종목평가 배치가 전혀 돌지 않은 걸 발견했습니다.
원인을 추적해보니 외부 상장목록 조회 호출 하나가 타임아웃 없이 걸려 있었습니다. 네트워크 응답이 끝까지 오지 않으면 그 호출이 영원히 대기 상태로 남는 구조였던 겁니다.
스케줄러는 "작업이 이미 실행 중"이라고 판단해서 같은 배치를 계속 건너뛰기만 했고, 그 결과 평가 결과 날짜가 하루 묵은 채로 멈춰 있었습니다.
빠르게 고치고 재시작했다
문제가 된 호출에 타임아웃을 씌우고, 이 수정을 제거하면 테스트가 실패하는 걸 확인해서 수정이 실제로 동작하는지도 검증했습니다.
관련된 상주 프로세스들을 모두 재시작해서 다시 정상적으로 돌기 시작하는 것까지 확인했습니다. 재시작 뒤로는 "이미 실행 중"이라는 이유로 건너뛰는 일이 더 없었습니다.
"이걸로 충분한가"를 다시 물었다
여기서 끝내지 않고, 수정한 내용이 재발을 막기에 충분한지 다른 AI에게 다시 검토를 맡겼습니다.
검토 결과는 "조건부로는 아니다"였습니다. 같은 외부 데이터 소스를 쓰는 호출이 하나 더 있었는데, 그쪽에는 아직 타임아웃이 없었습니다. 처음 고친 곳과 똑같은 방식으로 영원히 멈출 수 있는 구멍이었던 겁니다.
같은 유형의 문제가 코드베이스 안에 또 숨어 있을 수 있다는 뜻이라, 이번에는 그 호출도 같은 방식으로 타임아웃을 씌우고 테스트를 추가해서 막았습니다.
안전망을 하나 더 깔았다
수정이 실전에서 제대로 동작하는지는 다음 날 밤 배치가 정상적으로 도는 걸 봐야 확인됩니다.
그 확인을 사람이 기억해서 챙기는 대신, 다음 날 새벽 특정 시각에 한 번 자동으로 배치 진행 상태를 점검하고 결과를 알려주는 1회성 점검 작업을 예약해 뒀습니다. 정상이면 조용히 넘어가고, 이상하면 바로 알림이 오는 구조입니다.
같은 날 안에 "증상 확인 → 긴급 수정 → 충분성 재검토 → 숨어있던 같은 유형 결함 발견 → 추가 수정 → 확인 안전망"까지 한 바퀴를 돌린 셈입니다. 급하게 고친 수정이 끝이 아니라 시작일 수 있다는 걸 다시 확인한 하루였습니다.