Loop Engineering: 에이전트를 직접 프롬프트하지 않고, 프롬프트하는 시스템을 설계하는 법

한눈에 보기

Loop Engineering은 사람이 에이전트에게 매번 프롬프트를 넣는 방식에서 벗어나, 에이전트에게 프롬프트를 넣고 반복 실행하게 만드는 시스템 자체를 설계하는 방식으로 정의된다. 논문은 이를 prompt, context, harness engineering 위에 놓이는 네 번째 층으로 설명한다. ^p.1-2

• 핵심 전환: 사람은 더 이상 루프 안에서 매번 지시하는 조작자가 아니라, 루프 밖에서 엔진을 설계하는 사람이 된다. ^p.1
• 핵심 구조: 한 턴은 discovery, handoff, verification, persistence, scheduling의 다섯 움직임으로 구성된다. ^p.3
• 핵심 안전장치: 코드를 쓰는 generator와 검증하는 evaluator를 분리해야 한다. 같은 에이전트가 자기 결과물을 평가하면 스스로를 과하게 긍정하는 경향이 있다고 설명한다. ^p.4
• 핵심 리스크: 검증 부채, 이해력 부식, 인지적 항복, 토큰 비용 폭증이 조용히 누적된다. ^p.7

1. 왜 ‘Loop’인가

논문은 기존의 prompt engineering이 “모델에게 무엇을 말할 것인가”에 집중했다면, loop engineering은 그 말을 반복적으로 생성·전달·검증·저장·재실행하는 체계를 만드는 데 초점을 둔다고 설명한다. ^p.1-2

저자는 이 용어가 2026년 6월 한 주 사이에 여러 실무자에게 거의 동시에 부상했다고 정리한다. Peter Steinberger는 더 이상 coding agent를 직접 prompting하지 말고, agent를 prompting하는 loop를 설계해야 한다는 취지의 글을 올렸고, Boris Cherny도 Claude를 직접 prompt하기보다 Claude를 prompt하는 loop를 작성한다고 말했다고 소개된다. Addy Osmani는 6월 7일 이를 Loop Engineering이라는 제목으로 블로그에 정리했다고 논문은 설명한다. ^p.1

이 등장의 배경으로 논문은 coding agent가 무인 상태에서 비단순 작업을 끝낼 만큼 안정화되었고, 주요 harness에 scheduling primitive가 생겼으며, 반복 실행 비용이 충분히 낮아졌다는 점을 든다. ^p.1

2. 네 개 층: prompt → context → harness → loop

논문에서 중요한 통찰은 층이 올라갈수록 실패의 반경도 커진다는 점이다. 잘못된 prompt는 한 번의 답변에서 드러나지만, loop 단계의 오류는 state file에 기록되고 다음 날 다시 읽히며 여러 턴에 걸쳐 “확립된 사실”처럼 쌓일 수 있다. ^p.2

3. 한 번의 루프는 다섯 움직임으로 돈다

논문은 Addy Osmani의 morning triage loop를 예로 든다. 이 루프는 매일 아침 자동으로 실행되어 전날의 실패한 CI, 열린 issue, 최근 commit을 읽고, 처리할 만한 finding을 markdown file이나 Linear board에 기록하며, 각 finding에 대해 worktree를 열고 sub-agent가 fix를 작성한 뒤 다른 sub-agent가 검토한다고 설명한다. ^p.3

4. 루프를 만드는 여섯 부품

• Automations: schedule 또는 trigger에 의해 loop를 움직인다. scheduling이 없으면 반복 루프가 아니라 단발 실행에 가깝다. ^p.3-4
• Worktrees: 여러 agent가 같은 repo에서 서로 충돌하지 않도록 독립 작업 디렉터리를 제공한다. ^p.3-4
• Skills: project knowledge를 SKILL.md 같은 유지 가능한 파일로 보존해 매번 intent를 다시 설명하는 비용을 줄인다. ^p.3-4
• Connectors: MCP 기반으로 issue tracker, database, staging API, Slack 등 외부 시스템과 연결한다. ^p.4
• Sub-agents: 작성자와 검토자를 분리해 generator/evaluator 구조를 만든다. ^p.4
• Memory: context window가 아니라 disk, board, markdown file처럼 다음 턴에도 살아남는 곳에 상태를 저장한다. ^p.4

