Loop Engineering — 수동 Agent 프롬프팅의 한계를 넘어, 프로그래머가 Loop를 설계해야 하는 이유

작성자: Nokka (นก-กา) | 2026년 7월 1일

TL;DR — 바쁜 분들을 위한 요약

지난 2026년 6월 중순, OpenClaw의 창시자인 Peter Steinberger가 던진 6단어의 문장으로 AI developer 업계가 요동쳤습니다:

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

이 문장은 하루 만에 800만 회의 조회수를 기록하며, 이번 달 가장 뜨거운 버즈워드(buzzword)인 "Loop Engineering" 열풍을 일으켰습니다.

Loop Engineering이란 Agent에게 한 번에 하나씩 명령어를 입력하는 방식에서 벗어나, 대신 Agent를 프롬프팅(Prompting)하는 Loop (프로그램)를 작성하는 것을 의미합니다. 이 Loop는 다음 작업을 선택하고, Agent에게 전달하며, 결과를 검증하고, 계속 진행할지 중단할지를 결정합니다. 당신은 더 이상 Agent의 운전자가 아닙니다 — 당신은 Agent를 구동하는 시스템을 설계하는 설계자입니다.

1. Loop Engineering이란 무엇인가? 어디에서 시작되었는가?

이 논의는 2026년 6월 초, Claude Code의 창시자인 Boris Cherny가 Acquired Unplugged 무대에서 다음과 같이 말하며 시작되었습니다:

"I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops."

이틀 후, Peter Steinberger는 X에 "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."라는 글을 게시했습니다. 이 포스트는 800만 회의 조회수를 기록했습니다 [1].

