한줄 요약
Claude Code Routines는 반복 작업을 클라우드에서 무인 실행하는 자동화 단위로, 야간 코드 리뷰·알림 트리아지·배포 검증에 실전 투입 가능하다.
어떤 상황에서 필요한가?
에이전시나 팀 개발 환경에서 반복적으로 마주치는 상황이 있다. PR이 올라올 때마다 누군가 보안 체크리스트를 돌리고, 매일 아침 이슈 트래커 정리를 손으로 하고, 배포 직후 에러 로그를 사람이 뒤지는 일들. 이런 작업들은 자동화 대상이 분명하지만, 기존 CI/CD 파이프라인으로 처리하기엔 판단 로직이 복잡하다.
Claude Code Routines는 이 지점을 노린다. "프롬프트 + 저장소 + 커넥터"를 한 묶음으로 저장해두고, 세 가지 방식으로 실행 트리거를 건다. 스케줄(매일 밤, 매주 등), API 엔드포인트 호출, GitHub 이벤트 반응. 실행 환경은 Anthropic 클라우드 인프라라서 로컬 머신 상태와 무관하게 돌아간다.
특히 에이전시 실무에서 체감 효과가 큰 케이스는 세 가지다.
야간 코드 리뷰 자동화. GitHub 트리거를 pull_request.opened에 걸어두면 PR이 생성될 때마다 팀 고유의 리뷰 체크리스트를 자동 적용하고, 보안·성능·스타일 이슈에 인라인 코멘트를 남긴다. 사람 리뷰어는 기계적 검사 대신 설계 결정에 집중할 수 있다.
알림 트리아지. 모니터링 툴이 에러 임계치를 넘으면 루틴의 API 엔드포인트를 호출한다. 스택 트레이스를 받아서 최근 커밋과 상관관계를 분석하고, 수정 제안이 담긴 드래프트 PR까지 만들어준다. 온콜 담당자가 빈 터미널에서 시작하는 대신 PR 검토로 바로 들어갈 수 있다.
배포 검증. CD 파이프라인이 프로덕션 배포 후 API 트리거를 호출하면, 루틴이 스모크 테스트를 실행하고 에러 로그에서 회귀를 스캔해 릴리스 채널에 go/no-go를 포스팅한다.
핵심 구현 방법
루틴 생성은 웹 UI(claude.ai/code/routines), CLI(/schedule), 데스크톱 앱 세 경로 모두 가능하고 동일한 클라우드 계정에 저장된다.
트리거 설정 방식별 차이를 알아두자.
스케줄 트리거는 웹과 CLI 모두 설정 가능하다. 기본 프리셋은 hourly, daily, weekdays, weekly이고, 커스텀 cron 표현식은 CLI에서 /schedule update로 설정한다. 최소 간격은 1시간이다.
API 트리거는 웹에서만 생성·토큰 관리가 가능하다. 엔드포인트에 POST 요청을 보낼 때 text 필드로 알림 본문이나 로그를 함께 넘길 수 있다. 응답으로 세션 ID와 URL이 돌아오고, URL을 열면 실시간으로 실행 과정을 확인할 수 있다.
GitHub 트리거도 웹 UI 전용이다. Pull Request(opened, closed, labeled 등)와 Release 이벤트를 지원하고, 필터 조건을 조합해 트리거 범위를 좁힌다. 예를 들어 "base branch가 main이고 head branch에 auth-provider가 포함된 PR"처럼 구체적으로 걸 수 있다. 필터의 matches regex 연산자는 전체 필드값 매칭이라 부분 문자열을 잡으려면 .*hotfix.* 식으로 앞뒤에 .*를 붙여야 한다.
브랜치 권한 기본값에 주의. 루틴은 기본적으로 claude/ 접두사 브랜치에만 푸시 가능하다. 보호 브랜치 오염을 막기 위한 안전장치다. 필요하다면 루틴 편집 화면에서 저장소별로 제한을 해제할 수 있다.
커넥터는 루틴 생성 시 현재 연결된 모든 커넥터가 기본 포함된다. 루틴이 실제로 필요한 것만 남기고 나머지는 제거하는 게 원칙이다. 루틴이 수행하는 커밋, PR, Slack 메시지, Linear 티켓 등의 액션은 모두 루틴 소유자의 계정 권한으로 실행된다는 점도 기억해야 한다.
실전에서 주의할 점
루틴은 개인 claude.ai 계정 단위로 귀속된다. 팀원과 공유되지 않고, 계정의 일일 실행 한도를 소진한다. 인터랙티브 세션과 동일한 방식으로 구독 사용량을 차감하므로, 고빈도 트리거를 여러 개 묶어두면 예상보다 빠르게 한도에 닿을 수 있다.
루틴 실행 중에는 승인 프롬프트가 없다. 완전 자율 실행이다. 따라서 루틴에 포함할 저장소, 환경, 커넥터 범위를 처음부터 필요한 것으로 좁혀두는 설계가 중요하다. "일단 다 넣고 나중에 정리"하는 방식은 루틴에서 특히 위험하다.
멀티 루틴 운영 시 같은 저장소에 여러 루틴이 동시에 반응하는 상황을 설계 단계에서 고려해야 한다. GitHub 트리거는 매칭 이벤트마다 독립 세션을 생성하므로, 필터 조건이 겹치면 중복 코멘트나 충돌 PR이 생길 수 있다.
도구 자체가 아직 experimental-cc-routine-2026-04-01 베타 헤더를 요구하는 상태다. 프로덕션 크리티컬 워크플로우에 투입하기 전에 별도 저장소나 테스트 환경에서 충분히 검증하는 게 맞다.
