루프 엔지니어링: 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.234 기준 최신 내용입니다(2026년 8월).

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 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월 분류 체계를 따릅니다.¹¹)

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

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

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

/goal — 평가자-최적화 loop

/goal <condition>은 조건을 충족할 때까지 Claude이 계속 작업하게 합니다. “각 실행이 끝나면 작고 빠른 모델이 조건 충족 여부를 확인합니다. 충족되지 않았다면 Claude은 사용자에게 제어권을 돌려주는 대신 다음 실행을 시작합니다.”⁹ 기본적으로 Haiku를 사용하는 평가자는 예 또는 아니요와 그 이유를 반환하며, Claude은 이 내용을 다음 실행의 지침으로 활용해요. Headless 방식도 지원합니다. claude -p "/goal ..."를 사용하면 loop가 완료될 때까지 실행됩니다.

작성할 때는 조건을 막연한 목표(“코드가 깔끔함”)가 아니라 관찰 가능한 상태(“테스트 통과”, “endpoint가 200 반환”, “TypeScript 오류 0개”)로 만드세요. 검증 조건이 모호하면 loop가 나아갈 방향도 정할 수 없어요. 또한 자신감 있게 작성된 transcript가 모델이 판단하는 조건에 동의하도록 설득할 수 있으므로, 가능한 경우 /goal을 기계적인 검사와 함께 사용하세요.¹¹

v2.1.234에서는 loop 자체의 안정성을 높이는 두 가지 변경 사항이 적용됐어요. 이제 인증 취소, 크레딧 잔액 소진, context overflow처럼 복구할 수 없는 오류로 실행이 중단되면 goal은 더 이상 작업할 수 없는 세션에 활성화된 채 남지 않고 알림과 함께 자동으로 해제됩니다. 또한 background tasks 때문에 goal이 30분 이상 대기하면 Claude이 무기한 기다리지 않고 작업 상태를 확인해요. CLAUDE_CODE_GOAL_CHECKIN_MINUTES로 기준 시간을 조정할 수 있으며, 0으로 설정하면 기존의 무기한 대기 동작으로 돌아갑니다.³³

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

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

중요한 제약이 있어요. /loop는 사용자 세션 안에서만 유지됩니다. 터미널을 닫으면 loop도 종료돼요. 이 한계를 해결하는 기능이 routines입니다.

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

Anthropic의 공식 ralph-wiggum plugin은 커뮤니티에서 즐겨 사용하는 단순하고 강력한 패턴을 제품으로 구현했어요. Stop hook이 Claude의 세션 종료 시도를 가로채 프롬프트를 다시 주입하므로, 모델은 한 세션 안에서 계속 반복 작업을 수행합니다. /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>"로 시작하고 /cancel-ralph로 중단해요. README에서는 --max-iterations가 “가장 중요한 안전장치”라고 명확히 설명합니다. 정확한 문자열을 비교하는 완료 조건은 영원히 충족되지 않을 수 있기 때문이에요.¹⁴

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

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

제한과 구조는 다음과 같아요. 동시에 실행할 수 있는 에이전트는 16개이고, 실행당 최대 1,000개로 제한됩니다. 이 제한은 “제어 불능 loops를 방지”하기 위한 것이에요. 실행 중에는 사용자 입력을 받을 수 없습니다. .claude/workflows/에 저장한 스크립트는 재사용 가능한 slash commands가 되며, 캐시된 에이전트 결과를 이용해 실행을 재개할 수도 있어요.¹⁶ 대표적인 구조는 fan-out / refute / converge입니다. 독립적인 탐색 에이전트가 정보를 찾고, 적대적 검증 에이전트가 각 결과를 반박하도록 지시받은 뒤, 검증을 통과하는 답변이 나올 때까지 반복해요. 공개 당시 대표 사례는 Bun의 535,496줄 규모 Zig 코드베이스를 Rust로 이식한 작업입니다. Jarred Sumner의 설명에 따르면 에이전트 64개를 병렬로 실행해 2026년 5월 3일부터 14일까지 11일 만에 백만 줄이 넘는 Rust 코드베이스를 만들었어요.¹⁵

