에이전틱 루프 (The Agentic Loop) 🔄 루프 엔지니어링 (Loop Engineering): 실무 가이드 📘

AI 코딩 에이전트가 당신의 일일이적인 감독 없이도 실제 작업을 반복적이고 검증 가능한 방식으로 수행하게 만드는 방법.

현재의 관행(2025–2026)을 종합함: Addy Osmani의 "Loop Engineering", Peter Steinberger의 "Just Talk To It" 및 "Shipping at Inference‑Speed", Boris Cherny의 Claude Code에 관한 강연, Geoffrey Huntley의 Ralph 기술, Matt Van Horn의 "WTF Is a Loop?", Forward Future의 Loop Library, Lushbinary의 루프 엔지니어링 가이드, 그리고 Matthew Berman, Eric Lott, Hiten Shah 등 실무자들이 공유한 작동 루프들을 참고함.

📋 목차

⚡ TL;DR (요약)
1. 🔄 에이전틱 루프 (agentic loop)란 실제로 무엇인가
1. 🔧 프롬프팅 (prompting)에서 루프 엔지니어링 (loop engineering)으로
1. 🐣 루프의 시작: Ralph 기술
1. 🚀 이것이 지금 왜 중요한가
1. 🏗️ 좋은 루프의 해부학
1. 📝 보편적인 루프 템플릿
1. 🧱 자가 실행 루프의 5가지 구성 요소
1. 📜 중단 조건 (stop condition)을 계약처럼 작성하기
1. 📚 검증된 루프의 스타터 라이브러리
1. 🪜 성숙도 사다리: 루프를 안전하게 도입하기
1. 🛠️ 도구에서 루프 실행하기
1. 🛡️ 루프를 안전하게 유지하기 (타협 불가능한 가드레일)
1. 💸 이제 루프가 비용이 많이 드는 부분이다
1. 💬 "그냥 대화하세요 (just talk to it)"라는 상쇄 요인
1. ⚠️ 루프가 해결하지 못하는 위험 요소
1. 🐛 일반적인 실패 모드
1. ✅ 빠른 시작 체크리스트
📖 출처 및 추가 읽을거리

⚡ TL;DR

**에이전틱 루프 (agentic loop)**는 유용한 에이전트 작업의 가장 단순한 단위입니다: 무언가를 수행함 → 결과를 확인함 → 계속할지 중단할지 결정함. 이 기술의 핵심은 확인(check) 과정을 실질적으로 만드는 것과 언제 멈출지를 정의하는 것에 있습니다. 그 외의 모든 것 — 모델 선택, 하네스 (harness), MCPs, 하위 에이전트 (subagents) — 은 부차적인 것입니다.

한 문장만 기억한다면: 루프는 확인 과정이 포함된 작업입니다. 확인 과정이 없는 작업은 그저 희망 사항일 뿐입니다.

시야를 넓혀보면 이와 동일한 개념에 이름이 붙어 있습니다: 바로 루프 엔지니어링 (loop engineering) 입니다. 이는 모든 프롬프트를 직접 입력하는 대신, 정해진 일정과 목표에 따라 에이전트 (agent)에게 프롬프트를 전달하는 _시스템 (system)_을 설계하는 것을 의미합니다. Anthropic의 Boris Cherny가 표현했듯이, "내 업무는 루프를 작성하는 것이다." 이 가이드는 여러분을 하나의 좋은 루프에서 스스로 실행되는 루프로 안내하며, 어디에 브레이크가 있어야 하는지도 알려줄 것입니다.

1. 🔄 에이전틱 루프 (agentic loop)의 실체

대부분의 사람들은 "에이전트 (agent)"를 한 번에 코드를 작성하는 챗봇으로 상상합니다. 그것은 _일회성 작업 (one-time task)_입니다. 루프는 다릅니다. 에이전트는 다음과 같이 동작합니다:

관찰 (Observes): 현재 상태를 파악합니다 (파일 읽기, 테스트 실행, 스크린샷 찍기 등).
제한된 하나의 행동 수행 (Takes one bounded action): 한 가지 사항을 변경합니다.
확인 (Checks): 정해진 기준에 따라 무엇이 일어났는지 확인합니다.
결정 (Decides): 계속 진행할지, 성공했으므로 중단할지, 혹은 차단되었거나 예산(budget)을 초과하여 중단할지를 결정합니다.

        ┌───────────────────────────────────────────┐
        │                                           │
        ▼                                           │
