루프 엔지니어링(Loop Engineering)이란 무엇인가: 에이전트에 지시하는 루프를 설계한다는 것

이 글은 3부작의 2편입니다. ① 하네스 엔지니어링이란 무엇인가 → ② 루프 엔지니어링이란 무엇인가(이 글) → ③ 그래서 어떻게 쓰이고 있는가

들어가며: 에이전트를 쥐고 있는 손

Claude Code나 Codex 같은 코딩 에이전트를 써 보셨다면 이 리듬에 익숙하실 겁니다. 무언가를 입력하고, 돌아온 것을 읽고, 다음 것을 입력합니다. 결과가 마음에 안 들면 다시 설명하고, 또 읽고, 또 입력합니다. 한 턴, 그리고 또 한 턴.

지난 2년간 코딩 에이전트에서 좋은 결과를 얻는 방법은 이 리듬을 잘 타는 것이었습니다. 좋은 프롬프트를 쓰고 충분한 맥락을 넘기는 일, 즉 프롬프트 엔지니어링과 컨텍스트 엔지니어링이 그 기술의 이름이었습니다. 그런데 이 구조에는 지워지지 않는 전제가 하나 깔려 있습니다. 에이전트는 도구이고, 사람이 그 도구를 처음부터 끝까지 손에 쥐고 있어야 한다는 것입니다. 에이전트가 아무리 빨라져도 다음 지시를 내리는 사람이 병목이 됩니다. 자리를 비우면 루프가 멈춥니다.

여기서 자연스러운 질문이 하나 나옵니다. 에이전트를 찌르는 그 사람이, 사람이 아니어도 된다면?

이 질문에 이름을 붙인 것이 루프 엔지니어링(loop engineering)입니다. 최근 두 달 사이 AI 코딩 담론에서 가장 빠르게 퍼진 말이고, 경쟁하는 두 AI 연구소의 엔지니어들이 거의 동시에 같은 이야기를 꺼내면서 주목받았습니다. 지금은 벤더가 자사 문서 제목에 이 용어를 쓰는 단계까지 왔습니다.

동시에 이 말은 그만큼 과열돼 있기도 합니다. 한국어 소개 글은 이미 여러 편 나왔는데 대부분 "루프란 무엇인가 + 부품 목록 + Claude Code 대응표"라는 같은 형태이고, 반대편에는 "엔지니어링이라는 말이 또 하나 늘었구나" 하는 냉소가 있습니다. 그 사이가 비어 있습니다.

이 글은 그 사이에 서려고 합니다. 루프 엔지니어링이 정확히 무엇인지, 무엇으로 만드는지, 하나의 루프가 실제로 어떻게 생겼는지를 먼저 보고, 그다음에 이 개념을 둘러싼 이야기 중 무엇이 실물이고 무엇이 나중에 붙은 서사인지를 구분합니다. 결론을 미리 말하면, 실물은 생각보다 단단하고 서사는 생각보다 허술합니다.

세 사람이 같은 말을 했다

루프 엔지니어링 담론은 세 사람의 발언 위에 서 있습니다. 순서대로 보겠습니다.

Peter Steinberger. 개인 AI 비서 OpenClaw를 만들었고 2026년 2월 OpenAI에 합류한 개발자입니다. 2026년 6월 7일 X에 이렇게 썼습니다.

Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

이제 코딩 에이전트에 직접 프롬프트를 쓰지 말고, 에이전트에 프롬프트를 쓰는 루프를 설계하라는 것입니다. 이 문장이 담론의 발화점이 됐습니다.

한 가지 사소하지만 온도를 정확히 맞춰 주는 사실이 있습니다. 널리 인용되는 판본은 대개 "You shouldn't be..."부터 시작하는데, 원문에는 그 앞에 "Here's your monthly reminder that", 즉 "이번 달 정기 알림입니다"가 붙어 있습니다. 새로운 선언이 아니라 전에도 여러 번 했던 말을 또 한 것이라는 뜻입니다. 이 개념은 어느 날 선포된 것이 아니라, 한동안 반복되던 이야기가 이름을 얻은 쪽에 가깝습니다.