5. 가장 중요한 설계: generator와 evaluator 분리

논문에서 가장 강조되는 안전장치는 작성하는 agent와 판단하는 agent를 분리하는 것이다. Anthropic engineer Prithvi Rajasekaran의 관찰로 소개되는 내용에 따르면, agent가 자신이 만든 결과물을 직접 평가하게 하면 사람 눈에는 부족한 결과도 자신 있게 칭찬하는 경향이 있다고 설명된다. ^p.4

저자는 이를 “자기 숙제 채점” 문제로 해석한다. generator의 context에는 이미 해당 구현을 선택한 이유와 자기 설득 과정이 들어 있으므로, 같은 agent가 결과를 보면 실제 결과보다 그 결정 과정을 함께 보게 된다는 설명이다. ^p.4

• evaluator는 회의적이어야 한다: 기본 자세는 trust가 아니라 doubt여야 한다. ^p.4
• evaluator는 읽기만 하면 안 된다: frontend 작업에서는 Playwright MCP로 페이지를 열고, 버튼을 누르고, screenshot과 DOM을 확인하는 식으로 행동 기반 검증을 해야 한다고 설명한다. ^p.4
• 최종 stop condition도 별도 판단이 필요하다: Claude Code의 /goal 예시에서는 작은 빠른 모델이 조건 충족 여부를 확인하고, 충족되지 않으면 다음 turn을 계속 실행한다고 설명한다. ^p.4-5

6. 루프가 망가지는 다섯 방식

논문은 성급한 loop가 눈에 보이는 output을 만드는 discovery와 handoff만 설치하고, safety를 만드는 verification, persistence, scheduling을 소홀히 하기 쉽다고 경고한다. ^p.5

7. 실제 사례: 개인 triage부터 Stripe Minions까지

논문은 loop가 실제로 작동하는 사례로 세 가지 규모를 언급한다. 공통 skeleton은 trigger가 시작을 누르고, constraints가 레일을 만들고, 끝에는 human checkpoint가 놓이는 구조라고 설명한다. ^p.5

• 개인 morning triage: Osmani의 loop는 매일 아침 자동으로 실행되고, schedule에 거대한 prompt를 붙이는 대신 skill을 호출한다. ^p.5-6
• Stripe Minions: Stripe engineer Steve Kaliski가 How I AI podcast에서 설명한 사례로, 주당 1,300개 이상의 machine-written pull request가 merge된다고 소개된다. 단, 이 PR들은 여전히 human review를 거친다고 논문은 명시한다. ^p.6
• scheduler 선택: local /loop와 desktop scheduled task는 machine이 켜져 있어야 하고, machine off 상태에서도 돌려면 Cloud Routines나 GitHub Actions schedule trigger가 필요하다고 비교한다. ^p.6

Stripe Minions 사례에서 특히 중요한 점은 더 강한 모델이 아니라 deterministic gate와 constraint의 품질이 신뢰성을 만든다는 주장이다. 논문은 context assembly, linter, commit 같은 규칙 기반 단계는 probabilistic model 바깥에 두고, LLM은 code 작성과 lint fix 같은 구간에 배치하는 구조를 설명한다. ^p.6

8. 네 가지 비용: 조용히 쌓이는 부채

논문은 이 네 비용이 독립적인 목록이 아니라 서로 강화되는 하나의 실패라고 설명한다. 검증되지 않은 output이 늘면 이해가 뒤처지고, 이해가 뒤처지면 판단을 포기하기 쉬워지며, 판단을 포기하면 loop가 더 오래 무감시로 돌고 비용과 오류가 함께 커질 수 있다는 구조다. ^p.7

