9. 자동화와 스케줄링: cron으로 반복 업무 맡기기

Hermes를 잘 쓰는 사람과 오래 쓰는 사람의 차이는 아주 단순한 곳에서 갈립니다. 바로 반복 업무를 직접 하느냐, 맡기느냐입니다. 한 번 묻고 끝나는 에이전트는 똑똑한 도구에 가깝지만, 정해진 시간마다 알아서 움직이는 에이전트는 진짜 비서에 가까워집니다. Hermes에서 그 변신을 맡는 기능이 바로 cron 자동화입니다.¹

이 기능을 이해하면 Hermes는 "필요할 때만 부르는 도우미"에서 "항상 일하는 에이전트"로 바뀝니다. 아침 브리핑, 서버 점검, 주간 리포트, 이상 감지 알림, 경쟁사 모니터링 같은 일을 사람이 잊어도 Hermes는 잊지 않습니다.¹²

자동화가 왜 핵심인가

매일 아침 같은 보고서를 확인하고, 매주 같은 점검을 하고, 매시간 같은 상태를 확인하는 일은 사람에게는 지루하지만 에이전트에게는 딱 맞는 일입니다. Hermes의 cron은 이런 반복을 일정으로 묶어 두고, 시간이 되면 새 세션에서 작업을 수행한 뒤 결과를 원하는 곳으로 전달합니다.¹

중요한 점은 Hermes의 자동화가 단순히 "명령 예약"이 아니라는 것입니다. 정해진 시각에 에이전트가 실행되어 추론하고, 도구를 쓰고, 결과를 정리해 전달합니다. 그래서 같은 자동화라도 "서버 확인해"가 아니라 "SSH로 접속해 nginx 상태를 확인하고, 웹 응답까지 검증한 뒤 요약해"처럼 꽤 복합적인 일을 맡길 수 있습니다.¹

쉽게 말해, 일반적인 스케줄러가 알람시계라면 Hermes의 cron은 알람이 울리면 직접 일까지 해 주는 비서입니다.

Hermes cron의 큰 그림

Hermes의 스케줄링은 하나의 통합된 cronjob 계열 기능으로 관리됩니다. 사용자는 자연어로 요청할 수도 있고, /cron 슬래시 명령이나 hermes cron CLI로 직접 만들 수도 있습니다.¹

실행 구조는 비교적 명확합니다. 작업은 저장소 파일에 기록되고, 게이트웨이가 일정 주기로 스케줄러를 확인합니다. 실행 시간이 된 작업이 있으면 Hermes는 그 작업마다 완전히 새로운 에이전트 세션을 띄워 작업을 수행합니다. 실행 결과는 채팅 원본, 로컬 파일, 혹은 연결된 플랫폼으로 전달됩니다.¹³

여기서 꼭 기억할 점이 있습니다. cron 작업은 기존 대화의 맥락을 이어받지 않습니다. 즉, 평소 채팅에서 "그 서버"라고 불렀던 대상은 cron 실행 시에는 아무 의미가 없습니다. 자동화 프롬프트는 혼자서도 이해될 만큼 자급자족형이어야 합니다.¹

먼저 준비할 것

cron이 돌아가려면 Hermes가 계속 살아 있어야 합니다. 가장 일반적인 방법은 게이트웨이를 지속 실행하는 것입니다. 서버라면 서비스로 설치해 두는 편이 안정적입니다. 문서와 가이드들은 PM2, Docker, 사용자 서비스, 시스템 서비스 등 어떤 방식이든 Hermes 프로세스가 계속 떠 있어야 일정이 제때 실행된다고 강조합니다.¹²

예를 들어 다음과 같이 게이트웨이를 실행하거나 서비스로 설치할 수 있습니다.

hermes gateway
hermes gateway install
sudo hermes gateway install --system

스케줄이 안 맞는 것처럼 보일 때는 시간대도 확인해야 합니다. 일부 가이드에서는 시간대 미설정 시 UTC 기준으로 동작할 수 있어, "분명 9시에 맞췄는데 왜 오후에 오지?" 같은 일이 생길 수 있다고 설명합니다.²

스케줄을 만드는 세 가지 방식

