[AI] 루프 엔지니어링: 에이전트를 프롬프트하지 않고 굴리는 법

루프 엔지니어링

에이전트를 붙여놨는데도 하루 종일 터미널 앞에 앉아 있다. 프롬프트를 던지고, 결과를 보고, 다시 프롬프트를 던진다. 코드는 에이전트가 쓰는데 정작 내 시간은 줄지 않았다. 이쯤에서 나오는 처방은 대개 둘 중 하나다. 프롬프트를 더 잘 쓰자. CLAUDE.md를 더 채우자. 그런데 문제는 프롬프트가 아니다. 프롬프트를 매번 사람이 넣고 있다는 것이 문제다.

2026년 6월, Peter Steinberger가 이런 말을 던졌다.

이제 코딩 에이전트에 프롬프트를 넣지 마라. 에이전트에게 프롬프트를 넣는 루프를 설계해라.
You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

이 문장이 퍼지면서 루프 엔지니어링(loop engineering)이라는 이름이 붙었다. Google의 Addy Osmani가 곧바로 에세이로 뼈대를 세웠고, 두 달 만에 AI Engineer World's Fair 2026에서 에이전트 개발의 제어 계층으로 다뤄질 만큼 자리를 잡았다.

1. 프롬프트에서 루프까지

컨텍스트 엔지니어링은 모델에게 무엇을 얼마나 보여줄지를 설계하는 일이고, 하네스는 그 모델에 도구·메모리·권한·샌드박스를 붙여 실제로 일하게 만드는 껍데기다. 새 계층이 나왔다고 앞의 것이 폐기되는 게 아니다. 각 계층은 이전 것을 대체하지 않고 감싼다. 루프 안에 하네스가 있고, 하네스 안에 컨텍스트가 있고, 컨텍스트 안에 프롬프트가 있다. 다만 그걸 누가 넣느냐가 바뀌었을 뿐이다. 작업의 단위가 한 번의 요청에서 하나의 사이클로 옮겨간 것. 이게 루프 엔지니어링의 전부다.

계층	시기	다루는 단위	대표 질문
프롬프트 엔지니어링	2022–2024	한 번의 요청	어떻게 물어볼까
컨텍스트 엔지니어링	2025	추론 시점에 모델이 보는 전부	무엇을 넣어줄까
하네스 엔지니어링	2026 상반기	에이전트를 둘러싼 환경	무엇을 쥐여줄까
루프 엔지니어링	2026 2분기	반복 사이클 자체	누가 다음 턴을 시작할까

2. 이너 루프와 아우터 루프

Osmani가 구조를 한 문장으로 요약한 게 인상적이었다.

모델이 그 줄을 쓸 수는 있다. 하지만 판정(Verdict)은 내 몫이다.

여기서 판정이란 이걸 프로덕션에 넣을 것인가에 대한 최종 결정이다. 자동화의 목표는 이 판정을 없애는 게 아니라, 판정에 필요한 증거를 자동으로 모아오는 것이다. 에이전트가 테스트를 돌리고 린트를 통과시키고 리뷰 코멘트에 대응하는 것은 이너 루프. 그 결과를 보고 말하는 것은 아우터 루프이다.

	이너 루프	아우터 루프
주체	에이전트	사람
하는 일	조사 → 구현 → 검증 → 반복	제약 설정, 샘플링, 증거 감사, 배포 판정
자동화	가능	불가능
실패 비용	다시 돌면 됨	되돌리기 어려움

3. 루프가 성립하는 조건

루프에는 측정 가능한 종료 조건이 반드시 있어야 한다. 루프를 설계할 때 실제로 하는 일의 대부분은 프롬프트를 다듬는 게 아니라 종료 조건을 코드로 표현 가능한 형태까지 좁히는 작업이다. 이게 루프 엔지니어링의 실체에 가깝다.

성립하는 것

Dashboard.tsx의 데이터 페칭 레이어를 리팩터링한다.
Lighthouse 성능 점수 92 이상이 될 때까지.

성립하지 않는 것

이 UI 디자인을 좋게 유지해줘.

루프가 언제 멈춰야 하는지 판단할 방법이 없다. 취향, 창의적 탐색, 주관적 판단이 들어가는 일은 자동 판정이 불가능하다. 검증할 수 없으면 루프가 아니다. 그냥 반복이다.

4. Claude Code 활용