...

한 단계의 결과가 다음 단계에 영향을 미쳐야 할 때 루프를 사용하세요. 그렇지 않다면 대신 일회성 작업을 사용하십시오. (Forward Future, How agent loops work.)

이것이 바로 "코드를 개선하라"는 명령은 실패하고, "동일한 테스트 조건 하에서 모든 페이지가 50ms 미만으로 로드되게 하라"는 명령은 성공하는 이유입니다. 전자는 결승선이 없지만, 후자는 에이전트가 매 변경 사항 이후에 실행할 수 있는 확인 절차와 _완료 (done)_를 나타내는 수치가 있기 때문입니다.

🔁 내부 루프 (Inner loop) vs. 외부 루프 (outer loop)

위의 사이클은 내부 루프 (inner loop) 입니다. 이는 코딩 에이전트가 매 턴마다 이미 실행하고 있는 것입니다. 즉, 상태를 인지하고, 무엇을 할지 추론하며, 행동하고 (도구 호출, 파일 편집, 테스트 실행), 결과를 관찰한 뒤 다시 추론합니다. 여러분이 이것을 만드는 것이 아니라, 하네스 (harness)가 수행합니다.

여러분이 구축하는 것은 외부 루프 (outer loop) 입니다. 즉, 여러분이 각 프롬프트를 직접 입력하지 않아도, 정해진 일정에 따라 내부 루프를 실행하고, 작업을 투입하며, 결과를 확인하고, 다음 단계를 결정하는 시스템입니다. 이 섹션 이후의 모든 내용은 이 외부 루프를 잘 설계하는 방법에 관한 것입니다.

2. 🔧 프롬프팅 (prompting)에서 루프 엔지니어링 (loop engineering)으로

2026년 6월, 이 패턴에 이름이 붙었습니다. Addy Osmani는 이를 **루프 엔지니어링 (loop engineering)**이라 불렀으며, 이는 Peter Steinberger와 Anthropic의 Boris Cherny (Claude Code 책임자)가 주장해 온 내용을 구체화한 것입니다:

"더 이상 코딩 에이전트 (coding agents)에게 프롬프트를 입력해서는 안 됩니다. 에이전트에게 프롬프트를 입력하는 루프 (loops)를 설계해야 합니다." — Peter Steinberger

"저는 더 이상 Claude에게 직접 프롬프트를 입력하지 않습니다. Claude에게 프롬프트를 입력하고 무엇을 할지 결정하는 루프를 실행합니다. 제 업무는 루프를 작성하는 것입니다." — Boris Cherny

이는 수년간 쌓여온 스택 (stack)의 세 번째 계층입니다. 각 계층은 내부의 계층을 감싸며, 레버리지 포인트 (leverage point)를 원시 모델 호출 (raw model call)로부터 더 멀리 이동시킵니다:

계층	최적화 대상	작업 단위
프롬프트 엔지니어링 (Prompt engineering)	하나의 지시어를 어떻게 표현하는가	직접 타이핑하는 한 번의 턴 (turn)
...

하위 계층이 사라지는 것은 아닙니다. 루프 내부의 허술한 프롬프트는 그저 허술한 결과물을 더 빠르게 만들어낼 뿐이며, 루프는 여전히 매 턴 모델 앞에 적절한 파일을 놓아주어야 합니다. 루프 엔지니어링이 추가하는 것은 이 모든 것을 아우르는 **자율적 제어 구조 (autonomous control structure)**입니다.

레버리지는 이동했지만, 작업이 쉬워진 것은 아닙니다. 잘 설계된 루프는 유능한 엔지니어를 배가시킵니다. 반면 잘못 설계된 루프는 당신의 감시가 적은 상태에서 잘못된 결정을 그만큼 빠르게 배가시킵니다.

3. 🐣 루프의 시작: Ralph 기법