Hermes에서 예약 작업을 만드는 방법은 크게 세 가지입니다.

자연어로 만들기

가장 편한 방법은 그냥 말하는 것입니다.

매일 아침 9시에 Hacker News에서 AI 뉴스를 확인해서 텔레그램으로 요약 보내줘.

Hermes는 이런 요청을 내부적으로 적절한 스케줄 형식으로 바꿔 cron 작업을 생성합니다.¹

이 방식의 장점은 사람답다는 점입니다. 특히 "평일 오전 8시", "매주 월요일", "두 시간마다" 같은 표현은 기억하기 쉽습니다. 초보자라면 먼저 자연어부터 시작하는 것이 좋습니다.

채팅에서 /cron 명령 쓰기

이미 채팅 안에 있다면 슬래시 명령이 빠릅니다.

/cron add 30m "빌드 확인하라고 알려줘"
/cron add "every 2h" "서버 상태를 점검해줘"
/cron add "every 1h" "새 피드 항목을 요약해줘" --skill blogwatcher

대화형 인터페이스 안에서 바로 만들고 수정하고 목록을 볼 수 있어, 운영 중인 에이전트를 손보기에 편합니다.¹

CLI에서 직접 만들기

터미널 중심으로 운용한다면 CLI가 깔끔합니다.

hermes cron create "every 2h" "Check server status"
hermes cron create "0 9 * * 1-5" "평일 오전 9시에 작업 브리핑 작성" --name "Morning Brief"

스크립트화하기 쉽고, 원격 서버에서 관리하기도 좋습니다.¹

스케줄 형식 이해하기

Hermes는 여러 형식의 일정을 받습니다. 처음에는 어려워 보여도 실제로는 네 가지만 익히면 됩니다.¹

1회 실행: 상대 시간

30m, 2h, 1d 같은 형식은 "지금부터 얼마나 뒤에 한 번 실행할지"를 뜻합니다.¹

/cron add 30m "30분 뒤에 배포 상태 다시 확인해줘"

짧은 리마인더나 임시 점검에 좋습니다.

반복 실행: interval 형식

every 30m, every 2h, every 1d 같은 형식은 주기적으로 반복합니다.¹

hermes cron create "every 6h" "장애 공지 페이지에 새 업데이트가 있는지 확인해줘"

이 형식은 사람이 읽기 쉬워서 실무에서 가장 자주 쓰입니다.

정밀 제어: cron 표현식

전통적인 5필드 cron 표현식도 지원합니다.¹

0 9 * * *
0 9 * * 1-5
0 */6 * * *
30 8 1 * *

각각 매일 9시, 평일 9시, 6시간마다, 매달 1일 8시 30분을 뜻합니다.¹

자연어보다 딱딱하지만, 운영 자동화에서는 아주 강력합니다. "평일만", "매달 첫날만", "매주 일요일 자정"처럼 세밀하게 조정하기 좋습니다.

특정 시각 1회 실행: ISO 타임스탬프

정확한 날짜와 시각에 딱 한 번 실행하고 싶다면 ISO 형식을 쓸 수 있습니다.¹

hermes cron create "2026-05-01T09:00:00" "출시일 체크리스트 실행"

런칭, 행사, 결제일, 공지 배포 같은 이벤트성 작업에 유용합니다.

가장 중요한 원칙: 프롬프트는 혼자서도 이해되어야 한다

cron 작업은 매번 새 세션에서 실행됩니다. 이전 대화, 방금 전 설명, 지난주의 문맥을 당연하게 기대하면 안 됩니다.¹

예를 들어 이런 프롬프트는 좋지 않습니다.

그 서버 문제 좀 다시 확인해줘

이런 식이 훨씬 좋습니다.

SSH로 192.168.1.100 서버에 deploy 사용자로 접속해 nginx 상태를 확인하고,
https://example.com 이 HTTP 200을 반환하는지 검사한 뒤
문제가 있으면 원인 후보와 함께 요약 보고해줘.

좋은 자동화 프롬프트는 세 가지를 분명히 말합니다. 무엇을 볼지, 어떻게 판단할지, 어떤 형식으로 보고할지입니다. 이 세 가지가 빠지면 자동화는 금방 들쭉날쭉해집니다.¹

