AI에게 9시에 하라고 예약했는데 9시 반에 합니다 — 일부러 그렇게 만든 겁니다

예약 작업 · 알고 써야 할 것

9시에 시켰는데
9시 반에 돌 수 있습니다.

버그가 아니라 일부러 넣은 흔들림입니다. 그리고 반복 예약은 7일 뒤에 스스로 사라집니다. 둘 다 이유가 있는데, 모르면 당황합니다.

AI에게 "5분마다 배포 확인해줘" 같은 걸 시킬 수 있습니다. 저도 이 블로그 발행을 주기 반복으로 돌리고 있고요. 그런데 컨텍스트를 뜯어볼 때 "예약 작업은 유휴 중에도 전체 컨텍스트를 매번 실어 보낸다"는 한 줄을 각주로만 남겨뒀길래, 이번에 기능 문서를 통째로 열었습니다. 예상 못 한 규칙이 네 개 나왔습니다.

📌 30초 요약

• ⚠️ 반복 작업은 예정 시각보다 최대 30분 늦게 실행됩니다. 의도된 설계입니다.
• ⚠️ 반복 작업은 생성 7일 뒤 자동 소멸합니다. 마지막으로 한 번 뜨고 자기를 지웁니다.
• ⚠️ 놓친 실행은 보충되지 않습니다. 바쁜 동안 세 번을 지나쳤어도 한 번만 뜹니다.
• ⚠️ 새 대화를 시작하면 전부 지워집니다. 이어하기로 열면 만료 전인 것만 돌아옵니다.
• 정확한 시각이 필요하면 정각과 30분을 피하라고 문서가 직접 권합니다.
• 세션당 최대 50개, 그리고 환경변수 하나로 기능 전체를 끌 수 있습니다.

① 왜 일부러 늦게 실행하나

📄 문서가 밝힌 이유

"To avoid every session hitting the API at the same wall-clock moment, the scheduler adds a deterministic offset to fire times."

→ 전 세계 세션이 9시 정각에 동시에 몰리는 걸 막으려고 시각을 흩뜨립니다. "deterministic"이라는 단어가 중요한데, 오프셋이 작업 ID에서 계산되므로 같은 작업은 항상 같은 만큼 밀립니다. 매번 랜덤하게 흔들리는 게 아닙니다.

작업 종류	얼마나 흔들리나
반복 작업 (1시간 이상 주기)	예정 시각 이후 최대 30분
반복 작업 (1시간 미만 주기)	주기의 절반까지
일회성 (정각·30분에 예약한 경우)	최대 90초 일찍

반복은 늦게, 일회성은 일찍 — 방향이 반대입니다

첫 줄이 실무에서 제일 걸립니다. 매일 9시에 리포트를 만들라고 걸어두면 9시에서 9시 30분 사이 어딘가에 뜹니다. 30분 주기로 걸면 최대 15분까지 밀립니다.

✅ 문서가 알려준 회피법

일회성 작업의 90초 흔들림은 정각(:00)이나 30분(:30)에 예약할 때만 붙습니다. 그래서 정확한 시각이 필요하면 0 9 * * * 대신 3 9 * * *처럼 애매한 분을 고르라고 되어 있습니다. 3분이 손해처럼 보이지만 90초 앞당김이 사라집니다. 반복 작업의 30분 흔들림에는 적용되지 않는 요령입니다.

② 7일 뒤에 스스로 사라집니다

"Recurring tasks automatically expire 7 days after creation. The task fires one final time, then deletes itself. This bounds how long a forgotten loop can run."

→ 마지막 문장이 설계 의도입니다 — "잊힌 루프가 얼마나 오래 돌 수 있는지에 상한을 둔다." 켜두고 잊어버린 5분짜리 반복이 한 달 내내 토큰을 태우는 일을 막는 장치입니다.

이건 제한이자 보호입니다. 예약 작업은 유휴 상태에서도 전체 대화를 매번 실어 보냅니다. 즉 아무 일이 없어도 요청은 나갑니다. 잊고 방치하면 청구서에 그대로 쌓이니, 7일 상한은 오히려 고마운 쪽입니다.

