루프 엔지니어링: 에이전트를 프롬프트하는 시대에서 루프를 설계하는 시대로

들어가며: 이름이 막 붙은 작업

2026년 6월, 한 단어가 갑자기 타임라인을 채웠다. loop engineering. 오늘 기준으로 길어야 3주 된 신조어다. 그런데 가리키는 대상은 새로운 게 아니다. 이미 많은 사람이 하고 있던 작업에 이름이 붙었을 뿐이다.

정의부터 보자. Loop engineering은 에이전트에게 매 턴 직접 지시문을 쓰는 대신, 에이전트를 자동으로 굴리는 시스템(루프) 자체를 설계하는 작업이다. 일거리를 발견하고(discover), 에이전트에 넘기고(act), 결과를 작성자와 분리된 검증자로 검증하고(verify), 상태를 외부에 기록하고(remember), 다음 행동을 고르는 닫힌 순환을, 사람이 매번 키를 누르지 않아도 돌아가게 만드는 것.

이 글은 그 단어가 어디서 왔고, 루프가 무엇으로 이루어지며, 어디서 깨지는지, 그리고 비용과 보안은 어떻게 통제하는지를 정리한다. 마지막엔 내가 직접 자율 개발 루프를 운영하면서 배운 것을 붙인다. 자료는 7개 각도로 웹을 훑고 1차 출처를 정독한 뒤 적대적으로 교차검증했고, 그 과정에서 떠돌던 통설 몇 개가 정정됐다. 정정된 것들은 본문에 그대로 표시했다.

1. 기원과 계보

먼저 분명히 해둘 것이 있다. 단일 트윗이 이 개념을 발명하지 않았다. Ralph-style bash 루프, /loop 커맨드 같은 실천은 라벨보다 먼저 있었다. 2026년 6월에 일어난 일은 발명이 아니라 명명이다.

계보를 시간순으로 정리하면 이렇다.

• Andrej Karpathy (선행) - 2026년 3월 No Priors 에피소드에서 "loopy era"를 언급하고 autoresearch 루프를 시연했다.¹ 용어보다 약 2.5개월 앞선다.
• Peter Steinberger (OpenClaw 제작자) - X 게시물 "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." (2026년 6월 초). 개념을 던진 핵심 발화. 원문은 "Here's your monthly reminder that..."로 시작하는 강조용 밈 포맷이고, 많은 2차 글이 이 리드를 누락한다.
• Addy Osmani (Google) - 에세이 Loop Engineering. 해부도를 그리고 형태를 체계화한 canonical 문헌이다. 다만 Osmani 본인은 용어를 만들었다고 주장하지 않는다. 본문에서 Steinberger와 Cherny에게 명시적으로 공을 돌린다. "Osmani가 loop engineering을 coined했다"는 흔한 서술은 틀렸다.
• swyx (Shawn Wang) - Loopcraft: The Art of Stacking Loops (6월 12일). "loopcraft"라는 별개 용어로, Karpathy/Steinberger/Cherny를 함께 기원으로 나열한다.
• Sydney Runkle (LangChain) - The Art of Loop Engineering (6월 16일). loopcraft 위에 4-loop 프레임워크를 얹었다.

지적 불씨로 가장 많이 인용되는 건 Boris Cherny (Anthropic, Head of Claude Code)의 발언이다. 요지는 이렇다. "나는 더 이상 Claude를 프롬프트하지 않는다. Claude를 프롬프트하고 무엇을 할지 정하는 루프를 돌린다. 내 일은 루프를 쓰는 것이다." 이 인용은 강력하지만, 출처를 파보면 깔끔하지 않다.²

