저는 수학쌤이 코딩에 도전하는 이야기를 블로그에 올리는데, 그 발행 과정을 조금씩 자동화해 두고 있어요. 그중 하나가 “매일 밤 우리 콘텐츠 상태를 한 파일로 정리해두는 작업”이었습니다. 어떤 글이 발행됐고, 예약은 어떻게 걸렸고, 소재는 뭐가 남았는지를 매일 밤 갱신해두는 거죠. 저는 이게 매일 알아서 도는 줄 알고 몇 주를 지냈어요.
그런데 어느 날 이상한 걸 발견했습니다. 분명 새 글을 공개했는데, 그 상태 파일에는 며칠 전 상태 그대로 멈춰 있던 거예요. 처음엔 “작업이 고장 났나?” 했는데, 파헤쳐 보니 더 황당했습니다. 고장이 아니라, 애초에 한 번도 돈 적이 없었어요. 초보가 자동화를 붙일 때 정말 쉽게 빠지는 함정이라 정리합니다.
증상 — 계기판이 어제에 멈춰 있었다
제 파이프라인엔 매일 갱신되는 상태 파일이 하나 있어요. 자동차로 치면 계기판이죠. 지금 몇 편이 라이브고, 뭐가 예약됐는지를 이 파일 하나만 보면 알 수 있게요. 매일 아침 받는 요약(브리핑)도 이 파일을 읽어서 만들어집니다.
문제는, 제가 새 글을 공개했는데도 이 계기판이 꿈쩍도 안 했다는 거예요. 브리핑은 여전히 며칠 전 숫자를 “오늘의 최신값”인 양 보여주고 있었고요. 계기판이 어제에 멈춰 있는데, 저는 그걸 오늘이라고 믿고 있었던 겁니다.
원인 — 스크립트는 만들었는데, 예약을 안 걸었다
파고들어 보니 원인이 명확했어요. 저는 그 갱신 작업을 돌려주는 실행 스크립트(래퍼)를 만들어 뒀습니다. 커밋도 됐고, 손으로 실행하면 멀쩡히 잘 돌았어요. 그래서 저는 “만들었으니 도는 거겠지” 하고 넘어갔던 거죠.
그런데 스크립트를 만든 것과 그걸 매일 자동으로 실행하도록 예약을 건 것은 완전히 별개의 일이었습니다. 저는 앞엣것만 하고 뒤엣것을 안 했어요. 윈도우로 치면 작업 스케줄러에 “이 스크립트를 매일 밤 10시 40분에 돌려라”라고 등록하는 단계가 통째로 빠져 있던 겁니다.
예약 작업(스케줄러 등록): 스크립트 파일이 존재하는 것과, 그 스크립트를 정해진 시각에 자동 실행하도록 운영체제에 등록하는 것은 다른 일이다. 등록을 안 하면 아무도 그 스크립트를 부르지 않는다.
그러니 그 스크립트를 실제로 실행한 건 제가 손으로 돌렸던 마지막 순간뿐이었어요. 상태 파일은 그때 시각에 딱 멈춰 버렸고요.
진짜 무서운 건 “모터 없는 계기판”이었다
이 버그가 특히 고약했던 이유가 있어요. 계기판(상태 파일)은 에러를 내지 않았거든요. 그냥 옛날 값을 그대로, 아주 자신 있게 보여줬습니다. 브리핑도 그걸 의심 없이 “최신”이라고 옮겼고요.
채점으로 치면, 학생이 답을 안 바꿨는데 저는 채점을 다시 안 하고 예전 점수를 그대로 성적표에 옮겨 적은 셈이에요. 성적표는 멀쩡해 보이지만 실은 낡은 값이죠. 계기판에 모터가 안 달려 있으면, 계기판이 멀쩡한 게 오히려 함정입니다. “빨간 에러”보다 “조용히 안 도는 것”이 훨씬 늦게 들통나거든요.
어떻게 고쳤나 — 예약을 진짜로 걸었다
고친 건 단순했어요. 빠져 있던 그 한 단계 — 스케줄러에 작업을 실제로 등록하는 것 — 을 했습니다. 윈도우 작업 스케줄러에 “이 스크립트를 매일 밤 22시 40분에 실행”으로 등록했죠. 이제야 계기판에 모터가 달린 겁니다.
여기서 배운 진짜 교훈은 하나였어요. 등록했다고 믿지 말고, 등록됐는지 확인하라. 스크립트를 만든 기억은 있는데 등록한 기억은 흐릿하다면, 십중팔구 안 한 거예요. 그래서 저는 이제 예약 작업을 걸면 반드시 정말 등록됐는지 조회해 봅니다.
- 윈도우:
schtasks /query /tn "작업이름"— 이 작업이 목록에 뜨는지 - 맥·리눅스:
crontab -l— 등록된 예약 목록에 내 줄이 있는지
만든 것과 등록된 것을 눈으로 대조하는 이 한 번이, “몇 주째 안 돌고 있었다”를 막아줍니다.
그래서 뭘 하면 되나
자동으로 돈다고 믿는 작업이 있다면, 이 표대로 점검하세요.
| 신호 | 판단 | 액션 |
|---|---|---|
| 자동 갱신 결과가 옛날에 멈춤 | 🔴 안 도는 것 의심 | 예약 등록 여부부터 조회 |
| 스크립트는 손으로 돌리면 됨 | 🟡 “존재 ≠ 등록” | 스케줄러 등록 단계 확인 |
| 계기판(상태)이 에러 없이 옛값 | 🔴 조용한 실패 | 마지막 갱신 시각을 항상 함께 본다 |
| 예약 걸었다는 기억이 흐릿 | 🟡 대개 안 한 것 | schtasks /query·crontab -l로 실물 확인 |
한 문장 요약: 스크립트를 만든 것과 스케줄러에 등록한 것은 별개다 — 자동화를 붙였으면 반드시 “정말 등록됐는지” 조회로 확인하고, 상태 파일엔 항상 마지막 갱신 시각을 함께 두어 ‘조용히 안 도는’ 실패를 눈에 보이게 하라.
돌아보면 이 사고의 본질은 코드 버그가 아니라 “했다고 믿은 일”과 “실제로 한 일” 사이의 틈이었어요. 자동화는 눈에 안 보이게 돌기 때문에, 안 도는 것도 눈에 안 보입니다. 그래서 자동으로 돌 거라 믿는 것일수록, 그게 진짜 등록됐는지 한 번은 직접 확인하는 습관이 필요하더라고요. 계기판을 믿기 전에, 모터가 달렸는지부터요.