원문 제목: Loop Engineering.
원문 저자: Addy Osmani
편역: Peggy, BlockBeats

편집자 주: AI 코딩 에이전트의 사용 방식은 '사람이 수동으로 프롬프트를 작성하고, 단계별로 작업을 진행하는 방식'에서 '사람이 루프를 설계하여 시스템이 지속적으로 에이전트를 조율하도록 하는 방식'으로 변화하고 있습니다. Addy Osmani가 말하는 Loop Engineering(루프 엔지니어링)의 핵심은 작업을 자동으로 발견하고, 할당하며, 결과를 확인하고, 진행 상황을 기록한 후 다음 단계를 결정하는 워크플로우를 구축하는 것입니다.

이 루프는 대략 다섯 가지 모듈로 구성됩니다: Automations(정기적인 작업 발견 및 트라이지), Worktrees(여러 병렬 개발 환경 격리), Skills(프로젝트 지식 및 팀 관행 축적), Plugins/Connectors(GitHub, Linear, Slack, 데이터베이스 등 실제 도구 연동), Sub-agents(실행자와 검토자 분리). 여기에 Markdown 파일이나 Linear 보드와 같은 외부 메모리 레이어를 추가하여 상태와 진행 상황을 저장합니다.

기사는 Loop Engineering의 의미가 단순히 'AI가 몇 번 더 반복하게 하는 것'이 아니라, 엔지니어의 판단력을 시스템 설계 단계에 선제적으로 배치하는 것이라고 강조합니다. 루프는 개발자의 작업 레버리지를 크게 확대할 수 있지만, 검증, 이해, 판단을 대체하지는 않습니다. 실제 위험은 루프를 사용하는 데 있는 것이 아니라, 루프를 코드와 시스템 이해를 회피하는 핑계로 삼는 데 있습니다. 미래 AI 코딩 협업의 핵심 역량은 더 이상 좋은 프롬프트 하나를 작성하는 것이 아니라, 신뢰할 수 있고 검증 가능하며 지속적으로 운영 가능한 에이전트 워크플로우를 설계하는 것이 될 것입니다.

다음은 원문입니다:

Loop engineering(루프 엔지니어링)은 '에이전트에게 프롬프트를 작성하는 사람'으로서의 당신의 역할을 대체하고 있습니다. 당신은 에이전트를 대신해 프롬프트를 작성해 줄 시스템을 설계하게 됩니다. 여기서 loop(루프)는 재귀적 목표로 이해할 수 있습니다. 당신이 목적을 정의하면, AI는 작업이 완료될 때까지 지속적으로 반복합니다. 이는 대략 다섯 가지 구성 요소로 이루어져 있으며, Claude Code와 Codex는 현재 이 다섯 가지 구성 요소를 모두 갖추고 있습니다.

저는 이것이 미래에 우리가 코딩 에이전트와 협업하는 방식이 될 수 있다고 믿습니다. 하지만 아직 초기 단계이며, 저도 회의적인 시각을 유지하고 있습니다. 토큰 비용에 대해 신중해야 합니다. 사용 패턴에 따라 비용 차이가 매우 클 수 있기 때문입니다. 특히 당신이 '토큰이 풍부한' 환경인지 '토큰이 부족한' 환경인지에 따라 달라집니다. 또한 품질이 저하되지 않도록 하는 메커니즘이 필요합니다. 'AI 쓰레기 산출물'(slop)에 대한 우려도 타당합니다. 그럼에도 불구하고, 이것이 무엇인지 살펴보겠습니다.

@steipete가 최근에 이런 말을 했어요: "더 이상 코딩 에이전트에게 프롬프트를 작성해서는 안 됩니다. 대신 에이전트를 프롬프트할 루프를 설계해야 합니다." 비슷하게, Anthropic의 Claude Code 책임자 @bcherny도 이렇게 말했죠: "저는 이제 Claude에게 프롬프트를 더 이상 하지 않습니다. 실행 중인 루프들이 Claude를 프롬프트하고, 스스로 다음에 무엇을 할지 판단합니다. 제 일은 그 루프를 작성하는 것입니다."

