[AI] Loop Engineering — "나는 더 이상 Claude에게 프롬프트를 치지 않는다"

Prompt Engineering이 중요하다고 배운 지 얼마 되지 않은 것 같은데, 벌써 한 단계 위의 이야기가 나오고 있다.

BORIS CHERNY, 2026

“나는 더 이상 Claude에게 프롬프트를 치지 않는다.
Claude에게 프롬프트를 치는 루프를 만든다.”

Claude Code를 만든 Boris Cherny가 2026년 6월 공개 석상에서 설명한 자신의 업무 방식이다. 실제 표현은 조금 더 강하다. 이제 자신의 일은 Claude에게 직접 지시하는 것이 아니라 Claude를 반복적으로 움직이는 Loop를 설계하는 것이라는 이야기다.

Addy Osmani는 6월 7일 이 패턴을 Loop Engineering이라는 이름으로 정리했다.

처음 들으면 거창하지만 본질은 꽤 단순하다.

Human → Prompt → Agent

↓

Human → Loop → Agent → Feedback ↺

TL;DR

Prompt Engineering이 “Agent에게 무엇을 말할까?”라면,
Loop Engineering은 “Agent가 스스로 계속 일하게 만드는 시스템을 어떻게 설계할까?”다.

01. 먼저 짚고 갈 것: “Loop Engineering”은 Boris가 만든 용어는 아니다

Boris Cherny가 직접 사용한 표현은 “I write loops”에 가깝다.

이후 Peter Steinberger가 “Coding Agent를 직접 prompting하지 말고 Agent를 prompting하는 loop를 설계하라”는 식으로 표현했고, Addy Osmani가 이를 Loop Engineering이라는 형태로 정리했다.

왜 이 구분이 중요할까?

Loop Engineering은 아직 소프트웨어 공학의 오래된 정식 분과라기보다, 2026년 Coding Agent 실무에서 빠르게 정리되고 있는 새로운 engineering pattern에 가깝다.

즉 이름 자체보다 그 뒤에 있는 구조를 보는 게 중요하다.

02. Prompt Engineering과 뭐가 다른가?

구분	Prompt Engineering	Loop Engineering
기본 단위	한 번의 요청 / turn	목표를 완료할 때까지의 실행 cycle
주도권	사람이 다음 prompt 입력	시스템이 다음 run을 결정
Feedback	사람이 결과를 보고 수정	Test / evaluator / event가 자동 피드백
종료	응답이 오면 일단 종료	명시된 stopping condition 충족 시 종료
시간축	초~분	분~시간, 혹은 반복 schedule
핵심 역량	Instruction design	Control / Verification / State design

흔히 “Loop Engineering이면 생산성이 10배, 100배” 같은 이야기도 나오지만, 그런 배수는 일반화하기 어렵다.

실제 레버리지는 업무가 얼마나 병렬화 가능한지, 검증이 자동화 가능한지, 사람 review가 얼마나 필요한지에 따라 크게 달라진다.

핵심 변화는 생산성 숫자가 아니라 사람이 작업의 내부 loop에서 바깥으로 이동한다는 것이다.

03. 사실 Loop Engineering은 AI판 Feedback Control System에 가깝다

Software Agent라는 말을 잠시 빼고 보면 구조는 꽤 익숙하다.

Goal

↓

Agent / Controller

↓

Action

↓

Environment

↓

Verifier / Feedback

↺

feedback가 다음 Agent input을 바꾼다

여기서 중요한 건 loop가 있다는 사실이 아니다.

나쁜 loop도 얼마든지 만들 수 있다.

BAD LOOP

Agent 실행
↓
“아직 안 된 것 같아. 다시 해.”
↓
Agent 실행
↓
“다시.”
↓
Token bill 💸

좋은 loop에는 관측 가능한 목표와 신뢰할 수 있는 feedback이 있어야 한다.

04. 실무적으로는 5개가 아니라 8개를 생각하면 편하다

원문의 Trigger · Goal · Actions · Verification · Memory는 좋은 출발점이다. Production에서는 여기에 세 가지를 더 붙이는 편이 안전하다.

01 · TRIGGER

언제 시작할 것인가?

Cron · Event · Queue · Human command · CI failure

02 · GOAL

무엇이 완료 상태인가?

“리포트 작성”보다 “필수 5개 지표가 포함된 초안 생성”

03 · ACTIONS

무엇을 할 수 있는가?

Search · Code · DB read · API · MCP · Sub-agent

04 · VERIFICATION

정말 끝났는가?

Test · Schema · LLM Judge · Human approval · Business rule

05 · MEMORY / STATE

다음 iteration이 무엇을 기억해야 하나?

Progress file · DB · Git · ticket · checkpoint

06 · STOPPING CONDITION

언제 강제로 멈출 것인가?