더 오래 돌려야 한다면? 문서는 만료 전에 취소하고 다시 만들거나, 아예 세션에 묶이지 않는 방식(클라우드 예약, 데스크톱 예약, CI 스케줄)을 쓰라고 안내합니다. 다음 표가 그 선택지입니다.

③ 세 가지 방식 — 뭘 골라야 하나

항목	클라우드	데스크톱	세션 안에서
내 컴퓨터가 켜져 있어야 하나	아니오	예	예
세션이 열려 있어야 하나	아니오	아니오	예
내 파일에 접근되나	아니오(새로 받아옴)	예	예
권한 확인 창	없음(자율 실행)	작업별 설정	세션 설정 상속
최소 간격	1시간	1분	1분

공식 비교표를 옮긴 것 · 이 글이 다루는 건 세 번째 열입니다

클라우드 쪽 두 칸이 눈에 띕니다. 권한 확인 창이 없고(자율 실행), 내 로컬 파일에는 접근 못 합니다(저장소를 새로 받아옴). 에이전트 팀에서 권한이 전원에게 복제되던 것과 같은 계열의 판단이 필요한 지점입니다 — 사람이 안 보는 동안 무엇까지 허용할 것인가.

최소 간격도 다릅니다. 클라우드는 1시간이 최소라 5분 폴링 같은 건 안 됩니다. 짧게 자주 확인해야 하면 세션 안에서 돌리는 수밖에 없고, 그러면 터미널을 켜둬야 합니다.

④ 조용히 안 뜨는 경우들

• 터미널을 닫으면 안 뜹니다. 예약은 실행 중이고 한가할 때만 발동합니다.
• 놓친 건 보충 안 됩니다. 긴 작업 도중에 세 번이 지나갔어도 한가해질 때 한 번만 뜹니다.
• 새 대화를 시작하면 전부 사라집니다. 이어하기·계속하기로 열어야 만료 전인 것들이 돌아옵니다.
• 바쁠 때 온 예약은 기다립니다. 응답 도중에 끼어들지 않고 턴이 끝난 뒤에 실행됩니다.
• 저장 폴더가 심볼릭 링크면 예약 자체가 에러로 실패합니다.
• 클라우드 제공사(Bedrock·AWS·GCP·Foundry) 환경에서는 동작이 다릅니다 — 간격 없는 반복이 10분 고정이 됩니다.

세 번째가 제일 많이 당할 항목일 겁니다. 예약을 걸어두고 습관적으로 새 대화를 열면 그 순간 전부 없어집니다. 에러도 안 나고 안내도 없습니다 — 기록이 조용히 정리되거나 안 되던 것들과 같은 결입니다.

그리고 문서가 스스로 더 나은 방법을 권하는 대목이 있습니다. 상태를 계속 확인해야 하는 일이라면 같은 프롬프트를 반복해서 다시 던지는 것보다, 백그라운드로 돌려놓고 출력이 나올 때마다 받아보는 방식이 토큰 효율이 낫다고 되어 있습니다. 폴링을 아예 안 하게 되니까요.

# 예약 기능 자체를 끄고 싶을 때 (환경변수)
CLAUDE_CODE_DISABLE_CRON=1

# 이걸 켜면 예약 도구도, 반복 명령도 못 쓰고
# 이미 걸어둔 작업도 더 이상 안 뜹니다.

# 정확한 시각이 필요할 때 — 정각을 피하는 요령
0 9 * * *   # 매일 9시 정각 → 90초 일찍 뜰 수 있음
3 9 * * *   # 매일 9시 3분 → 그 흔들림이 안 붙음

자주 묻는 것

Q. 30분 밀리는 걸 직접 재보셨나요?

아닙니다. 실측하지 않았습니다. 이 글의 숫자는 전부 문서에 적힌 값입니다. 제가 지금 돌리는 발행 반복은 다른 경로(자기 재호출 방식)라 위 흔들림 규칙이 그대로 적용되는지도 확인 안 했습니다. 궁금하시면 실행 로그의 시각을 며칠 모아보세요 — 오프셋이 작업마다 고정이라니 같은 작업은 늘 비슷하게 밀릴 겁니다.

Q. 예약을 많이 걸면 비용이 얼마나 드나요?

