루프 엔지니어링(Loop Engineering) 입문 — 프롬프트 대신 루프를 설계하는 5가지 부품

최근 Addy Osmani의 블로그에서 Loop Engineering이라는 글을 읽었습니다. 글에서 인용된 Peter Steinberger의 한 문장이 꽂힙니다.

You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents. (이제 코딩 에이전트에 프롬프트를 쓰는 건 그만두라. 에이전트에 프롬프트를 쓰는 "루프"를 설계하라)

이것은 Peter Steinberger의 말이고, Anthropic에서 Claude Code를 이끄는 Boris Cherny도 "나는 이제 Claude에 프롬프트를 쓰지 않는다. Claude에 프롬프트를 쓰고 다음에 무엇을 할지 판단하는 루프를 돌리고 있다. 내 일은 루프를 쓰는 것이다"라고 말하고 있습니다.

필자는 평소 Claude Code로 스킬과 스케줄 태스크를 짜서 개인 개발을 하고 있어서, 이 "루프 설계"라는 사고방식이 바로 납득이 갔습니다. 이 글에서는 Addy의 정리를 밑그림으로 깔되, 필자 나름대로 이 개념을 "5가지 부품 + 1가지 기억"이라는 형태로 씹어서 정리합니다.

배경: 하네스의 "한 층 위"

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

• 하네스 … 에이전트 1개가 움직이는 "환경" 그 자체. 컨텍스트, 툴, 가드레일을 갖춘다
• 루프 … 하네스를 타이머로 돌리고, 헬퍼를 만들어 내고, 자기 자신에게 일을 계속 공급하는 구조

Addy의 말을 빌리면 "하네스가 타이머로 움직이고, 작은 헬퍼를 낳고, 자기 자신에게 먹이를 준다"는 것이 루프입니다. 최근 1~2년간 에이전트에서 성과를 끌어내는 수단은 "좋은 프롬프트를 쓰고 충분한 컨텍스트를 넘기는" 것이었습니다. 한 턴 쓰고, 돌아온 것을 읽고, 또 다음을 쓴다. 툴을 쥐고 있는 건 언제나 자신이었죠.

루프 엔지니어링은 그 "쥐는 사람"을 자신에서 시스템으로 바꿉니다. 일을 찾고, 배분하고, 검증하고, 무엇이 끝났는지 기록하고, 다음에 할 일을 정한다. 그 일련의 흐름을 자동화해서, 에이전트를 찔러 주는 역할을 자신이 아니라 시스템에 시킨다는 발상입니다.

필자가 흥미롭다고 느낀 건, 이것이 더는 "자체 툴을 짜는 이야기"가 아니게 됐다는 점입니다. 1년 전이라면 루프를 짜려면 대량의 bash를 쓰고 영원히 유지보수를 이어 가야 했습니다. 지금은 부품이 제품 안에 표준으로 실려 있습니다.

본론: 루프를 구성하는 "5가지 부품 + 1가지 기억"

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

이름은 미묘하게 다르지만 능력은 거의 같습니다. 순서대로 봅니다.

1. 자동화 — 루프의 심장

자동화야말로 루프를 "한 번뿐인 실행"이 아니라 "진짜 루프"로 만드는 부품입니다. 스케줄로 기동해 스스로 발견과 트리아지를 합니다.

Claude Code에는 프롬프트나 커맨드를 일정 간격으로 재실행하는 /loop, cron을 이용한 스케줄 태스크, 에이전트 라이프사이클의 각 지점에서 셸 커맨드를 쏘아 주는 hooks, 노트북을 닫아도 계속 돌리고 싶다면 GitHub Actions, 라는 수단이 있습니다.

여기서 특히 챙겨야 할 것이 루프의 본질에 가장 가까운 세션 내 프리미티브의 차이입니다.

• /loop … 일정한 간격으로 재실행한다
• /goal … 자신이 쓴 조건이 정말 참이 될 때까지 계속 달린다

/goal이 영리한 점은, 매 턴 뒤에 별도의 작은 모델이 "끝났는지 아닌지"를 판정한다는 데 있습니다. 즉 코드를 쓴 에이전트 자신이 채점하지 않습니다. 예를 들어 다음 같은 정지 조건을 넘기고 자리를 떠도 됩니다.