스킬을 붙이면 자동화가 더 똑똑해진다

Hermes의 cron은 스킬과 아주 잘 어울립니다. 작업마다 긴 지시문을 매번 프롬프트에 욱여넣는 대신, 반복 로직은 스킬로 빼 두고 cron은 그 스킬을 불러 실행할 수 있습니다.¹

예를 들어 블로그 피드를 읽어 요약하는 스킬이 이미 있다면 다음처럼 붙이면 됩니다.

hermes cron create "every 1h" \
  "설정된 피드의 새 항목을 요약해줘" \
  --skill blogwatcher \
  --name "Feed Summary"

스킬은 여러 개도 붙일 수 있습니다. 이때 순서대로 로드되고, 마지막 프롬프트가 그 위에 덧씌워지는 작업 지시가 됩니다.¹

hermes cron create "every 6h" \
  "새 지역 이벤트와 근처 흥미로운 장소를 찾아 하나의 짧은 브리프로 합쳐줘" \
  --skill blogwatcher \
  --skill find-nearby \
  --name "Local Brief"

이 구조가 좋은 이유는 자동화가 점점 재사용 가능한 작업 체계로 바뀌기 때문입니다. 처음엔 그냥 일정 하나였는데, 나중엔 "우리 팀 주간 리포트 스킬", "배포 검증 스킬", "경쟁사 탐지 스킬"처럼 자산이 쌓입니다.¹⁶

결과는 어디로 보내는가

자동화의 완성은 실행이 아니라 전달입니다. 아무리 잘 돌았어도 사람이 못 보면 소용이 없으니까요.

Hermes는 결과를 다양한 대상으로 보낼 수 있습니다. 기본적으로 메시징 플랫폼에서 만든 작업은 원래 대화방으로, CLI에서 만든 작업은 로컬 파일로 저장되는 경향이 있습니다. 필요하면 텔레그램, 디스코드, 슬랙 등 특정 플랫폼이나 채널로 직접 보낼 수 있습니다.¹

대표적인 전달 대상은 다음과 같습니다.

• origin: 작업을 만든 원래 채팅으로 전달

• local: 로컬 파일에만 저장

• telegram, discord, slack: 해당 플랫폼의 홈 채널로 전달

• telegram:채팅ID, discord:#channel 같은 형식: 특정 대상에 직접 전달

• email, sms, signal, matrix, mattermost, homeassistant 등: 연결된 플랫폼으로 전달¹

예를 들어 매일 아침 리포트를 텔레그램으로 받고 싶다면 이렇게 만들 수 있습니다.

hermes cron create "0 9 * * *" \
  "어제 밤부터 지금까지의 AI 주요 뉴스를 5줄로 요약해줘" \
  --name "Morning AI Digest" \
  --deliver telegram

이미 게이트웨이와 홈 채널이 설정돼 있다면, 출근길 메신저에서 자연스럽게 결과를 받게 됩니다. 에이전트가 먼저 말을 거는 순간입니다.¹

응답 전달의 숨은 규칙

Hermes cron에는 실전에서 꽤 유용한 규칙이 몇 가지 있습니다.

기본적으로 cron 실행의 최종 응답은 자동 전달됩니다. 그래서 같은 대상에 보내기 위해 프롬프트 안에서 send_message를 또 호출할 필요가 없습니다. 같은 곳으로 중복 전송하려 하면 Hermes가 중복을 피하도록 처리합니다.¹

또한 기본 설정에서는 cron 결과가 약간의 머리말과 꼬리말로 감싸집니다. "이건 스케줄된 작업의 결과입니다"라는 표시를 붙여 주는 셈입니다. 만약 완전히 생 텍스트 그대로 보내고 싶다면 cron.wrap_response: false로 바꿀 수 있습니다.¹

# ~/.hermes/config.yaml
cron:
  wrap_response: false

메시지 꾸밈이 필요 없는 기계 처리용 채널이나, 짧고 깔끔한 알림만 받고 싶을 때 유용합니다.

알림 폭탄을 막는 [SILENT] 패턴

