코딩 에이전트에 매 프롬프트를 지시하는 방식 대신, 정지 조건이 충족될 때까지 작업 사이클을 반복하는 에이전트 운영 패턴으로 전환 중

Claude Code 팀은 루프를 트리거 방식, 정지 방식, 사용 primitive, 적합 작업 유형 네 기준으로 분류

주요 루프 유형은 Turn-based, Goal-based, Time-based, Proactive 네 가지로 구성

모든 작업에 복잡한 루프가 필요한 것은 아니며, 가장 단순한 해법부터 시작해 선택적으로 패턴 적용

루프 출력 품질은 주변 시스템에 좌우되므로 코드 품질 유지와 토큰 사용 관리가 핵심

루프의 정의와 분류 기준

Claude Code 팀은 루프를 정지 조건이 충족될 때까지 작업 사이클을 반복하는 에이전트로 정의

루프 분류의 네 가지 기준 제시

어떻게 트리거되는가

어떻게 정지되는가

어떤 Claude Code primitive를 사용하는가

어떤 유형의 작업에 가장 적합한가

복잡한 루프가 항상 필요한 것은 아니며, 단순한 해법 우선 후 패턴을 선택적으로 사용

Turn-based 루프

사용자 프롬프트로 트리거되며, Claude가 작업 완료를 판단하거나 추가 맥락이 필요할 때 정지

정기 프로세스나 스케줄에 속하지 않는 짧은 작업에 적합

관리 방법은 구체적 프롬프트 작성과 skills를 활용한 검증 개선으로 턴 수 감소

모든 프롬프트는 사용자가 각 턴을 지시하는 수동 루프를 시작, 이를 agentic loop로 지칭

Claude가 맥락 수집 → 액션 수행 → 작업 확인 → 필요 시 반복 → 응답

예: like 버튼 생성 요청 시 코드 읽기, 편집, 테스트 실행 후 결과 반환, 이후 사용자가 수동 확인 후 다음 프롬프트 작성

검증 단계는 수동 절차를 SKILL.md로 인코딩해 Claude의 자체 확인 범위를 확대 가능

결과를 보고 측정하거나 상호작용할 도구·커넥터 포함 필요

정량적 검증일수록 자체 검증이 용이

SKILL.md 예시 (verify-frontend-change)

UI 변경을 완료 선언 전 엔드투엔드로 검증하는 규칙

편집 성공만으로 완료 보고 금지, 사람 리뷰어처럼 검증

dev 서버 시작 후 편집한 페이지를 브라우저로 열기

변경 요소를 직접 조작(버튼·입력·토글 클릭), 상태 변화 확인, 전후 스크린샷

브라우저 콘솔에서 신규 에러·경고 제로 확인

Chrome Devtools MCP로 성능 트레이스 실행 및 Core Web Vitals 감사

단계 실패 시 수정 후 1단계부터 재실행, 부분 검증 상태로 반환 금지

Goal-based 루프 (/goal)

실시간 수동 프롬프트로 트리거되며, 목표 달성 또는 최대 턴 수 도달 시 정지

검증 가능한 종료 기준을 가진 작업에 적합

관리 방법은 구체적 완료 기준과 명시적 턴 상한 설정, "5회 시도 후 정지"

단일 턴으로 부족한 복잡한 작업에서 에이전트는 반복(iterate) 시 성능 향상

/goal로 완료 상태를 정의하면 Claude가 "충분히 좋은지" 스스로 판단해 조기 종료하지 않음

Claude가 정지 시도 때마다 evaluator 모델이 조건을 확인, 목표 달성 또는 지정 턴 수 도달까지 재작업

통과 테스트 수, 특정 점수 임계치 등 결정론적 기준이 효과적

예시

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

Time-based 루프 (/loop와 /schedule)

지정된 시간 간격으로 트리거되며, 사용자 취소 또는 작업 완료(PR 병합, 큐 비움) 시 정지

반복 작업이나 외부 환경·시스템과의 인터페이스에 적합

관리 방법은 간격을 길게 설정하거나 시간이 아닌 이벤트 기반 반응

일부 agentic 작업은 반복적이며 작업은 동일하고 입력만 변경, 예: 매일 아침 Slack 메시지 요약

