Fable을 사용하여 40개의 하위 에이전트로 대규모 프로젝트를 오케스트레이션하는 방법

지난주 @HelloUntangle 에서 저희는 역사상 가장 크고 위험한 엔지니어링 프로그램을 완료했습니다.

• 834 개 파일
• 프로덕션 데이터 변환
• DB 스키마 업데이트
• 31 개 PR
• 금요일 시작 → 월요일 완료
• 프로덕션 장애 제로

모든 작업이 단 하나의 Fable 부모 오케스트레이터 세션으로 처리되었습니다.

하나의 @DevinAI 부모 세션이 작업을 계획하고, 40 개의 자식 세션을 생성하여 실행하도록 했으며, 단계 간 회귀 게이트와 백업 검사를 적용하고, 소유자의 결정이 실제로 필요한 사항(범위 판정 및 되돌릴 수 없는 단계에 대한 진행/중단 결정)만을 전달했습니다.

이 작업을 가능하게 한 것은 모든 대규모 마이그레이션을 개선할 수 있는 프로그램 관리 패턴 세트였습니다.

방법은 다음과 같습니다 ...

아키텍처: 하나의 오케스트레이터, 여러 워커

• 하나의 부모 세션이 프로그램을 처음부터 끝까지 담당했습니다. 유일한 역할은 계획 수립, 자식 세션 생성, 출력 검토, 단계 순서 지정, 그리고 인간의 결정이 필요한 사항을 저에게 에스컬레이션하는 것이었습니다. 코드는 한 줄도 작성하지 않았습니다.
• 약 40 개의 자식 세션이 모든 실제 작업을 수행했습니다: 0 단계에서 11 개의 병렬 감사 세션, 각 웨이브의 실행 세션, 그리고 회귀 테스트 스위트 실행만을 담당하는 전용 게이트 실행 세션 등이 포함됩니다.

이러한 분할이 중요한 이유는 장기 실행 프로젝트(AI든 인간이든)의 실패 모드가 컨텍스트 붕괴(context collapse), 즉 작업을 수행하는 주체가 전체 프로그램의 맥락을 점차 잃어버리기 때문입니다.

부모를 순수한 오케스트레이터로 유지하면 부모의 컨텍스트가 깔끔하게 유지됩니다. 부모는 계획, 범위 결정, 각 웨이브의 상태를 보유합니다. 각 자식은 정확히 하나의 작업에 집중하는 새롭고 명확한 컨텍스트를 받습니다.

성공을 가능하게 한 7가지 패턴

1. 먼저 감사하고, 결과를 단일 매니페스트에 고정하라

0 단계는 11 개의 병렬 감사 세션으로 구성되었으며, 각 세션은 코드베이스의 한 부분(앱 라우트, API 라우트 및 크론, 데이터베이스 스키마, 공유 라이브러리 및 워크플로우, 스크립트 및 문서)을 담당했습니다. 그 결과는 하나의 파일로 종합되어 리포지토리에 커밋되었습니다.

매니페스트는 모든 코드 단위에 판정과 웨이브 번호를 할당합니다. 두 가지 규칙이 이를 강력하게 만들었습니다:

• 어떤 워커도 범위를 재론하지 않는다. 모든 실행 프롬프트는 사실상 "매니페스트가 진실의 원천이다"라고 명시했습니다. 이것이 없으면 40 개의 각 세션이 범위에 대한 자신의 의견을 도출하게 되고, 서로 일치하지 않을 것입니다.
• UNKNOWN은 멈추고 질문하라는 의미다. 감사에서 언급되지 않은 모든 것은 명시적으로 unknown으로 표시되었고, "추측하지 말고 판정을 받으라"는 지침이 함께 제공되었습니다. 소유자의 판정은 매니페스트에 직접 기록되어 이후 세션에서 이를 상속받을 수 있도록 했습니다.

2. 편의가 아닌 위험도에 따라 작업 순서를 정하라

웨이브는 가장 안전한 것부터 가장 되돌릴 수 없는 것 순으로 정렬되었습니다.

웨이브

내용

위험도

0

감사 + 매니페스트 + 복원 지점 git 태그

없음

1

라이브 종속성이 없는 것으로 확인된 변경 사항

거의 제로

2

공유 인프라에 대한 얽힘 수술

중간

3–4

코드 변경의 대부분

중간

5

프로덕션 데이터 변경 (드라이런 인벤토리 + 스냅샷 포함)

높음

6

스키마 마이그레이션

높음

7

종속성 정리, agents.md 재작성, 에이전트 지식 베이스 감사

