APScheduler·워치독으로 운영 자동화하기 | 토스 자동매매 개발기 #18

Phase 5까지 알림/모니터링을 실사용 검증까지 마치고 나니, 로드맵에 남은 마지막 개발 항목이 눈에 들어왔다. Phase 6, 운영 자동화였다.

문제 상황: 두 갈래로 갈리는 “자동화”

막상 “운영 자동화”를 붙잡고 보니 필요한 게 하나가 아니라 두 가지였다. 하나는 시세 스냅샷 같은 데이터 수집 스크립트를 주기적으로 자동 실행하는 것이고, 다른 하나는 auto_trader.py, bot_server.py처럼 항상 켜져 있어야 하는 스크립트를 PC 부팅 시 자동으로 띄우고 계속 살아있게 하는 것이었다. 전자는 파이썬 코드 레벨에서 풀 수 있는 문제지만, 후자는 사실상 OS(Windows) 설정 영역이라 접근 방식부터 다르게 가야 했다.

구현 1: APScheduler로 주기적 데이터 수집

scheduler.py를 새로 만들어 APScheduler의 BlockingScheduler로 시세 스냅샷 수집을 30분 간격(설정 가능)으로 반복시켰다. 기존 toss_portfolio.py의 display_portfolio()는 사람이 눈으로 보는 콘솔 테이블 출력용이라 무인 자동 실행에는 안 맞는다는 걸 깨닫고, 화면 출력 없이 DB 저장만 담당하는 collect_price_snapshots() 함수를 따로 분리했다.

인증 실패나 예상 못한 예외가 나도 스케줄러 자체는 죽지 않고 다음 주기에 다시 시도하도록 방어적으로 짰다. 실제로 1초 간격으로 짧게 돌려서 설정한 주기대로 정확히 반복 실행되는 걸 직접 확인했다.

구현 2: 워치독으로 프로세스 자동 재시작

watchdog.py는 상시 실행 스크립트가 네트워크 오류 누적이나 예상 못한 문제로 죽었을 때 자동으로 다시 띄워주는 역할이다. 여기서 가장 신경 쓴 부분은 정상 종료(exit code 0)는 재시작하지 않는다는 원칙이었다. auto_trader.py가 모든 종목 매수를 끝내고 스스로 종료한 경우까지 억지로 재시작해버리면 오히려 사고가 날 수 있기 때문이다.

일부러 실패하도록 만든 더미 스크립트를 반복 실행시켜서 재시작 횟수, 최대 재시작 한도, 정상 종료 시 미재시작까지 실제 동작으로 검증했다. 재시작이 일어나도 config.py는 매번 새로 읽으므로 DRY_RUN이나 목표가 같은 3중 안전장치 값은 항상 원래 설정 그대로 유지된다.

Docker 컨테이너화는 의도적으로 보류

지금은 Windows 개인 PC + Google Drive 동기화 폴더로 운영 중인데, 이 환경에서 Docker를 도입하면 오히려 복잡도만 늘어난다고 판단했다. 나중에 클라우드 서버로 옮기게 되면 그때 다시 검토하기로 로드맵에 남겨뒀다.

문서화: 배포/운영 체크리스트

그동안 머릿속과 여기저기 흩어져 있던 실무 지식을 배포_운영_체크리스트.md 한 문서로 정리했다. 스크립트별 실행 방식 표, 워치독 사용법, Windows 작업 스케줄러로 부팅 시 자동 시작 등록하는 절차, 자동화 적용 전 반드시 안전장치 테스트를 통과해야 한다는 점검 절차, 웹 대시보드·텔레그램 봇·로그 파일을 활용한 운영 모니터링 방법까지 담았다.

Phase 6에서는 APScheduler로 시세 수집 주기 실행을, 워치독 스크립트로 상시 실행 프로세스의 자동 재시작을 구현했다. 정상 종료 시 재시작하지 않는 원칙을 지키고, 재시작 후에도 3중 안전장치 값이 유지되는지를 실제 테스트로 검증했다.

결과

전체 pytest를 다시 돌려 118개 전부 통과했다(기존 109개 + 신규 9개). 안전장치 값이 바뀌지 않았음을 확인했고, 로컬 실행 환경과 프로젝트 저장소 양쪽 반영·동기화까지 마쳤다. 이걸로 Phase 0부터 Phase 6까지 로드맵상의 개발 단계가 전부 완료됐다.

FAQ

Q1. APScheduler와 Windows 작업 스케줄러 중 어떤 걸 써야 하나요?

파이썬 코드 안에서 주기 실행 로직을 관리하고 싶다면 APScheduler가 편하고, OS 부팅 시 자동 시작처럼 코드 밖의 실행 자체를 제어해야 한다면 Windows 작업 스케줄러가 필요하다. 이번 Phase 6에서는 둘을 용도에 맞게 나눠서 함께 썼다.

Q2. 워치독이 무한 재시작을 반복하면 어떻게 하나요?

최대 재시작 한도를 두고, 한도를 넘으면 재시작을 멈추고 알림만 보내도록 설계했다. 무한 재시작은 근본 원인을 숨기고 리소스만 소모시키기 때문에 반드시 상한선이 필요하다.

Q3. Docker는 왜 이번에 적용하지 않았나요?

현재 운영 환경(Windows 개인 PC + Google Drive 동기화)에서는 Docker가 오히려 복잡도를 늘린다고 판단해서 보류했다. 클라우드 서버로 옮길 때 재검토할 예정이다.

Q4. 다음 단계는 무엇인가요?

로드맵상 마지막 단계인 Phase 7(실전 전환 준비)이 남아있다. 이 단계는 사용자의 명시적 승인 없이는 진행하지 않는 가장 신중한 단계로 남겨뒀다.