프롬프트, 하네스 다음은 루프 설계, Claude Code 팀이 정리한 루프 엔지니어링 가이드(/goal·/loop·/schedule)

요즘 코딩 에이전트 커뮤니티에서 프롬프트를 잘 쓰는 법 대신 '루프를 설계하라'는 이야기가 자주 나옵니다. OpenClaw의 창시자 Peter Steinberger가 X에 올린 '이제 코딩 에이전트에 프롬프트를 치지 마세요. 에이전트에게 프롬프트를 보내는 루프를 설계해야 합니다'라는 글이 이 논의의 기점이 됐습니다.¹ 그런데 X에서 루프가 정확히 무엇인지 찾아보면 사람마다 답이 다릅니다. 이 혼란을 정리하려고 Claude Code 팀이 2026년 7월 7일, 공식 가이드를 내놓았습니다.² 루프를 네 가지 유형으로 나누고 각 유형을 언제 쓰는지, 코드 품질과 토큰 사용량은 어떻게 관리하는지 담은 글입니다. 모던웹연구소가 전문을 번역하고 한국 독자에게 맞게 재구성했습니다.

루프란 무엇인가

Claude Code 팀은 루프를 '에이전트가 정지 조건을 만족할 때까지 작업 사이클을 반복하는 것(loops as agents repeating cycles of work until a stop condition is met)'으로 정의합니다. 그리고 네 가지 기준으로 루프의 유형을 나눕니다.

• 무엇이 루프를 시작시키는가

• 무엇이 루프를 멈추는가

• 어떤 Claude Code 기능을 쓰는가

• 어떤 작업에 가장 적합한가

한 가지 전제를 먼저 짚고 갑시다. 모든 작업에 복잡한 루프가 필요한 것은 아닙니다. 간단한 방법부터 시도해보고 안 되면 아래 패턴을 선별적으로 쓰세요.

턴 기반 루프

• 시작 조건: 사용자의 프롬프트

• 정지 조건: Claude가 작업을 끝냈다고 판단하거나 추가 컨텍스트가 필요하다고 판단할 때

• 적합한 작업: 정기 프로세스나 일정에 속하지 않는 짧은 작업

• 사용량 관리: 프롬프트를 구체적으로 쓰고 스킬로 검증을 강화해 턴 수를 줄인다

사실 여러분이 입력하는 모든 프롬프트가 루프를 하나씩 시작시키고 있는 셈입니다. 각 턴을 사람이 직접 지시하는 수동적인 형태이지만 이 역시 루프입니다. Claude는 컨텍스트를 수집하고 작업을 실행하고 결과를 점검하고 필요하면 반복한 뒤 응답합니다. Claude Code 팀은 이 사이클을 '에이전틱 루프'라고 부릅니다.

좋아요 버튼을 만들어 달라고 요청하는 상황을 예로 들어봅시다. Claude가 코드를 읽고 수정하고 테스트를 돌린 뒤 작업이 다 끝났다고 판단해 결과물을 건네줍니다. 그러면 사람은 결과물을 직접 확인하고 다음 프롬프트를 씁니다.

이때 사람이 하던 확인 절차를 SKILL.md 파일로 문서화하면 Claude가 자기 작업을 끝까지 스스로 검증하게 만들 수 있습니다. 이때, 검증 스킬에는 Claude가 결과물을 보고 측정하고 조작할 수 있는 도구나 커넥터가 포함되어야 합니다. 점검 항목이 정량적일수록 Claude의 자가 검증이 쉬워집니다.

프런트엔드 변경을 검증하는 SKILL.md 예시를 들어봅시다.

---
name: verify-frontend-change
description: UI 변경은 완료를 선언하기 전에 반드시 end-to-end로 검증한다.
---

# 프런트엔드 변경 검증하기
편집이 성공했다는 사실만으로 UI 변경을 완료로 보고하지 않는다. 사람 리뷰어가 하듯 검증한다.

1. dev 서버를 켜고 수정한 페이지를 브라우저에서 연다.

2. 변경 사항을 직접 조작해 테스트한다. 클릭으로 통제하는 요소(버튼·입력·토글) 이면 클릭해서 기대한 상태 변화를 확인하고 전후 스크린샷을 남긴다.

3. 브라우저 콘솔을 확인한다. 새 에러·경고가 하나도 없어야 한다.

4. Chrome DevTools MCP로 성능 트레이스(performance trace, 웹페이지가 로드되거나 실행될 때 발생하는 브라우저의 작업들을 녹화하고 분석하는 도구)를 돌려보고 Core Web Vitals를 점검한다.

