Claude Code 자동화 완전 정리: loops·goal·routines·workflows 가이드

같은 프롬프트를 몇 번씩 다시 치고 계신가요? "배포됐는지 확인해줘", "테스트 다시 돌려봐", "이제 됐어?"를 반복하고 있다면, Claude Code에는 그 반복 자체를 맡길 수 있는 기능이 이미 있습니다. Claude Code 자동화는 크게 네 갈래로 나뉩니다. 세션 안에서 시간마다 반복하는 loops, 조건이 충족될 때까지 스스로 판단하며 반복하는 goal, 노트북을 꺼도 클라우드에서 도는 routines(스케줄), 그리고 하나의 작업을 수백 개로 쪼개 병렬 처리하는 dynamic workflows(ultracode)입니다. 이 네 가지 모두 Anthropic 공식 문서에 실린 기능이고, 각각 언제 쓰는 게 맞는지가 다릅니다. 이 글에서 명령어 예시와 함께 정리해 보겠습니다.

Claude Code 자동화가 필요한 이유

지금까지는 작업이 끝날 때마다 사람이 다시 프롬프트를 입력해야 했습니다. "빌드 끝났어?", "테스트 통과했어?"를 반복해서 물어보는 건 개발자의 집중을 계속 끊습니다. Claude Code 자동화 기능들은 이 반복 개입을 줄이는 방향으로 설계됐습니다. 다만 방식이 서로 다릅니다.

시간이 기준이면 → /loop
조건 충족 여부가 기준이면 → /goal
노트북 전원과 무관하게 돌아야 하면 → routines(스케줄)
작업 규모가 혼자 하기엔 너무 크면 → dynamic workflows(/ultracode)

아래에서 하나씩 무엇인지, 어떻게 쓰는지, 실제로 어떤 상황에 맞는지 살펴보겠습니다.

Claude Code loops — `/loop`로 시간 간격 반복 실행하기

/loop은 지금 열려 있는 세션 안에서 하나의 프롬프트를 정해진 시간 간격으로 계속 다시 실행하는 기능입니다. 주방 타이머를 맞춰 놓고 "5분마다 오븐 안을 확인하라"고 시키는 것과 같습니다. 사람이 계속 지켜보지 않아도, 정해진 간격마다 같은 점검을 자동으로 반복합니다.

어떻게 쓰나요

/loop 5m 배포가 끝났는지 확인하고 결과를 알려줘

이렇게 입력하면 5분마다 이 프롬프트가 다시 실행됩니다. 정지 조건을 함께 지정할 수도 있습니다.

/loop every 2m until: tests pass

제약 조건 (공식 문서 기준)

항목	값
최소 반복 간격	1분
최대 지속 시간	3일

10초마다 같은 초단위로 반복시키는 건 불가능하고, 3일이 넘도록 계속 도는 것도 안 됩니다. 배포 폴링, 긴 빌드 상태 확인, PR 감시처럼 "주기적으로 다시 들여다봐야 하는" 작업에 적합합니다.

Claude Code goal — `/goal`로 조건 충족까지 자율 반복하기

/goal은 목표(조건)를 주면 Claude가 턴을 이어가며 작업하되, 매 턴이 끝날 때마다 별도의 평가자 모델이 대화 기록을 독립적으로 읽고 "조건이 충족됐는가?"만 판정하는 기능입니다.

/loop과 헷갈리기 쉬운데, 차이는 명확합니다. /loop은 "시간이 지나면" 다음 턴을 시작하고 사람이 멈출 때까지 돕니다. /goal은 "직전 턴이 끝나는 즉시" 다음 턴을 시작하고, 평가자 모델이 조건 충족을 확인하는 순간 스스로 멈춥니다.

/goal이란: Claude Code에서 작업을 수행하는 모델과, 그 작업이 끝났는지 판정하는 모델을 분리하는 기능입니다. 기본값으로 더 작고 빠른 모델(Haiku)이 매 턴 독립적으로 완료 여부를 확인하고, "아니오"라고 답하면 그 이유가 다음 턴의 지시가 됩니다.

이 구조가 중요한 이유는, 일을 한 모델이 스스로 "다 했다"고 우기는 상황(자기 검증 편향)을 막아주기 때문입니다. 숙제를 한 사람이 스스로 다 했다고 말하는 게 아니라, 별도의 검사관이 "여기 아직 틀렸다"고 지적해야 다음 단계로 넘어가는 구조라고 보면 됩니다. 평가 자체는 작고 빠른 모델이 하기 때문에 이 판정에 드는 비용은 본 작업 대비 대체로 미미합니다.