낮음

프로덕션 데이터 변경(웨이브 5)은 스키마 변경(웨이브 6) 전에 이루어지며, 둘 다 영향을 받는 테이블을 건드리는 모든 코드 경로가 검증 가능하게 업데이트된 후에만 실행됩니다. 마이그레이션이 실행될 때쯤이면 이전 상태에 의존하는 것은 아무것도 없었습니다.

3. 파일이 서로 겹치지 않는 경계가 병렬성을 안전하게 만든다

웨이브 내에서 자식 세션은 병렬로 실행되었습니다. 한 웨이브에서는 네 개의 세션이 동시에 트리의 다른 부분을 작업했습니다. 규칙은 다음과 같습니다: 모든 프롬프트에는 명시적인 파일 경계가 포함되었고, 그 경계는 서로 겹치지 않았습니다. 병합 충돌도, 같은 파일을 편집하는 두 에이전트도, 자식 간의 조정도 전혀 필요하지 않았습니다.

이는 고전적인 작업 분해입니다. 엔지니어 간에 작업을 분할할 때와 동일한 방식이지만, 에이전트의 경우 매번 프롬프트에 명시적으로 명시해야 합니다.

4. 웨이브 간 안전 게이트

이전 웨이브가 게이트를 통과할 때까지 다음 웨이브는 시작되지 않았습니다. 게이트 자체도 자식 세션이었습니다:

• 브라우저 기반의 종단 간 회귀 테스트 스위트는 플랫폼의 핵심 고객 워크플로우를 다루며, 웨이브 2 이후와 웨이브 3-4 이후에 각각 신선한 격리된 데이터베이스 브랜치에서 실행되었습니다.
• 프로덕션 데이터 변경 전: 전용 세션이 데이터베이스 백업 인벤토리(개수, 날짜 범위, 보존 기간)를 감사하고, 새로운 특정 시점 스냅샷을 생성했습니다.
• 프로덕션 단계 자체는 먼저 드라이런으로 실행되어 소유자 승인을 위한 행 개수를 생성하고, 실행 후 개수를 재확인했습니다.
• 변경된 모든 줄에 대한 복원 지점을 표시하는 git 태그가 있습니다.

게이트가 실패하면 범위가 지정된 수정 세션이 생성되었습니다. 예를 들어, 회귀 테스트 스위트는 지나치게 적극적인 변경으로 인해 손상된 고객 대면 플로우를 발견했습니다. 하나의 수정 세션이 몇 시간 만에 이를 복원했습니다. 이는 시스템이 제대로 작동하고 있다는 증거입니다. 게이트는 고객이 보고했을 버그를 당일 수정으로 전환했습니다.

5. 인간은 승인하고, 에이전트는 제안한다

이 프로젝트에서 저는 코드를 작성하거나, 마이그레이션을 실행하거나, 프로덕션 스크립트를 실행하지 않았습니다. 하지만 모든 되돌릴 수 없는 단계에는 명시적인 제 승인이 필요했습니다: main 브랜치로의 각 병합, 프로덕션 데이터 변경, 스키마 마이그레이션, 그리고 UNKNOWN 범위 항목에 대한 각 판정이 그렇습니다.

파괴적인 작업에 대한 패턴은 다음과 같습니다: 에이전트가 인벤토리를 제안하고, 인간이 인벤토리를 승인한 다음, 에이전트가 정확히 그 인벤토리를 실행합니다. 프로덕션 세션은 아무것도 건드리기 전에 건드릴 행의 정확한 목록을 생성했습니다. 저는 막연한 의도가 아닌 구체적인 목록을 승인했습니다.

6. 예상치 못한 상황에 대한 에스컬레이션 프로토콜

자식 세션은 현실이 매니페스트와 일치하지 않을 때 어떻게 해야 하는지 지시받았습니다: 중단하고, 부모에게 보고하며, 즉흥적으로 대처하지 말 것. 실제 사례:

• 감사에서 안전하다고 판단된 모듈이 실제로 다른 곳에 라이브 종속성을 가지고 있음 → 자식이 이를 플래그로 표시했고, 해당 유닛은 얽힘이 기록된 상태로 이후 웨이브로 강등되었습니다.
• 두 번째 감사 라운드에서 첫 번째 라운드의 판정이 5개 전체 영역에 대해 뒤집힘 → 뒤집힌 내용은 이를 발견한 세션이 임시로 해결하는 대신 명시적 재정의로 매니페스트에 기록되었습니다.

부모는 이러한 예상치 못한 상황을 계획에 흡수했습니다. 개별 워커는 범위 결정을 내리지 않았습니다.

