# 루프 시작하기

> Clean Markdown view of GeekNews topic #31225. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31225](https://news.hada.io/topic?id=31225)
- GeekNews Markdown: [https://news.hada.io/topic/31225.md](https://news.hada.io/topic/31225.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-08T09:40:02+09:00
- Updated: 2026-07-08T09:40:02+09:00
- Original source: [x.com/ClaudeDevs](https://x.com/ClaudeDevs/status/2074208949205881033)
- Points: 13
- Comments: 0

## Topic Body

- 코딩 에이전트에 매 프롬프트를 지시하는 방식 대신, **정지 조건이 충족될 때까지 작업 사이클을 반복**하는 에이전트 운영 패턴으로 전환 중  
- 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 활용  
- 시작 방법은 이미 하는 작업을 살펴 **본인이 병목인 작업 하나**를 골라 위임 가능한 부분 판단  
  - 검증 체크를 작성할 수 있는가  
  - 목표가 충분히 명확한가  
  - 작업이 스케줄로 도착하는가  
- 아이디어가 생기면 루프를 실행하고 정체나 과도 실행 지점을 관찰, **반복 개선**을 두려워하지 말 것

## Comments



_No public comments on this page._