3줄 요약
- Flask·Sentry·Pi 창립자 Armin Ronacher가 2026년 6월 23일 자기 블로그에 발표한 에세이로, 최근 agentic engineering 담론에서 “harness loop” — 에이전트 바깥에서 작업을 이어붙이는 외부 오케스트레이션 루프 — 가 트위터 담론을 지배하기 시작했다고 관찰한다.
- 저자는 자기가 신경 쓰는 코드에는 아직 이 방식이 잘 맞지 않는다고 고백한다. 현재 모델은 너무 방어적이고, 강한 invariant를 피하고 fallback을 덧붙이며, 루프 안에 두면 그 경향이 증폭된다.
- 그럼에도 이 미래는 불가피하다. 보안 비대칭과 경쟁 속도가 옵트아웃을 허락하지 않기 때문이다. 남은 질문은 루프를 어떻게 채택하는가 — 판단을 어떻게 유지하고, 책임 있는 인간 감독을 어떻게 보존하고, 코드 아키텍처의 sanity를 어떻게 유지할 것인가다.
두 종류의 루프 — agent loop vs harness loop
저자는 글머리에 Boris Cherny의 인용을 둔다.
I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.
— Boris Cherny
이 한 문장이 글 전체의 중심 명제다. 저자는 이어서 두 가지 루프를 구분한다.
- agent loop — 코딩 에이전트 안에 이미 존재하는 루프. 모델이 도구를 호출하고, 결과를 받아 다시 도구를 호출하고, 파일을 읽고 수정하고 테스트를 돌리다가 결국 답을 내놓는다. 우리에게 익숙한 그 루프다.
- harness loop — 에이전트 바깥에서 도는 루프. 작업을 큐에 넣고, 머신이 집어 들고, 시도하고, 멈춘 뒤, 어떤 하네스가 그게 진짜 끝인지 판정한다. 끝이 아니라면 같은 세션을 이어가거나, 컨텍스트를 바꿔 새 세션을 띄우거나, 다른 머신에 작업을 넘긴다.
이 두 번째 루프는 새로 등장한 것이 아니다 — Claude Code 초기부터 변형들이 있었다. 다만 최근 몇 주 사이 트위터 담론을 지배할 만큼 부상했다.
저자가 아직 잘 못하는 이유 — 통제와 이해
저자의 솔직한 고백이 글의 결을 정한다.
My current status is that I have not had much success with this way of working for code I deeply care about which turns out to be quite a lot of code.
이유는 두 가지다. 취향(taste), 그리고 통제(control). 저자는 자기가 출하하는 코드를 이해하고 싶다. 압박 상황이나 다른 사람과의 토론에서, 시스템이 무엇을 하는지 설명할 수 있길 원한다 — 그것도 기계에게 먼저 설명해 달라고 부탁하지 않고서. 이 욕구가 몇 년 뒤에도 남아 있을지는 별개의 질문이다.
현재 모델이 만드는 코드의 결함도 구체적이다. 너무 방어적이고, 너무 복잡하고, 너무 국소적으로 추론한다. 강한 invariant를 피하고 fallback을 덧붙인다. 코드를 중복시키고, 나쁜 추상을 발명하고, 불분명한 설계를 더 많은 기계로 덧칠한다. Karpathy의 표현이 정확하다 — 모델은 “예외에 대해 죽도록 겁먹고 있다(mortally terrified of exceptions)”.
핵심 인프라나 영속 데이터 포맷처럼 중요한 invariant가 있는 시스템에서, 옳은 수정은 “모든 malformed 케이스를 처리하라"가 아니다. 옳은 수정은 malformed 케이스를 표현 불가능하게 만들거나, 애초에 기록될 수 없게 만드는 것이다. 그런데 LLM은 손으로 많이 조타해도 그런 코드를 자연스럽게 내놓지 않는다. 설사 그런 코드가 나오더라도, 이제 불가능해진 에러를 굳이 처리하려 든다.
이 행동을 루프 뒤에 두면 증폭된다. 각 반복이 작은 방어를 하나씩 더하면, 시스템은 겉으로는 더 견고해 보이면서 속으로는 점점 이해 불가능해진다. 손을 뗄수록 그 경향이 커진다. 가이드 없이 주니어에게 이런 도구를 쥐여 주면 나쁜 관행이 학습된다 — 왜 그렇게 했냐고 물으면 설득력 있게 자기 정당화를 늘어놓을 것이기 때문이다.
루프가 작동하는 영역
저자는 정직하게 인정한다. 루프 패턴이 일부 영역에서는 이미 놀랍게 잘 작동한다.
- 코드 포팅 — Bun이 Zig에서 Rust로 옮겨지고 있다. 저자 자신도 MiniJinja를 Go로 옮기는 데 루프를 성공적으로 썼다.
- 성능 탐색 — 머신이 실험을 돌리고, 벤치마크하고, 실패는 버리고, 계속 탐색한다.
- 보안 스캔.
- 연구 — 복잡한 문제 공간을 탐색해 보고만 받는 작업. 영속 코드는 만들지 않아도 된다.
공통점은 두 가지다. 새 코드를 만들기보다 이미 있는 코드를 변환하거나, 수명이 길지 않을 산출물을 만든다. proof of concept, 발견 사항, 기계적 변환 — 이런 것들은 루프와 잘 맞는다.
여기서 저자가 강조하는 통찰이 있다.
The harness just needs some signal that lets it continue. It does not have to be objective or binary, it just has to be useful enough to drive another iteration.
하네스가 다음 반복을 굴리려면 유용한 신호 하나만 있으면 된다 — 객관적이거나 이분법적일 필요는 없다. 기계적 변환 사례는 이진 테스트로 검증할 수도 있지만, 다른 LLM이 심사관(judge)을 맡아도 된다. 성공적인 루프 응용 다수가 또 다른 LLM을 judge나 오케스트레이터로 쓴다.
저자는 단언한다 — 자기는 이미 지루한 부분을 하루 일과에서 빼내 실험하고 측정하고 아이디어를 가져다 주는 루프를 사랑한다.
소프트웨어 = 유기체
문제는 같은 방법론을 오래 갈 코드에 쓸 때 발생한다. 저자가 즐겨 쓰는 비유는 결정론적 기계로서의 소프트웨어 → 유기체로서의 소프트웨어다.
저자가 엔지니어가 된 환경은 기계를 이해하라고 부추겼다. 더 깊은 이해로 가는 한 겹의 추상이 늘 존재했다. 결정론적이고 관측 가능한 동작을 보이지 않는 기계는 받아들여지긴 해도 최적으로 여겨지지 않았다. 아키텍처상으로도 결정성을 줄이기보다 늘리는 방향이 바람직했다. 코드를 이해할 수 있어야 한다는 것도 부정할 수 없는 목표였다.
물론 이상은 늘 위태로웠다. 큰 시스템은 누구의 머리에도 다 들어가지 않을 때가 많다. LLM이 없던 시절에도 분산 시스템은 의사처럼 진단했다 — 증상을 관찰하고, 가설을 세우고, “추가 검사를 처방"하고, 치료를 시도하고, 다시 관찰한다.
그런데 LLM과 함께 그 방향으로 훨씬 빨리, 훨씬 멀리 가고 있다. 코드를 LLM이 쓰고, 진단도 LLM이 하고, 처방도 LLM이 한다. 이미 일부 엔지니어는 프로덕션 이슈가 터지자마자 첫 단계가 기계가 로그를 읽고, 루트 원인을 제안하고, 능동적으로 패치를 제출하는 것인 세계에 살고 있다. 패치는 또 다른 머신이 리뷰하고, 인간 감독 없이 main에 머지되기도 한다.
저자는 이게 매력적이라는 걸 부정하지 않는다. 다만 인간 감독을 점점 더 줄이는 쪽으로 기우는 건, 곧 우리가 더 이상 시스템 전체를 같은 방식으로 이해하지 않게 된다는 것을 받아들이는 일이다. 우리는 시스템을 치료하고, 모니터링하고, 안정시키지만 — 더 이상 이해(comprehend)하지는 않는다.
저자는 일부 소프트웨어에 대해서는 그래도 괜찮다고 인정한다. 모든 코드 한 줄이 인간의 저작권을 요구하는 건 아니다. 더 나쁜 코드도 과거에 충분히 쓰여 왔다. 다만 — 모든 소프트웨어가 이런 방식으로 저작되길 내가 원하는가? 라는 질문이 남는다.
옵트아웃은 불가능하다
기계 주도 미래에서 완전히 빠지는 선택이 가능하지 않다는 점이 불편하다.
보안이 가장 분명한 사례다. 당신이 직접 루프로 소프트웨어를 만들지 않더라도, 다른 사람들이 당신의 소프트웨어를 향해 루프를 돌린다. 공격자가 머신을 지속적으로 돌리고, 공격자가 아니더라도 보안 연구자가 돌린다. 자동화된 작업은 먼지를 일으키지만 진짜 문제도 찾아낸다. 신호와 잡음이 함께 당신에게 쇄도하고, 머신을 직접 던지지 않고선 다루기 거의 불가능한 양으로 온다.
Daniel Stenberg가 쓴 curl의 summer of bliss가 좋은 사례다. curl 핵심 개발에 AI가 큰 역할을 하지는 않는데도, 메인테이너는 AI가 만들어 낸 보고서에 압도되고 있다. 공격자와 보고자가 루프를 돌리면, 방어자도 결국 루프를 돌려야 한다 — 패치를 직접 쓰지는 않더라도 적어도 분류하고 재현하기 위해서라도.
경쟁도 마찬가지다. 어떤 팀은 순수한 속도로 다른 팀을 앞질러 갈 것이다. 다섯 명이 옛날의 50명 몫을 하기 시작한다. 누군가는 말 그대로 당신의 제품을 루프에 던져 넣고 “다른 것처럼 만들어 봐"라고 시킬 것이다. 그들의 사용자가 만족한다면, 그게 정말 문제일까?
모든 소프트웨어가 같은 정도로 영향받지는 않을 것이다. 어떤 도메인은 sloppy함을 처벌하고 신뢰와 책임을 요구한다. 하지만 많은 소프트웨어는 날것의 속도, 빠른 실험, 넓은 커버리지가 압도적으로 중요한 세계에 산다.
새로운 의존성
저자에게 가장 무서운 부분은 이 새 머신들에 대한 새로운 종류의 의존이다.
소프트웨어는 늘 도구에 의존했다. 저자는 컴파일러를 사야 했던 시절을 기억한다. 새 도구는 그 시절로 돌아간 듯한 감각을 준다 — 다만 이번엔 일회성 결제가 아니라 지속적 의존이다. 지갑에 대한 의존만이 아니라 인지적 의존이다.
코드베이스가 루프로 만들어지고, 루프로 리뷰되고, 루프로 패치되고, 루프로 살아 있다면 — 같은 등급의 시스템에 더 이상 접근하지 못하게 되었을 때 무엇이 남는가? 무역 제한이 가장 강한 모델에 대한 접근을 막아 버린다면? 비용 자체가 감당 불가능해진다면? 당신과 당신 팀이 기계 없이는 그 코드를 이해할 수 없게 된다면?
We may create codebases that are not merely hard to maintain by humans, but that assume machine participation as part of their maintenance model.
이미 일어나고 있는 일이다. 사람들은 자기가 완전히 설명하지 못하는 코드를 점점 더 머지한다. 이슈 보고서를 작성하거나 채팅에서 토론하는 능력을 잃어 가는 사람들도 있다 — 메시지를 기계에 통과시켜 다듬지 않고선 보내지 않는다. 점점 더 많은 사람이 LLM의 간접 매개를 거쳐 저자와 대화한다.
미래의 하네스 — Pi에 대한 자문
저자는 자기 회사 Pi의 위치도 다시 생각한다고 적는다. Pi는 신중했고, 그 신중함이 옳다고 본다. 모든 상호작용이 내가 따라갈 수 없는 변경을 가하는 통제 불가능한 머신 떼로 바뀌는 미래를 저자는 원하지 않는다. Pi가 그런 엔지니어링을 부추기는 도구가 되는 것도, Pi 자신이 그런 식으로 유지 불가능한 덩어리가 되는 것도 원하지 않는다.
그럼에도 Pi는 하네스이고, 하네스는 새로운 종류의 실험을 돌리는 사람들의 중심에 있다. 코딩 작업을 위한 작업 큐, 에이전트와 서브에이전트 오케스트레이션, 지속 가능한 세션 — 이런 것들이 점점 더 중요해진다. 루프를 맹목적으로 받아들이지 않더라도, 이 실험을 시작해야 한다. 이 미래를 경계 지어지고 살아남을 수 있게(bounded and survivable) 만들 방법을 이해해야 하기 때문이다.
루프를 통제한다는 것
저자는 결론에서 자기 위치를 분명히 한다.
As you can read from this post, I’m very uneasy about this future. Not cause of fear, but because of caution given experiences with this technology so far.
하네스 루프를 받아들인다는 건, 하네스가 작업의 끝을 결정한다는 뜻이다. agent loop에서는 모델이 결국 “끝"이라고 말하고 저자가 리뷰한다. 그 전에도 저자는 보통 함께 조타하고, 관여하며, 배우는 게 즐겁다. 하네스 운영 루프에서는 저자의 역할이 무엇이 될지 분명하지 않다. “끝” 신호조차 의미를 잃고, 또 다른 머신이 심사하기 위해 전달되는 메시지로 축약된다. 저자의 역할이 전령(messenger)으로 줄어든다.
오늘 저자는 그런 방식으로 만들어진 시스템에서 나오는 코드를 별로 좋아하지 않는다. AI 어시스턴트로 만들어진 너무 많은 소프트웨어와 상호작용하는 것도 즐겁지 않다. 루프는 강력하지만, 책임을 점점 더 제거하고 — 적어도 현재로서는 기계에 굴복하라고 부추긴다.
그럼에도 저자는 이 미래가 우리의 미래가 되리라는 데 의심이 없다. 이미 놀랍도록 작은 팀이 불가능한 속도로 만들어 내고 있고, 코드베이스는 점점 더 많은 머신으로만 진단할 수 있는 모호하고 혼란스러운 유기체로 변하고 있다 — 그 코드베이스들은 동시에 유용하고 엉망이다.
저자의 마지막 정리는 질문의 형태로 끝난다.
Maybe the question is that in a future of loops, how do we don’t abdicate judgment, how we can retain rules of good engineering, how we can ensure that responsible human can continue to supervise, how we need to re-think how we architect code to retain sanity along the way.
루프를 할지 말지가 아니라, 루프의 미래에서 판단을 어떻게 양도하지 않을지, 좋은 엔지니어링의 규칙을 어떻게 유지할지, 책임 있는 인간 감독을 어떻게 보존할지, 아키텍처를 어떻게 재구상해 sanity를 유지할지가 진짜 질문이다.
가장 흥미로운 지점
내가 가장 곱씹은 대목은 두 개다.
첫째는 “the harness just needs some signal” 단락이다. 루프가 작동하는 영역의 본질을 한 문장으로 정리한다 — 하네스는 유용한 신호 하나만 있으면 다음 반복을 굴린다. 객관적이거나 이진적일 필요가 없다. 이게 LLM judge를 다음 반복의 신호로 쓰는 패턴의 정당화이고, 동시에 한계의 정확한 위치 — 유용한 신호가 만들어지지 않는 영역(영속 코드의 invariant 설계, 시스템 전체 sanity 보존)에서는 루프가 작동하지 않는 이유도 같은 논리로 설명된다.
둘째는 “소프트웨어 = 유기체” 비유다. 진단·치료·안정화는 가능하지만 이해(comprehend)는 아닌 상태로 시스템 전체가 옮겨 간다는 진단. 저자가 모든 코드가 그런 식으로 저작되길 원하는가라고 자문하는 대목에서, 자기 회사 Pi의 신중함을 옹호하는 것과 그럼에도 실험은 해야 한다는 결론이 만나는 지점이 흥미롭다.
저자가 Flask·Jinja2·Sentry를 만든 시니어 엔지니어이고, 동시에 하네스를 만드는 회사(Pi)의 창립자라는 점이 이 글의 voice에 양가성을 부여한다. 옹호자도 아니고 비관자도 아닌, 이미 그 안에 있는 사람이 자기 행위의 의미를 자문하는 글이다. 같은 시기 발표된 Osmani·Firecrawl·Oracle·OpenAI·Fowler·DSDojo·mem0의 루프 엔지니어링 담론과 함께 읽으면, 루프 시대가 방법론(how to)에서 책임(what for) 단계로 넘어가는 변곡점에 와 있음이 분명해진다.
출처
Armin Ronacher, “The Coming Loop”, lucumr.pocoo.org, 2026년 6월 23일. 원문: https://lucumr.pocoo.org/2026/6/23/the-coming-loop/
원문에는 이미지가 포함되어 있지 않아 본 다이제스트는 텍스트만으로 정리했다.