백그라운드 무인 스케줄러 제어 불능 사태와 태스크 종료 실전 가이드

블로그 자동화 파이프라인을 구축하면서 가장 달콤했던 유혹은 '스케줄러'의 도입이었습니다. 파이썬의 schedule이나 운영체제의 크론(Cron) 작업을 활용하면, 컴퓨터가 켜져 있는 동안 매일 정해진 시간에 자동으로 포스팅을 발행할 수 있기 때문입니다.

통제 불능에 빠진 터미널 화면

하지만 안전 장치 없이 구동된 백그라운드 무인 스케줄러는 순식간에 통제 불능의 좀비 프로세스로 돌변할 위험을 안고 있었습니다. 이번 글에서는 제가 겪었던 스케줄러 폭주 사태와, 이를 수습하기 위한 백그라운드 태스크 관리 및 프로세스 강제 종료(Kill) 경험을 기록합니다.

통제 불능에 빠진 백그라운드 스케줄러

처음 스케줄러 코드를 작성할 때, 단순히 while True 루프 안에서 특정 시간이 되면 스크립트가 실행되도록 설정했습니다. 스크립트가 정상적으로 끝날 것이라는 안일한 전제하에 백그라운드 데몬(Daemon) 모드로 실행을 걸어둔 것입니다.

문제는 자동화 스크립트 내부의 셀레니움(Selenium)이 특정 웹페이지 버튼을 찾지 못해 무한 대기 상태에 빠지면서 시작되었습니다.

일반적인 터미널 실행이었다면 Ctrl+C를 눌러 스크립트를 즉시 정지시켰겠지만, 백그라운드로 돌아가는 스케줄러는 화면에 보이지 않았습니다. 스케줄러는 앞선 작업이 끝나지 않았음에도 다음 주기가 되자 새로운 자동화 스크립트를 중복해서 실행하기 시작했습니다.

결국 메모리 사용량이 급증하고 파이썬 프로세스가 수십 개씩 쌓이면서 전체 시스템이 멈추기 직전의 상황까지 치달았습니다.

화면에 보이지 않는 프로세스 추적하기

사태를 파악했을 때는 이미 시스템 리소스가 한계에 달한 상태였습니다. 가장 먼저 해야 할 일은 백그라운드에서 폭주하고 있는 파이썬 스케줄러와 셀레니움 프로세스들을 찾아내 완전히 종료시키는 것이었습니다.

윈도우 환경이었기 때문에 터미널을 열고 다음 명령어들을 사용해 문제의 프로세스들을 추적했습니다.

1. 실행 중인 파이썬 프로세스 목록 확인

Get-Process | Where-Object { $_.ProcessName -match "python" -or $_.ProcessName -match "chrome" }

이 명령어를 통해 정상적인 브라우저 외에, 백그라운드에서 메모리를 잡아먹고 있는 수많은 크롬 드라이버와 파이썬 실행 파일(PID)들의 목록을 확인할 수 있었습니다.

2. 문제가 된 태스크(Task) 강제 종료

프로세스 아이디(PID)를 하나씩 종료하는 것은 너무 느렸기 때문에, Stop-Process 혹은 taskkill 명령어를 통해 백그라운드에서 실행 중인 자동화 관련 프로세스를 일괄적으로 종료(Kill)했습니다.

taskkill /F /IM python.exe /T
taskkill /F /IM chromedriver.exe /T
taskkill /F /IM chrome.exe /T

프로세스 강제 종료 성공 화면

명령어가 실행되자 폭주하던 시스템 리소스가 정상으로 돌아왔습니다. 화면에 보이지 않는 백그라운드 프로세스의 무서움을 뼈저리게 느끼는 순간이었습니다.

스케줄러 폭주 사태 이후 도입한 원칙

이 경험을 통해 백그라운드 스케줄러는 '완벽하게 검증된 로직' 위에서만 돌아가야 한다는 교훈을 얻었습니다. 이후 자동화 파이프라인에는 다음과 같은 필수 규칙이 추가되었습니다.

1. 자동 스케줄러 기본 비활성화: 이제 스케줄러는 기본적으로 작동하지 않도록 잠가두었습니다. 충분한 dry-run(모의 실행) 테스트를 거치고 완벽히 검증된 작업만 수동 혹은 제한된 조건 하에서 실행합니다.
2. 타임아웃(Timeout) 강제 설정: 셀레니움 대기나 외부 API 호출 시, 무한정 기다리는 일이 없도록 최대 대기 시간(Timeout)을 엄격하게 적용했습니다. 지정된 시간이 넘으면 예외(Exception)를 발생시키고 즉시 스크립트를 중단합니다.
3. 중복 실행 방지 락(Lock) 파일 도입: 이전 작업이 아직 실행 중이라면 스케줄러가 새로운 작업을 시작하지 못하도록, 실행 시작 시 임시 파일을 생성하고 종료 시 삭제하는 락(Lock) 구조를 구성했습니다.

결론

백그라운드 스케줄러는 자동화의 훌륭한 도구지만, 예기치 않은 오류 앞에서는 브레이크가 고장 난 자동차와 같습니다.

보이지 않는 곳에서 실행되는 코드일수록 타임아웃, 예외 처리, 그리고 프로세스 강제 종료에 대한 철저한 대비가 선행되어야 함을 배울 수 있었습니다. 현재는 모든 자동화 코드가 안전장치를 거친 후에만 작동하도록 파이프라인을 완전히 개편하여 안정적으로 블로그를 운영하고 있습니다.