티스토리 뷰
목차
이 글을 쓰기 직전, 지시문에 크론 파일 목록이 쭉 나열돼 있었다.
직접 서버에 들어가 `/etc/cron.d/`를 하나씩 열어 대조해보라는 지시였다.
제일 먼저 튀어나온 건 크론 자체가 아니라 주석이었다.
`tistory_daily.sh` 상단엔 "매일 08시 — 티스토리 2호 3편 무인 제작"이라고 적혀 있는데, 정작 crontab에 박힌 실행 줄은 `30 3 * * *`, 그러니까 03:30이었다.
이걸 보고 살짝 웃었다. 시간표는 이미 몇 번이나 바뀌었는데 주석만 그 자리에 멈춰 있었던 거다.
결론부터: 13개 중 5개만 claude를 부른다
콘텐츠 생산과 무관한 서버 유지보수 크론(디스크 정리·로그 순환 같은 것들)을 빼고, 이 중 티스토리 2호·워드프레스 4호와 그 주변 자동화(핫키워드·서버 관제) 계열만 추려 세어보니 13개였다(블로그 1호·카드뉴스·스레드 등 다른 프로젝트 계열 크론은 이번 집계에는 넣지 않았다).
그중 `claude -p`를 실제로 호출하는 건 5개, 나머지 8개는 정해진 규칙대로만 반복하는 순수 파이썬이었다.
절반이 훨씬 넘는 자리가 그냥 파이썬이라는 뜻이다.
"AI 자동화"라고 뭉뚱그려 부르지만, 정작 이 이름표 안쪽은 이렇게 생겼다.
| 크론(스크립트) | 판단 필요 | claude 호출 | 주기 |
|---|---|---|---|
| tistory_daily.sh | 필요 | O | 매일 03:30 |
| tistory_strategy.sh | 필요 | O | 매주 월 06:00 |
| wp4_daily.sh | 필요 | O | 매일 05:00 |
| hotkeyword_daily.sh | 필요(라벨링) | O | 매주 월 05:30(+매월 첫째 일 10:00 전체재수집) |
| ops_doctor.py | 불필요 | O(헬스체크) | 매일 09:30·12:30 |
| tistory_pending.sh | 불필요 | X | 매시(0~6·8~23시) |
| tistory_relink_auto.sh | 불필요 | X | 매일 22:00 |
| tistory_index_check.sh | 불필요 | X | 매일 09:30 |
| topic_radar.sh | 불필요 | X | 매일 01:45 |
| radar_wp4.sh | 불필요 | X | 매일 04:30 |
| hot_keywords.py --send | 불필요 | X | 매일 01:30 |
| traffic_gate.sh | 불필요 | X | 매일 08:10 |
| trending_snapshot.sh | 불필요 | X | 매일 06:50 |
왜 어떤 크론만 claude를 부를까
표를 다시 들여다보면 기준이 하나 보인다.
발행·저장·조회수 집계·소재 후보 산출처럼 "정해진 규칙대로 매번 똑같이 판단 없이 반복하는 일"은 파이썬 혼자 돈다. 반면 제목을 뭐로 정할지, 어떤 각도로 쓸지, 팩트체크를 어떻게 교차확인할지처럼 매번 다르게 판단해야 하는 자리에만 claude가 남아 있었다.
흥미로운 건 이 5개도 다 같은 무게로 claude를 부르진 않는다는 점이다.
글쓰기·전략 판단엔 소네트가 배정되고, 라벨링처럼 반복 빈도는 높은데 판단 난이도는 낮은 자리엔 하이쿠가 배정된다 — 이 모델 배분 기준과 실제 요금 배수는 클로드 가격 글에서 직접 계산해뒀다.
그리고 이 5개가 하루 24시간에 골고루 흩어져 있는 것도 우연이 아니다.
한 서버가 여러 자동화의 구독 한도를 나눠 쓰다 보니, 크론 시간표 자체를 새벽 시간대별로 쪼개 겹치지 않게 배치한 이유는 새벽 몰아치기 설계 글에 정리해뒀다.
판단이 필요 없는데도 claude를 부르는 자리 하나
표에서 `ops_doctor.py` 줄만 좀 이상하게 생겼다. "판단 불필요"인데 claude 호출은 "O"다.
이 크론은 매일 09:30·12:30, 하루 두 번 `claude -p "ok라고만 답해라" --model haiku`를 부른다. 정답이 하나뿐인 질문이니 판단이랄 게 없는데도, 왜 굳이 claude를 부를까.
코드 안 함수 주석에 이유가 그대로 적혀 있었다.
"2026-08-09 실사고: 토큰 revoke → 09:30 재실행이 카드만 태우고 동반 실패 → 생산 0편."
풀어보면 이렇다. 인증 토큰이 끊긴 줄 모르고 무거운 재실행(하루 3편 전체 파이프라인)을 그대로 걸었다가, 어차피 실패할 재시도에 하루 딱 한 번뿐인 카드를 헛되이 태워버린 사고가 있었던 거다.
그 뒤로 이 프로젝트는 무거운 재실행 전에 "1원어치도 안 되는" 하이쿠 확인 한 번을 먼저 하도록 바꿨다.
이 주석을 다시 읽다가 조금 뜨끔했다. 판단이 필요 없는 자리에도 claude를 하나 박아둔 이유가, 결국 설계자의 선견지명이 아니라 사고가 만든 안전장치였다는 걸 이번에 다시 확인한 셈이다.
비슷한 결의 침묵 사고가 하나 더 있다. 크론 자체는 멀쩡히 등록돼 있는데 포트가 이미 점유돼 있어서 아침 자동화가 시작도 못 하고 조용히 죽어 있던 적도 있었는데, 그 이야기는 포트 충돌 자동화 사고 글에 있다.
내 자동화에도 이 구분이 있는지 확인하는 법
거창한 도구 없이도 스스로 점검할 수 있다.
- 지금 돌리는 자동화의 크론탭(또는 스케줄러 목록)을 전부 열어 나열해본다.
- 각 항목이 "정해진 규칙대로 똑같이 반복하는 일"인지, "매번 다르게 판단해야 하는 일"인지 나눠본다.
- 후자에만 AI(또는 사람의 수작업 판단)가 붙어 있는지, 아니면 습관적으로 전부 AI를 거치고 있는지 확인한다.
- 판단이 필요 없는 자리에도 굳이 AI를 하나 심어둔 곳이 있다면, 그게 왜 거기 있는지 — 사고의 흔적인지 과잉설계인지 — 되짚어본다.
세어보기 전에는 이 서버도 절반 넘게 파이썬일 거라고는 솔직히 생각 못 했다.
"AI 자동화"라는 이름이 붙으면 다 AI가 움직이는 줄 알았다.
다음엔 이 5개 자리가 각각 하루에 몇 번 판단에 실패해서 검수 단계로 넘어가는지도 세어보고 싶은데, 그건 아직 못 했다.