Hermes Cron 시스템 사용법

A practical guide to Hermes Cron for designing recurring AI-agent jobs with schedules, self-contained prompts, skills, delivery, scripts, and pacing rules. Use it when deciding how a repeated automation should run and report its work.

자동화에서 “정해진 시간에 실행된다”는 말은 출발점일 뿐입니다. 실제 운영에서 더 중요한 질문은 따로 있습니다. 그 실행은 매번 무엇을 끝내는가. 실패했을 때 어디까지 보고하는가. 다음 실행이 이전 실행의 빈칸을 어떻게 이어받는가.

Hermes Cron은 이 질문을 다루기 위한 예약 실행 기능입니다. 단순히 알람을 울리는 장치가 아니라, 특정 시점마다 에이전트에게 독립적인 작업 지시를 실행시키고, 결과를 정해진 채널이나 장소로 돌려보내는 반복 실행 시스템입니다. 잘 쓰면 매일의 리서치, 주기적 점검, 정기 보고, 백로그 처리, 외부 피드 모니터링 같은 일을 사람의 기억력에 의존하지 않고 꾸준히 굴릴 수 있습니다.

다만 Hermes Cron은 “한번 만들어 두면 알아서 똑똑해지는 마법”이 아닙니다. Cron 작업은 사람이 자리를 비운 상태에서도 실행됩니다. 그래서 질문을 되물을 수 없고, 현재 대화의 분위기에 기대서 움직일 수도 없습니다. 좋은 Cron 설계는 스케줄보다 먼저 실행 단위와 완료 조건을 명확히 정하는 일에서 시작합니다.

Hermes Cron이 실제로 하는 일

Hermes Cron 작업은 크게 네 가지 요소로 구성됩니다. 첫째, 언제 실행할지 정하는 schedule입니다. 둘째, 실행 시 에이전트가 읽을 self-contained prompt입니다. 셋째, 작업에 필요한 skills, toolsets, workdir, script 같은 실행 환경입니다. 넷째, 결과를 어디로 보낼지 정하는 delivery입니다.

중요한 점은 Cron 실행이 보통 새로운 세션처럼 다뤄진다는 것입니다. 지금 사람과 나눈 대화의 뒷부분을 암묵적으로 기억하고 있다고 가정하면 안 됩니다. 작업 지시에는 목표, 입력 범위, 판단 기준, 중단 조건, 최종 보고 형식이 들어 있어야 합니다. “늘 하던 것 해줘” 같은 문장은 사람이 있는 대화에서는 통할 수 있어도, 예약 실행에는 약합니다.

스케줄은 여러 방식으로 표현할 수 있습니다. 30m, 2h 같은 duration은 지금부터 일정 간격 뒤 실행하는 감각에 가깝습니다. every 2h, every monday 9am 같은 표현은 사람이 읽기 쉬운 반복 일정입니다. 0 9 * * * 같은 5-field cron expression은 정교한 운영 시간표를 만들 때 좋습니다. ISO timestamp는 특정 시점에 한 번 실행해야 할 때 유용합니다.

CLI에서는 작업 목록을 확인하고 직접 실행하거나 멈출 수 있습니다.

hermes cron list
hermes cron create "every 2h"
hermes cron run JOB_ID
hermes cron pause JOB_ID
hermes cron resume JOB_ID
hermes cron remove JOB_ID

이 명령들은 운영 표면입니다. 그러나 좋은 Cron의 품질은 명령어보다 prompt와 실행 환경에서 결정됩니다.

좋은 Cron Prompt의 조건

Cron prompt는 독립 실행 가능한 운영 문서처럼 써야 합니다. 에이전트가 새로 깨어난다고 생각하고, 그 시점에 필요한 판단 재료를 모두 포함해야 합니다.

첫째, 목표가 단일해야 합니다. “새 글감도 찾고, 기존 글도 고치고, 필요하면 발행까지 해줘”처럼 여러 단계가 섞이면 반복 실행의 품질이 흔들립니다. 한 작업은 하나의 완료 단위를 가져야 합니다.