Claude Code는 지난 몇 달간 루프의 구성요소를 하나씩 채워왔다. 릴리즈 노트에 흩어져 있어서 잘 안 보이는데, 루프 관점에서 다시 배열하면 그림이 선명해진다. 개별 기능을 다 몰라도 된다. 어떤 자리를 무엇이 채우고 있는지만 보면 된다.

루프	구성요소	Claude Code 기능 도입
종료 조건	/goal	v2.1.139 (2026.5)
주기 실행	/loop, Monitor 도구	v2.1.98 (2026.4)
이벤트 트리거	Routines, /autofix-pr	2026.4
병렬 실행	백그라운드 서브에이전트 + worktree 격리	v2.1.195~ 기본값
대량 분배	dynamic workflows (/workflows)	2026.5, 리서치 프리뷰
루프 간 통신	세션 간 메시징	v2.1.224 (2026.8)
관제	claude agents	v2.1.139
마찰 제거	auto mode	2026.8.14부터 기본값
검증 게이트	/code-review, security-guidance 플러그인	2026.5~7

종료 조건: /goal

매 턴이 끝날 때마다 빠른 모델이 조건 충족 여부를 검사한다. 충족되지 않았으면 제어권을 사람에게 넘기지 않고 다음 턴을 스스로 시작한다. 조건이 충족되면 goal이 해제된다.

/goal all tests in test/auth pass and the lint step is clean

/goal이 하는 일을 정확히 말하면 이렇다. "엔터를 대신 눌러주는 것." 별것 아닌 것 같지만, 이너 루프에서 사람을 빼내는 최소 단위가 정확히 이거다.

주기와 이벤트: /loop와 Monitor

/goal이 조건이 만족될 때까지라면, /loop는 주기적으로다.

/loop check CI on my PR

간격을 생략하면 Claude가 작업 성격에 맞춰 다음 실행 시점을 스스로 정한다. 아예 폴링을 건너뛰고 Monitor 도구를 쓰기도 한다.

Monitor는 백그라운드 감시자를 띄우고 이벤트를 대화에 흘려넣는 도구다. 이벤트 하나가 새 메시지로 들어오고 Claude가 즉시 반응한다.

Tail server.log in the background and tell me the moment a 5xx shows up

sleep 루프로 턴을 붙잡고 있을 필요가 없다는 게 핵심이다. 폴링 기반 루프와 이벤트 기반 루프는 비용 구조가 완전히 다르다. 감시 대상이 명확하다면 Monitor 쪽이 압도적으로 싸다. PR 단위로는 /autofix-pr이 있다. 브랜치를 푸시하고 명령 하나 실행하면 CI와 리뷰 코멘트를 지켜보다가 green이 될 때까지 수정을 밀어넣는다.

대량 분배: dynamic workflows

한 대화가 조율하기엔 너무 큰 작업이 있다. 코드베이스 전체 감사, 대규모 마이그레이션, 교차 검증이 필요한 리서치 같은 것.

create a workflow that migrates every internal fetch() call to the new HttpClient wrapper

이렇게 요청하면 Claude가 오케스트레이션 스크립트를 직접 작성하고, 그 스크립트가 다수의 서브에이전트에 작업을 뿌린다. 실행 중인 워크플로는 /workflows로 관리한다. 파일 충돌은 worktree 격리로 처리된다.

루프 간 통신: 세션 간 메시징

Claude Code 세션끼리 서로 메시지를 보낸다.

Tell the session working on the payments API that users.name is now users.display_name

ListAgents로 도달 가능한 다른 세션을 찾고 SendMessage로 보낸다. 두 도구 모두 Claude가 알아서 호출하니 직접 부를 일은 없다. 도달 범위는 /list-agents(별칭 /peers)로 확인한다. macOS와 Linux에서 동작하고 네이티브 Windows에서는 지원하지 않는다.

대상을 직접 지정하려면 @로 멘션한다. v2.1.232부터다.

Let @api-worker know the schema migration finished

세 가지가 중요하다. 첫째, 사람이 시키지 않아도 Claude가 스스로 보낸다. 한 세션의 변경이 다른 세션이 하고 있는 일에 영향을 준다고 판단하면 알아서 전달한다. 둘째, 넘어가는 건 Claude가 작성한 텍스트뿐이다. 대화 기록도, 파일도 넘어가지 않는다. MCP가 에이전트와 외부 도구를 잇는 프로토콜이라면, 이건 에이전트와 에이전트를 잇는 훨씬 얇은 통로다. 실제로 도착하는 메시지는 이런 한 줄이다.

Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.