provenance 메모. Cherny 인용은 널리 유통되는 paraphrase다. 2026년 6월 초 WorkOS가 주최한 "Acquired Unplugged" 에디션과 여러 2차 클립을 통해 퍼졌는데, 표기가 단수("write the loop")와 복수("write loops")로 갈리고, 공식 timestamped transcript는 확인되지 않았다. 정확한 문구와 최초 발화 장소는 확정하지 않는 게 정직하다. 흥미롭게도 가장 많이 인용되는 Osmani의 canonical 에세이조차 이 인용을 1차 녹음이 아니라 제3자 트윗에 앵커링했다. 통설의 "fuzzy provenance"는 여기서 나온다.

한 가지 더 정정. "Anthropic이 Willison의 'tools in a loop' 정의를 채택했다"는 순서가 반대다. *"Agents are models using tools in a loop"*는 Anthropic의 Hannah Moran이 먼저 말했고, Simon Willison이 2025년 5월 그 표현을 Moran에게 크레딧한 뒤 9월에 확장 정의를 덧붙였다.

2. 진화 계층: prompt에서 loop까지

업계가 수렴한 4계층 구도가 있다. 각 층은 앞 층을 폐기하지 않고 감싼다. 바뀌는 건 "작업 단위"다.

다이어그램 1. prompt -> context -> harness -> loop의 4계층을 겹겹이 감싼 그림. 안쪽 prompt engineering(한 번의 턴, 2022-2024)을 context engineering(컨텍스트 윈도우, 2025)이 감싸고, 그 위를 harness engineering(에이전트 1개의 실행 환경: 도구·제약·검증·관측, 2026 초)이, 다시 그 위를 loop engineering(자율 순환 cadence, 2026 중)이 감싼다. 안쪽에서 바깥으로 갈수록 작업 단위가 커지고, 각 바깥 층은 안쪽 층을 대체하지 않고 그 위에서 동작한다. 가장 바깥 층에는 트리거(스케줄/이벤트/CI)와 검증 가능한 목표라는 두 전제를 함께 적었다.

적어도 prompt에서 context로 이어지는 연속성은 벤더 문서에서도 확인된다. Anthropic은 공식 블로그 Effective context engineering에서 *"우리는 context engineering을 prompt engineering의 자연스러운 연장으로 본다"*고 명시했다. 컨텍스트 엔지니어링 자체에 대해서는 예전에 별도 글로 정리한 적이 있다.

왜 루프가 단위가 됐나. 병목이 옮겨갔기 때문이다. "모델의 턴당 능력"에서 "긴 task horizon에 걸친 자율 지속성과 오류 복구"로. cron job과 루프의 차이는 결정자의 유무다. cron은 고정 스크립트를 돌리지만, 루프는 현재 상태를 보고 다음 행동을 고르는 에이전트를 돌린다. 루프가 성립하려면 두 가지가 필요하다. 트리거와 검증 가능한 목표.

3. 루프의 해부: agent loop와 harness loop

루프를 이해하는 가장 깔끔한 틀은 Armin Ronacher가 The Coming Loop에서 제시한 2층 구분이다. 그는 루프 회의론자에 가깝지만, 구조 자체는 명료하게 잘랐다.

• agent loop - 한 세션 안에서 모델이 도구를 호출하고 관찰하고 다시 호출하는 안쪽 순환. ReAct가 그 원형이다.
• harness loop - 세션을 재시작하고, 컨텍스트를 갈아끼우고, 에스컬레이트하고, 일거리를 라우팅하는 바깥쪽 오케스트레이션.

loop engineering이 실제로 다루는 건 대부분 바깥쪽, harness loop다. LangChain은 이 바깥 구조를 4개의 중첩 루프로 분해한다. (1) agent loop, (2) verification loop(grader가 rubric으로 채점), (3) event-driven loop(webhook/스케줄이 트리거), (4) hill-climbing loop(프로덕션 trace를 읽고 프롬프트·도구·rubric을 자동 재작성하는 자기개선).

