대부분의 개발자는 아직도 코딩 에이전트에게 프롬프트를 손으로 입력합니다. 타이핑하고, 기다리고, diff를 읽고, 다시 타이핑하죠. 에이전트에게 대신 프롬프트를 던지는 루프를 작성해 본 빌더는 10명 중 1명도 되지 않습니다.
자동화도 없고, 상태 파일도 없고, 검증기도 없고, 일정도 없습니다. 이제 지렛대는 다른 곳으로 옮겨갔습니다. 프롬프트를 더 잘 타이핑하는 것보다, 프롬프트를 던지는 시스템을 설계하는 일이 중요해졌습니다. 이 글은 프롬프터에서 루프 설계자로 넘어가기 위한 14단계 로드맵입니다.
이 14단계는 Anthropic의 엔지니어링 문서, Addy Osmani의 루프 엔지니어링 장문 글, 최근 측정 연구들을 바탕으로 정리했습니다.
세 층으로 나누면 이해하기 쉽습니다. 먼저 정말 루프가 필요한지 판단합니다. 그다음에는 다섯 가지 구성 블록을 익힙니다. 마지막으로 자신을 해치지 않는 가장 작은 루프를 만듭니다.
14단계. 3개 층. 프롬프트를 반복 입력하는 데서 멈추지 말고, 이제 루프를 설계할 차례입니다.
Part 1. 왜 필요한가, 그리고 언제 필요한가
01. 루프 엔지니어링은 프롬프터로서의 나를 교체하는 일입니다
지난 2년 동안 코딩 에이전트에서 결과를 얻는 방식은 대체로 비슷했습니다. 프롬프트를 쓰고, 맥락을 공유하고, 돌아온 답을 읽습니다. 그러고 나서 다음 프롬프트를 다시 씁니다. 에이전트는 도구였고, 우리는 그 도구를 계속 손에 쥐고 있었습니다. 그런데 이 방식은 끝나가고 있습니다.
루프 엔지니어링은 작은 시스템을 만드는 일입니다. 이 시스템은 할 일을 찾고, 에이전트에게 넘기고, 결과를 확인합니다. 무슨 일이 있었는지 기록하고, 다음 행동도 스스로 정합니다. 사람은 그 시스템을 한 번 설계합니다. 그다음부터는 시스템이 에이전트에게 프롬프트를 던집니다.
Addy Osmani는 이것을 여섯 부분으로 나눕니다.
Anthropic 엔지니어들은 2024년에 비해 하루에 병합하는 코드가 8배 늘었다고 말합니다. 다만 Anthropic 자신도 이 수치가 “실제 생산성 향상을 거의 확실히 과장한 값”이라고 덧붙입니다.
숫자는 논쟁적일 수 있습니다. 다만 작동 방식은 분명합니다. 지렛대는 이제 프롬프트를 직접 입력하는 일이 아니라, 프롬프트를 던지는 루프를 설계하는 일 쪽에 있습니다.
02. 무엇이든 만들기 전에 4조건 테스트를 먼저 하세요
루프가 비용을 감당할 만큼 가치를 내려면 네 가지 조건이 맞아야 합니다. 하나라도 빠지면 루프는 돌려주는 것보다 더 많은 비용을 먹습니다. AlphaSignal의 분석에서 가장 솔직한 부분도, 대부분의 X 스레드가 건너뛰는 지점도 바로 여기입니다.
작업이 반복됩니다. 루프는 설정 비용을 여러 번의 실행에 나누어 회수합니다. 한 번만 하는 일이라면 좋은 프롬프트 하나가 더 빠르고 저렴합니다. 매주 돌아오지 않는 일이라면 루프라기보다 한 번 실행한 스크립트에 가깝습니다.
검증이 자동으로 돌아갑니다. 루프에는 내가 자리에 없어도 결과를 탈락시킬 장치가 필요합니다. 테스트 스위트, 타입 체커, 린터, 빌드 같은 것들이죠. 자동 검증이 없으면 결국 내가 다시 의자에 앉아 모든 diff를 읽어야 합니다. 바로 그 일을 없애려고 루프를 만든 것인데 말입니다.
토큰 예산이 낭비를 견딜 수 있습니다. 루프는 맥락을 다시 읽고, 재시도하고, 탐색합니다. 결과가 실제로 배포되지 않아도 토큰은 나갑니다. 이 기법은 예산이 있을수록 잘 확장됩니다. 그래서 토큰이 사실상 무료인 사람에게는 너무 당연해 보이고, 종량제 요금을 쓰는 사람에게는 무모해 보입니다.
에이전트에게 시니어 엔지니어 수준의 도구가 있습니다. 로그, 재현 환경, 자신이 쓴 코드를 실행해 보고 무엇이 깨지는지 확인할 능력이 필요합니다. 이것이 없으면 루프는 눈을 감고 반복하는 셈입니다.
03. 누가 이기고, 누가 지는가. 루프는 쓸 수 있는 쪽에 유리합니다
경제성은 누구에게나 똑같이 적용되지 않습니다. 루프 엔지니어링이 당연하다고 말하는 사람들은 대체로 토큰을 거의 제한 없이 씁니다.
반대로 루프가 무모하다고 느껴지는 사람은 보통 월 20달러 소비자 요금제에서 무거운 검증 루프를 돌립니다. 그러다 한도나 예상치 못한 청구서를 마주하죠.
실제로 이득을 보는 쪽은 비교적 분명합니다.
반복적이고 기계적으로 검증 가능한 작업이 있고, 그것을 돌릴 예산이 있는 팀. 예를 들어 지속적인 테스트 실패 분류, 의존성 업데이트, 린트 자동 수정, 테스트가 탄탄한 코드베이스에서의 이슈-PR 초안 작업이 여기에 들어갑니다.
이미 강한 테스트 스위트를 갖춘 코드베이스. 주니어 엔지니어가 체크리스트를 보고 처리할 수 있고, 실수는 테스트 스위트가 잡아낼 수 있다면 루프와 잘 맞습니다.
멀티 에이전트 패턴을 이미 쓰고 있는 비동기 중심 팀. 이런 팀에게는 루틴이 빠져 있던 오케스트레이션 계층입니다.
반대로, 지금은 건너뛰는 편이 나은 경우도 있습니다.
소비자 요금제를 쓰는 1인 개발자. 생산성 이득이 오기 전에 토큰 요금이 먼저 옵니다.
자동 검증이 없는 코드에서 일하는 사람. 실제 검증이 빠진 루프는 에이전트가 자기 말에 계속 동의하는 구조가 됩니다.
진짜 병목이 타이핑 속도가 아니라 리뷰 용량인 팀. 루프는 더 많은 코드를 만듭니다. 이미 리뷰가 병목이었다면 줄만 더 길어집니다.
한 번만 하는 작업, 탐색 작업, 또는 “완료”가 판단의 문제인 일에는 아직도 잘 겨냥한 프롬프트 하나가 이깁니다. 솔직히 말하면 이렇습니다. 루프 엔지니어링은 분명 의미가 있습니다. 다만 대부분의 개발자에게는 아직 필요하지 않습니다.
04. 30초 루프 체크
2단계의 4조건 테스트가 전략적 판단이라면, 이것은 전술적 판단입니다. 특정 작업을 루프로 바꾸기 전에 빠르게 확인하는 체크리스트라고 보면 됩니다.
하나라도 빠지면 아직은 수동 프롬프트로 남겨두세요.
1. 작업이 최소 매주 발생합니다. 그보다 덜 자주 발생하면 설정 비용을 회수하지 못합니다.
2. 테스트, 타입 체크, 빌드, 린터가 나쁜 결과를 거절할 수 있습니다. 자동 게이트가 없다면 에이전트가 자기 숙제를 스스로 채점하는 셈입니다.
3. 에이전트가 자신이 바꾸는 코드를 실행할 수 있습니다. 재현 환경이 없으면 반복은 눈먼 반복입니다.
4. 루프에 강제 중단 조건이 있습니다. 토큰 예산, 반복 횟수, 시간 제한이 필요합니다. 이것이 없으면 누군가 청구서를 보고 알아차릴 때까지 루프가 돌아갑니다.
5. 병합, 배포, 의존성 변경 전에는 사람이 리뷰합니다. 되돌리기 어려운 행동은 실행 전에 사람의 승인 게이트가 필요합니다.
처음 시도하기에 좋은 루프는 이런 것들입니다.
CI 실패 분류. 매일 밤 실패를 훑고 원인을 나눈 뒤, 쉬운 건은 수정 PR 초안을 엽니다.
의존성 업데이트 PR. 매주 업데이트를 확인하고, 호환성을 테스트한 다음 PR을 엽니다.
린트 자동 수정. PR이 열릴 때마다 스타일 수정을 자동으로 적용합니다.
불안정 테스트 재현. 어떤 가설이 테스트를 통과할 때까지 반복합니다.
테스트가 강한 코드에서 이슈-PR 초안 만들기. 나쁜 결과는 테스트 스위트가 거절합니다.
반대로 첫 루프로 삼기에는 좋지 않은 작업도 있습니다. 이런 일은 사람이 자리에 있어야 합니다.
아키텍처 재작성
인증 또는 결제 코드
프로덕션 배포
모호한 제품 작업
“완료”가 판단의 문제인 모든 일
Part 2. 다섯 가지 구성 블록
05. 자동화: 루프의 심장박동
자동화는 루프를 진짜 루프로 만들어 줍니다. 한 번 실행하고 끝나는 작업이 아니게 해 주는 것이죠. 자동화는 일정, 이벤트, 트리거 조건에 따라 실행됩니다. 말하자면 심장박동입니다. 루프의 다른 요소들은 모두 이 박동에 맞춰 움직입니다.
많이 쓰는 두 도구에서는 이런 식으로 나타납니다.
Codex. Automations 탭에서 프로젝트를 고르고, 프롬프트와 실행 주기를 정한 뒤 로컬 체크아웃 또는 백그라운드 worktree를 선택합니다. 무언가를 찾은 실행은 Triage inbox에 들어가고, 아무것도 찾지 못한 실행은 스스로 보관됩니다.
Claude Code에서는 같은 모양을 세 가지 기본 요소로 조합합니다.
/loop, Desktop scheduled tasks, Routines입니다. /loop는 세션 범위의 주기를 만들고, Desktop scheduled tasks는 재시작을 넘어 살아남는 예약 작업을 만들며, Routines는 노트북이 꺼져 있어도 클라우드에서 실행됩니다. 여기에 lifecycle event를 위한 hook을 함께 붙입니다.
작동하는 루프와 비싼 루프를 가르는 자동화 내부 요소도 있습니다. 핵심은 두 가지입니다.
/loop는 주기적으로 다시 실행합니다. 상태와 관계없이 정기적으로 확인하고 싶을 때 씁니다.
/goal은 작성한 조건이 실제로 참이 될 때까지 계속 진행합니다. 별도의 작은 모델이 완료 여부를 확인하므로, 코드를 작성한 에이전트가 스스로 채점하지 않습니다.
이 구조는 메이커-체커 분리를 중단 조건에까지 적용한 사례입니다.
> /loop 30m /goal test/auth의 모든 테스트가 통과하고 lint가 깨끗하다.
src/auth에서 새 실패를 스캔하고,
claude/auth-fixes에서 수정안을 제안한 뒤,
목표 조건이 충족되면 draft PR을 연다.
▲ Claude
CronCreate(*/30 * * * * : auth quality loop)
Stop condition: tests pass + lint clean (verified by checker)
✓ 예약되었습니다. 중간 완료 상태를 지나도 계속 진행하며,
독립 체커가 /goal 조건 충족을 확인할 때까지 멈추지 않습니다.
06. Worktree: 혼란 없이 병렬로 진행하기
에이전트를 둘 이상 돌리는 순간 파일 충돌이 시작됩니다. 두 에이전트가 같은 파일을 쓰는 상황은, 두 엔지니어가 서로 말하지 않고 같은 줄을 동시에 커밋하는 것과 비슷합니다.
Git worktree는 이 문제를 풀어 줍니다. 같은 저장소 기록을 공유하되, 각자 다른 브랜치의 별도 작업 디렉터리를 갖게 합니다. 그래서 한 에이전트의 수정이 다른 에이전트의 체크아웃을 물리적으로 건드릴 수 없습니다.
두 도구에서는 이런 모습입니다.
Codex는 worktree 지원을 내장합니다. 여러 스레드가 같은 저장소를 동시에 다뤄도 서로 부딪히지 않습니다.
Claude Code는 git worktree를 직접 노출합니다. 별도 체크아웃에서 세션을 여는 --worktree 플래그가 있고, 서브에이전트에는 isolation: worktree 설정을 둘 수 있습니다. 그러면 각 helper가 새 체크아웃을 받아 작업하고, 끝난 뒤 스스로 정리합니다.
Worktree는 기계적인 충돌을 없애 줍니다. 그래도 한계는 여전히 사람에게 있습니다. 실제로 몇 개의 병렬 에이전트를 운영할 수 있는지는 도구가 아니라 당신의 리뷰 처리량이 결정합니다.
07. Skill: 프로젝트 지식은 한 번 쓰고, 매 실행마다 읽게 하세요
Skill은 매 세션마다 같은 프로젝트 맥락을 다시 설명하지 않게 해 주는 장치입니다. 양쪽 도구 모두 형식은 같습니다. SKILL.md가 들어 있는 폴더 하나를 만들고, 그 안에 지시사항과 메타데이터를 둡니다. 필요하면 스크립트, 참고자료, 에셋도 함께 넣습니다.
루프에서 Skill은 특히 중요합니다. Skill이 없으면 루프가 매 주기마다 프로젝트 맥락을 처음부터 다시 추론합니다. Skill이 있으면 의도가 쌓입니다.
컨벤션, 빌드 단계, “예전에 그 사건 때문에 우리는 이렇게 하지 않는다” 같은 지식은 한 번 바깥에 적어 둡니다. 그리고 모든 실행이 그 파일을 읽게 합니다.
---
name: ci-triage
description: CI 실패를 근본 원인별로 분류합니다. env, flake, real bug,
dependency, infra로 나누고, 쉬운 건은 수정 초안을 만들며,
나머지는 에스컬레이션합니다.
워크플로 실행이 실패했거나 아침 triage loop가 돌 때 실행하세요.
---
# CI triage skill
## Classification rules
- env: secret 누락, 잘못된 env var, 인프라 미구성. # human
- flake: 코드 변경 없이 재시도하면 통과. # retry once, then file
- bug: 최근 커밋과 연결된 결정적 실패. # draft fix
- dependency: 버전 업데이트와 연결된 실패. # draft rollback
- infra: timeout, OOM, runner issue. # escalate
## Fix patterns
- Auth tests -> src/auth/middleware부터 확인
- Database tests -> CI 환경에 migration이 적용됐는지 확인
- E2E tests -> 최신 UI snapshot과 selector 비교
## Never do
- 실패 테스트를 비활성화하지 마세요. 항상 escalation으로 기록합니다.
- 사람 승인 없이 CI 설정을 수정하지 마세요.
- src/payments/ 또는 src/billing/은 건드리지 마세요. (claude/permissions.md)
## State
각 실행 후 STATE.md를 업데이트합니다.
확인한 파일 경로, 분류 결과, 연 PR, 에스컬레이션 항목을 기록합니다.
08. Connector: 루프가 MCP로 실제 도구를 만납니다
파일시스템만 볼 수 있는 루프는 아주 작은 루프입니다. Model Context Protocol, 즉 MCP 위에 만든 connector를 붙이면 에이전트가 이슈 트래커를 읽고, 데이터베이스를 조회하고, staging API를 호출하고, Slack에 메시지를 남길 수 있습니다.
Codex와 Claude Code는 모두 MCP를 이해합니다. 그래서 한쪽을 위해 만든 connector가 다른 쪽에서도 대체로 그대로 작동합니다.
이 차이는 큽니다. 에이전트가 “이게 수정안입니다”라고 말하는 수준에서 끝나지 않습니다. 루프가 PR을 열고, Linear 티켓을 연결하고, CI가 초록색이 되면 채널에 알리는 수준으로 바뀝니다.
Connector가 있으면 루프는 실제 환경 안에서 행동합니다. “할 수 있다면 이렇게 하겠다”라고 말하는 데서 끝나지 않습니다. 그 차이를 만드는 장치가 connector입니다.
루프 작업에서 비용을 가장 빨리 회수하는 connector는 대체로 다음 순서입니다.
GitHub. 저장소 읽기, 브랜치 생성, PR 열기, 이슈 댓글 달기, webhook event 반응. 코드 루프라면 첫날부터 가장 큰 이득을 줍니다.
Linear 또는 Jira. 루프 진행 상황에 따라 티켓을 업데이트하고, PR을 이슈에 연결하고, 검증이 통과하면 항목을 자동으로 닫습니다.
Slack. triage 결과를 올리고, 에스컬레이션이 필요할 때 사람을 부르며, 밤새 실행된 결과를 아침에 요약합니다.
Sentry 또는 오류 추적기. 루프가 실시간 알림을 조사하고, 자주 발생하는 문제의 수정 초안을 만들 수 있습니다.
09. Sub-agent: 만드는 쪽과 검사하는 쪽을 떨어뜨리세요
루프에서 가장 유용한 구조적 선택은 코드를 쓰는 에이전트와 확인하는 에이전트를 떼어 놓는 일입니다.
Osmani의 표현은 정확합니다. 코드를 쓴 모델은 “자기 숙제를 채점하기에는 너무 친절합니다.” 그래서 다른 지시사항을 가진 두 번째 에이전트가 필요합니다. 때로는 다른 모델을 쓰는 에이전트가 첫 번째 에이전트가 스스로 납득해 버린 문제를 잡아냅니다.
이 구조는 Anthropic이 2024년 12월 엔지니어링 글에서 설명한 evaluator-optimizer 패턴에 새 이름을 붙인 것입니다. 한 모델이 만들고, 다른 모델이 비판한 뒤 다시 반복합니다. 용어는 2026년에 유행했습니다. 다만 구조 자체는 이미 18개월 전에 문서화되어 있었습니다.
두 도구에서 sub-agent는 이렇게 나타납니다.
Codex는 요청할 때만 subagent를 만들고, 동시에 실행한 뒤 결과를 하나의 답변으로 접어 넣습니다. 자체 에이전트는 .codex/agents/ 안의 TOML 파일로 정의합니다. 이름, 설명, 지시사항을 적고, 필요할 때 모델과 reasoning effort를 둡니다.
보안 리뷰어는 강한 모델에 높은 reasoning effort를 줄 수 있고, explorer는 빠른 read-only 모델로 둘 수 있습니다.
Claude Code도 .claude/agents/ 안의 subagent와, 작업을 서로 넘기는 agent team으로 같은 구조를 만듭니다.
흔한 분리는 세 가지입니다. 한 에이전트가 탐색하고, 하나가 구현하고, 나머지 하나가 spec에 맞춰 검증합니다.
루프 안에서 이것이 특히 중요한 이유는 간단합니다. 루프는 내가 보지 않는 동안 실행됩니다. 믿을 만한 verifier가 있어야 잠시 자리를 비울 수 있습니다.
Sub-agent는 더 많은 토큰을 씁니다. 각자 모델과 도구 작업을 하기 때문입니다. 그러니 두 번째 의견이 비용을 낼 가치가 있는 곳에만 쓰세요.
Part 3. 제대로 만들거나, 만들지 마세요
10. 상태 파일: 에이전트는 잊습니다. 파일은 잊지 않습니다
너무 단순해서 중요하지 않아 보일 수 있습니다. 하지만 실제로는 작동하는 루프의 척추입니다. Markdown 파일, Linear 보드, JSON 상태 파일처럼 단일 대화 바깥에 남아 완료된 일과 다음 일을 보관합니다.
이유는 단순합니다. 에이전트는 기본적으로 기억이 짧습니다. 이번 세션에서 배운 것도 어딘가에 적어 두지 않으면 내일이면 사라집니다.
Osmani의 규칙도 간단합니다. 에이전트는 잊습니다. 저장소는 잊지 않습니다. 지속 상태가 없는 루프는 매 실행마다 처음부터 다시 시작하고, 상태가 있는 루프는 이어서 진행합니다.
# Loop state · ci-triage
## Last run
2026-06-09 03:30 UTC · 실패 7건 분류, 수정 초안 3건, 에스컬레이션 4건
## In progress
- claude/fix-auth-token-refresh — 로컬 테스트 통과, CI 대기 중
- claude/fix-flaky-payment-webhook — 재시도 패턴 적용, 모니터링 중
## Completed today
- claude/bump-axios-1.7.4 -> merged (CI green, deps loop verified)
- claude/lint-fix-pass-june-9 -> merged
## Escalated to humans
- src/billing/refund.ts — 세 가지 방식으로 테스트 실패, 근본 원인 불명확
- ci/staging-runner — 인프라 timeout, 코드 문제가 아님
## Lessons learned (write here, not in chat)
- 2026-06-08: 이 Windows runner에서 PowerShell은 TLS 1.2 문제를 겪음. bash 사용.
- 2026-06-07: tests/e2e/checkout은 env에 Stripe webhook secret 필요. 없으면 skip.
## Stop conditions met since last review
- /goal “all tests pass + lint clean” achieved on commit 3a7b8c1 at 02:14 UTC
상태 파일은 보통 두 곳 중 하나에 둡니다.
저장소 안의 Markdown. 루트나 .claude/ 안에 STATE.md를 둡니다. 버전 관리가 되고, 단순하며, diff로 읽기 쉽습니다. 1인 작업이나 작은 팀에 좋습니다.
외부 시스템. Linear, GitHub Issues, 데이터베이스를 씁니다. 여러 저장소를 넘어 살아남고, 조회할 수 있으며, 팀 전체가 루프의 행동을 볼 수 있습니다. 여러 사람이 봐야 하는 production loop에 좋습니다.
오래 실행되어 목표에서 벗어날 위험이 있는 루프라면, 상태 파일을 높은 수준의 spec과 함께 두세요. 예를 들어 매 실행마다 VISION.md나 AGENTS.md를 다시 읽게 하는 방식입니다. 상태는 에이전트에게 “현재 어디에 있는지”를 알려 줍니다. spec은 “어디로 가야 하는지”를 알려 줍니다.
11. 최소 실행 가능 루프
2단계의 4조건 테스트를 통과했다면, 멋진 것을 붙이기 전에 작동하는 가장 작은 루프부터 만드세요. 네 부분이면 충분합니다. 처음부터 swarm까지 갈 필요는 없습니다.
네 부분을 쉬운 말로 풀면 이렇습니다.
자동화 하나. 명확한 조건에서 멈추는 예약 실행입니다. Claude Code에서는 /loop를, Codex에서는 automation을 씁니다. 작성한 조건이 참이 될 때까지 실행하고 싶다면 /goal을 함께 붙입니다.
Skill 하나. 에이전트가 매번 처음부터 다시 추론할 프로젝트 맥락을 SKILL.md에 저장합니다.
상태 파일 하나. 끝낸 일과 다음 일을 기록하는 Markdown 파일 또는 Linear 보드입니다. 내일 실행은 처음부터가 아니라 이어서 시작합니다.
게이트 하나. 나쁜 작업을 자동으로 실패시키는 테스트, 타입 체크, 빌드입니다. 루프가 도움을 주는지, 아니면 돈만 쓰는지를 여기서 가릅니다.
순서가 중요합니다. 먼저 수동 실행 하나를 안정적으로 만듭니다. 그것을 skill로 바꿉니다. 그다음 loop로 감싸고, 마지막으로 schedule합니다. 이 순서를 건너뛰면 production에서 루프가 실패합니다.
중요한 지표는 토큰 사용량도, 시도한 작업 수도, 예약한 루프 수도 아닙니다. 승인된 변경 1건당 비용입니다. 승인 변경률이 50%보다 낮다면, 루프가 덜어 주기로 했던 리뷰 일을 내가 다시 하고 있는 셈입니다. 그 루프는 손해를 보고 있습니다.
12. Ralph Wiggum loop: 조용히 실패하는 루프
엔지니어 Geoffrey Huntley가 이 실패 모드를 기록하고 이름을 붙였습니다. 작업이 끝났을 때만 완료 토큰을 내야 하는 에이전트가 너무 일찍 완료 토큰을 내고, 루프가 반쯤 끝난 작업에서 빠져나옵니다. 강한 게이트가 없으면 루프는 조용히 실패하면서 계속 비용을 씁니다.
Ralph Wiggum loop는 대체로 이런 상황에서 생깁니다.
실제 verifier가 없습니다. 두 번째 에이전트에게 그냥 “리뷰해 줘”라고만 요청하고 객관 신호를 두지 않습니다. 낙관주의자 둘이 서로 동의하는 구조입니다.
완료 조건이 부드럽습니다. 테스트, 빌드, 타입 체크가 아니라 에이전트의 판단으로 “done”을 정의합니다.
강제 중단이 없습니다. 성공이 검증될 때까지가 아니라, 외부 요인에 멈출 때까지 계속 돌아갑니다. 예를 들어 rate limit에 걸리거나, 사람이 비용을 보고 알아차릴 때까지입니다.
해결책은 11단계의 gate입니다. 작업을 객관적으로 실패시킬 무언가가 있어야 합니다. 통과하거나 실패하는 테스트, 컴파일되거나 실패하는 빌드, 0 또는 non-zero를 반환하는 린터입니다. 의견을 가진 verifier가 아닙니다.
함께 알아 둘 만한, 측정된 실패 모드도 있습니다.
긴 세션에서 목표가 흐려집니다. 각 요약 단계는 손실을 만듭니다. 47번째 턴쯤에는 “X를 하지 마라” 같은 제약이 사라질 수 있습니다. 완화책은 매 실행마다 VISION.md나 AGENTS.md를 다시 읽게 하는 것입니다.
자기 선호 편향. 코드를 쓴 에이전트는 자기 숙제를 채점할 때 너무 친절합니다. maker의 추론을 보지 않은 별도 verifier subagent가 완화책입니다.
Agentic laziness. 루프가 부분 완료 상태에서 “충분히 끝났다”고 선언합니다. 완화책은 신선한 모델이 객관적 중단 조건을 확인하는 /goal입니다.
13. 이해 부채와 인지적 항복
이 실패 모드는 루프가 나빠질수록이 아니라 좋아질수록 더 날카로워집니다. 두 이름 모두 Osmani의 글에서 가져왔습니다.
이해 부채. 루프가 내가 쓰지 않은 코드를 더 빨리 배포할수록, 저장소 안에 들어 있는 것과 내가 이해하는 것 사이의 거리가 커집니다. 정말 아픈 청구서는 토큰 청구서가 아닙니다. 팀에서 아무도 읽지 않은 시스템을 언젠가 디버깅해야 하는 날입니다.
인지적 항복. 스스로 의견을 형성하기를 멈추고, 루프가 돌려주는 것을 그대로 받아들이고 싶은 유혹입니다. 판단을 가지고 루프를 설계하면 치료제가 됩니다. 생각을 피하려고 루프를 설계하면 가속제가 됩니다. 같은 행동이지만 결과는 정반대입니다.
완화책은 의외로 기술적이지 않습니다.
diff를 읽으세요. 루프가 배포하는 것을 읽지 않으면, 이해 부채를 복리로 빌리는 셈입니다.
게이트를 표본 점검하세요. 루프가 연 PR 몇 개를 골라, 그 PR을 승인한 테스트가 실제로 내가 걱정하는 실패 모드를 잡는지 확인하세요. 게이트도 낡습니다.
아키텍처 작업은 루프에서 막으세요. 루프는 작고 기계적으로 확인 가능한 변경에만 두세요. 판단이 필요한 일을 만지는 순간 이해 부채가 빨라집니다.
동료와 함께 루프를 설계하세요. 루프를 설계할 때 두 번째 눈이 있으면, 루프가 앞으로 계속 악용할 사각지대를 미리 잡을 수 있습니다.
14. 보안 비용: 무인 루프는 무인 공격 표면입니다
무인으로 실행되는 루프는 무인으로 열려 있는 공격 표면이기도 합니다.
루프가 방어해야 하는 위협 모델은 다음과 같습니다.
생성된 코드가 리뷰 없이 배포됩니다. 루프는 사람이 읽을 수 있는 속도보다 빠르게 PR을 엽니다. SAST, 의존성 audit, secret scanning 같은 보안 검사가 게이트에 들어 있지 않으면 취약한 코드가 자동으로 병합될 수 있습니다.
Skill이 injection vector가 됩니다. 루프가 skill을 자동 설치하면, skill 설명에 숨어 있는 prompt injection도 그대로 물려받습니다. 설치 전에 skill 출처를 감사하세요.
로그에 credential이 남습니다. 오래 실행되는 루프에서 debug logging을 켜 두면, 모니터링하지 않는 로그 곳곳에 secret이 흩어집니다. production loop에서는 verbose logging을 끄고, 남기는 로그도 sanitize하세요.
권한 범위가 조금씩 넓어집니다. read-only 권한으로 테스트한 루프에 편의상 “쓰기 권한 하나만” 추가한 뒤 다시 감사하지 않는 일이 생깁니다. 30일마다 권한을 다시 확인하세요.
루프를 돈 먹는 구멍으로 만드는 실수들
4조건 테스트 없이 루프를 만듭니다. 2단계가 있는 데는 이유가 있습니다. 대부분의 개발자는 적어도 조건 하나에서 실패합니다.
객관적 게이트가 없습니다. 테스트, 타입 체크, 빌드 없이 두 번째 에이전트에게 “리뷰해 줘”라고만 요청하는 것은 낙관주의자를 한 명 더 세우는 일입니다.
한 에이전트가 작성과 검증을 모두 합니다. 자기 선호 편향입니다. maker가 자기 숙제를 채점하고, 늘 A+를 줍니다.
상태 파일이 없습니다. 내일 실행은 이어서 진행하지 못하고 처음부터 다시 시작합니다.
중단 조건이 모호합니다. “좋아 보이면 완료”는 조건이 아닙니다. 테스트 통과, 타입 통과, 빌드 성공처럼 확인 가능한 신호를 쓰세요.
토큰 예산 상한이 없습니다. 루프는 맥락을 다시 읽고 재시도합니다. 상한이 없으면 야심 찬 루프는 예상보다 5~10배 많은 토큰을 태웁니다.
무거운 검증을 소비자 요금제에서 돌립니다. 토큰 청구서든 rate limit이든, 둘 중 하나는 결국 찾아옵니다.
커뮤니티 skill을 자동 설치합니다. 감사된 skill 17,022개 중 520개가 credential을 유출합니다. 설치하기 전에 소스를 읽으세요.
판단이 필요한 작업에 루프를 씁니다. 아키텍처, 인증, 결제, 모호한 제품 결정이 여기에 해당합니다. 루프는 전략이 아니라 lint-and-fix에 두세요.
diff를 읽지 않습니다. 이해 부채를 복리로 쌓는 일입니다. 아무도 읽지 않은 시스템을 디버깅해야 하는 날은 토큰보다 훨씬 비쌉니다.
결론: 지렛대가 옮겨갔습니다. 당신의 일도 옮겨갔습니다
지난 2년 동안 코딩 에이전트와 일할 때의 지렛대는 프롬프트에 있었습니다. 더 나은 프롬프트, 더 나은 맥락, 더 나은 one-shot 결과가 중요했습니다.
그 단계는 끝나가고 있습니다. 에이전트가 충분히 좋아졌기 때문에 다음 지렛대는 한 층 위로 올라갔습니다. 이제 중요한 것은 시스템입니다. 에이전트가 무엇을, 언제, 어떤 게이트 아래에서 작업할지, 실행 사이에 어떤 상태를 남길지 정하는 시스템 말입니다.
다만 이 이야기의 솔직한 버전은 “모두가 서둘러 루프를 만들어야 한다”가 아닙니다. 대부분의 개발자에게는 아직 루프가 필요하지 않습니다. 작업이 반복되고, 검증이 자동으로 돌아가며, 예산이 낭비를 견딜 수 있고, 에이전트가 시니어 엔지니어의 도구를 갖춘 경우에만 필요합니다.
조건이 하나라도 빠지면 루프는 돌려주는 것보다 더 많은 비용을 씁니다.
테스트를 통과했다면 작게 시작하세요. 자동화 하나. Skill 하나. 상태 파일 하나. 게이트 하나. 먼저 수동 실행을 안정화하세요. 그것을 skill로 바꾸고, 루프로 감싼 뒤, 그다음 예약하세요. 순서가 중요합니다. 건너뛰면 아무도 이해하지 못하는 시스템에 돈을 내게 됩니다.
Cherny의 요지는 일이 쉬워졌다는 데 있지 않습니다. 지렛대의 위치가 옮겨갔다는 데 있습니다.
댓글 1
하네스엔지니어링에 이어 루프엔지니어링까지....