Agent teams — 동료 간 graph

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1을 통해 사용할 수 있으며, v2.1.32부터 research preview로 2026년 2월에 공개됐어요. 팀 리더와 팀원은 “각자 독립된 컨텍스트 창에서 독립적으로 작업하며 서로 직접 소통합니다.” subagent 트리가 아닌 동료 간 graph인 셈이에요. 의존성이 포함된 공유 작업 목록, 파일 잠금 기반 작업 선점, 에이전트별 mailbox를 통해 조율합니다. Hook으로 강제되는 quality gates에서 TaskCompleted가 종료 코드 2를 반환하면 완료 처리가 차단되므로, 팀원이 “완료”를 선언하기 전에 기계적인 검사를 거치게 됩니다.¹⁷

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

Routine은 “Claude Code 설정을 저장한 것입니다. 프롬프트, 하나 이상의 저장소, connectors 모음을 한 번 패키징하면” Anthropic가 관리하는 클라우드나 자체 self-hosted runners에서 자동으로 실행돼요.¹⁸ 함께 사용할 수 있는 트리거 유형은 3가지입니다. cron 일정(최소 1시간 간격), API 실행(POST .../routines/{id}/fire), GitHub 이벤트예요. /schedule이나 claude.ai/code/routines에서 만들 수 있습니다. 실행은 승인 프롬프트 없이 자율적으로 진행돼요. 바로 그렇기 때문에 다음 문서 경고가 매우 중요합니다. 녹색 실행 상태는 “프롬프트의 작업이 성공했다는 뜻이 아닙니다. 실행을 열고 transcript를 읽어 Claude이 실제로 무엇을 했는지 확인하세요.”¹⁸

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

지원 기능

Background subagents는 v2.1.198부터 기본값으로 적용되어 위임된 작업이 사용자 컨텍스트를 차지하지 않게 하며, /agents 패널에서 상태를 확인할 수 있어요. Cross-session messaging은 v2.1.224부터 SendMessage를 통해 독립된 세션들을 메시지 전달 graph로 연결합니다. 다른 세션에서 온 메시지는 “절대로 사용자의 동의로 간주되지 않는다”는 보안 원칙도 그대로 따를 만해요.¹⁹ Self-hosted runners는 v2.1.224부터 Team/Enterprise에서 제공되며, 사용자 소유 장비에서 클라우드 세션과 routines를 실행합니다. 조직 규모의 에이전트 집단을 운영하기 위한 기반이에요.²⁰

Ralph 패턴

커뮤니티가 먼저 이 지점에 도달했어요. 2025년 7월, Geoffrey Huntley는 The Simpsons 캐릭터의 이름을 따 이 기법을 명명한 에세이를 발표했어요. Ralph는 문자 그대로 다음과 같아요.

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

— 공개된 그대로의 한 줄 명령이에요. 하나의 저장소에서 반복마다 하나의 작업을 처리하고, 매번 새로운 컨텍스트를 사용하며, 파일 시스템의 명세와 진행 상황 파일로 반복 간 상태를 전달하고, 테스트와 린트가 “backpressure” 역할을 해요.²¹ 같은 구조를 현대적인 헤드리스 형태로 구현하면 셸 루프 안에서 claude -p "$(cat PROMPT.md)"를 실행하게 되며, 이는 본질적으로 Anthropic의 자체 C 컴파일러 harness가 실행한 방식이에요.²³ 그가 주장한 성과에는 토큰 비용 $297로 $50K 계약 규모의 MVP를 완성한 사례와 해커톤에서 하룻밤 사이에 6개 저장소를 만든 사례가 있지만, 한계도 그만큼 명확했어요. 그린필드에만 적합했고, 자리 표시자와 중복 구현이 반복적으로 발생했으며, “LLMs are mirrors of operator skill.”이라는 점이에요.

Anthropic는 엔지니어링 자료에서 이 이름을 사용하지 않지만, 이 패턴은 이제 두 차례에 걸쳐 공식 원칙으로 자리 잡았어요. 2025년 11월의 장기 실행 에이전트 에세이는 초기화 에이전트가 기능 목록과 진행 상황 파일을 만든 뒤, 컨텍스트 창마다 새로운 코딩 에이전트를 투입해 “진행 상황 메모 파일과 git 커밋 로그를 읽는 것으로 세션을 시작”하도록 하는 똑같은 구조를 제시해요.²² 또한 2026년 2월의 C 컴파일러 프로젝트에서는 파일 기반 작업 잠금과 git을 동기화 계층으로 사용해 16개의 Claude 에이전트를 병렬로 실행했어요. Nicholas Carlini의 표현대로 “나는 Claude을 간단한 루프에 넣는 harness를 만들었고”, 약 $20K의 비용으로 약 2,000개 세션에 걸쳐 약 100K줄의 Rust 코드를 생성했어요.²³ 이 에세이의 검증에 관한 문장이 패턴의 전체 이론을 요약해요. “작업 verifier가 거의 완벽해야 한다는 점이 중요하다.”