다이어그램 2. 안쪽 agent loop(Thought -> Action -> Observation)를 harness loop가 감싸고, harness loop는 Discovery -> Handoff -> Verification -> Persistence -> Scheduling의 사이클을 돈다. 바깥에서 event-driven loop(webhook/스케줄/CI)가 사이클의 시작점을 트리거하고, hill-climbing loop가 프로덕션 trace를 읽어 안쪽 agent loop의 프롬프트·도구·rubric을 직접 다시 쓴다. 핵심은 피드백이 맨 위로만 돌지 않고 안쪽 루프를 직접 갱신한다는 점이다. swyx의 표현으로는 "다음 세기의 게임은 루프를 얼마나 효과적으로 쌓느냐에 달렸다."

빌딩 블록 수준에서 Osmani는 6개 컴포넌트로 정리한다.

운영 관점에서 loopengineering.run 가이드는 같은 것을 5단계 사이클로 본다. Discovery(CI·이슈·커밋·인박스·분석에서 일거리 발견) -> Handoff(범위가 한정된 태스크 + 컨텍스트 + 격리된 작업공간) -> Verification(별도 verifier가 테스트·diff·요구사항·실패모드 점검) -> Persistence(PR/이슈/상태파일) -> Scheduling(타이머/webhook/CI가 재트리거). 그리고 4개의 명명된 리스크(verification debt, comprehension rot, cognitive surrender, token blowout)에 예산 캡·재시도 제한·휴먼 게이트를 가드레일로 건다. 이 운영 그림은 6장에서 비용·보안과 함께 다시 그린다.

State/Memory를 마크다운으로 운영하는 구체적 설계는 LLM Wiki와 ADR 글에서, 자기개선 루프를 갖춘 에이전트들의 비교는 자가개선 AI 에이전트 5종 비교에서 더 깊게 다뤘다.

4. 루프 설계 패턴의 학술적 뿌리

루프 패턴 대부분은 2022년 이후 논문에 이름이 있다.

마지막 행은 주의해서 인용해야 한다. +90.2%는 리서치 eval 수치이고, 흔히 같이 인용되는 "토큰이 분산의 80%를 설명한다"는 별개의 BrowseComp eval 수치다. 두 숫자를 한 문장에 섞으면 틀린 주장이 된다.

에이전트 아키텍처를 패턴 수준에서 비교한 내용은 [Agent Architecture Comparison](2025-06-04-Agent Architecture Comparison)에 따로 정리해뒀다.

5. 프레임워크별 루프 제어

모든 하네스가 같은 while-loop("도구 호출이 없을 때까지 반복")를 구현하지만, 노출하는 제어와 기본 한도가 다르다. 여기서 통설 하나가 정정된다. "다들 20스텝쯤이 기본"이라는 말은 부정확하다.

Claude Agent SDK 문서에 따르면 max_turns와 max_budget_usd의 기본값은 모두 "No limit"이다. CI나 컨테이너에서 의도적으로 무제한을 노린 설계다. 단, 예산은 호출과 호출 사이에 검사되므로, 단일 과대 호출 하나는 캡을 넘길 수 있다.

루프의 종료 조건을 다루는 네이티브 기능으로 Claude Code의 /goal이 있다(v2.1.139 이후). 별도의 작고 빠른 모델이 매 턴 후 완료 조건을 판정하고, "아직"이면 그 이유를 다음 턴 지침으로 다시 넣는다. 이게 뒤에서 말할 "maker != checker"를 네이티브로 구현한 것이다. 다만 한계가 분명하다. 이 evaluator는 도구를 돌리거나 파일을 직접 읽지 못하고 transcript만 본다. 조건은 4,000자로 제한되고, 내장 turn cap이 없어 종료 횟수는 조건문에 직접 인코딩해야 한다.

(참고: OpenAI Assistants API의 requires_action 폴링 방식은 deprecated 상태이고 Responses API로 대체되고 있다. 구체적 종료 날짜는 출처마다 흔들려 여기서는 단정하지 않는다.)

6. 루프는 오류를 자동으로 없애지 않는다

여기가 가장 실무적인 부분이다. 루프를 길게 돌리면 좋아진다는 직관은 절반만 맞다.

