Hermes 자동화의 시간 모델

A guide to choosing the right time model in Hermes automation: cron for recurring work, kanban dispatcher for durable queued work, and delegate_task for synchronous burst work. Use it when deciding how an AI-agent task should persist, retry, or return.

사람은 자동화를 보통 “지금 해줘”라는 감각으로 부릅니다. 질문을 던지고, 답을 기다리고, 결과가 돌아오면 다음 판단을 합니다. 그러나 에이전트 시스템은 사람의 대화 시간과 다른 방식으로 움직입니다. 어떤 작업은 정해진 시간에 다시 깨어나야 하고, 어떤 작업은 상태를 보존한 채 며칠 동안 이어져야 하며, 어떤 작업은 지금 이 순간 여러 갈래로 나뉘었다가 곧바로 합쳐져야 합니다.

Hermes 자동화를 안정적으로 쓰려면 이 차이를 먼저 이해해야 합니다. 문제는 “에이전트가 할 수 있는가”가 아니라 “그 일이 어떤 시간 위에서 살아야 하는가”입니다. 반복되는 시간인가, 남아 있어야 하는 시간인가, 지금 병렬로 밀어붙이는 시간인가. 이 구분을 놓치면 좋은 기능도 엉뚱한 자리에 배치됩니다.

Hermes에는 이 차이를 다루는 대표적인 시간 모델이 있습니다. Cron은 예약과 반복의 시간입니다. Kanban dispatcher는 상태와 의존성이 보존되는 시간입니다. delegate_task는 한 세션 안에서 짧게 폭발하는 병렬 시간입니다. 세 기능은 모두 에이전트를 움직이지만, 유지되는 것과 사라지는 것이 다릅니다.

Cron: 정해진 때마다 새로 깨어나는 시간

Cron은 반복 실행을 위한 시간 모델입니다. 매일 아침 리포트를 만들거나, 두 시간마다 피드를 확인하거나, 매주 특정 작업의 상태를 점검하는 식의 일을 맡기기 좋습니다. Hermes Cron 작업은 schedule, prompt, skills, delivery, script, workdir 같은 실행 조건을 묶어 둘 수 있습니다.

Cron의 핵심은 반복입니다. 하지만 반복된다고 해서 같은 대화가 계속 이어지는 것은 아닙니다. Cron 실행은 보통 새 세션처럼 시작된다고 보는 편이 안전합니다. 그래서 prompt는 self-contained해야 합니다. “지난번처럼 처리해줘”가 아니라, 무엇을 보고, 어떤 기준으로 판단하고, 어디까지 처리하고, 결과를 어떻게 보고할지 매번 독립적으로 읽혀야 합니다.

Cron은 사람에게 질문할 수 없는 시간에도 실행됩니다. 이 점은 아주 중요합니다. 사람이 자고 있거나 다른 일을 하고 있을 때도 돌아가야 하므로, 애매한 상황의 기본 행동이 미리 정해져 있어야 합니다. 입력이 없으면 조용히 종료할지, 실패 보고를 남길지, 위험한 정보가 보이면 중단할지 같은 규칙이 prompt 안에 있어야 합니다.

또 하나의 특징은 delivery입니다. Cron은 결과를 자동으로 돌려보내는 일과 잘 맞습니다. 변화가 있을 때만 알림을 보내는 watchdog, 매일 일정한 형식으로 요약을 보내는 briefing, 새 항목을 모아 정리하는 digest처럼, 사람이 직접 호출하지 않아도 결과가 도착해야 하는 작업에 적합합니다.

따라서 Cron을 선택해야 하는 질문은 단순합니다. 이 작업이 반복되어야 하는가. 사람이 매번 부르지 않아도 정해진 리듬으로 실행되어야 하는가. 실행 결과가 정해진 형식으로 배달되어야 하는가. 그렇다면 Cron이 맞습니다.

Kanban dispatcher: 일이 남아 있는 시간

반면 어떤 작업은 반복보다 지속성이 중요합니다. 한 번에 끝나지 않고, 여러 단계와 담당자를 거치며, 중간에 막히거나 재시도될 수 있습니다. 이런 작업은 “다시 실행”보다 “상태를 잃지 않는 것”이 중요합니다. Hermes의 Kanban dispatcher는 이런 시간을 다룹니다.

Kanban dispatcher는 durable work queue입니다. 작업은 카드처럼 남고, assignee가 정해지고, parent-child dependency를 가질 수 있습니다. 어떤 작업이 끝나야 다음 작업이 ready 상태가 되고, 작업자가 실행 중 문제를 만나면 block 상태로 남길 수 있습니다. 끝난 작업은 complete로 결과와 metadata를 남기고, 실패하거나 시간이 초과된 작업은 다시 시도되거나 사람이 개입할 수 있는 상태로 보존됩니다.

이 시간 모델의 핵심은 “기억”이 아니라 “상태”입니다. 대화가 끝나도 작업이 사라지지 않습니다. 다음 작업자는 이전 작업의 summary와 metadata를 읽고 이어받을 수 있습니다. 오래 걸리는 조사, 여러 명의 전문 작업자가 필요한 발행 파이프라인, 검토와 수정이 분리되어야 하는 콘텐츠 작업, build와 publish 검증이 필요한 운영 작업은 Kanban 쪽이 더 안전합니다.

Kanban dispatcher를 Cron처럼 쓰면 답답해집니다. 정해진 시간마다 같은 일을 반복하는 장치가 아니라, 남아 있는 일을 적절한 작업자에게 넘기고 상태를 보존하는 장치이기 때문입니다. 반대로 장기 프로젝트를 단순 대화나 짧은 delegation으로만 처리하면, 중간 상태와 재시도 근거가 흩어집니다.