이름이 붙기 전에는 Ralph가 있었습니다. 2025년 7월, Geoffrey Huntley는 일반적인 while 루프 안에서 코딩 에이전트를 실행하는 방식을 설명하며, 이를 Ralph Wiggum의 이름을 따서 명명했습니다. 그는 이를 "예측 불가능한 세상 속에서 결정론적으로 단순하다(deterministically simple in an unpredictable world)"라고 표현했습니다. 너무 멍청해 보여서 작동하지 않을 것 같지만, 실제로 작동합니다. (Huntley는 이를 이용해 약 297달러로 프로그래밍 언어 전체를 구축했습니다.)

# 오리지널 Ralph 루프: 완료될 때까지 동일한 프롬프트와 새로운 컨텍스트 사용
while ! grep -q "ALL TASKS DONE" STATUS.md; do
  # 각 패스 (pass)는 빈 컨텍스트 윈도우 (context window)를 가진 완전히 새로운 에이전트입니다
...

그 핵심적인 통찰은 바로 **컨텍스트 리셋 (context reset)**입니다. 세션이 길어지면 컨텍스트 윈도우 (context window)가 오래된 추론 과정, 막다른 길, 그리고 유효하지 않은 파일 내용으로 채워지면서 성능이 저하됩니다. Ralph는 이 문제를 우회합니다. 모든 반복 (iteration)은 현재 저장소 (repo) 상태와 작업 목록을 디스크로부터 읽어오는 깨끗한 컨텍스트를 가진 새로운 에이전트입니다. 각 에이전트는 정확히 하나의 작업 단위만 수행하고, 커밋(commit)한 뒤 종료합니다. 지능은 단 한 번의 영웅적인 실행에 머무는 것이 아니라, 모델이 오염시킬 수 없는 외부 메모리 (external memory)를 대상으로 반복해서 적용되는 명확하고 세밀한 명세 (specs)와 검증 가능한 결과물에 존재합니다.

루프 엔지니어링 (Loop engineering)은 제품화된 Ralph입니다. while 루프는 스케줄링된 자동화가 되고, 컨텍스트 리셋은 워크트리 (worktree)와 서브 에이전트 (sub-agent)가 되며, ALL TASKS DONE을 찾는 grep은 별도의 모델이 평가하는 /goal 조건이 됩니다. 구조는 같지만, 날카로운 모서리(부작용)는 줄어들었습니다.

📊 5단계 계보

Ralph는 갑자기 나타난 것이 아니며, 오늘날 Steinberger와 Cherny가 말하는 것도 Ralph가 아닙니다. *루프 (loop)*라는 단어에는 최소 다섯 가지의 서로 다른 의미가 숨겨져 있습니다. 이 사다리의 어느 지점에 있는지 아는 것이 타인과 겉도는 대화를 멈추는 가장 빠른 방법입니다.

단계	시기	이전 형태	추가된 요소
1. ReAct	2022	학술적 while-loop: 추론(reason) → 행동(act) → 관찰(observe) → 반복(repeat)	하나의 모델, 하나의 루프, 인간의 관찰
...

1~4단계는 단일 에이전트 (single-agent) 방식입니다. 5단계가 진정으로 새로운 것입니다. 루프가 (작업이 아닌) 작업의 단위가 되었고, 루프가 다른 루프들을 동시에 그리고 스케줄에 따라 감독하기 시작했으며, 스케줄링이 인간의 시작(kickoff)을 대체했습니다 (따라서 사용자의 주의력이 아닌 인프라의 시간에 따라 실행됩니다). 또한 내구성 (durability)이 명시되었습니다 (git 기반의 상태 관리 및 충돌 복구. Ralph는 사용자의 터미널이 계속 열려 있다고 가정했지만, 2026년 버전은 그렇지 않다고 가정합니다).

