개인용 아카이브(동료 엔지니어가 읽어도 따라올 수 있는 밀도). 숫자·주장은 1차 자료를 확인하여 정리하였으며, 확증이 부족한 것은 "말할 수 없음"으로 구분했다. 조사 시점: 2026-07.

이 기사의 목적

코딩 에이전트(Coding Agent)를 "좋은 프롬프트를 계속 입력하는 도구"로 사용하는 단계에서, "에이전트가 다음 업무를 찾고, 배분하고, 검증하게 만드는 메커니즘"을 설계하는 단계로 담론이 이동하고 있다. 그 중심에 있는 것이 **루프 엔지니어링 (Loop Engineering)**이라는 용어다.

이 기사는 명명자·실무자·관련 실험의 1차 소스에 가까운 자료로부터, 나중에 자신이 설계 판단을 내릴 때 필요한 지식만을 하나로 모은 것이다. 제품의 조작 순서나 특정 개인 리포지토리(Repository)에 적용하는 방법은 쓰지 않는다.

"필요한 정보량"의 정의

이 기사가 완결되었다는 것은, 태스크(Task) 내의 다른 노트를 열지 않고도 다음 6가지 질문에 답할 수 있는 상태를 말한다.

결론 (중심 명제)

레버리지(Leverage)는 "프롬프트 문장"에서 "루프 설계"로 이동한다. 단, 자기 채점, 정지 경계의 결여, 대화 내에만 머무는 상태, 인간의 최종 책임 포기를 제외하면 루프는 깨진다 (또는 깨졌다는 사실을 인지하지 못한다).

효과의 일반적인 생산성 퍼센트는 현시점의 독립 측정으로는 말할 수 없다. 말할 수 있는 것은 설계 원칙과 실패 클래스(Failure Class) 측면이다.

1. 정의와 출처 (Q1·Q2)

정의

Addy Osmani (2026)의 정의가 1차 핵심이다.

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

즉, 자신이 에이전트에게 프롬프트를 입력하는 역할을 그만두고, 에이전트가 프롬프트를 입력하게 만드는 시스템을 설계하는 것이다. 위치상으로는 단일 에이전트의 실행 환경(Harness)의 한 단계 위——타이머로 동작하고, 헬퍼(Helper)를 만들어내며, 자신에게 다음 업무를 먹이는 계층——로 여겨진다.

누구의 이야기인가

상정 독자는 IDE/CLI 상의 코딩 에이전트 (Claude Code, Codex 등)로 소프트웨어를 작성하는 엔지니어와, 그 오케스트레이션(Orchestration)을 설계하는 사람이다. 조사 메타 분석이나 개인 태스크 관리 이야기가 아니다.

출처의 요점

• Boris Cherny (Claude Code)는 Acquired Unplugged (2026-06-02)에서 IDE 수기 작성 → 복수의 Claude를 수동 프롬프트 → 자신은 프롬프트를 하지 않고 루프를 작성함, 이라는 3단계를 언급했다 (영상 자막으로 확인). "loop engineering"이라는 용어 자체는 Cherny의 조어가 아니라 제3자의 라벨이다.
• Peter Steinberger도 같은 취지로 "에이전트에게 프롬프트를 하지 마라, 에이전트가 프롬프트를 하는 루프를 설계하라"고 말하고 있다.
• Anthropic의 제품 블로그 (2026-06-30 Getting started with loops)는 "loop engineering"을 제목과 본문에서 사용하며, 루프를 "정지 조건까지 작업 사이클을 반복하는 것"으로 정의하고, Turn / Goal / Time / Proactive의 4가지 유형을 제시하고 있다. 반면 문서(Docs) 본체에 해당 고정 용어가 있는지는 조사 시점에서 말할 수 없다.

2. 기억해 두어야 할 원칙 (Q3)

제품명이나 커맨드(Command)는 바뀌어도 남기 쉬운 것을 먼저 배치한다. 확신도가 높은 것일수록 상세히 적는다.

2.1 쓰는 사람과 채점하는 사람을 분리한다 (Maker / Checker) — 가장 강력함

만든 주체가 자신의 성과를 채점하면 계통적으로 관대해진다. 명명자는 이를 루프의 가장 중요한 구조로 보며, 학술적으로도 자기 귀속 편향(Self-attribution bias)·자기 선호(Self-preference)로 측정되고 있다.

무인으로 돌리는 부분일수록, 별도의 에이전트 / 별도의 모델 / 기계적 테스트 등 Maker와 다른 검증자를 두는 것이 안전하다. 참고로 "Maker/Checker"는 Osmani 계열의 어휘이며, Anthropic 측은 evaluator model이나 second agent 등 다른 표현을 사용한다. 내용의 축은 비슷하다.

별도의 주의사항: Cursor 등이 제시하는 **Planner(계획)／Worker(실행)**는 "누가 분해하고 누가 구현할 것인가"의 분리이며, Maker/Checker(누가 만들고 누가 채점할 것인가)와는 직교(orthogonal)한다. 혼동하지 말 것.

2.2 멈출 수 없는 루프는 위험하다 (정지 경계)

에이전트의 feedback path가 model／tool／agent／workflow를 반복하는데, 강력한 정지 경계(stopping boundary)가 없으면 비용 고갈이나 부작용의 반복이 발생할 수 있다. 이는 Infinite Agentic Loop (IAL)로서, 대규모 리포지토리(repository) 해석에서 실패 클래스로 정식화되어 있다 (preprint). 설계 시에는 턴 제한(turn limit), 목표 조건(goal condition), 예산 캡(budget cap) 등을 처음부터 설정해야 한다.

