🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Hermes Agent의 Cron & Automation은 예약 실행, fresh session, 자동 전달, 비용 절감 게이트를 결합해 반복 작업을 사용자의 수동 호출 없이 운영하게 만드는 자동화 계층이다.

📌 핵심 요점

1. Cron은 Hermes gateway 안에서 동작하며, 일정이 되면 이전 대화 이력이 없는 fresh session을 열어 프롬프트를 실행하고 결과를 지정 채널로 전달한다.
2. Cron 작업은 CLI, Telegram 같은 채팅, TUI, Web dashboard에서 만들고 관리할 수 있으며, profile·skill·blueprint를 선택해 작업별 실행 환경을 나눌 수 있다.
3. fresh session은 안전성과 재현성을 높이지만, 이전 대화 맥락을 기억하지 않기 때문에 대상 서버, 확인 절차, 성공 기준, 전달 방식까지 프롬프트에 구체적으로 적어야 한다.
4. 비용 최적화의 핵심은 no agent 모드, wake agent gate, pre-run script, 좁은 tool set을 활용해 모델이 꼭 필요할 때만 깨어나게 만드는 것이다.
5. context from 기능은 이전 Cron 작업의 최신 출력을 downstream 작업에 주입해, 별도 프레임워크 없이 데이터 수집·분석·보고가 이어지는 시간 기반 파이프라인을 만든다.

🧩 배경과 문제 정의

• Hermes Agent는 도구, MCP, 서비스 설정을 통해 수행 범위를 넓힐 수 있지만, 여전히 사용자가 채팅을 열고 직접 지시해야 하는 수동 시작점이 남아 있다.
• Cron은 Hermes가 정해진 시간에 새 세션을 열고, 프롬프트를 실행한 뒤 결과를 지정 채널로 전달하게 해 반복 업무 자동화의 마지막 연결 고리를 맡는다.
• Hermes의 Cron은 단순한 예약 실행을 넘어 CLI, 채팅, TUI, 대시보드, Telegram, Discord, 로컬 파일 출력 등 다양한 운영 표면과 연결된다.
• 각 Cron 실행은 새 세션에서 시작되기 때문에 이전 대화 맥락에 의존하지 않는 명확한 프롬프트, 필요한 skill, 작업 디렉터리, 사전 스크립트, upstream 출력 설계가 중요하다.
• 비용 효율적인 자동화를 위해서는 매번 LLM을 호출하는 방식만이 아니라 no agent 모드, wake agent gate, deterministic script, context handoff를 함께 고려해야 한다.
• 영상의 핵심 문제는 “에이전트가 무엇을 할 수 있는가”를 넘어, “언제 자동으로 실행하고, 언제 깨우지 않으며, 어떤 맥락을 전달해 실용적인 자동화 파이프라인으로 만들 것인가”이다.

🕒 시간순 섹션별 상세정리

1. Cron 자동화의 목적과 이번 범위

• Hermes Agent의 Cron과 자동화는 매번 채팅을 열어 반복 지시해야 하는 흐름을 줄이는 데 초점을 둔다 [00:18]
• 이번 모듈의 핵심 범위는 예약 실행부터 작업 완료, 결과 전달까지 이어지는 end-to-end 자동화다 [00:33]

2. Gateway 기반 실행 구조와 fresh session

• Hermes의 Cron은 별도 독립 프로그램이 아니라, 항상 켜져 있는 gateway 안에서 동작한다 [02:19]
• Gateway는 에이전트를 외부에서 접근 가능한 상태로 유지하는 실행 기반이며, Cron도 이 구조 위에서 발화된다 [02:34]

3. Cron 상태 확인과 생성 경로

• Hermes cron status는 gateway 실행 여부와 Cron 발화 가능 상태를 확인하는 기본 점검 명령이다 [03:35]
• Gateway가 실행 중이 아니면 Cron 작업이 발화할 수 없으며, 이 상태는 status 출력에서 바로 확인된다 [03:50]

4. Dashboard, profile 선택, blueprint와 안전장치

• Web dashboard의 Cron 화면에서는 기존 예약 작업을 확인하고 새 작업을 생성할 수 있다 [05:49]
• 새 작업 생성 시 실행할 profile을 선택해, 모델과 skill set이 다른 자동화를 서로 분리해 운영할 수 있다 [06:04]

5. 스케줄 표현 방식과 자연어 변환