외부 시스템 의존 작업은 간격마다 확인 후 변경에 반응하는 방식으로 인터페이스, 예: 코드 리뷰나 CI 실패가 발생하는 PR

/loop은 프롬프트를 간격마다 재실행

/loop 5m check my PR, address review comments, and fix failing CI

/loop은 사용자 컴퓨터에서 실행되어 종료 시 중단, /schedule로 routine을 만들어 클라우드로 이동 가능

Proactive 루프

이벤트나 스케줄로 트리거되며 실시간 사람 개입 없음

각 작업은 목표 달성 시 종료, routine 자체는 사용자가 끌 때까지 실행

버그 리포트, 이슈 분류, 마이그레이션, 의존성 업그레이드 등 잘 정의된 반복 작업 흐름에 적합

관리 방법은 routine을 더 작고 빠른 모델로 라우팅하고, 판단이 필요한 부분에만 가장 강력한 모델 사용

위 primitive들과 auto mode, dynamic workflows(research preview) 등을 조합해 장기 실행 루프 구성

피드백 처리 구성 예시

/schedule(research preview)로 신규 리포트 확인 routine 실행

/goal로 완료 정의, skills로 검증 방법 문서화

Dynamic workflows로 각 리포트 분류·수정·검토 에이전트 오케스트레이션

Auto mode로 권한 확인 없이 routine 실행

통합 프롬프트 예: /schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.

코드 품질 유지

루프 출력 품질은 주변 시스템에 좌우되므로 시스템 설계가 중요

코드베이스 청결 유지: Claude는 기존 코드베이스의 패턴과 컨벤션을 따름

자체 검증 수단 제공: skills로 팀 기준의 "좋은 상태"를 인코딩

문서 접근 용이화: 프레임워크·라이브러리 문서에 최신 베스트 프랙티스 존재

코드 리뷰용 second agent 사용: 새 맥락의 리뷰어가 편향이 적고 메인 에이전트 추론에 영향받지 않음, 내장 /code-review skill 또는 Github용 Code Review 활용

개별 결과가 기준 미달 시 개별 이슈 수정에 그치지 않고, 시스템 자체를 개선하도록 인코딩

토큰 사용 관리

루프는 명확한 경계를 가져야 하며 다음 원칙 적용

적합한 primitive·모델 선택: 작은 작업엔 다중 에이전트나 루프 불필요, 일부 작업은 저렴하고 빠른 모델 사용

명확한 성공·정지 기준 정의: 완료 상태를 구체화해 너무 이르지 않게 조기 도달

대규모 실행 전 파일럿: dynamic workflows는 수백 개 에이전트 생성 가능, 작은 범위로 먼저 사용량 측정

결정론적 작업엔 스크립트 사용: 단계를 추론하기보다 스크립트 실행이 저렴, 예: PDF skill이 폼 채우기 스크립트를 제공해 매번 코드 재생성 대신 실행

필요 이상으로 routine 미실행: 감시 대상의 변경 빈도에 간격을 맞춤

사용량 검토: /usage는 skills·subagents·MCPs별 사용량 분석, 인자 없는 /goal은 현재 턴 수와 토큰 사용량 표시, /workflows는 각 에이전트의 토큰 사용량 표시 및 언제든 중지 가능

시작하기

루프 유형별 요약

Turn-based: 검증(check)을 위임, 탐색·결정 시 사용, 커스텀 검증 skills 활용

Goal-based: 정지 조건을 위임, 완료 상태를 알 때 사용, /goal 활용

Time-based: 트리거를 위임, 프로젝트 외부에서 스케줄로 작업이 발생할 때 사용, /loop·/schedule 활용

Proactive: 프롬프트를 위임, 반복적이고 잘 정의된 작업일 때 사용, 위 모든 것과 dynamic workflows 활용

시작 방법은 이미 하는 작업을 살펴 본인이 병목인 작업 하나를 골라 위임 가능한 부분 판단

검증 체크를 작성할 수 있는가

목표가 충분히 명확한가

작업이 스케줄로 도착하는가

아이디어가 생기면 루프를 실행하고 정체나 과도 실행 지점을 관찰, 반복 개선을 두려워하지 말 것