어느 단계라도 실패하면 문제를 고치고 1단계부터 다시 실행한다. 일부만 검증된 작업은 건네지 않는다.

목표 기반 루프(/goal)

• 시작 조건: 실시간으로 /goal을 앞에 붙여 입력하는 프롬프트

• 정지 조건: 목표 달성 또는 지정한 최대 턴 수 도달

• 적합한 작업: 종료 기준을 검증할 수 있는 작업

• 사용량 관리: 구체적인 완료 기준과 '5번 시도 후 중단' 같은 명시적 턴 상한을 정한다

복잡한 작업일수록 한 턴으로는 부족합니다. 에이전트는 반복적으로 목표 달성을 위한 사이클을 돌 때 일을 더 잘합니다. /goal로 '완료 상태의 모습'을 정의하면 Claude는 반복하는 시간을 늘려 원하는 목표를 달성하려 합니다.³

성공 기준을 사람이 정의해주면 Claude가 '이 정도면 충분한가'를 스스로 판정하다 루프를 일찍 끝내는 일이 사라집니다. Claude가 멈추려 할 때마다 평가 모델은 성공 조건을 확인합니다. 그리고 목표를 달성하거나 지정한 턴 수에 도달할 때까지 멈추지 않고 다시 작업을 시작하게 합니다.

통과한 테스트 개수나 특정 점수 임계값처럼 결정론적인 기준이 효과적인 이유가 여기에 있습니다. 평가자 모델이 판단을 망설일 여지가 없기 때문입니다.

/goal 홈페이지 Lighthouse 점수를 90 이상으로 올려. 5번 시도해도 안 되면 중단해.

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

• 시작 조건: 지정한 시간 간격에 도달했을 때

• 정지 조건: 사람이 취소하거나 작업이 완료되었을 때(PR 머지, 큐 비움)

• 적합한 작업: 반복 업무 또는 외부 환경·시스템과 상호작용하는 작업

• 사용량 관리: 간격을 길게 잡거나 시간 대신 이벤트에 반응하게 한다

에이전트는 작업 내용은 그대로인데 입력만 바뀌는 반복 작업도 자주 처리하는데, 매일 아침 Slack 메시지를 요약하는 일이 대표적인 예시입니다. 이런 작업과 외부 시스템에 의존하는 작업은 시간 기반 루프로 처리 가능합니다. 일정 간격으로 외부 시스템의 변화를 확인하고 바뀐 것에 반응하면 되기 때문입니다. 코드 리뷰가 필요하거나 CI에 실패한 PR이 여기서 외부 시스템의 대표적인 예시입니다.

/loop를 쓰면 손쉽게 시간 기반 루프를 만들 수 있습니다. /loop는 프롬프트를 지정한 간격으로 다시 실행하게 해주는 명령입니다.⁴

/loop 5분 간격으로 내 PR을 확인해서 리뷰 코멘트에 대응하고 실패한 CI를 고쳐줘

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

프로액티브 루프

• 시작 조건: 특정 이벤트 또는 스케줄. 사람이 실시간으로 개입하지 않는다

• 정지 조건: 개별 작업은 목표 달성 시 종료되고 루틴 자체는 사람이 끌 때까지 유지

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

• 사용량 관리: 반복 업무는 작고 빠른 모델로 돌리고 판단이 필요한 지점에만 가장 유능한 모델을 쓴다

앞서 본 기능들은 auto 모드나 dynamic workflows(research preview) 같은 다른 Claude Code 기능과 조합하면 장기 실행 루프로 구성할 수 있습니다.⁵ 들어오는 피드백을 처리하는 루프를 예로 들어보겠습니다. 이런 조합이 가능합니다.

• /schedule(research preview)로 새 리포트를 확인하는 루틴을 실행한다

• /goal로 완료 기준을 정의하고 스킬로 검증 방법을 문서화한다

• dynamic workflows로 리포트별 분류·수정·리뷰를 담당할 에이전트들을 오케스트레이션한다

• auto 모드로 루틴이 권한 요청 없이 계속 돌게 한다

전부 합치면 프롬프트는 이런 모습이 됩니다.

/schedule 매시간마다 project-feedback 채널에서 버그 리포트를 확인해. /goal: 이번 실행에서 발견한 모든 리포트가 분류·조치·응답될 때까지 멈추지 마. 버그를 고칠 때는 dynamic workflow를 써서 세 가지 해결책을 병렬 worktree에서 탐색하게 하고, 심판 에이전트를 따로 둬 적대적 리뷰를 하게 해.

코드 품질 유지하기

루프가 내놓는 결과물의 품질은 루프를 둘러싼 시스템에 달려 있습니다. 시스템을 설계할 때 네 가지를 챙기세요.