Boris Cherny. Anthropic에서 Claude Code를 이끄는 사람입니다. 2026년 6월 2일 공개된 대담에서 자신의 작업 방식이 또 한 단계 올라간 것 같다는 취지로 말했습니다. 이제 자신은 Claude에 직접 프롬프트를 쓰지 않고, 루프들이 돌면서 Claude에 프롬프트를 쓰고 무엇을 할지 판단하며, 자기 일은 루프를 짜는 것이라는 이야기였습니다. 앞으로 몇 달 안에 보게 될 전환이라고 덧붙였습니다.

여기서 한 가지 짚어 둘 것이 있습니다. 이 대담은 공식 트랜스크립트가 공개되지 않았고, 시중에 도는 인용문은 자동 자막에서 나온 것입니다. 그리고 실제 발언에는 "I think", "kind of" 같은 완충 표현이 여러 번 들어 있는데, 인용될 때마다 그 표현들이 사라집니다. 진행 중인 변화에 대한 한 엔지니어의 조심스러운 관찰이, 완성된 교리의 선포처럼 전해지는 것입니다. 그래서 이 글은 그의 발언을 축자 인용하지 않고 취지만 옮깁니다.

Addy Osmani. 2026년 6월 7일 자신의 블로그에 "Loop Engineering"이라는 글을 올렸습니다. 앞의 두 발언을 인용하며 시작해서, 그것이 실제로 무슨 뜻인지를 아키텍처 수준으로 풀어냅니다. 영어권에서 이 개념을 가장 널리 읽히게 만든 글이고, 6월 22일 O'Reilly Radar에 다시 실리며 도달 범위가 한 번 더 넓어졌습니다.

여기서 진짜 주목할 만한 지점은 발언의 내용이 아니라 발언자들의 소속입니다. Steinberger는 OpenAI에 있고, Cherny는 Anthropic에서 Claude Code를 만듭니다. 경쟁하는 두 연구소의 사람이 같은 시기에 같은 결론에 도달했습니다. 한 회사가 자기 제품을 팔기 위해 밀어붙이는 이야기였다면 이 정도 무게를 갖지 못했을 것입니다. 서로 다른 곳에서 같은 것을 발견했다는 사실이, 이 개념을 그냥 유행어로 넘기기 어렵게 만듭니다.

루프 엔지니어링이란 무엇인가

Osmani의 정의는 첫 문장에 있습니다.

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

에이전트에 프롬프트를 넣는 사람, 즉 자기 자신을 대체하는 것입니다. 그 일을 대신 수행하는 시스템을 설계하는 것이라고 그는 덧붙입니다. 루프는 재귀적 목표(recursive goal)로 생각할 수 있습니다. 목적을 정의해 두면 AI가 완료될 때까지 반복하는 구조입니다.

도입부에서 본 리듬과 대조해 보면 차이가 분명해집니다. 기존 방식에서 사람이 하던 일은 사실 "코딩"이 아니었습니다. 다음에 무엇을 할지 정하고, 돌아온 것이 쓸 만한지 판단하고, 아니면 다시 시키는 일이었습니다. 루프 엔지니어링은 그 일을 목록으로 만들어 시스템에 넘깁니다. 일감을 찾아내고, 나눠 주고, 결과를 검사하고, 무엇이 끝났는지 적어 두고, 다음에 무엇을 할지 결정하는 작은 시스템을 만든 다음, 사람 대신 그 시스템이 에이전트를 찌르게 하는 것입니다.

그래서 이름이 루프입니다. 사람이 매번 시작 버튼을 눌러 주는 일회성 실행이 아니라, 스스로 다음 회차를 시작하는 구조이기 때문입니다.

