루프 시작하기

요즘 코딩 에이전트에 프롬프트를 입력하는 대신 '루프를 설계'해야 한다는 이야기가 많습니다. X(구 트위터)에서 루프가 정확히 무엇인지 찾아보면 사람마다 다른 답을 내놓습니다.

Claude Code 팀에서는 루프를 '종료 조건이 충족될 때까지 에이전트가 작업 주기를 반복하는 것'으로 정의합니다. 루프는 다음 기준에 따라 몇 가지 유형으로 분류됩니다:

• 실행 트리거
• 종료 방식
• 사용하는 Claude Code 기본 요소
• 각각에 적합한 작업 유형

이 글에서는 주요 루프 유형과 각각의 활용 시점, 그리고 토큰 사용량을 관리하면서 코드 품질을 유지하는 방법을 살펴봅니다. 모든 작업에 복잡한 루프가 필요한 건 아닙니다. 가장 단순한 방법에서 시작해, 필요한 경우에만 이 패턴을 선택적으로 활용하세요.

턴 기반 루프

트리거: 사용자 프롬프트‍

종료 기준: Claude가 작업을 완료했다고 판단하거나 추가 컨텍스트가 필요하다고 판단할 때

적합한 작업: 정기적인 프로세스나 일정에 포함되지 않는 단기 작업

사용량 관리: 구체적인 프롬프트를 작성하고, 스킬을 활용해 검증 단계를 개선하여 턴 수 줄이기

프롬프트를 입력할 때마다 수동 루프가 시작되며, 각 턴을 직접 지시하게 됩니다. Claude는 컨텍스트를 수집하고, 작업을 수행하고, 결과를 확인하고, 필요하면 반복한 뒤 응답합니다. 이를 에이전트 루프(agentic loop)라고 합니다.

예를 들어, Claude에게 좋아요 버튼을 만들어 달라고 요청하면, 코드를 읽고 수정한 뒤 테스트를 실행하고 작동한다고 판단한 결과물을 전달합니다. 이후 직접 결과를 확인하고 다음 프롬프트를 작성하게 됩니다.

수동으로 수행하던 단계를 SKILL.md에 정의해 두면 Claude가 엔드투엔드로 더 많은 부분을 스스로 검증할 수 있습니다. 이를 위해 Claude가 결과를 확인하고, 측정하고, 상호작용할 수 있는 도구나 커넥터를 포함해야 합니다. 검증 항목이 정량적일수록 Claude의 자체 검증이 수월해집니다.

예를 들어, SKILL.md 파일에 다음과 같이 정의할 수 있습니다:

--- 
name: verify-frontend-change 
description: Verify any UI change end-to-end before declaring it done. 
--- 

# Verifying frontend changes 
Never report a UI change as complete based on a successful edit alone. Verify it the way a human reviewer would: 

1. Start the dev server and open the edited page in the browser. 

2. Interact with the change directly. For a new control (button, input, toggle): click it, confirm the expected state change, and screenshot before/after. 

3. Check the browser console: zero new errors or warnings. 

4. Use the Chrome Devtools MCP, run a performance trace and audit Core Web Vitals.

If any step fails, fix the issue and rerun from step 1 — do not hand back partially verified work.

목표 기반 루프 (/goal)

트리거: 실시간 수동 프롬프트

종료 기준: 목표 달성 또는 최대 턴 수 도달

적합한 작업: 검증 가능한 종료 기준이 있는 작업

사용량 관리: 구체적인 완료 기준과 명시적인 턴 상한선 설정하기. 예: "5번 시도 후 중단"

‍

복잡한 작업일수록 단 한 번의 턴으로는 부족한 경우가 많습니다. 에이전트는 반복을 통해 더 나은 결과를 냅니다. /goal을 사용해 완료 기준을 정의하면 Claude가 반복을 이어가는 시간을 늘릴 수 있습니다.

성공 기준을 명확히 정의해 두면 Claude가 '이 정도면 충분하다'고 스스로 판단해 루프를 일찍 종료하는 일이 없어집니다. Claude가 멈추려 할 때마다 평가(evaluation) 모델이 조건을 확인하고, 목표가 달성되거나 정해진 턴 수에 도달할 때까지 작업을 이어가도록 합니다.

이것이 바로 테스트 통과 수나 특정 점수 기준 충족처럼 결정론적 기준이 효과적인 이유입니다.

예시:

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

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

트리거: 지정된 시간 간격

종료 기준: 직접 취소하거나, 작업이 완료될 때 (PR이 병합되거나 큐가 비워질 때)

적합한 작업: 반복 작업, 또는 외부 환경 및 시스템과의 연동

사용량 관리: 간격을 길게 설정하거나, 시간이 아닌 이벤트 기반으로 반응하기

에이전트 작업 중에는 반복적인 것들이 있습니다. 작업 자체는 동일하고 입력만 바뀌는 경우입니다. 매일 아침 Slack 메시지를 요약하는 작업이 대표적인 예입니다. 외부 시스템과 연동해야 하는 작업도 있는데, 가장 간단한 방법은 일정 간격으로 시스템을 확인하고 변경 사항에 반응하는 것입니다. 코드 리뷰가 달리거나 CI가 실패할 수 있는 PR이 좋은 예입니다.

