5가지 구성 요소로 이해하는 Loop Engineering

최근 Addy Osmani 씨의 블로그에서 Loop Engineering이라는 기사를 읽었습니다. 기사 중에 인용된 Peter Steinberger 씨의 한 문장이 가슴에 와닿았습니다.

You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

(이제 코딩 에이전트에게 프롬프트를 작성하는 것을 그만두어야 합니다. 에이전트에게 프롬프트를 작성하게 하는 "루프(loop)"를 설계해야 합니다.)

이는 Peter Steinberger 씨의 말이며, Anthropic에서 Claude Code를 이끄는 Boris Cherny 씨도 "나는 더 이상 Claude에게 프롬프트를 작성하지 않는다. Claude가 프롬프트를 작성하고 다음에 무엇을 할지 판단하는 루프를 실행하게 한다. 나의 일은 루프를 쓰는 것이다"라고 말하고 있습니다.

필자는 평소 Claude Code로 스킬이나 스케줄 태스크를 구성하여 개인 개발을 하고 있기 때문에, 이 "루프 설계"라는 사고방식이 깊이 공감되었습니다. 본 기사에서는 Addy 씨의 정리를 바탕으로, 필자 나름대로 이 개념을 "5가지 부품 + 1가지 기억"이라는 형태로 풀어서 정리해 보겠습니다.

필자는 이전에 Agent Harness Engineering(에이전트가 작동하는 환경 = 하네스(harness)를 설계하는 사고방식)에 대해서도 글을 쓴 적이 있습니다. Loop Engineering은 그보다 한 단계 높은 개념에 해당합니다.

하네스(Harness)… 1체의 에이전트가 움직이는 "환경" 그 자체. 컨텍스트(Context), 툴(Tool), 가드레일(Guardrail)을 정비함
루프(Loop)… 하네스를 타이머로 돌려 헬퍼(Helper)를 생성하고, 자신에게 계속해서 일을 공급하는 메커니즘

Addy 씨의 말을 빌리자면 "하네스가 타이머로 움직이며, 작은 헬퍼를 만들어내고, 자신에게 먹이를 주는 것"이 루프입니다. 최근 1~2년 동안 에이전트로부터 성과를 이끌어내는 수단은 "좋은 프롬프트를 작성하고 충분한 컨텍스트를 전달하는 것"이었습니다. 한 턴 작성하고, 돌아온 것을 읽고, 다시 다음 것을 작성한다. 툴을 쥐고 있는 것은 항상 자신이었습니다.

Loop Engineering은 그 "쥐고 있는 사람"을 자신에서 **시스템(System)**으로 대체합니다. 일을 찾아내고, 할당하고, 검증하고, 무엇이 끝났는지 기록하고, 다음에 할 일을 결정한다. 그 일련의 과정을 자동화하여, 에이전트를 몰아붙이는 것을 자신이 아닌 시스템이 하게 만드는 발상입니다.

필자가 흥미롭다고 느낀 점은, 이것이 이제 더 이상 "자체 툴을 만드는 이야기"가 아니라는 점입니다. 1년 전이라면 루프를 구성하기 위해 대량의 bash를 작성하고 영구적으로 유지보수해야 했습니다. 지금은 부품들이 제품 안에 표준으로 탑재되어 있습니다.

Addy 씨는 루프에는 5가지 부품과 상태를 기억해 두는 1곳이 필요하다고 정리했습니다. 필자 나름대로 표로 만들면 다음과 같습니다.