한 가지 오해를 미리 정리해 둘 필요가 있습니다. 이것이 프롬프트 엔지니어링을 폐기한다는 뜻은 아닙니다. Osmani 자신이 글 말미에서 명시적으로 물러섭니다. 루프를 만들되 에이전트에 직접 프롬프트를 쓰는 것도 여전히 효과적이며, 균형을 찾는 문제라는 것입니다. 바뀐 것은 프롬프트의 유효성이 아니라 최적화의 단위입니다. 한 번의 출력이 아니라 반복해서 도는 시스템 전체가 대상이 됩니다. 루프 안에서도 프롬프트는 여전히 핵심 부품이고, 조악한 지시로 짠 루프는 조악하게 돕니다.

그리고 Osmani는 전도사가 아닙니다. 같은 글 첫 단락에서 이렇게 씁니다.

However, its still early, I'm skeptical and you absolutely have to be careful about token costs

아직 이르고, 자신은 회의적이며, 토큰 비용을 정말 조심해야 한다는 것입니다. 이 개념을 가장 널리 퍼뜨린 글이 첫 단락부터 유보를 답니다. 그 유보는 2차 소개 글로 넘어오면서 대부분 사라집니다.

무엇으로 만드나

Osmani는 루프에 다섯 개의 부품과 기억할 장소 하나가 필요하다고 정리합니다.

• Automations — 일정에 따라 스스로 발화해서 발굴과 분류(triage)를 수행하는 것.
• Worktrees — 두 에이전트가 병렬로 일할 때 서로의 파일을 밟지 않도록 격리하는 것.
• Skills — 에이전트가 없으면 그냥 추측해 버릴 프로젝트 지식을 적어 두는 것.
• Plugins와 connectors — 이미 쓰고 있는 도구에 에이전트를 연결하는 것.
• Sub-agents — 하나가 아이디어를 내고 다른 하나가 그것을 검사하게 하는 것.

여섯 번째가 메모리입니다. 마크다운 파일이든 Linear 보드든, 단일 대화 바깥에 살면서 무엇이 끝났고 무엇이 남았는지를 담는 장소입니다. Osmani는 이것이 너무 시시해서 중요해 보이지 않는다고 인정하면서도, 장기 실행 에이전트가 의존하는 바로 그 요령이라고 말합니다. 모델은 실행 사이에 모든 것을 잊으므로 메모리는 컨텍스트가 아니라 디스크에 있어야 합니다. 그의 표현이 이 발상을 한 문장에 담습니다.

The agent forgets, the repo doesnt.

에이전트는 잊지만 저장소는 잊지 않는다는 것입니다.

이 여섯 가지가 두 제품에 어떻게 대응되는지는 이미 여러 한국어 소개 글이 다룬 내용이므로 표로 압축하고 넘어가겠습니다. Osmani가 정리한 대응 관계입니다.

이름은 조금씩 다르지만 능력은 같은 것이라고 Osmani는 말합니다. 그리고 여기서 그가 던지는 관찰이 이 표 자체보다 중요합니다. 어느 도구를 쓸지 논쟁하는 대신, 어느 쪽에 앉아 있든 작동하는 루프를 설계하면 된다는 것입니다.

다섯 부품 중에서 특히 눈여겨볼 것은 sub-agents입니다. Osmani는 루프에서 구조적으로 가장 유용한 것이 단연 쓰는 쪽과 검사하는 쪽을 분리하는 일이라고 말합니다. 코드를 쓴 모델은 자기 숙제를 채점할 때 너무 관대하다는 것입니다. 이 지점이 2편의 주제와 곧바로 이어지는데, 일단 여기서는 이것이 다섯 부품 중 하나로 제안되었다는 사실만 기록해 둡니다.

하나의 루프는 실제로 어떻게 생겼나

부품 목록만 봐서는 감이 잘 오지 않습니다. Osmani가 자신이 계속 쓰고 있다고 밝힌 실제 루프 하나를 따라가 보겠습니다. 여섯 부품이 어떻게 맞물리는지가 여기서 드러납니다.