자동화에서 가장 흔한 실패는 오류가 아니라 너무 성실한 알림입니다. 매시간 "문제 없습니다"가 날아오면, 며칠 뒤에는 진짜 경고도 무시하게 됩니다.

Hermes는 이를 위해 [SILENT] 규칙을 지원합니다. 작업이 성공했고 최종 응답이 [SILENT]로 시작하면, 결과 전달을 생략합니다. 대신 출력은 로컬 감사 기록에 남습니다.¹

예를 들어 이런 프롬프트를 만들 수 있습니다.

nginx가 실행 중인지 확인하세요.
모든 것이 정상이라면 [SILENT]만 응답하세요.
문제가 있다면 원인과 함께 경고를 작성하세요.

이 패턴은 서버 모니터링, 배포 검증, 사이트 변경 감지 같은 작업에 아주 잘 맞습니다. 정상일 때는 조용하고, 이상이 생길 때만 말합니다. 에이전트가 배려심까지 갖춘 셈입니다.¹⁴

작업 수정, 일시정지, 재실행

자동화는 한 번 만들고 끝나는 기능이 아닙니다. 일정은 바뀌고, 프롬프트는 다듬어지고, 스킬도 교체됩니다. Hermes는 작업 전체 생명주기를 관리할 수 있게 해 줍니다.¹

자주 쓰는 명령은 다음과 같습니다.

/cron list
/cron pause <job_id>
/cron resume <job_id>
/cron run <job_id>
/cron remove <job_id>

CLI에서도 거의 같은 방식입니다.

hermes cron list
hermes cron pause <job_id>
hermes cron resume <job_id>
hermes cron run <job_id>
hermes cron remove <job_id>
hermes cron status
hermes cron tick

pause는 작업을 지우지 않고 잠시 멈추는 기능이고, resume은 다시 활성화합니다. run은 다음 스케줄러 틱에서 즉시 한 번 실행하게 만들고, remove는 완전히 삭제합니다.¹

일정이나 프롬프트를 바꾸고 싶다면 새로 만들 필요도 없습니다.

hermes cron edit <job_id> --schedule "every 4h"
hermes cron edit <job_id> --prompt "개정된 작업 지시를 사용해줘"
hermes cron edit <job_id> --add-skill find-nearby
hermes cron edit <job_id> --remove-skill blogwatcher
hermes cron edit <job_id> --clear-skills

운영 관점에서 이 기능은 꽤 중요합니다. 실제 현장에서는 "처음부터 완벽한 자동화"보다 "조금씩 다듬는 자동화"가 훨씬 많기 때문입니다.¹

내부에서 어떻게 돌아가는가

Hermes의 스케줄러는 게이트웨이 데몬이 주기적으로 확인하며, 기본적으로 약 60초마다 한 번씩 틱을 돕니다. 각 틱에서 해야 할 일은 단순합니다. 저장된 작업 목록을 읽고, 실행 시간이 지난 작업을 찾아, 각각 새 에이전트 세션으로 실행하고, 결과와 다음 실행 시각을 갱신합니다.¹³

중복 실행 방지도 들어 있습니다. 파일 락을 사용해 겹치는 틱이 같은 작업 묶음을 두 번 실행하지 않도록 막습니다.¹

작업 정보는 ~/.hermes/cron/jobs.json에 저장되고, 실행 결과는 ~/.hermes/cron/output/{job_id}/{timestamp}.md에 쌓입니다. 따라서 메시지 전송이 실패했더라도 로컬 결과를 다시 확인할 수 있습니다.¹

이 구조를 알면 문제를 찾기 쉬워집니다. "작업이 생성되지 않았나?", "게이트웨이가 안 떠 있나?", "실행은 됐는데 전달만 실패했나?"를 구분할 수 있기 때문입니다.

자동화가 놓치는 것과 놓치지 않는 것

스케줄러가 꺼져 있던 시간에 예정된 반복 작업은, 다시 켠 뒤 한꺼번에 몰아서 다 실행하지 않는 방향으로 동작합니다. 즉, 세 시간 꺼져 있었다고 해서 시간당 작업을 세 번 연속 쏟아붓지 않고, 현재 시점 기준 다음 실행으로 넘어가는 식입니다.⁴

