Claude Code Routines란? 2026년에 언제 쓰고, 언제 `/loop`·Desktop scheduled tasks·GitHub Actions를 써야 하나

Claude Code에는 이제 네 가지 자동화 surface가 있다. 여기서 먼저 결정해야 하는 것은 trigger syntax가 아니라 runtime ownership이다. Routines는 cloud 쪽 가지다. 노트북을 닫은 뒤에도 Anthropic-managed clone 안에서 workflow를 계속 실행할 수 있다. Desktop scheduled tasks는 로컬 머신에 남고, /loop는 현재 session 안에 남고, GitHub Actions는 CI에 남는다.

이 주제는 launch 소식처럼 보기보다 ownership으로 보면 훨씬 단순해진다. 노트북을 닫은 뒤에도 계속 돌아가야 하고 cloud clone 안에서 성립하는 workflow라면 Routines가 맞다. 로컬 files, 로컬 apps, 로컬 browser에 의존하면 Desktop scheduled tasks가 맞다. 지금 열려 있는 Claude Code session 안에서 짧은 반복만 있으면 /loop가 맞다. repo policy, build, audit logs를 포함한 CI-native automation이라면 GitHub Actions가 맞다. 일이 머신, live session, CI에 속해 있다면 반복 작업이어도 Routines는 올바른 owner가 아니다.

Anthropic은 2026년 4월 14일에 Routines를 research preview로 공개했다. 중요한 것은 새롭다는 사실보다 현재 contract가 아직 꽤 좁다는 점이다. Routines는 이미 schedule, API, GitHub triggers를 지원하지만 CLI의 /schedule은 scheduled routine만 만든다. 그리고 API trigger는 일반 Anthropic API key가 아니라 per-routine bearer token으로 인증된다.

“

검증 메모: 이 글은 Anthropic의 현재 routines docs, scheduled tasks docs, /fire docs를 2026년 4월 16일 기준으로 확인한 내용에 기반한다. daily caps, beta header, preview status는 날짜가 붙은 사실로 읽어야 한다.

가장 빠른 판단법

prompt나 cron을 생각하기 전에, 이 workflow를 어느 runtime owner에게 맡길지 먼저 결정한다.

이 표가 먼저 나와야 한다. 여기서 가장 큰 실수는 설정 방법을 모르는 것이 아니라, workflow를 잘못된 owner에게 넘기는 것이다.

Routines가 실제로 가지는 것

automation이라는 말만 보면 네 surface의 차이가 trigger 차이처럼 보이기 쉽다. 실제 차이는 더 앞에 있다. 실행 위치와 ownership이 다르다. Anthropic의 current docs에서 routine은 prompt, 하나 이상의 repository, connectors, 환경 설정을 저장해 두고 Anthropic-managed cloud infrastructure에서 자동으로 깨우는 Claude Code workflow에 가깝다.

여기서 몇 가지 현실적인 결과가 나온다. 첫째, routine은 지금 이 Mac에서 열어 둔 Claude Code session의 원격판이 아니다. Anthropic의 current docs는 run마다 repository를 새로 clone하고, 보통 default branch에서 시작하며, 외부 시스템 action도 연결된 claude.ai account의 사용자로 보인다고 설명한다. 즉 Routines는 remote control이 아니라 별도의 cloud execution surface다.

둘째, Routines는 많은 local Claude Code workflows보다 더 정리된 실행 환경을 가지지만 동시에 경계도 더 분명하다. Anthropic은 cloud environments로 network access, environment variables, setup scripts를 다룬다. 그래서 자리를 비운 뒤에도 계속 돌아가야 하는 작업에는 맞다. 반대로 local browser profile, desktop software, mounted drive, machine-specific credential path가 핵심이면 맞지 않는다.

셋째, Routines는 기본적으로 무제한 unattended shell이 아니다. Anthropic은 현재 repository에서 unrestricted pushes를 따로 켜지 않으면 push를 claude/ prefix branch로 제한한다. 이 경계는 사소한 detail이 아니라, Routines가 bounded cloud automation surface로 설계되었다는 신호다.

언제 Routines가 잘 맞는가

Routines가 설득력을 갖는 순간은 “노트북을 계속 켜 둔다”가 더 이상 acceptable하지 않을 때다. 예를 들어 아침마다 하나의 repository를 살펴 stale issues를 보고, 새 PR을 훑고, 다음 action을 정리하는 workflow. 또는 docs drift를 정기적으로 확인하는 일, backlog triage, GitHub event로 시작되는 cloud-side repo work. 이런 작업의 공통점은 prompt가 복잡하다는 것이 아니라 cloud persistence 자체가 가치라는 점이다.