오류 복합과 그 반례

스텝당 정확도가 p면 N스텝 루프는 단순 모델로 p^N이다. 95%/스텝이면 10스텝에 약 60%, 20스텝에 약 36%다. 멀티에이전트에선 한 에이전트의 열화된 출력이 다음 에이전트의 "ground truth"가 되어 hop마다 전파된다.

그런데 이 p^N 서사를 그대로 받으면 안 된다. "Beyond Exponential Decay"는 순진한 p^N이 실패를 과대예측한다고 반박한다. 실제 LLM 오류는 균등 분포가 아니라 일부 "key token"에 집중되고, 런 중간의 self-correction이 오류를 줄여서 sub-exponential에 가까워진다.

문제는 반대 방향 증거도 있다는 것이다. 장기 신뢰성을 다룬 arXiv:2603.29231은 2.3만 에피소드, 10개 모델에서 평균 pass@1이 단기 76.3%에서 초장기 52.1%로 떨어지고(약 24점), capability 순위가 reliability 순위와 일치하지 않으며, correlated error 때문에 i.i.d. 예측보다 나쁜 감쇠가 나타난다고 보고한다. 특히 메모리 스캐폴드를 붙여도 장기 신뢰성이 개선되지 않았다. 이건 "에이전트는 잊지만 repo는 안 잊는다"는 anatomy의 낙관과 긴장 관계를 만든다.

정직한 결론은 이렇다. 두 결과가 모순은 아니다. self-correction이 작동하는 task mix가 따로 있고, correlated error가 지배하는 task mix가 따로 있다. 루프를 길게 돌린다고 오류가 저절로 사라지지는 않는다. 테스트가 있고 진위를 외부에서 판정할 수 있는 검증 가능한 상태공간, 거기서만 회복성이 생긴다.

게다가 검증자도 안전하지 않다. Classifier Context Rot 계열 연구는 모니터/가드레일 분류기 자체가 컨텍스트가 길어지면 정확도가 떨어진다고 본다. 루프의 checker도 maker와 같은 장기-컨텍스트 감쇠를 겪으므로, 검증자 컨텍스트는 짧고 신선하게 유지해야 한다. (Context rot 자체는 Chroma가 18개 모델로 보고한 일반 현상이다.)

2026년 중반 쏟아진 장기 horizon 벤치마크들도 같은 방향을 가리킨다. Agents' Last Exam(2606.05405)에서 frontier 모델의 평균 full pass는 한 자릿수 초반에 그치고, SWE-Marathon(2606.07682)에서는 모델들이 롤아웃당 수천만 토큰을 쓰고도 과반을 풀지 못한다. 작업이 길어질수록 신뢰성이 빠르게 무너진다는 신호다.

실패 모드의 지도

Harness-Bench는 이 글 전체에서 가장 중요한 citable 수치다. 능력은 모델 단독이 아니라 모델+하네스 수준으로 보고해야 한다. loop/harness 설계가 일급 평가 변수라는 직접 근거다.

7. 경제성과 보안: 루프를 안전하게 운영하기

루프를 24시간 돌린다는 건 비용과 공격면을 24시간 연다는 뜻이다.

경제성

먼저 전제 하나. 저렴한 야간 루프는 현재 구독 보조금에 올라타 있고, 그건 명시적으로 시한부다. Anthropic은 Agent SDK와 headless 실행을 구독 풀에서 빼 별도 달러 크레딧으로 옮기겠다고 발표했다가 시행 예정일에 "Nothing changes for now"로 보류했다. 지금의 루프 경제는 이 보조금 위에 서 있다.