그렇다면, 이게 도대체 무슨 뜻일까요?

지난 약 2년 동안, 코딩 에이전트에게 무언가를 시키려면 기본적으로 좋은 프롬프트를 작성하고 충분한 컨텍스트를 제공하는 방식이었습니다. 한 문장을 입력하고, 결과를 읽고, 다음 문장을 입력하는 식이었죠. 에이전트는 도구였고, 당신은 그 도구를 계속 쥐고 라운드마다 밀어붙였습니다. 이 단계는 어느 정도 끝났고, 적어도 어떤 사람들은 그것이 곧 끝날 것이라고 생각합니다.

이제 당신이 구축하는 것은 작은 시스템입니다. 스스로 작업을 찾고, 할당하고, 결과를 확인하고, 완료를 기록한 다음, 다음에 무엇을 할지 결정합니다. 즉, 당신이 직접 반복해서 프롬프트하는 대신, 시스템이 에이전트를 구동하도록 하는 것입니다. 저는 이전에 그 '근친'인 agent harness engineering(에이전트 실행 프레임워크 엔지니어링), 즉 단일 에이전트를 위한 실행 환경 구축과 factory model(팩토리 모델), 즉 소프트웨어를 구축하는 시스템에 대해 썼습니다. Loop engineering은 harness보다 한 단계 위에 있습니다. harness와 비슷하지만 타이머에 따라 실행되고, 작은 도우미를 생성하며, 스스로 피드백을 받습니다.

놀랍게도, 이제 이것은 더 이상 '도구 수준'의 문제가 아닙니다. 1년 전만 해도 loop를 원한다면 수많은 bash 스크립트를 작성하고 영원히 유지보수해야 했습니다. 그것은 당신만의 것이었고, 오직 당신만의 것이었죠. 이제 이러한 구성 요소는 제품에 직접 내장되어 있습니다. Steinberger가 나열한 기능은 거의 Codex 앱에 일대일로 대응되며, Claude Code에도 거의 동일하게 대응됩니다. 일단 그 형태가 동일하다는 것을 깨닫게 되면, 어떤 도구를 사용할지 고민하는 대신 loop를 설계하게 됩니다. 어떤 도구에 앉아 있든 계속 작동할 수 있는 loop를 말이죠.

다섯 가지 구성 요소와 몇 가지 설명

loop에는 다섯 가지가 필요하며, 정보를 기억할 장소가 하나 더 필요합니다. 먼저 나열하고, 하나씩 대응시켜 보겠습니다.

첫째, Automations(자동화 작업): 일정에 따라 트리거되어 자동으로 발견 및 분류를 수행합니다.

둘째, Worktrees(작업 트리): 두 개의 병렬 작업 에이전트가 서로의 파일을 건드리지 않도록 합니다.

셋째, Skills(스킬): 프로젝트 지식을 문서화하여 에이전트가 매번 추측에 의존하지 않도록 합니다.

넷째, Plugins and connectors(플러그인 및 커넥터): 에이전트가 이미 사용 중인 도구에 연결할 수 있도록 합니다.

다섯째, Sub-agents(서브 에이전트): 하나는 솔루션을 제안하고, 다른 하나는 그 솔루션을 검토합니다.

그리고 여섯 번째 요소: memory(메모리). 이는 Markdown 파일일 수도 있고, Linear 보드일 수도 있으며, 단일 대화와 독립적으로 '완료된 작업'과 '다음 작업'을 저장할 수 있는 모든 공간입니다. 너무 단순해서 중요해 보이지 않을 수 있지만, 모든 장기 실행 에이전트가 의존하는 동일한 기술입니다. long-running agents에서도 자세히 설명했듯이, 모델은 실행 사이마다 모든 것을 잊어버리므로 메모리는 컨텍스트가 아닌 디스크에 저장되어야 합니다. 에이전트는 잊어버리지만, 코드 저장소는 그렇지 않습니다.

이제 두 제품 모두 이 다섯 가지 구성 요소를 갖추고 있습니다.