Anthropic의 launch materials에 나오는 예시도 이쪽이다. issue triage, research, recurring repo work. Routines를 고르는 이유는 “가장 유연한 automation surface”이기 때문이 아니다. open session이나 local machine보다 bounded cloud session이 owner가 되는 편이 workflow에 더 잘 맞기 때문이다.

다른 중요한 fit은 외부 시스템이 remote로 workflow를 깨워야 하는 경우다. 여기서 useful 한 mental model은 “코드에서 Claude를 호출한다”가 아니라 “이미 정해진 cloud workflow를 작은 payload로 깨운다”이다. 이 관점은 surface를 더 좁게 보이게 하지만, 안정적인 workflow에는 오히려 더 깨끗하다.

동시에 negative case도 계속 보여야 한다. Routines는 every recurring job의 default answer가 아니다. workflow가 live Claude Code session 안에 있어야 의미가 있거나, machine-bound라면 cloud surface를 하나 더 늘려도 constraint는 해결되지 않는다.

Desktop scheduled tasks, /loop, GitHub Actions가 더 나은 경우

Routines를 선택하지 않는 판단이 오히려 더 자주 정답이다. 그래서 나머지 세 route도 같은 무게로 다뤄야 한다.

Desktop scheduled tasks: machine-bound work는 machine에 남긴다

workflow가 local files, local applications, local browser profile에 의존한다면 trigger를 고민하기 전에 route choice는 거의 끝난다. job은 machine에 남겨야 한다. Desktop scheduled tasks의 가치는 routine의 cloud clone이 볼 수 없는 local state를 그대로 쓸 수 있다는 데 있다.

여기에는 또 하나의 practical boundary가 있다. sub-hour local cadence다. 로컬 의존성이 있고 한 시간보다 촘촘한 local scheduling이 필요하면, Desktop scheduled tasks가 훨씬 자연스럽다.

/loop: live session용 surface이지 cloud persistence용 surface가 아니다

/loop가 Routines보다 가벼운 이유는 책임 범위가 더 작기 때문이다. Anthropic의 current scheduled tasks docs는 이것을 session-scoped scheduling으로 설명한다. 분 단위로 돌릴 수 있지만 recurring loops는 7일 뒤 만료된다. 그래서 open session 안의 watch-work나 polling에는 아주 잘 맞는다.

자주 생기는 오해는 “/loop와 Routines는 같은 것의 구형/신형 버전”이라고 생각하는 것이다. 그렇지 않다. /loop는 open session이 owner인 채로 충분한 작업을 위한 route다. Routines는 open session이 owner면 곤란하기 때문에 의미가 있다.

실제 문제가 unattended automation이 아니라 긴 local coding session 안의 approval friction이라면, 더 가까운 sibling은 Claude Code Auto Mode다. Auto Mode는 local workflow의 approval behavior를 바꾸고, Routines는 workflow가 어디서 실행되는지를 바꾼다.

GitHub Actions: CI-owned automation은 CI에 둔다

GitHub Actions는 오래된 fallback이 아니라 지금도 강한 sibling route다. workflow가 repository policy, build, test gates, scheduled CI maintenance, audit-friendly logs에 속한다면 GitHub Actions contract가 더 깔끔하다. logs도 permissions도 repo-native한 자리에 남는다.

Routines도 GitHub event로 깨울 수 있지만, 그렇다고 “더 좋은 GitHub Actions”가 되는 것은 아니다. 올바른 질문은 repo event가 단지 wake-up signal인지, 아니면 workflow 자체가 CI-owned인지다. 후자라면 GitHub Actions를 그대로 두는 편이 맞다.

반대로 cloud branch로 가지 않고 local route에 남는다고 결정했다면, 다음 문제는 scheduling보다 tool access인 경우가 많다. 그럴 때는 Claude Code용 추천 MCP Servers가 더 실무적인 다음 단계가 된다.

현재 경계: preview, auth, 실행 빈도

Routines는 이미 사용할 수 있는 surface지만 current contract는 여전히 route choice를 바꾼다. Anthropic의 launch materials 기준으로 2026년 4월 16일 현재 included routine runs는 Pro 5/day, Max 15/day, Team 또는 Enterprise 25/day다. 또 routine runs는 interactive Claude Code sessions와 같은 subscription usage pool을 쓴다. headline로 만들 필요는 없지만, 어떤 workload를 먼저 routines에 넘길지에는 직접적인 영향을 준다.

auth model도 그만큼 중요하다. Anthropic의 current /fire docs는 API trigger가 per-routine bearer token과 anthropic-beta: experimental-cc-routine-2026-04-01 header를 쓴다고 분명히 적고 있다. 즉 이것은 일반 Anthropic API key integration의 변형이 아니라 Claude Code Routines product surface의 일부다.