둘째, 입력 범위가 닫혀 있어야 합니다. 어떤 폴더, 어떤 피드, 어떤 데이터 범위, 어떤 조건의 항목을 볼지 명확해야 합니다. 범위가 열려 있으면 Cron은 매번 그럴듯한 일을 하지만, 전체 백로그의 어디를 닫았는지는 알기 어려워집니다.

셋째, 완료 조건이 있어야 합니다. “요약해줘”보다 “새 항목이 있으면 세 문단으로 요약하고, 없으면 조용히 종료하라”가 낫습니다. “고쳐줘”보다 “검사에서 통과한 항목은 완료로 기록하고, 실패한 항목은 원인과 다음 액션을 보고하라”가 낫습니다.

넷째, 질문할 수 없다는 전제를 포함해야 합니다. Cron 실행 중 사람에게 되물을 수 없는 상황이라면, 애매한 경우의 기본값을 미리 정해 두어야 합니다. 예를 들어 “소스가 없으면 새 글을 만들지 말고 실패 사유만 보고한다”, “민감한 정보가 보이면 발행하지 않는다”, “지정된 시간 안에 끝나지 않으면 현재까지의 결과만 요약한다” 같은 규칙입니다.

다섯째, 최종 보고 형식이 정해져 있어야 합니다. Cron은 실행 후 결과를 delivery 설정에 따라 전달합니다. 보고가 길어야 하는 작업도 있고, 변화가 없을 때는 아무 말도 하지 않는 편이 나은 watchdog형 작업도 있습니다. 사람이 읽을 보고인지, 다음 작업이 이어받을 구조화된 출력인지에 따라 형식이 달라져야 합니다.

Skills, scripts, delivery를 함께 설계하기

Hermes Cron의 장점은 단순한 시간표를 넘어서, 실행에 필요한 맥락을 함께 묶을 수 있다는 데 있습니다. 반복 작업이 특정 도메인 절차를 따라야 한다면 skills를 붙입니다. 예를 들어 블로그 발행 작업은 글 작성, 이미지 확인, 빌드, 배포 검증이 하나의 절차로 묶여 있어야 합니다. 이 절차를 skill로 고정하면 매 실행마다 같은 기준을 다시 설명하지 않아도 됩니다.

script는 Cron 실행 앞단에서 데이터를 수집하거나 변화를 감지할 때 유용합니다. 예를 들어 RSS 피드, 디스크 사용량, 특정 API 상태, 새 파일 목록처럼 기계적으로 확인할 수 있는 정보는 스크립트가 모으고, 에이전트는 그 결과를 읽고 판단하게 만들 수 있습니다. 반대로 판단이 거의 필요 없는 watchdog은 no_agent=True처럼 스크립트 출력 자체를 최종 메시지로 쓰는 방식이 더 적합할 수 있습니다. 이 경우 stdout이 비어 있으면 조용히 지나가고, 문제가 있을 때만 알림을 보내도록 설계할 수 있습니다.

context_from은 이전 작업의 결과를 다음 작업에 주입해야 할 때 쓰는 연결 장치입니다. workdir은 특정 프로젝트 안에서 실행해야 하는 작업에 필요합니다. enabled_toolsets는 Cron 작업이 정말 필요한 도구만 쓰게 제한할 때 도움이 됩니다. 모델이나 provider를 고정해야 하는 반복 작업이라면 model override도 설계 요소가 됩니다.

delivery도 별도의 설계 대상입니다. 같은 Cron이라도 개인 메모로 남길지, 팀 채널에 보낼지, 아무 변화가 없으면 침묵할지에 따라 운영 감각이 완전히 달라집니다. 반복 실행은 쉽게 소음이 됩니다. 그래서 Cron은 “언제 말할지”만큼 “언제 말하지 않을지”도 정해야 합니다.

한 가지 안전 규칙도 중요합니다. Cron 실행 안에서 다시 Cron을 만들도록 설계하지 않는 편이 좋습니다. 예약 작업이 예약 작업을 계속 낳으면 운영자가 전체 실행 구조를 추적하기 어렵습니다. 반복성은 Cron 설정에서 관리하고, 개별 실행은 주어진 작업을 끝내는 쪽에 집중시키는 편이 안정적입니다.