아침마다 automation 하나가 저장소에서 돕니다. 사람이 켜지 않아도 정해진 시각에 발화합니다. 이것이 루프의 심장이고, 이게 없으면 그냥 "예전에 한 번 실행해 본 것"이지 루프가 아닙니다.

그 automation의 프롬프트는 triage 스킬을 호출합니다. 여기서 스킬이 왜 필요한지가 보입니다. 매번 거대한 지시문 덩어리를 일정에 복사해 넣는 대신, 스킬 이름 하나를 부르는 것입니다. 그 스킬은 어제의 CI 실패, 열린 이슈, 최근 커밋을 읽고 발견한 것들을 마크다운 파일이나 Linear 보드에 적습니다. 이게 메모리입니다.

해 볼 만한 발견 하나하나에 대해, 격리된 worktree를 열고 서브에이전트를 보내 수정안을 쓰게 합니다. worktree가 여기서 필요한 이유는 단순합니다. 여러 에이전트가 동시에 같은 파일을 건드리면 서로를 밟기 때문입니다. Osmani의 비유대로, 두 엔지니어가 서로 얘기도 안 하고 같은 줄을 커밋하는 것과 정확히 같은 골칫거리입니다.

그리고 두 번째 서브에이전트가 그 수정안을 프로젝트 스킬과 기존 테스트에 비추어 검토합니다. 앞에서 말한 "쓰는 쪽과 검사하는 쪽의 분리"가 실제로 적용되는 자리입니다.

connector가 PR을 열고 티켓을 갱신합니다. 루프가 파일 시스템만 볼 수 있다면 작은 루프입니다. connector 덕분에 루프는 "이렇게 고치면 됩니다"라고 말하는 데서 그치지 않고, 실제로 PR을 열고 CI가 초록이 되면 채널에 알립니다.

루프가 감당하지 못하는 것은 triage inbox로 들어와 사람을 기다립니다.

상태 파일이 이 전체의 척추입니다. 무엇을 시도했고, 무엇이 통과했고, 무엇이 아직 열려 있는지를 기억하므로, 내일 아침의 실행이 오늘 멈춘 자리에서 이어집니다.

Osmani가 이 예시 끝에 붙인 문장이 이 개념의 핵심을 가장 짧게 요약합니다. 방금 무슨 일이 일어났는지 보라는 것입니다. 당신은 이것을 한 번 설계했을 뿐이고, 그 단계들 중 어느 것에도 프롬프트를 쓰지 않았다는 것입니다.

왜 지금인가

Osmani가 놀랐다고 밝힌 지점이 이 개념을 유행어 이상으로 만듭니다. 이것이 더 이상 도구의 문제가 아니라는 것입니다.

A year ago if you wanted a loop you wrote a pile of bash and you maintained that pile forever and it was yours and only yours. Now the pieces just ship inside the products.

1년 전에 루프를 원했다면 bash 스크립트 더미를 직접 쓰고 영원히 유지보수해야 했으며, 그것은 오롯이 자기 것이었습니다. 지금은 그 부품들이 제품 안에 그냥 들어 있습니다.

이 주장은 확인 가능합니다. Claude Code의 /goal은 완료 조건을 걸어 두면 매 턴이 끝날 때마다 별도의 빠른 모델이 조건 충족 여부를 판정하고, 충족되지 않으면 제어를 사용자에게 돌려주지 않고 다음 턴을 시작하는 기능입니다. v2.1.139 이상에서 동작합니다. /loop은 프롬프트를 주기적으로 반복 실행하는데, 간격을 생략하면 Claude가 매 반복마다 1분에서 1시간 사이의 지연을 스스로 고르고 ScheduleWakeup을 stop: true로 호출해 루프를 스스로 끝낼 수도 있습니다(v2.1.202 이상). 이 문서들은 2026년 7월 15일 기준으로 유효합니다. 다만 Claude Code는 활발히 변하는 중이므로 버전과 날짜를 함께 기억해 두는 편이 좋습니다.

