루프 엔지니어링: Claude Code 루프, 루틴, 워크플로

요약: Loop engineering은 중지 조건을 충족할 때까지 에이전트가 작업 주기를 반복하게 만드는 규율입니다. 한 번에 한 턴씩 프롬프트를 입력하는 방식과는 다릅니다. Claude Code을 만든 Anthropic의 Boris Cherny는 자신의 워크플로를 단도직입적으로 설명합니다. “저는 이제 Claude에 직접 프롬프트를 입력하지 않아요. 대신 루프를 실행합니다. 루프가 Claude에 프롬프트를 입력하고 해야 할 일을 알아냅니다. 제 역할은 루프를 작성하는 것입니다.”¹ 이제 Claude Code은 다양한 단계의 루프 실행 방식을 모두 제공합니다. /goal은 별도의 모델이 조건 충족을 확인하거나 조건을 달성할 수 없다고 판단할 때까지 반복하고, /loop는 로컬에서 주기적으로 실행하며, 공식 Ralph 플러그인은 약속한 결과를 달성할 때까지 반복합니다. 클라우드 예약 작업(이전 명칭 routines)은 클라우드 cron을 지원하며, dynamic workflows에서는 Claude이 JavaScript 오케스트레이션 그래프를 작성하고 최대 1,000개의 subagents를 실행합니다. 하지만 이 기능들 가운데 핵심을 지탱하는 기술은 없습니다. 진짜 핵심은 검증입니다. 루프는 테스트, 평가 모델, 픽셀 차이 비교, 자동 검사처럼 생성기 외부에 있는 무언가가 “완료”를 판정할 때만 수렴합니다. 이를 제대로 설계하면 루프의 성과가 누적되지만, 잘못 설계하면 막대한 비용을 들여 무작위로 헤매게 됩니다. 이 가이드에서는 버전 기준점과 함께 모든 루프 실행 방식을 살펴보고, Ralph 패턴과 실패 유형, 루프를 그래프로 확장해야 하는 시점, 검증 단계, 비용 및 안전 원칙, 상시 운영 에이전트군을 관리하는 방법을 다룹니다. Claude Code v2.1.312 기준 최신 내용입니다(2026년 10월).

Loop Engineering이란 무엇인가요?

2년 전에는 엔지니어가 소스 코드를 직접 작성했어요. 그다음에는 에이전트가 사람의 프롬프트를 바탕으로 코드를 작성했죠. 지금 진행 중인 변화는 여기서 한 단계 더 나아갑니다. 에이전트가 에이전트에게 프롬프트를 보내고, 사람은 무엇을 프롬프트로 전달할지 결정하는 시스템을 작성해요. Cherny는 이 변화를 직접 이렇게 평가합니다. “소스 코드에서 에이전트로 넘어간 변화만큼이나 loops도 중요하며, 그에 못지않게 큰 도약입니다.”²

그가 내린 정의는 의외로 평범해요. “Loop는 본질적으로 Claude에서 로컬로 실행되는 cron 작업입니다. Routine도 같은 것이지만 클라우드에서 실행됩니다.”³ 밤새 “수백 개, 때로는 수천 개의 에이전트가 5시간, 10시간, 20시간 동안 실행되는” 모습이나,⁴ Claude Code가 “6개월 넘게 Claude Code에 의해 100% 작성된” 사례처럼⁴ 이국적으로 들리는 방식도 결국 몇 가지 기본 요소로 정리됩니다. 일정이나 조건에 따라 다시 실행되는 프롬프트, 반복 실행 사이에도 유지되는 상태, 그리고 실행을 종료하는 검사예요.

Anthropic는 2026년 6월에 이 분야에 이름을 붙였어요. loops는 “중지 조건을 충족할 때까지 에이전트가 작업 주기를 반복하는 것”이며, “loop의 결과 품질은 이를 둘러싼 시스템에 따라 달라집니다.”⁵ 이 가이드는 바로 그 주변 시스템을 다룹니다.

2026년 중반에 관련 논의가 빠르게 전개되었으므로 출처를 짚고 넘어갈 필요가 있어요. 바이럴 게시물에서 흔히 Cherny의 표현으로 알려진 “graph engineering”이라는 용어는 Anthropic나 Cherny가 아니라 커뮤니티에서 만들었습니다. Peter Steinberger가 7월 18일에 올린 “아직도 loops를 이야기하고 있나요, 아니면 이제 graphs로 넘어갔나요?”라는 글을 Hamel Husain이 확산하면서 알려졌어요.⁶ 널리 공유된 “우리 엔지니어의 85%가… 그 방법이 바로 graph engineering입니다”라는 인용문은 제3자 게시물에만 등장합니다. 이 가이드를 준비하면서 그의 발표에 관한 어떤 1차 기록에서도 해당 문구를 찾지 못했어요. 여기에는 YC Startup School 대화, Bloomberg의 Odd Lots, TechCrunch의 Meta @Scale 보도가 포함됩니다. 따라서 출처가 확인되지 않은 인용으로 봐야 합니다. 실제 그의 작업 방식은 graph 형태가 맞아요. 오케스트레이터가 구현, 검증, 수정 역할의 subagents를 생성하고, 최대 5단계 깊이까지 중첩합니다. 하지만 확인된 용어는 loops, routines, workflows이며, 이 가이드에서도 이 용어를 사용합니다.

5분 만에 따라가는 골든 패스

다음 3개 명령어로 프롬프트 실행에서 looping으로 넘어갈 수 있어요.

# 1. A goal loop: Claude keeps working until a SEPARATE model confirms the condition
/goal all tests pass and coverage is above 80%

# 2. A recurring local loop: re-runs on a schedule while your session is open
/loop 30m check CI on my open PRs and fix any failures

# 3. A cloud scheduled task (formerly a routine): runs on Anthropic's infrastructure whether your laptop is open or not
/schedule every morning at 7am: triage new issues, reproduce what you can, draft fixes as PRs

일반 프롬프트와 이 명령어들의 차이는 겉모습이 아니라 구조에 있어요. 각각에는 재실행 규칙이 있고, 조건이나 시계, cron이 이를 결정합니다. 또한 각각에 중지 규칙도 필요해요. 이 가이드의 나머지 내용은 이 두 규칙을 어떻게 신뢰할 수 있게 만들지 다룹니다.

핵심 Loop와 단 하나의 규칙

모든 에이전트 시스템은 동일한 내부 주기로 작동합니다. Anthropic의 Agent SDK 문서에서는 이를 컨텍스트 수집 → 작업 수행 → 작업 검증 → 반복으로 정리해요.⁷ Claude Code 자체의 처리 과정도 loop입니다. 프롬프트를 평가하고, 도구를 호출하고, 결과를 읽은 뒤, 도구 호출이 없는 응답이 나올 때까지 반복해요.⁸

Loop engineering은 이 내부 loop를 외부 loops로 감쌉니다. 이 분야의 주요 출처에서 한결같이 강조하는 단 하나의 양보할 수 없는 규칙도 그대로 따릅니다.

작업을 수행한 에이전트가 직접 평가해서는 안 됩니다.

