루프 시작하기

Category: Claude Code · Product: Claude Code · Date: June 30, 2026 · Reading time: 5 min

요즘 "루프를 설계한다"는 말이 코딩 에이전트에게 프롬프트를 보내는 방식을 대신하며 많이 오갑니다. X에서 루프가 정확히 무엇인지 찾아보면 서로 다른 답이 여러 개 나옵니다.

Claude Code 팀은 루프를 멈춤 조건을 만날 때까지 일을 반복하는 에이전트로 정의합니다. 우리는 다음 네 가지를 기준으로 루프를 몇 종류로 나눕니다.

• 무엇이 루프를 시작시키는가
• 무엇이 루프를 멈추는가
• 어떤 Claude Code primitive를 쓰는가
• 어떤 종류의 일에 가장 잘 맞는가

모든 일에 복잡한 루프가 필요하지는 않습니다. 가장 단순한 방법부터 시작하고, 이 패턴들은 골라서 씁니다.

턴 기반 루프 (Turn-based loops)

• 시작 방식: 사용자 프롬프트.
• 멈춤 조건: Claude가 일을 끝냈다고 판단하거나, 맥락이 더 필요하다고 판단할 때.
• 잘 맞는 곳: 정해진 절차나 일정에 속하지 않는 짧은 일.
• 사용량 관리: 프롬프트를 구체적으로 쓰고, skill로 검증을 개선해 턴 수를 줄입니다.

프롬프트를 하나 보낼 때마다 사용자가 매 턴을 이끄는 수동 루프가 시작됩니다. Claude는 맥락을 모으고, 행동하고, 자기 일을 확인하고, 필요하면 반복한 뒤 답합니다. 우리는 이걸 에이전트 루프라고 부릅니다.

예를 들어 Claude에게 좋아요 버튼을 만들라고 합니다. Claude는 코드를 읽고, 수정하고, 테스트를 돌린 뒤 작동한다고 믿는 결과를 돌려줍니다. 그러면 사용자가 직접 결과를 확인하고 다음 프롬프트를 씁니다.

검증 단계는 손으로 하던 절차를 SKILL.md로 적어두면 개선됩니다. 그러면 Claude가 자기 일을 처음부터 끝까지 더 많이 확인합니다. 여기에는 Claude가 결과를 보고, 재고, 다뤄볼 수 있게 하는 도구나 connector를 넣습니다. 확인이 정량적일수록 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-based loop, /goal)

• 시작 방식: 실시간 수동 프롬프트.
• 멈춤 조건: 목표 달성, 또는 최대 턴 수 도달.
• 잘 맞는 곳: 검증 가능한 종료 기준이 있는 일.
• 사용량 관리: 구체적인 완료 기준과 명확한 턴 상한을 정합니다. "5번 시도하고 멈춰."

한 턴으로 부족할 때가 있습니다. 특히 더 복잡한 일이 그렇습니다. 에이전트는 반복할 수 있을 때 더 잘합니다. /goal로 "완료"가 무엇인지 정의하면 Claude가 반복하는 시간을 늘릴 수 있습니다.

성공 기준을 정해두면 Claude가 "이 정도면 됐다"를 스스로 판단해 루프를 일찍 끝내지 않습니다. Claude가 멈추려 할 때마다 평가 모델이 조건을 확인하고, 목표를 만족하거나 정해둔 턴 수에 이를 때까지 다시 일을 시킵니다.

그래서 통과한 테스트 수나 특정 점수 기준을 넘겼는지 같은 결정적 기준이 아주 잘 통합니다.

예를 들어:

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

시간 기반 루프 (Time-based loop, /loop과 /schedule)

• 시작 방식: 정해진 시간 간격.
• 멈춤 조건: 사용자가 취소하거나, 일이 끝날 때(PR이 병합되거나 큐가 빌 때).
• 잘 맞는 곳: 반복되는 일, 또는 외부 환경이나 시스템과 주고받는 일.
• 사용량 관리: 간격을 길게 두거나, 시간 대신 이벤트에 반응하게 합니다.

어떤 에이전트 일은 반복됩니다. 일은 그대로고 입력만 바뀝니다. 예를 들어 매일 아침 Slack 메시지를 요약하는 일입니다. 또 어떤 일은 외부 시스템에 달려 있는데, 이런 시스템과 주고받는 간단한 방법은 일정 간격으로 확인하고 바뀐 것에 반응하는 것입니다. 예를 들어 코드 리뷰를 받거나 CI가 깨질 수 있는 PR이 그렇습니다.

이런 일에는 /loop으로 Claude가 실행되는 시점을 정할 수 있습니다. /loop은 프롬프트를 일정 간격으로 다시 돌립니다. 예를 들어:

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

