루프 시작하기

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

함께 보면 좋은 글 β