"그냥 모자 쓴 cron일 뿐이다" — 절반은 맞습니다. 전체 담론에서 가장 날카로운 회의론적 문장은 네 단어였습니다: "요즘 cronjob들이 이상한 리브랜딩(re-branding)을 하고 있다." 그리고 맞습니다, 스케줄링 레이어(scheduling layer)는 cron이 맞습니다. Claude Code의 /loop는 내부적으로 cron 위에서 실행됩니다. 하지만 cron에는 결코 없었던 것이 바로 '신체(body)'입니다. cron job은 고정된 스크립트를 실행하지만, 루프(loop)는 현재 상태를 읽고, 다음에 무엇을 할지 **결정(decides)**하며, 이를 실행하고, 성공 여부를 확인한 뒤, 계속할지 여부를 결정하는 모델을 실행합니다. 루프는 cron에 결정권자(decision-maker)라는 신체를 더한 것입니다. 이것들을 쌓아 올리면 — 즉, 하나의 루프가 내구성이 있는 공유 상태(durable shared state)를 가지고 다른 루프들을 배정하고 감독하게 하면 — cron으로는 표현할 수 없는 무언가가 탄생합니다. 오픈 소스 증거는 Steve Yegge의 Gas Town입니다: "Mayor(시장)" 에이전트에 의해 조정되는 20~30개의 Claude Code 인스턴스, 지속적인 루프를 실행하는 순찰(patrol) 에이전트들, 그리고 작업이 충돌(crash) 상황에서도 생존할 수 있도록 git에 저장된 상태(state)가 존재합니다.

🗺️ 5단계 오케스트레이션(orchestration)의 모습

flowchart TD
    CRON([⏰ Scheduler / cron tick]) --> MAYOR

...

위에서 아래로 읽어보세요: **스케줄러 틱(scheduler tick)**이 Mayor(외부 루프)를 깨우면, Mayor는 각 **순찰 에이전트(patrol agent)**에게 자신의 워크트리(worktree) 내에서 수행할 제한된 작업 하나를 전달합니다. 각 순찰 에이전트는 자신만의 내부 관찰(observe) → 실행(act) → 확인(check) 사이클을 실행하며, 그 후 **검증기(verifier)**가 결과를 통제합니다. 실패 시에는 재작업을 위해 Mayor에게 되돌아가고, 통과 시에는 **내구성이 있는 git 상태(durable git state)**에 커밋됩니다. 다음 틱은 해당 상태를 읽어 마지막 작업이 멈춘 지점부터 다시 시작합니다. Mayor는 세 가지 강제 중단 조건(최대 반복 횟수, 진전 없음, 예산 초과)을 집행하여, 전체 시스템이 낭떠러지로 떨어지듯 폭주하는 대신 멈출 수 있도록 합니다.

4. 🚀 이것이 지금 중요한 이유

역량의 기준선이 이동했습니다. 실무자들은 에이전틱 코딩(agentic coding)의 수준이 2025년 중반쯤 "이건 형편없다"에서 "이건 괜찮다"로 넘어갔으며, 최신 프론티어 코딩 모델(frontier coding models)과 함께 "괜찮다"에서 "이건 놀랍다"의 단계로 진입했다고 보고합니다. Steinberger의 표현을 빌리자면, 실질적인 결과는 다음과 같습니다: 이제 당신이 만들 수 있는 소프트웨어의 양은 타이핑 속도가 아니라, 주로 추론 시간(inference time)과 심도 있는 사고(hard thinking)에 의해 제한됩니다.

이는 여러분의 노력이 투입되는 지점을 변화시킵니다. 병목 현상은 더 이상 코드를 작성하는(writing) 것이 아니라, 에이전트가 관리자 없이 실행될 수 있고 여러분이 결과를 신뢰할 수 있을 만큼 목표(goal)와 검증(check)을 정밀하게 지정하는 것이 됩니다. 에이전틱 루프(agentic loop)는 바로 이 두 가지를 정확하게 인코딩하는 형식입니다.

두 번째로 중요한 이유: 루프를 닫는 것(closing the loop). 모든 신뢰할 수 있는 출처에서 반복되는 주제는, 에이전트가 _자신의 작업물을 스스로 검증(verify their own work)_할 수 있을 때(CLI를 실행하거나, 테스트를 수행하거나, 스크린샷을 비교(diff)하거나, 엔드포인트(endpoint)를 호출하는 등) 비약적으로 더 신뢰할 수 있게 된다는 점입니다. 무엇을 만들든, 에이전트가 스스로를 확인할 수 있도록 만드세요. "기본적으로 제가 만들고 싶은 것은 무엇이든 CLI로 시작합니다. 에이전트가 이를 직접 호출하고 출력을 검증할 수 있어 루프를 닫을 수 있습니다." (Steinberger.)