Kanban을 선택해야 하는 질문은 이렇습니다. 이 작업은 한 번의 세션을 넘어 살아남아야 하는가. 누가 무엇을 했는지, 무엇이 막혔는지, 다음 작업이 무엇인지 보존되어야 하는가. 의존성과 완료 조건이 중요한가. 그렇다면 Kanban dispatcher가 맞습니다.

delegate_task: 지금 병렬로 터뜨리는 시간

delegate_task는 또 다른 시간입니다. 이것은 오래 남는 queue가 아니라, 현재 세션 안에서 짧게 병렬 사고를 펼치는 방식입니다. 여러 하위 조사, 두 개의 대안 비교, 독립적인 파일 검토, 초안 방향 제안처럼 “지금 동시에 해보면 좋은 일”에 적합합니다.

장점은 빠른 병렬성입니다. 부모 세션은 여러 subagent에게 독립적인 목표와 맥락을 주고, 각각의 요약을 받아 다시 합칠 수 있습니다. 긴 도구 출력이나 세부 탐색을 부모 세션에 모두 쌓지 않아도 되므로, 복잡한 작업을 정리하는 데 유용합니다.

하지만 delegate_task는 durable하지 않습니다. 부모 세션이 중단되면 하위 작업도 함께 사라질 수 있고, 장기적으로 상태를 보존하거나 재시도를 보장하는 용도로 설계된 기능이 아닙니다. 하위 agent가 외부 side effect를 수행했다면, 부모가 직접 검증해야 합니다. 파일이 실제로 쓰였는지, URL이 열리는지, 빌드가 통과했는지는 요약만 믿지 말고 다시 확인해야 합니다.

그래서 delegate_task를 선택해야 하는 상황은 분명합니다. 지금 이 세션 안에서 병렬로 사고를 넓히고, 곧바로 결과를 합쳐야 하는가. 하위 작업이 오래 살아남을 필요는 없는가. durable queue보다 빠른 분산 검토가 중요한가. 그렇다면 delegate_task가 맞습니다.

세 시간 모델을 고르는 법

세 기능은 서로의 대체재가 아닙니다. 같은 에이전트 자동화라도 시간 모델이 다르면 운영 방식이 달라집니다.

선택 기준을 더 짧게 말하면 이렇습니다. 반복되면 Cron입니다. 남아 있어야 하면 Kanban입니다. 지금 나눠서 생각하고 바로 합치면 delegate_task입니다.

이 구분은 작은 차이처럼 보이지만 실제 운영에서는 큰 차이를 만듭니다. 반복 리포트를 Kanban에만 올려 두면 사람이 dispatcher를 기다려야 합니다. 며칠 걸리는 발행 프로젝트를 delegate_task만으로 밀면 중간 상태가 사라집니다. 단순 병렬 검토를 Kanban 카드로 지나치게 쪼개면 오히려 관리 비용이 커집니다.

익명 사례: 발행 자동화에서 시간이 어긋날 때

한 공개 글 파이프라인을 생각해볼 수 있습니다. 처음에는 에이전트에게 “글을 고치고 발행해줘”라고 맡기면 충분해 보입니다. 하지만 실제로는 시간이 여러 층으로 나뉩니다. 초안 방향을 비교하는 일은 지금 병렬로 빠르게 처리할 수 있습니다. 원문 재작성, 메타데이터 정리, 빌드, 검증, publish는 상태가 남아야 하는 단계입니다. 그리고 정기적으로 새 글감을 점검하거나 발행 후보를 모으는 일은 반복 실행에 가깝습니다.

이 세 시간을 구분하지 않으면 문제가 생깁니다. 짧은 병렬 검토에 장기 queue를 쓰면 느려지고, 장기 발행 작업을 단발 delegation으로 처리하면 검증 상태가 흐려집니다. 정기 점검을 사람이 매번 직접 부르면 자동화의 리듬이 무너집니다.

더 나은 설계는 역할을 나누는 것입니다. Cron은 주기적으로 후보를 모으거나 상태를 알립니다. Kanban dispatcher는 실제 발행 작업을 단계별로 보존합니다. delegate_task는 특정 순간에 여러 방향을 빠르게 비교하는 데 씁니다. 이렇게 나누면 에이전트는 더 많은 일을 하는 것이 아니라, 각 일이 살아야 할 시간 위에 놓이게 됩니다.

자동화는 속도가 아니라 시간 구조다

Hermes를 쓸 때 “이 기능으로 할 수 있는가”만 묻는 것은 충분하지 않습니다. 더 중요한 질문은 “이 일은 어떤 시간 모델을 필요로 하는가”입니다.

반복되어야 하는 일은 Cron으로 리듬을 얻습니다. 오래 남아야 하는 일은 Kanban dispatcher로 상태를 얻습니다. 지금 넓게 검토해야 하는 일은 delegate_task로 병렬성을 얻습니다. 이 셋을 구분하면 자동화는 단순히 빠른 실행이 아니라, 사람의 작업 리듬과 기계의 실행 리듬을 연결하는 운영 구조가 됩니다.

기계는 인간과 다른 시간으로 작동합니다. Hermes 자동화의 목표는 그 차이를 숨기는 것이 아닙니다. 오히려 반복, 지속, 순간 병렬성이라는 서로 다른 시간을 드러내고, 각각에 맞는 자리를 주는 것입니다. 좋은 자동화는 사람 대신 시간을 쓰는 기술이 아니라, 일이 살아 있어야 할 시간을 정확히 배치하는 기술입니다.