Hermes Agent의 cron 스케줄러는 에이전트가 하는 일의 세 번째 모양이다 — 턴 단위 채팅과 /goal 루프 다음으로. cron에선 에이전트가 스케줄에 따라 무인으로 돈다. 결과는 네가 정한 메시징 플랫폼으로 배달된다 — 혹은 deliver=all로 연결된 전체에 한 번에(#21495).
이 글에선 구체적인 잡 하나 — 아침 일일 리포트 — 를 짜고, 그걸로 스케줄러 작동 방식을 설명한다. 같은 패턴이 야간 백업, 주간 보안 감사, 온콜 교대 알림, 혹은 네가 예전에 깨지기 쉬운 bash + cron으로 짰던 어떤 잡이든 다 처리한다.
만들 것
매 평일 아침 8시에:
- 1.밤사이 온 이메일 읽기 (어제 오후 5시 이후)
- 2.github skill로 GitHub 알림 가져오기 (이슈, PR 리뷰, 멘션)
- 3.google-calendar로 오늘의 첫 4시간 캘린더 확인
- 4.세 가지를 묶어서 Telegram 메시지 한 통으로
중요한 일이 있었으면 자세히. 아무 일도 없었으면 한 줄로: "밤은 조용했음. 11시까지는 캘린더 한산."
1단계: 잡 정의
hermes cron add가 안내한다. CLI가 묻는 것: 이름, 스케줄, 잡 설명(자연어), 배달 타깃.
$ hermes cron add
Name: daily-morning-report
Schedule (cron expression or natural language): 0 8 * * MON-FRI
Description: |
Read overnight email (since 5 PM yesterday).
Pull GitHub notifications via the github skill.
Check today's calendar via google-calendar for the first 4 hours.
Summarize all three into one Telegram message.
Be brief when nothing important happened.
Delivery: telegram
0 8 <em class="italic text-slate-200"> </em> MON-FRI는 표준 cron 문법이다: 분 0, 시 8, 매일, 매월, 월요일부터 금요일까지. Hermes는 cron 문법과 "every weekday at 8 AM" 같은 느슨한 자연어 표현 둘 다 받는다.
2단계: 아침 8시에 무엇이 도는가
다음 평일 아침 8시, Hermes는 격리된 에이전트 세션을 띄운다. 안에 든 것:
- •잡 설명을 시작 사용자 메시지로
- •에이전트가 호출할 skill (
email,github,google-calendar) - •최종 응답을 Telegram으로 흘려보내는 delivery hook
영구 컨텍스트도, 사용자 타이핑도 없다. 에이전트가 설명을 읽고, skill을 호출하고, 메시지를 초안잡고, 보낸다. 보통 15–30초.
출력은 네 Hermes bot이 Telegram에서 보내는 메시지로 나온다. 평소보다 오래 걸렸거나 에러를 만났으면, 같은 채널로 에러 메시지도 받게 된다.
3단계: deliver=all — 전 플랫폼으로 퍼뜨리기
기본적으로 배달은 한 플랫폼으로 간다 — cron add에서 지정한 그것. 리포트가 네가 닿을 수 있는 모든 곳에 도착하게 하고 싶으면:
hermes cron edit daily-morning-report --deliver all
이제 메시지는 연결된 모든 메시징 플랫폼 — Telegram, Discord, Slack, WhatsApp, Signal, LINE, SimpleX, 네가 구성한 어느 거든 — 으로 한 번에 간다. v0.14.0이 cron용 플랫폼별 배달을 명시적으로 배선했다(#21495).
이게 쓸모 있는 경우: 그 메시지를 어느 앱에 있든 반드시 보고 싶을 때.
오버킬인 경우: 아침엔 한 플랫폼만 본다. 그러면 그 하나만 골라라.
4단계: 무엇이 스케줄돼 있는지 보기
hermes cron list
스케줄된 전부, 다음 실행 시각, 직전 실행 상태를 보여준다. v0.14.0이 잡 동작에 이름 기반 조회를 추가해서(#26231), 잡을 ID 대신 이름으로 가리킬 수 있다:
hermes cron logs daily-morning-report --last 5
hermes cron disable daily-morning-report
hermes cron run-now daily-morning-report # 스케줄 외에서 즉시 발동
잡이 실패할 때
cron 잡은 자기 샌드박스 세션에서 돈다 (백엔드는 대화형 Hermes와 같은 세트 — 샌드박스 백엔드 글 참고). skill 호출이 실패하면, 에이전트가 에러를 받고 재시도하거나 그대로 보고한다.
잡 전체가 무너지면(에이전트 자체가 에러로 종료), Hermes가 네 기본 메시징 플랫폼으로 에러와 로그 링크를 보낸다. v0.13.0의 세션 영속성 작업 덕에 게이트웨이 재시작이 보류 중인 cron 배달을 잃지 않는다 — 중복 제거는 원자적 claim + 실패 시 되감기로 처리된다(#23401).
실제로 굴리고 있는 잡 패턴
이건 진짜로 사람들이 굴리는 패턴들:
야간 백업 검증. 새벽 3시 cron: 백업 스냅샷 나열, 오늘 자가 존재하고 비어 있지 않은지 확인, 없으면 큰 소리로 실패. deliver=all을 붙여놓으면 문제가 있을 때 일어나자마자 알게 된다.
주간 보안 감사. 일요일 밤 10시 cron: 의존성 권고를 끌어오고, lockfile에서 알려진 CVE를 스캔하고, 새로 생긴 취약점을 요약한다. v0.14.0의 supply-chain advisory 체커(#24220)가 자체 스크립트보다 깔끔하게 받쳐준다.
온콜 교대. 금요일 오후 5시 cron: 이번 주 페이지를 읽고, 다음 주 온콜한테 한 문단짜리 인수인계를 적는다. 공유 Slack 채널로 배달.
Watchers (v0.14.0의 skill, #21881). RSS 피드, HTTP JSON 엔드포인트, GitHub 리포지토리의 변경을 폴링하고, 변했을 때만 알린다. cron과 묶으면 "X가 변하면 알려줘"가 되는데, 가장 저평가된 자동화 프리미티브 중 하나다.
로그는 어디로
hermes cron logs daily-morning-report
기본으로 최근 10회. 각 실행마다: 타임스탬프, 소요 시간, 호출한 skill, 배달한 것, 실패가 있었다면 무엇이. 로그는 ~/.hermes/cron/logs/ 아래에 살고, 자동으로 회전된다.
왜 shell 스크립트보다 나은가
같은 일일 리포트를 bash 스크립트 + cron + Telegram으로 curl + 어쩌면 작은 LLM 호출 하나로 짤 수 있다. 많은 사람이 그렇게 해왔다.
에이전트 위의 cron이 흥미로운 이유:
- 1.잡 설명 자체가 스펙이다. 유지보수할 코드가 없다. "첫 4시간"을 "첫 6시간"으로 바꾸려면 설명을 고치면 된다, 재배포 없이.
- 2.skill이 조립된다. "Linear에서 새 티켓도 같이 확인해줘"를 더하는 게 설명에 한 문장이다. shell 스크립트면 새 API 클라이언트가 된다.
- 3.배달이 분리돼 있다.
deliver=all덕에 5개 채팅 앱용으로 5개의 다른 webhook을 짤 필요가 없다. 게이트웨이는 이미 22개 플랫폼을 말한다. - 4.에러가 디버그 가능하다. 잡이 실패하면, 에이전트가 자기가 뭘 시도했고 왜 실패했는지를 사람 말로 알려준다. bash 스크립트는 exit code 1을 준다.
이건 에이전트-cron이 늘 정답이란 뜻은 아니다 — 100% 결정적이고 30 ms 안에 끝나야 하는 잡엔 shell 스크립트가 여전히 낫다. 그런데 "이 시간에 머리를 좀 쓴 일을 하고 결과를 알려줘" 같은 잡엔 cron-on-Hermes가 도구함에서 가장 깔끔한 손잡이다.