중복 파일 삭제 스크립트를 돌렸다가 식은땀 흘린 날
이 블로그의 스케줄러 편과 텔레그램 자동 발송 편을 각각 소개했었는데, 사실 이 둘을 실제로 연결해서 "매일 아침 9시에 날씨와 환율을 텔레그램으로 받는" 시스템을 만들 때는 생각보다 여러 번 헛발질을 했습니다. 이번 글에서는 그 과정을 그대로 공유합니다.
목표는 단순했습니다. 매일 아침 출근 전에 오늘 날씨와 환율을 텔레그램으로 자동으로 받는 것. 코드 자체는 기존에 소개한 두 게시글을 합치기만 하면 될 것 같았는데, 실제로는 세 번의 실패를 거쳤습니다.
처음에는 schedule 라이브러리로 단순하게 만들었습니다.
import schedule
import time
def send_morning_briefing():
# 날씨 API 호출 + 텔레그램 발송 코드
pass
schedule.every().day.at("09:00").do(send_morning_briefing)
while True:
schedule.run_pending()
time.sleep(30)
터미널을 켜둔 채로 테스트했을 때는 정확히 9시에 알림이 왔습니다. 그런데 다음 날 아침, 알림이 오지 않았습니다.
무엇이 잘못됐나: 전날 밤에 노트북 뚜껑을 덮고 퇴근했는데, 절전 모드로 들어가면서 파이썬 스크립트도 함께 멈췄던 것입니다. schedule 라이브러리는 PC가 켜져서 스크립트가 실제로 돌아가고 있는 동안에만 동작한다는 당연한 사실을, 실제로 겪고 나서야 체감했습니다.
❌ 실패 원인: "코드가 정확하면 당연히 실행되겠지"라고 생각했지, "실행 환경(PC 전원 상태)까지 자동화의 일부"라는 것을 고려하지 않았습니다.
PC가 꺼져 있어도 동작하도록 윈도우 작업 스케줄러에 등록하는 방식으로 바꿨습니다. 그런데 다음 날 아침 텔레그램을 열어보니 같은 알림이 5번 연달아 와 있었습니다.
무엇이 잘못됐나: 원인을 찾아보니, 예전에 테스트하면서 등록해뒀던 작업 스케줄러 항목이 지워지지 않고 남아 있었고, 그 위에 새 항목을 또 등록하면서 같은 작업이 여러 개 중복 등록되어 있었습니다. 심지어 이름을 조금씩 바꿔가며 테스트했던 탓에 작업 스케줄러 목록에 비슷한 이름의 작업이 5개나 쌓여 있었습니다.
schtasks /query /fo LIST | findstr "아침브리핑" → 결과: "아침브리핑", "아침브리핑_v2", "아침브리핑_테스트", "아침브리핑_final", "아침브리핑_진짜최종" 5개가 전부 매일 9시에 실행되도록 등록되어 있었음
❌ 실패 원인: 테스트하면서 만든 임시 작업들을 정리하지 않고 그대로 방치했습니다. 자동화는 "새로 만드는 것"보다 "기존에 등록한 걸 확인하고 정리하는 것"이 의외로 더 중요하다는 것을 이때 깨달았습니다.
중복 작업을 모두 지우고 하나만 남겼더니 알림은 정확히 한 번씩 왔습니다. 그런데 며칠 지켜보니, 가끔 텔레그램 메시지에 날씨 정보가 빠지고 환율 정보만 오는 날이 있었습니다.
무엇이 잘못됐나: 날씨 API 서버가 일시적으로 응답하지 않거나 타임아웃되는 경우가 가끔 있었는데, 코드에서 이 실패를 except: pass로 조용히 무시하고 넘어가도록 짜여 있었습니다. 즉, 실패해도 아무 표시 없이 그냥 넘어가서 내가 직접 알아채기 전까지는 문제가 있는지도 몰랐습니다.
# 문제가 있던 코드
try:
weather = get_weather_data()
except:
pass # ← 여기가 문제. 실패해도 아무 로그도 안 남음
# 개선한 코드
try:
weather = get_weather_data()
except Exception as e:
weather = "날씨 정보 조회 실패"
send_message(f"⚠️ 날씨 API 오류 발생: {e}") # 실패 자체를 알림으로 받음
❌ 실패 원인: 오류를 "일단 넘어가게" 처리하면 당장은 스크립트가 안 멈추지만, 정작 무엇이 잘못되고 있는지 알 방법이 없어집니다. "실패했을 때 조용히 넘어가는 것"과 "실패했을 때 실패했다고 알려주는 것"은 완전히 다른 설계입니다.
1. PC 전원 상태까지 고려해서 스케줄링 방식을 선택한다 → schedule 라이브러리는 개발·테스트용, 실무 운영은 윈도우 작업 스케줄러 → 스케줄러 완전 정복 편에서 두 방식을 나눠 설명한 이유가 이것입니다. 2. 작업 스케줄러에 새 작업을 등록하기 전, 기존 작업을 먼저 확인한다 → schtasks /query 로 중복 등록 여부를 항상 먼저 확인하는 습관이 생겼습니다. 3. 오류는 절대 조용히 넘기지 않는다 → 실패해도 알림이 오게 만들어야, 실패했다는 사실 자체를 알 수 있습니다. → 이 원칙이 지금 이 블로그의 거의 모든 완성 코드에 있는 "✔ 성공 / ✘ 실패" 로그 출력으로 이어졌습니다.
날씨와 환율을 텔레그램으로 받는 것 자체는 코드 몇 줄이면 끝나는 간단한 작업처럼 보였습니다. 하지만 실제로 "매일 안정적으로" 돌아가게 만드는 것은 완전히 다른 문제였습니다. 코드가 논리적으로 맞는 것과, 그 코드가 매일 사람 없이도 문제없이 실행되는 것은 별개의 영역이라는 걸 이 과정에서 배웠습니다.
특히 "실패했을 때 어떻게 될까"를 미리 생각하지 않으면, 문제가 생겨도 한동안 모르고 지나가게 됩니다. 알림을 못 받은 첫날은 그냥 넘어갔지만, 만약 이게 업무에 중요한 자동화였다면 훨씬 큰 문제로 이어질 수 있었을 것입니다.
💡 지금 비슷한 걸 만들고 계시다면: 스케줄러 완전 정복 편과 텔레그램 자동 발송 편은 이 시행착오를 반영해서 처음부터 안정적인 형태로 정리해둔 글입니다. 두 글을 그대로 조합하시면 같은 실패를 반복하지 않을 수 있습니다.