Max turns · deadline · no-progress threshold · terminal failure

07 · BUDGET

얼마까지 쓸 수 있는가?

Token · API cost · tool calls · compute · concurrency

08 · ESCALATION

사람에게 언제 넘길 것인가?

Low confidence · irreversible action · repeated failure · policy exception

이 8가지를 정의하면 “Agent 한번 돌려보기”가 아니라 꽤 명확한 운영 가능한 workflow specification이 된다.

05. Loop Engineering의 진짜 핵심은 Prompt가 아니라 Verifier다

Loop는 목표를 반복하는 구조다. 그런데 목표를 달성했는지 판정할 수 없다면 Loop는 끝날 수 없다.

THE CORE RULE

Goal과 Verification은 한 쌍이다.

Coding은 이 점에서 Loop Engineering에 유리하다.

Goal: 로그인 race condition 수정
Verification:
├── targeted test PASS
├── full test PASS
├── typecheck PASS
└── security reviewer PASS

반면 “좋은 마케팅 전략을 만들어라” 같은 목표는 종료 조건이 애매하다.

이런 업무를 Loop로 만들려면 추상적인 품질을 검증 가능한 rubric이나 human checkpoint로 바꿔야 한다.

검증 대상	추천 Verifier
JSON / 필수 필드 / 숫자 범위	Deterministic code
코드 동작	Tests / typecheck / lint
답변 groundedness	LLM Judge + citation check
금융 업무의 중요 결정	Business rule + Human approval

06. 만든 Agent와 검사하는 Agent를 분리하는 이유

Addy Osmani가 특히 강조하는 primitive 중 하나가 Sub-agent다.

이유는 간단하다. 자기 결과물을 자기 자신이 평가하면 너무 쉽게 “완료”라고 판단할 수 있다.

Maker Agent
Generate / Fix / Act
↓
Verifier Agent
Independent review
↓
PASS → Finish
FAIL → Evidence → Maker ↺

물론 verifier도 LLM이라면 완벽한 증명은 아니다.

그래서 가장 좋은 구조는 deterministic checker를 우선 사용하고, 애매한 semantic quality에만 LLM evaluator를 붙이는 것이다.

07. Addy Osmani가 정리한 “다섯 조각 + Memory”

Addy의 최신 정리는 조금 다른 관점에서 Loop를 설명한다. 실제 Coding Agent 제품에 들어 있는 primitive 기준이다.

1. Automations

일정/이벤트에 따라 discovery와 triage를 자동 실행

2. Worktrees

여러 Agent의 병렬 작업을 filesystem 수준에서 격리

3. Skills

프로젝트 지식과 작업 규칙을 재사용 가능한 형태로 외부화

4. Plugins / Connectors

MCP 등을 통해 issue tracker, DB, Slack, API와 연결

5. Sub-agents

탐색 / 구현 / 검증 역할 분리

+ State / Memory

Conversation 밖에 진행상태를 남겨 다음 run이 이어받게 한다.

Addy의 표현이 인상적이다.

Agent는 잊어도, Repository는 잊지 않는다.

장시간 Loop에서 state를 conversation 안에만 들고 있으면 context compaction이나 session 종료 때 연속성이 깨진다. 그래서 progress file, issue tracker, Git, DB 같은 외부 state가 loop의 spine이 된다.

08. Harness Engineering과는 어떤 관계일까?

앞 글에서 Harness Engineering을 다뤘다면 여기서 연결이 된다.

그런데 한 가지는 바로잡아야 한다. Loop를 단순히 Harness의 “하위 기능”이라고 보면 약간 어긋난다.

HARNESS ENGINEERING

한 Agent가 일하는 환경

Tools · Context · Sandbox · Hooks · Permission · State

↑ controlled by

LOOP ENGINEERING

그 Harness를 언제, 왜, 얼마나 반복할지

Schedule · Goal · Feedback · Verification · Escalation

Addy 표현대로라면 Loop는 Harness보다 한 층 위에 있다.

Harness가 Agent에게 “좋은 작업환경”을 준다면, Loop는 그 Agent를 하나의 지속적으로 돌아가는 업무 시스템으로 바꾼다.

09. Open Loop와 Closed Loop를 구분하면 사고가 쉬워진다

OPEN LOOP

실행하고 끝

“매일 아침 뉴스 10개를 찾아 요약해.”

결과가 좋은지는 다음 iteration에 영향을 주지 않는다.

CLOSED LOOP

검사하고 보정

뉴스 수집 → 중복검사 → 신뢰도 평가 → 부족한 카테고리 재검색 → 초안 생성 → 리뷰

결과가 다음 행동을 바꾼다.

Agentic AI가 재미있어지는 지점은 대부분 Closed Loop 쪽이다.

하지만 자율성도 같이 올라가기 때문에, feedback과 stop condition이 부실하면 문제도 자동화된다.