페이스는 주기보다 완료 단위에서 나온다

Cron을 처음 설계할 때 가장 흔한 실수는 실행 주기를 먼저 조정하는 것입니다. 느리면 더 자주 돌리고, 시끄러우면 덜 자주 돌립니다. 하지만 실제 문제는 주기가 아니라 한 번의 실행이 닫는 단위일 때가 많습니다.

예를 들어 큰 백로그를 처리하는 Cron이 있다고 해보겠습니다. 두 시간마다 한 항목을 무작위로 고치는 방식이라면, 로그는 꾸준히 쌓이지만 전체가 언제 끝날지는 예측하기 어렵습니다. 반대로 한 번의 실행이 “하나의 소스 묶음을 붙잡고 상태를 판정한다”처럼 닫힌 단위를 가진다면, 같은 주기에서도 진척이 훨씬 분명해집니다.

그래서 Cron 설계에서는 세 가지를 분리해야 합니다. 실행 주기는 얼마나 자주 깨어날지 정합니다. 처리 단위는 무엇을 완료로 볼지 정합니다. 처리량은 한 번 깨어났을 때 얼마나 밀어낼지 정합니다. 이 셋을 섞어 버리면 자동화는 성실하게 움직이지만 프로젝트는 앞으로 가지 않는 상태가 됩니다.

실제 운영에서도 비슷한 조정이 필요했습니다. 한 내부 문서화 작업은 처음에 “정기적으로 보수한다”는 점만으로 충분해 보였습니다. 하지만 백로그 규모와 처리 단위가 맞지 않아, 그대로 두면 몇 달 동안 돌아도 한 바퀴를 끝내기 어려운 상태였습니다. 해결은 단순히 더 자주 실행하는 것이 아니었습니다. 한 실행이 붙잡는 단위를 정하고, 통과 가능한 항목은 빠르게 완료 처리하고, 실제 수리가 필요한 항목에는 별도의 처리량과 시간 제한을 두는 쪽이었습니다. 사건 자체보다 중요한 교훈은 이것입니다. Cron의 페이스는 숫자 하나가 아니라 완료 단위, 배치 크기, 중단 조건의 조합에서 나옵니다.

Hermes Cron 설계 체크리스트

Cron 작업을 만들기 전에는 아래 질문을 확인하는 편이 좋습니다.

• 이 작업은 반복 실행이 정말 필요한가, 아니면 한 번 실행하면 끝나는가?
• 스케줄은 duration, every 표현, cron expression, ISO timestamp 중 무엇이 가장 자연스러운가?
• prompt만 읽어도 새 세션의 에이전트가 작업을 이해할 수 있는가?
• 한 번의 실행이 무엇을 완료로 인정하는가?
• 입력 범위와 제외 범위가 명확한가?
• 실패하거나 애매할 때의 기본 행동이 정해져 있는가?
• 필요한 skills, script, workdir, toolsets가 지정되어 있는가?
• 결과는 어디로 전달되는가?
• 변화가 없을 때도 보고해야 하는가, 아니면 조용히 넘어가야 하는가?
• Cron 실행이 또 다른 Cron을 만들도록 설계되어 있지는 않은가?

Hermes Cron은 “시간이 되면 에이전트를 깨우는 기능”으로 설명할 수 있습니다. 하지만 운영 관점에서는 더 정확히 말해야 합니다. Hermes Cron은 반복되는 시간을 작업 단위로 바꾸는 장치입니다. 그래서 좋은 Cron은 몇 시에 도는지보다, 깨어난 뒤 무엇을 끝내고 어떤 흔적을 남기는지가 분명합니다.

반복 자동화의 품질은 실행 횟수가 아니라 닫힌 작업의 누적에서 나옵니다. Cron을 만들 때는 먼저 시간표를 쓰기보다, 그 시간표 위에서 닫힐 일의 모양을 그려야 합니다. 그것이 Hermes Cron을 단순 알림이 아니라 신뢰할 수 있는 에이전트 운영 시스템으로 쓰는 첫 번째 방법입니다.