7. 캠프장을 더 깨끗하게 남겨라: 시스템에 무엇이 변경되었는지 가르쳐라

웨이브 7은 가장 과소평가된 단계일 수 있습니다. 변경 사항이 배포된 후, 세션은 AGENTS.md, 리포지토리 스킬, 에이전트 지식 베이스를 새로운 아키텍처를 설명하도록 재작성했습니다. 따라서 미래의 모든 에이전트 세션은 오래된 지침이 아닌 진실에서 시작합니다. 엔지니어링이 에이전트 기반이라면, 문서는 부하를 견디는 인프라입니다.

비용

프로그램의 모든 세션에 태그가 지정되어 있어 원장이 완전합니다: 하나의 부모와 39개의 자식, 모두 Devin의 Ultra Agent에서 금요일 오후부터 월요일 아침까지 실행되었습니다. 다음은 사용량 대시보드에서 가져온 실제 계량 비용입니다.

단계

세션 수

비용

부모 오케스트레이터 (다일)

1

$115.26

0 단계 감사 (두 라운드) + 매니페스트 종합

12

$85.56

웨이브 1

4

$37.55

웨이브 2 (얽힘 수술)

4

$299.34

웨이브 2-4 회귀 게이트 + 수정

4

$244.69

웨이브 3-4

5

$130.84

웨이브 5 (프로덕션) + 백업 감사

2

$15.20

웨이브 6 (스키마 마이그레이션)

3

$118.83

웨이브 7 (종속성, 문서, 지식) + 최종 게이트

4

$96.64

인프라 수정

1

$11.47

합계

40

$1,155.38

세부 내역에서 눈에 띄는 세 가지 사항이 있습니다.

1. 매니페스트를 생성한 전체 12개 세션 감사 단계의 비용은 $90 미만이었습니다. 이는 우리가 지금까지 산 보험 중 가장 저렴한 것입니다.
2. 가장 비용이 많이 드는 항목은 정확히 어려운 사고가 필요한 곳에 위치했습니다: 얽힘 수술($299)과 모든 것을 정직하게 유지한 회귀 게이트($245)입니다.
3. 가장 위험이 큰 단계인 프로덕션 데이터 변경 비용은 $15였습니다. 실행될 때쯤에는 모든 위험이 이미 제거되었기 때문입니다.

참고: Devin이 서브 에이전트에 대해 다른 모델을 선택할 수 있도록 허용했다면 이 전체 프로젝트는 훨씬 더 저렴했을 수 있습니다. 대부분의 코딩 작업은 gpt 5.5 또는 opus 4.8로도 성공적으로 완료될 수 있었습니다. Fable에게 서브 에이전트 작업에 적합한 모델을 선택하도록 지시하는 것은 간단했을 것입니다.

하지만 그런 기능이 없더라도: $1,000는 우리가 완료한 작업에 비해 믿을 수 없을 정도로 저렴하며, 작업이 완료되고 검증된 속도는 정말 놀랍습니다.

https://x.com/ryancarson/status/2072694425365426344

결론

핵심은 AI가 많은 코드를 작성했다는 것이 아닙니다. 잘 지정된 변경 사항을 실행하는 에이전트는 이제 기본적인 사항입니다.

핵심은 프로그램 관리 자체가 위임되었다는 것입니다: 분해, 순서 지정, 병렬화, 게이팅, 에스컬레이션이 모두 오케스트레이터 내에서 실행되었고, 인간의 역할은 소유자가 필요한 결정으로 정확히 압축되었습니다.

이를 시도하려면 도구가 아닌 패턴을 가져가십시오:

1. 먼저 감사하고, 어떤 워커도 재론할 수 없는 매니페스트에 결과를 고정하십시오.
2. 위험도에 따라 웨이브 순서를 정하고, 되돌릴 수 없는 단계는 마지막에 배치하십시오.
3. 병렬 워커에게 명시적으로 서로 겹치지 않는 파일 경계를 제공하십시오.
4. 모든 웨이브를 실제 회귀 테스트 스위트와 실제 백업으로 게이트하십시오.
5. 파괴적인 변경 전에 제안된 인벤토리를 요구하고, 아이디어가 아닌 목록을 승인하십시오.
6. 예상치 못한 상황이 발생하기 전에 에스컬레이션 경로를 정의하십시오.
7. 프로젝트의 일부로, 프로젝트 후가 아닌 시점에 문서와 에이전트 지식을 업데이트하십시오.

즐거운 오케스트레이팅 되세요! :)