5. 🏗️ 좋은 루프의 해부학 (The anatomy of a good loop)

모든 신뢰할 수 있는 루프는 다섯 가지 요소를 명시적으로 정의합니다. 하나라도 놓치면 루프가 표류하거나, 무한히 실행되거나, 테스트는 실패하는데 "성공"했다고 보고하게 됩니다.

구성 요소	답변하는 질문	누락 시 발생하는 실패
트리거 (Trigger)	루프가 언제 실행되는가?	시작되지 않거나, 잘못된 시점에 실행됨
...

📐 네 가지 설계 규칙 (How agent loops work 기준)

측정 가능한 목표로 시작하세요. 검토하거나 측정할 수 있도록 결과를 기술하세요.
각 액션(action)을 작게 유지하세요. 한 번에 하나의 경계가 명확하고 되돌릴 수 있는(reversible) 변경을 수행하세요. 그래야 검증하기 쉽고 되돌리기도 쉽습니다.
고정된 검증(fixed check)을 사용하세요. 매 변경 후 동일한 테스트/벤치마크/루브릭(rubric)/승인 절차를 실행하세요. 작업의 개선 여부를 결정하는 것은 에이전트의 의견이 아니라 검증(check)입니다.
종료 조건을 정의하세요. 성공(Success), 작업 없음(no-op), 승인 요청(ask-for-approval), 차단됨/예산 초과(blocked/out-of-budget) 상황이 모두 명시되어야 합니다.

6. 📝 범용 루프 템플릿 (The universal loop template)

이 단일 프롬프트 구조는 Cursor, Codex, Claude Code, Factory, Devin 등 무엇에서나 작동합니다. 대괄호 부분을 채우세요:

[trigger]일 때, [fresh inputs]를 조사하세요. [criteria]를 사용하여 범위 내의 액션 중 하나를 선택한 다음, 변경을 수행하세요.

...

스케줄을 예약하기 전에 반드시 수동으로 한 번 실행해 보세요. 첫 번째 수동 실행에서는 누락된 체크(check), 모호한 경계(fuzzy boundary), 또는 더 날카롭게 다듬어야 할 종료 조건(stop condition)이 거의 항상 드러나기 마련입니다. (Forward Future.)

🍦 두 가지 유형

목표 루프 (Goal loop) — 수동으로 시작하며, 체크를 통과하거나 예산(budget)이 소진될 때까지 실행됩니다. (예: "테스트 스위트(test suite) 안정화")
스케줄된 루프 (Scheduled loop) — 타이머나 이벤트에 따라 시작되어, 제한된 작업을 수행하고, 보고한 뒤, 다음 트리거(trigger)를 기다립니다. (예: 5분마다 깨어나 저장소(repository)를 분류하고, 가장 가치 있는 제한된 작업을 할당하며, 어떤 것이 반영되기 전에 반드시 통과된 CI(Continuous Integration)를 요구하는 Steinberger의 5분 저장소 관리자)

7. 🧱 자가 실행 루프 (self-running loop)의 5가지 구성 요소

1년 전만 해도 루프란 당신이 영원히 관리해야 하는 bash 스크립트 더미를 의미했습니다. 2026년 중반 현재, 이러한 요소들은 제품 _내부(inside)_에 탑재되어 배포됩니다. 그리고 그 형태는 OpenAI Codex와 Anthropic의 Claude Code 전반에 걸쳐 동일하므로, 어떤 도구를 사용할지 논쟁하기보다는 어느 쪽에서든 작동하는 루프를 설계하는 것이 중요합니다. 루프에는 상태(state)를 기억할 한 곳과 더불어 다섯 가지 블록이 필요합니다.

#	블록 (Block)	역할	Codex에서	Claude Code에서
1	자동화 (Automations)	스케줄된 탐색(discovery) + 분류(triage)	Automations 탭 (프로젝트, 프롬프트, 주기, 환경); Triage 인박스; `/goal`	`/loop`, 스케줄된 작업/cron, 훅(hooks), GitHub Actions, `/goal`
...

이 중 네 가지는 메커니즘(mechanics)이며, 두 가지는 루프의 성패가 결정되는 지점입니다.