어떻게 쓰나요

/goal 테스트 스위트 전체가 skip·warning 없이 통과한다 /loop every 2m until: tests pass

/goal 모든 export 함수·클래스가 현재 구현을 반영한 정확한 JSDoc 주석을 가진다 /loop until: documentation coverage is complete

/goal과 /loop을 이렇게 함께 쓰면, "조건"과 "반복 간격"을 동시에 지정할 수 있습니다.

Claude Code 스케줄 — routines로 클라우드에서 무인 실행하기

여기엔 두 층위가 있습니다.

세션 내 scheduled tasks는 열려 있는 세션 안에서 프롬프트를 간격마다 자동 재실행하는 기능입니다. 배포 폴링, 긴 빌드 확인, "나중에 다시 알려줘" 같은 리마인더에 씁니다. 성격상 /loop과 비슷하되 세션 스케줄러 쪽에 가깝습니다.

**Routines(클라우드 자율 실행)**는 완전히 다른 층위입니다. 2026-04-14에 리서치 프리뷰로 출시된 기능으로, 프롬프트·레포·연동(커넥터)을 한 번 설정해 두면 스케줄·API·이벤트로 실행되는 자동화입니다. 핵심은 Claude Code 웹 인프라에서 실행된다는 점입니다. 노트북이 켜져 있는지, 터미널이 열려 있는지, 심지어 사람이 깨어 있는지와 무관하게 돌아갑니다. "매일 밤 사무실 문 단속하고 보고서 올려두기"를 직원에게 맡겨 두는 것과 비슷합니다. 내가 집에서 자는 동안에도 클라우드의 직원이 정해진 시각에 그 일을 해 둡니다.

어떻게 쓰나요

routine은 claude.ai/code/routines 웹 UI에서 만들거나, CLI에서 /schedule 명령으로 대화형으로 생성합니다. 트리거는 세 가지를 자유롭게 조합할 수 있습니다.

트리거	설명
스케줄	표준 5필드 cron 표현식(분·시·일·월·요일), 최소 1시간 간격
API 호출	routine별 HTTP 엔드포인트 + bearer 토큰
GitHub 저장소 이벤트	webhook (예: PR이 열릴 때마다)

플랜별 일일 실행 한도도 정해져 있습니다.

플랜	일일 실행 한도
Pro	5회
Max	15회
Team / Enterprise	25회

여기서 주의할 점이 하나 있습니다. 세션 내 /loop의 "최소 1분"과 클라우드 routine cron의 "최소 1시간"은 완전히 다른 제약입니다. 서로 다른 기능이니 혼동하지 않아야 합니다.

Dynamic workflows — `/ultracode`로 수백 개 서브에이전트 병렬 처리

dynamic workflows란: Claude가 사용자의 목표를 보고 즉석에서 작성하는 JavaScript 오케스트레이션 스크립트입니다. 이 스크립트를 런타임이 백그라운드에서 실행하는 동안 세션은 계속 다른 요청에 응답할 수 있는 상태로 유지됩니다. 2026-05-28에 리서치 프리뷰로 발표됐습니다.

/ultracode가 이 dynamic workflow 경로를 트리거하는 슬래시 명령입니다. 미리 사람이 구성해 둔 "에이전트 팀"이 아니라, 작업이 들어올 때마다 그 작업에 맞춰 새로 서브에이전트들을 생성합니다. 한 번의 실행에서 공식 문서 기준 최대 1,000개의 서브에이전트를 병렬로 돌릴 수 있습니다.

핵심 API는 세 가지 함수로 구성됩니다(스크립트 자체는 top-level await를 쓰는 순수 JavaScript입니다).

함수	역할
`agent()`	서브에이전트 하나를 생성 (선택적으로 검증된 JSON 출력 스키마 지정 가능)
`pipeline()`	리스트의 각 항목을 배리어 없이 스트리밍으로 다음 단계에 흘려보냄
`parallel()`	배리어를 만들어 병렬 결과를 한꺼번에 모음