10. 코드로 보면 의외로 별것 없어 보인다

python · conceptual loop

state = load_state()

for attempt in range(MAX_ATTEMPTS):
    result = agent.run(
        goal=GOAL,
        state=state,
        tools=TOOLS,
    )

    verdict = verifier.check(
        goal=GOAL,
        result=result,
        state=state,
    )

    save_trace(result, verdict)

    if verdict.passed:
        save_state(state)
        break

    state = update_state(
        state,
        evidence=verdict.evidence,
    )

else:
    escalate_to_human(
        reason="retry_budget_exhausted",
        state=state,
    )

핵심 로직은 어렵지 않다.

어려운 것은 GOAL, verifier, state, retry policy, escalation을 무엇으로 정의하느냐다.

결국 Loop Engineering도 code volume보다 control semantics가 중요한 분야다.

11. “다시 해”는 Retry Policy가 아니다

Agent가 실패했을 때 같은 prompt를 무한 반복하는 건 좋은 loop가 아니다.

Failure Type	다음 행동
Transient API error	Backoff 후 동일 action retry
Tool result 부족	다른 search/query strategy
Verifier fail	구체적인 evidence를 context에 주입
동일 실패 반복	No-progress 감지 후 human escalation
Policy violation	즉시 중단, retry 금지

즉 Retry도 모델에게 전부 맡기기보다 failure class별로 deterministic policy를 두는 편이 좋다.

12. Loop가 실제 시스템을 건드리기 시작하면 Idempotency가 중요해진다

매 iteration이 단순히 검색만 한다면 retry가 크게 위험하지 않다.

하지만 Loop가 실제 side effect를 만들면 이야기가 달라진다.

Send email
Create ticket
Update database
Submit payment
Deploy service

Verifier timeout 때문에 Agent가 “실패했다”고 착각하고 같은 action을 다시 실행할 수 있기 때문이다.

LOOP SAFETY

✓ Idempotency key
✓ Action receipt / transaction ID
✓ Already-done check
✓ Compensating action / rollback
✓ External side effect 전 human approval

이 지점부터 Loop Engineering은 꽤 전통적인 distributed systems / workflow engineering과 만난다.

13. 가장 과소평가되는 종료 조건: 돈

Addy Osmani도 Loop Engineering을 소개하면서 아직 초기 단계이며 token cost에 주의해야 한다고 명시적으로 경고한다.

Loop는 반복될수록 비용이 선형으로 늘지 않을 수도 있다. context가 커지고, verifier와 sub-agent가 추가되고, search와 tool call도 누적되기 때문이다.

Cost / Loop
= Agent calls
+ Verifier calls
+ Sub-agents
+ Search / MCP
+ External APIs
+ Retry
+ Compute / Sandbox

따라서 timeout만큼 cost ceiling도 stopping condition으로 넣어야 한다.

가장 좋은 측정 단위도 “LLM call당 비용”보다는 성공한 업무 하나당 비용(Cost per Successful Task)에 가깝다.

14. 인간은 Loop 밖으로 나갈 뿐, 사라지는 건 아니다

Loop Engineering을 잘못 읽으면 “사람이 이제 볼 필요가 없다”는 이야기처럼 들릴 수 있다.

Addy의 결론은 오히려 반대다.

반복 실행의 Inner Loop는 최대한 자동화하되, 목표와 품질 기준을 정하고 정말 이 방향이 맞는지 판단하는 Outer Loop는 사람이 가져가야 한다.

INNER LOOP · AGENT

Investigate → Act → Verify → Repeat

OUTER LOOP · HUMAN

Goal → Quality → Risk → Verdict

Agent가 빨라질수록 오히려 새로운 부채도 생긴다.

Comprehension Debt

시스템은 빨리 변하는데 사람은 더 이상 내부를 이해하지 못함

Cognitive Surrender

Loop가 주는 결과를 판단 없이 그대로 받아들이기 시작함

Loop는 사고를 없애는 기술이 아니라 사람이 사고해야 하는 위치를 바꾸는 기술에 더 가깝다.

15. 예를 들어 이 블로그 뉴스레터 루틴을 Loop로 만든다면

“매일 AI 뉴스를 찾아서 글을 써줘”라고 한 번 호출하는 것과 운영 가능한 Loop를 만드는 건 다르다.

DAILY AI NEWSLETTER LOOP

07:00 Trigger

↓

Discover
papers · vendor releases · security · finance AI

↓

Deduplicate + Rank
이전 발행 주제 · novelty · practical relevance

↓

Research + Draft
official sources first · finance implications · references

↓

Verifier
freshness · factual consistency · duplicate topic · broken citations

↓

Human Approval
최종 톤 · 주장 · 발행 여부

↓

Save topic / sources / feedback → Tomorrow's Memory