명칭은 일부 다르지만, 기능은 본질적으로 동일합니다. 아래에서 하나씩 설명하겠습니다. 솔직히 말하면, 루프가 안정적으로 작동하느냐, 아니면 조용히 곳곳에서 새느냐는 모두 세부 사항에 달려 있기 때문입니다.

Automations: 이것이 루프의 심장입니다

Automations는 루프를 단순히 수동으로 한 번 실행한 일회성 작업이 아닌, 진정한 루프로 만드는 요소입니다. Codex 앱에서는 Automations 탭에서 자동화 작업을 생성하고, 프로젝트, 실행할 프롬프트, 실행 빈도, 그리고 로컬 checkout에서 실행할지 백그라운드 worktree에서 실행할지 선택할 수 있습니다. 문제를 발견한 실행 결과는 Triage inbox(분류 받은 편지함)로 전송되고, 문제가 없는 실행은 자동으로 보관됩니다. 이 점은 괜찮습니다. OpenAI 내부에서도 이를 사용하여 지루하지만 필수적인 작업, 예를 들어 일일 이슈 분류, CI 실패 요약, 커밋 브리핑 작성, 지난주에 누군가가 도입한 버그 추적 등을 수행합니다. 자동화 작업은 skill을 호출할 수도 있으므로, 반복 실행되는 작업을 유지 관리 가능하게 만들 수 있습니다. 즉, 나중에 아무도 업데이트하지 않을 계획된 작업에 긴 설명문을 붙여넣는 대신, $skill-name을 트리거하는 방식입니다.

Claude Code도 동일한 효과를 낼 수 있습니다. 단지 접근 방식이 다를 뿐입니다. 스케줄링과 훅(hooks)을 통해 구현됩니다. `/loop`를 사용하면 고정된 간격으로 프롬프트나 명령어를 실행할 수 있고, cron 작업을 예약할 수도 있으며, 에이전트 생명주기의 특정 지점에서 훅을 사용해 셸 명령을 트리거할 수도 있습니다. 노트북을 덮은 후에도 계속 실행되길 원한다면, 전체 세트를 GitHub Actions로 푸시할 수도 있습니다. 핵심 아이디어는 완전히 동일합니다. 자율적인 작업을 정의하고, 리듬을 부여한 후, 직접 확인하러 다니지 않아도 결과가 당신에게 오도록 만드는 것입니다.