워크플로가 만든 서브에이전트는 항상 acceptEdits 모드(파일 편집을 자동 승인하는 모드)로 실행되며, 세션에 설정된 도구 허용 목록을 그대로 물려받습니다. 사용하려면 Claude Code v2.1.154 이상이 필요하고, 모든 유료 플랜은 물론 Anthropic API, Amazon Bedrock, Google Cloud Agent Platform(Vertex AI), Microsoft Foundry에서도 쓸 수 있습니다.

한 사람이 조사원 한 명 한 명에게 일일이 지시하는 대신, 프로젝트 매니저가 즉석에서 업무 분장표를 짜고 수십~수백 명의 임시 조사원을 병렬로 투입한 뒤 결과를 교차 검증해 하나의 보고서로 합치는 것과 비슷합니다. 코드베이스 전역 버그 헌트, 대규모 마이그레이션, 보안 감사, 복잡한 아키텍처 분석처럼 "단일 에이전트로는 너무 큰" 작업에 맞는 도구입니다.

참고로 /goal이 하나의 작업을 조건 충족까지 파고드는 "깊이(depth)" 지향이라면, dynamic workflows는 하나의 작업을 여러 갈래로 넓혀 처리하는 "폭(width)" 지향으로 대비됩니다.

Verification loops — 만든 에이전트와 검사하는 에이전트 분리하기

dynamic workflows 안에는 결과의 신뢰성을 높이는 오케스트레이션 패턴이 하나 내장돼 있습니다. 바로 verification loop입니다. 어떤 에이전트가 발견(finding)을 만들면, 그 발견을 반증하는 것만이 임무인 별도 에이전트를 생성해 기준에 대조시키는 방식입니다.

핵심은 이 두 에이전트가 컨텍스트 창을 공유하지 않는다는 점입니다. 생산자(작업한 에이전트)와 회의론자(검증하는 에이전트)가 서로의 작업 맥락을 모른 채로 마주치기 때문에, 자기 결과를 스스로 정당화하려는 편향이 구조적으로 줄어듭니다. 회의론자가 무너뜨리지 못한 발견만 최종 보고서에 남습니다.

논문 심사와 비슷합니다. 저자가 주장을 내면, 저자와 말도 섞지 않은 독립 심사위원이 "이게 정말 맞나?"만 파고듭니다. 심사를 통과한 주장만 최종 결과에 실립니다. 공식 문서가 드는 예시는 "src/routes/ 아래 모든 라우트 핸들러에서 인증 검사 누락을 감사하고, 각 발견을 보고 전에 적대적으로 검증하라"는 지시입니다. pipeline()으로 git diff에 리뷰 에이전트를 돌린 뒤, 각 발견을 병렬로 반증 검토하는 식입니다.

실전 사례로 보는 Claude Code 자동화

사례 1. 야간 무인 유지보수 (routines)

/schedule로 "매일 새벽 3시(cron 0 3 * * *)에 의존성 업데이트를 확인하고, 취약점이 있으면 패치 PR을 열어라"를 등록해 둡니다. 노트북이 꺼져 있어도 클라우드에서 실행되므로, 아침에 출근하면 PR이 이미 열려 있습니다. GitHub 이벤트 트리거를 함께 걸면 "PR이 열릴 때마다" 자동 리뷰도 붙일 수 있습니다.

사례 2. 테스트 통과까지 자율 반복 (goal + loop)

/goal 전체 테스트가 skip·warning 없이 통과한다 /loop every 2m until: tests pass

사람이 매번 "다시 돌려봐"라고 치지 않아도 됩니다. 작업 모델이 코드를 고치면, 별도의 Haiku 평가자가 "정말 통과했는가"를 매 턴 독립적으로 확인하고, 통과할 때까지 이 과정을 반복하다 통과하는 순간 멈춥니다.

사례 3. 코드베이스 전역 보안 감사 (dynamic workflows + verification)

"모든 라우트 핸들러의 인증 누락을 감사하라"는 한 줄 지시에 Claude가 오케스트레이션 스크립트를 작성합니다. 수백 개 서브에이전트가 파일들을 병렬로 조사하고, 각 "인증 누락 의심" 발견마다 독립 회의론자 에이전트가 반증을 시도합니다. 살아남은 진짜 문제만 최종 보고서에 담기고, 그동안 세션은 계속 다른 작업에 응답할 수 있는 상태를 유지합니다.

프롬프트를 매번 치는 것과 비교했을 때 실질적으로 얻는 것

