
매일 아침마다 정체불명의 네트워크 오류로 죽어버리는 내 봇, 해결 방법은?
요약
매일 아침 발생하는 네트워크 오류로 인해 중단되는 봇 문제를 해결하기 위해, 애플리케이션 코드 수정 대신 Windows 작업 스케줄러의 내장 기능을 활용하는 방법을 소개합니다.
핵심 포인트
- 네트워크 오류로 인한 봇 중단 문제를 OS 계층에서 해결 가능
- 코드 내 재시도 로직 구현 대신 Windows 작업 스케줄러 설정 활용
- 작업 실패 시 특정 간격으로 자동 재시작하도록 설정 가능
- 환경 의존적인 오류를 애플리케이션 수정 없이 우아하게 처리
안녕하세요 여러분, 여러분의 친절한 동네 개발 선배입니다.
저는 집에서 사용하는 개발용 PC에서 몇 개의 봇을 24시간 내내 실행하고 있는데, 그중 하나가 아주 미묘하게 짜증 나는 습관을 갖게 되었습니다. 바로 매일 아침 똑같은 시간에 어김없이 죽어버리는 것이었습니다.
에러 로그는 항상 네트워크 관련 예외(exceptions)를 가리켰습니다. requests.exceptions.ConnectionError와 그 친구들 같은 것들이죠. 기본적으로, API를 호출하려고 시도하는 순간
전형적인 타이밍 이슈(timing issue)였습니다. 이런 종류의 일시적이고 환경에 의존적인 오류는 디버깅하기가 믿을 수 없을 정도로 진을 빼놓습니다. 코드 내 진단 도구(in-code diagnostics)를 사용하여 이를 디버깅하려고 하면 종종 헛수고만 하게 되기 때문입니다.
해결책: 코드 한 줄 건드리지 않고 OS 기능을 사용하여 해결하기
이 문제에 접근하는 데는 두 가지 주요 방법이 있었습니다:
- 애플리케이션 계층(application layer)에서 해결: Python 스크립트 내에 재시도 로직(retry logic)을 구현합니다.
try-except블록을 추가하여 네트워크 오류를 포착한 다음, 재시도하기 전에time.sleep(60)과 같은 로직을 포함합니다. - 실행 환경(OS) 계층에서 해결: 스크립트를 실행 중인 메커니즘을 사용하여 재시도를 우아하게 처리합니다.
대부분의 사람들은 아마 (1)번을 선택하겠지만, 저는 이번에 (2)번을 선택했습니다.
왜일까요? 이 "시작 직후의 네트워크 불안정성"은 단지 이 특정 스크립트만의 문제가 아니기 때문입니다. 만약 같은 시간에 실행되는 다른 봇을 만든다면, 그 봇 역시 동일한 문제에 직면할 가능성이 매우 높습니다. 근본 원인은 애플리케이션에 있는 것이 아니라, 실행 환경의 특성에 있습니다. 따라서 환경이 이를 처리하도록 하는 것이 더 합리적이었습니다.
그리고 제가 사용한 도구는 Windows 작업 스케줄러(Windows Task Scheduler)의 매우 유용한 내장 기능이었습니다.
작업 속성(task properties)을 열고 "설정(Settings)" 탭으로 이동하면 다음과 같은 옵션을 찾을 수 있습니다:
"작업이 실패하는 경우, 다음 간격으로 다시 시작(If the task fails, restart every):"
바로 이것이었습니다.
저는 간격을 "10분"으로, "다시 시작 시도(Attempts to restart):"를 "2회"로 설정했습니다.
이제 어떤 이유로든 작업이 비정상적으로 종료되면(종료 코드가 0이 아닌 경우), 작업 스케줄러가 이를 감지하고 10분 후에 작업을 자동으로 다시 시작합니다.
다음은 이러한 설정이 포함된 내보낸 XML의 발췌본입니다:
<!-- 작업 스케줄러 설정 XML 발췌본 (재시도 설정) -->
<Settings>
<RestartOnFailure>
...
PT10M은 ISO 8601 형식으로, "Period, Time, 10 Minutes" 즉, 10분 간격을 의미합니다.
이 설정을 적용한 이후로, 제 봇은 아침에 단 한 번도 죽지 않았습니다. 로그를 보면 오전 7시에 실패 기록이 남아있지만, 작업이 10분 뒤인 오전 7시 10분에 재시작되어 아무 일도 없었다는 듯이 프로세스를 정상적으로 완료했습니다. 아마도 네트워크가 완전히 준비된 후에야 다시 실행된 것으로 추측됩니다.
교훈: 애플리케이션과 실행 환경 계층(Execution Environment Layers)을 구분하라
이번 경험을 통해 얻은 교훈은 다음과 같습니다: 애플리케이션의 코드 내부에서 모든 것을 해결하려고 하지 마세요.
물론 API의 일시적인 503 오류처럼 애플리케이션이 직접 처리해야 하는 오류들도 있습니다. 하지만 이번 사례와 같이 환경에 따라 발생하는 일시적인(transient) 오류를 위해 코드 안에 재시도 로직(retry logic)을 억지로 집어넣다 보면, 코드는 금세 과도하게 복잡해집니다:
- 스크립트의 단순성이 사라집니다.
- 이제 재시도 로직 자체를 테스트해야 합니다.
- 결국 동일한 로직을 다른 스크립트에 복사하여 붙여넣게 되어 유지보수성(maintainability)을 해치게 됩니다.
OS나 Docker, Kubernetes와 같은 실행 플랫폼(execution platforms)에서 제공하는 기능(헬스 체크(health checks) 및 재시작 정책(restart policies) 등)을 활용하면, 애플리케이션은 핵심 로직에만 집중할 수 있습니다. 이번 경우에는 Windows 작업 스케줄러(Windows Task Scheduler)가 그 역할을 완벽하게 수행했습니다.
코드 한 줄 바꾸지 않고, 단 몇 번의 마우스 클릭만으로 제 봇의 안정성은 극적으로 향상되었습니다. 이 해결책의 가성비는 정말 엄청납니다.
만약 여러분도 "PC 부팅 직후 발생하는 정체불명의 오류"로 고통받고 있다면, 스크립트 코드를 깊게 파고들기 전에 작업 스케줄러 설정을 먼저 확인해 보시길 강력히 추천합니다.
다음에 또 만나요!
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기