slot 점검 배치에 재시도·자동화 인프라를 구축한 과정

slot 리소스를 주기적으로 체크하는 인프라를 첫 번째 버전으로 구축했다. 단순한 기능 추가가 아니라, 분산 환경에서 실제로 도는 시스템이 얼마나 많은 순간적 장애를 견뎌내야 하는지를 다시 한 번 생각하게 된 작업이었다.

재시도 없으면 운영은 없다

claude_cli를 수년간 쓰면서 깨달은 게 하나다. 네트워크 일시 장애나 서버의 순간적 지연 때문에 정상적인 요청도 실패하곤 한다는 것. 그런데 스케줄된 작업이 한두 번 실패하면, 그걸 복구하려면 사람이 나서야 한다. 특히 slot-checkup처럼 정기적으로 돌아야 하는 배치 작업은 "한 번 실패하면 다음 주기까지 못 본다"는 게 최악이다.

그래서 이번에는 처음부터 재시도 로직을 강화했다:

• 지수 백오프(Exponential Backoff): 첫 실패 후 점진적으로 대기 시간을 늘려서 서버 회복 시간을 확보
• 최대 재시도 횟수 설정: 무한 루프를 방지하면서도 실제 통신 실패와 일시 장애를 구분
• 타임아웃 정책: 너무 오래 기다리지 않도록 재시도당 제한 시간 설정

이건 단순한 "에러 처리"가 아니다. 팀 관점에서 보면, 배치 작업 하나가 안 돌 때마다 누군가 알림을 받고 확인해야 한다는 뜻. 재시도 강화는 그 "누군가"의 야간 호출을 1-2건 줄이는 것과 같다.

JS와 Python, 같은 로직으로 일관되게

변경 파일 목록을 보면 claude_cli.mjs와 claude_cli.py가 나란히 있다. 우린 팀 내에서 일부는 JavaScript를, 일부는 Python을 선호한다. 문제는 두 구현체가 다르게 동작하면 안 된다는 것.

slot-checkup을 작성하면서:

이런 식으로 일관성을 맞춰두면, 누군가 Python 버전만 고쳐서 배포하는 실수를 줄일 수 있다. 코드 리뷰 체크리스트에도 "양쪽 구현체 모두 수정했는가?"를 넣을 수 있고.

자동화와 가시성을 함께 구축

cron 설정(etc/cron.d/slot-checkup)이 들어간 것도 중요하다. 주기적으로 돌려야 의미 있는 모니터링인데, 수작업으로 실행하면 언젠가는 빼먹는다. 더 나아가 scripts/publish-progress.py는 실행 결과를 외부로 발행하는 역할을 한다.

이게 왜 소중한가? 운영 관점에서:

• slot-checkup이 돌았는지 안 돌았는지를 자동으로 기록
• 실패 패턴을 시간대별로 추적할 수 있음
• 대시보드나 알림 시스템과 연동 가능
• 원인 분석할 때 "언제부터 문제였는지"를 빠르게 파악

1차 인프라이니 모든 게 완벽하진 않지만, 재시도와 자동화라는 두 개의 기둥을 세우면서 "정기 작업은 네트워크 장애를 견뎌내야 한다"는 기본 원칙을 코드에 녹여낸 기분이다.

다음 단계는 이 기반 위에서 모니터링과 알림 기능을 강화하는 것. 아직 할 일이 많지만, 일단 재시도 없이 운영했던 때와 비교하면 훨씬 마음이 편하다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.