• 코드베이스 자체를 깨끗하게 유지한다. Claude는 코드베이스에 이미 존재하는 패턴과 컨벤션을 따른다.

• Claude가 자기 작업을 검증할 방법을 준다. 나와 팀에게 '좋은 결과'가 어떤 모습인지 스킬로 문서화한다.

• 문서에 쉽게 접근하게 한다. 프레임워크·라이브러리 문서에 최신 모범 사례가 들어 있다.

• 코드 리뷰에는 두 번째 에이전트를 쓴다. 새 컨텍스트로 시작하는 리뷰어는 편향이 적고 메인 에이전트의 추론에 영향을 받지 않는다. 내장 /code-review 스킬이나 GitHub 및 Codex Code Review를 쓸 수 있다.

개별 결과물이 기준에 못 미쳤다면 그 건만 고치고 끝내지 마세요. 문제와 해결책을 시스템에 반영해 이후 모든 반복이 개선되게 만들어야 합니다.

토큰 사용량 관리하기

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

• 작업에 맞는 기능과 모델을 고른다. 작은 작업에는 여러 에이전트나 루프가 필요 없다. 더 싸고 빠른 모델로 충분한 작업도 있다.

• 성공·정지 기준을 명확히 정의한다. 완료가 어떤 모습인지 구체적으로 적을수록 Claude가 답에 일찍(그러나 너무 일찍은 아니게) 도달한다.

• 대규모 실행 전에 파일럿을 돌린다. dynamic workflows는 에이전트를 수백 개까지 만들 수 있다. 작업의 작은 조각으로 사용량을 먼저 가늠하라.

• 결정론적 작업에는 스크립트를 쓴다. 스크립트 실행이 추론으로 단계를 풀어가는 것보다 싸다. PDF 스킬에 양식 채우기 스크립트를 넣어두면 Claude가 매번 코드를 다시 만들지 않고 실행만 한다.

• 루틴을 필요 이상 자주 돌리지 않는다. 관찰 대상이 변하는 주기에 실행 간격을 맞춘다.

• 사용량을 확인한다. /usage 명령은 최근 토큰 사용량을 스킬·서브에이전트·MCP별로 보여준다. /goal을 인자 없이 실행하면 지금까지의 턴 수와 토큰 사용량이 나온다. /workflows는 에이전트별 토큰 사용량을 보여주고 언제든 에이전트를 중지할 수 있다.

무엇부터 시작할까

네 가지 루프를 한 표로 정리하면 이렇습니다. 핵심은 각 루프가 사람이 하던 일 중 '무엇을 넘겨받는가'입니다.

루프를 시작하려면 이미 하고 있는 일을 들여다보세요. 내가 병목인 작업을 하나 골라 어느 조각을 넘길 수 있을지 물어보면 됩니다.

• 검증 방식과 기준을 글로 쓸 수 있는가

• 목표가 충분히 명확한가

• 작업 일정이 정해져 있는가

병목이 어딘지 떠오르면 루프를 돌려보고, 어디서 작업이 멈추는지 어디서 과하게 나가는지 관찰한 뒤 주저 없이 다듬으세요.

정리

이 가이드가 유용한 이유는 도구 목록이 아니라 위임의 관점을 제시하기 때문입니다. 프롬프트 엔지니어링이 '지시를 잘 쓰는 법'이었다면 루프 설계는 '검증·정지 조건·트리거·프롬프트 중 무엇까지 에이전트에게 넘길지 정하는 일'입니다. 모던웹연구소 역시 격주 뉴스레터 초안과 콘텐츠 발행 검증을 루프로 옮기면서 같은 순서를 밟았습니다. 검증 스킬을 먼저 만들고, 완료 기준을 정의하고, 그다음에야 일정 기반 루틴으로 올렸습니다. 순서를 건너뛰고 프로액티브 루프부터 만들면 품질과 비용 양쪽에서 대가를 치릅니다.

더 깊이 보려면 Claude Code 공식 문서의 에이전트 병렬 실행, goal, scheduled tasks, dynamic workflows 페이지를 읽어보세요.

1. Peter Steinberger(@steipete), "You should be designing loops that prompt your agents.", X, 2026-06-08.

   ↩

2. Claude Developers(@ClaudeDevs), Getting started with loops, X, 2026-07-07. 작성자 delba de Oliveira.

   ↩

3. Anthropic, Keep Claude working toward a goal, Claude Code Docs.

   ↩

4. Anthropic, Run prompts on a schedule, Claude Code Docs.

   ↩

5. Anthropic, Orchestrate subagents at scale with dynamic workflows, Claude Code Docs.

   ↩