새로운 컨텍스트가 하나의 긴 세션보다 나은 이유는 세션의 컨텍스트가 차면서 효과가 떨어지기 때문이에요. 실무자들의 공통된 견해에 따르면 약 100K 토큰부터 결과가 흔들리기 시작하며, 압축 요약은 오류를 자신감 넘치는 문장으로 세탁하는 손실성 의역이에요.²⁴ Ralph의 새로운 프로세스 생성과 파일 기반 설계는 이 두 문제를 모두 우회해요. (공식 플러그인의 세션 내 반복 방식은 편의성을 위해 이 장점의 일부를 포기해요. 장시간 실행에는 외부 상태를 사용하는 헤드리스 방식이 여전히 더 강력한 패턴이에요.)

이 패턴의 경고 사례도 유익해요. 한 실무자가 모호한 프롬프트와 max_iterations: 0으로 플러그인을 실행했는데, 이 값은 비활성화가 아니라 무한 반복을 뜻해요. 그 결과 Claude은 같은 확인 질문을 스스로 1,966번 반복했고, Stop hook이 이후의 모든 메시지를 가로챘어요.²⁵ 반복 횟수 제한은 선택 사항이 아니에요.

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

단일 루프는 각 반복이 서로 독립적이거나 엄격한 순서로 진행된다고 가정해요. 병렬 작업에 의존성이 생기는 순간, 예를 들어 작업 B가 A의 결과를 필요로 하거나 두 에이전트가 같은 파일을 수정하려는 순간 자유 형식 루프는 충돌해요. 이때는 의존성 배열이 포함된 작업 목록, 파일 선점, 병합 규율 같은 명시적인 구조가 필요해요. 이것이 루프와 그래프 논쟁의 솔직한 핵심이에요. 하나의 저장소와 하나의 목표에는 루프를 사용하고, 병렬 작업에 순서가 필요하면 그래프를 사용하세요.²⁶

인프라 수준이 낮은 것부터 높은 것까지 그래프 선택지를 나열하면 다음과 같아요.

1. 동적 워크플로 — 의존성을 JavaScript 제어 흐름으로 표현하고, 한 단계가 앞선 모든 결과를 실제로 필요로 할 때만 장벽을 둬요. Anthropic가 명명한 토폴로지는 분산 후 종합, 적대적 검증, 생성 후 필터링, 토너먼트(“각각 다른 접근 방식으로 같은 작업을 시도하는 N개의 에이전트를 생성”한 뒤 쌍별로 판정), 완료될 때까지 반복이에요.¹⁵
2. 에이전트 팀 — 의존성을 추적하는 공유 작업 목록과 계획을 승인하는 리드가 있으며, 그래프는 코드가 아니라 데이터예요.¹⁷ 이 패턴에서는 한 가지 기본값이 변경됐어요. v2.1.233부터 작업 도구(TaskCreate/Get/Update/List, TodoWrite)는 Opus 4.8, Sonnet 5, Fable 5 이상에서 기본적으로 꺼져 있어요. 문서에는 Task 도구가 없는 에이전트가 “공유 작업 목록 대신 메시지를 통해 조율한다”고 명시되어 있어요. 따라서 최신 세대의 기본 설정에서는 작업 목록이 아무런 알림 없이 존재하지 않아요. 복원하려면 CLAUDE_CODE_ENABLE_TODO_TOOLS=1을 설정하세요.³³
3. 외부 오케스트레이터 — 커뮤니티가 확장한 방식이에요. Steve Yegge의 Gas Town은 git 기반 “beads”로 구성된 DAG를 대상으로 20~30개의 Claude Code 인스턴스를 실행해요. 그의 설명에 따르면 17일 만에 75K줄의 Go 코드를 만들었지만, 숙련된 운영자가 필요한 “돈 먹는 하마”이기도 해요.²⁷ claude-flow/Ruflo(약 31K개의 스타)는 퀸과 워커 계층으로 스웜을 감싸며, LangGraph 유형의 엔진은 노드 내부에 Claude Code을 두고 그 위에 타입이 지정된 상태 머신을 올려요.