과장 없이, 공식 문서가 명시한 설계 목표와 동작 범위 안에서만 정리하면 다음과 같습니다.

반복 개입 제거 — 배포 확인, 테스트 재실행, 야간 점검처럼 "주기적으로 다시 시켜야 하는" 일을 /loop과 routines가 대신합니다. 사람은 조건과 목표만 정의하면 됩니다.
완료 판정의 객관화 — /goal은 일하는 모델이 스스로 "다 됐다"고 판단하는 상황을 막고, 별도 평가자 모델이 조건 충족을 확인해야만 멈춥니다.
병렬 규모 확장 — dynamic workflows는 단일 에이전트로는 버거운 코드베이스 전역 작업을 수백 개 서브에이전트로 병렬 분해합니다.
결과 신뢰성 — 생산자와 회의론자가 컨텍스트를 공유하지 않는 verification 패턴이 자기 검증 편향을 줄여, 단일 패스보다 신뢰할 만한 결과를 냅니다.
로컬 의존 탈피 — routines는 클라우드 실행이라 개인 머신의 전원·네트워크 상태와 무관하게 자동화가 지속됩니다.

다만 온라인에서 종종 도는 과장된 성과 주장(특정 비율만큼 코드를 알아서 써 준다거나, 사람이 더는 손댈 필요가 없다는 식의 이야기)은 이 글에서 다루지 않습니다. 공식 문서가 명시한 동작 범위를 벗어나 검증하기 어려운 내용이기 때문입니다. 이 글의 수치와 동작은 모두 Anthropic 공식 문서·블로그에서 확인한 것만 담았습니다.

마무리

Claude Code 자동화는 하나의 만능 버튼이 아니라, 상황에 맞는 네 가지 도구입니다. 시간 간격으로 반복해야 하면 /loop, 조건 충족 여부로 판단해야 하면 /goal, 노트북 전원과 무관하게 돌아야 하면 routines(스케줄), 작업 규모가 혼자 감당하기 버거우면 dynamic workflows(/ultracode)를 씁니다. 그리고 그 안에 있는 verification loop이 "만든 사람과 검사하는 사람을 분리"하는 원칙으로 결과의 신뢰도를 받쳐 줍니다. Claude Code 자동화를 오늘 하나만 골라 써 본다면, 지금 반복하고 있는 프롬프트 하나를 /loop이나 /goal로 옮겨보는 것부터 시작해 보시길 권합니다.

자주 묻는 질문 (FAQ)

Q: `/loop`과 `/goal`은 어떻게 다른가요?

/loop은 정해진 시간 간격(예: 5분마다)마다 같은 프롬프트를 다시 실행하고, 사람이 멈추기 전까지 계속 돕니다. /goal은 시간이 아니라 조건을 기준으로 삼아서, 별도의 평가자 모델이 매 턴 "조건이 충족됐는가"를 확인하고 충족되는 순간 스스로 멈춥니다.

Q: routines(스케줄)는 노트북을 꺼도 정말 실행되나요?

네, routines는 Claude Code 웹 인프라에서 실행되도록 설계됐습니다. 노트북 전원이나 터미널이 열려 있는지와 무관하게 클라우드에서 돕니다. 다만 실행 한도는 플랜별로 다릅니다(Pro 5회/일, Max 15회/일, Team·Enterprise 25회/일).

Q: `/ultracode`는 언제 쓰는 게 맞나요?

작업 하나가 단일 에이전트로 처리하기엔 너무 큰 경우입니다. 코드베이스 전역 버그 헌트, 대규모 마이그레이션, 보안 감사처럼 파일 수백~수천 개를 동시에 훑어야 하는 작업에 적합합니다. 반대로 하나의 작업을 조건 충족까지 깊게 파고드는 경우라면 /goal이 더 맞습니다.

Q: verification loop을 쓰려면 별도로 설정해야 하나요?

verification loop은 별도 기능이 아니라 dynamic workflows 안에 내장된 오케스트레이션 패턴입니다. 오케스트레이션 스크립트를 작성할 때 발견을 검증하는 별도 에이전트를 함께 구성하면 되고, 공식 문서에도 pipeline()으로 리뷰와 적대적 검증을 함께 구성하는 예시가 실려 있습니다.

Claude Code 자동화 완전 정리: loops·goal·routines·workflows 가이드