용어가 굳어지고 있다는 더 강한 신호는 벤더 쪽에서 나왔습니다. 2026년 6월 30일, Anthropic이 자사 블로그에 "Loop engineering: Getting started with loops"라는 제목의 글을 올렸습니다. 벤더가 자기 제품 문서의 제목에 이 용어를 채택했다는 것은, 이것이 소셜 미디어의 유행어 단계를 지나 실무 어휘로 이동하고 있다는 뜻입니다. 그 글은 루프를 이렇게 정의합니다.

agents repeating cycles of work until a stop condition is met

정지 조건이 충족될 때까지 작업 사이클을 반복하는 에이전트. 정의 자체가 정지 조건(stop condition)을 중심에 놓는다는 점을 기억해 두시기 바랍니다.

그런데 그 사다리는 아무도 그린 적 없다

여기까지가 실물입니다. 이제 서사를 보겠습니다.

루프 엔지니어링을 소개하는 글은 거의 예외 없이 다음과 같은 계보를 제시합니다. 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로, 다시 실행 환경을 설계하는 하네스(harness) 엔지니어링으로, 그리고 이제 루프 엔지니어링으로. 최적화의 단위가 한 층씩 올라간다는 깔끔한 4단 사다리입니다. 한국어 소개 글 다수가 이것을 확정된 사실로, 출처 없이 한 문장에 담아 서술합니다.

문제는 이 사다리를 그린 1차 소스가 없다는 것입니다.

Osmani의 루프 글과 하네스 글을 모두 뒤져도 그런 4단계 진행은 나오지 않습니다. 그가 하는 유일한 계층 주장은 2단이고, 공간 비유입니다.

Loop engineering sits one floor above the harness.

루프 엔지니어링이 하네스보다 한 층 위에 있다는 것. 그리고 하네스 엔지니어링을 "이것의 사촌(the cousin of this)"이라고 부릅니다. 인접한 두 항 사이의 관계는 말하지만, 이름 붙은 4단계 진화는 말한 적이 없습니다. 그 사다리는 하류 해설자들이 만든 것이고, 흥미롭게도 그들 중 누구도 그것을 Osmani에게 귀속하지 않습니다.

날짜를 따라가 보면 왜 사다리가 아닌지가 더 분명해집니다. 바로 아래 층인 "하네스"라는 말만 봐도 그렇습니다. 이 용어는 어느 날 누가 선포한 게 아니라, 에세이가 나오기 한참 전부터 여러 저장소의 커밋 메시지와 디렉터리 이름에서 먼저 굳어지고 있었습니다. 여러 실무자가 비슷한 시기에 각자 자기 자리에서 같은 필요를 느껴 이름을 붙였고, 서로를 거의 인용하지 않습니다. (이 계보는 1편에서 자세히 다뤘습니다.) 한 사람이 층층이 쌓아 올린 사다리가 아니라, 동시다발적인 침전에 가깝습니다.

결정적으로, 계층 관계 자체에 합의가 없습니다. 2026년 7월 4일 Lilian Weng이 하네스 엔지니어링에 관한 글을 냈는데, 거기서 하네스 엔지니어링이 "workflow design (e.g. loop engineering), evaluation, permission controls, and persistent state management"를 포함한다고 씁니다. 루프 엔지니어링이 하네스 엔지니어링의 하위 부품이라는 것입니다. Osmani가 "한 층 위"라고 한 것과 정확히 반대입니다. 참고로 Weng의 언급은 발전되지 않은 괄호 하나이고 Osmani를 참조하지도 않습니다. 즉 두 사람이 논쟁을 벌인 것이 아니라, 애초에 합의된 층위가 없는 것입니다.

