claude code 루틴 한 줄 요약
짧은 답변: claude code 루틴은 PR(pull request, 코드 변경 검토 요청) 리뷰·배포 검증·이슈 분류처럼 AI 판단이 필요한 일을 스케줄, API(서비스끼리 주고받는 HTTP 호출), GitHub 이벤트로 돌리는 자동화예요. 훅은 Claude Code 세션 안에서 도는 가드레일이고, GitHub Actions는 GitHub의 CI/CD 자동화라서 역할이 달라요. Pro는 하루 5회라서 핵심 루틴 1~3개만 고르고, 나머지는 Actions와 훅에 맡기는 쪽이 현실적이더라고요.
결론부터. Claude Code 루틴은 “노트북 닫아도 AI가 알아서 일한다”는 말 때문에 혹하기 쉬운데, 아무 작업이나 맡기면 바로 피곤해져요. 특히 Pro 하루 5회 한도에서는 루틴을 많이 만드는 사람이 이기는 게 아니라, 자주 반복되고 판단 비용이 큰 일만 고르는 사람이 이겨요.
처음엔 PR 리뷰 요약 하나면 충분해요. 아침마다 열린 PR을 훑고, 위험 파일을 표시하고, 사람 리뷰어가 볼 포인트를 줄이는 정도. 이 정도만 잘 돌아도 10분은 아끼거든요. Claude Code 자체가 아직 낯설면 먼저 Claude Code 사용법: 설치부터 첫 실행까지 5분 가이드를 보고 CLI(터미널 명령어 환경) 로그인부터 잡아두세요.
근데 루틴은 만능 자동화가 아니에요. 스케줄·API·GitHub 트리거는 편하지만, 실행은 클라우드에서 돌아가고 계정 한도도 같이 써요. 이 글을 읽으면 루틴, 훅, GitHub Actions를 어디에 나눠야 하는지 보이고, 첫 루틴을 만들 때 GitHub App 설치·웹훅 상한·text 필드 같은 함정을 먼저 피할 수 있어요.
루틴이 훅·GitHub Actions랑 뭐가 다른가
루틴은 Claude Code 클라우드 세션을 외부 이벤트로 깨우는 기능이에요. 훅은 세션 안에서 특정 시점에 도는 자동 명령이고, GitHub Actions는 빌드·테스트처럼 고정된 절차를 돌릴 때 더 잘 맞아요.
근데 왜 굳이 셋을 나눠야 할까요? 같은 “자동화”라고 묶으면 처음 세팅부터 꼬이거든요.
| 구분 | 도는 위치 | 트리거 | 잘 맞는 일 | 피해야 할 일 |
|---|---|---|---|---|
| Routines | Anthropic 클라우드 | 스케줄, API, GitHub 이벤트 | PR 리뷰 요약, 이슈 분류, 배포 후 검증 | 자동 머지, 대형 리팩터링 |
| Hooks | 내 Claude Code 세션 | 파일 편집, 명령 실행, 세션 시작 같은 내부 이벤트 | 포맷팅, 위험 명령 차단, 테스트 강제 | 노트북 꺼진 뒤 작업 |
| GitHub Actions | GitHub 인프라 | push, pull_request, release 같은 Git 이벤트 | 빌드, 테스트, 린트, 배포 | 애매한 코드 판단 |
루틴을 만들 수 있는 환경
Claude 공식 문서 기준으로 루틴은 웹, Desktop 앱, CLI에서 만들 수 있어요. 단, CLI의 /schedule은 스케줄 루틴만 만들고, API나 GitHub 트리거는 웹에서 편집해야 해요. Desktop 앱에서 New remote task를 고르면 루틴 쪽이고, New local task는 내 컴퓨터에서 도는 예약 작업이라 성격이 달라요.
쓸 수 있는 환경도 헷갈리기 쉬워요.
| 환경 | 루틴과의 관계 | 메모 |
|---|---|---|
| CLI | /schedule로 스케줄 루틴 생성 |
스크립팅은 CLI가 제일 편해요 |
| Web | claude.ai/code/routines에서 전체 관리 |
API·GitHub 트리거 편집은 여기서 |
| Desktop App | New remote task로 클라우드 작업 시작 |
로컬 예약 작업과 이름이 비슷해서 주의 |
| VS Code / Cursor | Claude Code를 에디터 안에서 쓰는 환경 | 루틴 관리보다는 코드 작업에 가까워요 |
| JetBrains | IntelliJ, PyCharm, WebStorm 쪽 플러그인 | diff 보기와 선택 영역 공유에 강해요 |
| Mobile | iOS·Android 앱에서 클라우드 작업 시작·모니터링 | 긴 작업 체크용으로 좋아요 |
| Chrome extension beta | 로그인된 브라우저 조작 | 웹 앱 테스트에 가까운 쪽 |
| Slack | @Claude 멘션으로 웹 세션 생성 |
팀 채팅에서 버그 수정 요청할 때 편해요 |
| GitHub Actions / GitLab CI/CD | CI 파이프라인에서 Claude 실행 | 고정 자동화는 여기가 더 예측 가능해요 |
| Agent SDK | Python·TypeScript로 에이전트 직접 제작 | 제품 안에 Claude Code급 기능을 넣을 때 |
세션 안에서 파일 편집 후 테스트를 강제하고 싶으면 루틴 말고 Claude Code Hooks 완벽 가이드 – 자동화 훅 설정법을 먼저 보세요. 반대로 노트북을 닫아도 아침 9시에 PR 요약이 와야 한다면 루틴 쪽이에요.
첫 루틴 30분 세팅: claude code routines 사용법
첫 루틴은 스케줄 트리거로 잡는 게 제일 덜 위험해요. GitHub 웹훅부터 붙이면 권한, 필터, 이벤트 상한까지 한 번에 봐야 해서 처음부터 삽질 폭이 커져요.
첫날부터 배포 자동 승인 루틴은 무리예요. 일일 PR 리뷰 요약부터 가세요.
먼저 Claude Code CLI에서 세션을 열어요. 설치가 안 됐다면 앞에서 링크한 설치 글부터 처리하세요.
# Claude Code 세션 안에서 입력
/schedule daily PR review at 9am
그러면 Claude가 저장소, 실행할 프롬프트, 스케줄을 차례로 물어봐요. 프롬프트는 길게 쓰지 말고 성공 조건을 박아두는 게 좋아요.
매일 오전 9시에 열린 PR을 훑어줘.
목표는 사람 리뷰어가 먼저 볼 위험 포인트를 줄이는 거야.
해야 할 일:
- draft PR은 제외
- 테스트 파일만 바뀐 PR은 낮은 우선순위
- 인증, 결제, 권한 관련 파일은 높은 우선순위
- 결과는 PR별 3줄 요약으로 작성
- 코드 변경은 하지 말고 리뷰 메모만 남겨
예상 흐름은 이렇게 잡으면 돼요.
# 예상 응답 형태, 실제 문구로 교체 필요
Routine created: daily-pr-review
Trigger: daily at 09:00 Asia/Seoul
Repository: owner/example-app
Next run: 2026-04-17 09:00
저장 후에는 웹에서 한 번 더 봐야 해요. claude.ai/code/routines로 들어가서 루틴 카드에 저장소, 트리거, 다음 실행 시간이 맞는지 체크하세요. 공식 문서에 따르면 루틴은 개인 claude.ai 계정에 붙고, 팀원에게 공유되지 않아요. 그래서 팀에서 쓰더라도 “공용 루틴 하나”가 아니라 “각자 계정의 루틴”으로 봐야 해요.
PR 리뷰 루틴이 잘 돌면 다음엔 세션 내부 가드레일을 붙일 차례예요. 코드 편집 뒤 테스트 강제 같은 건 Claude Code Hooks 완벽 가이드 – 자동화 훅 설정법이 더 맞아요.
GitHub 트리거가 안 오면 이 3가지부터 보세요
GitHub 트리거 문제는 대부분 권한 착각, 이벤트 필터 착각, 웹훅 상한 착각에서 나와요. 특히 /web-setup을 했다고 GitHub App 설치까지 끝난 건 아니에요.
커뮤니티에서도 이 세 지점에서 제일 많이 막혀요.
체크 순서는 이렇게 가면 돼요.
github.com/settings/installations에서 Claude GitHub App이 해당 저장소에 설치됐는지 본다- 루틴 편집 화면에서 GitHub event가
pull_request인지release인지 본다 - PR 필터가 너무 좁지 않은지 본다.
contains와matches regex를 섞으면 자주 틀려요 - draft PR 제외, base branch, label 조건을 하나씩 끄면서 테스트한다
- 루틴 목록 화면에서 시간당 웹훅 상한을 본다. research preview 기간에는 초과 이벤트가 버려질 수 있어요
공식 문서에 따르면 /web-setup은 저장소를 클론하고 push할 수 있는 권한을 연결해요. 근데 GitHub 트리거로 웹훅을 받으려면 Claude GitHub App 설치가 따로 필요해요. 여기서 많이 속더라고요.
이벤트도 제한이 있어요. 2026년 4월 16일 기준 공식 문서는 GitHub 트리거에서 pull request와 release 계열 이벤트를 안내하고 있어요. 모든 GitHub 이벤트를 다 받는다고 생각하면 안 돼요.
# GitHub 트리거 테스트용 PR 제목 예시
routine-test: trigger daily review
# 필터 예시
base branch equals main
title contains routine-test
is draft equals false
저장소 연결 자체가 처음이면 Claude Code 사용법: 설치부터 첫 실행까지 5분 가이드 쪽으로 돌아가세요. GitHub 인증이 꼬인 상태에서 루틴만 계속 만지면 시간만 녹아요.
Pro 5회 한도에서 먼저 만들 claude code 자동화 5개
Pro 하루 5회면 적어요. 근데 잘 고르면 충분히 쓸 만해요. 루틴은 “많이”가 아니라 “반복 판단 비용이 큰 것”에 써야 하거든요.
그럼 5개를 어디에 써야 할까요? 제 기준은 사람 시간이 아깝고, 실패해도 사람이 회수할 수 있는 작업이에요.
| 우선순위 | 루틴 | 트리거 | 결과 위치 | 왜 먼저인가 |
|---|---|---|---|---|
| 1 | 일일 PR 리뷰 요약 | 스케줄 | PR 코멘트 또는 Slack | 매일 반복되고 판단이 필요해요 |
| 2 | 배포 후 스모크 테스트 | API | Slack 또는 릴리스 채널 | 온콜 피로가 바로 줄어요 |
| 3 | 신규 이슈 트리아지 | GitHub | 이슈 라벨·요약 | 사람이 분류하던 일을 줄여요 |
| 4 | 주간 보안 체크 리포트 | 스케줄 | 문서 또는 채널 | 자동 머지 없이도 가치가 있어요 |
| 5 | 릴리스 노트 초안 | release 이벤트 | draft 문서 | 사람이 마지막 문장만 손보면 돼요 |
가격과 한도도 같이 봐야 해요. 2026년 4월 16일 공식 가격 페이지와 루틴 발표 기준이에요. 세금은 별도고, 가격은 바뀔 수 있어요.
| 플랜 | 공식 가격 기준 | 루틴 일일 한도 | 메모 |
|---|---|---|---|
| Pro | 연간 결제 월 $17, 월간 결제 $20 | 5회 | 개인 실험·가벼운 자동화 |
| Max 5x | 월 $100 | 15회 | 매일 여러 루틴을 돌릴 때 |
| Max 20x | 월 $200 | 15회 | 루틴보다 일반 Claude 사용량이 더 중요할 때 |
| Team Standard | 연간 결제 좌석당 월 $20, 월간 $25 | 25회 | Claude Code 포함, 팀 관리 기능 |
| Team Premium | 연간 결제 좌석당 월 $100, 월간 $125 | 25회 | Standard보다 사용량이 많아요 |
| Enterprise | 좌석 $20 + API 사용량 기준 과금 | 25회 | 관리·보안·감사 로그가 필요한 조직 |
Extra Usage와 API 트리거 주의점
Extra Usage도 있어요. 공식 Help Center 기준 번들은 $50 가치가 $45, $250 가치가 $200, $1000 가치가 $700이에요. Pro와 Max는 월 $2000 가치까지, Team은 월 $3000 가치까지 할인 번들을 살 수 있어요. 근데 이걸 루틴 설계 실패를 덮는 데 쓰면 돈이 새요.
배포 후 검증 루틴은 API 트리거로 붙이는 게 깔끔해요. 중요한 건 text 필드에 JSON을 그대로 넣고 파싱을 기대하면 안 된다는 거예요. 공식 문서상 text는 freeform 문자열이라 Claude가 읽을 자연어 설명을 담는 자리예요.
# 배포 파이프라인 마지막 단계에서 루틴 호출
# 토큰은 CI 비밀값에 넣고, 로그에 찍히지 않게 처리하세요
# 엔드포인트·헤더 이름은 research preview 기간에 바뀔 수 있어요. 공식 문서에서 최신 값을 확인하세요.
curl -X POST "https://api.anthropic.com/v1/claude_code/routines/${ROUTINE_TRIGGER_ID}/fire" \
-H "Authorization: Bearer ${ROUTINE_TOKEN}" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d '{
"text": "Deploy finished for service=checkout env=prod version=2026.04.16-1. Run smoke checks, scan recent error logs, and post a go/no-go summary to the release channel."
}'
{
"type": "routine_fire",
"claude_code_session_id": "session_example",
"claude_code_session_url": "https://claude.ai/code/session_example"
}
외부 도구 연결이 늘어나면 MCP(Model Context Protocol, 외부 도구를 AI에 붙이는 표준 방식) 쪽도 같이 보게 돼요. 보안 스캔이나 사내 API 호출을 붙일 계획이면 MCP 서버 사용법: Claude Code 연결 가이드를 미리 읽어두세요.
외부 도구 자체를 자체 인프라로 묶고 싶으면 자체 호스팅 n8n + AI 스택 월 10만원 미만으로 돌리기도 같이 보세요. 루틴 트리거를 외부 API 대신 본인 서버로 받는 흐름이 거기 정리돼 있어요.
클라이언트 온보딩처럼 사람·시간이 동시에 얽힌 워크플로를 루틴으로 옮기는 사례는 AI 클라이언트 온보딩 자동화: 프리랜서 첫 미팅부터 계약까지에 따로 정리했어요. 트리거 뼈대는 PR 리뷰 루틴과 비슷해요.
루틴 맡기면 안 되는 작업: 장애와 품질 논쟁으로 배운 것
루틴은 편한데, 실패했을 때 손실이 큰 작업에는 아직 보수적으로 써야 해요. 특히 자동 머지, 대형 코드베이스 전면 수정, 법·보안·개인정보 판단이 섞인 결정은 사람이 마지막 버튼을 눌러야 해요.
클라우드 자동화인데 서비스가 잠깐 불안정하면 어떻게 될까요? 그 시간대에 배포 검증 루틴이 멈추면 결국 온콜이 직접 봐야 해요.
2026년 4월 15일 Claude Status에는 Claude.ai, API, Claude Code의 에러율 급증 인시던트가 기록됐어요. UTC 기준 14:53에 조사 시작, 17:42에 해결로 바뀌었고, 한국 시간으로는 4월 15일 23:53부터 4월 16일 02:42쯤이에요. 루틴 자체 문제라고 단정하면 안 돼요. 다만 노트북 밖에서 도는 자동화가 플랫폼 상태에 묶인다는 건 분명히 봐야 해요.
맡기면 안 되는 작업은 이런 쪽이에요.
- 자동 머지: 실패하면 사람 검토 없이 main 브랜치가 오염돼요
- 결제·인증·권한 코드 수정: 작은 실수가 사고로 이어질 수 있어요
- 긴 instruction 체인: 중간 단계가 빠져도 나중에 티가 나요
- 대형 리팩터링: 컨텍스트가 커지고 검증 비용이 더 커져요
- 약관·법무 판단: 자동화 결과를 그대로 쓰기엔 리스크가 커요
대신 이렇게 나누면 안정적이에요.
루틴: 아침마다 PR 위험도와 리뷰 포인트 요약
GitHub Actions: 테스트, 린트, 빌드, 배포
훅: Claude Code 세션 안에서 위험 명령 차단
사람: 머지, 배포 승인, 정책 판단
긴 루틴 하나에 모든 걸 밀어 넣고 싶을 때가 있어요. 근데 그럴수록 실패 지점이 안 보여요. 이럴 땐 작업을 작은 단위로 쪼개거나, 코드 리뷰·테스트·문서화처럼 역할이 다른 에이전트를 따로 두는 쪽이 낫죠. 그 흐름은 Claude Code 서브에이전트 만들기 실전 가이드: 자동 위임·비용 절감 세팅까지에서 이어서 보면 돼요.
자주 묻는 질문
Q1: 루틴이랑 훅이 정확히 뭐가 달라요?
A: 훅은 Claude Code 세션 안에서 도는 자동 명령이에요. 루틴은 스케줄, API, GitHub 이벤트처럼 세션 밖에서 들어온 신호로 클라우드 세션을 새로 깨워요. 그래서 포맷팅·테스트 강제는 훅, 노트북 닫은 뒤 PR 리뷰 요약은 루틴이 맞아요.
Q2: GitHub Actions 이미 쓰는데 루틴도 써야 하나요?
A: 빌드, 테스트, 린트, 배포는 GitHub Actions에 두세요. 루틴은 “이 PR에서 사람이 먼저 볼 위험 포인트가 뭔지” 같은 판단에 쓰는 게 좋아요. 둘을 합치기보다 역할을 나누는 게 덜 피곤해요.
Q3: claude -p를 크론에 넣는 건 루틴이랑 다른가요?
A: 달라요. 크론은 내 머신이나 서버에서 CLI를 돌리는 방식이고, 루틴은 Claude Code 웹 인프라에서 계정 한도 안에 도는 기능이에요. 약관 해석은 사람 검토가 필요하니, 자동화 규모가 커지면 공식 Consumer Terms나 Commercial Terms를 직접 체크하세요.
Q4: GitHub 트리거를 세팅했는데 이벤트가 안 와요. 어디부터 봐요?
A: 먼저 Claude GitHub App이 해당 저장소에 설치됐는지 보세요. /web-setup은 웹훅을 켜는 작업이 아니에요. 그다음 이벤트 종류, PR 필터, 시간당 웹훅 상한을 순서대로 줄여가며 테스트하면 원인이 빨리 보여요.
Q5: Pro 하루 5회 한도면 너무 적지 않나요?
A: 무거운 루틴 5개면 하루 한도는 바로 써요. 그래서 Pro에서는 일일 PR 요약, 배포 후 검증, 이슈 트리아지처럼 매일 손으로 하던 핵심 작업 1~3개만 잡는 게 좋아요. 더 많이 돌릴 거면 Max나 Team, Extra Usage까지 가격표를 같이 봐야 해요.
다음 단계
첫 루틴 하나 만들고 나면 세션 내부까지 조여야 할 때가 와요. 그때는 Claude Code Hooks 완벽 가이드 – 자동화 훅 설정법로 넘어가서 루틴이 아니라 훅으로 잡아야 하는 케이스를 먼저 보세요.
긴 루틴을 쪼개고 싶다면 Claude Code 서브에이전트 만들기 실전 가이드: 자동 위임·비용 절감 세팅까지로 이어가면 돼요. 루틴 세팅하다 막히면 댓글에 환경이랑 막힌 단계 남겨주세요.