Cherny가 이 발전 과정을 직접 체계화한 모델은 2026년 7월 Anthropic를 통해 공개한 AI 도입 단계 사다리예요. Gated(에이전트 0개) → Assisted(약 1개) → Parallel(약 10개) → Supervised autonomy(약 100개, 여기서는 “대부분의 에이전트를 사람이 아니라 Claude이 시작”) → AI-native(1,000개 이상)로 이어져요. 이와 함께 그는 “각 단계에서 다음 병목을 찾아 세분화하고, 다음 guardrail을 구축해야 한다”고 조언해요.²⁸

검증 엔지니어링

위의 모든 내용은 배관에 불과해요. 이 섹션이 진짜 제품이에요.

Anthropic의 단계별 강화 체계는 현재의 모범 사례 문서에서 가져왔어요. Claude에게 통과 또는 실패 결과를 생성하는 수단을 제공하면 “루프가 스스로 닫혀요” → 별도의 평가자가 다시 확인하는 /goal 조건 → “결정론적 gate” 역할을 하는 Stop hook → “자체 결과를 검사하는 검증 subagent 또는 동적 워크플로가 새로운 모델에 결과를 반박하도록 해, 작업을 수행한 에이전트가 스스로 채점하지 않게 해요.”²⁹ 여기에 적용되는 증거 규범은 다음과 같아요. “Claude이 성공을 주장하는 대신 증거를 제시하게 하세요.”

세 가지 피드백 유형은 Agent SDK 에세이에서 가져왔어요. 규칙 기반 피드백(“출력에 대한 규칙을 명확히 정의한 뒤 어떤 규칙이 왜 실패했는지 설명”하는 최선의 형태), 시각적 피드백(스크린샷, 픽셀 차이), LLM-as-judge(모호한 평가 기준으로, Anthropic의 표현에 따르면 “일반적으로 그다지 견고한 방법이 아님”)예요.⁷ 이 순서대로 우선하세요. 실제로 존재하는 결정론적 검사는 의견을 제시하는 judge보다 나아요.

수렴 조건. 루프에 대한 가장 날카로운 비판적 분석인 Yoko Li의 2026년 8월 분석에서는 수렴에 필요한 조건을 4가지로 정리해요. 정의된 목표 상태, 관찰 가능한 현재 상태, 정밀한 국소 수정, 그리고 생성기 외부에 있는 중단 규칙이에요. 계측된 실험에서 기억할 수치는 다음과 같아요. 수익이 로그함수처럼 둔화됐다는 사실을 루프에 알려 주는 장치가 없었기 때문에 루프가 소비한 토큰의 67%는 아무런 개선도 만들지 못했어요.³⁰ 예산 상한은 단순한 비용 통제 수단이 아니라 최후의 중단 규칙이에요.

테스트 무결성. Anthropic의 장기 실행 에이전트 원칙에는 다음과 같이 나와 있어요. “테스트를 제거하거나 수정하면 기능이 누락되거나 버그가 발생할 수 있으므로 허용할 수 없다.”²² 루프는 보이는 테스트는 통과하면서 숨겨진 의도는 충족하지 않는 방식으로 명세를 공략하므로, verifier 자체도 평가 대상인 에이전트로부터 보호해야 해요.

경로가 아니라 결과를 평가하세요. evals 에세이에서는 “에이전트가 거친 경로가 아니라 생성한 결과를 평가”하고, 객관적인 항목에는 코드 기반 grader를, 평가 기준에는 모델 기반 grader를 사용하라고 해요. 또한 다음과 같이 보정해야 해요. “여러 번의 시도에서 나온 기록과 평가 결과를 직접 읽지 않으면 grader가 제대로 작동하는지 알 수 없다.”³¹

대부분의 논의에서 놓치는 구분이 하나 더 있어요. 루프의 모든 검사가 결정론적이라면 루프에 모델이 들어갈 이유가 전혀 없어요. 타임스탬프를 비교하는 변경 감시기, 링크 검사기, 빌드 감시기는 일정에 따라 실행되는 셸 스크립트면 충분해요. 토큰을 전혀 쓰지 않고, 몇 초 만에 실행되며, 완벽하게 반복 가능해요. 판단이 필요한 반복 작업에만 모델 기반 루프를 사용하세요. 가장 저렴한 루프는 모델을 한 번도 호출하지 않는 루프예요.