• Anthropic의 /goal 문서: “완료 여부는 작업을 수행한 모델이 아니라 새 모델이 판단합니다.”⁹
• Anthropic의 harness 설계 글: “작업을 수행하는 에이전트와 이를 판단하는 에이전트를 분리하면 이 문제를 해결하는 데 큰 효과가 있습니다.”¹⁰
• 실무자가 가장 자주 놓치는 부분에 관한 Cherny의 설명: “검증은 사람들이 제대로 구현하지 못하는 요소 중 아마 가장 중요한 한 가지일 것입니다.”³ Electron 앱을 Swift로 2주 만에 다시 작성하도록 지시한 그의 실제 예시는 다음과 같아요. “Mac 가상 머신에서 Electron 앱을 실행하고 스크린샷을 찍은 다음 픽셀 단위로 살펴보세요. Swift 버전과 비교하세요. 완료할 때까지 멈추지 마세요.”³

그 이유는 윤리적 문제가 아니라 기계적인 특성 때문이에요. “작업을 완료했나요?”라는 질문을 받은 모델은 자신에게 유리하게 평가하는 편향을 보입니다. 자신감 있게 작성된 transcript는 모델이 판단하는 종료 조건을 설득해 성급하게 “완료” 판정을 끌어낼 수도 있어요.¹¹ 테스트 모음, 컴파일러, 픽셀 차이 비교, 답변에 이해관계가 없는 새 모델처럼 외부에서 수행하는 검증만이 이러한 편향에 흔들리지 않는 신호를 제공합니다.

자율성 단계

Claude Code의 loop 실행 방식은 “다시 엔터 키 누르기”부터 “사용자 없이 실행하기”까지 이어지는 단계로 구성됩니다. 단계가 올라갈수록 더 많은 자율성을 얻는 대신 검증 부담도 커져요.

(이 단계 구성은 이 분야를 가장 명확하게 독립적으로 정리한 pardel.dev의 2026년 7월 분류 체계를 따릅니다.¹¹)

3단계와 5단계 사이에는 로컬 선택지가 하나 있습니다. Desktop 예약 작업은 세션을 열어 두지 않아도 사용자 컴퓨터에서 실행되며, Claude가 설정하면 최소 1분, 양식에서 설정하면 최소 1시간 간격으로 실행할 수 있습니다. 문서는 “로컬 파일과 도구에 접근해야 할 때” 이 기능을 사용하라고 안내합니다.¹²

이 단계에서 지켜야 할 원칙은 다음과 같아요. 문제를 해결할 수 있는 가장 낮은 단계부터 시작하고, 해당 단계의 검증 방식이 입증된 뒤에만 다음 단계로 올라가세요. /goal의 조건을 검사 가능한 형태로 정의할 수 없다면 아직 클라우드 예약 작업으로 전환할 준비가 되지 않은 것입니다.

Loop 실행 방식 자세히 살펴보기

(이 가이드에서는 loop 실행 방식 자체를 다룹니다. Claude Code 가이드는 설정, 권한, hooks, MCP을 다루는 전체 CLI 참고 자료이며, Agent Architecture 가이드는 harness 구성 요소를 조합하는 방법을 설명합니다. loops는 이 두 요소 위에서 실행됩니다.)

/goal — 평가자-최적화 loop

/goal <condition>은 조건을 충족할 때까지 Claude가 계속 작업하게 합니다. “각 턴이 끝나면 모델이 조건 충족 여부를 확인합니다. 모델이 아직 충족되지 않았다고 판단하면 Claude는 사용자에게 제어권을 돌려주는 대신 다음 턴을 시작합니다.”⁹ 내부적으로 “/goal은 세션 범위의 프롬프트 기반 Stop hook을 감싼 래퍼”이므로, hooks가 꺼져 있는 환경(disableAllHooks, 또는 관리형 설정의 allowManagedHooksOnly)에서는 사용할 수 없습니다. 평가자는 사용자가 설정한 작고 빠른 모델이며, 다음 세 가지 판정 중 하나를 짧은 이유와 함께 반환합니다.⁹

Headless 방식도 지원합니다. claude -p "/goal ..."를 사용하면 loop가 완료될 때까지 실행됩니다.

작성할 때는 조건을 막연한 목표(“코드가 깔끔함”)가 아니라 관찰 가능한 상태(“테스트 통과”, “endpoint가 200 반환”, “TypeScript 오류 0개”)로 만드세요. 검증 조건이 모호하면 loop가 나아갈 방향도 정할 수 없어요. 또한 자신감 있게 작성된 transcript가 모델이 판단하는 조건에 동의하도록 설득할 수 있으므로, 가능한 경우 /goal을 기계적인 검사와 함께 사용하세요.¹¹ 문서는 이 한계를 분명히 밝힙니다. 평가자는 “명령을 실행하거나 파일을 독립적으로 읽지 않으므로, Claude 자신의 출력으로 입증할 수 있는 형태로 조건을 작성하세요.”⁹ 중지 규칙도 조건 안에 넣으세요. or stop after 20 turns 같은 절도 조건의 나머지 부분과 똑같이 판정되며, 조건은 최대 4,000자까지 작성할 수 있습니다. Claude가 여러 턴 연속으로 도구를 사용하지 않고 평가자에게 답변만 하면, Claude Code는 goal을 설정된 상태로 둔 채 loop를 멈추고 제어권을 사용자에게 돌려줍니다.⁹

실패 처리는 v2.1.234에서 처음 강화되었고,³⁴ 이제는 턴이 실패하는 모든 경우를 다룹니다.

데스크톱 앱이나 클라우드 세션처럼 호스트가 자격 증명을 관리하는 경우에는 호스트가 직접 접근 권한을 복구하므로, 인증 실패가 발생해도 goal은 활성 상태로 유지됩니다. 또한 백그라운드 작업 때문에 goal이 대기하면 Claude는 30분 후에 상태를 확인하고, 1시간 뒤에 다시 확인한 다음 2시간마다 확인하며, 사용자 프롬프트 사이에 시작하는 유휴 상태 확인은 최대 3회입니다(CLAUDE_CODE_GOAL_CHECKIN_MINUTES는 첫 확인 간격을 설정하며, 0으로 설정하면 상태 확인과 자동 재시도가 모두 꺼집니다).⁹

/loop — 로컬에서 반복 실행하기

/loop [interval] <prompt>는 일정에 따라 프롬프트를 다시 실행합니다. 고정 간격(/loop 5m check the deploy), 자체 조절 방식(Claude가 관찰 결과를 바탕으로 1분에서 1시간 사이의 다음 대기 시간을 선택), 또는 내장 유지 관리 작업을 실행하는 단독 /loop를 사용할 수 있어요. 내부에서는 CronCreate/CronList/CronDelete(5개 필드로 구성된 cron, 세션당 작업 50개, 7일 후 만료)와 폴링 대신 백그라운드 스크립트의 출력을 스트리밍하는 Monitor 도구가 작동합니다.¹² Cherny가 공개 당시 제시한 예시는 다음과 같아요. “/loop로 내 모든 PR을 관리하세요. 빌드 문제는 자동으로 수정하고, 댓글이 달리면 worktree 에이전트를 사용해 수정하세요.”¹³ 내장 유지 관리 프롬프트를 바꾸려면 loop.md를 작성하세요(프로젝트의 .claude/loop.md가 우선하며, 그 밖에는 ~/.claude/loop.md). “loop.md를 수정하면 다음 반복부터 적용”되며, 25,000바이트를 넘는 내용은 잘립니다.¹²

중요한 제약이 있습니다. /loop는 실행 중인 Claude Code 프로세스 안에서만 유지됩니다. “작업은 Claude Code가 실행 중이고 유휴 상태일 때만 실행됩니다.” 종료하면 작업이 더 이상 실행되지 않고, 세션을 백그라운드로 보내면 터미널 없이도 loop가 계속 실행됩니다. --resume이나 --continue로 재개하면 CronCreate로 예약한 작업은 복원되지만 자체 조절 방식의 /loop는 복원되지 않으므로 다시 실행해야 합니다.¹² 세션보다 오래 지속되어야 하는 작업을 위해 문서는 세 가지 실행 방식을 비교합니다.¹²