이 사실을 어떻게 받아들여야 할까요. 사다리를 잃으면 이야기가 초라해지는 것처럼 보이지만, 실은 반대입니다. 여러 사람이 서로 독립적으로 같은 결론에 도달했다는 것은, 한 사람이 프레임워크를 발명했다는 것보다 훨씬 강한 증거입니다. 앞에서 본 것처럼 경쟁 연구소의 두 사람이 같은 말을 하고 있다는 사실도 같은 종류의 증거입니다. 깔끔한 도표를 버리면 잃는 것은 도식의 정갈함이고, 얻는 것은 주장의 힘입니다.

그리고 이것이 이 개념을 대하는 올바른 태도를 알려 줍니다. 루프라는 실물은 단단합니다. 벤더 문서로 확인되고, 제품 안에 들어 있고, 경쟁사끼리 수렴합니다. 반면 그것을 감싼 계보 서사는 나중에 붙은 것이고 아직 굳지 않았습니다. 둘을 구분하면 이 개념을 진지하게 다루면서도 과열되지 않을 수 있습니다.

왜 사람은 아직 루프 안에 있나

루프가 스스로 돈다면 사람은 어디에 있어야 할까요. 이 질문에 가장 정돈된 답을 내놓은 것은 Andrew Ng입니다.

먼저 정확히 해 둘 것이 있습니다. Ng는 루프 엔지니어링을 정의하지 않았습니다. 2026년 6월 26일 The Batch에 실린 그의 레터는 이 용어를 딱 한 번, 따옴표 안에, 자신이 반응하는 유행어로만 씁니다. Boris Cherny와 Peter Steinberger의 언급이 소셜 미디어에서 퍼지면서 뜨거운 유행어가 됐다는 문장입니다. 그리고 곧바로 "my 3 key loops", 즉 자기 자신의 세 루프로 화제를 옮깁니다. 그의 3중 루프를 루프 엔지니어링의 정본 정의처럼 소개하는 글이 많은데, 두 개는 다른 이야기입니다.

그의 세 루프는 0-to-1 제품을 만드는 과정을 설명합니다.

• Agentic coding loop — 가장 빠른 루프입니다. 몇 분 단위로 돕니다. 코딩 에이전트가 새 버전을 빌드하고 테스트합니다.
• Developer feedback loop — 수십 분에서 몇 시간 사이의 간격으로 돕니다. 개발자가 결과물을 써 보고 방향을 제시하면 그 판단이 명세와 평가 기준에 반영됩니다.
• External feedback loop — 가장 느립니다. 몇 시간이 걸리는 경우는 드물고 며칠, 때로는 몇 주가 걸립니다. 알파 테스터나 실제 사용자의 반응이 제품 비전을 바꿉니다.

여기서 자주 유실되는 것이 있습니다. 세 루프는 나란히 놓인 세 개의 상자가 아니라 중첩(nested)되어 있습니다. 명세(spec)가 세 루프를 잇는 결합 인터페이스입니다. 외부 피드백이 개발자의 비전을 바꾸고, 비전이 명세와 평가 기준으로 구체화되고, 그 기준이 코딩 에이전트를 움직입니다. 느린 루프가 한 번 도는 동안 빠른 루프는 여러 번 돕니다. 대부분의 2차 해설이 세 상자를 평면에 나열하면서 이 중첩을, 즉 논지의 핵심을 잃습니다.

그렇다면 인간은 왜 남아 있어야 하는가. Ng는 그 이유를 "맥락 우위(context advantage)"로 설명합니다.

Many people describe this human contribution as "taste," but I prefer to think of it as humans having a context advantage, since that gives us a clearer path to helping AI systems get better.

많은 사람이 이 인간의 기여를 "취향(taste)"이라고 부르지만, 자신은 그것을 인간이 가진 맥락 우위로 생각하는 편을 선호한다는 것입니다. 그래야 AI 시스템을 개선할 더 명확한 경로가 보이기 때문이라고 그는 덧붙입니다.