• 자연어 채팅에서는 “매일 오전 9시”처럼 원하는 시간이나 반복 간격을 그대로 요청할 수 있다 [07:41]
• Hermes는 이런 자연어 요청을 예약 실행에 필요한 내부 스케줄 형식으로 변환한다 [07:56]

6. 전달 채널, silent 출력, fresh session 프롬프트 리스크

• Messaging platform에서 생성한 작업은 기본적으로 생성된 origin을 결과 전달 대상으로 삼는다 [09:24]
• Telegram에서 만든 Hugging Face 논문 감시 작업은 실행 결과도 같은 Telegram으로 돌아가도록 구성된다 [09:39]

7. Cron 실행 컨텍스트와 비용 절감 문제

• 각 cron 실행은 이전 session의 지식이나 맥락을 이어받지 않고 새 session으로 시작된다 [12:09]
• 실행 briefing은 prompt와 attached skill에 의존하므로, 프롬프트가 모호하면 실패 위험이 커진다 [12:24]

8. No agent 모드와 deterministic alert

• No agent 모드는 scheduled job이 language model 없이 script만 실행하는 방식이다 [13:16]
• 이 모드에서는 script의 standard output을 그대로 전달하므로 provider, token, model 비용이 발생하지 않는다 [13:31]

9. $0 gate와 wake agent 조건

• Wake agent gate는 매 tick마다 script가 저비용으로 상태 변화를 확인하는 구조다 [15:12]
• 변화가 없으면 wake agent false를 출력해 agent 실행을 생략하고 추가 비용을 만들지 않는다 [15:27]

10. Agent Wikis 버그 리포트 감시 데모 구성

• Agent Wikis의 knowledge base에는 사용자가 페이지 오류를 신고할 수 있는 report a mistake 기능이 있다 [16:27]
• 신고 내용과 선택적 email은 VPS의 log로 전달된다 [16:42]

11. Gate 실행 결과와 실제 신고 처리

• Cron job을 만든 뒤 현재 cron 목록을 확인하고, bug triage 작업이 정상적으로 등록된 것을 확인한다 [19:36]
• 아직 report가 생성되지 않은 상태에서는 Telegram이나 TUI에 별도의 출력이 나타나지 않는다 [19:51]

12. Free code로 데이터 수집을 넘기는 추가 비용 계층

• Workflow가 충분히 안정되면 agent는 fix plan 작성에 머무르지 않고 실제 파일 수정까지 수행할 수 있다 [22:53]
• 다만 현재 단계에서는 사람을 loop에 남겨 최종 변경을 승인하도록 하는 방식이 더 안전하다 [23:08]

13. 작업별 도구 표면 축소와 cron 복원력

• 작은 뉴스 수집 작업에는 MOA나 브라우저 위임처럼 넓은 도구 스키마가 필요하지 않다 [24:07]
• 불필요한 도구 context는 호출할 때마다 비용과 토큰 부담을 늘리므로, 작업별로 필요한 표면만 남기는 것이 중요하다 [24:22]

14. context from으로 만드는 프레임워크 없는 파이프라인

• context from은 upstream 작업의 가장 최근 완료 출력을 downstream prompt 앞에 붙여 전달한다 [25:45]
• 각 단계는 거대한 workflow engine 없이도 독립적인 스케줄을 유지한 채 서로 연결되어 실행될 수 있다 [26:00]

15. Daily briefing 예제와 handoff를 LLM에서 런타임으로 옮기는 이유

• 예제 파이프라인은 Agent Wikis 기반 daily briefing 흐름으로 구성된다 [26:51]
• 첫 번째 작업은 매시간 knowledge base 조회 수를 기록하는 no-agent script에서 시작된다 [27:06]

16. 여러 upstream을 모으는 fan-in과 wiki traffic collector 구성

• context from에는 여러 upstream cron job을 comma로 연결해 지정할 수 있다 [29:13]
• 이 방식으로 서로 다른 위치에서 수집한 여러 report를 하나의 downstream context로 합치는 fan-in 구조를 만들 수 있다 [29:28]

17. Daily Telegram briefing과 저비용 실행 구조

• 두 번째 cron job은 collector output을 context로 받아 하루 동안의 top knowledge bases를 분석한다 [30:26]
• 이어 시간대별 reading trend를 요약하고, 매일 오전 Telegram으로 간결한 report를 전송한다 [30:41]

18. 실제 Telegram 결과와 cron·sub agents의 역할 구분

