뉴스 요약 자동화 파이프라인(extract_news.py)을 처음 만들었을 때는, 이걸 Hermes의 자체
cron 기능에 등록해서 평일 9:30/10:00에 돌아가게 해뒀다. Hermes가 이미 스케줄링
기능(cronjob)이 있으니 자연스러운 선택이었다.
”오전에 실행이 안 됐는데?”
어느 날 확인해보니 예정된 시각에 실행이 안 돼 있었다.
지금 시간이 9시반이 넘었는데, 실행이 안됐는데?
다른 세션에서 수동으로 돌려보니 정상 작동했다. 스크립트 자체는 멀쩡한데, 왜 예약된 시각엔 안 돌았을까.
실제 로그로 원인 추적
며칠 뒤 비슷한 문제가 또 발생해서 이번엔 제대로 파고들었다.
cron job이 오전에 제대로 실행되어야 할 시간에 실행이 안됐어. 그래서 다른 AI가 수동으로 실행하니 제대로 동작하네
크론잡 목록과 프로세스 상태를 확인한 결과는 이랬다.
- 시스템 부팅:
2026-06-24 23:45(이틀 전부터 켜져 있었음 — 시스템 자체는 문제없음) - Hermes 프로세스 시작:
당일 11:22 - 9:30 잡의 실제 실행:
11:15(다른 세션이 수동으로 돌린 것) - 10:00 잡의
last_run_at:null— 한 번도 실행된 적이 없음
시스템은 계속 켜져 있었는데, 9:30~10:00 그 시각에 Hermes 프로세스 자체가 떠 있지 않았다.
in-process 스케줄러의 함정
원인은 명확했다. Hermes의 cron은 in-process 스케줄러다. 리눅스 시스템 cron
(crontab)과 달리, Hermes 프로세스가 살아있는 동안에만 예약된 잡이 발화된다. Hermes가
종료되거나 세션이 닫혀 있으면, 예약 시간이 지나가도 그 잡은 그냥 조용히 skip된다 —
에러도 안 나고, 나중에 몰아서 실행되지도 않는다.
해결책은 두 가지로 나왔다.
- Hermes를 systemd 서비스로 등록해서 시스템 부팅 시 항상 켜져 있게 만들기 (가장 근본적)
- 시스템 crontab을 병행해서
python3 extract_news.py를 직접 9:30/10:00에 등록하기 — Hermes가 켜져 있든 꺼져 있든 무관하게 실행됨
실제로는 2번(시스템 crontab)으로 옮겼다. extract_news.py는 그냥 스크립트를 실행하는
거지 LLM이 판단할 일이 없는 작업이라, Hermes를 거칠 이유가 애초에 없었다.
”왜 처음부터 이 방법을 안 알려줬지?”
시스템 crontab으로 옮기고 나서 반응은 직설적이었다.
좋았어… 이게 훨씬 깔끔한데, 왜 처음부터 이 방법을 안 알려 줬지?
이 질문의 답도 그대로 남아있다.
맞아요, 처음부터 이 방법을 제안했어야 했는데요. 돌아보면
extract_news.py가 단순히 스크립트를 실행하는 거고 LLM 판단이 필요 없는 구조였으니까, 처음 크론잡 설정할 때 시스템 crontab이 더 적합하다고 짚었어야 했습니다. Hermes cron은 LLM이 판단하거나 툴을 써야 할 때 쓰는 게 맞는데, 그냥 스크립트 실행에 Hermes를 끼워 넣은 게 과했던 거죠.
일반화하면
이건 Hermes만의 특성이 아니다. AI 에이전트가 제공하는 cron/스케줄링 기능은 대체로 그 에이전트 자신의 프로세스가 떠 있을 때만 작동하는 in-process 스케줄러인 경우가 많다. “정해진 시각에 반드시 실행돼야 하는” 작업이라면, 그 작업 자체에 LLM의 판단이 필요한 게 아닌 이상 시스템 레벨 cron이나 systemd로 내리는 게 맞다. AI 에이전트의 스케줄러는 “판단이 필요한 작업”에 쓰고, “그냥 실행만 하면 되는 작업”은 시스템에 맡기는 것 — 이 구분을 처음부터 했으면 실행 안 된 걸 며칠씩 모르고 지나가는 일은 없었을 거다.