Loop Engineering 의 후속작, 그리고 에이전트를 10배 더 넓게 운영하는 워크플로우...
멀티 스텝 에이전트를 구축하는 대부분의 사람들은 직선으로 끝납니다.
1단계, 2단계, 3단계. 각 단계는 이전 단계가 끝날 때까지 기다립니다.
여기서 거의 아무도 확인하지 않는 것이 있습니다:
그 단계들 중 절반은 기다릴 필요가 전혀 없었다는 것입니다
그저 한 번에 하나의 작업만 큐에 넣고, 컨텍스트 창이 가득 차서 에이전트가 자신이 무엇을 하고 있었는지 잊어버릴 때까지 기다립니다.
- 느린 이유는 모델이 약해서가 아니었습니다.
- 느린 이유는 작업이 그래프인데 선을 그렸기 때문입니다.
이 가이드는 그 선에서 출발하여, 작업을 여러 에이전트로 펼쳐내고 스스로 결과를 검증하는 그래프로 안내합니다.
다섯 단계. 2단계에서 이미 하나를 구축하게 됩니다 -
이를 통해 작동하는 그래프를 얻고, 실제 그래프를 망가뜨리는 함정들을 알게 되며, 어려운 부분이 시작되는 지점을 알려드립니다.
알파 공개 전 - 더 많은 신규 알파를 위해 제 Substack 을 구독하세요 ↓
0장 - 그래프 엔지니어링이 실제로 무엇인가
한 달 전, 이 분야는 루프에 대해 이야기하고 있었습니다.
Peter Steinberger 가 그것을 아홉 단어로 포착했습니다:
https://x.com/steipete/status/2078277297791189132
루프는 더 나아지기 위한 하나의 사이클입니다:
무언가 시도하기 → 결과 확인하기 → 조정하기 → 다시 시도하기
그것이 원자입니다: 하나의 에이전트가 한 가지를 반복해서 개선하는 것
(제 Loop Engineering 글을 읽으셨다면, 그 내용입니다)
https://x.com/0xCodila/status/2072329149520232639
하지만 단일 루프에는 알려진 실패 지점이 있습니다 - 지원팀이 피드백 루프를 하나의 지표(티켓 해결률)에 묶어버립니다.
수개월 동안 수치는 오르지만 만족도는 떨어집니다. 봇이 문제를 해결하는 대신 티켓을 빨리 닫는 법을 배운 것입니다.
이것이 굿하트의 법칙입니다. 루프는 자신의 지표만 볼 수 있습니다. 그 목표가 올바른지, 혹은 자신의 측정값이 변하고 있는지 물을 수 없습니다.
정답은 더 나은 루프가 아닙니다. 루프들의 그래프입니다 - 서로를 감시하고 교정하는 사이클들의 네트워크입니다.
에이전트의 경우, 이는 한 가지를 의미합니다:
모든 것을 하나의 라인으로 처리하는 하나의 에이전트를 작성하는 것을 멈추고, 작업의
형태
를 설계하세요 - 어떤 것이 무엇보다 먼저 실행되고, 어떤 것이 동시에 실행되며, 어떤 것이 기다려야 하는지.
노드는 사고를 수행합니다. 엣지는 결과를 전달합니다.
그리고 Claude Code 가 이를 직접 구축할 수 있는 도구를 출시했습니다: 동적 워크플로우
1단계 - 존재하지 않는 엣지 보기
그래프는 두 부분으로 구성됩니다:
- 노드는 하나의 작업 단위입니다: 하나의 에이전트, 하나의 작업, 하나의 입력, 하나의 출력
- 엣지는 의존성입니다: 이 노드의 출력이 저 노드의 입력으로 전달됩니다
모두가 저지르는 실수는 "그리고 나서" 를 엣지로 취급하는 것입니다.
"이 파일을 요약해줘
그리고 나서
날씨를 알려줘"
날씨는 요약을 읽지 않습니다.
이것들은 선형 스크립트가 아무 이유 없이 연결한 두 개의 독립적인 작업입니다. 각각은 아무 이유 없이 이전 작업이 끝나기를 기다립니다.
모든 것을 시작하는 습관:
모든 "그리고 나서"에 대해 물어보세요 - 다음 단계가 실제로 이전 단계의 출력을 읽는가?
- 예 → 실제 엣지입니다. 순서를 유지하세요.
- 아니오 → 엣지가 아닙니다. 기다림은 낭비입니다. 병렬로 실행하세요.
두 상자 사이에 데이터가 오가지 않는다면, 그들은 독립적입니다.
그 독립성이 이 가이드의 나머지 부분에서 활용할 부분입니다.
평범한 "A를 하고, 그 다음 B를 하고, 그 다음 C를 하는" 에이전트는 이미 그래프입니다 - 가장 슬픈 그래프일 뿐입니다: C가 멈추면 D가 절대 실행되지 않는 단일 체인입니다.
2단계 - 첫 번째 그래프 구축하기 (처음부터 끝까지)
이론은 충분합니다. 하나를 구축하고 실행되는 것을 지켜보세요.
시작하기 전에:
- Claude Code v2.1.154+ (claude --version 으로 확인)
- 유료 플랜. Max, Team 또는 Enterprise 에서 워크플로우는 기본적으로 켜져 있습니다. Pro 에서는 /config 에서 Dynamic workflows 행을 켜세요.
1. 알고 있는 저장소를 여세요.
실제 저장소여야 결과가 의미 있습니다.
2. 이 프롬프트를 붙여넣으세요 (Anthropic 제공):
1src/routes/ 아래의 모든 라우트 파일에 대해 인증 검사가 누락되었는지 감사하는 워크플로우를 생성하세요. 파일당 하나의 에이전트를 생성하고, 각 발견 사항에 대해 독립적인 검증기를 실행한 후 보고하세요. 시작하려면 최대 20개의 파일을 분석하세요.
src/routes/ 를 파일이 있는 실제 경로로 바꾸세요. "최대 20개" 라인은 첫 번째 실행 비용을 낮게 유지합니다.
3. "워크플로우"가 활성화되는 것을 확인하세요.
Claude Code 가 강조 표시합니다: "동적 워크플로우가 요청되었습니다." 이는 일반 채팅이 아닌 그래프가 구축되고 있다는 신호입니다.
4. 계획을 승인하세요.
Claude 가 JavaScript 오케스트레이션 스크립트를 작성하고 먼저 단계를 보여줍니다. 읽어보고 "예, 실행합니다." 를 선택하세요.
5. 에이전트 군단이 실행되도록 하세요.
파일당 하나의 에이전트가 병렬로 실행되는 동안 세션은 자유롭게 유지됩니다.
/workflows 를 입력하여 실시간으로 확인하세요: 범위, 확장, 검증, 종합.
6. 하나의 답변을 읽으세요.
20개의 개별 채팅이 아닌 하나의 보고서입니다. 중간 결과가 컨텍스트가 아닌 스크립트의 변수에 저장되었기 때문입니다.
그것이 그래프입니다.
단 하나의 문장에서 나온 수십 개의 에이전트.
"제로 토큰" 주장에 대해 들어보셨을 텐데요
조정 스크립트는 코드입니다.
따라서 에이전트 간에 결과를 전달해도 채팅 핸드오프처럼 컨텍스트를 다시 소비하지 않습니다.
하지만 에이전트는 여전히 사용량을 소모합니다. 워크플로우는 일반 세션보다 상당히 더 많은 비용이 듭니다.
절약되는 부분은 조정에 있으며, 작업 자체에는 해당하지 않습니다. 범위를 좁게 시작하고, 사용량을 모니터링한 다음, 확장하세요.
- 나만의 것으로 만들기
실행이 잘 되었다면 s 를 누르세요.
~/.claude/workflows 에 저장되며, 이름으로 다시 실행할 수 있습니다.
이제 작업을 바꾸고 형태는 유지하세요. "인증 검사 누락"을 "처리되지 않은 Promise"나 "100줄 초과 함수"로 바꿔보세요.
이것이 얼마나 확장될 수 있는가 (기사 제목)
하나의 워크플로우 실행은 최대 1,000개의 에이전트로 확장될 수 있으며, 한 번에 최대 16개가 동시에 작업합니다.
"한 창에서 1000개 이상의 루프"라는 말이 나오는 이유입니다. 은유가 아니라 기능의 실제 상한선입니다.
- 그리고 그 규모가 핵심입니다. 천 개의 에이전트는 단일 컨텍스트로는 절대 감당할 수 없는 작업을 의미합니다. 전체 코드베이스를 한 번에 감사하고, 모든 파일에 영향을 미치는 마이그레이션, 천 가지 관점을 병렬로 실행하는 검색을 의미합니다.
한 번에 16개라는 제한은 단지 에이전트 군단이 파도처럼 움직이며, 사용자가 하나하나 지켜보지 않아도 천 개를 모두 처리한다는 의미일 뿐입니다.
20개부터 시작하여 실행이 어떻게 동작하고 비용이 얼마인지 확인한 다음, 확장하세요 - 이것이 다른 누구도 구축하지 않는 한계선이기 때문입니다
3단계 - 실제로 망가지는 부분
그래프를 구축했습니다. 여기서 실제 그래프가 무너지는 지점이 있습니다.
두 가지 실패가 가장 중요합니다
- 실패 1: 그래프가 자기 자신과 동의함
에이전트가 자신의 작업을 확인할 때, 자신에게 관대해집니다. 모델은 자신의 출력을 선호하는 경향이 있습니다.
따라서 엣지에 검증기를 둡니다. 발견 사항이 다운스트림으로 흘러가기 전에 이를 확인하는 별도의 노드입니다.
아무도 언급하지 않는 함정: 검증기에게는 깨끗한 컨텍스트가 필요합니다.
실행자가 사용했던 것과 동일한 대화를 검증기에게 넘겨주면, 그것은 검증이 아닙니다. 다른 글꼴로 자신과 동의하는 것입니다.
하나의 컨텍스트를 공유하는 에이전트들의 그래프는 코스튬을 입은 단일 루프에 불과합니다. 동일한 방식으로 실패합니다 - 더 늦게, 더 비싸게, 더 많은 녹색 불이 켜진 상태에서 추락합니다.
따라서 검증기는 새로운 노드입니다 - 자체 컨텍스트를 가집니다. 실제 신호를 확인합니다 - "에이전트가 완료했다고 말했는가"가 아니라 "테스트가 실제로 통과하는가"를 확인합니다.
- 실패 2: 에이전트들이 서로 간섭함
이것은 가상의 이야기가 아닙니다
Bun 팀이 처음으로 대규모 포팅 작업을 여러 에이전트에 분산시켰을 때, 실행이 운영상 실패했습니다. 에이전트들이 하나의 작업 공간에서 공유된 git 명령어를 사용하여 서로의 작업을 덮어썼기 때문입니다.
해결책은 구조적인 것이었지, 영리한 프롬프팅이 아니었습니다. 그들은 안전하지 않은 명령어를 금지하고 각 그룹에 자체 격리된 작업 트리를 제공했습니다.
이것이 병렬 처리의 진정한 교훈입니다. 두 개의 에이전트가 동일한 파일에 쓰면 경합이 발생합니다.
확장하기 전에 세 가지 질문에 답하세요:
- 각 에이전트는 어디서 작업하는가?
- 결과는 어떻게 병합되는가?
- 두 에이전트가 의견이 다를 때는 어떻게 되는가?
이 계획 없이 그래프는 확장되지 않습니다. 더 빠르게 실패합니다.
4단계 - 이번 주에 구축할 여섯 가지 그래프
방법: 실제 엣지 찾기 → 확장하기 → 독립적인 컨텍스트에서 검증하기 → 작업자 격리하기
///
다음 각각은 동일한 형태를 새로운 작업에 맞춘 것입니다. 작업 줄을 변경하고 시작하세요:
- 보안 점검 - 파일당 하나의 에이전트가 누락된 인증을 찾고, 검증기가 각 발견 사항을 확인합니다 (방금 구축한 것)
- /deep-research 로 인용 보고서 - 이미 제공됨: 질문을 여러 관점으로 나누고, 병렬로 검색하며, 에이전트가 작성 전에 서로 반박합니다.
- 모듈 포팅 - 파일별로, 테스트를 게이트로 사용하고, 실패 시 루프백.
- 적대적 diff 리뷰 - 크기에 따라 라우팅: 작은 변경 → 단일 패스; 큰 변경 → 완전 병렬 감사.
- 예약된 생태계 스캔 - 한 번 저장하고, 이름으로 재실행.
- 알 수 없는 규모의 탐색 - 파인더가 병렬로 실행되고, 각 결과가 지금까지 본 모든 것과 비교 확인되며, 두 라운드에서 새로운 것을 찾지 못할 때까지 반복됩니다.
///
한계가 무엇인지 보여주는 예https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
Bun 의 Zig-to-Rust 포팅은 정확히 이 동일한 메커니즘에서 실행되었습니다.
약 50개의 워크플로우, 최대 64개의 에이전트가 병렬로 실행되었습니다. 약 535,000줄의 Zig 가 11일 만에 100만 줄 이상의 Rust 로 변환되었습니다.
또한 사용량 기준으로 약 $165,000 의 비용이 들었고, 전체 과정을 설계하고 모니터링할 인간이 필요했습니다.
그리고 그렇게 많은 AI가 작성한 코드를 안전하게 리뷰할 수 있는지에 대한 공개적인 비판을 받기도 했습니다.
규모는 현실입니다. 가격과 감독도 마찬가지입니다.
5단계 - 그래프를 정직하게 유지하는 앵커
토폴로지만으로는 진실을 보장하지 않습니다.
서로를 확인하는 에이전트 네트워크는, 그 어느 것도 실제적인 것에 닿지 않는다면, 더 많은 움직이는 부품만 있을 뿐 단일 루프와 똑같이 실패합니다.
그래프에는 앵커가 필요합니다: 논쟁의 여지가 없는 노드들입니다.
- 실제로 실행된 테스트 - "통과해야 한다"가 아니라 통과했다
- 분위기가 아닌 증거에 기반한 검증기
- 에이전트가 절대 조정할 수 없는 고정된 규칙 - 최적화 도구가 약화시키려고 할 것이기 때문입니다.
그래프는 그래프 안에서 움직이기를 거부하는 요소들만큼만 정직합니다.
그래프가 잘못된 선택인 경우
대부분의 작업은 그래프가 아닙니다. 필요하지 않을 때 그래프를 사용하면 돈만 낭비하고 실패할 방법만 늘어납니다.
다음과 같은 경우 그래프를 건너뛰세요:
- 작업이 작거나 고립된 경우. 함수 추가, 하나의 버그 수정. 워크플로우는 순수한 오버헤드입니다. 단일 에이전트가 더 빠르고 저렴합니다.
- 엄격한 감독이 필요한 경우. 각 단계를 읽고 승인한 후에 다음 단계를 실행하고 싶다면, 그래프의 핵심(사용자 없이 넓게 실행)이 역효과를 냅니다.
- 무엇을 찾고 있는지 아직 모르는 경우. 탐색적 작업은 조종할 수 있는 하나의 에이전트를 원하지, 문제를 이해하기 전에 계획에 고정된 에이전트 군단을 원하지 않습니다.
- 단계가 진정으로 서로 의존하는 경우. 모든 단계가 이전 단계의 출력을 읽는다면, 그것은 실제 체인입니다. 병렬 처리가 활용할 것이 없습니다. 진정한 순차적 작업에 그래프를 강제로 적용하면 속도 향상 없이 조정 비용만 추가됩니다.
판단 기준은 1단계입니다. 두 상자 사이에 화살표가 없는 것을 찾을 수 없다면, 구축할 그래프가 없는 것입니다. 그것은 루프이며, 루프는 괜찮습니다.
그래프는 폭을 위한 도구입니다 - 독립적인 작업을 한 번에 처리하는 것입니다.
작업이 넓지 않다면, 선이 문제였던 적은 없습니다...
전환점
프롬프터는 질문을 던집니다. 아키텍트는 그래프를 그립니다.
선형 에이전트는 결코 한계가 아니었습니다.
그것은 첫 번째 형태였습니다. 우리가 입력하는 방식과 일치하기 때문에 모든 사람이 사용하는 형태입니다: 한 줄, 한 번에 한 가지.
노드와 엣지를 보게 되면, 에이전트에게 더 많이 하라고 요청하는 것을 멈추고 그래프에게 더 넓게 하라고 요청하기 시작합니다:
- 확장하세요 작업이 독립적인 곳에서
- 게이트를 설정하세요 신뢰도가 중요한 엣지에
- 고정하세요 진실을 담고 있는 노드를
대부분의 사람들은 계속해서 단계를 한 줄로 큐에 넣을 것입니다.
그래프를 그리고, 그것을 망가뜨리는 것을 존중하는 법을 배운 소수는 에이전트 군단을 운영하게 될 것입니다.
그래프를 그리세요. 아키텍트로 남으세요.
전제 조건부터 시작하세요:
- 이 그래프가 기반한 단일 루프