계산하지 않았습니다. 다만 구조는 분명합니다 — 발동할 때마다 그 시점의 대화 전체가 실려 갑니다. 그러니 대화가 길수록, 주기가 짧을수록 커집니다. 세션당 50개까지 걸 수 있다는 점도 같이 보세요. 짧은 주기 여러 개는 위험한 조합입니다.

Q. 7일이 지나면 어떻게 되나요?

마지막으로 한 번 실행되고 스스로 삭제됩니다. 별도 알림에 대한 언급은 문서에서 못 봤습니다. 그러니 오래 돌릴 작업이라면 달력에 재생성 일정을 따로 적어두시거나, 애초에 세션에 묶이지 않는 방식으로 거는 게 맞습니다.

⏱️ 간격을 안 적으면 10분마다 도는 경로가 있습니다

이 글은 예약한 시각과 실제 실행 시각이 어긋나는 이유를 다뤘습니다. 그 위에 간격 자체가 달라지는 경우가 있습니다 — 공식 문서 각주에 따르면 클라우드 마켓플레이스를 거쳐 구매한 경로에서는 반복 실행이 스스로 간격을 정하지 못해, 간격 없이 준 프롬프트가 10분마다 실행됩니다. 하루 144번입니다. 구독으로 로그인해 쓸 때의 습관대로 간격을 비워두면 그날부터 계속 돕니다. 그 경로에서는 간격을 반드시 명시하세요. 구매 경로가 기능을 어디까지 깎는지는 요금제보다 구매 경로가 더 크게 갈리는 이유에 정리했습니다.

✨ 정리하면

예약 시각은 최대 30분 밀립니다. 세션이 한꺼번에 몰리는 걸 막으려는 의도된 흔들림이고, 같은 작업은 늘 같은 만큼 밀립니다.

반복 예약은 7일 뒤 스스로 사라집니다. 잊힌 루프가 계속 도는 걸 막는 상한이라 오히려 고마운 쪽입니다.

새 대화를 열면 예약이 전부 지워집니다. 정확한 시각이 필요하면 정각 대신 9시 3분처럼 걸고, 오래 돌릴 일이면 세션 밖으로 빼세요.

🧭 AI 지출 전체 그림

유휴 중에도 나가는 토큰은 4단계(쓰면서 새는 곳)에 해당합니다. 일곱 단계 지도는 여기입니다 → AI에 쓰는 돈 총정리 — 숨은 비용 7가지

🔗 같이 보면 좋은 글

• 컨텍스트의 92퍼센트는 화면에 안 보입니다 — 매번 실려 가는 그 덩어리
• AI 팀원 다섯 명을 붙이기 전에 — 사람이 안 볼 때의 권한
• 대화는 30일 뒤 지워지는데 프롬프트는 남습니다 — 예약 목록도 같은 폴더에
• 캐싱은 조용히 실패합니다 — 반복 요청이라면 같이 볼 것

---

확인 시점 — 2026년 8월 14일. ✅ 1차 확인 : Claude Code 공식 문서의 예약 작업 페이지 전문 — 세 가지 스케줄 방식 비교표(실행 위치·기기 전원·세션 필요 여부·로컬 파일 접근·권한 창·최소 간격) · 지터 규칙 세 항목과 그 사유 · 7일 만료 조항과 설계 의도 문장 · 스케줄러 동작(초 단위 확인, 턴 사이 발동, 로컬 시간대 해석) · 제한 목록 여섯 항목 · 세션당 50개 상한 · 비활성화 환경변수 · 크론 표현식 규칙 · 제공사별 동작 차이. 확인하지 않은 것 : 지터를 실제로 관측 · 7일 만료 시점의 알림 유무(문서에서 관련 언급을 못 봤습니다) · 예약 반복의 실제 토큰·비용 · 제가 돌리는 발행 반복(자기 재호출 경로)에 같은 지터 규칙이 적용되는지. 범위 한정 : 이 글은 세션 안에서 도는 예약이 대상이며, 클라우드·데스크톱 방식은 비교표 수준으로만 다뤘습니다. 실험적·버전 의존 항목이 섞여 있어 쓰시는 버전에 따라 다를 수 있습니다. 제휴·협찬 없습니다.