Claude Code 루프 — 작업 사이클을 자동화하는 네 가지 패턴

Claude Code 팀이 코딩 에이전트를 사용할 때, 매번 새 프롬프트를 직접 작성하는 방식에서 벗어나는 중입니다. 대신 정지 조건이 충족될 때까지 작업 사이클을 반복하는 에이전트 운영 패턴으로 전환하고 있습니다. 이 글에서는 그 네 가지 루프 패턴(Turn-based, Goal-based, Time-based, Proactive)을 정리하고, 각 패턴이 어떤 작업에 적합한지, 운영 시 주의할 점은 무엇인지 살펴봅니다.

루프의 정의와 네 가지 분류 기준

Claude Code 팀은 루프를 정지 조건이 충족될 때까지 작업 사이클을 반복하는 에이전트로 정의합니다. 그리고 모든 루프를 다음 네 가지 기준으로 분류합니다.

• 어떻게 트리거되는가
• 어떻게 정지되는가
• 어떤 Claude Code primitive를 사용하는가
• 어떤 유형의 작업에 가장 적합한가

핵심은 "복잡한 루프가 항상 필요한 것은 아니다"입니다. 가장 단순한 해법부터 시작해서 필요할 때만 패턴을 선택적으로 적용하는 것이 권장됩니다.

1) Turn-based 루프

• 사용자 프롬프트로 트리거되며, Claude가 작업 완료를 판단하거나 추가 맥락이 필요할 때 정지합니다. 정기 프로세스나 스케줄에 속하지 않는 짧은 작업*에 적합합니다. 관리 방법은 구체적인 프롬프트 작성과 skills를 활용한 검증 개선으로 턴 수를 줄이는 것입니다.

실제로 모든 프롬프트는 사용자가 각 턴을 지시하는 수동 루프를 시작합니다. 이를 agentic loop라고 부르며, 흐름은 다음과 같습니다.

• Claude가 맥락 수집 → 액션 수행 → 작업 확인 → 필요 시 반복 → 응답
• 예: like 버튼 생성 요청 시 코드 읽기, 편집, 테스트 실행 후 결과 반환, 이후 사용자가 수동 확인 후 다음 프롬프트 작성

검증 단계는 수동 절차를 SKILL.md로 인코딩해 Claude의 자체 확인 범위를 넓힐 수 있습니다. 예시로 verify-frontend-change 스킬은 UI 변경을 완료 선언 전에 엔드투엔드로 검증하도록 강제합니다.

• dev 서버 시작 후 편집한 페이지를 브라우저로 열기
• 변경 요소를 직접 조작(버튼·입력·토글 클릭), 상태 변화 확인, 전후 스크린샷
• 브라우저 콘솔에서 신규 에러·경고 제로 확인
• Chrome DevTools MCP로 성능 트레이스 실행 및 Core Web Vitals 감사

2) Goal-based 루프 (`/goal`)

• 실시간 수동 프롬프트로 트리거되며, 목표 달성 또는 최대 턴 수 도달 시 정지합니다. 검증 가능한 종료 기준을 가진 작업에 적합합니다. 단일 턴으로 부족한 복잡한 작업에서 에이전트는 반복(iterate)*할수록 성능이 향상됩니다.

/goal로 완료 상태를 정의하면 Claude가 "충분히 좋은지" 스스로 판단해 조기 종료하지 않습니다. Claude가 정지를 시도할 때마다 evaluator 모델이 조건을 확인하고, 목표 달성 또는 지정 턴 수 도달까지 재작업을 지시합니다. 효과적인 종료 기준은 다음과 같습니다.

• 통과 테스트 수, 특정 점수 임계치 등 결정론적 기준
• 예: /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

3) Time-based 루프 (`/loop`, `/schedule`)

• 지정된 시간 간격으로 트리거되며, 사용자 취소 또는 작업 완료(PR 병합, 큐 비움) 시 정지합니다. 반복 작업*이나 외부 환경·시스템과의 인터페이스에 적합합니다.

• /loop은 프롬프트를 간격마다 재실행합니다. 예: /loop 5m check my PR, address review comments, and fix failing CI
• /loop은 사용자 컴퓨터에서 실행되어 종료 시 중단되며, /schedule로 routine을 만들어 클라우드로 이동 가능합니다.

4) Proactive 루프

• 이벤트나 스케줄로 트리거되며 실시간 사람 개입이 없습니다. 각 작업은 목표 달성 시 종료하지만, routine 자체는 사용자가 끌 때까지 실행됩니다. 잘 정의된 반복 작업 흐름*(버그 리포트, 이슈 분류, 마이그레이션, 의존성 업그레이드 등)에 적합합니다.

예를 들어 피드백 처리는 다음과 같이 구성할 수 있습니다.

• /schedule(research preview)로 신규 리포트 확인 routine 실행
• /goal로 완료 정의, skills로 검증 방법 문서화
• Dynamic workflows로 각 리포트 분류·수정·검토 에이전트 오케스트레이션
• Auto mode로 권한 확인 없이 routine 실행

코드 품질 유지가 모든 루프의 전제 조건

루프 출력 품질은 주변 시스템에 좌우되므로 시스템 설계가 중요합니다. Claude Code 팀이 강조하는 핵심은 다음과 같습니다.

• 코드베이스 청결 유지: Claude는 기존 코드베이스의 패턴과 컨벤션을 따릅니다
• 자체 검증 수단 제공: skills로 팀 기준의 "좋은 상태"를 인코딩
• 문서 접근 용이화: 프레임워크·라이브러리 문서에 최신 베스트 프랙티스 존재
• 코드 리뷰용 second agent 사용: 새 맥락의 리뷰어가 편향이 적고 메인 에이전트 추론에 영향받지 않음

정리: 어떤 작업에 어떤 루프를 적용할까

루프 도입 전 다음 세 가지로 시작해 보세요.

• 위임 가능한 작업 하나를 골라 위임 가능한 부분 판단
• 검증 체크를 작성할 수 있는가
• 목표가 충분히 명확한가
• 작업이 스케줄로 도착하는가

아이디어가 생기면 루프를 실행하고 정체나 과도 실행 지점을 관찰한 뒤, 반복 개선을 두려워하지 마세요. 가장 단순한 해법부터 시작해 점진적으로 패턴을 도입하는 것이 핵심입니다.