블로그 · 가이드 · 2026년 10월 28일

AEGIS로 예약 에이전트 실행하기: 스케줄, 실행, 그리고 실패할 때 보이는 것

다른 언어: English, Español, Português, 日本語, Deutsch, Français, 简体中文, Italiano, हिन्दी · 한국어 가이드 전체

공개: AEGIS는 100monkeys.ai가 만들고 있으므로 이 가이드는 만든 쪽의 설명으로 읽어 주세요. 이 가이드는 저희 AI 에이전트 하나가 공개 AEGIS 문서(영어), 주로 Schedules 페이지와 Schedule Tools 레퍼런스를 바탕으로 초안을 쓰고 회사가 검토했으며, 이 한국어판은 영어 원문 가이드의 번역입니다. 아래의 모든 필드, 경로, 메시지는 그 페이지들에서 인용했고, 인용은 영어 원문 옆에 번역을 붙였습니다. 이 가이드를 위해 이 호출들을 실행하지 않았으며, 문서가 단계를 열어 둔 곳에서는 그렇다고 밝힙니다.

AEGIS by 100monkeys.ai, in beta는 자율 에이전트를 격리되고 정책이 강제되는 런타임에서 실행하는 자체 호스팅 오케스트레이터입니다. 이 가이드는 여러분의 에이전트 하나를 타이머에 걸고, 각 실행이 무엇을 했는지 다시 읽고, 하나의 실행이 가질 수 있는 네 가지 결과를 보여 줍니다. 그래서 일어나지 않은 실행도 일어난 실행만큼 잘 보입니다.

스케줄이란 무엇인가

문서는 한 문장으로 정의합니다. "A schedule starts one of your agents or workflows as you, either once at a time you choose or again and again on a recurrence."(스케줄은 여러분의 에이전트나 워크플로 하나를 여러분으로서 시작합니다. 여러분이 고른 시각에 한 번, 또는 반복 규칙에 따라 계속해서.) 여기서 세 가지 결과가 나오며, 각각이 아래 단계를 결정합니다.

스케줄은 여러분 자신의 객체이며, "never a field of the agent or workflow it runs"(그것이 실행하는 에이전트나 워크플로의 필드가 아닙니다).
사람으로서 실행됩니다. "A schedule always runs as a person. A service account, or an operator acting for no person, cannot make, change, pause, resume, run or delete one."(스케줄은 언제나 사람으로서 실행됩니다. 서비스 계정이나, 어떤 사람도 대신하지 않는 운영자는 스케줄을 만들거나, 바꾸거나, 일시 중지하거나, 재개하거나, 실행하거나, 삭제할 수 없습니다.)
각 실행은 평범한 실행입니다. "At each fire the orchestrator starts the run exactly as aegis.task.execute or aegis.workflow.run would for you, with the schedule's intent, input and connections."(실행 시점마다 오케스트레이터는 aegis.task.execute나 aegis.workflow.run이 여러분을 위해 하는 것과 똑같이, 스케줄의 intent, 입력, 연결로 실행을 시작합니다.)

1단계. 에이전트와 시간 고르기

aegis task execute <AGENT>로 이미 한 번 직접 실행해 본 에이전트를 쓰세요. 그래야 좋은 실행이 어떤 모습인지 압니다.

그다음 두 가지 시간 방식 중 하나를 고르세요. 정확히 하나만 줍니다.

한 번: at, "at least one minute from now and at most a year ahead"(지금부터 최소 1분 뒤, 최대 1년 앞)인 RFC 3339 시각.
반복: cron, timezone, jitter_seconds가 있는 recurrence. cron에는 다섯 필드(분, 시, 일, 월, 요일)가 있고, "no seconds field and no @daily-style shorthand"(초 필드도, @daily 같은 약칭도 없습니다). 시간대는 IANA 이름이며 기본값은 UTC입니다. jitter는 각 실행을 그 초 수까지의 무작위 시간만큼 늦추며, 최대 3600입니다.

계획할 때 고려할 두 가지 한도: "A schedule runs at most once every 5 minutes"(스케줄은 최대 5분에 한 번 실행됩니다), 그리고 삭제되지 않은 스케줄은 최대 25개까지 가질 수 있습니다.

2단계. 실행이 닿을 수 있는 곳 고르기

예약 실행은 그 profile이나 contexts가 지정한 연결에만 닿으며, "a schedule with neither reaches none of your connections."(둘 다 없는 스케줄은 여러분의 어떤 연결에도 닿지 않습니다.) 스케줄은 둘 중 하나만 가지며, 둘 다 가지지는 않습니다. 에이전트가 메일이나 저장소를 읽는다면 지금 profile을 지정하세요. 그렇지 않으면 연결이 없어서 실행이 거부되고, 거부 메시지가 그렇게 말합니다.

3단계. 스케줄 만들기

CLI Reference에는 aegis schedule 셸 명령이 없습니다. 스케줄은 REST 경로 POST /v1/schedules(범위 schedule:write), MCP 도구 aegis.schedule.create, 또는 Zaru의 Schedules 페이지에서 만듭니다. 도구는 레퍼런스가 나열하는 대로 다음 인수를 받습니다.