이 동작은 실무적으로 꽤 합리적입니다. 아침에 서버를 켰더니 밤새 놓친 리포트가 열두 개 도착하는 상황을 막아 주기 때문입니다. 물론 "그 사이 빠진 실행도 꼭 복구해야 하는 업무"라면 cron보다 이벤트 기반 웹훅이나 별도 큐 시스템이 더 적합할 수 있습니다.

자동화 안에서 또 자동화를 만들 수는 없다

Hermes는 안전장치로, cron 실행 중에는 cron 관리 도구를 비활성화합니다. 즉, 예약 작업이 또 다른 예약 작업을 재귀적으로 만들지 못합니다.¹³

왜 이런 제한이 있을까요? 이유는 간단합니다. "매시간 실행되는 작업이 자기 자신을 복제하는" 사고를 막기 위해서입니다. 이런 보호장치가 없으면 토큰 비용도 폭증하고, 시스템도 순식간에 어지러워집니다.¹

안전한 자동화는 똑똑한 자동화만큼 중요합니다. Hermes는 이 부분을 꽤 현실적으로 다룹니다.

스크립트와 결합하면 더 실용적이다

Hermes cron은 프롬프트만으로도 쓸 수 있지만, 필요하면 사전 스크립트를 붙여 실행 전에 데이터를 준비할 수 있습니다. 스크립트의 표준 출력은 이후 에이전트 문맥으로 주입되어, 에이전트는 "수집된 데이터"를 읽고 판단하는 역할에 집중할 수 있습니다.¹³⁵

예를 들어 단순한 사이트 상태 점검 스크립트가 있다고 해 봅시다. 스크립트는 HTTP 응답 코드와 지연 시간을 수집하고, 에이전트는 그 결과를 해석해 요약만 합니다. 이 방식의 장점은 기계적 수집과 언어적 판단을 분리할 수 있다는 것입니다.⁵

스크립트는 기본 120초 제한이 있으며, 더 오래 걸리면 설정이나 환경 변수로 늘릴 수 있습니다.¹

cron:
  script_timeout_seconds: 300

짧은 데이터 수집, 변경 감지, diff 생성 같은 일은 스크립트가 맡고, "이게 의미하는 바를 정리하는 일"은 Hermes가 맡는 구조가 가장 깔끔합니다.

비용과 안정성을 함께 생각하기

자동화는 편리하지만 공짜는 아닙니다. 특히 클라우드 모델을 쓴다면 cron 한 번마다 모델 호출 비용이 생깁니다. 그래서 처음부터 5분 간격으로 모든 걸 자동화하기보다, 일 1~2회 정도의 중요한 작업부터 시작하는 편이 좋습니다.⁴

대신 Hermes는 안정성 측면에서 꽤 준비가 되어 있습니다. cron 작업도 일반 에이전트처럼 fallback provider와 자격 증명 풀 회전을 이어받을 수 있어, 특정 키가 속도 제한에 걸리거나 공급자가 실패했을 때 다른 경로로 복구를 시도할 수 있습니다.¹

즉, 자동화를 많이 돌릴수록 중요한 건 단순한 "성공 여부"가 아니라 꾸준히 실패하지 않는 구조입니다. Hermes는 그 점을 고려해 설계되어 있습니다.¹

실전 예시 1: 아침 브리핑

가장 무난하고 효과가 큰 자동화입니다.

hermes cron create "0 8 * * 1-5" \
  "평일 오전 8시에 주요 AI 뉴스, 내 GitHub 알림, 오늘 일정의 핵심만 10줄 이내로 요약해줘" \
  --name "Morning Brief" \
  --deliver telegram

이 작업의 핵심은 "길게 쓰지 말고, 당장 읽을 수 있게 쓰라"는 식으로 출력 형식을 제한하는 것입니다. 자동화는 사람이 바쁜 순간에 읽는 경우가 많으므로, 짧고 예측 가능한 형식이 좋습니다.

실전 예시 2: 서버 이상 감지

알림이 많으면 안 되는 대표 사례입니다.

