바이브코딩 Tips 3: Claude Code Routines에서 /schedule로 먼저 붙이고 API /fire는 중복 호출 막기

2026년 4월 17일 | 바이브코딩 Tips

---

Claude Code Routines를 붙일 때 내가 먼저 보는 건 프롬프트 문장보다 /schedule 진입점과 API /fire 재호출 조건이다. Anthropic 문서를 다시 읽어 보니 routine은 저장된 프롬프트 메모가 아니라 prompt + repositories + connectors + trigger를 묶어 두는 실행 설정에 가깝고, Hacker News 항목도 지금 기준 710 points, 405 comments까지 올라와 있었다. 반복 프롬프트를 채팅창 밖으로 빼는 흐름 자체는 반갑지만, 이런 기능은 편의보다 범위와 중복 실행 조건을 먼저 잡아 두는 편이 훨씬 덜 시끄럽다.

내가 routine을 “긴 프롬프트 저장소”로 보지 않는 이유도 여기 있다. 이건 로컬 터미널에 붙는 단축키가 아니라 Anthropic 관리형 클라우드에서 도는 저장된 작업 단위다. 그래서 야간 PR 리뷰, 배포 뒤 smoke check, 문서 드리프트 점검처럼 입력 표면이 비교적 일정한 일부터 잘 맞고, 아직 성공 조건이 흐린 탐색형 작업은 여전히 대화 세션 안에 남겨 두는 편이 안전하다.

Figure 1. routine은 trigger를 하나 더 붙이는 기능이라기보다, 범위와 재호출 규칙까지 같이 관리해야 하는 저장형 실행 단위에 가깝다.

문서를 보면서 제일 좋았던 점은 진입점이 과하게 크지 않다는 것이었다. CLI에서는 일단 /schedule만 알아도 시작할 수 있다. 첫 routine부터 API 토큰, GitHub 이벤트, 여러 connector를 한꺼번에 엮으려 들면 설정 화면만 복잡해지고 정작 반복 작업 후보를 좁히지 못한다. 내 기준에서는 밤마다 같은 형식으로 열리는 PR을 읽어 체크리스트를 남기거나, 평일 저녁마다 특정 저장소 상태를 요약하는 정도가 가장 좋은 첫 시작이다.

1. 가장 작은 시작은 /schedule 하나로 충분했다

Claude Code docs 기준으로 CLI에서 가장 작은 진입점은 scheduled routine이다. 웹에서 API trigger나 GitHub trigger를 더 붙일 수는 있지만, 처음에는 굳이 거기까지 가지 않아도 된다. 중요한 건 같은 프롬프트를 대화 히스토리에서 다시 찾는 대신, 이름 붙은 반복 작업으로 올려 두는 감각이다.

/schedule
/schedule list
/schedule update
/schedule run

나는 이런 류의 기능에서 “무슨 자동화를 할까”보다 “사람이 다시 붙지 않아도 되는가”를 먼저 본다. routine이 잘 맞는 일은 대개 세 가지 공통점이 있다. 입력 표면이 비슷하고, 출력 형식을 미리 적어 둘 수 있고, 끝났는지 아닌지를 체크리스트로 판정할 수 있다. 반대로 리팩터링 방향이 자꾸 바뀌거나, 사람 합의가 여러 번 필요한 설계 작업은 routine보다 대화 세션이 낫다.

2. API /fire는 text 슬롯보다 idempotency 부재가 더 중요했다

API trigger 문서에서 실무적으로 더 중요하게 보인 건 text 필드 자체보다 중복 호출을 막아 주는 장치가 없다는 점이었다. 문서 예시처럼 text로 이번 알림 문장만 덧붙이는 방식은 꽤 좋다. routine 본체에는 “어떻게 처리할지”를 저장하고, 호출 시점에는 “이번에 무슨 일이 났는지”만 짧게 넘길 수 있기 때문이다.

curl -X POST ROUTINE_FIRE_URL   -H "Authorization: Bearer ROUTINE_FIRE_TOKEN"   -H "anthropic-version: 2023-06-01"   -H "anthropic-beta: experimental-cc-routine-2026-04-01"   -H "Content-Type: application/json"   -d '{"text":"Sentry alert SEN-4521 fired in prod. Check recent logs."}'

그런데 API docs에는 더 중요한 문장이 있다. 성공한 요청마다 새 세션이 하나씩 만들어지고, idempotency key는 없다는 점이다. 즉 webhook caller가 재시도하면 routine도 그대로 여러 번 돈다. 나는 이 문장을 보고 routine 호출부를 그냥 알림 끝단에 바로 붙이기보다, 적어도 caller 쪽 dedupe나 재시도 가드를 먼저 두는 편이 낫다고 봤다. 토큰 운영도 비슷하다. API token은 생성 시 한 번만 보여 주고, 새 토큰을 만들면 이전 토큰이 바로 revoke된다. 이건 편의 기능이라기보다 secret rotation 규칙에 더 가깝다.

3. connector는 기본 전체 포함, repo push는 claude/ 브랜치가 기본값

routine을 붙일 때 내가 먼저 줄이는 건 connector 범위다. docs에는 현재 연결된 connector가 기본값으로 다 포함된다고 적혀 있다. 이 상태로 시작하면 PR 리뷰 routine인데도 굳이 필요 없는 Slack, Linear, 문서 계정까지 같은 세션에 딸려 들어올 수 있다. 그래서 첫 routine은 기능을 늘리기보다 범위를 덜어내는 쪽이 맞다.

• Connectors: 필요한 것만 남기고 나머지는 빼기
• Repositories: 처음에는 한 저장소만 붙여서 출력 품질 확인하기
• Branch permissions: 기본 clone은 default branch에서 시작하고 push는 claude/ 접두어 브랜치에만 두기
• Environment: 문서 점검용 routine과 배포 후 점검 routine의 네트워크·변수 범위를 분리하기

이 조합이 중요한 이유는 routine이 결국 내 계정으로 도는 작업이기 때문이다. docs도 run allowance가 개인 계정 기준으로 차감된다고 못 박고 있고, connector 액션과 GitHub 변경도 결국 내 연결 계정 이름으로 남는다. 그러니 “편한 자동화 하나 만들기”보다 “내 이름으로 반복 실행되는 작업 하나 만들기”에 더 가깝게 보는 편이 운영 감각이 맞다.

4. 내가 routine 후보로 먼저 고를 세 가지

내가 routine 후보로 먼저 보는 건 화려한 작업이 아니라 반복성이 높은 작업이다. 구체적으로는 야간 PR 리뷰, 배포 뒤 smoke check, 문서 드리프트 점검 같은 것들이다. 셋 다 입력 표면이 비교적 일정하고, 결과를 짧은 체크리스트나 코멘트 형식으로 고정할 수 있다. 반대로 코드베이스를 처음 읽는 탐색 작업이나, 여러 선택지를 열어 놓고 토론해야 하는 설계 작업은 routine으로 빼면 오히려 시끄러워진다.

결국 내 결론은 단순하다. 같은 프롬프트를 세 번 이상 다시 치고 있다면 routine 후보로 보고, 붙일 때는 /schedule로 가장 작게 시작하고, API /fire는 caller 쪽 중복 방지를 먼저 넣고, connector 범위는 기본값에서 덜어내기부터 하자는 것. 문서는 Claude Code routines docs와 /fire API reference를 같이 보는 편이 좋았고, 화제성은 HN item 47768133에서 확인했다.