2.3 상태는 대화 외부에 두어야 한다

모델은 run 간에 내용을 잊어버린다. 완료·다음 단계·결정 사항은 컨텍스트(context)가 아니라 repo·보드·파일 등 영구 저장소(persistent store)에 기록해야 한다. "에이전트는 잊지만, 리포지토리는 잊지 않는다."

2.4 인간은 사라지지 않는다

명명자(namer) 본인도 리뷰 없이 자동화에 모든 것을 맡기는 것은 품질의 하락 스파이럴(spiral)이 될 수 있다고 기술했다. 이해의 포기(cognitive surrender)는 설계의 실패 모드다. 루프는 일하는 방식을 바꿀 뿐, 당신을 삭제하지 않는다.

2.5 레버리지의 이동 (정의의 동기)

매 턴의 프롬프트(prompt) 최적화보다, 발견→배분→검증→다음 단계로 이어지는 메커니즘을 설계하는 것이 레버리지가 된다는 것이 주장의 핵심이다. 다만 Osmani는 직접적인 프롬프트 활용도 여전히 유효하다고 병기했다. 이 둘은 이지선다(either-or)가 아니다.

2.6 병렬 처리는 격리가 필요하지만, 리뷰 대역폭이 제약이 된다

여러 에이전트는 동일한 파일을 동시에 건드린다. worktree 등의 격리는 기계적 충돌을 줄여준다. 반면, 인간이 리뷰할 수 있는 양을 초과하는 병렬 처리는 품질 리스크가 된다. 이는 명명자의 설계상의 경고이며, 독립적으로 측정된 "물리 법칙"은 아니다.

2.7 활동량이 진척을 보장하지 않는다

커밋(commit) 수·충돌(conflict) 수·PR 수의 폭발은 수렴하지 않는 루프의 증상일 수 있다. Cursor의 구형 harness 실험이나, 저자가 보고한 "수정 루프가 멈추지 않는" 사례가 이 유형을 보여준다. 수치 그 자체를 일반화하지는 않는다.

2.8 계획／실행의 분리와 모델 경제 (사례 및 증거는 희박함)

장시간 멀티 에이전트(multi-agent) 환경에서는 계획 역할이 구현 상세 내용으로 컨텍스트(context)를 채우지 않고, 실행 역할이 좁은 조각(piece)에 집중하는 분리가 유효하다고 보고되었다 (Cursor 자체 실험). 또한, 실행 벌크(bulk)의 토큰이 많더라도 판단 측의 단가가 높다면 총비용의 대부분이 그쪽으로 쏠리게 되며, 동일한 품질이라도 모델 구성에 따라 총액이 자릿수 단위로 달라지는 사례가 있다. 유망한 방향이지만 단일 이해관계 소스에 의존하고 있으므로, 원칙의 보조 자료로 읽어야 한다.

3. 실패 모드 (Q4)

헤드라인에 등장하는 고액 사고 수치는 전파 과정에서 합성되거나 자기 신고된 데이터가 섞여 있을 수 있다. 설계의 교훈(정지·예산·탐지)에는 사용할 수 있지만, "검증된 단일 인시던트(incident)"로 취급하지는 않는다.

4. 말할 수 없는 것 (Q5)

• "도입하면 생산성이 X% 향상된다" —— 독립적인 효과 측정은 조사 범위 내에서 발견되지 않았다.
• 특정 고액 사고를 검증된 단일 실측치로 단정하는 것.
• Anthropic이 docs 기준 용어를 "공식 채택"했다는 것 (제품 블로그에서의 언급과는 별개).
• inner／outer loop의 단일 표준 정의 (논자에 따라 레이어가 다름).
• Cursor의 벤치마크 수치를 업계 전반으로 일반화하는 것.
• "loop engineering"이 Cherny의 조어라는 점 (오히려 부정됨).

5. 우선순위 (Q6)

출처의 확실성만을 기준으로 한 우선순위:

1. Maker／Checker (또는 그에 준하는 검증 분리)
2. 정지 경계 (턴·목표·예산)
3. 외부 상태 및 인간의 최종 책임 (리뷰／이해의 위치)
4. 레버리지를 루프 설계로 옮길 것인가에 대한 판단 (직접 프롬프트와의 균형 포함)
5. 병렬 시의 격리 및 "활동≠진척" 모니터링
6. 계획／실행의 분리 및 모델 경제는 규모가 커진 이후에

제품의 /loop나 Automations 같은 구체적인 기능은 위 원칙의 구현 수단으로서 후순위에 둔다. 수단부터 접근하면 정지와 검증을 잊기 쉽다.

주요 출처

주요 출처

• Addy Osmani, Loop Engineering
• Boris Cherny, Acquired Unplugged (WorkOS), 2026-06-02 — YouTube
• Anthropic / Claude Code, Loop engineering: Getting started with loops (2026-06-30)
• Cursor, Agent swarms and the new model economics
• Hou et al., When Agents Do Not Stop (arXiv:2607.01641) — Infinite Agentic Loops
• Self-attribution / self-preference 系: arXiv:2603.04582, arXiv:2404.13076

이 기사만으로 답할 수 있는 것 (완결 체크)

토론 (Discussion)