부품	루프 내에서의 역할	Codex에서의 구현	Claude Code에서의 구현
자동화 (Automations)	스케줄에 따른 발견 및 트리아지 (Triage)	Automations 탭, /goal	스케줄 태스크 / cron, /loop, /goal, hooks, GitHub Actions
워크트리 (Worktrees)	병렬 작업의 격리	스레드별 내장 워크트리	git worktree, --worktree, 서브 에이전트의 isolation: worktree
스킬 (Skills)	프로젝트 지식의 명문화	Agent Skills (SKILL.md)	Agent Skills (SKILL.md)
커넥터 / 플러그인	기존 툴로의 연결	Connectors (MCP) + 플러그인	MCP 서버 + 플러그인
서브 에이전트	입안역과 검증역의 분리	.codex/agents/ 의 TOML	.claude/agents/ 의 Task 서브 에이전트
상태 (State) ※기억	완료된 사항의 기록	Markdown 또는 Linear (커넥터 경유)	Markdown (AGENTS.md 등) 또는 Linear (MCP 경유)

이름은 미묘하게 다르지만, 능력은 거의 같습니다. 차례대로 살펴보겠습니다.

자동화야말로 루프를 '단 한 번의 실행'이 아닌 '진정한 루프'로 만드는 부품입니다. 스케줄에 따라 기동하며, 스스로 발견과 트리아지 (Triage)를 수행합니다.

Claude Code 에서는 프롬프트나 명령어를 일정 간격으로 재실행하는 /loop,

cron을 통한 스케줄 태스크, 에이전트 라이프사이클의 각 지점에서 셸 명령어를 실행하는 hooks, 노트북을 닫아도 계속 돌리고 싶다면 GitHub Actions라는 수단이 있습니다.

여기서 특히 짚고 넘어가야 할 점은 루프의 본질에 가장 가까운 세션 내 프리미티브 (Primitive)의 차이입니다.

/loop

… 일정 간격으로 재실행함

/goal

… 자신이 작성한 조건이 실제로 참(True)이 될 때까지 계속 실행됨

/goal이 뛰어난 점은 매 턴이 끝난 후에 별도의 작은 모델이 '끝났는지 여부'를 판정한다는 점입니다. 즉, 코드를 작성한 에이전트 스스로 채점하지 않습니다. 예를 들어 다음과 같은 정지 조건을 전달하고 떠날 수 있습니다.

# "test/auth 의 테스트가 모두 통과하고, lint가 깨끗해질 때까지" 계속 실행
/goal "all tests in test/auth pass and lint is clean"

Codex에도 동일한 이름의 /goal이 있으며, 검증 가능한 정지 조건이 충족될 때까지 턴을 넘기며 계속 움직입니다. pause / resume / clear 도 마찬가지입니다. 동일한 프리미티브가 두 도구 모두에 탑재되어 있다 —— 이것이 이 글을 관통하는 패턴입니다.

에이전트를 2대 이상 동시에 실행하는 순간, 파일 충돌이 시작됩니다. 같은 파일을 두 대가 작성하는 것은, 두 명의 엔지니어가 상의 없이 같은 행을 커밋하는 것과 같은 골칫거리입니다.

이를 해결하는 것이 git의 워크트리 (Worktree)입니다. 동일한 리포지토리 히스토리를 공유하면서도 각각 별도의 브랜치와 별도의 디렉토리에서 작업하기 때문에, 한쪽 에이전트의 편집이 물리적으로 다른 쪽의 체크아웃 (Checkout)에 영향을 주지 않습니다.

# 서브 에이전트마다 일회용 체크아웃을 부여하는 예시 (Claude Code)
git worktree add ../feature-a feature-a
# 서브 에이전트 정의 측에서 isolation: worktree 를 지정하면
...

다만 Addy 씨도 주의를 주었듯이, 워크트리가 제거하는 것은 '기계적인 충돌'뿐입니다. 실제로 몇 대까지 돌릴 수 있는가의 상한선은 당신의 리뷰 대역폭 (Review Bandwidth) 입니다. 도구가 아니라 인간이 병목 (Bottleneck)이 됩니다.