컴퓨터가 꺼져 있어도 실행되어야 하는 작업에는 클라우드 예약 작업을 사용합니다.

Ralph plugin — 약속을 지킬 때까지 반복하기

Anthropic의 공식 ralph-loop plugin은 커뮤니티에서 즐겨 사용하는 단순하고 강력한 패턴을 제품으로 구현했습니다. 이 plugin은 2026년 1월 6일 Anthropic이 “법률 자문에 따라” ralph-wiggum에서 이름을 바꾼 뒤로 anthropics/claude-plugins-official 저장소에서 ralph-loop라는 이름을 사용합니다. 2026년 10월 26일에는 claude-code 저장소가 자체 보관하던 오래된 ralph-wiggum 사본을 삭제했고, 이제 이 저장소의 marketplace는 공식 저장소에서 ralph-loop를 설치하므로 “기존 plugin id는 계속 작동합니다.”¹⁴ 작동 방식은 다음과 같습니다. Stop hook이 Claude의 세션 종료 시도를 가로채 프롬프트를 다시 주입하므로, 모델은 한 세션 안에서 계속 반복 작업을 수행합니다. /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>"로 시작하고 /cancel-ralph로 중단합니다. README에서는 --max-iterations가 “가장 중요한 안전장치”라고 명확히 설명합니다. 정확한 문자열을 비교하는 완료 조건은 영원히 충족되지 않을 수 있기 때문입니다.¹⁴ 모든 Stop hook loop의 바탕에는 harness 제한이 하나 있습니다. “hook이 사이에 도구 호출 없이 연속으로 여덟 번 종료를 차단하면, Claude Code는 다음 차단을 무시하고 턴을 종료합니다”(CLAUDE_CODE_STOP_HOOK_BLOCK_CAP으로 상한을 높일 수 있습니다).²⁹ 이 제한은 진전이 멈춘 loop를 끝내지만, 도구를 계속 호출하는 Ralph loop는 끝내지 않습니다. 따라서 반복 횟수 상한은 여전히 중요합니다.

Dynamic workflows — Claude이 graph를 작성합니다

Claude Code v2.1.154와 함께 2026년 5월에 도입되고 Anthropic의 2026년 6월 2일 공개 글에서 자세히 소개된 dynamic workflows는 가장 큰 개념적 도약이에요. “Claude은 이제 작업에 맞춰 즉석에서 자체 harness를 작성할 수 있습니다.”¹⁵ 작업을 설명하거나, “workflow를 사용하세요”라고 말하거나, 키워드 ultracode를 포함하면 Claude가 JavaScript 오케스트레이션 스크립트를 작성하고 runtime이 이를 백그라운드에서 실행합니다. 이 스크립트에서 agent()는 선택적으로 JSON-schema 출력을 지정해 subagent를 생성하고, pipeline()은 목록의 항목마다 하나씩 실행하며, parallel()은 여러 작업을 한꺼번에 실행하고, 일반 await/loops/조건문이 제어 흐름을 담당합니다. /effort ultracode는 한 걸음 더 나아갑니다. Claude는 “세션의 모든 실질적인 작업마다 workflow를 계획”하며, 이런 세션은 “같은 작업을 이 설정 없이 할 때보다 세션 한도나 주간 한도에 더 빨리 도달합니다.”¹⁶ “Workflow는 계획을 코드로 옮깁니다… Workflow 스크립트가 loop, 분기, 중간 결과를 직접 관리하므로 Claude의 컨텍스트에는 최종 답변만 남습니다.”¹⁶

문서에 따른 제한과 구조는 다음과 같습니다.¹⁶

.claude/workflows/에 저장한 스크립트는 재사용 가능한 slash commands가 됩니다. Claude가 실행을 다시 시작하면 저장된 에이전트 결과에서 재개하지만, 실패한 에이전트는 “다시 실행되며, 스크립트가 그 뒤에 시작하는 모든 에이전트도 이미 완료되었더라도 다시 실행됩니다.” 또한 도중에 백그라운드로 보내거나 종료한 실행은 “스스로 계속되지 않습니다.”¹⁶

대표적인 구조는 fan-out / refute / converge입니다. 독립적인 탐색 에이전트가 정보를 찾고, 적대적 검증 에이전트가 각 결과를 반박하도록 지시받은 뒤, 검증을 통과하는 답변이 나올 때까지 반복해요. 이제 Anthropic은 이 구조를 구현한 예를 직접 제공합니다. 내장 /deep-research workflow는 “하나의 질문에 대해 여러 관점으로 웹 검색을 분산하고, 찾은 출처를 가져와 교차 확인하고, 각 주장에 투표한 뒤, 교차 확인을 통과하지 못한 주장을 걸러 낸 인용 보고서를 반환”하며, 검증 에이전트가 주장을 확인할 수 없으면 “보고서는 그 주장을 반박된 것으로 세지 않고 미검증으로 표시합니다.”¹⁶ 공개 당시 대표 사례는 Bun의 535,496줄 규모 Zig 코드베이스를 Rust로 이식한 작업입니다. Jarred Sumner의 설명에 따르면 에이전트 64개를 병렬로 실행해 2026년 5월 3일부터 14일까지 11일 만에 백만 줄이 넘는 Rust 코드베이스를 만들었어요.¹⁵

Agent teams — 동료 간 graph

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1을 통해 사용할 수 있습니다. 2026년 2월 v2.1.32에서 research preview로 추가되었으며, 현재 문서는 “Agent teams는 실험적 기능이며 기본적으로 비활성화되어 있습니다”라고 설명합니다. 팀 리더와 팀원은 “각자 독립된 컨텍스트 창에서 독립적으로 작업하며 서로 직접 소통합니다.” 따라서 subagent 트리가 아닌 동료 간 graph가 되며, 의존성이 포함된 공유 작업 목록, 파일 잠금 기반 작업 선점, 에이전트별 mailbox를 통해 조율합니다. Hook으로 강제되는 quality gates는 팀원이 “완료”를 선언하기 전에 기계적인 검사를 거치게 합니다. TaskCompleted가 종료 코드 2를 반환하면 완료 처리가 차단되고, TeammateIdle이 종료 코드 2를 반환하면 팀원이 작업을 계속합니다.¹⁷ 이 기능을 켜기 전에 알아 둘 동작이 두 가지 있습니다. agent teams가 활성화되어 있는 동안에는 “Claude가 이름을 붙인 subagent가 팀원으로 실행되므로, 사용자가 요청하지 않아도 팀이 구성될 수 있습니다.” 또한 “팀원은 사용자를 대신해 권한 프롬프트를 승인하거나 동의를 제공할 수 없습니다.”¹⁷

Routines — 노트북이 꺼져도 계속되는 loops