aegis.schedule.create {
  "name": "Morning inbox triage",
  "target_kind": "workflow",
  "target": "email-inbox-triage",
  "intent": "Sort the new mail",
  "input": { "mailbox": "ann@example.com" },
  "recurrence": { "cron": "*/30 * * * *", "timezone": "UTC", "jitter_seconds": 300 }
}

이 예시는 문서 자체의 스케줄입니다. target_kind를 agent로, target을 여러분 에이전트의 이름으로 바꾸세요. 답은 state, next_run_at, last_run이 담긴 {"schedule": {...}}입니다. 자리를 뜨기 전에 next_run_at을 다시 읽으세요.

4단계. 지금 한 번 실행하기

작동하는지 알기 위해 첫 예약 시각을 기다리지 마세요. 소유자는 POST /v1/schedules/{id}/run이나 aegis.schedule.run_now로 실행 하나를 바로 시작할 수 있습니다. 그것은 "exactly as a fire starts it: as the owner, with the schedule's target, input, connections or profile, and attachments"(예약 실행이 시작하는 것과 똑같이, 소유자로서, 스케줄의 대상, 입력, 연결 또는 profile, 첨부와 함께) 실행되고, "nothing else changes"(다른 것은 아무것도 바뀌지 않습니다). 스케줄은 상태와 시간을 그대로 유지합니다.

5단계. 실행 기록 읽기

aegis.schedule.runs { "schedule_id": "<id>", "limit": 20 }

경로는 GET /v1/schedules/{id}/runs?limit=입니다. 실행은 최신순으로 오며, 각각 scheduled_time(지금 시작한 실행이면 null), fired_at, outcome, detail, execution(그 id, kind, status)을 가집니다. 실행 자체를 읽으려면 실행 ID를 CLI로 가져가세요. aegis task logs <EXECUTION_ID>, 실패만 보고 싶으면 --errors-only를 붙입니다.

6단계. 네 가지 결과 알기

모든 실행은 예약 시각마다 한 번 기록되므로, Temporal이 반복하는 실행은 "answers the first fire's record instead of starting a second run"(두 번째 실행을 시작하지 않고 첫 실행의 기록으로 답합니다). 각 기록에는 결과가 하나 있습니다.

started: 실행이 시작되었고, 그 실행 ID가 기록됩니다.
skipped_overlap: "The run the previous fire started is still running, so this fire starts nothing."(이전 실행이 시작한 작업이 아직 돌고 있으므로, 이번에는 아무것도 시작하지 않습니다.) Zaru는 이를 "Skipped: the last run was still running"(건너뜀: 마지막 실행이 아직 진행 중이었습니다)으로 보여 줍니다.
skipped_paused: 스케줄이 일시 중지되어 있습니다.
refused: "The run could not start. The fire records the refusal's sentence, for example a required connection that was not chosen."(실행을 시작할 수 없었습니다. 거부 문장이 기록됩니다. 예를 들어 필요한 연결이 선택되지 않은 경우입니다.)

started 결과는 실행이 시작되었다는 뜻이지, 성공했다는 뜻이 아닙니다. 실행 자체의 상태는 execution.status에 있고, 실패한 이유는 그 로그에 있습니다.

7단계. 실행이 계속 실패하면 어떻게 되는지 알기

"When the last three fires of a recurring schedule were all refused, the schedule pauses itself, with the reason 'Paused after three runs could not start: <the last refusal>.'"(반복 스케줄의 마지막 세 실행이 모두 거부되면, 스케줄은 'Paused after three runs could not start: <마지막 거부>.'라는 이유와 함께 스스로 일시 중지합니다.) 스케줄의 paused_reason을 읽고, 원인을 고친 다음, aegis.schedule.resume으로 재개하세요. 오케스트레이터가 재시작하는 동안 놓친 실행은 "is still made up to 10 minutes late; later than that, the time is skipped."(최대 10분 늦게까지는 여전히 실행되고, 그보다 늦으면 그 시각은 건너뜁니다.)

8단계. 승인은 여전히 적용됩니다

예약 실행은 여러분으로서 행동하므로, "so every tool call that waits for your approval in a conversation waits for it in a scheduled run too"(대화에서 여러분의 승인을 기다리는 모든 도구 호출은 예약 실행에서도 그것을 기다립니다). Zaru에서는 그 요청이 Approvals 페이지에 "From your schedule <name>"(여러분의 스케줄 <name>에서)으로 나열됩니다.

문서가 열어 둔 것

셸 명령. CLI Reference에는 schedule 하위 명령이 없으므로, 자체 호스팅 사용자는 REST 경로나 MCP 클라이언트를 씁니다.
로컬 스택에서 "여러분"이 누구인지. 스케줄은 사람으로서 실행되고 schedule:write가 필요한데, aegis init 스택은 IAM 없이 실행됩니다. 문서는 거기서 스케줄의 소유가 어떻게 되는지 말하지 않으며, 저희도 시험하지 않았습니다.

예약 에이전트와 그것이 보내는 모든 것 사이에 사람을 두려면 오케스트레이터에 승인 단계를 주는 방법을 읽으세요. 실행이 무엇을 했는지 읽으려면 AEGIS 실행 로그 읽기를 읽으세요.

100monkeys.ai에서 AEGIS 설치하기