arrow_back Back to Blog
Post 2026년 5월 15일
hermesai-agentworkflowcron

hero

LLM 에이전트는 보통 "내가 부르면 그때 일한다." Hermes Cron은 그 전제를 뒤집는다. 사용자가 부르지 않아도, 정해진 시각에 에이전트가 스스로 깨어나서 일하고, 결과만 전달한다. 매일 아침 메일 요약, 두 시간마다 도는 PKM 정리, 하루 한 번의 블로그 발행처럼 "사람이 매번 시작하지 않아도 되는 일"을 에이전트의 손에 맡기는 기능이다.

기능 개요

Hermes Cron은 Hermes Agent에 내장된 스케줄러로, 다음 세 가지를 묶어 하나의 "작업(job)"으로 만든다.

  • 스케줄(schedule) — 30m, every 2h 같은 간격 표기, 혹은 표준 cron 표현(0 9 *).
  • 프롬프트 또는 스크립트 — 매 실행마다 에이전트에게 줄 지시, 또는 셸/파이썬 스크립트.
  • 전달 대상(deliver) — origin, local, telegram, discord, signal, 혹은 platform:chat_id 형태의 채팅 대상.

여기에 선택적으로 skill을 연결할 수 있다. Skill을 붙이면 그 작업이 깨어났을 때 해당 절차 문서(SKILL.md)가 자동으로 로드되어, 모델이 매번 같은 규칙·스크립트·체크리스트를 따르게 된다. 즉 cron은 "시간"을, skill은 "절차"를 담당한다.

작업 상태는 active 또는 paused로 관리되고, 각 작업은 마지막 실행 시각·결과(ok/error)·다음 실행 시각을 기록한다.

사용법

핵심 명령은 모두 hermes cron 하위에 있다.

hermes cron list                 # 등록된 작업 목록
hermes cron status               # 스케줄러 데몬이 살아있는지 확인
hermes cron create <schedule> ["prompt"] [옵션]
hermes cron edit <id>            # 스케줄/프롬프트 수정
hermes cron pause <id>           # 일시 중지
hermes cron resume <id>          # 재개
hermes cron run <id>             # 다음 tick에 즉시 1회 실행
hermes cron remove <id>          # 삭제
hermes cron tick                 # 데몬 없이 due 작업 1회만 실행

가장 기본적인 형태는 자연어 프롬프트를 그대로 넣는 것이다.

hermes cron create "0 7 * * *" \
  --name "morning-brief" \
  --deliver telegram \
  "Gmail 받은편지함 최근 24시간 메일을 요약하고 답장이 필요한 항목만 정리해라."

매일 아침 7시에 에이전트가 깨어나서 메일을 읽고, 결과를 Telegram으로 보낸다. 별도의 코드 작성 없이 자연어 작업 지시만으로 반복 업무가 만들어진다.

Skill을 결합하기

같은 절차를 여러 번 돌릴 때는 프롬프트에 모든 규칙을 다시 적기보다, skill로 분리해두는 편이 깔끔하다.

hermes cron create "30 7 * * *" \
  --name "hermes-blog-publish-0730" \
  --skill obsidian \
  --skill dexa-blog-publish \
  --deliver local \
  "오늘자 Hermes 시리즈 글 한 편을 발행해라."

작업이 깨어나면 Hermes는 연결된 skill의 SKILL.md를 먼저 읽고, 거기 정의된 워크플로(소스 노트 위치, 프론트매터 규칙, 빌드/퍼블리시 스크립트 경로 등)에 따라 움직인다. 같은 토픽으로 다른 시간대를 추가해도 절차는 한 곳에서 유지된다.

스크립트로 가는 두 가지 길

--script 옵션은 두 가지 모드를 가진다.

  • 기본 모드: 스크립트의 stdout이 에이전트 프롬프트에 주입된다. "환경 정보를 모아서 LLM에게 판단하게 시키고 싶을 때" 쓴다.
  • --no-agent 모드: LLM을 거치지 않는다. 스크립트의 stdout이 그대로 deliver 대상으로 전달된다. 메모리/디스크 경보, CI 핑처럼 결정적 출력만 필요한 와치독에 적합하다.
# LLM 없이 디스크 사용량 알림
hermes cron create "0 */6 * * *" \
  --name "disk-alert" \
  --script disk_check.sh \
  --no-agent \
  --deliver telegram

.sh/.bash는 bash로, 그 외는 Python으로 실행된다. 스크립트는 ~/.hermes/scripts/ 아래에 둔다.

Workdir과 컨텍스트 주입

--workdir로 특정 폴더를 지정하면, 해당 디렉토리의 AGENTS.md, CLAUDE.md, .cursorrules 같은 컨텍스트 파일이 자동으로 주입되고, 터미널/파일/코드 실행도 그 폴더 기준으로 동작한다. 프로젝트 단위 자동화를 만들 때 유용하다.

실제 운영 사이드바

이 환경에서는 hermes cron list에 PKM 볼트 정리(2시간 간격), 공식 문서 라디아 점검(30분 간격), 일일 메일 브리핑, 그리고 두 종류의 일일 블로그 발행 작업이 함께 돌고 있다. 각각의 작업은 서로 다른 skill 묶음(obsidian, dexa-blog-publish, telegram-multi-bot-topic-governance 등)에 매여 있어서, 동일한 cron 인프라 위에 PKM·발행·운영 자동화가 한꺼번에 얹혀 있는 형태다. "시간은 cron, 절차는 skill, 의사결정은 LLM"이라는 분업이 그대로 드러난다.

주의할 점

  • delivery는 디버그 통로가 아니다. --deliver telegram을 붙이면 매 실행마다 채팅에 결과가 쌓인다. 보고할 게 없는 작업은 --deliver local로 두고 로컬 로그만 남기는 편이 낫다. 시스템 프롬프트에서 "보고할 게 없으면 [SILENT]만 출력" 같은 규약을 함께 쓰면 알림 노이즈가 크게 줄어든다.
  • 인증이 만료된 프로바이더는 조용히 실패한다. 이미지·음성처럼 외부 인증이 걸린 자원을 쓰는 cron은 토큰이 만료되면 깔끔히 빈 결과를 내고 last_status: ok로 끝나는 경우가 있다. cron 실행 전에 hermes auth list로 만료 상태를 한 번 훑어두는 readiness 점검이 안전하다.
  • hermes cron status로 데몬을 확인한다. macOS에서 절전·재로그인 이후 스케줄러가 죽어 있을 수 있다. tick 서브커맨드는 데몬 없이 due 작업을 한 번 실행해주므로 트러블슈팅에 쓴다.
  • --skill은 신중하게 늘려라. Skill을 많이 붙이면 그 모든 절차 문서가 매 실행마다 컨텍스트에 들어간다. 정말 필요한 skill만 연결하고, 나머지는 본문 프롬프트에서 요점만 지시하는 편이 토큰 측면에서 효율적이다.

언제 cron을 선택할 것인가

수동으로 한 번만 시키면 되는 일은 그냥 채팅으로 지시하면 된다. 그러나 "매일 아침 같은 시각, 같은 절차로, 같은 종류의 결과"가 필요해지는 순간 — 메일 브리핑, 데일리 리포트, 정기 백업 점검, 일정 발행 — Hermes Cron이 답이다. 반복은 사람이 가장 못하는 일이고, 에이전트가 가장 잘하는 일이다. cron은 그 둘 사이의 합의서다.