작년 12월, Boris Cherny는 한 달 동안 259개의 풀 리퀘스트를 처리했습니다. 모두 Claude가 작성한 코드입니다. 그는 그 기간 동안 편집기를 한 번도 열지 않았다고 말합니다.
그의 역할은 코드를 작성하는 것이 아니었습니다. 코드를 작성하는 대상을 만드는 것이었죠. Peter Steinberger는 이를 두 줄로 압축했고, 이 글은 800만 회 이상 조회되었습니다: "더 이상 코딩 에이전트에게 프롬프트를 입력해서는 안 됩니다. 에이전트에게 프롬프트를 입력하는 루프를 설계해야 합니다."
이것이 바로 루프 엔지니어링(Loop Engineering)입니다. 작업을 찾아 에이전트에 전달하고, 결과를 확인하며, 다음 행동을 결정하는 작은 시스템을 구축한 뒤, 당신이 잠든 사이에도 실행되도록 두는 것입니다.
하지만 같은 달에 문제점도 드러났습니다. 다른 누군가의 루프가 11일 동안 감시 없이 실행되며 누군가 알아채기도 전에 47,000달러를 소진해버린 것입니다. 따라서 여기에는 두 가지 기술이 필요하며, 거의 모든 사람이 그중 하나만 가르칩니다: 작업을 처리하는 루프를 만드는 기술과, 루프가 통제 불능 상태가 되는 것을 막는 제동 장치를 만드는 기술입니다.
당신이 만든 루프가 어떤 것인지는 단 하나의 질문으로 판가름납니다: 그 루프가 진정한 결과를 향해 수렴하는가, 아니면 그저 값비싼 무작위 탐색(Random Walk)에 불과한가?
1. 루프는 여섯 가지 요소와 하나의 질문으로 구성된다
겉으로 보기에는 복잡해 보이지만, 실제로 작동하는 루프는 여섯 부분으로 이루어져 있습니다. 처음 보기에는 목록이 너무 단순해 보일 수도 있습니다. 하지만 각 부분의 세부 내용이 루프를 견고하게 유지하거나, 하룻밤 사이에 자금을 새 나가게 만듭니다.
이제 이러한 요소들을 수동으로 구축할 필요는 없습니다. 1년 전만 해도 루프는 소유자가 직접 관리하고 지속적으로 모니터링해야 하는 쉘 스크립트 덩어리에 불과했습니다. 하지만 이제는 이러한 요소들이 제품 내에 포함되어 있습니다. 동일한 여섯 가지 요소가 OpenAI Codex 앱과 Claude Code 모두에 적용됩니다. 이를 이해하면, 도구 자체는 더 이상 논쟁의 대상이 아니게 되고 루프 자체가 설계의 핵심이 됩니다.
1요소 루프 내 역할 CODEX CLAUDE CODE2------------- ------------------------ ------------------------- --------------------------3상태(State) 실행 간 기억 유지 markdown / Linear (MCP) markdown / Routines + MCP4자동화 일정 기반 실행 Automations 탭 + Triage /loop (skill), Routines, /goal5작업트리 병렬 에이전트 격리 Worktree per thread --worktree, isolation: worktree6스킬(Skills) 의도 명시화 ~/.agents/skills/SKILL.md ~/.claude/skills/SKILL.md7커넥터 실제 도구 연동 MCP 서버 (config.toml) MCP 서버 (.mcp.json)8하위 에이전트 생성자와 검증자 분리 TOML in .codex/agents/ .claude/agents/ + agent teams
2. 상태(State)는 다음 실행이 물려받는 유일한 것이다
가장 기본적인 부분부터 시작해야 합니다. 다른 모든 것이 이 위에 의존하기 때문입니다.
모델은 실행이 종료되면 모든 것을 잊습니다. 대화는 사라지고, 컨텍스트는 초기화되며, 다음 실행은 아무것도 모른 채 시작됩니다. 채팅 내의 메모리는 실행과 함께 소멸됩니다. 따라서 메모리는 디스크에 저장되어야 합니다.
실제로는 하나의 파일로 충분합니다. 저장소 내의 STATUS.md 파일이나, 커넥터를 통해 접근하는 Linear 보드가 여기에 해당합니다. 이 파일은 완료된 작업, 진행 중인 작업, 다음에 할 작업, 그리고 루프가 절대 건드려서는 안 되는 몇 가지 사항을 보관합니다.
1# STATUS.md (루프는 이 파일을 먼저 읽고, 마지막으로 씁니다)2## 완료됨3- [x] auth: v2 토큰으로 마이그레이션 완료, 테스트 통과4## 진행 중5- [ ] billing: 웹훅 리팩토링 (PR #214, CI 실패)6## 다음 할 일7- [ ] dashboard: test/charts 내 변덕스러운 테스트 수정8## 절대 하지 말 것9- infra/ 디렉토리는 사람의 승인 없이 수정하지 말 것
루프를 당신이 절대 지켜보지 않는 야간 근무자처럼 취급하세요. 당신은 새벽 3시에 루프가 무엇을 했는지로 평가받지 않습니다. 당신은 아침 9시에 책상 위에 놓인 메모로 평가받습니다. 그 메모를 먼저 설계하면 루프의 대부분은 자연스럽게 설계됩니다.
3. 자동화는 '루프'와 '한 번 실행한 것'을 구분짓는 요소다
루프라는 이름값을 하려면 스스로 실행되어야 합니다.
Codex 앱에서는 Automations 탭에서 루프를 만듭니다: 저장소, 프롬프트, 실행 주기를 설정합니다. 무언가를 찾은 실행은 Triage 받은 편지함에 저장되고, 아무것도 찾지 못한 실행은 자동으로 보관됩니다. OpenAI는 이를 코드베이스의 소박한 백본, 즉 일일 이슈 분류, CI 실패 요약, 지난주에 누군가가 몰래 집어넣은 버그를 잡는 등의 작업에 사용합니다.
Claude Code는 몇 가지 기본 요소를 통해 이를 구현합니다. 관련된 인기 글들이 종종 세부 사항을 잘못 설명하기 때문에 정확하게 짚고 넘어가는 것이 중요합니다. /loop는 내장 명령어가 아닌 스킬이며, 세션이 열려 있는 동안 설정된 주기에 따라 프롬프트를 다시 실행합니다. 반복 실행되는 클라우드 작업은 Routines이며 /schedule로 설정하고 최소 1시간 간격으로 실행되며, 노트북을 닫아도 계속 실행됩니다. 로컬 crontab은 존재하지 않습니다.
꼭 익혀야 할 것은 /goal입니다. 이는 사용자가 작성한 조건이 참이 될 때까지 실행되며, 각 실행 후에는 별도의 작은 모델이 실제로 작업이 완료되었는지 확인합니다. 코드를 작성한 에이전트는 자신의 작업을 평가할 수 없습니다.
1# Claude Code: 작업이 끝난 '기분'이 아닌, 실제로 끝날 때까지 실행2/goal test/auth 디렉토리의 모든 테스트가 통과하고 린트 단계가 깔끔해야 함34# Claude Code: 반복 실행되는 클라우드 작업 (최소 1시간 간격)5/schedule 매일 오전 9시에 PR 분류 작업 실행67# Codex: 자동화 프롬프트 (주기는 양식에서 설정)8"평일 오전 9시: 열린 PR을 스캔하고, CI 실패 또는 리뷰어 부재를 플래그 지정하여 Triage에 게시"
중단 조건을 계약서처럼 명확하게 작성하세요. "test/auth 디렉토리의 모든 테스트 통과"는 계약서입니다. "더 좋게 만들어"는 루프가 월급날까지 계속 실행되게 만드는 방법입니다.
4. 작업트리(Worktree)는 병렬 에이전트들이 서로 충돌하는 것을 방지한다
두 개 이상의 에이전트를 실행하는 순간, 실패 양상이 바뀝니다. 더 이상 모델 문제가 아닙니다. 아무도 이야기하지 않는 상태에서 두 명의 엔지니어가 같은 코드 라인에 커밋하는 것과 같은 혼란, 즉 두 에이전트가 동일한 파일을 쓰는 문제가 발생합니다.
Git 작업트리는 에이전트들 사이의 벽입니다: 저장소 히스토리를 공유하지만 각각 자체 브랜치에 있는 별도의 작업 디렉토리로, 한 에이전트의 편집이 다른 에이전트의 작업 공간에 영향을 미칠 수 없습니다.
1# Claude Code: 에이전트당 격리된 체크아웃2claude --worktree feature-auth34# 또는 하위 에이전트의 .claude/agents/<name>.md 프론트매터에서:5# isolation: worktree67# Codex: 스레드를 열 때 "Worktree" 선택 (각각 분리된 HEAD)
도구가 언급하지 않는 한 가지 주의사항이 있습니다. 작업트리는 충돌을 제거할 뿐, 병목 현상을 해결하지는 않습니다. 당신 여전히 성능의 한계입니다. 아무리 많은 에이전트를 시작하더라도, 당신의 리뷰 처리 능력만큼만 신뢰할 수 있습니다.
5. 스킬(Skills)은 당신의 의도를 한 번만 작성하여 외부에 저장하는 것이다
에이전트는 매번 실행을 차갑게 시작하며, 당신 의도의 빈틈을 자신감 넘치는 추측으로 채웁니다. 스킬은 모델이 매번 읽는 곳에 그 의도를 기록하여 추측을 중단시키는 것입니다.
두 도구 모두 형식은 동일합니다: 명령어와 설명이 담긴 SKILL.md 파일과 필요한 스크립트를 포함하는 폴더입니다. 이름으로 호출하거나 작업 설명과 일치할 때 실행되며, 이것이 바로 평범하고 직설적인 설명이 교묘한 설명보다 나은 이유입니다.
1# .claude/skills/triage/SKILL.md (Codex: ~/.agents/skills/triage/SKILL.md)2---3name: triage4description: 어제의 CI 실패, 열린 이슈, 최근 커밋을 읽고 각 결과를 STATUS.md에5 작업으로 작성합니다.6---71. 실패한 CI를 가져와 근본 원인별로 그룹화합니다.82. 각각을 원인이 된 열린 이슈 또는 커밋과 연결합니다.93. 실제 발견 사항당 하나의 STATUS.md 작업을 작성합니다. 잡음은 건너뜁니다.
스킬이 없으면 매 사이클마다 프로젝트를 처음부터 다시 학습합니다. 스킬이 있으면 루프는 매일 아침 조금씩 더 정교해집니다.
6. 커넥터(Connectors)는 루프가 단순히 말하는 것을 넘어 행동할 수 있게 한다
파일 시스템만 볼 수 있는 루프는 장난감에 불과합니다. 공유 MCP 표준을 기반으로 구축된 커넥터는 에이전트가 이슈 트래커를 읽고, 스테이징 API에 접근하고, 데이터베이스를 쿼리하고, 채널에 게시할 수 있게 해줍니다.
1# Claude Code2claude mcp add --transport http linear https://mcp.linear.app/mcp34# Codex5codex mcp add linear --url https://mcp.linear.app/mcp
이것이 "여기 수정 사항이 있습니다"라고 말하는 에이전트와, 풀 리퀘스트를 열고, 티켓을 연결하고, 스스로 통과를 보고하는 루프 사이의 차이를 만듭니다. 두 도구 모두 MCP를 사용하기 때문에, 한 도구를 위해 연결한 커넥터는 일반적으로 다른 도구에서도 사용할 수 있습니다.
7. 하위 에이전트(Sub-agents)는 생성자와 검증자를 분리한다
모든 루프에서 가장 가치 있는 움직임은 코드를 작성하는 에이전트와 코드를 검사하는 에이전트를 분리하는 것입니다.
자신의 작업을 검토하는 모델은 항상 합격점을 줍니다. 다른 지침과, 이상적으로는 다른 모델을 가진 두 번째 에이전트가 첫 번째 에이전트가 스스로 납득한 오류를 발견합니다.
1# Codex: .codex/agents/reviewer.toml2name = "reviewer"3description = "적대적 PR 리뷰어: 정확성, 보안, 누락된 테스트 확인."4developer_instructions = "소유자처럼 리뷰하세요. 작성자가 틀렸다고 가정하고5 diff가 그 반대를 증명할 때까지 기다리세요."6model_reasoning_effort = "high"78# Claude Code: .claude/agents/reviewer.md 프론트매터9# name: reviewer10# description: 적대적 리뷰어. 코드 변경 후 사용.11# model: opus
하나는 탐색하고, 하나는 구현하며, 다른 하나는 명세와 비교하여 검증합니다. 이것이 /goal이 내부적으로 수행하는 방식입니다: 새로운 모델이 작업 완료 여부를 판단합니다. 두 번째 의견에는 비용(토큰)이 발생합니다. 각 에이전트가 자체 모델과 도구를 실행하기 때문에, 잘못되었을 때 비용이 많이 드는 부분에 사용하는 것이 현명합니다.
8. 실제 루프의 예시
여섯 가지 요소를 결합하면 단일 스레드가 하나의 작은 기계가 됩니다.
매일 아침 예약된 자동화가 저장소에서 실행됩니다. 분류 스킬을 호출하여 전날 밤의 CI 실패, 열린 이슈, 최근 커밋을 읽고 각각의 실제 발견 사항을 STATUS.md에 기록합니다. 실행할 가치가 있는 각 발견 사항에 대해 루프는 격리된 작업트리를 열고, 한 하위 에이전트는 수정 초안을 작성하고 다른 하위 에이전트는 사용자 스킬 및 테스트와 비교하여 검토합니다. 커넥터는 PR을 열고 티켓을 업데이트합니다. 처리할 수 없는 사항은 Triage 받은 편지함에서 대기합니다. STATUS.md는 통과한 사항과 여전히 열려 있는 사항을 기억하므로, 내일은 오늘 중단된 지점부터 다시 시작됩니다.
실제로 아침에 마주하게 되는 것은 로그의 벽이 아닌 짧은 인수인계 메시지입니다:
1# 오전 9:00 — 루프의 야간 인수인계 (Triage 받은 편지함)2병합 준비 완료3 PR #218 test/charts 내 변덕스러운 테스트 수정 CI 통과4 PR #219 429 오류 시 웹훅 재시도, 백오프 테스트 추가 CI 통과5당신의 결정 필요6 auth/session.ts 이 문제를 해결하는 두 가지 안전한 방법이 있습니다; 저는 어느 쪽도 선택하지 않았습니다, 당신이 결정하세요.7조용함8 7개의 예약 실행이 아무것도 찾지 못해 자동 보관됨
당신은 한 번 설계했습니다. 프롬프트는 전혀 입력하지 않았습니다.
9. 자리를 비우기 전에 제동 장치를 먼저 구축하라
아무도 가르쳐주지 않는 절반이며, 루프가 자산인지 부채인지를 결정합니다.
그 47,000달러 청구서는 교활한 모델이 제멋대로 굴어서 발생한 것이 아닙니다. 분석기와 검증기라는 두 에이전트가 서로 정중하게 더 많은 작업을 요청했고, 단계 제한, 예산 상한, 중단 조건이 전혀 없었기 때문입니다. 11일 동안 실행되었습니다. 하나의 제한 장치만 있었어도 첫날에 중단되었을 것입니다.
출력 성능을 높이기 전에 제동 장치를 먼저 설치하십시오. 브레이크 페달을 먼저 장착하기 전에는 엔진을 출시하지 마십시오.
1# 자리를 비우기 전에 이것들을 먼저 장착하세요:2- 단계 제한: --max-turns 50 (하드 스탑, 예외 없음)3- 예산 상한: claude -p --max-budget-usd 10 (프린트 모드; 단계별)4- 피해 범위: 하나의 작업트리, 하나의 브랜치, src/ 외부는 읽기 전용5- 차단기: 동일 도구 + 동일 인수가 3회 연속 = 중단6- 데드맨 스위치: 각 실행마다 STATUS.md에 하트비트 작성; 침묵은 당신을 호출
루프의 범위는 원하는 작업이 아니라 파괴할 수 있는 것을 기준으로 정하세요: 어떤 저장소, 어떤 브랜치, 얼마나 많은 비용, 강제 종료 전까지 몇 단계인지. 피해 범위를 먼저 선택하고, 작업은 그 다음에 선택하세요.
그리고 정직하게 비용을 산정하세요. Steinberger의 100개 에이전트 함대는 실제이며, 한 달에 약 130만 달러가 소요됩니다. 이것이 가능한 이유는 OpenAI가 현재 그를 고용하여 비용을 지불하고 있기 때문입니다. 최첨단 사례는 후원을 받습니다. 당신의 경우는 그렇지 않습니다. 20달러에서 200달러 요금제에서 수익을 내는 루프는 작고, 제한적이며, 떼가 아닌 단 하나의 지루한 작업을 대상으로 합니다.
1비용 분포 (모두 실제 사례로, 지난 6개월간)2-----------------------------------------------------------------330일 동안 259개의 PR 한 명의 엔지니어, 100% Claude가 작성411일 동안 47,000달러 제한 장치 없이, 아무도 감시하지 않는 통제 불능 루프5월 약 130만 달러 100개 에이전트 함대 (비용은 후원받음)6-----------------------------------------------------------------7동일한 기술입니다. 차이는 제동 장치입니다.
10. 루프가 실패하는 방식
실패하는 모든 루프는 네 가지 방식 중 하나로 죽습니다. 지금 이름을 익혀 두면, 새벽 3시에 문제를 발견할 수 있습니다.
통제 불능 재귀. 두 에이전트가 서로에게 영원히 작업을 제공합니다. 해결책은 위에서 언급한 단계 제한과 예산 상한이며, 더 교묘한 방법은 없습니다.
침묵형 실패. 한 개발자의 야간 실행이 컨텍스트 창을 가득 채워 중단된 후, 계속 살아있는 것처럼 보이면서 동일한 장애물에 재개를 시도했습니다. 루프는 몇 시간 동안 죽어 있어도 진행 상황을 계속 보고할 수 있습니다. 해결책은 하트비트와 단계별로 새로운 컨텍스트를 사용하는 것이지, 하나의 끝없는 실행이 아닙니다.
무작위 탐색. 검증 가능한 중단 조건이 없으면 루프는 목표를 향해 나아가지 않고 표류합니다. 통과하는 테스트 스위트는 도달 가능한 고정점입니다. "완료된 것 같다"는 고정점이 아닙니다.
이해 부채. 루프가 당신이 작성하지 않은 코드를 더 빨리 생산할수록, 저장소가 실제로 하는 일과 당신이 이해하는 것 사이의 격차는 더 커집니다. 읽지 않은 채로 오래 실행하면, 당신은 더 이상 엔지니어가 아니라 고무 도장이 됩니다. 해결책은 루프가 절대 건너뛸 수 없는 사람의 검토 관문입니다.
11. 루프를 구축하라. 그러나 엔지니어로 남아라.
두 사람이 똑같은 루프를 구축해도 정반대의 결과를 얻을 수 있습니다. 한 사람은 뼛속까지 이해하는 작업을 더 빠르게 진행하기 위해 사용합니다. 다른 사람은 작업 자체를 더 이상 이해하지 않기 위해 사용합니다. 루프는 그 둘을 구분할 수 없습니다. 당신은 구분할 수 있습니다.
Cherny의 요점은 작업이 쉬워졌다는 것이 결코 아닙니다. 요점은 지렛대가 프롬프트에서 루프로, 그리고 타이핑에서 판단력으로 이동했다는 것입니다. 이것은 프롬프트를 입력하는 것보다 더 어려운 작업이지, 더 쉬운 작업이 아닙니다.
따라서 여기 행동 계획이 있습니다. 의도적으로 작게 시작하는 이유는 이 분야가 아직 초기이고 비용이 급변하기 때문입니다. 내일 아침, 당신이 아직 수동으로 처리하는 가장 지루한 작업, CI 분류, 오래된 이슈 정리, 변덕스러운 테스트 추적 등을 선택하고 하나의 제한된 루프로 감싸십시오. 제동 장치를 먼저 설치하세요. 루프가 생성하는 모든 diff를 여전히 읽을 수 있을 정도로 작게 유지하십시오.
한 달에 200개의 풀 리퀘스트를 처리하는 사람은 100개의 에이전트로 시작하지 않았습니다. 그들은 신뢰할 수 있는 하나의 루프로 시작했고, 내내 엔지니어로 남았습니다. 그 하나의 루프를 구축하십시오.