셋째, 권한 경계는 세션마다 유지된다. 다른 세션에서 온 메시지는 사람의 승인으로 취급되지 않는다. 대기 중인 권한 프롬프트에 대신 답할 수 없고, 권한 설정이나 CLAUDE.md를 바꾸라는 요청도 거부된다. 메시지 안의 /compact 같은 명령은 그냥 텍스트로 도착할 뿐 실행되지 않는다. 에이전트끼리 통신시킬 때 제일 먼저 걱정되는 부분인데, 여기는 막아뒀다.

두 세션이 서로 메시지를 주고받으며 무한히 도는 상황도 자동으로 차단된다. 발신자별 레이트 리밋이 걸려 있고 짧은 시간 안의 동일 반복은 버려진다. 수신 정책을 직접 제어하고 싶다면 crossSessionInbound 설정으로 전달/보류/거부를 고를 수 있다. 루프 관점에서 이게 왜 중요하냐면, 지금까지 병렬로 돌린 루프들은 서로를 몰랐다. 세션 A가 스키마를 바꿔도 세션 B는 옛 스키마를 가정한 채 계속 돌았고, 그 불일치는 사람이 발견해서 사람이 전달해야 했다. 즉 병렬 루프가 늘어날수록 아우터 루프의 부담이 선형으로 늘었다. 여러 루프가 서로를 알게 되면 그 부담 일부가 이너 루프로 내려간다. 팩토리가 실제로 성립하기 시작하는 지점이 여기다.

5. 루프의 숨은 비용

• 인지적 항복(cognitive surrender): 결과를 비판 없이 받아들이면서 확신은 오히려 커지는 상태. 루프가 매끄럽게 돌수록 심해진다. 잘 돌아가는 것처럼 보이는 게 검증의 근거가 되어버린다.
• 인지 부채(cognitive debt): 위임이 길어질수록 코드에 대한 이해가 깎인다. Anthropic이 엔지니어 52명(대부분 주니어)을 대상으로 진행한 연구에서, 처음 접하는 라이브러리로 과제를 수행한 뒤 본 퀴즈 점수가 AI 지원 그룹은 평균 50%, 직접 작성 그룹은 67%였다. 17%p 차이다. 격차가 가장 컸던 항목은 디버깅이었다. 흥미로운 건 사용 방식에 따라 결과가 갈렸다는 점이다. 코드 생성을 통째로 위임한 쪽은 40% 아래였고, 되물어보거나 개념 질문에만 AI를 쓴 쪽은 65% 이상이었다.
• 오케스트레이션 세금: 실행은 병렬화되지만 사람의 판단은 병렬화되지 않는다. 에이전트를 10개 돌려도 검토는 순차적으로 해야 한다. 루프를 늘리면 늘릴수록 사람의 주의력이 병목이 된다. 여기가 루프 개수의 실질적 상한이다.

자동 평가자는 규칙 충족만 본다. 테스트가 통과하는지, 린트가 깨끗한지는 보지만 방향이 맞는지는 보지 못한다. 종료 조건을 잘 세운 루프일수록 이 문제가 커진다. 형식은 완벽하게 만족시키면서 잘못된 방향으로 성실하게 달려가는 결과물이 나온다. 그리고 루프는 그걸 성공으로 판정하고 다음 작업으로 넘어간다. 그래서 아우터 루프에서 반드시 남겨둬야 할 게 샘플링이다. 전부 볼 수 없으니 무작위로 뽑아서 본다. 통과한 것 중에서도 뽑아서 본다. 이게 없으면 루프는 조용히 잘못된 방향으로 수렴한다.

참고

• Peter Steinberger — 루프 설계에 관한 포스트
• Addy Osmani — Own the Outer Loop
• Addy Osmani — Practical Loop Engineering
• Latent Space — 5 Trends That Defined AI Engineering at World's Fair 2026
• Martin Fowler — Harness engineering for coding agent users
• Anthropic — AI assistance and coding skills
• Claude Code Docs — Goals
• Claude Code Docs — Dynamic workflows
• Claude Code Docs — Cross-session messaging
• Claude Code Docs — Permission modes
• Claude Code Docs — What's new