이 구조가 되면 다음 날 Loop는 처음부터 시작하지 않는다. 이전에 무엇을 썼는지, 어떤 주제를 피해야 하는지, 어떤 형식의 글이 좋았는지를 state로 이어받는다.

여기서 발행처럼 외부에 영향을 주는 action은 처음에는 human approval 뒤에 두는 게 자연스럽다.

16. 금융권에서는 어떤 Loop부터 시작하면 좋을까?

금융권에서 첫 Loop를 고른다면 반복적이고, 검증 가능하고, 실패 시 되돌릴 수 있는 업무가 좋다.

Loop	Trigger	Verifier	Action Level
모델 Drift Review	Weekly	Threshold + human review	Report only
RAG Quality Regression	Index / prompt change	Golden set + judge	Deploy gate
규정 변경 Watch	Daily	Source freshness / diff	Notify only
운영 이상 리포트	Metric anomaly	Query evidence + analyst	Recommendation

반대로 고객의 금전적 권리나 계약 상태를 직접 변경하는 업무는 초기 Loop로 잡기 좋지 않다.

금융권에서 Loop의 기본값은 “스스로 조사하고 검증하되, 중요한 action은 사람이 승인한다” 정도가 현실적이다.

17. 금융권 Loop는 이렇게 생기는 게 안전하다

CONTROLLED AGENT LOOP

Scheduler / Event Trigger

↓

Identity
Service / Agent ID

Budget
Cost / Turn Limit

Policy
Allowed Actions

↓

Agent Loop Runtime
Observe → Plan → Act → Persist

↓

Independent Verification

↓

PASS → Finish / Save State

FAIL → Retry / Escalate

↓

Trace · Audit · Cost · Outcome

이렇게 보면 Loop 자체보다 Loop 밖의 control layer가 오히려 더 많이 보인다.

Production Loop Engineering이 결국 Harness, Observability, IAM, Workflow Engine과 만나는 이유다.

18. Loop가 실패하는 대표적인 방식

① No Stopping Condition

Agent가 “더 좋아질 수 있다”며 계속 반복한다.

② Self-grading

만든 Agent가 스스로 너무 쉽게 PASS를 준다.

③ Context Rot

iteration이 길어지며 오래된 정보와 불필요한 로그가 쌓인다.

④ Duplicate Side Effect

retry 때문에 같은 메일/티켓/DB update가 두 번 실행된다.

⑤ Review Bottleneck

Agent는 20개가 병렬인데 승인자는 한 명이다.

⑥ Cost Runaway

Sub-agent × verifier × retry가 곱해지면서 비용이 폭발한다.

19. 첫 Loop를 만든다면 나는 이 순서로 한다

1

사람이 매주 반복하는 업무 하나를 고른다

처음부터 “회사 전체를 자동화”하지 않는다.

2

Done을 먼저 정의한다

Prompt보다 verifier부터 설계한다.

3

처음에는 Read-only Action만 준다

Search / Analyze / Draft부터.

4

Retry / Stop / Budget을 명시한다

“알아서 끝날 때까지”는 specification이 아니다.

5

Production Trace를 남긴다

어디서 반복하고 왜 실패했는지 관측 가능하게.

6

신뢰가 쌓일 때만 Action 권한을 확대한다

Autonomy는 feature가 아니라 permission이다.

20. 결국 엔지니어의 역할이 한 단계 위로 올라간다

Coding의 abstraction은 계속 올라왔다.

Write code
↓
Prompt Agent
↓
Design Context / Harness
↓
Design Loops

하지만 abstraction이 올라간다고 engineering이 사라지는 것은 아니다.

오히려 우리가 직접 쓰던 code 대신 goal, verifier, state, permissions, budget, escalation을 설계하게 된다.

MY TAKE

Prompt Engineering은 모델의 한 번의 행동을 최적화한다.
Loop Engineering은 모델의 반복되는 행동 전체를 엔지니어링한다.

그래서 좋은 Loop의 가장 중요한 질문은 “Prompt가 얼마나 영리한가?”가 아니다.

“이 시스템은 무엇을 보고 스스로 멈출 수 있는가?”

Loop가 길어질수록 이 질문이 더 중요해진다.

그리고 금융권처럼 실수의 비용이 큰 환경에서는 여기에 하나를 더 붙여야 한다.

“멈추지 못했을 때, 누가 강제로 멈출 수 있는가?”

---

References

01. Addy Osmani — Loop Engineering

02. Loop Engineering — Boris Cherny's Claude Code Methodology (fact-checked field guide)

03. Loop Engineering — What “The Loop” Is

04. OpenAI Codex — Use Cases / Automation & Durable Goals

05. Anthropic — Claude Code CLI / Programmatic Agent Runs

06. Anthropic — LLM Gateway / Usage & Budget Controls

written by rubrub · AI / LLM / Agent Engineering