이런 경우 `/loop`를 사용해 Claude의 실행 시점을 지정할 수 있습니다. `/loop`는 지정된 간격으로 프롬프트를 반복 실행합니다. 예:

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

`/loop`는 로컬 컴퓨터에서 실행되므로 컴퓨터를 끄면 중단됩니다. `/schedule`로 루틴을 생성하면 루프를 클라우드로 옮길 수 있습니다.

능동적 루프

트리거: 이벤트 또는 일정 (실시간 사람 개입 없음)

종료 기준: 각 작업은 목표 달성 시 종료. 루틴 자체는 직접 끌 때까지 실행됨

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

사용량 관리: 루틴은 더 작고 빠른 모델에 할당하고, 판단이 필요한 작업에만 가장 성능이 높은 모델 사용하기

위의 기본 요소들을 auto mode와 dynamic workflows(리서치 프리뷰) 등 Claude Code의 다른 기능들과 조합하면 장기 실행 작업을 위한 루프를 구성할 수 있습니다.

예를 들어, 들어오는 피드백을 처리하기 위해 다음을 활용할 수 있습니다:

1. `/schedule` (리서치 프리뷰)로 새 리포트를 확인하는 루틴 실행
2. `/goal`로 완료 기준을 정의하고, 스킬로 검증 방법을 문서화
3. Dynamic workflows로 각 리포트를 분류하고, 수정하고, 수정 사항을 검토하는 에이전트 오케스트레이션
4. Auto mode로 권한 요청 없이 루틴 실행

이를 모두 합치면 프롬프트는 다음과 같은 형태가 됩니다:

/schedule every hour: check #project-feedback 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는 코드베이스에 이미 존재하는 패턴과 관행을 따릅니다.
• Claude가 스스로 결과를 검증할 수 있도록 하기: 스킬을 활용해 팀이 생각하는 '좋은 코드'의 기준을 정의하세요.
• 문서에 쉽게 접근하기: 프레임워크와 라이브러리 문서에는 최신 모범 사례가 담겨 있습니다.
• 코드 리뷰에 두 번째 에이전트 활용하기: 새로운 컨텍스트를 가진 리뷰어는 편향이 적고 메인 에이전트의 추론에 영향받지 않습니다. 내장된 `/code-review` 스킬이나 GitHub용 Code Review를 사용할 수 있습니다.

개별 결과가 기준에 미치지 못할 때, 단순히 해당 문제만 수정하는 데 그치지 마세요. 이를 시스템에 반영해 향후 모든 반복 작업의 품질을 높이세요.

토큰 사용량 관리

토큰 사용량을 관리하려면 루프의 경계를 명확히 해야 합니다:

• 작업에 맞는 기본 요소와 모델 선택하기: 소규모 작업에는 여러 에이전트나 루프가 필요하지 않습니다. 일부 작업은 더 저렴하고 빠른 모델로도 충분합니다.
• 명확한 성공 및 종료 기준 정의하기: 완료 상태를 구체적으로 명시해 Claude가 적절한 시점에 해결책에 도달할 수 있도록 하세요 (너무 이르지도 않게).
• 대규모 실행 전에 파일럿 테스트하기: Dynamic workflows는 수백 개의 에이전트를 생성할 수 있습니다. 먼저 작은 규모로 사용량을 파악하세요.
• 결정론적 작업에는 스크립트 사용하기: 스크립트 실행이 단계를 추론하는 것보다 비용이 적게 듭니다. 예를 들어 PDF 스킬은 매번 코드를 새로 도출하는 대신, Claude가 실행할 수 있는 양식 작성 스크립트를 포함할 수 있습니다.
• 필요 이상으로 루틴을 자주 실행하지 않기: 모니터링 대상이 변경되는 빈도에 맞춰 간격을 설정하세요
• 사용량 확인하기: `/usage` 명령어로 스킬, 서브에이전트, MCP별 최근 사용량을 확인할 수 있습니다. 인수 없이 `/goal`을 입력하면 지금까지의 턴 수와 토큰 사용량을 볼 수 있고, `/workflows`는 각 에이전트의 토큰 사용량을 보여주며 언제든지 에이전트를 중단할 수 있습니다.

시작하기

정리하면:

루프를 시작하려면 먼저 현재 자신이 하는 작업을 살펴보세요. 내가 병목이 되는 작업을 하나 골라, 어떤 부분을 위임할 수 있을지 생각해 보세요. 검증 단계를 직접 정의할 수 있나요? 목표가 충분히 명확한가요? 작업이 일정에 따라 반복되나요?

아이디어가 생겼다면 루프를 실행해 보세요. 어디서 멈추거나 과도하게 진행되는지 결과를 관찰하고, 과감하게 반복 개선해 나가세요.

더 자세한 내용은 병렬 에이전트 실행에 관한 Claude Code 공식 문서인 에이전트 병렬 실행, 그리고 loop, schedule, goal, dynamic workflows 페이지를 참고하세요.

이 글은 Delba de Oliveira와 Michael Segner가 작성했습니다