# "test/auth의 테스트가 전부 통과하고 lint가 클린해질 때까지" 계속 달린다
/goal "all tests in test/auth pass and lint is clean"

Codex에도 같은 이름의 /goal이 있어, 검증 가능한 정지 조건이 충족될 때까지 턴을 넘나들며 계속 움직입니다. pause / resume / clear도 같습니다. 같은 프리미티브가 두 툴 모두에 실려 있다 — 이것이 이 글을 관통하는 패턴입니다.

2. 워크트리 — 병렬이 카오스가 되지 않도록

에이전트를 2개 이상 동시에 돌리는 순간 파일 충돌이 시작됩니다. 같은 파일을 2개가 쓰는 것은, 두 엔지니어가 상의 없이 같은 줄을 커밋하는 것과 똑같은 골칫거리예요.

이를 해결하는 것이 git의 워크트리입니다. 같은 리포지토리 이력을 공유하면서 각자 다른 브랜치·다른 디렉터리에서 작업하기 때문에, 한쪽 에이전트의 편집이 물리적으로 다른 쪽 체크아웃에 닿지 않습니다.

# 서브에이전트마다 일회용 체크아웃을 주는 예(Claude Code)
git worktree add ../feature-a feature-a
# 서브에이전트 정의 쪽에서 isolation: worktree 를 지정하면
# 헬퍼마다 새 체크아웃이 만들어지고 종료 후 자동으로 청소된다

다만 Addy도 못을 박고 있지만, 워크트리가 없애는 것은 "기계적인 충돌"뿐입니다. 몇 개까지 실제로 돌릴 수 있는가의 상한은 당신의 리뷰 대역폭입니다. 툴이 아니라 인간이 병목이 됩니다.

3. 스킬 — 매번 프로젝트를 다시 설명하지 않는다

스킬은 매 세션 같은 프로젝트 컨텍스트를 금붕어처럼 처음부터 다시 설명하는 것을 그만두기 위한 부품입니다. 두 툴 모두 형식은 같아서, SKILL.md를 중심으로 명령·메타데이터·임의의 스크립트나 참조·에셋을 둔 폴더입니다.

포인트는 description(설명문)을 "재치 있는 표현"보다 "지루하고 정확한 표현"으로 쓰는 것입니다. 태스크가 스킬의 description에 매칭됐을 때 자동 기동하므로, 애매한 설명이면 발화하지 않습니다.

스킬은 "의도(intent)를 한 번의 기술로 끝내는" 장소이기도 합니다. 에이전트는 매 세션 차가운 상태에서 시작해, 의도의 구멍을 자신만만한 추측으로 메웁니다. 규약·빌드 절차·"그 일이 있었으니 이렇게는 하지 않는다" 같은 암묵지를, 에이전트가 매번 읽는 자리에 한 번 써 둔다. 스킬이 없으면 루프는 매 사이클마다 프로젝트를 0에서 다시 도출하지만, 스킬이 있으면 쌓여 갑니다.

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

4. 커넥터 / 플러그인 — 루프가 실제 툴에 닿는다

파일 시스템밖에 못 보는 루프는 작은 루프입니다. MCP를 토대로 한 커넥터 덕분에 에이전트는 이슈 트래커를 읽고, DB에 질의하고, 스테이징 API를 호출하고, Slack에 메시지를 떨어뜨릴 수 있습니다.

Codex도 Claude Code도 MCP를 말하기 때문에, 한쪽용으로 쓴 커넥터는 대개 다른 쪽에서도 그대로 돕니다. 이것이 "여기 수정안이 있습니다"라고 말하기만 하는 에이전트와, "CI가 그린이 되면 스스로 PR을 열고, Linear 티켓을 연결하고, 채널에 알리는" 루프의 차이입니다.

5. 서브에이전트 — 만드는 자와 검증하는 자를 떼어 놓는다

루프 안에서 가장 유용한 구조는 쓰는 자와 검증하는 자를 나누는 것이라고 필자도 생각합니다. 코드를 쓴 모델은 자기 숙제를 채점하기에는 너무 관대합니다. 다른 명령, 때로는 다른 모델을 가진 두 번째가, 첫 번째가 스스로를 설득해 통과시켜 버린 문제를 주워 올립니다.

