AI 코딩 업계에서 떠도는 주장이 있습니다: 코딩 에이전트에게 프롬프트를 직접 입력하지 말고, 대신 에이전트가 프롬프트를 입력하도록 설계된 루프를 디자인하라는 것입니다. 모든 새로운 것과 마찬가지로, 이 말은 자주 반복되지만 설명은 거의 되지 않습니다. 여기서는 실용적인 측면을 다룹니다: 에이전트 루프가 무엇인지, 왜 중요한지, 실제 운영 환경에서 어떻게 생겼는지에 대한 내용입니다.
아래는 제가 (Claude 의 도움을 받아) 일부 실험, 연구, 그리고 저희 [학생들](https://academy.dair.ai/) , 기술 창업자, AI 엔지니어, 스타트업과 나눈 대화에서 얻은 생각 중 일부입니다.
또한 최근 진행한 "[장기 실행 자율 코딩 에이전트](https://academy.dair.ai/events/cmplo7v3b000e04l1pxprat4d)" 라이브 세션도 이 모든 내용을 이해하는 좋은 출발점이 될 수 있습니다.
이 주장의 유래
"더 이상 코딩 에이전트에게 프롬프트를 입력해서는 안 됩니다. 에이전트에게 프롬프트를 입력하는 루프를 설계해야 합니다."Peter Steinberger (
@steipete ), 2026년 6월 7일. 조회수 220만.
Claude Code 의 창시자인 Boris Cherny 도 같은 관점을 다른 측면에서 제시합니다.
"저는 더 이상 Claude 에게 프롬프트를 입력하지 않습니다. 루프가 실행되고 있어요. 루프가 Claude 에게 프롬프트를 입력하고 무엇을 할지 결정합니다. 제 일은 루프를 작성하는 것입니다."Boris Cherny (
@bcherny ).
중요한 점은 프롬프트 엔지니어링이 쓸모없어졌다는 것이 아닙니다. 루프 엔지니어링을 통해 작업 수준이 한 단계 올라가서, 코드를 직접 작성하는 것에서 코드를 작성하는 시스템을 작성하는 것으로 바뀝니다. 이 길에서 가장 앞서 있는 개발자들은 IDE 를 열지 않고도 수백 개의 PR 을 제공했으며, 모든 코드는 에이전트가 작성했다고 보고합니다.
루프의 실제 의미
루프는 네 가지 작업을 수행하는, 여러분이 작성하는 작은 프로그램입니다:
- 코딩 에이전트를 대신해 프롬프트를 입력하고,
- 에이전트가 생성한 결과물을 읽고,
- 작업이 완료되었는지 판단하며,
- 완료되지 않았다면 오류나 다음 단계와 함께 다시 프롬프트를 입력합니다.
여러분은 루프 안에 앉아 프롬프트를 직접 입력하는 것을 멈추고, 루프를 작성합니다. 그러면 모델은 루프가 호출하는 서브루틴이 됩니다.
형태는 항상 동일합니다: 목표 설정, 실행, 확인, 오류 피드백, 그리고 확인이 통과되거나 루프가 스스로 중단될 때까지 반복합니다.
"루프"는 적어도 다섯 가지를 의미합니다
의견 차이의 대부분은 사람들이 하나의 단어를 다섯 가지 다른 개념에 사용하기 때문입니다. 다음은 가장 오래된 것부터 최신 것까지의 발전 과정입니다.
- ReAct (2022). 원래 연구 패턴: 추론, 행동, 관찰, 반복.
- AutoGPT (2023). 자기 프롬프트 목표 루프로, 언제 멈춰야 할지 모르는 것으로 유명합니다.
- ralph loop. 반복 간에 의도적으로 컨텍스트를 초기화하여 에이전트가 자신의 기록에 빠지지 않도록 합니다.
- /loop 및 /goal. 작업 속도와 완료 조건이 에이전트에 내장되어 상태를 단계 간에 전달합니다.
- 오케스트레이션. 한 작성자가 여러 에이전트를 분산하여 여러분의 GitHub, Slack, 채팅을 읽고 무엇을 구축할지 결정합니다.
실제로 조립하는 부품
위의 발전 과정은 사람들이 루프를 통해 의미하는 바를 설명합니다. 여기서는 루프가 무엇으로 구성되는지 살펴봅니다. 매번 동일한 여섯 가지 부품이 나타나며, 현재는 대부분 직접 유지 관리하는 맞춤 스크립트 대신 코딩 도구 내부에 내장되어 제공됩니다.
- 트리거. 여러분이 직접 시작 버튼을 누르지 않아도 루프를 시작하는 요소: 스케줄, 웹훅, 파일 변경, PR 에 레이블이 지정되는 것 등입니다. 이것이 실제 루프와 수동으로 반복 실행하는 단일 실행을 구분짓는 요소입니다.
- 격리. 에이전트당 개인 체크아웃(보통 git worktree)으로, 두 에이전트가 동시에 실행될 때 서로의 파일을 덮어쓰지 못하게 합니다. 두 개 이상 실행하기 시작하면 이는 선택 사항이 아닙니다.
- 기록된 컨텍스트. 규칙, 빌드 단계, 프로젝트별 규칙을 에이전트가 실행할 때마다 읽을 수 있는 곳에 보관합니다. 이를 생략하면 루프가 매번 처음부터 프로젝트를 다시 유추하여 빈틈을 추측하게 됩니다.
- 도구에 대한 접근. 이슈 트래커, CI, 데이터베이스, 채팅에 연결하여 루프가 PR 을 열고, 티켓을 연결하고, 결과를 게시할 수 있도록 합니다. 수정 사항을 출력하고 나머지 과정을 기다리라고 요청하는 대신 말이죠.
- 두 번째 에이전트가 확인. 출력물을 평가하는 별도의 워커는 출력물을 생성한 워커와 분리되어 있습니다. 모델이 자신의 작업을 검토하면 거의 모든 것을 통과시키기 때문입니다.
- 디스크에 저장된 상태. 마크다운 파일, 보드, 또는 큐: 완료된 작업과 다음 작업을 기록하는 대화 외부의 모든 것입니다. 모델은 실행 사이에 잊어버리지만, 파일은 잊지 않습니다.
이 여섯 가지를 조립하면 루프 엔지니어링의 좋은 출발점이 됩니다. 예전에는 모든 것을 직접 구축해야 했지만, 이제는 대부분이 내장 기능으로 제공되므로, 이 패턴이 주변 기술에서 일반적인 사용으로 이동한 이유입니다.
구체적인 루프: PR babysitter
오늘 구축할 수 있는 구체적인 예시입니다:
- 트리거. 15분마다.
- 범위. agent-watch 레이블이 지정된 열려 있는 PR.
- 작업. 결정론적 이유로 CI 가 빨간색이면, 한 번의 수정을 시도합니다. 메인 브랜치가 이동했다면, 한 번 리베이스합니다.
- 예산. PR 당 한 번의 수정 시도, 5분, 10개 파일 변경.
- 중단 조건. CI 가 녹색이 되거나 예산이 소진되면 중단하고 사람에게 알립니다.
결국, 깨진 빌드의 백로그 대신 병합된 PR 을 보게 됩니다. 동일한 형태는 대부분의 운영 작업에서도 적용됩니다:
- CI 상태. 30분마다 실패한 실행을 가져와 서명별로 클러스터링하여, 하나의 근본 원인을 가진 10개의 빨간 PR 이 하나의 확인 대상이 되도록 합니다.
- 배포 확인. 푸시 후, 엔드포인트에 접속하여 200 상태와 예상 콘텐츠를 확인하고, 사용자가 발견하기 전에 회귀를 표시합니다.
- 피드백 클러스터링. 30분마다 채널에서 댓글을 가져와 주제별로 그룹화하고, 각 클러스터를 해당 파일이나 문서에 매핑합니다.
/goal 을 사용한 구체적인 Claude Code 루프
babysitter 는 직접 연결하는 루프입니다. 에이전트 내부에 내장된 루프를 보는 것도 도움이 됩니다. Claude Code 에서 가장 작은 완전한 루프는 /goal입니다: 확인 가능한 최종 상태를 제공하면, 그 상태가 참이 될 때까지 계속해서 단계를 수행합니다.
다음은 Claude Code 에서 /goal 을 세션 내 명령어로 사용하는 예시입니다. 세션을 시작한 다음, 그 안에서 목표를 설정합니다:
1$ claude # Claude Code 실행2$ /goal tests in test/auth pass # 세션 내에서 목표 설정
앞서 본 것과 동일한 실행, 확인, 반복 형태이며, 검증기가 내장되어 있습니다.
이 시점에서 효과적인 /goal 은 프롬프트라기보다는 계약서에 가깝다는 것이 분명합니다. 좋은 /goal 은 네 가지를 구체적으로 지정합니다: 원하는 최종 상태, 그 상태에 도달했음을 증명하는 증거, 에이전트가 도달하는 과정에서 깨뜨리지 말아야 할 제약 조건, 그리고 사용이 허용된 예산입니다. 이 중 하나라도 모호하게 남겨두면, 모델은 가장 쉬운 해석으로 빈칸을 채웁니다: 일찍 멈추거나, 지름길을 선택하거나, 실제 시스템은 고장난 상태에서도 기록이 완료된 것처럼 보이도록 성공을 재정의합니다.
- 조건 설정. /goal 과 확인 가능한 최종 상태를 입력합니다. 예:/goal tests in test/auth pass. 첫 번째 단계가 즉시 시작됩니다.
- 에이전트가 작업 수행. 에이전트가 편집하고, 테스트를 실행하고, 세션에 결과를 표시합니다.
- 평가자가 확인. 빠른 모델이 기록을 읽고 목표가 충족되었는지 또는 충족되지 않았는지 판단하여, 에이전트가 자신의 작업을 스스로 평가하지 않도록 합니다.
- 루프 또는 종료. 충족되지 않음은 안내와 함께 다음 단계를 의미합니다. 충족됨은 목표가 자체적으로 해제되고 실행이 중단됨을 의미합니다.
상태는 단계 간에 전달되므로, 일찍 종료하거나 도중에 제약 조건을 놓치지 않습니다. 몇 가지 제어 장치가 안정성을 유지합니다:
- 측정 가능한 확인을 만드세요. 테스트 결과, 종료 코드, 파일 수 또는 빈 큐 등입니다. npm test exits 0 은 목표이지만, "더 좋게 만드세요"는 목표가 아닙니다.
- 실행 범위를 제한하세요. 예를 들어 "또는 20턴 후 중지"와 같은 내용을 추가하여, 루프가 막혔을 때 턴을 소모하는 대신 중단되도록 합니다.
- 자동 모드와 함께 사용하여 턴이 감독 없이 실행되도록 하고, /goal clear를 사용하여 일찍 중단합니다.
평가자 단계에는 유용한 미묘함이 숨어 있습니다: 확인자가 반드시 코더와 동일한 모델일 필요는 없다는 것입니다. 루프에 별도의 역할(계획자, 실행자, 평가자, 시각 검토자)이 있으면, 각 역할을 다른 모델에서 실행할 수 있으며, 어떤 모델이 어떤 역할을 수행할지 선택하는 것은 하나의 "최고" 코딩 에이전트에 대한 단일 베팅이 아닌 아키텍처 결정이 됩니다. 일부 모델은 계획을 더 잘하고, 일부는 더 저렴하게 실행하며, 일부는 스크린샷을 더 정확하게 판단합니다. 좋은 오케스트레이터는 단일 공급업체가 모든 범주에서 승리하기를 기다리는 대신 역할별로 모델을 교체할 수 있게 해줍니다.
이것은 API 마이그레이션(컴파일되고 테스트가 통과할 때까지 모든 호출 사이트 이동), 리팩터링(각 모듈이 예산 이하가 될 때까지 파일 분할), 이슈 백로그(레이블이 지정된 큐가 빌 때까지 작업), 평가 루프(점수가 임계값을 초과할 때까지 프롬프트 조정)에 효과적입니다. /loop 는 단일 완료 지점이 없는 작업을 위한 대응입니다: 완료 조건 대신 스케줄에 따라 다시 프롬프트를 입력하며, 이것이 PR babysitter 와 같은 루프가 계속 실행되는 방식입니다.
여러 루프를 감독 없이 실행하기
단일 /goal 루프는 하나의 목표를 향해 작업하는 하나의 에이전트입니다. 여러 감독 없는 프로세스를 실행하면 위험 부담이 커집니다. 루프는 자신의 작업을 확인하는 능력만큼만 신뢰할 수 있기 때문입니다. Cherny 가 Opus 를 수시간 동안 자율적으로 실행하기 위한 설정은 다섯 단계로 요약됩니다:
- 권한 자동 승인하여 에이전트가 모든 도구 호출에서 중단하여 묻지 않도록 합니다.
- 동적 워크플로우 사용(프롬프트에 Ultracode 추가)하여 하나의 직렬 스레드 대신 여러 에이전트로 분산합니다.
- /goal 또는 /loop 사용하여 계속 진행합니다. /goal 은 완료 조건을 설정하고, /loop 는 스케줄에 따라 다시 프롬프트를 입력하며, 둘 다 상태를 전달하므로 일찍 종료되지 않습니다.
- 클라우드에서 실행(데스크톱 또는 모바일 앱)하여 랩톱을 닫아도 세션이 유지되도록 합니다.
- 엔드 투 엔드 자체 검증 방법 제공. 웹용 Chrome 의 Claude, 모바일용 시뮬레이터 MCP, 백엔드용 라이브 서버입니다. 이 단계가 나머지 네 단계를 안전하게 만듭니다.
전체 시퀀스:
1claude --permission-mode auto # 1 · 승인 프롬프트 없음2ultracode orchestrate sub-agents to ship the feature # 2 · 분산3/goal all tests pass and the demo loads clean # 3 · 계속 진행4→ cloud / desktop app # 4 · 랩톱 닫기5→ chrome ext · sim MCP · live server # 5 · 자체 검증 후 중단
crabfleet: 제품으로서의 오케스트레이션
오케스트레이션은 구체적인 도구를 통해 상상하기 더 쉽습니다. Peter Steinberger 의 crabfleet 은 "에이전트 실행을 위한 미션 컨트롤"이라고 소개되는 OpenClaw 프로젝트로, 제품으로 패키지화된 루프이며 그 형태는 위의 모든 내용에 매핑됩니다.
- 보드의 카드로서의 작업. 작업은 프롬프트, GitHub 이슈 또는 PR 로 구축된 카드로 입력된 후, 할 일, 실행 중, 인간 검토, 완료 상태로 이동합니다. 그 보드는 루프의 큐이자 중단 및 보고 단계이며, 시각적으로 표시됩니다.
- 발사 후 망각이 아닌 지속적인 실행. 각 실행은 하트비트가 있는 추적된 시도이므로, 시선을 돌려도 계속 진행되고 랩톱을 닫아도 유지됩니다. 런타임이 핸드오프를 지원한다고 광고할 때만 인수합니다.
- 에이전트를 생성하는 에이전트. 실행은 샌드박스 내부에서 하위 세션을 시작하고, 메시지를 보내고, 기록을 읽고, 자체 요약을 업데이트할 수 있습니다: 한 곳의 디스크 메모리와 분산, 한 명의 작성자와 여러 에이전트.
브라우저 기반 터미널이 있는 일회용 클라우드 샌드박스에서 실행되므로, 감독 없는 실행에서 벗어나도 안전합니다. 중요한 점은 특정 도구가 아니라 루프가 인프라로 굳어졌다는 것입니다: 큐, 지속적 실행, 분산, 인간 검토 게이트는 이제 매번 직접 스크립트를 작성하는 대신 구성하는 것들입니다.
비용이 발생하는 곳
2년 동안 AI 코딩의 비용 문제는 간단했습니다: 어떤 모델과 몇 개의 토큰인지. 루프 내부에서는 그 본능이 잘못된 계층을 가리킵니다. 지출은 더 이상 단일 호출이 아니라 루프가 몇 번이나 반복되는지입니다. 따라서 동일한 모델에서 첫 번째 패스에 성공하는 루프보다 수렴하기 전에 여섯 번 재시도하는 루프는 6배의 비용이 듭니다.
이는 최적화할 가치가 있는 것을 변화시킵니다:
- 반복 횟수가 예산 항목이지 토큰이 아닙니다. 두 배 더 자주 반복하는 저렴한 모델이 더 저렴한 것은 아닙니다. 따라서 호출당 비용이 아닌 완료된 작업당 비용을 추적하세요.
- 취약한 검증기는 출시할 수 있는 가장 비싼 버그입니다. "완료"를 결정하는 검사가 느슨하면, 루프는 깨진 작업에서 일찍 멈추거나 이미 괜찮은 작업에서 계속 진행하며, 둘 다 전체 반복을 낭비합니다. 다른 것보다 먼저 이것을 강화하세요.
- 빠른 실패는 비용 통제입니다. 연속 실패에 대한 상한선이 없는 루프는 결국 성공하지 않습니다. 결국 계좌를 소진하므로, 중단 조건은 코드베이스만큼이나 비용 청구서를 보호합니다.
예전에는 프롬프트를 조정했습니다. 이제는 루프를 조정합니다. 비용이 거기서 축적되기 때문입니다.
루프를 사용하지 말아야 할 때
루프는 작업이 반복되고 기계가 완료 시점을 알 수 있을 때 효과적입니다. 그 외에는 루프는 단지 소모적인 자동화일 뿐입니다. 다음 경우에는 건너뛰세요:
- 일회성 편집. 단일 패스로 완료할 수 있다면, 루프는 순수한 오버헤드입니다.
- 범위가 없거나 탐색적 작업. "사용자가 이탈하는 이유를 알아내기"는 통과 조건이 없으므로 루프가 수렴하지 않습니다.
- 저렴한 자동 확인이 없는 모든 것. 유일한 검증자가 여러분의 눈이라면, 여러분은 여전히 루프 안에 있는 것입니다. 먼저 확인을 구축하거나, 작업을 직접 수행하세요.
잘못될 수 있는 것
여러분이 잠자는 동안 실행되는 루프는 여러분이 잠자는 동안에도 실수를 하며, 실패 모드는 예측 가능합니다.
- 확인 부담은 여전히 인간에게 있습니다. 루프는 여러분이 검토할 수 있는 것보다 더 빠르게 작성합니다. 따라서 diff 읽기를 중단하면 작업을 제거한 것이 아니라 연기한 것뿐입니다.
- 이해 격차가 커집니다. 여러분이 작성하지 않은 코드를, 여러분이 흡수할 수 있는 것보다 더 빠르게 제공하면, 여러분 자신의 시스템에 대한 모델이 침식되고, 그 부채는 다음 사고发生时에 갚아야 합니다.
- 느슨한 검사로 인한 무음 표류. 취약한 검증자는 잘못되었지만 통과하는 작업을 모든 반복에서 통과시키므로, 루프는 구멍을 파면서 생산적으로 보입니다.
이 중 어느 것도 루프에 대한 반대 논거가 아닙니다. 그렇기 때문에 루프를 설계하는 엔지니어가 더 중요해지고, 덜 중요해지는 것이 아닙니다.
직접 구축하는 방법
- 반복 가능한 하나의 작업을 선택하세요. PR babysitting, CI 수정, 배포 확인: 일상적인 작업부터 시작하세요.
- 범위를 좁게 설정하세요. "빌링 웹훅 유효성 검사 수정, app/api/billing 및 lib/billing 만 건드리기"가 "버그 수정"보다 낫습니다. 느슨한 루프는 방황합니다.
- 예산과 중단 조건을 제공하세요. 최대 시도 횟수, 최대 실행 시간, 최대 파일 수, 최대 지출, 최대 연속 실패 횟수. 감독 없이 실행되는 루프는 감독 없이 실수를 저지르는 루프이기도 합니다.
- 독립적인 검증기를 추가하세요. 별도의 하위 에이전트가 작업을 평가합니다. 코드를 작성한 에이전트가 작업이 완료되었는지 판단하는 데 가장 적합하지 않기 때문입니다.
- 일정에 따라 실행하세요. 간격을 위한 /loop, 스케줄을 위한 cron, 라이프사이클 지점의 훅, 또는 랩톱을 닫아도 유지되도록 GitHub Actions.
- 디스크에 메모리를 유지하세요. 모델은 실행 사이에 잊어버리므로, 상태는 컨텍스트 창이 아닌 마크다운 또는 보드에 저장됩니다.
핵심 요점: 이제 모델이 아니라 루프가 비용이 많이 들고 실패하기 쉬운 부분입니다. 단순히 실행을 시작하는 사람이 아니라, 출력물에 대한 책임을 지는 엔지니어로 남을 의향이 있는 사람처럼 구축하세요.
오류가 있거나 더 명확한 설명이 필요한 부분이 있다면, 주저하지 말고 연락해 주세요.
