• 출처: Anthropic 블로그 Getting Started with Loops (Delba de Oliveira, Michael Segner).
  • 루프: 에이전트가 정지 조건을 충족할 때까지 작업 사이클을 반복하는 것.
    • 사람이 매 턴을 지시하는 대신, 에이전트가 스스로 “맥락 수집 → 실행 → 검증 → 필요 시 반복"을 돌게 만든다.
  • 핵심 메시지: 루프 자체가 새로운 게 아니라, 어떤 작업을 어떤 종류의 루프에 위임하느냐를 고르는 안목이 중요하다. 위임할수록 사람은 감독만 하면 된다.
  • 루프를 분류하는 4가지 축:
    • 트리거: 어떻게 시작되는가.
    • 중지 기준: 언제 끝나는가.
    • 프리미티브: 어떤 도구를 쓰는가.
    • 작업 특성: 어떤 일에 적합한가.

4가지 루프 타입

타입트리거중지 기준적합한 작업도구
턴 기반사용자 프롬프트Claude가 완료·추가정보 필요 판단짧은 일회성 작업커스텀 Skill
목표 기반사용자 프롬프트목표 달성 또는 최대 턴 도달검증 가능한 종료 기준이 있는 작업/goal
시간 기반지정된 시간 간격사용자 취소 또는 작업 완료반복 작업, 외부 시스템 모니터링/loop, /schedule
사전 대응형이벤트·스케줄 (실시간 사용자 없음)각 작업은 목표 달성 시, 루틴은 사용자가 중지할 때까지반복되는 잘 정의된 작업위 전부 + Dynamic Workflows

턴 기반 루프 (Turn-based)

  • 사람이 프롬프트로 한 턴씩 지시하는 수동 루프. 가장 기본 형태.
  • 위임 대상은 **검증(verification)**이다. 프롬프트나 Skill에 “무엇이 잘 된 상태인지"를 인코딩하면 Claude가 스스로 확인한다.
    • 예: UI 변경 검증을 SKILL.md에 넣어두면 Claude가 개발 서버 기동 → 브라우저로 페이지 확인 → 버튼 클릭 등 직접 상호작용 → 콘솔 오류 확인 → DevTools 성능 추적까지 알아서 수행한다.
  • 토큰 관리: 프롬프트를 구체적으로 쓰고, 검증은 Skill로 강화한다.

목표 기반 루프 (/goal)

  • 단일 턴으로 부족한 복잡한 작업에서, 평가자(evaluator) 모델이 성공 조건을 검증하고 미달이면 다시 작업하도록 지시한다.
  • 위임 대상은 중지 조건 판단이다. Claude가 “이 정도면 됐다"며 일찍 멈추는 것을 막는다.
  • 예: /goal 홈페이지 Lighthouse 점수를 90 이상으로, 5회 시도 후 중지.
  • 토큰 관리: 명확한 성공 기준 + 명시적 턴 제한을 반드시 건다.

시간 기반 루프 (/loop, /schedule)

  • 지정한 간격마다 같은 프롬프트를 반복 실행한다. 위임 대상은 트리거(언제 실행할지).
  • 두 명령의 차이:
명령동작실행 위치
/loop설정 간격으로 프롬프트 반복로컬 머신 (항상 켜져 있어야 함)
/schedule루틴을 클라우드에서 실행클라우드 (24/7)
  • 활용 예: 매일 아침 Slack 요약, PR 리뷰 반영 + CI 실패 수정 모니터링.
    • 예: /loop 5분마다: PR 확인, 리뷰 의견 반영, 실패한 CI 수정.
  • 종료는 사용자 취소 외에 “PR 머지”, “큐 비워짐” 같은 작업 완료 조건으로도 걸 수 있다.
  • 토큰 관리: 간격을 넉넉히 두거나 이벤트 기반으로 반응하게 한다.

사전 대응형 루프 (Proactive)

  • 실시간 사용자 없이 이벤트·스케줄로 돌아가는, 앞 세 가지를 조합한 최종 형태. 위임 대상은 초기 프롬프트뿐이다.
  • 구성:
    • /schedule: 새 입력(예: 버그 리포트)을 주기적으로 확인.
    • /goal: 명확한 종료 기준 정의.
    • Dynamic Workflows: 여러 에이전트 조율 (병렬 탐색, 판사 리뷰).
    • Auto mode: 승인 없이 자동 실행.
  • 통합 예: 매시간 #project-feedback에서 버그 리포트 확인 → 모두 분류·조치·응답할 때까지 중지 금지 → 3개 병렬 워크트리에서 해법 탐색 후 판사가 적대적으로 검토.
  • 적합 작업: 버그 리포트 처리, 이슈 분류, 마이그레이션처럼 반복되고 잘 정의된 일.
  • 토큰 관리: 작은 모델로 라우팅하고, 판단이 필요한 작업만 강력한 모델에 맡긴다.

루프 품질은 주변 시스템이 결정한다

  • 루프의 결과 품질은 루프 로직이 아니라 에이전트를 둘러싼 환경에 달려 있다.
    • 깨끗한 코드베이스: Claude는 기존 패턴·관례를 따르므로, 코드가 정돈돼 있어야 반복 결과도 좋다.
    • 자체 검증 능력: Skill로 “좋은 코드"의 정의를 인코딩해 Claude가 스스로 채점하게 한다.
    • 문서 접근성: 프레임워크·라이브러리의 최신 베스트 프랙티스를 제공한다.
    • 코드 리뷰 자동화: 별도 리뷰어 에이전트(/code-review Skill, GitHub Code Review)를 붙인다.
  • 핵심 원칙: 실패를 만나면 그 한 번을 고치고 끝내지 말고, 다음 반복이 재현하지 않도록 시스템에 인코딩하라.

토큰 사용량 관리

  • 가장 큰 비용 요인은 모델 선택과 effort level 설정이다. (참고: Claude Code 모델과 Effort Level.md)
  • 절약 전략:
    • 올바른 프리미티브·모델 선택: 작은 작업에 루프나 비싼 모델을 쓰지 않는다.
    • 명확한 성공·중지 기준: 완료 정의가 정확할수록 빨리 끝난다.
    • 파일럿 운영: Dynamic Workflows를 대규모로 돌리기 전에 소규모로 검증한다.
    • 결정론적 작업은 스크립트화: 추론보다 스크립트 실행이 싸다 (예: PDF 양식 채우기).
    • 루틴 빈도 최적화: 대상이 바뀌는 빈도에 맞춰 실행 간격을 조정한다.
  • 사용량 점검 명령: /usage(종합 분석), /goal(턴·토큰 현황), /workflows(에이전트별 사용량).

어떤 루프부터 시작할까

  • 시작 절차:
    1. 지금 하는 작업을 훑는다.
    2. 병목인 작업을 하나 고른다.
    3. 위임 가능한지 따진다 — 검증 체크를 작성할 수 있는가 / 목표가 명확한가 / 작업이 정기적으로 도착하는가.
    4. 루프를 돌리고 관찰한다.
    5. 실패 지점·과도한 실행을 분석해 개선한다.
  • 판단 기준: 검증을 자동화할 수 있으면 턴 기반, 종료 조건이 명확하면 목표 기반, 정기적으로 발생하면 시간 기반, 이 셋이 모두 성립하면 사전 대응형으로 완전 위임한다.