이 전환이 왜 중요한지는 조금 생각해 볼 만합니다. "취향"이라고 부르면 그것은 타고난 것, 설명할 수 없는 것, 따라서 개선하거나 시스템에 주입할 수 없는 것이 됩니다. "맥락 우위"라고 부르면 그것은 지식의 격차가 되고, 격차는 원리적으로 메울 수 있는 것이 됩니다. Ng는 자동화할 수 없는 이유를 조건문으로 세웁니다. 인간이 AI가 모르는 무언가를 아는 한, 그 지식을 시스템에 주입하기 위해 human-in-the-loop이 필요하다는 것입니다.

이 조건문은 정직합니다. 스스로 반증 가능하기 때문입니다. 그의 논리대로라면 격차가 사라지는 순간 그 근거도 사라집니다. Ng 본인도 "현재의 AI 시스템(current AI systems)"이라고 시간 범위를 걸어 두고, 격차가 좁혀질 수 있음을 인정합니다.

Osmani도 7월 9일 후속 글에서 같은 문제를 다른 각도로 다룹니다. 그는 루프를 안팎으로 나눕니다. 에이전트가 소유하는 내부 루프는 조사하고, 계획을 실행하고, 결과를 검증합니다. 사람이 소유하는 외부 루프는 품질과 판정과 책임입니다. 그리고 그 경계에서 벌어지는 일을 이렇게 씁니다. 증거가 경계를 넘어오고, 그 결과에 책임지는 인간이 증거를 보고 진행 여부를 결정한다는 것입니다. 그가 이 구조의 이유로 드는 문장은 짧고 정확합니다.

The agent can ship more than you can review.

에이전트는 당신이 리뷰할 수 있는 것보다 많이 만들어 낼 수 있습니다. 이 비대칭이 루프 엔지니어링의 진짜 제약 조건입니다. 도구가 아니라 사람의 리뷰 대역폭이 천장입니다.

얼마나 비싼가

루프에는 값이 붙습니다. 그리고 그 수치는 벤더 자신이 공개했습니다. Anthropic이 자사의 멀티에이전트 리서치 시스템을 설명한 글에 이런 문장이 있습니다.

In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.

자사 데이터에서 에이전트는 채팅 대비 약 4배, 멀티에이전트 시스템은 채팅 대비 약 15배의 토큰을 쓴다는 것입니다.

이 15배라는 숫자는 널리 인용되는데, 인용될 때 거의 항상 중간 단계가 생략됩니다. 단일 에이전트가 이미 4배입니다. 즉 멀티에이전트가 단일 에이전트 대비 치르는 추가 비용은 15배가 아니라 약 3.75배입니다. 많은 인용이 15배를 "에이전트로 넘어가는 비용"처럼 암시하는데, 정확하지 않습니다. Anthropic은 이 수치를 자랑이 아니라 비용 경고로 제시합니다. 토큰 값을 정당화할 만큼 가치 있는 과제에만 멀티에이전트가 경제적이라는 논지입니다.

Osmani가 첫 단락에서 토큰 비용을 조심하라고 한 것도 같은 맥락입니다. 그는 토큰이 넉넉한 사람과 궁한 사람 사이에 사용 패턴이 크게 갈린다는 점을 지적합니다.

여기서 한 가지 불편한 관찰을 덧붙일 필요가 있습니다. 6월 24일 The Register가 이 개념을 다루면서 인센티브 문제를 제기했습니다. 루프를 옹호하는 사람들이 토큰 소비로 이익을 보는 쪽에 서 있지 않으냐는 것입니다. Ed Zitron은 OpenAI가 자기 자신에게 토큰 비용을 청구하느냐고 되물었고, 월 단위로 막대한 토큰을 태울 수 있는 위치에 있는 사람이 자율 루프를 옹호하는 것은 편리한 일이라고 꼬집었습니다.

이 비판을 어떻게 받아들일지는 각자의 몫입니다. 다만 기술적 논증만 보고 경제적 위치를 보지 않는 것은 균형이 아닙니다. 동시에, 인센티브가 있다는 것이 주장이 틀렸다는 증명도 아닙니다. 두 가지를 다 기억해 두면 됩니다.