Claude Code에서는 .claude/agents/ 에 서브에이전트를 정의하고, 에이전트 팀으로 일을 주고받습니다. 전형적인 분업은 "1개가 탐색, 1개가 구현, 1개가 사양에 대한 검증"입니다.

# Codex의 경우: .codex/agents/ 에 TOML로 정의하는 예
name = "security-reviewer"
description = "보안 관점에서 PR을 비판적으로 리뷰한다"
model = "<강한 모델을 지정>"        # 검증 역은 강한 모델로
reasoning_effort = "high"          # 그리고 높은 reasoning effort로

서브에이전트는 저마다 독자적으로 모델과 툴을 돌리므로 토큰을 많이 소비합니다. 두 번째 의견에 값을 치를 만한 자리로 좁혀 쓰는 것이 요령입니다. 앞서 말한 /goal이 뒤에서 하고 있는 것도 본질적으로는 이것으로, 작업한 모델이 아닌 새 모델이 "끝났는가"를 판정한다 — 정지 조건 자체에 maker / checker 분리를 적용하고 있는 셈입니다.

하나의 루프는 어떤 모양인가

부품을 조합하면 1개의 스레드가 작은 관제탑이 됩니다. Addy가 예로 들었고 필자도 따라 하고 싶어진 모양은 이렇습니다.

상태 파일이 이 루프의 등뼈입니다. 무엇을 시도했고, 무엇이 통과했고, 무엇이 아직 열려 있는지를 기억하고 있으니, 다음 날 아침의 실행은 오늘 멈춘 자리에서 재개할 수 있습니다. 모델은 실행 사이에 모든 것을 잊지만, 리포지토리는 잊지 않습니다. 기억은 컨텍스트가 아니라 디스크에 둔다 — 이것이 장시간 달리는 에이전트가 공통으로 기대는 비결입니다.

그리고 주목할 것은, 여기서 실제로 한 일이 "한 번 설계했을 뿐"이라는 점입니다. 개별 스텝에 프롬프트를 쓰지 않았습니다. 그것이 Steinberger의 주장의 실체이고, 부품이 같은 이상 Codex에서도 Claude Code에서도 같은 루프가 됩니다.

걸려 넘어지기 쉬운 곳: 루프화해도 손에 남는 3가지 일

루프는 일을 "바꾸는" 것이지 자신을 지워 주는 게 아닙니다. 오히려 루프가 좋아질수록 날카로워지는 문제가 3가지 있습니다.

1. 검증은 여전히 자신의 일. 무인으로 달리는 루프는 무인으로 실수를 저지르는 루프이기도 합니다. 검증 역 서브에이전트를 나누는 건 "끝났다"에 의미를 갖게 하기 위해서지만, 그래도 "끝났다"는 주장이지 증명이 아닙니다.
2. 이해는 방치하면 썩는다. 루프가 자신이 쓰지 않은 코드를 빨리 내놓을수록, "존재하는 것"과 "자신이 파악하고 있는 것"의 간극이 벌어집니다(comprehension debt, 이해 부채).
3. 편안한 자세가 가장 위험하다. 루프가 돌기 시작하면 의견 갖기를 그만두고, 돌아온 것을 그대로 받아들이고 싶어집니다. Addy는 이것을 cognitive surrender(인지적 항복)라고 부릅니다.

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

정리

Loop Engineering은 "프롬프트 엔지니어링이 필요 없어진다"는 이야기가 아니라, 지렛대를 대는 지점이 옮겨 갔다는 이야기라고 필자는 이해했습니다.

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

같은 루프를 두 사람이 짜도, 깊이 이해하고 있는 작업을 가속하는 데 쓰는 사람과, 작업을 이해하지 않기 위해 쓰는 사람은 정반대의 결과를 얻습니다. 루프는 그 차이를 모르지만, 자신은 압니다. 버튼만 누르는 사람이 아니라 엔지니어로 남을 작정으로 루프를 짠다 — 는 것이 필자의 결론입니다. 우선은 "매일 아침 CI 실패를 트리아지하는 스킬을 스케줄 기동한다" 언저리부터 작게 시험해 볼 생각입니다.