요약: Anthropic은 Claude Fable 5 발표와 함께 Claude Managed Agents에 scheduled deployments와 vault environment variable credentials 지원을 추가했습니다. 이 기능은 “에이전트를 cron처럼 실행한다”는 점에서 매력적이지만, 운영 기준 없이 붙이면 실패 알림, 중복 실행, secret 관리, 비용 추적이 빠르게 꼬입니다. 실무에서는 스케줄보다 runbook이 먼저입니다.
AI 에이전트는 대화형 작업에만 쓰이지 않습니다. 매일 아침 리포트를 만들고, 새 이슈를 분류하고, 고객 피드백을 요약하고, 문서 변경을 감시하고, 보안 로그에서 이상 패턴을 찾는 작업은 주기 실행에 잘 맞습니다.
Anthropic Platform release notes의 2026년 6월 9일 항목에는 Claude Managed Agents가 scheduled deployments를 지원한다고 나옵니다. 별도 scheduler를 직접 운영하지 않고 cron schedule로 세션을 실행할 수 있다는 의미입니다. 같은 릴리스에서 vault가 environment variable credentials를 지원해, 에이전트 sandbox 안에 CLI와 SDK용 secret을 주입할 수 있게 됐습니다.
이 두 기능은 같이 봐야 합니다. scheduled deployment는 자동 실행을 만들고, vault credential은 자동 실행이 실제 시스템에 접근할 수 있게 만듭니다. 즉 편해지는 만큼 사고 표면도 넓어집니다.
전통적인 cron은 결정적입니다. 스크립트가 같은 입력을 받으면 대부분 같은 출력을 냅니다. 에이전트는 다릅니다. 모델 응답, tool 선택, 외부 API 상태, 검색 결과, 문서 변경에 따라 실행 경로가 달라집니다.
그래서 에이전트 scheduled deployment에는 일반 cron보다 더 많은 안전장치가 필요합니다. 같은 시간에 두 번 실행되면 중복 글을 발행할 수 있습니다. 외부 API가 느리면 timeout 뒤에도 일부 작업이 완료됐을 수 있습니다. 모델이 불확실한 판단을 했는데 자동으로 쓰기 작업을 하면 복구가 어렵습니다.
자동 실행 대상은 먼저 읽기 중심 작업으로 시작하는 편이 안전합니다. 요약, 분류, 후보 생성, 리포트 작성은 좋습니다. 이메일 발송, 결제 변경, 운영 DB 수정, 고객 알림은 사람 승인 단계를 두는 것이 낫습니다.
vault environment variable credentials는 CLI와 SDK가 익숙한 방식으로 인증할 수 있게 해 줍니다. 예를 들어 GITHUB_TOKEN, SLACK_BOT_TOKEN, DATABASE_URL, AWS_ROLE_ARN 같은 값이 sandbox에 주입될 수 있습니다.
문제는 범위입니다. scheduled agent가 매일 실행된다면 secret은 사실상 자동화 시스템의 권한입니다. 개인 계정 토큰을 넣거나, production 전체 권한이 있는 key를 넣는 것은 위험합니다. 작업별 최소 권한 secret을 따로 만들어야 합니다.
예를 들어 GitHub 이슈 분류 에이전트에는 repository issue read/write 권한만 있으면 됩니다. production deploy 권한이 필요 없습니다. Slack 리포트 에이전트에는 특정 채널 메시지 전송 권한만 주고, 사용자 DM이나 채널 관리 권한은 빼야 합니다.
scheduled deployment에서 가장 먼저 설계할 것은 “실패했을 때 무엇을 남길 것인가”입니다. 실행 ID, 시작 시각, 종료 시각, 입력 스냅샷, 사용한 모델, tool call 목록, 최종 상태를 저장해야 합니다. 이 정보가 없으면 재시도해도 되는지 판단할 수 없습니다.
중복 방지도 중요합니다. 매일 09:00 리포트라면 날짜 기준 idempotency key를 둡니다. 같은 key로 이미 성공한 실행이 있으면 새 실행은 중단합니다. 일부만 성공한 경우에는 단계별 상태가 필요합니다. 예를 들어 “초안 생성 완료, 게시 실패”와 “게시 완료, 알림 실패”는 재시도 방식이 다릅니다.
외부 API 쓰기 작업은 두 단계로 나누는 편이 좋습니다. 먼저 draft를 만들고 검증합니다. 그 다음 publish를 실행합니다. publish 전에 제목 prefix, placeholder, 링크 유효성, 금지어, 길이 같은 정적 검사를 통과해야 합니다.
에이전트 cron은 조용히 비용을 쓸 수 있습니다. 실패한 작업이 긴 컨텍스트를 계속 재시도하면 하루 비용이 예상보다 커집니다. therefore 실행마다 input token, output token, tool 비용, retry 횟수를 기록해야 합니다.
관측성은 비용뿐 아니라 품질에도 필요합니다. 어제는 좋은 리포트를 만들었는데 오늘은 빈약한 결과를 냈다면 입력 데이터가 부족했는지, 검색이 실패했는지, 모델 refusal이 있었는지, timeout이 있었는지 봐야 합니다. scheduled deployments를 쓰더라도 별도의 작업 로그 저장소와 알림 채널은 필요합니다.
알림은 성공보다 실패에 집중합니다. 매번 성공 메시지를 길게 보내면 사람들이 무시합니다. 대신 실패, 부분 성공, 품질 검사 실패, 비용 임계치 초과, 중복 실행 감지만 강하게 알리는 편이 낫습니다.