정리, 그리고 남는 질문

지금까지의 내용을 정리하면 이렇습니다.

실물. 루프 엔지니어링은 에이전트에 프롬프트를 넣는 사람, 즉 자기 자신을 시스템으로 대체하는 일입니다. 다섯 개의 부품(automations, worktrees, skills, connectors, sub-agents)과 대화 바깥에 사는 메모리 하나로 구성됩니다. 이 부품들은 이제 Codex와 Claude Code 양쪽 제품 안에 들어 있고, 벤더가 문서 제목에 용어를 채택할 만큼 굳어지고 있습니다. 경쟁 연구소의 엔지니어들이 독립적으로 같은 결론에 도달했습니다.

서사. 프롬프트에서 컨텍스트로, 하네스로, 루프로 이어지는 4단 사다리는 어느 1차 소스에도 없습니다. 그것은 나중에 해설자들이 만든 합성물입니다. 실제로는 여러 사람이 비슷한 시기에 각자 이름을 붙였고, 조어자로 지목된 사람은 스스로 조어를 부인하며, 층위 관계에는 지금도 합의가 없습니다.

사람의 자리. Ng의 맥락 우위는 인간이 AI가 모르는 것을 아는 동안만 유효한 조건부 논거입니다. Osmani의 표현대로 에이전트는 사람이 리뷰할 수 있는 것보다 많이 만들어 냅니다. 그 비대칭이 실질적 천장입니다.

비용. 에이전트는 채팅 대비 4배, 멀티에이전트는 15배의 토큰을 씁니다. 벤더 자신의 수치입니다.

그런데 이 글은 가장 중요한 질문에 아직 답하지 않았습니다. 루프의 다섯 부품 중 하나가 sub-agents였고, 그 이유는 쓰는 쪽과 검사하는 쪽을 분리하기 위해서였습니다. Anthropic의 정의도 정지 조건을 중심에 놓았습니다. 즉 루프가 성립하려면 누군가 "이제 됐다"고 판정해야 합니다.

그 판정을 누가 하는가. 무엇을 근거로 하는가. 그 판정을 믿고 자리를 비워도 되는가. 여기에 답하지 못하면 루프는 잘못된 행동을 빠르고 비싸게 반복하는 장치가 됩니다.

이 질문에는 최근 몇 달 사이 쌓인 상당한 양의 증거가 있습니다. 자기 코드를 스스로 고쳐 SWE-bench 점수를 두 배 넘게 끌어올린 시스템도 있고, 에이전트가 스스로 작성한 스킬이 오히려 성능을 떨어뜨린다는 통제된 측정도 있습니다. 검증이 생성보다 쉽다는 오래된 직관이 지금 뒤집히고 있다고 주장하는 2026년 논문도 있습니다. 그리고 이 판정 문제를 Claude Code와 Codex가 정확히 반대 방향으로 풀었다는 사실도 있습니다.

다음 글에서는 그것을 다룹니다. 루프는 언제 닫히는가, 그래서 실제로 어떻게 쓰는가.

이 글에서 다루지 못한 주제

이 글은 루프 엔지니어링의 정의와 구성, 그리고 그것을 둘러싼 계보 서사의 실제를 다뤘습니다. 다음 주제들은 2편에서 다루기 위해 의도적으로 미뤘습니다.

• 검증자의 구조와 그 한계. Claude Code /goal의 평가자가 어떤 증거를 볼 수 있고 볼 수 없는지, Codex가 같은 문제를 어떻게 다르게 풀었는지.
• 자기 개선 루프가 실제로 작동한 사례와 그 조건. 그리고 그 조건이 없을 때의 측정 결과.
• 루프의 자율성 범위를 정하는 기준. 얼마나 오래 자리를 비워도 되는지를 무엇으로 판단하는가.
• 루프의 생산성 효과에 대한 실측 데이터와 그 해석의 어려움.