스킬 (Skill)은 매 세션마다 동일한 프로젝트 문맥을 금붕어처럼 다시 설명해야 하는 수고를 덜기 위한 부품입니다. 두 도구 모두 형식은 동일하며, SKILL.md를 중심으로 명령, 메타데이터, 임의의 스크립트나 참조, 에셋을 배치한 폴더입니다.

핵심은 description (설명문)을 '그럴듯한 표현'보다는 '지루할 정도로 정확한 표현'으로 만드는 것입니다. 태스크가 스킬의 description과 일치할 때 자동으로 기동되기 때문에, 설명이 모호하면 발화되지 않습니다.

스킬은 '의도 (Intent)를 단 한 번의 기술로 끝내는' 장소이기도 합니다. 에이전트는 매 세션 차가운 상태에서 시작하며, 의도의 빈틈을 자신만만한 추측으로 채우려 합니다. 규약, 빌드 절차, '그 사건이 있었으니 이렇게는 하지 않는다'와 같은 암묵지를 에이전트가 매번 읽는 곳에 한 번 써두는 것입니다. 스킬이 없다면 루프는 매 사이클마다 프로젝트를 처음부터 다시 유도하겠지만, 스킬이 있다면 지식이 쌓여갑니다.

참고로 **스킬은 '쓰는 형식'이고, 플러그인 (Plugin)은 '배포하는 형식'**입니다. 여러 리포지토리에서 공유하거나 묶을 때 플러그인으로 패키징합니다.

파일 시스템만 볼 수 있는 루프는 작은 루프입니다. MCP를 기반으로 한 커넥터 (Connector)를 통해 에이전트는 이슈 트래커를 읽고, DB에 질의하고, 스테이징 API를 호출하며, Slack에 메시지를 남길 수 있습니다.

Codex와 Claude Code 모두 MCP를 사용하기 때문에, 한쪽을 위해 작성한 커넥터는 대개 다른 쪽에서도 그대로 작동합니다. 이것이

루프(Loop) 내에서 가장 유용한 구조는 작성자(Writer)와 검증자(Verifier)를 분리하는 것이라고 저 또한 생각합니다. 코드를 작성한 모델은 자신의 숙제를 채점할 때 너무 관대합니다. 별도의 명령, 때로는 별도의 모델을 가진 두 번째 존재가 첫 번째 존재가 스스로를 설득해 그냥 통과시켜 버린 문제들을 잡아냅니다.

Claude Code에서는 .claude/agents/에 서브 에이전트(Sub-agent)를 정의하여 에이전트 팀이 업무를 주고받습니다. 전형적인 분업 방식은 "한 명은 탐색, 한 명은 구현, 한 명은 사양(Specification)에 대해 검증"하는 것입니다.

# Codex의 경우: .codex/agents/ 에 TOML로 정의하는 예
name = "security-reviewer"
description = "보안 관점에서 PR을 비판적으로 리뷰한다"
...

서브 에이전트는 각각 독립적으로 모델과 도구(Tool)를 구동하므로 토큰을 많이 소비합니다. 따라서 두 번째 의견에 비용을 지불할 가치가 있는 곳에 집중해서 사용하는 것이 요령입니다. 앞서 언급한 /goal이 내부적으로 수행하는 것도 본질적으로는 이것이며, 작업한 모델이 아닌 새로운 모델이 "끝났는지"를 판정하는 것—즉, 정지 조건(Stopping condition) 그 자체에 maker / checker 분리를 적용하고 있습니다.

부품들을 조합하면 하나의 스레드(Thread)가 작은 제어반이 됩니다. Addy 씨가 제시했고 저 또한 따라 하고 싶게 만든 형태는 다음과 같습니다.

상태 파일(State file)은 이 루프의 중추입니다. 무엇을 시도했고, 무엇이 통과되었으며, 무엇이 아직 열려 있는지를 기억하고 있기 때문에, 다음 날 아침의 실행은 오늘 멈춘 지점에서 재개할 수 있습니다. 모델은 실행 사이에 모든 것을 잊어버리지만, 리포지토리(Repository)는 잊지 않습니다. 기억은 컨텍스트(Context)가 아니라 디스크(Disk)에 두어야 한다—이것이 장시간 실행되는 에이전트들이 공통적으로 의존하는 트릭입니다.

