Anthropic이 Claude Code에 Routines를 넣었습니다. 한 번 설정한 프롬프트·저장소·커넥터를 일정, API 호출, GitHub 이벤트에 맞춰 Claude가 클라우드에서 자동 실행하는 기능입니다. 로컬 터미널이나 켜 둔 노트북에 의존하지 않는다는 점이 핵심입니다.12
겉으로 보면 "AI 크론 잡"처럼 보입니다. 하지만 진짜 질문은 자동화 가능 여부가 아닙니다. 이제는 어떤 종류의 일을 자동화할 가치가 생겼느냐입니다. 스크립트가 잘 못하던, 맥락을 읽고 우선순위를 정하고 애매한 입력을 정리하는 반복 업무가 새 후보군으로 올라왔기 때문입니다.
이건 스크립트 대체재가 아니라, 스크립트와 사람 사이의 빈칸을 메운다
확인된 사실부터 보죠. Claude Routines는 스케줄 기반 실행뿐 아니라 API 트리거, GitHub 웹훅 기반 실행도 지원합니다. 예시도 단순 배치 작업보다 "알림 내용을 읽고 담당 서비스를 찾은 뒤 온콜 채널에 첫 대응안을 올리기", "특정 모듈을 건드린 PR만 골라 요약을 공유하기"처럼 판단이 섞인 일들에 집중돼 있습니다.1
이게 중요한 이유는 전통적 자동화의 경계가 비교적 명확했기 때문입니다.
정해진 입력과 정해진 출력이면 스크립트가 제일 낫습니다.
앱 A에서 앱 B로 데이터 넘기는 배관 작업이면 Zapier나 n8n 같은 도구가 강합니다.
문제는 그 중간입니다. 사람이 매번 "이게 더 중요해 보여", "이건 요약해서 공유해야 해", "이번 변경은 문서도 손봐야겠네" 같은 가벼운 판단을 넣어야 하는 업무 말입니다.
Claude Routines의 실전 가치는 바로 여기 있습니다.
즉, 결정론적 자동화가 아니라 문맥형 자동화입니다.
그래서 판단 기준도 달라져야 합니다.
규칙이 명확하고 실패 허용도가 낮다: 스크립트
여러 SaaS를 연결하는 단순 전달이다: 노코드 자동화
매번 읽고, 분류하고, 요약하고, 우선순위를 정해야 한다: Claude Routine
AI를 붙였다고 다 고급 자동화가 되는 건 아닙니다. 오히려 너무 명확한 일에 AI를 쓰면 비용만 늘고 결과 예측 가능성은 떨어집니다.
첫 Routine은 '큰 일'보다 '지저분한 일'이어야 한다
Anthropic이 제시한 초기 활용 패턴도 비슷합니다. 이슈 트리아지, 문서 드리프트 탐지, 배포 검증, 알림 요약, 맞춤형 코드 리뷰 같은 작업들입니다.1 공통점은 중요하지만 귀찮고, 반복되지만 완전히 정형화되지는 않았다는 점입니다.
이게 첫 도입 포인트로 좋은 이유는 세 가지입니다.
첫째, ROI가 빨리 보입니다.
사람이 매일 20~40분씩 쓰는 분류·정리·초안 작성 업무를 줄여주기 때문입니다.
둘째, 실패해도 복구가 쉽습니다.
예를 들어 "주간 변경사항 요약"이 조금 아쉬우면 사람이 손보면 됩니다. 반면 프로덕션 DB를 직접 건드리는 자동화가 틀리면 비용이 훨씬 큽니다.
셋째, 팀의 실제 병목과 맞닿아 있습니다.
많은 조직에서 엔지니어링의 마찰은 코드를 못 짜서가 아니라, 상태 공유·핸드오프·백로그 정리·문서 갱신이 늘 늦어서 생깁니다.
반론도 있습니다. "이런 건 GitHub Actions나 기존 에이전트 플랫폼으로도 하던 일 아닌가?" 맞습니다. 실제로 그전에도 크론, VM, GitHub Actions, 별도 스케줄러를 조합해 비슷한 흐름을 만들 수 있었습니다.34 다만 이번 변화는 인프라 조립 비용을 Anthropic 쪽으로 밀어냈다는 데 있습니다. 팀 입장에선 자동화 실험의 진입장벽이 낮아졌습니다. 반대로 Anthropic 인프라와 사용량 정책에 더 묶이게 되는 트레이드오프도 생깁니다.
조용히 망가지는 Routine을 피하는 설계법
Routines는 연구 프리뷰이고, 플랜별 일일 실행 제한도 있습니다. Pro는 하루 5회, Max는 15회, Team/Enterprise는 25회입니다.1 이 수치만 봐도 "모든 걸 AI로 돌리는 플랫폼"이라기보다, 고가치 반복 작업을 선별해 쓰라는 신호에 가깝습니다.
또 하나 확인된 제약이 있습니다. 클라우드 루틴은 로컬 작업 디렉터리를 그대로 쓰는 게 아니라 저장소의 fresh clone 기준으로 동작합니다.5 즉, 당신 노트북의 임시 파일, 미커밋 상태, 로컬 툴체인을 전제로 짠 작업은 그대로 옮기기 어렵습니다.
그래서 설계 원칙은 꽤 보수적이어야 합니다.
프롬프트는 넓게 쓰지 말고 좁게 써야 합니다.
"버그를 알아서 처리해줘"보다 "새로운 P1 버그 3개만 읽고, 재현 가능성·영향도·담당 팀을 표 형식으로 정리"가 낫습니다.
성공 기준을 명시해야 합니다.
무엇을 읽고, 무엇을 산출하고, 어디까지 자동으로 하고, 어디서 사람 승인으로 넘길지 적어야 합니다.
실행 기록을 남겨야 합니다.
세션 URL, 결과 요약, 실패 사유가 남지 않으면 몇 주 뒤부터는 "뭘 했는지 모르지만 돌아가긴 도는" 자동화가 됩니다.
쓰기 권한은 늦게 열어야 합니다.
처음엔 요약·초안·제안만 하게 하고, 안정화된 뒤에 PR 생성이나 댓글 작성 권한을 주는 편이 안전합니다.
핵심은 프롬프트 엔지니어링보다 운영 설계입니다. 신뢰 가능한 Routine은 똑똑한 문장보다 감사 가능성과 실패 경로가 먼저 있어야 합니다.
결국 이 기능을 가장 먼저 진지하게 봐야 할 사람은 "개발자를 더 자동화하겠다"는 팀보다, 반복적인 조정 업무가 많은 팀입니다. 온콜, 플랫폼, 개발 생산성, 테크 리드, 작은 스타트업 운영팀이 특히 그렇습니다. 앞으로 주목할 포인트도 분명합니다. GitHub 외 이벤트 소스가 얼마나 늘어나는지, 실행 신뢰성이 얼마나 안정화되는지, 그리고 이 기능이 코딩 자체보다 팀의 조율 비용을 얼마나 줄이는지입니다. Claude Routines의 진짜 경쟁자는 다른 AI 에이전트라기보다, 사람이 매일 조금씩 태우고 있던 조직의 잡음일 수 있습니다.
참고
1Introducing routines in Claude Code
2Claude can now run tasks on its own! (Claude Routines)
3Claude Code routines promise mildly clever cron jobs
4Claude Code Routines: How to Run Scheduled AI Agents Without a Server
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.