Skip to content
푸땡로그
Go back

Claude Code /loop: 세션 안에서 반복 작업을 맡기는 가장 가벼운 방법

Claude Code를 쓰다 보면 “끝날 때까지 가끔 확인해줘”라는 요청이 자주 생깁니다. 배포가 끝났는지 확인하고, CI가 통과했는지 보고, PR 리뷰 코멘트가 새로 달렸는지 훑고, 긴 빌드가 끝나면 다음 조치를 하고 싶습니다.

이때 매번 터미널로 돌아와서 같은 프롬프트를 다시 입력하는 건 번거롭습니다. Claude Code의 /loop는 이런 상황을 위한 세션 안 반복 실행 도구입니다.

이 글은 작성 시점 2026-06-17 · Claude Code scheduled tasks 문서, Goals 문서, Channels 문서 스냅숏 기준으로 정리했습니다.

기준 /loop는 Claude Code v2.1.72 이상에서 사용할 수 있는 scheduled tasks 기능입니다. 이 글에서는 클라우드 Routines가 아니라, 현재 CLI 세션 안에서 반복 실행되는 /loop에 집중합니다.

/loop는 무엇인가

공식 문서는 /loop를 “세션이 열려 있는 동안 프롬프트를 반복 실행하는 가장 빠른 방법”으로 설명합니다. 핵심은 현재 대화 안에서 같은 요청을 다시 깨운다는 점입니다.

예를 들어 배포가 끝났는지 5분마다 확인하고 싶다면 이렇게 씁니다.

/loop 5m check if the deployment finished and tell me what happened

Claude는 이 요청을 cron 표현식으로 바꿔 현재 세션의 scheduled task로 등록합니다. 시간이 되면 새 턴이 큐에 들어가고, Claude가 바쁘지 않을 때 실행됩니다.

flowchart TD
    A[사용자: /loop 5m check deploy] --> B[Claude Code가 scheduled task 생성]
    B --> C[세션 안에서 대기]
    C --> D{시간 도달}
    D --> E[프롬프트 재실행]
    E --> F[결과 관찰]
    F --> C

중요한 점은 /loop가 독립 서버 작업이 아니라는 것입니다. 현재 Claude Code 세션, 현재 설정, 현재 MCP 서버, 현재 권한 모델을 그대로 이어받습니다.


세 가지 사용 방식

공식 문서 기준 /loop는 무엇을 넘기느냐에 따라 동작이 달라집니다.

입력예시동작
간격 + 프롬프트/loop 5m check the deploy고정 간격으로 같은 프롬프트 실행
프롬프트만/loop check the deployClaude가 매 반복 후 다음 간격을 고름
간격만 또는 없음/loop 15m, /loop기본 maintenance prompt 실행

고정 간격은 단순합니다. 5m, 2h, 1d 같은 값을 넣으면 Claude가 cron 표현식으로 바꿉니다. 초 단위는 cron의 1분 단위 제약 때문에 분 단위로 올림 처리됩니다.

프롬프트만 넘기면 Claude가 매번 상황을 보고 다음 대기 시간을 고릅니다. 공식 문서는 이 범위를 1분에서 1시간 사이로 설명합니다. 빌드가 곧 끝날 것 같으면 짧게 기다리고, 별일 없으면 길게 기다리는 식입니다.


빈 /loop가 하는 일

/loop만 입력하면 Claude는 내장 maintenance prompt를 실행합니다. 문서 기준 우선순위는 다음과 같습니다.

  1. 현재 대화에서 끝나지 않은 작업을 이어가기
  2. 현재 브랜치의 PR을 돌보기: 리뷰 코멘트, 실패한 CI, merge conflict
  3. 남은 일이 없으면 bug hunt나 단순화 같은 cleanup pass 수행

다만 여기서 Claude가 완전히 새로운 일을 마음대로 시작하는 것은 아닙니다. 공식 문서는 내장 prompt가 그 범위 밖의 새 initiative를 시작하지 않고, push나 delete 같은 되돌리기 어려운 행동은 기존 transcript에서 허용된 작업의 연장일 때만 진행한다고 설명합니다.

주의/loop는 편하지만, "무엇을 해도 되는지"가 애매하면 결과도 애매해집니다. 실무에서는 배포 확인, PR 대응, 특정 테스트 재시도처럼 관찰 대상과 허용 행동을 명확히 적는 편이 좋습니다.

loop.md로 기본 프롬프트를 바꾸기

프로젝트마다 반복 확인 방식이 다르다면 .claude/loop.md를 둘 수 있습니다. 공식 문서에 따르면 Claude는 먼저 프로젝트의 .claude/loop.md를 찾고, 없으면 사용자 홈의 ~/.claude/loop.md를 봅니다.

이 파일은 bare /loop의 기본 prompt를 대체합니다. 여러 작업 목록이 아니라, /loop만 쳤을 때 사용할 단일 기본 지시문이라고 보는 편이 맞습니다.

# .claude/loop.md

Check the release PR. If CI is red, inspect the failing job log and
propose the smallest safe fix. If review comments arrived, address them
one by one. If everything is green and quiet, report that in one line.

문서 기준 loop.md는 Markdown 파일이고 필수 구조는 없습니다. 실행 중 수정해도 다음 반복부터 반영됩니다. 단, 25,000 bytes를 넘는 내용은 잘릴 수 있으므로 짧고 구체적으로 두는 편이 좋습니다.


/goal, Routines, Channels와 어떻게 다른가