/loop은 내 컴퓨터에서 돌기 때문에 컴퓨터를 끄면 멈춥니다. /schedule로 routine을 만들면 루프를 클라우드로 옮길 수 있습니다.

자동 루프 (Proactive loops)

• 시작 방식: 이벤트나 일정. 실시간으로 사람이 개입하지 않습니다.
• 멈춤 조건: 각 일은 목표를 만족하면 끝납니다. routine 자체는 끌 때까지 돕니다.
• 잘 맞는 곳: 잘 정의된 일이 계속 들어오는 흐름. 버그 신고, 이슈 분류, 마이그레이션, 의존성 업그레이드 등.
• 사용량 관리: routine은 더 작고 빠른 모델로 보내고, 판단이 필요한 곳에만 가장 뛰어난 모델을 씁니다.

위의 primitive들은 auto mode나 dynamic workflows(research preview) 같은 다른 Claude Code 기능과 함께 엮어서 오래 도는 일을 위한 루프로 만들 수 있습니다.

예를 들어 들어오는 피드백을 처리하려면 이렇게 씁니다.

• /schedule(research preview): 새 신고가 있는지 확인하는 routine을 돌립니다.
• /goal: "완료"가 무엇인지 정의하고, skills로 검증 방법을 적어둡니다.
• Dynamic workflows: 각 신고를 분류하고, 고치고, 고친 것을 검토하는 에이전트들을 지휘합니다.
• Auto mode: routine이 권한을 물으려 멈추지 않고 돌게 합니다.

이걸 합치면 프롬프트는 이렇게 보일 수 있습니다.

/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가 자기 일을 검증할 방법을 줍니다: 나와 우리 팀에게 "좋은 것"이 무엇인지 skills로 적어둡니다.
• 문서를 쉽게 찾아보게 합니다: 프레임워크와 라이브러리 문서에 최신 모범 사례가 있습니다.
• 코드 리뷰에는 두 번째 에이전트를 씁니다: 맥락이 새로운 검토자는 덜 치우치고, 메인 에이전트의 추론에 휘둘리지 않습니다. 내장된 /code-review skill이나 GitHub용 Code Review를 쓸 수 있습니다.

결과 하나가 기준에 못 미칠 때는 그 문제 하나를 고치고 끝내지 말고, 앞으로의 모든 반복에 도움이 되도록 시스템에 반영해 봅니다.

토큰 사용량 관리

토큰을 관리하려면 루프에 뚜렷한 경계가 있어야 합니다.

• 일에 맞는 primitive와 모델을 고릅니다: 작은 일에는 여러 에이전트나 루프가 필요 없습니다. 어떤 일은 더 싸고 빠른 모델로 됩니다.
• 성공과 멈춤 기준을 뚜렷이 정합니다: "완료"가 무엇인지 구체적으로 정하면 Claude가 답을 더 빨리 찾습니다(너무 빨리는 말고요).
• 큰 일 전에 파일럿을 돌립니다: dynamic workflows는 에이전트를 수백 개까지 띄울 수 있습니다. 먼저 일의 작은 조각으로 사용량을 가늠합니다.
• 결정적인 일에는 스크립트를 씁니다: 스크립트를 돌리는 편이 단계를 추론하는 것보다 쌉니다. 예를 들어 PDF skill은 양식 채우기 스크립트를 함께 실어, Claude가 매번 코드를 다시 만들지 않고 그 스크립트를 돌리게 합니다.
• 필요보다 자주 routine을 돌리지 않습니다: 지켜보는 대상이 바뀌는 빈도에 간격을 맞춥니다.
• 사용량을 확인합니다: /usage는 최근 사용량을 skill, subagent, MCP별로 나눠 보여줍니다. /goal을 인자 없이 치면 지금까지의 턴 수와 토큰 사용량을 보여줍니다. /workflows는 각 에이전트의 토큰 사용량을 보여주고, 언제든 에이전트를 멈출 수 있습니다.

시작하기

루프별 차이는 다음과 같습니다.

루프를 시작하려면 이미 하고 있는 일을 봅니다. 내가 병목인 일을 하나 골라, 어떤 부분을 넘길 수 있을지 물어봅니다. 검증 확인을 내가 적을 수 있나? 목표가 충분히 뚜렷한가? 일이 일정대로 들어오나?

방법이 떠오르면 루프를 돌려보고, 어디서 멈추거나 지나치는지 결과를 살피고, 겁내지 말고 다듬어 갑니다.

더 알고 싶으면 Claude Code 문서에서 에이전트 병렬 실행, 그리고 loop, schedule, goal, dynamic workflows 페이지를 읽어 봅니다.

이 글은 Delba de Oliveira와 Michael Segner가 썼습니다.