실제 비용 데이터는 양극단을 보여준다. Jellyfish의 Q1-2026 데이터(1.2만 개발자/200기업)에서 PR당 비용은 사용량 최하위 대비 최상위 티어에서 $0.28에서$89.32까지 벌어졌다. 상위 decile은 약 10배 토큰을 쓰고 약 2배 처리량을 냈다.³ 기업 단위로는 Uber가 2026년 AI 코딩 예산을 4개월 만에 소진하고 [도구당 직원 월 $1,500 캡을 도입](https://techcrunch.com/2026/06/05/the-token-bill-comes-due-inside-the-industry-scramble-to-manage-ais-runaway-costs/)했다. 한 달$40,000 토큰을 쓴 엔지니어, 한 달 약 $500M Claude 청구 같은 사례도 돌지만, 이것들은 모두 전언이나 보도이지 1차 확인이 아니다.⁴

런어웨이 비용은 통제 가능한 엔지니어링 문제다. 흔히 인용되는 "4시간에 $2,847" 같은 일화는 출처가 불분명하니 인용하지 않는 게 낫다. 대신 통제 수단을 보자.

1. 하드 반복 캡(tool-call ceiling)
2. 런/세션 총액 캡
3. 비용-속도 서킷브레이커(총액 캡과 별개로, 빠르게 타들어가는 루프를 먼저 잡는다)
4. 결과 인지형 무진전 감지(같은 인자로 같은 도구를 2~3회 반복하면 정지)
5. 게이트웨이/프록시 레벨에서의 강제

반대로 루프 경제가 잘 작동한 사례도 있다. SkyPilot이 보고한 autoresearch 스케일링에서 Claude Code가 16-GPU 위에서 8시간에 약 910개 실험을 돌려 순차 대비 약 9배 빨랐고, 비용은 Claude API 약 $9 + GPU 약$260-300이었다. 에이전트가 지시 없이 "저렴한 GPU로 스크리닝, 빠른 GPU로 검증"하는 2-티어 전략을 스스로 만들었다는 점이 인상적이다.

거시적으로는 NBER Working Paper 35275가 한계를 정확히 짚는다. 10만+ GitHub 개발자 매칭 분석에서 AI 코딩 도구는 커밋을 autocomplete +40%, 동기 에이전트 +140%, 비동기 에이전트 +180%까지 늘렸지만, 이 효과는 프로젝트 수 +50%, 실제 릴리스 +30%로 줄어든다. 코드 쓰기만 가속하면 출력은 사람이 하는 가장 약한 단계(리뷰·통합·테스트·배포)에서 병목이 걸린다. 검증이 새 병목이라는 게 데이터로 나온다.

보안

루프 보안의 출발점은 Simon Willison의 "lethal trifecta"(사적 데이터 + 신뢰불가 콘텐츠 + 외부 유출 경로)다. Meta는 이걸 일반화한 "Agents Rule of Two"를 제안했다. 견고한 인젝션 탐지가 없는 한, 에이전트는 한 세션 안에서 (A) 신뢰불가 입력 처리, (B) 민감 데이터 접근, (C) 상태 변경 또는 외부 통신 중 둘 이하만 가져야 한다. 셋 다면 휴먼 인 더 루프가 필수다. 루프 설계에서는 "세션 = 예산 단위"로 이 규칙을 매핑하면 된다.

왜 in-loop 필터에 기대면 안 되는가. The Attacker Moves Second(OpenAI/Anthropic/DeepMind 공동)는 최근 발표된 12개 인젝션·탈옥 방어가 적응형 공격에 90% 이상의 성공률로 우회됨을 보였다. 결론은 루프 내부 필터가 아니라 아키텍처적 제약(Rule of Two, 샌드박싱)으로 막아야 한다는 것이다. 정리된 위협 목록으로는 OWASP Top 10 for Agentic Applications 2026이 있다(ASI06 Memory & Context Poisoning, ASI08 Cascading Failures 등 루프와 직결되는 항목 포함).

추상적인 얘기가 아니다. 실제 사례가 있다.

• CI/CD 루프 인젝션 - Microsoft가 보고한 사례에서, Claude Code GitHub Action이 신뢰불가 이슈/PR 텍스트의 인젝션으로 /proc/self/environ을 읽어 CI 시크릿을 유출할 수 있었다. Bash는 샌드박스였지만 Read 도구가 비샌드박스라 구멍이 났다. 2.1.128에서 수정됐다.
• 공급망 침해 - litellm 패키지의 백도어 버전이 PyPI에 노출된 사건. 근본 원인은 CI의 unpinned action이 publish 토큰을 탈취당한 것이었다. 루프가 의존하는 게이트웨이 한 곳이 뚫리면 그 위 모든 루프가 뚫린다.

방어 쪽 좋은 소식도 있다. Anthropic의 샌드박싱 보고에 따르면 파일시스템·네트워크 격리는 인젝션이 성공해도 피해를 봉쇄하면서 권한 프롬프트를 84% 줄였다. 자율성과 보안을 동시에 올린 셈이다. GitHub Agentic Workflows의 'safe outputs'는 한 걸음 더 나가서, 자율 루프가 레포를 직접 변경하지 못하게 하고 결정론적 비-LLM 스텝이 검증·적용하는 제안만 내게 한다. "생성하지 않은 무언가가 코드를 검증해야 한다"는 원칙의 아키텍처적 답이다.

다이어그램 3. 5단계 운영 루프(Discovery -> Handoff -> agent loop -> Verification -> Persistence -> Scheduling)에 세 종류의 게이트를 얹은 운영도. 비용 게이트(tool-call ceiling, session cap, cost-velocity circuit breaker)가 실행 구간을 통제하고, 보안 게이트(Rule of Two, sandbox)가 Handoff 입력을 검사하며, 검증은 maker와 분리된 독립 checker가 맡는다. Persistence(merge/deploy) 직전에 놓인 빨간 human gate가 한 문장 메시지를 만든다. "고위험 merge/deploy/destructive action은 human gate 없이는 일어나지 않는다."

8. 프로덕션의 현실: 벤더 주장과 독립 반증

루프가 실제로 코드를 짜고 머지하는 사례는 많아졌다. 다만 벤더 자가보고와 독립 분석을 반드시 짝지어 읽어야 한다.

벤더가 말하는 것

• Anthropic - 2026년 5월 기준 자사 코드베이스 병합 코드의 80%+가 Claude 저작이며, 한 자율 작업이 API 에러 한 클래스에 800+ 수정을 보내 에러율을 크게 낮췄다고 보고한다. 모두 내부 자가보고이고 recursive self-improvement 안전 서사 안에 있다.
• Mozilla - 2026년 4월 423건의 보안 수정을 처리했고, 그중 271건이 Claude 'Mythos' agentic 파이프라인의 직접 산출로 보고됐다(나머지는 외부 보고·타 모델·수동). 에이전트가 14~20회 재시도하며 사람 같으면 지쳤을 지점을 넘어 15년 묵은 버그를 재발견했다. "423건 전부를 루프 산출"로 쓰면 과장이다.
• Cognition (Devin) - 흥미롭게도 스스로 불확실성을 정량화했다. Devin 생산성을 인간-시간 등가로 약 2.08배로 추정하되, 세션의 약 50%만 그 추정의 2배 이내라고 인정한다. "Nx faster" 마케팅에 대한 sourced 카운터웨이트다.

독립 분석이 말하는 것

• arXiv:2606.22711은 3.3만 개의 실제 에이전트 PR을 분석했다. 풀링하면 자율 79.8% vs 협업 53.8%처럼 보이지만, 이는 한 도구가 데이터셋의 절반 이상을 차지해서 생긴 Simpson's paradox다. 에이전트별로 보면 자율 머지율은 Copilot 6.2%, Devin 21.6%로 떨어진다.
• Faros.ai의 텔레메트리(2.2만 개발자)는 처리량이 오르는 동안 사건-대-PR 비율 +242.7%, 코드 처닝 +861%, 리뷰 중앙값 시간 +441.5%, 개발자당 버그 +54%를 보고한다. 상관 비교라 인과는 미확립이지만 방향은 분명하다.
• 벤치마크 신뢰성 자체가 흔들린다. OpenAI는 SWE-bench Verified 보고를 중단하고(오염·결함 테스트) SWE-bench Pro를 권고했는데, Pro에서 점수가 크게 하락한다. 일부 감사는 모델이 컨테이너의 .git 히스토리에서 정답 커밋을 읽는 오염까지 보고했다.

종합하면, 루프는 코드를 빠르게 만들지만 그 코드가 안전하게 흘러가는지는 별개 문제다. 처리량 지표와 품질 지표를 같이 봐야 한다.

9. 반론을 진지하게: 루프를 쓰면 안 되는 때

좋은 글이라면 가장 강한 반론을 피하지 않아야 한다.

• comprehension debt와 cognitive surrender (Osmani 본인) - "시스템에 존재하는 코드와 어떤 인간이 진정으로 이해하는 양 사이의 격차". 루프가 빠르게 ship할수록 이 격차가 벌어진다. Osmani는 offloading(어떻게를 위임하되 판단은 보유)과 surrender(사고 자체를 위임)를 구분하며 후자를 경계한다.
• 이해도 17점 하락 (Anthropic RCT) - 낯선 라이브러리를 학습하는 실험에서, AI 그룹은 방금 작성한 코드의 이해 퀴즈에서 17점 낮았다(약 두 학점). 속도 향상은 통계적으로 유의하지 않았다. 가장 해로운 건 수동적 위임이었다.
• read-heavy는 멀티, write-heavy는 단일 - Cognition의 "Don't Build Multi-Agents"와 후속 글은 분계선을 명확히 한다. 컨텍스트를 공유하지 않는 병렬 writer는 서로 충돌한다. 작동하는 형태는 single-threaded writer 하나를, 지능만 보태는 서브에이전트가 보조하는 구조다. Stanford의 단일 vs 멀티 연구도 사고 토큰 예산을 같게 맞추면 단일 에이전트가 멀티를 매치/초과한다고 보고한다(이 논문은 Anthropic이 아니라 Stanford 연구다).
• 긴 루프일수록 위험하다 (Ord의 half-life) - Toby Ord의 모델은 에이전트가 작업 시간당 일정 위험률로 실패한다면 성공이 길이에 따라 지수 감소하고, 각 에이전트는 특성 "half-life"를 갖는다고 본다. 더 긴 자율 루프는 본질적으로 더 위험하다.
• 인센티브 회의론 - The Register는 루프 옹호가 벤더의 토큰 매출 인센티브와 겹친다고 지적한다(Cherny의 월 토큰 예산이 6자리로 보도된다는 점도 함께 짚는다). 회의를 건강하게 유지할 이유다.

그래서 "루프를 쓰면 안 되는 때"의 체크리스트는 이렇게 정리된다. 목표가 검증 불가능하게 주관적일 때, 로컬 미니마(자동 체크는 통과하나 유지보수성은 악화)에 빠지기 쉬운 작업일 때, 그리고 사람이 이해를 따라잡을 수 없을 만큼 빠르게 코드가 쌓일 때다.

여기서 maker != checker도 정확히 표현하자. 이건 절대 불변식이라기보다 최소 설계 규칙이다. /goal의 evaluator는 transcript만 보지 파일도 테스트도 직접 보지 못한다. 고위험 작업은 그 위에 결정론적 테스트, 샌드박스, 브랜치 보호, 휴먼 게이트까지 쌓아야 비로소 신뢰할 만해진다.

10. 직접 자율 개발 루프를 운영하며

이 조사를 하면서 가장 분명해진 건, 내가 몇 달째 굴려온 자율 개발 루프가 업계가 막 이름 붙인 loop engineering의 거의 교과서적 구현이라는 점이다. 트렌드 수집에서 이슈로, 이슈에서 PR로, 검증 게이트를 통과한 PR이 자동 머지로 이어지는 닫힌 순환은 Osmani의 "find work -> act -> verify -> remember"와 정확히 같은 형태다. 트윗이 나오기 전부터 이미 짓고 있었다.

운영하면서 배운 것들이 이번 조사로 이론적 근거를 얻었다.

• 검증 게이트를 작성 에이전트와 분리한 건 "maker != checker"였다. 다만 transcript만 보는 evaluator로는 부족하고, 결정론적 테스트와 CI 통과를 게이트의 비협상 조건으로 둬야 했던 이유가 6장과 9장에서 분명해졌다.
• 루프 기계장치(워크플로 정의, 게이트) 자체를 에이전트가 못 건드리게 막아둔 건, GitHub 'safe outputs'와 Lavaee의 "에이전트는 .github/workflows를 수정 못 한다" 가드레일과 같은 패턴이었다.
• 완료한 작업을 재사용 가능한 skill로 증류하고, 결정을 ADR로 남긴 건 hill-climbing 루프와 episodic memory였다. 메모리 운영의 구체적 설계는 Hermes로 조직 지식 만들기에 정리해뒀다.

실무적으로 가져갈 건 두 가지다.

첫째, Harness-Bench 교훈. 같은 모델이 하네스에 따라 23.8점 흔들린다. 루프의 가치는 모델 선택보다 루프·게이트 설계에 더 좌우된다. 그러니 평가도 모델 단독이 아니라 모델+하네스 단위로 봐야 한다.

둘째, comprehension debt를 비용으로 계상할 것. 루프가 빠르게 ship할수록 "존재하는 코드"와 "내가 이해하는 코드" 사이 간극이 벌어진다. Osmani의 말을 빌리면, 루프를 짓되 go 버튼만 누르는 사람이 아니라 엔지니어로 남을 사람처럼 지어야 한다. 그래서 내 루프에서도 사람이 읽는 다이제스트와 결정 로그를 루프의 일부로 둔다. 루프가 나를 일에서 지우는 게 아니라, 일의 모양을 바꾸도록.

마치며

loop engineering은 새 마법이 아니라 새 이름이다. 이름이 붙었다는 건, 흩어져 있던 실천(격리된 worktree, 외부화된 skill, 독립 검증, 영속 상태, 스케줄 트리거)을 하나의 설계 대상으로 다룰 수 있게 됐다는 뜻이다. 동시에 이름은 과대광고를 끌어온다. 그래서 이 글은 통설 몇 개를 일부러 정정했고(누가 용어를 만들었는가, 어떤 수치가 어떤 eval에서 나왔는가, 어떤 사례가 자가보고인가), 루프의 회복성이 공짜가 아니라 검증 가능한 상태공간을 전제한다는 점을 가운데 뒀다.

루프는 검증 가능한 상태공간 위에서, 비용·보안·이해의 게이트를 갖췄을 때 일한다. 그 게이트를 설계하는 게 loop engineering의 실체다.

주요 출처

실천가 - Osmani, Loop Engineering · swyx, Loopcraft · LangChain, The Art of Loop Engineering · Ronacher, The Coming Loop · loopengineering.run · Willison, tools in a loop

Anthropic - Building Effective Agents · Effective context engineering · Multi-agent research system · Claude Code sandboxing · Agent SDK agent loop

학술 - ReAct(2210.03629) · ReWOO(2305.18323) · MAST(2503.13657) · Beyond Exponential Decay(2505.24187) · 장기 신뢰성(2603.29231) · Harness-Bench(2605.27922) · The Attacker Moves Second(2510.09023) · 자율 PR 분석(2606.22711) · Ord half-life(2505.05115)

경제·보안·사례 - NBER 35275 · TechCrunch, the token bill comes due · OWASP Agentic Top 10 2026 · Microsoft, securing CI/CD · Mozilla via Lenny's · Cognition, AI productivity