그리고 주목해야 할 점은, 여기서 실제로 수행한 것은 "한 번 설계했을 뿐"이라는 점입니다. 개별 단계마다 프롬프트(Prompt)를 작성하지 않았습니다. 그것이 Steinberger 씨가 주장하는 실체이며, 부품이 동일한 이상 Codex에서도 Claude Code에서도 동일한 루프가 됩니다.

루프는 업무를 "변화"시키는 것이지, 자신을 없애주는 것이 아닙니다. 오히려 루프가 좋아질수록 더 날카로워지는 문제가 세 가지 있습니다.

• 검증은 여전히 자신의 몫이다. 무인으로 돌아가는 루프는 무인으로 실수를 저지르는 루프이기도 합니다. 검증 역할을 하는 서브 에이전트를 분리하는 것은 "끝났다"라는 말에 의미를 부여하기 위함이지만, 그럼에도 "끝났다"는 주장일 뿐 증명은 아닙니다.
• 이해는 방치하면 부패한다. 루프가 자신이 작성하지 않은 코드를 빠르게 내놓을수록, "존재하는 것"과 "자신이 파악하고 있는 것" 사이의 간극이 벌어집니다 (comprehension debt, 이해 부채).
• 편안한 자세가 가장 위험하다. 루프가 돌아가기 시작하면 의견을 갖는 것을 멈추고, 돌아온 결과물을 그대로 받아들이고 싶어집니다. Addy 씨는 이를 cognitive surrender (인지적 굴복)라고 부릅니다.

같은 "루프를 설계하는" 행위라도 판단력을 가지고 하면 처방전이 되고, 생각하지 않기 위해 하면 가속 장치가 된다—행위는 같지만 결과는 정반대라는 이 지적이 저에게는 가장 깊게 와닿았습니다.

Loop Engineering은 "프롬프트 엔지니어링(Prompt Engineering)이 필요 없어지는" 이야기가 아니라, 레버리지(Leverage)가 발생하는 지점이 이동했다는 이야기라고 저는 이해했습니다.

• 루프는 "5가지 부품(자동화, 워크트리, 스킬, 커넥터, 서브 에이전트) + 1개의 기억(상태)"로 구성된다
• 이것들은 이제 직접 만든 bash가 아니라, Codex / Claude Code의 표준 기능으로 갖춰져 있다
• 핵심은 /goal과 같이 "조건이 참이 될 때까지 실행되고, 별도의 모델이 채점하는" 자동화이다 — 그럼에도 검증, 이해, 주체성은 자신에게 남는다

같은 루프를 두 사람이 구성하더라도, 깊이 이해하고 있는 작업을 가속하는 데 사용하는 사람과, 작업을 이해하지 않기 위해 사용하는 사람 사이에는 정반대의 결과가 나타납니다. 루프는 그 차이를 모르지만, 자신은 알고 있습니다. 버튼만 누르는 사람이 아니라, 엔지니어로 남겠다는 마음가짐으로 루프를 구성한다—이것이 저의 결론입니다. 우선은 "매일 아침 CI 실패를 트리아지(Triage)하는 스킬을 스케줄링하여 실행하기" 정도부터 작게 시도해 볼 생각입니다.

• Addy Osmani, Loop Engineering (본 기사의 1차 정보)
• Addy Osmani, Agent Harness Engineering
• Addy Osmani, Long-running agents
• Addy Osmani, 의도 부채 (Intent debt) / 이해 부채 (Comprehension debt) / 인지적 항복 (Cognitive surrender)
• Peter Steinberger 氏의 발언 / Boris Cherny 氏의 발언