루프 시작하기

https://x.com/ClaudeDevs/status/2074208949205881033

요즘 코딩 에이전트에게 프롬프트를 쓰는 대신 "루프를 설계한다"는 이야기가 많이 나옵니다. 그런데 루프가 정확히 무엇인지 X에서 한참 찾아보면 저마다 다른 답을 내놓는 걸 보게 됩니다.

Claude Code 팀에서는 루프를 에이전트가 중지 조건이 충족될 때까지 작업 사이클을 반복하는 것으로 정의합니다. 그리고 다음 기준에 따라 루프를 몇 가지 유형으로 나눕니다.

• 무엇이 루프를 시작시키는지
• 어떻게 멈추는지
• 어떤 Claude Code 기본 기능(primitive)을 사용하는지
• 각 유형에 어떤 작업이 가장 잘 맞는지

이 글에서는 주요 루프 유형과 각각을 언제 쓰면 좋은지, 그리고 토큰 사용량을 관리하면서 코드 품질을 유지하는 방법을 다룹니다. 모든 작업에 복잡한 루프가 필요한 것은 아닙니다. 가장 단순한 방법부터 시작하고, 이 패턴들은 필요할 때만 골라 쓰세요.

턴 기반 루프

• 트리거: 사용자 프롬프트.
• 중지 기준: Claude가 작업을 끝냈다고 판단하거나 추가 컨텍스트가 필요하다고 판단할 때.
• 잘 맞는 작업: 정기적인 프로세스나 일정에 속하지 않는 짧은 작업.
• 사용량 관리: 구체적인 프롬프트를 쓰고, 스킬로 검증을 강화해 턴 수를 줄입니다.

여러분이 보내는 프롬프트 하나하나가 수동 루프를 시작시키고, 매 턴을 여러분이 직접 이끕니다. Claude는 컨텍스트를 모으고, 작업을 수행하고, 결과를 점검하고, 필요하면 반복한 뒤 응답합니다. 이것을 에이전틱 루프(agentic loop)라고 부릅니다.

예를 들어 Claude에게 좋아요 버튼을 만들어 달라고 해보세요. 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가 멈추려고 할 때마다 평가 모델이 여러분이 정한 조건을 확인하고, 목표가 달성되거나 지정한 턴 수에 도달할 때까지 다시 작업하도록 돌려보냅니다.

통과한 테스트 개수나 특정 점수 기준 통과처럼 결정적인(deterministic) 기준이 특히 효과적인 이유가 바로 이것입니다.

예를 들면 다음과 같습니다.

/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. 동적 워크플로로 리포트별 분류·수정·리뷰를 수행하는 에이전트들을 오케스트레이션합니다.
4. 자동 모드로 루틴이 권한 확인 때문에 멈추지 않고 돌아가게 합니다.

이를 모두 합치면 프롬프트는 이런 모습이 됩니다.

/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는 코드베이스에 이미 있는 패턴과 컨벤션을 따릅니다.
• Claude가 자기 작업을 검증할 방법을 마련해 주세요: 여러분과 팀이 생각하는 "좋은 결과"의 기준을 스킬로 정리해 두세요.
• 문서에 쉽게 접근할 수 있게 하세요: 프레임워크와 라이브러리 문서에는 최신 모범 사례가 담겨 있습니다.
• 코드 리뷰에는 별도의 에이전트를 쓰세요: 새 컨텍스트로 보는 리뷰어는 편향이 적고 메인 에이전트의 추론에 영향을 받지 않습니다. 내장 /code-review 스킬이나 GitHub용 Code Review를 쓸 수 있습니다.

어떤 결과물이 기준에 못 미치면 그 문제 하나만 고치고 끝내지 말고, 그 교훈을 시스템에 반영해서 앞으로의 모든 반복이 나아지게 해보세요.

토큰 사용량 관리하기

토큰 사용량을 관리하려면 루프에 명확한 경계가 있어야 합니다.

• 작업에 맞는 기본 기능과 모델을 고르세요: 작은 작업에는 여러 에이전트나 루프가 필요 없습니다. 더 저렴하고 빠른 모델로 충분한 작업도 있습니다.
• 성공 기준과 중지 기준을 명확히 정하세요: "완료"가 어떤 모습인지 구체적으로 알려주면 Claude가 더 빨리(그렇다고 너무 성급하지는 않게) 해답에 도달할 수 있습니다.
• 큰 실행 전에 시범 운행을 해보세요: 동적 워크플로는 수백 개의 에이전트를 띄울 수 있습니다. 먼저 작은 범위의 작업으로 사용량을 가늠해 보세요.
• 결정적인 작업에는 스크립트를 쓰세요: 스크립트를 실행하는 편이 단계를 일일이 추론하는 것보다 저렴합니다. 예를 들어 PDF 스킬에 양식 채우기 스크립트를 함께 넣어두면, Claude가 매번 코드를 새로 짜는 대신 그 스크립트를 실행하면 됩니다.
• 루틴을 필요 이상으로 자주 돌리지 마세요: 지켜보는 대상이 바뀌는 빈도에 실행 간격을 맞추세요.
• 사용량을 확인하세요: /usage 명령은 최근 사용량을 스킬·서브에이전트·MCP별로 나눠 보여주고, /goal을 인자 없이 실행하면 지금까지의 턴 수와 토큰 사용량을 보여주며, /workflows는 에이전트별 토큰 사용량을 보여주고 언제든 에이전트를 중지할 수 있게 해줍니다.

시작하기

정리하면 다음과 같습니다.

루프를 시작하려면 지금 하고 있는 일부터 살펴보세요. 여러분이 병목이 되는 작업 하나를 골라, 어느 부분을 맡길 수 있을지 자문해 보세요. 검증 절차를 글로 적어낼 수 있나요? 목표가 충분히 명확한가요? 그 일이 일정에 따라 들어오나요?

아이디어가 잡히면 루프를 돌려보고, 어디서 막히는지 혹은 어디서 과하게 나가는지 결과를 관찰하면서 주저하지 말고 계속 다듬어 보세요.

더 자세한 내용은 Claude Code 문서의 에이전트 병렬 실행 페이지와 loop, schedule, goal, dynamic workflows 페이지를 읽어보세요.

이 글은 @delba_oliveira가 작성했습니다.