또 하나 알아둘 가치가 있는 세션 내 기본 기능이 있습니다. 이는 이 글에서 진정으로 논의하는 핵심에 더 가깝습니다. `/loop`는 리듬에 따라 반복 실행됩니다. 반면 `/goal`은 당신이 작성한 특정 조건이 실제로 충족될 때까지 지속적으로 실행됩니다. 각 라운드가 끝난 후에는 별도의 작은 모델이 작업 완료 여부를 판단하므로, 코드를 작성하는 에이전트가 스스로 점수를 매기지 않습니다. `test/auth`의 모든 테스트가 통과하고 린트(lint)가 깨끗해질 때까지`와 같은 조건을 주고 떠나면 됩니다. Codex도 동일한 기능을 가지고 있으며, 역시 `/goal`이라고 부릅니다. 검증 가능한 중단 조건이 충족될 때까지 여러 라운드에 걸쳐 지속적으로 작업하며, 일시 중지, 재개 및 초기화를 지원합니다. 동일한 기본 기능이 두 도구 모두에 있습니다. 이것이 기본적으로 이 글에서 반복적으로 등장하는 패턴입니다.

따라서 Automations는 작업을 수면 위로 떠오르게 하는 역할을 합니다. 루프의 나머지 부분은 이러한 작업을 처리합니다.

Worktrees: 병렬 처리를 혼란으로 만들지 않는 방법

두 개 이상의 에이전트를 실행하기 시작하면 파일 충돌이 실패 지점이 됩니다. 두 에이전트가 동시에 같은 파일을 쓰는 것은, 본질적으로 두 명의 엔지니어가 소통 없이 같은 코드 라인을 수정하는 것만큼이나 번거롭습니다. git worktree는 이 문제를 해결합니다. 이는 독립적인 브랜치에 있는 별도의 작업 디렉토리이지만, 동일한 코드 저장소 히스토리를 공유하므로 한 에이전트의 수정 사항이 물리적으로 다른 에이전트의 체크아웃(checkout)에 영향을 줄 수 없습니다.

Codex는 worktree 지원을 직접 내장하고 있어, 여러 스레드가 동시에 동일한 저장소를 처리하면서도 서로 충돌하지 않습니다. Claude Code도 git worktree를 통해 동일한 격리를 구현할 수 있습니다. `--worktree` 플래그를 사용해 독립적인 체크아웃에서 세션을 열거나, 서브에이전트(subagent)에 `isolation: worktree`를 설정하여 각각의 작은 도우미가 완전히 새로운 체크아웃을 받고 작업 종료 후 자동으로 정리하도록 할 수 있습니다. 저는 *the orchestration tax*에서 이 문제의 인간적인 측면에 대해 썼습니다. worktrees는 기계적인 수준의 충돌을 제거하지만, 여전히 당신이 상한선입니다. 동시에 얼마나 많은 에이전트를 실행할 수 있는지를 실제로 결정하는 것은 도구가 아니라, 당신의 리뷰 대역폭(review bandwidth)입니다.

Skills: 매번 프로젝트를 다시 설명할 필요가 없게 해주는 기능

Skill은 매 세션마다 금붕어처럼 같은 프로젝트 컨텍스트를 다시 설명할 필요가 없게 해주는 메커니즘입니다. 두 도구 모두 동일한 형식을 사용합니다: 설명과 메타데이터를 저장하는 SKILL.md 파일이 포함된 폴더이며, 선택적으로 스크립트, 참고 자료 및 리소스 파일을 추가할 수 있습니다. Codex는 $ 또는 /skills로 호출할 때 skill을 실행하며, 작업이 해당 skill의 설명과 일치할 때 자동으로 실행됩니다. 이것이 바로 간결하고 소박한 설명이 종종 화려하고 영리한 설명보다 더 나은 이유입니다. Claude Code도 동일한 방식을 사용하며, 저는 agent skills에서 이 패턴을 다룬 적이 있습니다.

Skills는 또한 의도가 매번 소모되지 않게 하는 곳입니다. 저는 intent debt에서 언급했듯이, 에이전트는 세션이 시작될 때마다 콜드 스타트하며, 의도에 공백이 있으면 자신감 있는 추측으로 그 공백을 채웁니다. Skill은 이러한 의도를 외부에 기록하는 것입니다: 프로젝트 규칙, 빌드 단계, "이전에 그 사고가 있었기 때문에 우리는 이렇게 하지 않는다" 등등을 에이전트가 실행될 때마다 읽는 한 곳에 한 번에 작성합니다. Skills가 없으면 루프는 매번 처음부터 프로젝트 전체를 다시 추론해야 합니다; skills가 있으면 마치 복리 효과처럼 작동합니다.

한 가지 구분할 점이 있습니다: skill은 작성 형식이고, plugin은 배포 방식입니다. 여러 코드 저장소 간에 skill을 공유하거나 여러 skill을 하나로 묶고 싶을 때, 이를 plugin으로 패키징합니다. Codex도 그렇고 Claude Code도 마찬가지입니다.

Plugins and connectors: 루프가 실제 도구에 접근하게 하기

파일 시스템만 볼 수 있는 루프는 매우 작은 루프입니다. Connectors는 MCP를 기반으로 구축되어 에이전트가 issue tracker를 읽고, 데이터베이스를 쿼리하고, staging API를 호출하거나, Slack에 메시지를 보낼 수 있게 합니다. Codex와 Claude Code 모두 MCP를 지원하므로, 하나를 위해 작성한 connector는 일반적으로 다른 곳에서도 사용할 수 있습니다. Plugins는 connectors와 skills를 함께 패키징하여 팀원이 기억에 의존해 전체 설정을 재구축하는 대신 한 번에 완전한 구성을 설치할 수 있게 합니다.

이것이 바로 "에이전트가 '이게 수정方案입니다'라고 말하는 것"과 "루프가 스스로 PR을 열고, Linear ticket을 연결하며, CI가 통과한 후 채널에 알리는 것"의 차이입니다. Connectors가 중요한 이유는 루프가 "할 수 있다면 하겠습니다"라고 말하는 대신 실제 환경에서 행동할 수 있게 해주기 때문입니다.

서브 에이전트: 제작자와 검사자 분리하기

루프에서 가장 유용한 구조적 설계는 '작성하는 사람'과 '검사하는 사람'을 분리하는 것입니다. 코드를 작성하는 모델은 자신의 과제에 점수를 매길 때 너무 관대해지기 쉽습니다. 다른 지침을 가지고, 때로는 다른 모델을 사용하는 또 다른 에이전트가 첫 번째 에이전트가 스스로 납득한 후 놓친 문제를 잡아낼 수 있습니다.

Codex는 요청 시에만 서브 에이전트를 생성하며, 이들은 병렬로 실행된 후 결과를 하나의 답변으로 병합합니다. .codex/agents/ 디렉토리에서 TOML 파일을 사용해 자신만의 에이전트를 정의할 수 있습니다. 각 에이전트는 이름, 설명, 지침, 그리고 선택적으로 모델과 추론 강도를 가집니다. 따라서 보안 검토자는 높은 추론 강도의 강력한 모델이 될 수 있고, 탐색자는 빠르고 읽기 전용의 경량 모델이 될 수 있습니다. Claude Code도 .claude/agents/ 디렉토리의 서브 에이전트와 에이전트 팀을 통해 유사한 기능을 제공하며, 여러 에이전트가 서로 작업을 전달합니다. 양쪽에서 가장 흔한 역할 분담은 하나의 에이전트가 탐색하고, 하나가 구현하며, 하나가 사양에 따라 검증하는 것입니다.

저는 이 개념을 두 번 설명한 바 있습니다. 한 번은 코드 에이전트 오케스트라에서, 또 한 번은 적대적 코드 리뷰에서였습니다. 루프에서 이것이 특히 중요한 이유는 루프가 사용자가 지켜보지 않을 때 실행되기 때문입니다. 따라서 진정으로 신뢰할 수 있는 검증자(verifier)야말로 사용자가 자리를 떠날 수 있는 유일한 이유입니다. 서브 에이전트는 각각 자체 모델 호출과 도구 호출을 수행하기 때문에 더 많은 토큰을 소모하므로, '두 번째 의견을 낼 가치가 있는' 곳에 사용해야 합니다. 이는 기본적으로 Claude Code의 /goal이 내부적으로 수행하는 작업이기도 합니다. 작업을 완료한 모델이 아닌 새로운 모델이 루프 완료 여부를 판단하는 것입니다. 즉, '제작자'와 '검사자'의 분리를 중단 조건 자체에 적용한 것입니다.

루프의 모습

이 모든 것을 결합하면, 단일 스레드가 작은 제어판이 됩니다. 아래는 제가 자주 사용하는 구조입니다.

매일 아침, 자동화가 코드 저장소에서 실행됩니다. 프롬프트는 트리아지 스킬을 호출하여 전날의 CI 실패, 열린 이슈, 최근 커밋을 읽고 결과를 Markdown 파일이나 Linear 보드에 기록합니다. 처리할 가치가 있는 각 문제에 대해 스레드는 격리된 워크트리를 열고, 첫 번째 서브 에이전트가 수정 초안을 작성하도록 보내고, 두 번째 서브 에이전트가 프로젝트 스킬과 기존 테스트를 기반으로 이 초안을 검토하도록 보냅니다.

Connectors는 이 루프가 스스로 PR을 열고 티켓을 업데이트할 수 있게 해줍니다. 루프가 처리할 수 없는 모든 것은 triage 인박스로 들어와 제가 처리합니다. 상태 파일은 전체 시스템의 중추입니다. 시도한 것, 통과한 것, 아직 완료되지 않은 것을 기억합니다. 따라서 다음 날 아침 실행은 오늘 중단된 지점에서 계속됩니다.

당신이 실제로 한 일을 주목하세요. 당신은 단 한 번 설계했습니다. 그 단계들을 당신이 직접 하나하나 지시한 것이 아닙니다. 이것이 Steinberger의 말이 현실화된 버전입니다. 그리고 동일한 루프가 Codex에서도, Claude Code에서도 실행될 수 있습니다. 구성 요소 자체가 동일한 구성 요소이기 때문입니다.

루프가 여전히 당신을 대신해주지 않는 것

루프는 작업 방식을 바꾸지만, 당신을 작업에서 제거하지는 않습니다. 사실 루프가 강력해질수록 세 가지 문제는 더 쉬워지는 것이 아니라 더 날카로워집니다.

검증은 여전히 당신에게 달려 있습니다. 무인으로 실행되는 루프는 무인으로 실수할 수도 있습니다. verifier 서브 에이전트와 maker를 분리한 이유는 루프가 "완료"라고 말할 때 그것이 어느 정도 의미를 갖도록 하기 위해서입니다. 그럼에도 불구하고 "완료"는 증명이 아니라 주장일 뿐입니다. 저는 AI 시대의 코드 리뷰에서 항상 같은 말을 반복합니다. 당신의 책임은 당신이 유효하다고 확인한 코드를 전달하는 것입니다.

방치하면 당신 자신의 이해도 썩어갑니다. 루프가 당신이 직접 작성하지 않은 코드를 더 빨리 전달할수록, 당신이 실제로 이해하는 것과 시스템에 실제로 존재하는 것 사이의 격차는 더 커집니다. 이것이 comprehension debt(이해 부채)입니다. 루프가 생성한 것을 읽지 않는다면, 매끄러운 루프는 이 부채를 더 빠르게 증가시킬 뿐입니다.

그리고 네, 가장 편안한 자세가 가장 위험한 자세일 가능성이 높습니다. 루프가 스스로 실행될 때, 당신은 자신의 판단을 내리는 것을 멈추고 루프가 반환하는 모든 것을 그대로 받아들이기 쉽습니다. 저는 이것을 cognitive surrender(인지 항복)라고 부릅니다. 판단력을 가지고 루프를 설계한다면 그것은 해독제입니다. 생각을 회피하기 위해 루프를 설계한다면 그것은 가속제입니다. 같은 행동이 완전히 반대되는 결과를 가져옵니다.

루프를 구축하되, 여전히 엔지니어로 남기

저는 이것이 우리 미래 업무의 진화 방향을 예고한다고 생각합니다. 그렇긴 하지만, 제가 직접 코드를 검토하지 않거나 코드 수정을 자동화된 루프에 완전히 의존한다면, 제 제품 품질은 손상될 것입니다. 저는 아마도 하향 나선에 빠질 가능성이 높습니다. 계속해서 스스로를 더 깊은 구덩이로 파고드는 것입니다.

그러니 물론, 직접 루프를 구축할 수도 있지만, 에이전트에게 직접 프롬프트를 주는 방법도 여전히 유효하다는 점을 잊지 마세요. 핵심은 적절한 균형을 찾는 데 있습니다.

루프의 결과는 사람마다 다를 수 있습니다. 두 사람이 완전히 동일한 루프를 구축해도 정반대의 결과를 얻을 수 있습니다. 한 사람은 자신이 깊이 이해하는 작업의 속도를 높이는 데 사용하고, 다른 사람은 작업 자체를 이해하는 것을 회피하는 데 사용합니다. 루프는 이 둘의 차이를 알지 못합니다. 당신이 알고 있습니다.

이것이 바로 루프 디자인이 프롬프트 엔지니어링보다 더 어렵고, 더 쉬운 것이 아닌 이유입니다. Cherny가 말한 것은 작업이 쉬워진다는 것이 아니라, 레버리지 포인트가 이동했다는 뜻입니다.

루프를 구축하세요. 하지만 단순히 '시작' 버튼만 누르는 사람이 아니라, 여전히 엔지니어가 되려는 사람처럼 구축하세요.

[원문 링크]

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia