Skip to content
푸땡로그
Go back

Claude Code Routines 살펴보기: 로컬 CLI를 떠나 클라우드에서 반복 작업을 자동화하는 방식

Claude Code를 쓰다 보면 매번 같은 순서로 하는 작업이 생깁니다. 아침마다 이슈 큐를 훑고, PR이 열리면 체크리스트를 돌리고, 배포 후 스모크 테스트를 확인합니다.

이런 작업은 사람이 매번 하기엔 번거롭습니다. GitHub Actions 스크립트로 짜기엔 상황을 보고 판단해야 하는 부분이 많습니다.

2026년 4월 14일 Anthropic이 공개한 Claude Code Routines는 이런 작업을 자동화합니다. 로컬 CLI에서 직접 프롬프트를 입력하지 않습니다. 스케줄·API·GitHub 이벤트를 트리거로 삼아 클라우드에서 Claude가 반복 작업을 실행합니다.

이 글은 Routines의 구조와 세 가지 트리거의 쓰임을 정리합니다. 같은 제품군의 Ultra Plan, Channels와 어떻게 다른지도 비교합니다.


Claude Code Routines는 무엇인가요?

Routines는 Claude Code 내부의 자동화 단위입니다. 매 실행마다 새로운 세션이 만들어지고, 사용자의 노트북이 꺼져 있어도 Anthropic 관리 클라우드에서 작업이 계속됩니다.

하나의 루틴은 네 가지 요소로 구성됩니다.

인터페이스는 세 가지입니다. 웹은 claude.ai/code/routines에서 생성·관리하고, 데스크톱 앱은 Schedule 탭의 “New remote task”로 생성하며, CLI에서는 스케줄 기반 루틴에 한해 /schedule 명령어를 지원합니다.

참고 Routines는 Research Preview 단계입니다. 기능·API·가격 모델이 변경될 수 있으니, 프로덕션 파이프라인에 넣기 전에 공식 문서를 확인하세요.

동작 흐름

트리거가 루틴을 깨우면 Claude가 저장소와 커넥터에 접근해 작업을 수행합니다. 결과는 PR이나 외부 채널로 내보냅니다.

flowchart TD
    S[Schedule] --> R[Routine]
    A[API Endpoint] --> R
    G[GitHub Event] --> R
    R --> E{실행 환경<br/>Anthropic Cloud}
    E --> Repo[Repository<br/>claude/ branch]
    E --> MCP[Connectors<br/>Slack · Linear · Drive]
    Repo --> PR[Draft PR / 커밋]
    MCP --> Notify[메시지 / 이슈 업데이트]

루틴은 로컬이 아니라 Anthropic이 관리하는 클라우드에서 실행됩니다. 사용자는 세션을 열어둘 필요가 없고, 승인 프롬프트도 뜨지 않습니다. 권한은 루틴에 연결한 저장소·커넥터·환경 변수의 조합으로 결정됩니다.


세 가지 Trigger

트리거는 세 가지이며, 각각 다른 상황에 맞습니다.

Schedule

시간 기반 실행입니다. 사전 설정으로 Hourly, Daily, Weekdays, Weekly가 제공되고, /schedule update로 크론 표현식을 직접 지정할 수도 있습니다. 최소 주기는 1시간입니다.

Bash
# CLI에서 스케줄 루틴 업데이트
/schedule update

타임존은 로컬 기준으로 입력하면 자동 변환됩니다. 실제 실행은 몇 분 지연될 수 있어서, 초 단위의 정밀한 타이밍이 필요한 작업에는 적합하지 않습니다.

주로 “매일 아침 백로그 정리”, “주간 문서 동기화”처럼 주기적으로 같은 루틴을 돌리는 시나리오에 맞습니다.

API

전용 HTTP POST 엔드포인트가 루틴마다 하나씩 발급됩니다. Bearer 토큰 기반 인증이고, 요청 본문에 선택적 text 필드로 런타임 컨텍스트를 전달할 수 있습니다.

Bash
curl -X POST https://api.claude.com/routines/<routine-id>/runs \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"text": "[alert] checkout 500 error rate spike"}'

응답은 세션 ID와 URL을 담은 JSON입니다. 모니터링 도구나 배포 파이프라인처럼 외부 시스템이 직접 Claude를 깨워야 하는 상황을 겨냥합니다.

주의 Bearer 토큰은 생성 직후 한 번만 표시됩니다. 안전한 시크릿 매니저에 즉시 저장하고, 노출되면 바로 재발급하세요.

GitHub Event

Claude GitHub App을 설치한 저장소의 이벤트를 트리거로 삼습니다. 지원 이벤트는 Pull Request(opened, closed, assigned, labeled, synchronized 등)와 Release(created, published, edited, deleted)입니다.

필터 조건으로 Author, Title, Body, Base branch, Head branch, Labels, Is draft, Is merged, From fork 등을 조합할 수 있습니다. 예를 들어 “fork에서 온 non-draft PR만”, “특정 라벨이 붙은 머지된 PR만”처럼 조건을 좁힙니다.

Research Preview 기간에는 루틴별·계정별 시간당 한도가 있고, 한도를 넘은 이벤트는 드롭됩니다. 트래픽이 많은 공개 저장소라면 한도를 먼저 확인한 뒤 연결합니다.


실전 유스케이스

공식 문서와 커뮤니티 사례에 나온 쓰임은 다음과 같습니다.

Backlog Maintenance

주중 저녁에 한 번씩 도는 스케줄 루틴을 만듭니다. Linear 커넥터로 이슈 트래커를 읽고, 코드 영역에 따라 자동으로 라벨을 붙이고 담당자를 지정한 뒤, Slack에 요약을 포스팅합니다. 팀이 다음 날 아침 정리된 큐로 하루를 시작할 수 있습니다.

Alert Triage

모니터링 도구가 에러 임계값을 넘으면 API 트리거로 루틴을 깨웁니다. 스택 트레이스를 추출해 최근 커밋과 연관시키고, 제안 수정안을 담은 draft PR을 열어둡니다. 온콜 엔지니어가 빈 터미널이 아니라 검토할 수 있는 PR로 일을 시작합니다.

Custom Code Review

pull_request.opened 이벤트를 트리거로 걸고, 팀의 리뷰 체크리스트를 프롬프트에 담아둡니다. 보안·성능·스타일에 대한 인라인 코멘트를 남기고 요약 코멘트를 추가합니다. 사람 리뷰어는 기계적 검사 대신 설계 검토에 집중할 수 있습니다.

Deployment Validation

배포 파이프라인이 API로 루틴을 호출합니다. 스모크 테스트를 실행하고 에러 로그에서 회귀가 있는지 스캔한 뒤, 릴리스 채널에 go/no-go 판정을 남깁니다. 배포 윈도우 종료 전에 결정에 필요한 근거가 팀 앞에 놓입니다.

Tip 루틴을 처음 설계한다면 "사람이 매번 같은 순서로 하고 있는 작업"부터 뽑습니다. 판단이 필요하지만 입력 재료가 일정한 작업이 Routines에 맞습니다.

Claude Code 제품군에서의 위치

Routines만 보면 “클라우드용 크론”처럼 보입니다. 같은 제품군의 다른 기능과 비교하면 각 기능이 맡는 문제가 다릅니다.

기능겨냥하는 문제실행 위치전형적 쓰임새
Ultra Plan큰 작업 전 계획 분리클라우드 plan session리팩터링·설계 초안 만들기
Channels외부 이벤트 → 실행 중 세션로컬 세션Telegram/Discord로 세션에 푸시
Routines반복 작업의 클라우드 실행Anthropic 클라우드스케줄·API·GitHub 이벤트 자동화

Channels는 이미 열려 있는 로컬 세션에 외부 신호를 들여보냅니다. Routines는 세션 자체를 클라우드에서 새로 만듭니다. 그래서 Routines는 사용자의 노트북이 꺼져 있어도 실행됩니다.

Ultra Plan은 계획 단계를 맡습니다. Ultra Plan으로 계획을 만들고, 그 계획을 Routines로 주기적으로 실행하는 조합도 가능합니다.