클라우드 예약 작업(이전 명칭 routine)은 “Claude Code 설정을 저장한 것입니다. 프롬프트, 하나 이상의 저장소, connectors 모음을 한 번 패키징해 자동으로 실행”하며, Anthropic이 관리하는 클라우드 인프라나 조직의 self-hosted 환경에서 실행됩니다.¹⁸ 이름을 바꾸면 문제가 생기는 곳에는 이전 이름이 남아 있습니다. 웹 주소(claude.ai/code/routines), /schedule의 별칭인 /routines, /fire API 경로입니다. 함께 사용할 수 있는 트리거 유형은 3가지입니다. 일정(반복 주기는 최소 1시간 간격, 또는 지정한 시각의 일회성 실행), API 실행(POST .../routines/{id}/fire), GitHub 이벤트입니다. /schedule, Desktop 앱 또는 claude.ai/code/routines에서 만들 수 있습니다. 실행 세션은 auto 모드를 사용할 수 없는 경우가 아니면 auto 모드로 시작합니다. 분류기가 각 작업을 허용하거나 차단하며, auto 모드에서도 확인을 요청하는 작업(ask 규칙)이나 반복된 차단 같은 경우에는 실행이 멈추고 대기합니다. 바로 그렇기 때문에 다음 문서 경고가 매우 중요합니다. 실행 결과는 “세션이 어떻게 끝났는지를 알려 줄 뿐, Claude가 프롬프트에 설명된 작업을 완료했는지를 알려 주지 않으므로, 실행을 열고 transcript를 읽어 무슨 일이 있었는지 확인하세요.”¹⁸ 9월 이후의 두 가지 수정은 이 간극이 실제로 존재함을 보여 줍니다. v2.1.286 이전에는 클라우드 세션이 시작조차 되지 않은 실행이 Succeeded로 표시되었고, v2.1.302 이전에는 실행이 “클라우드 세션이 예기치 않게 중지된 뒤에도 Completed로” 표시되었습니다.³⁶ 같은 릴리스는 도중에 실패한 실행이 처음부터 다시 실행되던 문제도 수정했습니다. 이 문제는 “같은 보고서를 두 번 게시하는 것처럼 작업을 반복할 수 있었으므로”, 실행되는 작업은 멱등적으로 만들어야 합니다.³⁶

Anthropic는 자체 코드베이스 전반에서 “매일 약 20개나 30개의 routines”를 실행합니다. 사용하지 않는 코드 정리, 테스트 범위 확대, 실험 출시 등에 활용해요.³

지원 기능

Background subagents는 v2.1.198부터 기본값으로 적용되어 위임된 작업이 사용자 컨텍스트를 차지하지 않게 하며, /agents 패널에서 상태를 확인할 수 있어요. Cross-session messaging은 v2.1.224부터 SendMessage를 통해 독립된 세션들을 메시지 전달 graph로 연결합니다. 다른 세션에서 온 메시지는 “절대로 사용자의 동의로 간주되지 않는다”는 보안 원칙도 그대로 따를 만해요.¹⁹ Remote Control에 연결된 세션에서는 다른 컴퓨터에 있는 사용자 세션(v2.1.225+)과 클라우드 세션에도 메시지를 보낼 수 있습니다. loop 사이의 대기에는 notify_when_idle 입력(v2.1.236+)³⁶을 사용하세요. 이 컴퓨터의 다른 세션에 다음번에 유휴 상태가 되거나 종료될 때 알림을 한 번 보내도록 요청하며, Claude Code는 “감시 대상 세션에서 턴을 시작하거나 토큰을 쓰지 않고” 구독합니다.¹⁹ Self-hosted runners는 v2.1.224부터 Team/Enterprise에서 제공되며, 사용자 소유 장비에서 클라우드 세션과 클라우드 예약 작업(이전 명칭 routines)을 실행합니다. 조직 규모의 에이전트 집단을 운영하기 위한 기반이에요.²⁰

Ralph 패턴

커뮤니티가 먼저 이 지점에 도달했습니다. 2025년 7월, Geoffrey Huntley는 심슨 가족의 등장인물에서 이름을 따온 기법을 소개하는 글을 발표했습니다. Ralph는 말 그대로 다음과 같습니다.

while :; do cat PROMPT.md | claude-code ; done

— 그가 공개한 한 줄 코드를 그대로 옮긴 것입니다 — 저장소는 하나, 반복마다 작업도 하나이며, 매번 새로운 컨텍스트로 시작합니다. 파일시스템의 명세와 진행 상황 파일이 반복 사이의 상태를 전달하고, 테스트와 린트가 “배압” 역할을 합니다.²¹ 같은 구조를 오늘날의 헤드리스 방식으로 구현하면 셸 루프에서 claude -p "$(cat PROMPT.md)"를 실행하는 형태가 됩니다. Anthropic의 C 컴파일러 harness도 본질적으로 이 방식으로 실행되었습니다.²³ 그가 주장한 성과(토큰 비용 $297로 $50K 계약의 MVP 구현, 해커톤에서 하룻밤 사이 저장소 6개 작업)에는 그만큼 명확한 한계도 따랐습니다. 신규 프로젝트에만 적용할 수 있었고, 임시 구현과 중복 구현이 반복적으로 발생했으며, “LLM는 운영자의 역량을 비추는 거울”이라는 점입니다.

Anthropic는 엔지니어링 자료에서 이 이름을 사용하지 않지만, 이 패턴은 이미 두 차례 공식 원칙으로 제시되었습니다. 2025년 11월의 장시간 실행 에이전트 글은 정확히 이 구조를 권장합니다. 초기화 에이전트가 기능 목록과 진행 상황 파일을 만들고, 이후 컨텍스트 윈도우마다 새로운 코딩 에이전트가 “진행 상황 메모 파일과 git 커밋 로그를 읽으며 세션을 시작”합니다.²² 2026년 2월의 C 컴파일러 프로젝트에서는 Claude 에이전트 16개를 병렬로 실행했습니다. Nicholas Carlini의 설명대로 “Claude를 단순한 루프 안에서 실행하는 harness를 만들었습니다”. 파일 기반 작업 잠금과 동기화 계층으로 사용한 git을 통해 약 2,000개의 세션에서 약 $20K의 비용으로 Rust 코드 약 100K줄을 생성했습니다.²³ 이 글에서 검증을 다룬 한 문장이 패턴의 이론 전체를 담고 있습니다. “작업 검증기는 거의 완벽해야 합니다.”

새로운 컨텍스트가 하나의 긴 세션보다 나은 이유는 다음과 같습니다. 세션의 컨텍스트가 차오를수록 작업 효율이 떨어집니다. 실무자들은 대체로 약 100K 토큰을 방향 이탈이 시작되는 임계점으로 봅니다. 또한 컨텍스트 압축 요약은 정보를 잃는 재서술이어서, 오류마저 확신에 찬 문장으로 포장합니다.²⁴ 매번 새 에이전트를 시작하고 파일로 상태를 전달하는 Ralph의 설계는 두 문제를 모두 피합니다. (공식 플러그인의 세션 내 반복 방식은 편의성을 얻는 대신 이 장점을 일부 포기합니다. 장시간 실행에서는 외부에 상태를 저장하는 헤드리스 방식이 여전히 더 강력한 패턴입니다.)

이 패턴의 실패 사례도 교훈을 줍니다. 한 실무자가 모호한 프롬프트와 max_iterations: 0 설정으로 플러그인을 실행했습니다. 이 값은 비활성화가 아니라 무한 반복을 뜻합니다. Claude는 자신에게 같은 확인 질문을 1,966번 했고, Stop hook은 이후의 모든 메시지를 가로챘습니다.²⁵ 반복 횟수 제한은 필수입니다.

루프가 그래프로 바뀌는 시점