• 몇 시간 뒤 hourly cron이 정상적으로 실행되면서 수집 흐름이 실제로 동작함을 확인한다 [32:53]
• Daily report job을 수동으로 trigger하자 Telegram에 실제 report가 도착했고, cron과 report agent의 역할 분리가 검증되었다 [33:08]

🧾 결론

• 이 강의의 핵심은 Cron을 단순 예약 기능이 아니라 Hermes Agent를 반복 업무 운영 시스템으로 바꾸는 실행 계층으로 설명한다는 점이다.
• gateway가 켜져 있어야 Cron이 발화하고, 작업은 fresh session에서 실행되므로 자동화의 신뢰성은 명확한 프롬프트와 안정적인 실행 환경에 달려 있다.
• 반복 알림, 상태 감시, 리포트 생성처럼 패턴이 분명한 작업은 no agent나 gate script로 비용을 줄이고, 판단이 필요한 순간에만 LLM을 쓰는 구조가 적합하다.
• context from은 파일 경로를 모델이 기억하거나 직접 읽게 만드는 방식보다 안정적인 handoff를 제공해, 여러 예약 작업을 느슨한 파이프라인으로 연결할 수 있게 한다.
• 검증 필요: 영상에서 언급된 “하루 약 1센트 안팎” 수준의 비용은 사용 모델, 실행 빈도, provider 가격, tool 사용량에 따라 달라질 수 있으므로 실제 운영 전 별도 산정이 필요하다.

📈 투자·시사 포인트

• 자동화 도입의 우선순위는 모델을 많이 쓰는 것이 아니라, deterministic script로 처리할 수 있는 감시·수집·필터링을 먼저 분리하는 데 있다.
• 운영 관점에서는 gateway uptime, Cron 상태 확인, 실패 알림, silent 출력 정책을 함께 설계해야 자동화가 조용히 실패하지 않는다.
• 조직이나 개인 워크플로에서는 daily briefing, 서비스 상태 점검, 버그 리포트 triage, 트래픽 요약처럼 반복성과 판단이 섞인 업무가 Cron 적용 후보가 된다.
• 비용 관리 측면에서는 저렴한 모델을 쓰는 profile, 제한된 tool set, wake agent 조건, no-agent collector를 조합하는 설계가 장기 운영에 중요하다.
• 검증 필요: 실제 업무에 적용할 때는 각 Cron 작업의 성공 기준, 전달 채널 권한, 데이터 소스 안정성, 실패 시 재시도 정책을 환경별로 확인해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 영상에서는 Cron이 gateway 안에서 동작하고 gateway가 꺼져 있으면 작업이 실행되지 않는다고 설명하지만, 실제 운영 환경에서 grace window가 어느 정도까지 missed run을 보정하는지는 별도 확인이 필요하다.
• silent 출력이 정상 상황의 알림을 억제하고 실패 시에는 실패 정보가 전달된다고 설명되지만, 각 전달 채널별로 실패 알림 형식이나 재시도 정책이 동일한지는 확인이 필요하다.
• no agent 모드와 wake agent gate가 모델 비용을 0으로 줄일 수 있다는 설명은 데모 기준으로 제시되며, 실제 비용 구조는 실행 환경, 스크립트 호출 비용, 인프라 비용, provider 설정에 따라 달라질 수 있다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Hermes Cron을 쓰기 전에 gateway가 실행 중인지 cron status로 확인하고, gateway 중단 시 예약 작업이 실행되지 않는다는 전제를 운영 문서에 반영한다.
• Cron 프롬프트는 fresh session 기준으로 작성하고, 서버명·IP·계정·검증 URL·성공 조건처럼 필요한 맥락을 명시한다.
• 단순 모니터링·heartbeat·disk/RAM alert처럼 판단이 필요 없는 작업은 no agent 모드로 분리해 모델 호출을 줄인다.
• 변화가 있을 때만 reasoning이 필요한 작업은 pre-run script와 wake agent true/false gate 구조로 설계한다.

❓ 열린 질문

• gateway가 장시간 중단된 뒤 재시작될 경우, 놓친 Cron 작업을 재실행할지 건너뛸지 사용자가 세밀하게 제어할 수 있는가?
• context from으로 전달되는 upstream output에는 크기 제한이나 보존 기간 제한이 있는가?
• 여러 upstream job을 fan-in할 때 output 순서, 실패한 upstream 처리, stale output 감지는 어떻게 동작하는가?