trigger configuration에도 경계가 있다. Routines는 schedule, API, GitHub triggers를 지원하고 하나의 routine에 여러 trigger를 섞을 수 있다. 하지만 CLI는 surface 전체보다 좁다. claude --schedule은 scheduled routine만 만들고, API와 GitHub triggers는 web editor에서 설정한다. 이런 사실은 route choice 뒤에 나와야지 first screen의 주어가 되어서는 안 된다.

또 하나의 중요한 boundary는 cloud routines의 최소 간격이 한 시간이라는 점이다. minute-level polling이 필요하면 Routines는 그 순간 route에서 밀린다. 그 영역은 /loop, local path, 또는 CI다.

plan과 usage의 더 넓은 맥락이 필요하면 Claude Code 가격 가이드로 가는 편이 낫다. 이 페이지에서 중요한 것은 preview caps와 shared usage pool이 owner choice를 어떻게 바꾸는지다.

첫 routine은 무엇으로 시작하는 게 안전한가

가장 좋은 첫 routine은 약간 지루할수록 좋다. 가치가 있는지 빨리 확인할 수 있을 만큼 narrow해야 하고, 틀려도 cleanup work가 크게 생기지 않을 만큼 bounded해야 한다.

안전한 첫 형태로는 아침 single-repo triage가 이해하기 쉽다.

1. repository는 하나만 둔다.
2. 첫날에는 schedule trigger만 쓰고 API와 GitHub trigger를 한꺼번에 올리지 않는다.
3. stale issues, open PR, failing checks를 살펴보고 짧은 summary나 branch-scoped draft action list를 반환하게 한다.
4. push는 기본 branch boundaries 안에 두고 처음부터 write power를 넓히지 않는다.

이 시작점이 좋은 이유는 Routines가 정말 증명해야 할 것만 증명하기 때문이다. 즉, 자리를 비운 뒤에도 cloud persistence가 유용한 repo work를 계속 밀 수 있는가다. local machine에 의존하지 않고, CI가 사라져야 한다는 척도 하지 않는다.

반대로 나쁜 첫 routine의 패턴도 비슷하다. repository가 너무 많고, trigger가 너무 많고, write power가 너무 크고, automation이니까 한 surface로 몰아야 한다고 믿는다. 먼저 bounded workflow 하나로 surface가 스스로를 증명하게 하는 편이 훨씬 안전하다.

FAQ

Routines는 /schedule이나 scheduled tasks와 같은 것인가?

같지 않다. Routines는 지금의 더 넓은 surface 이름이고, 그 안에 schedule, API, GitHub triggers가 들어간다. CLI의 --schedule은 그중 scheduled routine만 만든다.

Desktop scheduled tasks를 골라야 하는 때는 언제인가?

local files, local apps, local browser, 또는 machine-bound state가 필요할 때다. sub-hour local cadence가 필요한 경우도 여기에 속한다. 의존성이 machine에 있으면 owner도 machine인 편이 자연스럽다.

/loop면 충분한 때는 언제인가?

현재 Claude Code session이 owner인 채로 충분하고, 짧은 반복만 필요할 때다. /loop는 분 단위로 돌릴 수 있지만 session-scoped이고 recurring loops는 7일 뒤 만료된다.

Routines가 GitHub Actions를 대체하나?

대체하지 않는다. workflow가 CI, repo policy, build automation, pipeline logs에 속한다면 GitHub Actions가 더 자연스럽다. Routines는 sibling route다.

routine API trigger는 어떻게 인증되나?

Anthropic의 current docs에 따르면 routine API trigger는 per-routine bearer token과 anthropic-beta: experimental-cc-routine-2026-04-01 header를 사용한다. 일반 Anthropic API key flow와 같지 않다.

현재 daily routine-run limits는 얼마인가?

2026년 4월 16일 기준 Anthropic launch materials에는 Pro 5/day, Max 15/day, Team 또는 Enterprise 25/day로 적혀 있다. preview facts로, 날짜와 함께 읽어야 한다.

결국 물어야 할 것은 runtime을 누구에게 맡길 것인가다

Routines가 중요한 이유는 Claude Code에 “더 대단한 scheduler”가 생겼기 때문이 아니다. Anthropic이 cloud-persistent automation이라는 route를 따로 떼어냈기 때문이다. workflow를 cloud clone에 남겨 두고 계속 밀어야 한다면 이것은 분명 의미 있는 새 선택지다.

하지만 모든 recurring workflow의 답이 되지는 않는다. 일이 local machine에 속하면 local route, open session에 속하면 /loop, CI에 속하면 GitHub Actions가 더 자연스럽다. 이렇게 보면 Routines는 범용 scheduler가 아니라 Claude Code automation stack 안에서 경계가 분명한 하나의 가지로 보이기 시작한다.