단일 루프는 각 반복이 서로 독립적이거나 엄격한 순서를 따른다고 가정합니다. 병렬 작업에 의존성이 생기는 순간, 예를 들어 작업 B에 A의 출력이 필요하거나 두 에이전트가 같은 파일을 수정하려는 순간, 자유롭게 실행하던 루프는 충돌합니다. 이때는 의존성 배열을 갖춘 작업 목록, 파일별 작업 권한 확보, 병합 규칙처럼 명시적인 구조가 필요합니다. 루프와 그래프를 둘러싼 논쟁의 실제 핵심은 이것입니다. 저장소 하나와 목표 하나에는 루프를, 병렬 작업에 순서가 필요하면 그래프를 사용합니다.²⁶

필요한 인프라가 적은 순서로 정리하면 그래프의 선택지는 다음과 같습니다.

1. 동적 워크플로 — 의존성을 JavaScript의 제어 흐름으로 표현합니다. 특정 단계에 이전 결과가 모두 필요한 경우에만 동기화 장벽을 둡니다. Anthropic가 제시한 구조는 병렬 분산 후 종합, 적대적 검증, 생성 후 필터링, 토너먼트(“같은 작업을 서로 다른 접근법으로 시도하는 에이전트 N개를 실행”한 뒤 결과를 쌍별로 비교 평가), 완료될 때까지 반복입니다.¹⁵
2. 에이전트 팀 — 의존성을 추적하는 공유 작업 목록을 둡니다. 리드가 plan 모드에 있을 때 생성된 팀원은 계획을 승인 요청으로 보내고, Claude Code가 이를 자동으로 승인합니다. 실행 중인 in-process 팀원을 plan 모드로 전환(Shift+Tab)한 경우에만 리드가 계획을 검토합니다. 그래프는 코드가 아니라 데이터로 표현됩니다.¹⁷ 이 패턴과 관련해 기본 설정 하나가 바뀌었으며, 처음 바뀐 것은 v2.1.233입니다.³⁴ 작업 추적 도구(TaskCreate, TaskGet, TaskUpdate, TaskList, TodoWrite)는 이제 “Opus 4.7, Sonnet 4.6, Haiku 4.5 및 이전 모델에서만 기본적으로 사용할 수 있으며”, 이 기본 구성은 v2.1.268부터 적용됩니다.³⁸ 이 도구가 없는 에이전트는 “공유 작업 목록 대신 메시지로 협업”하므로,¹⁷ 일반 로컬 세션에서 현재 모델을 사용하면 직접 활성화하지 않는 한 작업 목록이 없습니다. 백그라운드 세션과 클라우드 세션에서는 모든 모델에 이 도구가 제공됩니다.³⁸ 활성화하려면 CLAUDE_CODE_ENABLE_TODO_TOOLS=1, --allowedTools TaskCreate, 또는 이 도구들을 지정한 --tools 목록을 사용하세요. export한 환경 변수는 split-pane 팀원에게 전달되지 않으므로, 이런 팀원에게 도구를 제공하려면 claude --settings '{"env":{"CLAUDE_CODE_ENABLE_TODO_TOOLS":"1"}}'로 리드를 시작하세요.³⁸
3. 외부 오케스트레이터 — 커뮤니티가 규모를 확장한 방식입니다. Steve Yegge의 Gas Town은 git으로 상태를 관리하는 “beads”의 DAG를 대상으로 Claude Code 인스턴스 20~30개를 실행합니다(17일 만에 Go 코드 75K줄을 작성했지만, 그 자신도 높은 운영 역량을 요구하는 “돈 먹는 하마”라고 표현했습니다).²⁷ claude-flow/Ruflo(스타 약 31K개)는 에이전트 군집을 여왕/일꾼 계층으로 구성합니다. LangGraph 방식의 엔진은 각 노드 안에 Claude Code를 두고 그 위에 타입이 명시된 상태 머신을 얹습니다.

Cherny는 이러한 발전 경로를 AI 도입 단계라는 사다리로 정식화하고, 2026년 7월 Anthropic를 통해 발표했습니다. 승인 기반(에이전트 0개) → 보조형(약 1개) → 병렬형(약 10개) → 감독하의 자율형(약 100개, “대부분의 에이전트는 사람이 아니라 Claude가 실행하는” 단계) → AI 네이티브(1,000개 이상)입니다. 그는 여기에 다음과 같은 조언을 덧붙였습니다. “각 단계에서… 다음 병목들을 찾아 해소하고, 그에 맞는 새로운 보호 장치를 마련해야 합니다.”²⁸

검증 엔지니어링

지금까지 다룬 내용은 모두 기반 설비입니다. 이 절이 바로 제품입니다.

Anthropic가 제시한 단계별 강화 방안은 현재 모범 사례 문서의 조언 하나에서 출발합니다. “Claude에 실행하면 통과 또는 실패가 나오는 수단을 주세요. 그런 수단이 있으면 Claude는 스스로 작업을 이어 갈 수 있고, 사용자는 지켜볼 필요가 없습니다.” 이후 단계는 Claude가 결정하는 수준에서 harness가 강제하는 수준으로 올라갑니다. 프롬프트 한 줄(run the auth tests after, and keep going until they pass) → “별도 모델이 매 턴이 끝날 때마다 대화를 기준으로 확인하는” /goal 조건(이 조건은 “Claude가 항목이 아직 남아 있는데도 진행 상황 요약으로 턴을 끝내는 경우가 있는 장시간 백그라운드 실행에서 중요합니다”) → “Claude Code(harness)가 강제하므로 typecheck가 통과하거나 차단 한도에 도달할 때까지 턴이 끝나지 않는” Stop hook → “코드를 작성하지 않은 쪽”의 검토. 여기서 /code-review는 “대화를 본 적 없는 새 subagent에서 diff를 검토합니다. 코드를 만들어 낸 추론에 휘둘리지 않습니다.”²⁹ 여기에 따르는 증거 원칙은 다음과 같습니다. “Claude에 증거를 요청하세요. 실행한 명령과 그 출력, 또는 스크린샷입니다.” 그 이유는 “지켜보지 않은 세션에서는 그것이 가진 유일한 증거이기도 하기 때문입니다.”²⁹ 이 단계가 예전에 마지막 단계로 두었던 적대적 반박은 이제 워크플로 문서에 있으며, 그 예시 프롬프트는 워크플로에 “보고하기 전에 각 발견 사항을 적대적으로 검증”하라고 요청합니다.¹⁶

같은 문서는 모든 지시를 Claude가 결정하는 것과 Claude Code가 강제하는 것으로 나눕니다. 그중 세 행이 루프의 중지, 예산, 병합 규칙에 해당합니다.²⁹

무인 루프에는 모든 행에 오른쪽 열의 항목이 하나씩 필요합니다. 아무도 작성하지 않으면 루프에 남는 것은 왼쪽 열뿐입니다. 이 문서는 프롬프트 습관 하나도 폐기합니다. “계속해, 완료될 때까지 루프를 돌려, 게으름 피우지 마” 같은 문장은 “멈춤을 해결하기보다 과도한 작업을 일으킬 가능성이 더 크며”, “아무도 지켜보지 않는 실행에서는 /goal이나 Stop hook이 이를 강제합니다.”²⁹

피드백의 세 가지 유형은 Agent SDK 글에서 제시합니다. 규칙 기반 피드백(“출력에 적용할 규칙을 명확히 정의한 뒤, 어떤 규칙을 충족하지 못했고 그 이유가 무엇인지 설명하는 방식” — 가장 좋은 형태), 시각적 피드백(스크린샷, 픽셀 차이), LLM를 심사자로 활용하는 방식(모호한 평가 기준 — Anthropic의 표현으로는 “일반적으로 그다지 견고한 방법이 아닙니다”)입니다.⁷ 이 순서대로 우선하세요. 실제로 작동하는 결정론적 검사가 의견을 내놓는 심사자보다 낫습니다.