비용 및 안전 규율

루프 엔지니어링에 대한 커뮤니티의 가장 큰 반대 의견은 비용이며, 사후 분석 사례들이 이를 뒷받침해요. subagent를 생성하는 버그가 5분 만에 4M 토큰을 소모하거나, 밤새 실행된 루프가 수천 달러를 사용하거나, 사용량 제한에 “예상보다 훨씬 빨리” 도달한 사례가 있어요.³² 이후 그 장벽 중 하나가 바뀌었어요. v2.1.234부터는 claude.ai 사용량 제한이 초기화되면 세션이 자동으로 계속 실행돼요(/config → “Continue automatically at usage limit”에서 끌 수 있어요). 이전에는 한도에서 종료되던 야간 루프가 이제 사용 가능 시간이 다시 열리면 재개되므로, 아래의 예산 통제는 덜 중요한 것이 아니라 오히려 더 중요해졌어요.³³ 다음은 각 위험에 대응해 제품에 구현된 통제 수단이에요.

마지막 행은 별도의 문단으로 다룰 가치가 있어요. 가장 공격적으로 운영하는 실무자들이 안전을 유지하는 방법이기 때문이에요. pull request를 피해 범위로 삼으세요. 하나는 아키텍처를 지속적으로 개선하고 다른 하나는 중복 추상화를 찾는 Cherny의 상시 백그라운드 에이전트는 사람의 명령 없이 PR을 제출하지만,² 검토 없이는 아무것도 병합되지 않아요. 최악의 결과가 “병합되지 않은 브랜치”인 상시 실행 루프는 강하게 돌려도 되지만, main에 직접 쓰는 루프는 그렇게 할 수 없어요. 루프는 점진적으로 승격하세요. 먼저 관찰 전용으로 시작해 보고서만 만들고 파일에는 쓰지 않게 하세요. 문제없이 반복되는 실행을 통해 신뢰를 얻은 뒤 변경 제안 단계로 올리세요. 일정을 설치하기 전에 순서 보장(“새 marker가 반환됐다고 검증된 후에만 purge를 실행”)과 전체 피해 범위 선언을 문서로 작성해야 해요. 이 승격 과정의 경제성은 검증 비용이 낮은 곳에서 루프가 승리하는 이유에서 다뤄요. 무엇을 무인으로 실행할 수 있는지는 루프 구축 비용이 아니라 검증 비용으로 결정돼요.

가장 근본적인 반론은 비용이 아니라 검토 역량이에요. 루프는 사람이 의미 있게 검토할 수 있는 속도보다 빠르게 코드를 생성해요.³⁴ 영리한 해답은 없으며, 범위를 솔직하게 정하는 수밖에 없어요. 무인 루프는 검증을 기계적으로 수행할 수 있는 곳에만 속하며, 그 외에는 사용하면 안 돼요. “검증할 수 없다면 출시하지 마세요.”²⁹

Fleet 운영하기

loop engineering의 최종 형태는 하나의 loop가 아니라 상시 운영되는 fleet이에요. 체계가 안정적으로 자리 잡으면 다음과 같은 모습이 됩니다.

