Claude Code를 쓰다 보면 /loop라는 슬래시 커맨드가 눈에 띕니다. 이름만 보면 “그냥 같은 작업을 반복시키는 거 아닌가? 그게 진짜 쓸모가 있나?” 싶지만, 막상 써 보면 대기 시간을 자동화로 바꿔주는 도구라는 점에서 의외로 손이 자주 갑니다. 이 글에서는 /loop가 무엇인지 빠르게 짚고, 실제로 손에 익을 만한 활용 시나리오 7가지와 오히려 안 쓰는 게 나은 경우, 그리고 토큰 캐시까지 고려한 사용 팁을 정리하겠습니다.
목차
/loop는 어떤 명령인가
/loop는 Claude Code 세션 안에서 같은 프롬프트를 정해진 간격으로 자동 재실행해주는 세션 범위 스케줄러입니다. 형태는 단순합니다.
/loop 5m /check-deploy # 5분마다 /check-deploy 실행
/loop 30s ls -al # 30초마다 명령
/loop check the build status # 간격 생략 시 dynamic 모드(클로드가 직접 결정)
/loop # 내장 유지보수 프롬프트 실행시간 단위는 s(초), m(분), h(시간), d(일)을 지원합니다. 간격을 생략하면 dynamic mode가 활성화되어, 매 반복 끝에 클로드가 “다음에는 몇 초 뒤에 다시 깨울지”를 직접 정합니다. 폴링 간격을 사용자가 미리 정하기 애매한 경우(빌드가 1분 만에 끝날 수도, 30분 걸릴 수도 있는 경우)에 특히 유용합니다.
/schedule과 어떻게 다른가
비슷해 보이는 /schedule(Routines)과 자주 헷갈립니다. 핵심 차이를 정리하면 아래와 같습니다.
| 항목 | /loop | /schedule (Routines) |
|---|---|---|
| 실행 위치 | 로컬 머신, 현재 세션 | Anthropic 클라우드 |
| 세션 필요 여부 | 세션이 살아 있어야 동작 | 컴퓨터가 꺼져 있어도 실행 |
| 최소 간격 | 1분(초 단위 지정 시 1분으로 클램프) | 1시간 |
| 적합한 용도 | 지금 보고 있는 작업의 폴링 | 매일 아침 PR 리포트 같은 정기 자동화 |
한 줄로 요약하면, /loop는 “내가 모니터를 켜놓은 동안만 도와줘”이고, /schedule은 “내가 자고 있을 때도 돌아가줘”입니다. 야간 자동화, 무인 실행이 필요하면 /schedule 또는 로컬 launchd/cron을 쓰는 편이 맞습니다.
진짜 쓸 일이 있는 7가지 시나리오
1. 긴 빌드·테스트 폴링
“테스트 끝나면 알려줘”가 아니라 “끝나면 다음 작업까지 이어서 해줘”가 필요할 때입니다. 예시: /loop 4m npm test가 끝났는지 확인하고, 통과했으면 lint도 돌려줘. 클로드가 4분마다 깨어나서 상태를 보고, 끝나는 순간 다음 단계로 넘어갑니다. 그동안 사용자는 다른 일을 합니다.
2. PR 베이비시팅
PR을 올린 뒤 CI 결과·리뷰 코멘트가 어떻게 달리는지 신경 쓰는 시간을 자동화합니다. /loop check open PRs and respond to any new review comments처럼 dynamic 모드로 두면, 코멘트가 활발할 때는 자주, 잠잠할 때는 길게 쉬며 점검합니다.
3. 배포·롤아웃 관찰
Kubernetes나 Vercel 배포가 진행 중일 때 /loop 2m kubectl get pods를 보고 새 pod이 모두 ready인지 확인. 실패한 pod이 있으면 로그를 가져와줘처럼 쓰면, 사용자가 터미널을 계속 쳐다볼 필요가 없습니다.
4. 큐 드레인·재시도 처리
실패한 웹훅이나 잡이 쌓이는 큐가 있을 때, /loop 10m process the failed_webhooks table와 재시도 결과 요약처럼 정기 처리를 지시할 수 있습니다. 이 경우 진짜 cron으로 옮기기 전 임시 자동화로 적합합니다.
5. 장시간 학습·시뮬레이션 모니터링
ML 학습이나 시뮬레이션처럼 몇 시간 걸리는 작업을 /loop 30m loss curve를 확인하고, 발산 조짐이 있으면 학습을 중단하라로 감시할 수 있습니다. 사람이 30분마다 그래프를 들여다보는 일을 클로드에게 위임합니다.
6. 이슈 트리아지·일일 리포트
한 세션 동안만 필요한 가벼운 트리아지에 적합합니다. 예: /loop 1h 새로 들어온 이슈 중 우선순위 P0/P1만 골라서 알려줘. 종일 자동화는 /schedule이 맞지만, “오늘 하루만 지켜봐”는 /loop가 자연스럽습니다.
7. 데이터 수집 워밍업
외부 API에서 일정량의 데이터를 점진적으로 받아오는 경우, /loop 5m 다음 페이지 100건 fetch하고 DB에 저장 식으로 쓸 수 있습니다. 한 번에 다 못 받는 데이터셋의 백필(backfill) 작업에 잘 맞습니다.
안 쓰는 게 나은 경우
편리해 보이지만 /loop가 정답이 아닌 경우도 분명합니다.
- 일회성 작업: 한 번만 실행하면 되는 일은 그냥 직접 명령을 내리는 편이 토큰·시간 모두 효율적입니다.
- 세션 종료 후에도 돌아야 하는 자동화: 노트북을 닫으면
/loop는 멈춥니다./schedule또는 launchd로 가야 합니다. - 이벤트 기반이면 충분한 작업: GitHub Webhook, Slack 알림처럼 이미 푸시 알림이 있는 경우 굳이 폴링할 필요가 없습니다.
- 비용 민감한 컨텍스트: 매 반복마다 토큰을 소비하므로 무한정 돌리면 청구서가 늘어납니다.
루프를 종료하는 4가지 방법
- Esc 키로 즉시 중단: 가장 단순한 방법입니다.
- 자연어 지시: “방금 시작한 deploy check loop을 멈춰줘”라고만 해도 됩니다.
- 조건 만족 시 자기 종료: dynamic 모드에서는 클로드가 “더 할 일이 없다”고 판단하면 다음 wakeup을 등록하지 않아 루프가 자연스럽게 끝납니다.
- 7일 자동 만료: 별도로 손대지 않으면 7일 뒤 자동 종료됩니다(영구 자동화에는 부적합).
토큰 캐시(5분) 고려한 사용 팁
Claude API의 prompt cache는 5분 TTL을 가집니다. 즉, 5분을 넘기는 순간 직전 컨텍스트가 캐시에서 빠져 다음 호출은 풀로 재계산됩니다. 이 점을 알고 있으면 폴링 주기 선택이 달라집니다.
- 1~4분 간격: 캐시가 살아 있어 토큰 단가가 가장 저렴. 활발히 변하는 빌드·배포 감시에 적합.
- 5분 정확히: 가장 비효율적. 캐시는 빠지는데 대기 시간 이득은 없는 어정쩡한 지점이라 추천하지 않습니다.
- 20~30분 이상: 어차피 캐시 미스 한 번을 감수하는 것이 맞으므로, 짧게 자주 깨우는 것보다 긴 간격으로 한 번 제대로 작업하는 편이 낫습니다.
dynamic 모드를 쓸 때는 클로드에게 “가능하면 5분 미만이나 20분 이상으로 골라줘”라고 한 줄 덧붙여두면 캐시 효율이 안정적으로 올라갑니다.
마무리
/loop는 만능이 아니지만, “이 작업이 끝날 때까지 클로드가 대신 봐줬으면” 하는 순간이 한 세션에 한두 번은 분명히 옵니다. 빌드 폴링, PR 베이비시팅, 배포 관찰처럼 대기 시간이 자동화의 가치를 만드는 영역에서 가장 빛납니다. 영구 자동화는 /schedule이나 launchd로 분리하고, /loop는 “지금 이 세션 동안만 도와줘”의 도구로 한정하면 가장 깔끔합니다. 다음에 빌드를 7분쯤 기다려야 한다면, 한 번 /loop 4m로 넘겨보시기 바랍니다.
자주 묻는 질문
Q. /loop는 Claude Code Pro 요금제에서도 쓸 수 있나요?
네. /loop는 모든 요금제에서 사용 가능하지만, 매 반복마다 토큰이 소비되므로 사용량 한도를 신경 써야 합니다.
Q. 한 세션에 여러 /loop를 동시에 돌릴 수 있나요?
가능하지만 권장하지 않습니다. 같은 세션에서 동시에 여러 폴링을 돌리면 컨텍스트가 섞여 응답 품질이 떨어집니다. 진짜 병렬 자동화는 /schedule이나 별도 세션·worktree로 분리하는 편이 안전합니다.
Q. /loop 안에서 git commit 같은 위험 작업도 시켜도 될까요?
가능은 하지만 신중해야 합니다. 자동 커밋·푸시는 의도와 다르게 반복될 수 있으므로, 가급적 “변경이 있으면 커밋 메시지를 제안만 해줘”처럼 비파괴적인 보고형 프롬프트로 쓰시기를 권합니다.