GitHub Actions와는 무엇이 다를까

GitHub Actions와 Routines는 실행 방식이 많이 겹치지만, 맞는 작업의 성격이 다릅니다.

항목GitHub ActionsClaude Code Routines
실행 방식고정된 스크립트AI 판단 기반 맥락 처리
트리거저장소 이벤트 중심Schedule · API · GitHub
결정 방식결정적적응형
주 용도CI/CD 파이프라인판단이 필요한 개발 작업

Actions는 “빌드·테스트·배포”처럼 단계가 고정된 기계적 작업에 강합니다. Routines는 “이슈 라벨링·코드 리뷰·배포 검증”처럼 매 실행마다 상황을 보고 다르게 판단해야 하는 작업에 더 잘 맞습니다.

실무에서는 둘을 함께 씁니다. Actions가 신호를 올리면 Routines가 상황을 읽고 반응합니다.


플랜과 실행 한도

Routines를 쓰려면 Pro 이상 플랜과 Claude Code on the web 활성화가 필요합니다. 일일 실행 한도는 플랜마다 다릅니다.

플랜일일 실행 한도
Pro5 routines/day
Max15 routines/day
Team/Enterprise25 routines/day

사용량은 일반 세션과 같은 구독 사용량에서 차감됩니다. 초과 사용은 Extra usage가 활성화된 경우에만 종량제로 계산됩니다.

이 한도가 루틴을 얼마나 자주 돌릴 수 있는지 정합니다. Pro 플랜에서 매시간 도는 스케줄 루틴을 만들면 하루 한도를 금방 소진합니다. 설계 단계에서 플랜 한도에 맞춰 주기와 빈도를 정합니다.


주의사항

도입 전에 다음 세 가지를 확인합니다.

벤더 락인 우려

Anthropic 관리 클라우드에서 실행하면 실행 환경 자체를 벤더에 맡깁니다. 커뮤니티에서도 이 부분에 대한 우려가 나옵니다. Hacker News 토론에서는 “제공자가 아니라 플랫폼을 택하게 된다”는 지적이 자주 등장합니다.

대안으로 두 가지가 거론됩니다. 프롬프트와 저장소 접근 로직을 MCP 커넥터·Agent SDK 쪽으로 분리해 두거나, 핵심 루틴을 GitHub Actions + Claude API 조합으로 복제해 둡니다.

실행 횟수 제한

앞서 본 플랜별 일일 한도가 실제 설계에 영향을 줍니다. “이 루틴을 매시간 돌릴 것인가, 매일 한 번만 돌릴 것인가”는 기능의 가치뿐 아니라 구독 사용량 예산 관점에서도 결정해야 합니다.

Idempotency

같은 트리거가 여러 번 발생하면 루틴이 중복 실행될 수 있습니다. 예를 들어 “PR이 열릴 때마다 댓글을 남기는” 루틴은 synchronized 이벤트에서 의도치 않게 여러 번 돌 수 있습니다. 부작용이 있는 루틴이라면 프롬프트 안에 “이미 처리했는지 확인” 단계를 명시하거나, 필터링 조건을 좁게 잡습니다.

주의 Research Preview 단계에서는 GitHub 이벤트 트리거에 루틴별·계정별 시간당 한도가 있습니다. 초과분은 드롭되므로, 고트래픽 저장소나 크리티컬한 자동화에는 아직 적합하지 않습니다.

마무리

Claude Code Routines는 프롬프트·저장소·커넥터를 묶어 클라우드에서 Claude가 반복 작업을 처리하게 하는 자동화 단위입니다. 트리거별 용도는 다음과 같습니다.

Research Preview 단계라서 한도와 기능이 바뀔 수 있습니다. 매일 같은 순서로 반복하는 작업이 있다면 그중 하나를 Routines로 옮겨 시험해 봅니다.

관련 글


참고 자료


Share this post on:

Previous Post
A11Y 주간 다이제스트 2026.04.06 ~ 04.12: ADA Title II 마감 준비, 제9순회항소법원 판결
Next Post
Karpathy의 LLM-Wiki: LLM이 직접 쓰고 관리하는 개인 지식 위키