• 파일로 관리하는 명세. 각 loop는 이름, tier, 일정, 목표, verifier, 허용된 도구, 예산, timeout을 정의한 버전 관리 명세이며, 해당 loop가 지원하는 저장소에 저장돼요. 같은 수동 검사를 세 번 입력했다면 이제 명세로 만들 차례예요.
• 두 가지 tier와 검증을 거친 승격. Observe loop는 무엇이든 읽을 수 있지만 자체 보고서 디렉터리에만 쓰며 즉시 일정을 설정할 수 있어요. Act loop는 외부 환경을 변경하므로 순서가 안전하다는 증명, 영향 범위 선언, maker와 분리된 verifier가 필요하며, 이 세 가지는 일정을 만들기 전에 작성해야 해요. 모든 loop는 observe로 시작해 자격을 입증한 뒤 승격돼요.
• exec/model 분리. 결정론적 검사는 스크립트로 실행하고 토큰을 전혀 사용하지 않으며 1~2초면 끝나요. model loop는 판단이 필요한 작업에만 사용해요. fleet의 일일 상태 점검에는 비용이 전혀 들지 않을 수도 있어요.
• 보고서 규약. 검사마다 한 줄씩 PASS|FAIL <check>: <reason> 형식으로 날짜별 보고서 파일에 추가해요. 한눈에 알아볼 수 있는 PASS 줄을 정의할 수 없다면 아직 loop를 실행할 준비가 되지 않은 거예요. digest loop가 fleet의 보고서를 읽도록 구성하면 사람은 30페이지가 아니라 한 페이지만 읽으면 돼요.
• 스스로 유지되는 기준선. 가장 뛰어난 drift watcher는 자신이 지키는 artifact에서 예상값을 가져와요. 가이드 자체에 기록된 timestamp나 lockfile 자체의 hash가 그 예예요. artifact를 업데이트하면 watcher도 함께 업데이트되므로 잊어버리기 쉬운 두 번째 진실의 원천이 생기지 않아요.
• 지속 가능한 일정 실행. 로컬 fleet은 runner script를 호출하는 운영체제 scheduler(launchd, cron, systemd timers)에서 실행하고, cloud fleet은 routines로 실행해요. 세션에 종속되는 loop(/loop)는 사용자가 직접 지켜보는 작업에 적합해요.

이는 Cherny가 말한 “내 일은 loop를 작성하는 것이다”를 구체화한 모습이에요. 사람의 역할은 검사, verifier, 예산을 명세하고 보고서를 읽는 일로 바뀌어요.

가장 먼저 만들 가치가 있는 두 가지 Loop

fleet을 처음부터 구축한다면 다음 두 가지 loop부터 시작하세요. 둘 다 이 사이트의 harness에서 효과가 입증됐어요.

gate loop — 게시하는 모든 콘텐츠에 적용하는 maker-checker예요. 이전 라운드의 기억이 없는 새 evaluator가 명시적인 기준에 따라 artifact를 평가하고, 사용자는 지적된 모든 문제를 수정해요. 그런 다음 새 evaluator가 다시 평가하며, 기준을 충족하거나 정해진 최대 라운드 수에 도달하면 loop가 멈춰요. 15개 게시물을 연속으로 작업하며 얻은 두 가지 현장 교훈이 있어요. 수정 과정에서 새로운 결함이 생길 수 있고, 실제로 한 라운드에서 수치를 잘못 귀속한 문제를 다음 라운드의 evaluator가 발견했어요. 또한 evaluator는 양쪽 방향으로 모두 틀릴 수 있어요. 한 evaluator는 사실인 주장을 확신에 차서 “수정”했기 때문에, 구체적인 수정 사항은 적용하기 전에 원문 출처에서 검증해야 해요. checker가 권위 있는 근거는 아니며, 출처가 권위 있는 근거예요.

groundskeeper — act-tier의 진입점이에요. 실행할 때마다 객관적으로 검증할 수 있는 작은 문제 하나만 branch에서 수정하고, 테스트가 통과한 뒤에만 PR을 열며, loop 자체는 절대 merge하지 않아요. 두 가지 규칙이 안전을 지켜줘요. 모호한 문제는 무엇이든 수정하지 않고 표시만 하며, 첫 번째 감독 실행에서도 detector의 false positive를 올바르게 수정하지 않았어요. 또한 main에 이미 존재하던 실패는 그대로 보고하고 loop의 diff에 포함하지 않아요.

fleet 운영에서 참고할 만한 세부 사항이 하나 더 있어요. 무인 model loop에 session lease를 부여하세요. 같은 저장소에서 대화형 세션이 실행 중이면 모든 실행을 미뤄야 해요. 하나의 checkout을 두 writer가 함께 사용하면 언젠가는 commit이 서로 뒤섞이게 돼요. session lease를 사용하면 loop가 구조적으로 사람에게 우선권을 양보해요.

자주 묻는 질문

loop engineering이란 무엇인가요?