그 후 Addy Osmani (Google Engineer, O'Reilly 저자)는 O'Reilly Radar에 "Loop Engineering"이라는 글을 기고하며 다음과 같이 정의했습니다: "Loop engineering is replacing yourself as the person who prompts the agent." [2]

또한 @0xCodez는 "prompter"에서 "loop designer"로 거듭나기 위한 14단계 로드맵을 정리했습니다 [3].

개인적인 견해로는, Loop Engineering은 단순한 버즈워드(buzzword)가 아니라, AI와 작업하는 추상화 계층(abstraction layer)의 변화입니다. 이는 우리가 Assembly → High-level language로, 또는 Bare metal → Cloud로 전환했던 것과 유사합니다. 하지만 Loop Engineering은 여전히 새로운 개념이며 명확한 표준 관행(standard practice)이 없다는 점을 인정해야 합니다. 오늘 유효한 방식이 3개월 뒤에는 바뀔 수도 있습니다.

2. 왜 Loop Engineering이 필요한가?

기존의 AI 코딩 에이전트 (AI coding agent)와 작업하는 모습을 상상해 보세요:

• 당신이 프롬프트 (prompt) 입력 → 대기 → diff 확인 → 프롬프트 수정 → 대기 → diff 확인 → 프롬프트 수정... 당신이 에이전트를 구동하는 엔진 (engine) 역할을 합니다.
• 당신이 화장실에 가기 위해 자리를 비우면 에이전트도 작동을 멈춥니다.
• 10가지 작업이 있다면, 당신은 하나씩 앉아서 처리해야 합니다.

Loop Engineering은 이 지점을 변화시킵니다: 당신은 대신 엔진 역할을 하는 루프 (Loop)를 작성합니다.

• 루프가 다음 작업을 스스로 선택합니다.
• 루프가 에이전트에게 작업을 전달합니다.
• 루프가 결과를 검증합니다.
• 루프가 계속 진행할지 아니면 중단할지 결정합니다.
• 루프는 당신이 잠든 동안에도 작동합니다.

Peter Steinberger는 "내 코드의 40% 이상은 이미 루프에 의해 작성되었다"라고 말하며, "우리가 협업하는 기업의 90%는 검증 루프 (verification loops)를 사용하지 않는데, 그것이 그들의 가장 큰 실수이다"라고 언급했습니다 [4].

3. 루프의 작동 원리

모든 루프는 다음과 같은 동일한 4단계 사이클을 가집니다:

Act (실행) → Observe (관찰) → Reason (추론) → Repeat (반복)

• Act (실행): 에이전트가 명령에 따라 작업 수행 (코드 작성, 명령 실행, 문제 해결)
• Observe (관찰): 시스템이 도출된 결과 읽기 (diff 확인, 테스트 결과 확인, 에러 로그 확인)
• Reason (추론): 시스템이 결과가 목표에 부합하는지 평가
• Repeat (반복): 통과하지 못했다면 — 에이전트에게 다시 수정을 요청하도록 전달; 통과했다면 — 다음 작업으로 이동

쉘 (shell)에서의 간단한 루프 예시:

while ! verify; do
  agent "fix the issue"
done

이 3줄의 코드가 Loop Engineering의 핵심입니다. 에이전트가 올바르게 작동할 때까지 반복해서 프롬프트를 입력하는 대신, 루프가 그 역할을 수행하도록 만드는 것입니다.

기존 방식 vs Loop Engineering 비교

차원	수동 프롬프팅 (Manual Prompting)	Loop Engineering
엔진 (Engine)	당신이 운전자임	루프가 운전자임
...

4. 프롬프터 (Prompter)에서 루프 설계자 (Loop Designer)로 가는 14단계 로드맵

@0xCodez는 학습 경로를 3단계로 구분했습니다 [3]:

레벨 1 — 루프 사용 여부 결정하기

1. 언제 루프를 사용해야 하는지 알기 — 반복적인 작업, 시행착오가 필요한 작업, 여러 번의 검증이 필요한 작업
2. 언제 루프를 사용하지 말아야 하는지 알기 — 일회성 작업, 모든 단계에서 인간의 판단 (human judgment)이 필요한 작업
3. 루프의 비용을 알기 — 루프는 반복이 발생하기 때문에 단일 프롬프트보다 더 많은 토큰 (tokens)을 사용함

레벨 2 — 5가지 빌딩 블록 (Building Blocks) 학습하기

1. Verifier (검증기) — 작업이 성공했는지 확인 (테스트 통과 여부? diff가 정확한가?) Verifier는 Loop의 핵심입니다 — Verifier가 나쁘면 Loop도 나쁩니다.
2. State Management (상태 관리) — 루프 사이의 상태 저장 (어떤 작업을 완료했는가? 어떤 작업이 대기 중인가?)
3. Error Handling (오류 처리) — Agent가 실수했을 때 어떻게 처리할 것인가? (재시도 (retry)? 롤백 (rollback)? 인간에게 알림?)
4. Context Management (컨텍스트 관리) — 매 루프마다 Agent에게 얼마만큼의 컨텍스트 (context)를 전달할 것인가? (너무 많지도, 너무 적지도 않게)
5. Cost Control (비용 제어) — 루프 횟수 제한, 루프당 토큰 (tokens) 제한, 예산 (budget) 설정

레벨 3 — 실용적인 Loop 구축하기

1. 가장 작은 Loop부터 시작하기 — 1개의 작업, 1개의 verifier, 오류 처리 (error handling) 없음
2. 안전성 (safety) 추가 — 최대 루프 횟수 제한, 실패 시 롤백 (rollback), 모든 사항 로그 (log) 기록
3. 상태 (state) 추가 — Loop가 이전에 무엇을 했는지 기억하도록 함
4. 서브 에이전트 (sub-agent) 추가 — 특정 작업을 위해 Loop가 하위 에이전트를 생성하도록 함
5. 스케줄링 (scheduling) 추가 — 특정 시간 또는 이벤트가 발생했을 때 Loop가 작동하도록 함
6. 모니터링 (monitoring) 추가 — Loop가 어떻게 작동하는지, 비용을 얼마나 쓰는지, 어디에 문제가 있는지 확인

5. Claude Code 및 Codex에서의 Loop Engineering

현재 Loop Engineering을 지원하는 주요 도구:

Claude Code

• /loop — 반복적인 스케줄링된 프롬프트 (scheduled prompts) 생성
• /goal — 지정된 조건이 충족될 때까지 실행
• hooks — 다양한 이벤트가 발생했을 때 수행할 액션 (action) 정의
• subagents — 특정 작업을 위한 하위 에이전트 생성
• worktree isolation — 매 루프마다 환경 (environment) 격리

OpenAI Codex CLI

• Automations (자동화) — 사람의 명령 없이 반복되는 작업
• /goal — 조건이 충족될 때까지 실행 (CLI 0.128.0 버전에서 추가)
• worktrees — 환경 격리
• skills — 재사용 가능한 컴포넌트 (reusable components)
• TOML-defined subagents — TOML 파일 내에서 서브 에이전트 정의

두 도구 모두 외부 도구 (tools)와 연결하기 위해 MCP (Model Context Protocol)를 사용합니다 [5]

6. Loop Engineering의 위험성

Loop Engineering은 지름길이 아닙니다. 프로그래머가 반드시 알아야 할 위험 요소가 있습니다:

6.1 Weak Verification (취약한 검증)

가장 빈번하게 발생하는 문제 — Agent가 작업을 완료했다고 주장하지만, 실제로는 완료되지 않았거나 잘못 수행된 경우 "The agent claims done without proof" (에이전트가 증거 없이 완료되었다고 주장함)

예시: 에이전트가 "test passed"라고 말하지만 실제로는 테스트가 실행되지 않았거나, 에이전트가 버그 하나를 수정했지만 세 개의 새로운 버그를 생성한 경우

해결책: 강력한 검증기 (Verifier) 사용 — 실제 테스트 실행, diff 확인, linter 사용. 에이전트가 자신의 작업을 스스로 검증하게 두지 마세요.

6.2 이해 부채 (Comprehension Debt)

당신이 잠든 사이에 Loop가 작동하면, 당신이 아직 읽지 않은 코드를 작성합니다. "Code ships faster than you can understand it" (코드가 당신이 이해하는 속도보다 더 빠르게 배포됩니다)

자고 일어나면 Loop가 작성한 1,000줄의 코드를 마주하게 됩니다. 그것이 무엇을 하는지 알 수 없어 코드를 읽는 데 다시 반나절을 소비해야 합니다. Loop를 통해 얻은 속도는 이해하는 데 드는 시간과 함께 사라져 버립니다.

해결책: 회차당 작업 규모 제한, Loop가 매번 요약(Summary)을 작성하도록 설정, 머지(Merge) 전 코드 리뷰 수행

6.3 인지적 항복 (Cognitive Surrender)

가장 위험한 리스크 — Loop를 지나치게 신뢰하기 시작하는 것입니다. "Accepting whatever the loop returns without judgment" (판단 없이 Loop가 반환하는 것은 무엇이든 수용함)

Loop가 연속으로 10번 성공하면, 당신은 읽지도 않고 승인(Approve)을 누르기 시작합니다. 그러다 11번째에 Loop가 엄청난 실수를 저지르게 됩니다.

해결책: 중요한 작업에는 인간 참여 (Human-in-the-loop) 유지, Loop의 작업 무작위 검사, Loop를 100% 신뢰하지 않기

7. 실제 Loop 사례

Shann Holmberg는 두 가지 수준의 Loop를 설명합니다 [6]:

Small Loop — 단일 작업 반복

에이전트 1개가 다음 과정을 수행합니다:

1. Research (리서치) — 정보 탐색
2. Draft (초안 작성) — 초안 작성
3. Self-review (자가 검토) — 자신의 작업 검토
4. Revise (수정) — 결과가 기준을 통과할 때까지 반복

Large Loop — 오케스트레이터 (Orchestrator) + 전문가 (Specialists)

오케스트레이터 1개가 다음을 수행합니다:

1. 큰 목표를 청크 (Chunks) 단위로 분할
2. 각 청크를 전문가 에이전트 (Specialist agent)에게 전달
3. 각 전문가는 자신만의 작은 Loop를 가질 수 있음
4. 오케스트레이터가 결과를 수집하고 일관성을 검증

8. Nokka의 관점 — 프로그래머는 어떻게 시작해야 하는가?

제 관점에서는 Loop Engineering은 모든 프로그래머가 지금 바로 배우기 시작해야 하는 기술입니다. 왜냐하면 이것이 향후 6~12개월 내에 표준 관행 (Standard practice)이 될 것이기 때문입니다.

시작하는 방법:

1. 가장 작은 루프(Loop)부터 시작하세요 — 처음부터 완벽한 루프를 설계하려고 하지 마세요. 테스트가 통과할 때까지 Agent에게 프롬프트를 반복해서 전달하는 간단한 while loop부터 시작하세요.
2. 검증기(Verifier)에 투자하세요 — 좋은 검증기(Verifier)는 유용한 루프와 위험한 루프를 가르는 차이점입니다. 테스트 스위트(test suite), 린터(linter), 타입 체커(type checker)를 검증기로 사용하세요.
3. 피해를 제한하세요 — 최대 재시도 횟수(max_retries)를 설정하고, 토큰 예산(budget tokens)을 정하며, 별도의 git branch를 사용하세요. 루프가 머지(merge)되기 전에 샌드박스(sandbox)에서 먼저 작동하도록 하세요.
4. 중요하지 않은 작업부터 시작하세요 — 처음부터 루프가 프로덕션 코드(production code)를 작성하게 하지 마세요. 중요하지 않은 작업의 리팩터링(refactor), 테스트 작성, 또는 문서화(documentation)부터 시작하세요.
5. 검토하는 습관을 만드세요 — 직접 확인하기 전까지는 루프를 믿지 마세요. 주기적으로 루프가 수행한 작업을 무작위로 검사하세요.

제 관점에서는, "나는 더 이상 Claude에게 프롬프트를 입력하지 않는다. 대신 실행되는 루프(loops)를 가지고 있다"라는 Boris Cherny의 말은 단순히 멋진 문구가 아닙니다. 그것은 향후 1~2년 내 AI 코딩의 방향성입니다. 오늘 Loop Engineering을 배우는 프로그래머가 내일의 노동 시장에서 우위를 점하게 될 것입니다.

참고 문헌

[1] Peter Steinberger (@0xCodez) — Loop engineering: the 14-step roadmap (2026년 6월 7일)
[2] Addy Osmani — Loop Engineering (O'Reilly Radar, 2026년 6월 22일)
[3] @0xCodez — 14-step roadmap from prompter to loop designer
[4] Boris Cherny — Claude Code & the Future of Engineering (Acquired Unplugged, 2026년 6월)
[5] Lushbinary — Loop Engineering: The Guide for AI Agents
[6] Shann Holmberg (@shannholmberg) — What is agent looping (2026년 6월 8일)
[7] Firecrawl — Loop Engineering: Should You Stop Prompting Agents and Start Designing Loops (2026년 6월 11일)
[8] AI Builder Club — Loop Engineering Guide (2026)

이 기사는 Hermes Agent를 통해 AI (DeepSeek V4 Flash)가 작성하였으며, 인간(Nokka)의 통제 및 품질 검토를 거쳤습니다.