Claude Code에는 비슷해 보이는 자동화 기능이 많습니다. /loop의 자리는 “열려 있는 세션에서 빠르게 반복 확인”입니다.

기능다음 턴이 시작되는 조건좋은 용도
/loop시간이 지남배포, CI, PR 리뷰처럼 상태가 나중에 바뀌는 일
/goal이전 턴이 끝난 뒤 조건이 아직 안 맞음테스트 통과, 마이그레이션 완료처럼 검증 가능한 목표
Channels외부 이벤트가 세션으로 들어옴CI 실패, Telegram/Discord 메시지, 모니터링 알림
Routines클라우드 스케줄 또는 이벤트머신이 꺼져도 돌아야 하는 정기 작업

따라서 “10분마다 배포 상태를 봐줘”는 /loop가 자연스럽습니다. “테스트가 전부 통과할 때까지 계속 고쳐줘”는 /goal이 더 맞습니다. “CI가 실패하면 그때 바로 세션에 알려줘”는 Channels가 더 낫습니다. “매주 월요일 오전 의존성 점검”은 Routines나 GitHub Actions 쪽이 더 적합합니다.

이 구분은 이전에 다룬 Claude Code Channels, Claude Code Routines, Claude Code Ultra Plan과도 이어집니다. Claude Code 자동화는 하나의 기능으로 모든 일을 밀어붙이기보다, 시간 기반, 조건 기반, 이벤트 기반, 클라우드 기반을 나눠 쓰는 쪽이 안정적입니다.


실전 패턴

제가 보기에는 /loop가 가장 잘 맞는 작업은 “곧 상태가 바뀔 수 있지만, 정확히 언제인지는 모르는 일”입니다.

배포 감시

/loop 5m check whether the Netlify deploy for the current branch finished. If it failed, inspect the log and summarize the likely cause.

배포가 끝나기 전까지는 반복 확인이 필요하지만, 실패하면 원인 분석으로 넘어갈 수 있습니다.

PR babysitting

/loop check whether CI passed and whether new review comments arrived. If there is actionable feedback, address it and report the change.

프롬프트만 주면 Claude가 상황에 따라 다음 간격을 고를 수 있습니다. 리뷰가 활발하면 짧게, 조용하면 길게 기다리는 식입니다.

로컬 장기 작업 확인

/loop 10m check whether the long-running import script has finished. If it failed, inspect the latest log and stop the loop with a summary.

이런 작업은 사람이 터미널을 계속 보고 있을 필요가 없습니다. 다만 실패 시 어떤 로그를 볼지, 어떤 행동까지 허용할지를 프롬프트에 적어야 합니다.


멈추는 방법과 한계

/loop가 다음 실행을 기다리는 중이라면 Esc로 pending wakeup을 지울 수 있습니다. 고정 간격 loop는 사용자가 멈추거나 7일이 지나면 끝납니다. self-paced loop는 Claude가 작업이 완료됐다고 판단하면 다음 wakeup을 만들지 않고 종료할 수도 있습니다.

제약도 분명합니다. /loop 작업은 Claude Code가 실행 중이고 세션이 idle 상태일 때만 실행됩니다. 터미널을 닫거나 새 conversation을 시작하면 session-scoped task는 사라집니다. --resume이나 --continue로 되살릴 때는 아직 만료되지 않은 recurring task와 scheduled time이 지나지 않은 one-shot만 복원됩니다.

Tip 정확한 시간에 반드시 실행되어야 하거나, 노트북이 꺼져도 살아 있어야 하는 작업은 /loop가 아니라 Routines, Desktop scheduled tasks, GitHub Actions를 쓰는 편이 맞습니다.

블로그 대표 이미지 콘셉트

Claude Code 터미널을 중심으로 원형 루프가 돌아가는 기술 다이어그램이 잘 맞습니다. 중앙에는 열린 CLI 세션이 있고, 주변에는 “Check deploy”, “Read CI log”, “Address review”, “Wait 5m” 같은 단계가 순환 구조로 배치됩니다.

오른쪽에는 /goal, Channels, Routines가 각각 조건 기반, 이벤트 기반, 클라우드 기반 자동화로 나란히 비교되어 있고, /loop는 “session-scoped polling”으로 강조합니다. 전체 톤은 어두운 터미널 배경에 초록색 상태 표시와 파란색 scheduling 라인이 들어간 개발자 블로그용 워크플로우 일러스트가 좋습니다.


마무리

/loop는 거창한 자동화 플랫폼이 아닙니다. 오히려 그 점이 장점입니다. 현재 Claude Code 세션에서 짧게 반복 확인하고, 필요한 순간에만 다음 행동으로 넘어가게 만드는 가벼운 도구입니다.

배포, CI, PR 리뷰처럼 “조금 뒤에 다시 봐야 하는 일”에는 /loop가 잘 맞습니다. 반대로 명확한 종료 조건이 있는 작업은 /goal, 외부 이벤트에 즉시 반응해야 하는 작업은 Channels, 세션과 무관하게 오래 살아야 하는 작업은 Routines가 더 낫습니다.

Claude Code를 잘 쓰는 핵심은 에이전트를 오래 켜두는 것이 아니라, 어떤 방식으로 다시 깨울지 정하는 데 있습니다. /loop는 그중 가장 작고 실용적인 반복 버튼입니다.


참고 자료


Share this post on:

Previous Post
HTTPS DNS 레코드로 첫 연결부터 HTTP/3를 쓰게 만들기
Next Post
Claude Code Dynamic Workflows: 수백 개 서브에이전트로 큰 작업을 쪼개는 방식