hermes cron create "every 30m" \
  "웹 서버 상태와 주요 엔드포인트를 확인해줘. 모두 정상이면 [SILENT]만 응답하고, 하나라도 비정상이면 장애 요약과 우선 점검 순서를 작성해줘." \
  --name "Uptime Monitor" \
  --deliver discord

이 경우 Discord나 Telegram 같은 즉시 확인 가능한 채널이 잘 맞습니다. 정상일 때 조용하고, 문제 생길 때만 말하게 만드는 것이 포인트입니다.¹⁵

실전 예시 3: 주간 정리 리포트

주간 회고나 팀 리포트에도 잘 맞습니다.

hermes cron create "0 18 * * 5" \
  "이번 주 커밋, 이슈, 미완료 작업, 주목할 위험 요소를 정리해서 팀 공유용 주간 리포트를 작성해줘. 각 항목은 짧게, 마지막에 다음 주 우선순위 3개를 제안해줘." \
  --name "Weekly Team Report" \
  --deliver slack

정리형 자동화는 특히 "정보는 흩어져 있지만 읽을 시간은 없는 팀"에 잘 맞습니다.

자주 생기는 문제와 해결 힌트

자동화가 기대한 대로 움직이지 않을 때는 대개 네 가지를 점검하면 됩니다.

• 게이트웨이가 계속 실행 중인지 확인합니다. 재부팅 후 자동 시작이 안 되면 스케줄이 조용히 멈춥니다.¹²

• 시간대 설정을 확인합니다. UTC 기준과 로컬 시간 기준이 어긋나면 일정이 밀려 보입니다.²

• 프롬프트가 충분히 구체적인지 확인합니다. cron은 질문을 다시 물어보지 못하므로 अस्पष्ट한 지시는 실패의 지름길입니다.¹

• 전달 대상 플랫폼이 제대로 연결돼 있는지 확인합니다. 실행은 성공했지만 전달만 실패할 수도 있습니다.¹²

디버깅할 때는 hermes cron list, hermes cron status, hermes cron tick 같은 명령으로 현재 상태를 확인해 보는 것이 좋습니다. 수동 틱은 "스케줄러 자체는 도는가?"를 확인하기에 특히 유용합니다.¹

좋은 자동화는 작게 시작한다

처음부터 거대한 자동화 파이프라인을 만들 필요는 없습니다. 오히려 다음 순서가 가장 성공 확률이 높습니다.

• 먼저 하루 한 번짜리 리포트 하나를 만듭니다.

• 그다음 이상 시에만 알리는 [SILENT] 모니터 하나를 붙입니다.

• 마지막으로 스킬이나 스크립트를 결합해 재사용성을 높입니다.

이 순서로 가면 "쓸모 있는 자동화"에서 "운영 가능한 자동화"로 자연스럽게 발전합니다.

이 챕터의 핵심 정리

Hermes의 cron은 단순한 예약 기능이 아닙니다. 정해진 시간에 새 에이전트를 깨워, 필요한 도구와 스킬을 불러오고, 결과를 원하는 채널로 전달하는 자동화 엔진입니다.¹³

자연어로 쉽게 만들 수 있지만, 실전에서는 프롬프트를 구체적으로 쓰고, 결과 전달 방식을 설계하고, [SILENT] 패턴으로 알림 피로를 줄이고, 게이트웨이를 안정적으로 계속 띄워 두는 것이 중요합니다.¹²⁴

한마디로 정리하면 이렇습니다.

메모리와 스킬이 Hermes를 똑똑하게 만든다면, 자동화는 Hermes를 부지런하게 만듭니다.

이제부터 Hermes는 기다리는 에이전트가 아니라, 정해진 시간에 먼저 움직이는 에이전트가 됩니다.

참고

¹Scheduled Tasks (Cron) | Hermes Agent

²Schedule Tasks with Hermes Using Natural Language

³Cron and Scheduled Tasks | NousResearch/hermes-agent | DeepWiki

⁴10-1. 자연어 스케줄링

⁵Automation Templates | Hermes Agent

⁶Skills System | NousResearch/hermes-agent | DeepWiki