수렴 조건. 루프를 가장 날카롭게 비판적으로 다룬 Yoko Li의 2026년 8월 분석은 수렴의 요건을 네 가지로 압축합니다. 정의된 목표 상태, 관찰 가능한 현재 상태, 정밀한 국소 수정, 생성기 외부의 중단 규칙입니다. 계측을 적용한 그녀의 실험에서 기억해야 할 수치가 있습니다. 루프에 투입한 토큰의 67%가 아무런 개선도 만들어내지 못했습니다. 투입 대비 개선 폭이 로그 곡선처럼 줄어들기 시작했다는 사실을 루프에 알려주는 장치가 없었기 때문입니다.³⁰ 예산 상한은 단순한 비용 통제 수단이 아닙니다. 최후의 중단 규칙입니다.

테스트 무결성. Anthropic의 장시간 실행 에이전트 원칙은 다음과 같습니다. “테스트를 삭제하거나 수정해서는 안 됩니다. 기능 누락이나 버그로 이어질 수 있기 때문입니다.”²² 루프는 명세의 허점을 이용합니다. 눈에 보이는 테스트는 통과하면서도 그 뒤에 숨은 의도는 충족하지 못합니다. 따라서 검증기 자체를 평가 대상 에이전트로부터 보호해야 합니다.

경로가 아니라 결과를 평가하세요. 평가에 관한 글에서는 “에이전트가 거친 경로가 아니라 만들어낸 결과를 평가하세요”라고 권고합니다. 객관적 기준에는 코드 기반 평가기를, 정성적 평가 기준에는 모델 기반 평가기를 사용하고, 평가기의 판정도 보정해야 합니다. “여러 시행의 기록과 평가 결과를 직접 읽어보지 않으면 평가기가 제대로 작동하는지 알 수 없습니다.”³¹

대부분의 논의가 놓치는 구분이 하나 더 있습니다. 루프 안의 모든 검사가 결정론적이라면, 애초에 그 루프에 모델을 넣을 이유가 없습니다. 타임스탬프를 비교하는 변경 감시기, 링크 검사기, 빌드 감시기는 모두 일정에 따라 실행하는 셸 스크립트로 충분합니다. 토큰을 전혀 쓰지 않고, 실행에 몇 초면 되며, 완벽하게 재현할 수 있습니다. 모델 기반 루프는 판단이 필요한 반복 작업에 사용하세요. 가장 저렴한 루프는 모델을 호출하지 않는 루프입니다.

비용 및 안전 관리 원칙

루프 엔지니어링에 대한 커뮤니티의 가장 큰 반론은 비용이며, 실패 사례 분석도 이를 뒷받침합니다. subagents를 생성하는 버그로 5분 만에 400만 토큰이 소모되고, 밤새 실행된 루프가 수천 달러를 쓰고, 사용량 한도에 “예상보다 훨씬 빨리” 도달했다는 사례가 있습니다.³² 그 제약 중 하나는 이후 달라졌습니다. v2.1.234부터는 claude.ai 사용량 한도가 초기화되면 세션이 자동으로 계속됩니다(autoContinueAtUsageLimit 설정, /config → “Continue automatically at usage limit”에서 끌 수 있습니다).³⁴³⁷ 적용 범위는 좁습니다. “자동 계속은 claude.ai 구독으로 로그인한 대화형 세션에서 기본적으로 켜져 있습니다.” 주간 한도처럼 “24시간 이상 남은 초기화”에는 Claude Code가 스스로 대기를 시작하지 않고, Claude Code를 종료하면 대기도 끝나며, “백그라운드 세션과 -p 실행”에서는 Claude Code가 “대기 자체를 제안하지 않습니다.” 여기에는 헤드리스 Ralph와 claude -p "/goal ..."도 포함됩니다.³⁷ 조건을 충족하는 세션 안에서는 루프도 이 동작을 따릅니다. 일시 중지된 /goal은 초기화 시점에 재개되고,⁹ v2.1.271부터는 워크플로 실행이 에이전트를 실패 처리하지 않고 한도가 풀릴 때까지 기다리며, 이 대기는 실행당 최대 두 번입니다.¹⁶ 열린 대화형 세션에 머무는 야간 루프는 이제 한도를 넘어 계속될 수 있지만, 헤드리스나 백그라운드 세션에서 실행되는 루프는 여전히 한도에서 멈춥니다. 그래서 아래 예산 통제 수단이 더욱 중요해졌습니다. 이런 경험에서 정립된 원칙은 각각 실제로 제공되는 통제 수단과 연결됩니다.

마지막 행은 별도로 설명할 만합니다. 가장 적극적으로 자동화를 활용하는 실무자들이 안전을 지키는 방법이기 때문입니다. pull request를 영향 범위의 경계로 삼으세요. Cherny의 상시 백그라운드 에이전트는 하나는 아키텍처를 지속적으로 개선하고, 다른 하나는 중복된 추상화를 찾아내며, 사람이 실행을 지시하지 않아도 PR을 제출합니다.² 검토 없이 병합되는 변경은 없습니다. 최악의 결과가 “병합되지 않은 브랜치”인 상시 루프는 적극적으로 돌릴 수 있지만, main에 직접 쓰는 루프는 그럴 수 없습니다. 클라우드 예약 작업은 이를 기본값으로 제공합니다. “프롬프트에서 다른 브랜치로 푸시하라고 지시하지 않는 한, Claude는 claude/ 접두사가 붙은 브랜치에 작업을 푸시”하며, 실행이 어디에 푸시할 수 있는지는 GitHub 브랜치 보호나 rulesets가 결정합니다.¹⁸ 루프의 권한은 단계적으로 높이세요. 먼저 관찰 전용으로 시작하고(보고만 하고 쓰기는 하지 않음), 별일 없이 끝나는 실행을 거듭하며 신뢰를 쌓은 뒤 변경을 제안하는 단계로 올립니다. 이때 실행 순서 보장에 대한 근거(“검증이 새 마커를 반환한 뒤에만 purge 실행”)와 빠짐없이 작성한 영향 범위 선언을 스케줄을 등록하기 전에 문서화해야 합니다. 이러한 단계적 승격의 경제성은 검증 비용이 낮은 곳에서 루프가 유리합니다에서 다룹니다. 무엇을 무인으로 실행할 수 있는지는 루프 구축이 아니라 검증 비용이 결정합니다.

어떤 루프 입력도 동의로 간주되지 않습니다. 문서화된 네 가지 규칙이 같은 방향을 가리킵니다. 다른 세션에서 온 메시지는 “절대로 사용자의 동의로 간주되지 않습니다.”¹⁹ 팀원은 “사용자를 대신해 권한 프롬프트를 승인하거나 동의를 제공할 수 없습니다.”¹⁷ 클라우드 예약 작업에서 실행된 프롬프트는 “실행 중 작업에 대한 승인이나 동의로 작동할 수 없으며”, API 실행과 함께 보낸 텍스트는 “신뢰할 수 없는 데이터로 표시하는 <routine-fire-payload> 블록에 감싸여 전달됩니다.”¹⁸ 그리고 auto 모드에서 워크플로 스크립트가 agent()에 전달하는 프롬프트는 “Claude Code가 스크립트가 계산한 텍스트로 표시하기” 때문에 “사용자의 요청으로 간주되지 않습니다.”¹⁶ 이 규칙을 자신의 루프에도 그대로 적용하세요. 기계가 만든 텍스트는 데이터이고, 승인은 사람이 합니다.