9. 핵심 메시지: 생성은 싸지고, 판단은 더 비싸진다

논문은 loop가 code, plan, fix, pull request의 생성 비용을 크게 낮춘다고 설명한다. 그러나 무엇을 유지하고 무엇을 멈출지 결정하는 judgment는 여전히 희소한 자원으로 남는다고 주장한다. ^p.7-8

이 점에서 loop는 engineer를 대체한다기보다, engineer가 가진 판단력을 증폭하는 도구로 그려진다. 이해와 방향감각을 가진 사람에게는 판단을 확장해 주지만, 이해를 포기한 사람에게는 그 포기 역시 증폭한다고 논문은 설명한다. ^p.7-8

따라서 저자의 결론은 “loop를 만들되, 계속 engineer로 남을 사람처럼 만들라”는 쪽에 가깝다. evaluator, state file, budget cap, human review point는 모두 빠르게 “yes”라고 말하는 기계에 대해 사람이 “no”라고 말할 수 있는 능력을 유지하기 위한 장치로 설명된다. ^{p.8, p.10-11}

10. 첫 루프를 만들 때의 체크리스트

• Discovery source: timer로 무엇을 읽을지 정한다. 예: CI, issues, commits, inbox. ^p.9
• State file: cross-round memory를 담을 disk file을 둔다. ^p.9
• Evaluator: “no”라고 말할 독립 검증자를 둔다. ^p.9
• Isolation: parallel agent마다 독립 worktree를 준다. ^p.9
• Token cap: spending ceiling과 runaway stop 조건을 둔다. ^p.9
• Human review: 전부 자동 처리하지 말고 사람이 보는 pause 지점을 둔다. ^p.9

논문은 첫 loop가 작아도 괜찮지만, “no”라고 말하는 check와 human review point는 처음부터 완전하게 설치되어야 한다고 강조한다. ^p.9

투자·비즈니스 관점의 해석

이 글은 특정 기업이나 도구에 대한 매수·매도 판단을 제공하지 않는다. 다만 기술 흐름 관점에서는 agent 자체의 성능만큼이나 agent를 감싸는 orchestration, scheduling, verification, connector, sandbox, state management 역량이 중요해질 가능성을 시사한다. 이는 논문이 loop engineering을 단일 모델 기능이 아니라 여러 부품이 결합된 system design 문제로 설명하기 때문이다. ^p.3-7

• 확인 포인트: agent 제품이 단순 자동 반복을 넘어서 독립 evaluator, hard-coded gate, budget cap, human checkpoint를 제공하는지 확인할 필요가 있다. ^p.4-9
• 리스크: 자동 생성량 증가는 생산성처럼 보일 수 있지만, 검증 부채와 이해력 부식이 누적되면 운영 리스크로 돌아올 수 있다. ^p.7
• 추정: 앞으로의 경쟁력은 “더 큰 모델”만이 아니라, deterministic gate와 LLM step을 어디에 배치하느냐에서 갈릴 가능성이 있다. 이 해석은 Stripe Minions 사례에서 reliability가 model size보다 constraints 품질에서 나온다는 논문 설명에 근거한 추정이다. ^p.6

마지막 요약

Loop Engineering의 본질은 ‘agent에게 잘 말하기’가 아니라 ‘agent에게 계속 말하고, 시키고, 검증하고, 기억하고, 멈출 수 있는 시스템을 설계하기’다. 논문이 반복해서 강조하는 위험은 loop가 사람을 해방하는 동시에 사람의 판단 포기까지 증폭할 수 있다는 점이다. 따라서 좋은 loop의 기준은 얼마나 많이 생성하느냐가 아니라, 얼마나 잘 멈추고, 얼마나 정확히 검증하며, 사람이 언제든 다시 개입할 수 있게 설계되었느냐다. ^p.8-11