AI agent에게 매번 차례로 prompt를 입력하는 대신, 중지 조건을 충족할 때까지 작업 주기를 반복하게 만드는 방식이에요. engineer의 역할은 prompt 작성에서 loop 설계로 바뀌어요. 다시 실행되는 규칙인 조건, 일정, event와 iteration 사이에 유지되는 state, verifier, 예산을 설계해야 해요. Anthropic은 2026년 6월에 이 분야에 이름을 붙였으며, Claude Code에서 제공하는 관련 기능은 /goal, /loop, Ralph plugin, routines, dynamic workflows예요.

Ralph loop란 무엇인가요?

Geoffrey Huntley가 2025년 7월에 이름 붙인 brute-force autonomy pattern이에요. shell의 while loop에서 Claude Code을 실행하고 iteration마다 fresh context와 함께 같은 prompt를 전달해요. progress file과 git이 각 실행 사이의 state를 유지하고, 테스트는 backpressure 역할을 해요. Anthropic은 Stop hook을 통해 세션 안에서 반복을 수행하는 공식 ralph-wiggum plugin을 제공하며, --max-iterations가 기본 안전장치예요.

Claude Code을 loop로 실행하려면 어떻게 해야 하나요?

목적에 맞는 가장 낮은 ring을 선택하세요. 별도의 evaluator가 조건 달성을 확인할 때까지 반복하려면 /goal <condition>을 사용하고, 세션이 열려 있는 동안 작업을 반복 실행하려면 /loop <interval> <prompt>를 사용하세요. 하나의 작업을 완료 약속이 충족될 때까지 반복하려면 /ralph-loop를 사용하고, 컴퓨터 없이도 cron에 따라 실행되는 cloud routine을 만들려면 /schedule을 사용하세요. headless 환경에서는 외부 검사와 함께 shell loop 안에서 claude -p를 실행하는 방식이 전형적이에요.

loop가 prompting을 대체하나요?

prompt는 사라지지 않고 위치가 바뀌어요. loop의 명세에 한 번 작성하면 loop가 이를 반복해서 실행해요. 점차 dynamic workflows와 Cherny가 말한 “실제로 prompting을 수행하는 것은 또 다른 Claude이다”라는 방식처럼 orchestrating agent가 작업별 prompt를 작성하게 돼요. 사람의 기술로서 prompt 작성법을 대신하는 것은 verification design이에요. machine이나 fresh model이 검사할 수 있는 조건을 명시하는 일이 핵심이에요.

Claude Code에서 loop, routine, workflow는 어떻게 다른가요?

loop(/loop)는 로컬 세션 안에서 일정에 따라 prompt를 다시 실행하며 세션이 종료되면 함께 멈춰요. routine은 같은 개념을 cloud infrastructure에서 실행하도록 구성한 형태예요. cron, API, GitHub event를 통해 실행할 수 있으며 laptop이 필요하지 않아요. workflow는 단일 실행을 위한 orchestration graph예요. Claude이 작성한 JavaScript script가 최대 1,000개의 subagents를 생성하고 조율하며, loop와 분기 구조는 context가 아니라 code에 담겨요.

agent loop에는 비용이 얼마나 드나요?

솔직한 답은 “0에서 감당할 수 없는 수준까지”이며, 비용을 결정하는 변수는 설계예요. 결정론적 watcher는 일정에 따라 실행되는 스크립트이므로 비용이 들지 않아요. model loop는 iteration마다 비용이 발생해요. --max-iterations와 --max-budget-usd로 상한을 설정하고, 수익을 관찰할 수 있게 만들어 한계 수익이 줄어들 때 loop가 멈추도록 하세요. 모든 상한은 불편한 제약이 아니라 중지 규칙으로 다뤄야 해요. 하룻밤 사이에 수천 달러를 쓰거나 몇 분 만에 4M tokens를 소비한 실패 사후 분석에는 공통된 근본 원인이 있어요. 외부 중지 조건이 없었다는 점이에요.

loop는 언제 graph로 전환해야 하나요?

병렬 작업 사이에 의존성이 생겼을 때예요. 한 작업에 다른 작업의 결과물이 필요하거나 두 agent가 같은 파일을 수정해야 하는 경우가 해당해요. loop는 하나의 저장소와 하나의 목표를 처리하고, graph(dynamic workflows, agent teams, external orchestrators)는 의존성 순서, 파일 소유권, merge 규칙을 추가해요. 실제로 충돌이 발생할 때만 graph를 도입하세요. 추가되는 구조만큼 observability와 설정 비용이 늘어나요.

변경 이력