더 근본적인 반론은 비용이 아니라 검토 역량입니다. 루프는 사람이 제대로 검토할 수 있는 속도보다 빠르게 코드를 만들어 냅니다.³³ 묘책은 없습니다. 적용 범위를 정직하게 정해야 합니다. 무인 루프는 기계가 검증할 수 있는 곳에서만 사용해야 합니다. 검증할 수 없다면 출시하지 마세요.

통제된 연구가 보여 주는 harness 구성 요소의 효과

이 가이드를 포함해 대부분의 harness 관련 조언은 실무자들이 실제 운영 환경에서 한 번에 하나씩 바꿔 본 경험에서 나옵니다. 2026년 9월 UMass Amherst, Emory, UNC Charlotte, Zoom의 연구는 이를 통제된 조건에서 실험했습니다. 연구진은 “실행 루프는 고정하고 계획, 행동 공간, 컨텍스트 관리라는 세 가지 구성 요소를 바꾸는” 실험용 harness를 만들었습니다. 그리고 “컨텍스트 관리 전략 5종, 컨텍스트 윈도 예산 4종, 계획과 행동 공간의 특정 요소를 제거하는 실험을 아우르는 176개 대응 설정”을 SWE-Bench Verified와 Terminal-Bench 2.1에서 실행했습니다. 모델은 가중치가 공개된 4종으로, 크기가 다른 Nemotron-3 3종과 Mistral-Medium-3.5-128B였습니다.³⁵ 연구진이 직접 서술한 네 가지 결과는 다음과 같습니다.

• “컨텍스트 윈도 예산이 줄어들수록 컨텍스트 관리의 가치가 커지며, 그 이점 대부분은 컨텍스트 초과로 인한 실패를 막는 데서 나옵니다.”
• “규칙 기반 생략을 LLM 기반 요약보다 먼저 수행하면 컨텍스트 관리 전략 중 전반적인 효율이 가장 높습니다. 반면 생략한 내용을 복구할 수 있도록 하면 모델이 거의 사용하지 않는 장치만 추가될 뿐 정확도는 높아지지 않습니다.”
• “계획은 성능이 낮은 모델에서는 정확도를 뒷받침하지만, 성능이 높은 모델에서는 정확도 변화가 거의 없는 상태에서 비용을 줄이는 역할로 바뀝니다.”
• “미리 정의된 도구는 bash 활용 능력이 낮은 모델의 성능을 높입니다. 반면 bash를 잘 활용하는 모델은 bash만 제공되는 인터페이스에서도 효과적으로 작동하며, 특히 명령줄 중심 작업에서 비용을 크게 줄일 수 있습니다.”

제가 보기에는 이 중 세 가지가 루프 엔지니어링에 직접 적용됩니다. 컨텍스트 관리는 용량 초과에 대비하는 보험입니다. 오래 실행되는 루프는 컨텍스트 윈도 예산을 관리하고, 요약에 앞서 부피가 큰 도구 출력을 생략해야 합니다. 모델이 사용하지 않을 정보 복구 장치는 만들지 않아도 됩니다. 성능이 좋은 모델에서 계획은 정확도를 높이는 수단보다는 비용을 조절하는 수단에 가깝습니다. 강력한 모델을 사용하는 루프에 계획 단계를 추가하기 전에 알아 둘 만한 결과입니다. bash 전용 인터페이스의 결과는 exec/model 분리를 한 단계 위에 적용한 셈입니다. 실행 주체의 역량이 충분하다면 행동을 더 큰 단위로 묶어 횟수를 줄일수록 비용이 낮아집니다. 한계는 연구 자체에서 밝힌 그대로입니다. 모델 4종, 벤치마크 2종을 사용했고 harness도 출시된 에이전트가 아니라 실험용으로 만들었으므로, 결과는 설정값이 아닌 방향성으로 받아들여야 합니다.³⁵

루프 집합 운영하기

루프 엔지니어링이 궁극적으로 지향하는 것은 루프 하나가 아니라 상시 운영되는 루프 집합입니다. 운영이 안정화되면 다음과 같은 모습이 됩니다.

• 파일로 관리하는 명세. 각 루프는 자신이 담당하는 저장소 안에 버전 관리되는 명세로 존재합니다. 명세에는 이름, 등급, 스케줄, 목표, 검증기, 허용 도구, 예산, 시간 제한이 담깁니다. 같은 수동 점검을 세 번 입력했다면 명세로 만들 차례입니다. Anthropic도 이 아이디어의 작은 버전을 제공합니다. loop.md 파일은 단독 /loop의 내장 프롬프트를 대체하며, 이 파일을 수정하면 다음 반복부터 적용됩니다.¹²
• 두 등급과 검증을 거친 승격. 관찰 루프는 무엇이든 읽을 수 있지만 자신의 보고서 디렉터리에만 쓸 수 있으며, 바로 스케줄에 등록할 수 있습니다. 행동 루프는 외부 상태를 바꾸므로 실행 순서 보장에 대한 근거, 영향 범위 선언, 생성 주체와 분리된 검증기가 필요합니다. 이 모두를 스케줄을 만들기 전에 문서화해야 합니다. 루프는 관찰 등급으로 시작하고 신뢰를 얻어 승격됩니다.
• exec/model 분리. 결정론적 점검은 스크립트로 실행합니다(토큰 사용량 0, 실행 시간 1~2초). 모델 루프는 판단이 필요한 작업에만 사용합니다. 루프 집합의 일일 정기 점검에는 비용이 전혀 들지 않을 수 있습니다.
• 보고 규약. 점검마다 PASS|FAIL <check>: <reason> 형식으로 한 줄씩 날짜가 포함된 보고서 파일에 추가합니다. 한눈에 이해할 수 있는 PASS 행을 정의할 수 없다면 아직 루프를 실행할 준비가 되지 않은 것입니다. 요약 루프가 전체 보고서를 읽으면 사람은 30페이지 대신 한 페이지만 읽으면 됩니다.
• 스스로 유지되는 기준선. 잘 설계된 변경 감시기는 가이드에 기록된 타임스탬프나 lockfile에 담긴 해시처럼 자신이 감시하는 결과물에서 기대값을 도출합니다. 결과물을 갱신하면 감시 기준도 함께 갱신되므로, 따로 관리하다 잊어버릴 두 번째 기준 정보가 없습니다.
• 중단되지 않는 스케줄링. 로컬 루프 집합은 OS 스케줄러(launchd, cron, systemd 타이머)가 실행 스크립트를 호출하는 방식으로 운영하거나, 컴퓨터가 계속 켜져 있다면 Desktop 예약 작업으로 운영합니다. 클라우드 루프 집합은 클라우드 예약 작업(이전 명칭 routines)으로 운영합니다. 세션에 종속된 루프(/loop)는 사람이 지켜보는 작업이나 백그라운드로 보낸 세션에 사용합니다.¹²

이는 Cherny의 “제 일은 루프를 작성하는 것입니다”를 구체화한 모습입니다. 사람의 역할은 점검 항목, 검증기, 예산을 명세하고 보고서를 읽는 쪽으로 옮겨 갑니다.

가장 먼저 만들 만한 두 가지 루프

루프 집합을 처음부터 구축한다면 바로 효과를 볼 수 있는 루프가 두 가지 있습니다. 둘 다 이 사이트의 harness에서 검증되었습니다.

게이트 루프 — 게시하는 모든 결과물에 적용하는 생성자-검토자 방식입니다. 이전 회차를 기억하지 못하는 새로운 평가자가 명시적인 기준에 따라 결과물을 평가합니다. 지적된 사항을 모두 반영하면 또 다른 평가자가 다시 평가합니다. 루프는 기준에 도달하거나 정해진 최대 회차에 이르면 멈춥니다. 게시물 15개를 집중적으로 작성하며 이 루프를 운영한 경험에서 두 가지를 배웠습니다. 수정이 새로운 결함을 만들 수 있습니다. 한 회차의 수정에서 수치의 출처를 잘못 기재했고, 다음 회차의 평가자가 이를 발견했습니다. 또한 평가자는 양쪽 방향으로 모두 틀릴 수 있습니다. 한 평가자는 사실인 주장을 자신 있게 “바로잡았으므로”, 구체적인 수정 제안은 적용하기 전에 원문 출처에서 확인합니다. 판단의 최종 근거는 검토자가 아니라 출처입니다.

관리인 루프 — 행동 등급에 진입하는 첫 단계입니다. 실행할 때마다 브랜치에서 객관적으로 검증할 수 있는 작은 수정 하나를 수행하고, 테스트가 통과한 뒤 PR을 엽니다. 루프 자체는 절대 병합하지 않습니다. 두 가지 규칙이 안전을 지켜 줍니다. 모호한 사항은 수정하지 않고 표시합니다(사람이 감독한 첫 실행에서도 탐지기의 오탐을 올바르게 거부했습니다). main에 이미 존재하는 실패는 기존 실패로 보고하며, 루프의 diff에 절대 포함하지 않습니다.

루프 집합 운영에서 참고할 만한 세부 사항이 하나 있습니다. 무인 모델 루프에 세션 임대권을 부여하세요. 같은 저장소에서 대화형 세션이 활성화되어 있는 동안에는 실행을 미룹니다. 하나의 체크아웃에 두 주체가 쓰다 보면 결국 커밋이 뒤섞입니다. 세션 임대권은 구조적으로 루프가 사람에게 양보하도록 만듭니다.

자주 묻는 질문

루프 엔지니어링이란 무엇입니까?

AI 에이전트에 매번 프롬프트를 입력하는 대신, 중지 조건이 충족될 때까지 작업 주기를 반복하도록 만드는 기법입니다. 엔지니어의 역할은 프롬프트 작성에서 루프 설계로 옮겨 갑니다. 다시 실행하는 규칙(조건, 스케줄, 이벤트), 반복 사이에 유지할 상태, 검증기, 예산을 설계합니다. Anthropic는 2026년 6월 이 분야에 이름을 붙였습니다. Claude Code에서 이를 사용하는 수단으로는 /goal, /loop, Ralph 플러그인, 클라우드 예약 작업(이전 명칭 routines), 동적 워크플로가 있습니다.

Ralph 루프란 무엇입니까?

Geoffrey Huntley가 2025년 7월 이름을 붙인, 반복 실행으로 밀어붙이는 자율 작업 패턴입니다. 셸 while 루프 안에서 Claude Code를 실행하며, 반복할 때마다 새로운 컨텍스트에 같은 프롬프트를 전달합니다. 진행 상황 파일과 git이 반복 사이의 상태를 이어 주고, 테스트는 진행을 제어하는 역압 역할을 합니다. Anthropic는 Stop hook으로 세션 안에서 반복을 수행하는 공식 ralph-loop 플러그인(2026년 1월 ralph-wiggum에서 이름 변경)을 제공하며, 주요 안전장치는 --max-iterations입니다.

Claude Code를 루프로 실행하려면 어떻게 해야 합니까?

필요를 충족하는 가장 낮은 단계부터 선택하세요. /goal <condition>은 별도 평가자가 조건 충족을 확인할 때까지 반복합니다. /loop <interval> <prompt>는 Claude Code 세션이 실행 중인 동안 주기적으로 실행합니다. /ralph-loop는 완료 약속을 출력할 때까지 한 작업을 반복합니다. /schedule은 내 컴퓨터 없이도 cron으로 실행되는 클라우드 예약 작업을 만듭니다. 헤드리스 환경에서는 외부 점검을 갖춘 셸 루프 안에서 claude -p를 실행하는 방식이 고전적인 형태입니다.

루프가 프롬프트 작성을 대체합니까?

프롬프트는 사라지지 않고 자리를 옮깁니다. 루프 명세에 한 번 작성하면 루프가 이를 다시 실행합니다. 동적 워크플로나 Cherny의 “실제로 프롬프트를 작성하는 것은 또 다른 Claude입니다”라는 설명처럼, 작업별 프롬프트를 오케스트레이션 에이전트가 작성하는 경우도 늘고 있습니다. 사람이 숙련해야 할 일은 프롬프트를 다듬는 작업에서 검증 설계로 바뀝니다. 기계나 새로운 모델이 확인할 수 있는 조건을 명시하는 일입니다.

Claude Code에서 루프, routine, 워크플로는 어떻게 다릅니까?

루프(/loop)는 로컬 Claude Code 세션 안에서 스케줄에 따라 프롬프트를 다시 실행하며, 해당 프로세스가 종료되면 더 이상 실행되지 않습니다. 백그라운드로 보낸 세션에서는 계속 실행됩니다. 클라우드 예약 작업(이전 명칭 routine)은 같은 개념을 클라우드 인프라에서 실행하도록 구성한 것입니다. cron, API, GitHub 이벤트로 실행할 수 있으며 노트북이 필요하지 않습니다. 워크플로는 단일 실행의 오케스트레이션 그래프입니다. Claude가 작성한 JavaScript 스크립트가 최대 1,000개의 subagents를 생성하고 조율하며, 반복과 분기를 컨텍스트가 아닌 코드로 관리합니다.

에이전트 루프의 비용은 얼마나 듭니까?

솔직한 답은 “무료부터 감당할 수 없는 수준까지”이며, 그 차이를 만드는 변수는 설계입니다. 결정론적 감시기는 스케줄에 따라 실행되는 스크립트이므로 비용이 들지 않습니다. 모델 루프는 반복마다 비용이 발생합니다. 상한을 설정하고(--max-iterations, --max-budget-usd), 성과를 관찰할 수 있게 해 추가 이득이 줄어들면 멈추도록 하세요. 모든 상한은 불편한 제약이 아니라 중지 규칙으로 취급해야 합니다. 밤새 수천 달러를 쓰거나 몇 분 만에 400만 토큰을 소모한 실패 사례는 근본 원인이 같습니다. 외부 중지 조건이 없었습니다.

언제 루프를 그래프로 바꿔야 합니까?

병렬 작업 사이에 의존성이 생길 때입니다. 한 작업에 다른 작업의 출력이 필요하거나, 두 에이전트가 같은 파일을 수정하게 되는 경우입니다. 루프는 저장소 하나와 목표 하나를 다룹니다. 그래프(동적 워크플로, 에이전트 팀, 외부 오케스트레이터)는 여기에 의존성에 따른 실행 순서, 파일별 작업 권한 선점, 병합 규칙을 더합니다. 실제로 충돌이 나타날 때만 그래프를 도입하세요. 구조가 추가되면 실행 상태를 파악하기 어려워지고 설정 부담도 늘어납니다.

변경 이력