프롬프팅은 2024년에 죽었다. 새로운 기술은 오케스트레이션이다
1,000개의 AI 에이전트를 30일 동안 운영해본 결과를 공유합니다
프롬프팅을 대체한 기술, 그리고 지금 당장 실행할 수 있는 시스템들
프롬프트 최적화는 그만하세요. 더 이상 병목이 아닙니다.
하나의 에이전트가 하나의 채팅 창에서 작업할 때는 프롬프트가 거의 전부였습니다.
하지만 열 개의 에이전트가 몇 시간 동안 실행되면, 프롬프트는 오차 범위에 불과해집니다.
작업의 품질을 결정하는 것은 에이전트를 둘러싼 시스템입니다:
- 각 작업이 어떤 모드로 실행되는지
- 각 단계를 어떤 모델이 처리하는지
- 에이전트들이 어떻게 조정되는지
- 사용자가 잠든 사이에 '완료'가 어떻게 검증되는지
프롬프트는 하나의 결과물을 얻습니다. 루프는 복합적인 연산을 얻습니다.
변화는 간단합니다. 더 이상 각 결과를 읽고 다음 지시를 입력하는 사람이 아니라, 시스템을 한 번 설계하고 실행하도록 두는 사람이 되는 것입니다.
그 설계 레이어가 이제 여러분의 역할입니다. 이를 구축하는 방법은 다음과 같습니다.
오케스트레이터를 구축하세요, 코드를 구축하지 마세요
30개의 에이전트를 관리하기 위해 30개의 에이전트와 대화하지 않습니다. 하나의 에이전트와 대화합니다. 그 하나가 오케스트레이터이며, 나머지를 관리합니다.
좋은 오케스트레이터는 정확히 세 가지 일을 합니다:
- 목표를 경계가 명확하고 독립적으로 확인 가능한 하위 작업으로 분해합니다.
- 각 하위 작업을 작업자에게 위임하며, 간결한 지침과 명확한 파일 소유권을 부여합니다.
- 결과를 취합하고 다음에 무엇을 할지 결정합니다.
무엇보다 중요한 규칙이 하나 있습니다: 오케스트레이터는 절대 스스로 작업을 수행하지 않습니다.
주요 에이전트가 구현 코드를 작성하기 시작하면, 컨텍스트가 세부 사항으로 가득 차서 전체 작업의 흐름을 놓치게 됩니다.
오케스트레이터의 컨텍스트를 깔끔하게 유지하세요. 생각하고, 분할하고, 할당하고, 확인하는 일만 합니다. 그 외에는 아무것도 하지 않습니다.
그런 다음 넓게 확장하지 말고 깊이 파고드세요:
- 오케스트레이터가 8명의 작업자를 직접 생성하지 마세요. 그러면 컨텍스트가 산산조각납니다.
- 대신 2~3명의 리드를 생성하게 하세요.
- 각 리드가 자신만의 2~3명의 전문가를 생성하게 하세요.
결과는 동일한 컨텍스트 비용으로 3배의 분해 깊이를 얻는 것입니다. 이것이 실제 조직이 확장되는 방식입니다. 한 사람이 모든 작업을 할당하는 것이 아니라 계층을 통해 확장하는 것입니다.
검증 가능 여부: 모든 것을 결정하는 분할
무엇을 구축하기 전에 작업에 대해 한 가지 질문을 해야 합니다. 기계가 작업이 완료되었는지 확인할 수 있습니까?
그 답이 전체 접근 방식을 결정합니다.
작업이 검증 가능하다면, 루프를 돌릴 수 있습니다:
- 테스트가 통과하거나 통과하지 못합니다.
- 타입 검사기가 통과하거나 통과하지 못합니다.
- 벤치마크가 임계값을 넘거나 넘지 못합니다.
검증 가능한 작업에 에이전트를 투입하면 하룻밤 사이에 언덕을 오를 것입니다. 아침에 일어나면 문제가 해결되어 있습니다.
작업이 검증 불가능하다면, 루프만으로는 해결되지 않습니다. 예시:
- 좋은 평가(Eval) 설계하기.
- API가 적절한지 판단하기.
- 연구 방향을 추구할 가치가 있는지 판단하기.
이러한 경우에는 취향(Taste)을 주입해야 합니다. 목표를 넘겨주고 자리에서 떠날 수 없습니다. 정지할 게이트가 없기 때문입니다.
따라서 해야 할 일은 가능한 한 많은 작업을 검증 가능하게 만드는 것입니다:
- "좋게 만들어"를 "이 특정 검사들을 통과해"로 바꾸세요.
- 모호한 목표를 구체적이고 측정 가능한 목표로 대체하세요.
- 불가능한 경우에는 인간을 루프에 남겨두고 방향을 조정하세요.
오케스트레이션 엔지니어링의 대부분은 모호한 목표를 확인 가능한 목표로 변환하여 루프가 작업을 대신하게 하는 것입니다.
가장 작은 실제 시스템부터 시작하세요: 목표 루프
목표 루프는 지속적인 목표와 결정론적 검사로 구성됩니다. 에이전트는 한 번의 턴 후에 멈추는 대신 목표를 향해 단계별로 계속 작업합니다.
전체 시스템은 에이전트와 검증기를 둘러싼 루프입니다:
1i=02until npm test -s; do3 agent -p "목표: 테스트 스위트를 통과하게 만드세요.4 코드를 읽고, 변경하기 전에 전체 그림을 그리세요.5 'npm test'가 실패하고 있습니다. 통과를 위한 가장 작은 변경을 가하세요."6 (( ++i > 20 )) && { echo "중지: 20회 반복"; exit 1; }7done
검증기는 종료 코드가 게이트 역할을 하는 모든 명령어입니다. 테스트, 타입 검사, 린트 또는 사용자 정의 스크립트 등이 해당됩니다.
두 가지는 타협할 수 없습니다:
- 상한선. 중지 조건이 없는 루프는 깨어났을 때 다섯 자리 수 토큰 청구서를 보게 되는 지름길입니다.
- 읽기 우선 지시. 모든 에이전트의 기본 실패 모드는 코드를 읽는 대신 처음 발견한 그럴듯한 수정을 무작위로 시도하는 것입니다.
읽기를 강제하세요. 단계별로는 더 느리지만 전체적으로는 훨씬 빠릅니다.
'완료'를 타협 불가능하게 만드세요: 심판
에이전트는 일찍 그만둡니다. 그들은 정당화할 수 있는 순간 멈추도록 훈련되어 있습니다.
"최선을 다했지만 여기서 멈춥니다"는 완료와 같지 않습니다.
에이전트가 자신의 숙제를 스스로 평가하면 속임수를 씁니다. 악의적으로가 아니라, 스스로 끝났다고 납득시키기 때문입니다.
해결책은 별도의 심판입니다:
- 구체적인 평가 기준에 따라 작업을 평가하는 것이 유일한 임무인 두 번째 에이전트.
- 완료 또는 미완료, 그리고 무엇이 누락되었는지라는 한 가지 질문에 답합니다.
- 중단할 이유가 없기 때문에 주저하지 않습니다.
빌더와 심판을 서로 다른 모델 패밀리에서 실행하세요. 서로 다른 패밀리는 상관관계가 없는 실수를 하기 때문에, 심판은 빌더가 보지 못하는 것을 발견합니다.
1while :; do2 agent --model "$BUILD" -p "작업: $TASK. 먼저 읽고, 구현하고, 테스트를 실행하세요."3 verdict=$(agent --model "$JUDGE" -p "엄격한 검토자입니다. rubric.md의 모든 항목에 대해 점수를 매기세요.4 정확히 'PASS' 또는 'FAIL: <누락된 사항>'으로 답변하세요.")5 [[ $verdict == PASS* ]] && break6done
평가 기준을 구체적이고 이분법적으로 만드세요:
- 좋은 평가 기준: "모든 테스트 통과, 마이그레이션 포함, 디버그 로깅 없음."
- 나쁜 평가 기준: "좋게 만들어."
거부권을 가진 무관심한 검사자는 작업자가 지칠 때 작업이 중단되는 것을 방지하고 몇 시간 동안 실행을 지속할 수 있게 해주는 유일한 요소입니다.
모든 작업 완료 시 실행하세요. 그러면 검증된 작업만 보게 됩니다.
실제로 사용하게 될 더 많은 루프들
목표 루프는 기본 패턴입니다. 몇 가지 변형만으로 대부분의 경우를 처리할 수 있습니다.
1. 검증 루프.
실행하고, 검증기를 실행하고, 실패를 피드백하고, 게이트가 통과할 때까지 반복합니다.
회귀 스윕, 타입 검사 및 모든 결정론적 성공/실패에 사용하세요.
2. 큐 및 리셋 루프.
작업을 작고 원자적인 작업 목록으로 나누세요. 한 번에 하나씩 처리합니다.
각 작업 후에는 에이전트를 깨끗한 컨텍스트로 재설정하고 다음 작업을 가져옵니다.
몇 시간 동안 실행되는 컨텍스트는 혼란으로 가득 차게 됩니다. 리셋은 각 작업을 깨끗하게 유지합니다.
메모리는 에이전트 외부, 작업 파일과 커밋 기록에 존재합니다.
1while read -r task; do2 agent -p "작업: $task. 먼저 읽으세요. 구현한 후 테스트를 실행하세요."3 npm test -s && git commit -aqm "자동: $task" # 통과 시에만 커밋4done < tasks.txt
3. 모니터 루프.
신호 스트림에 에이전트를 연결하고 중요한 것을 표면화하도록 합니다. 공개된 이슈, 실패한 빌드, 오류 로그, 새로운 피드백 등.
사용자가 물을 때까지 기다리지 않습니다. 읽고, 분류하고, 보고하거나 초안 수정을 제안합니다.
1while sleep 300; do2 agent -p "지난 5분간의 오류 로그를 읽으세요. 새로운 패턴이 나타나면3 최소 재현 코드와 함께 이슈를 여세요. 그렇지 않으면 '새로운 것 없음'이라고 말하세요."4done
4. 계획 후 구축 루프.
루프를 두 단계로 실행하세요. 먼저 계획 수립 단계에서 서면 계획을 생성하고 중단합니다.
사용자가 계획을 검토합니다. 그런 다음 실행 단계에서 승인된 계획을 따릅니다.
계획은 수정하기 쉽습니다. 코드는 수정하기 어렵습니다. 잘못된 방향은 계획 단계에서 잡으세요.
실제 작업을 수행하는 프롬프트들
프롬프트는 소원이 아닙니다. 에이전트에게는 명세서(Spec)입니다.
평범한 결과물과 뛰어난 결과물의 차이는 거의 전적으로 프롬프트의 품질에 달려 있습니다.
재사용 가능한 소수의 프롬프트를 보관하세요. 5개면 대부분의 작업을 처리할 수 있습니다.
1. 분해 프롬프트, 오케스트레이터용:
1당신은 오케스트레이터입니다. 코드를 작성하지 마세요.2이 목표를 3~6개의 경계가 명확한 하위 작업으로 분해하세요.3각 작업에 대해: 한 줄 요약, 정확한 파일 소유권, 완료 확인 조건.4다른 작업에 의존하는 작업이 있으면 표시하세요. 목록을 출력한 후 중지하세요.5목표: <goal>
2. 작업자 지침, 전문가용:
1당신은 다음 파일만 소유합니다: <files>.2작업: <한 줄>. 완료 조건: <검증 가능한 확인>.3편집하기 전에 해당 파일과 호출자를 읽으세요. 자신의 파일 밖은 변경하지 마세요.4완료되면 <name>.md에 5줄 보고서를 작성하고 테스트를 실행하세요.
3. 심판 프롬프트, 다른 모델 패밀리용:
1당신은 엄격하고 인색한 검토자입니다. 이 코드를 작성하지 않았습니다.2다음의 모든 항목에 대해 저장소를 평가하세요. 누락은 FAIL입니다.3<rubric>4정확히 한 줄로 답변하세요: 'PASS' 또는 'FAIL: <누락된 사항>'.
4. 계획 우선 프롬프트, 계획 모드용:
1<goal>에 대한 서면 계획을 작성하세요. 포함 사항: 접근 방식, 수정할 파일,2에지 케이스, 테스트 전략, 그리고 하지 않을 것.3아직 코드를 작성하지 마세요. 검토할 수 있도록 계획 후에 중지하세요.
5. 반성 또는 중단 프롬프트, 에이전트가 막혔을 때:
1동일한 검사를 3번 실패했습니다. 동일한 접근 방식을 반복하지 마세요.23줄로 답변하세요: 정확히 무엇이 실패했는지, 어떤 가정이 틀렸는지,3그리고 시도할 가장 작은 다른 방법. 그런 다음 그것만 시도하세요.
다섯 가지 모두에 공통된 패턴이 있습니다. 역할, 경계, 완료 조건, 그리고 하지 말아야 할 것을 명시하세요.
모델 라우팅: 모두가 묻는 질문
질문은 일반적으로 선택의 문제로 제기됩니다. 고가 모델을 계획에 투입할까요, 구현에 투입할까요?
그것은 잘못된 프레임입니다. 대신 영향 반경(Blast Radius)을 기준으로 라우팅하세요. 실수가 가장 큰 비용을 초래하는 곳이 어디인지 질문하세요.
논리는 간단합니다:
- 계획 수립 단계의 잘못된 결정은 전체 플릿(Fleet)에 영향을 미칩니다.
- 경계가 명확하고 테스트된 함수의 잘못된 한 줄은 몇 분 안에 발견됩니다.
- 따라서 오류 비용이 크고 되돌릴 수 없는 곳에 비용을 투자하고, 오류 비용이 저렴하고 통제된 곳에서는 비용을 절약하세요.
다음은 계층별 라우팅입니다:
- 계획, 아키텍처 및 분해: 항상 최상위 티어. 가장 높은 레버리지, 미미한 토큰 볼륨. 여기서 저렴하게 가는 것은 가장 큰 실수입니다.
- 엄격한 명세가 있는 구현: 중간 티어, 병렬 실행. 명세가 생각을 대신했습니다. 테스트로 검증하세요.
- 느슨한 명세가 있는 구현: 최상위 티어. 간격 메우기는 추론이며, 저렴한 모델은 여러 방향으로 잘못 추측합니다.
- 검토 및 판단: 다른 패밀리, 저렴하지 않은 모델. 값비싼 실수를 잡아내는 곳입니다.
- 탐색, 검색, 요약 및 분류: 가장 저렴하고 빠른 모델. 추론 제로, 높은 볼륨. 프리미엄 요금을 grep에 지불하지 마세요.
따라서 "저렴한 계획 또는 저렴한 구현"에 대한 실제 답변은 맹목적으로 둘 다가 아닙니다.
계획 및 검토에는 항상 최상위 모델을 사용하세요. 구현은 변동 가능한 부분입니다.
또한 서로 다른 모델 패밀리는 서로 다른 특성을 가지며, 이는 라우팅에 중요합니다:
- 한 패밀리는 간격을 메웁니다. 명세가 느슨할 때 합리적인 가정을 하고 계속 진행합니다. 이는 가정이 좋을 때는 도움이 되고, 그렇지 않을 때는 해가 됩니다.
- 다른 패밀리는 문자 그대로입니다. 정확히 지시한 대로만 수행하며, 정밀한 유틸리티 나이프와 같습니다.
작업이 개방적이고 명세가 느슨한 곳에서는 간격 메우기 모델을 사용하세요. 검토 및 정확하고 잘 정의된 변경에는 문자 그대로 모델을 사용하세요.
구현을 제어하는 레버는 바로 명세입니다
- 엄격한 명세는 저렴하고 병렬적인 작업자를 실행할 권리를 부여합니다.
- 느슨한 명세는 간격을 메우기 위해 다시 고가 모델을 사용하도록 강제합니다.
구축 비용을 낮추기 위해 계획에 정확하게 투자하세요.
한 가지 함정을 언급할 가치가 있습니다. 저렴한 라우팅은 각 호출의 가격을 최적화하지만, 출시 가능하고 병합 가능한 결과물을 생성하는 토큰의 비율을 조용히 파괴할 수 있습니다.
다섯 번 재시도하고 병합할 수 없는 코드를 생성하는 저렴한 모델은 프리미엄 모델의 한 번의 깔끔한 패스보다 더 비쌉니다.
호출당 비용이 아니라 유용한 결과물의 비용을 측정하세요.
규모 측면에서 두 가지 숫자가 도움이 됩니다:
- 최상위 티어는 저렴한 티어의 토큰당 출력 가격보다 약 5배 비쌉니다.
- 계층적 라우팅은 일반적으로 최고 모델을 모든 곳에 실행하는 것보다 지출을 40%에서 60%까지 줄입니다.
스킬: 워크플로를 한 번 패키징하고 영원히 재사용하세요
동일한 프롬프트를 반복해서 붙여넣거나 동일한 워크플로를 반복 실행한다면, 그것을 스킬로 전환하세요.
스킬은 에이전트가 관련될 때만 로드하는 작은 명령 파일입니다.
워크플로를 한 번 작성하면 모든 에이전트가 사용할 수 있습니다.
스킬 파일은 두 부분으로 구성됩니다:
- 이름과 설명이 포함된 YAML 프론트매터.
- 실제 지침이 포함된 마크다운 본문.
설명이 가장 중요한 줄입니다. 에이전트에게 스킬이 무엇을 하는지, 정확히 언제 사용해야 하는지 알려주어, 사용자가 이름을 지정하지 않아도 에이전트가 스스로 선택하도록 합니다.
최소 스킬 파일:
1---2name: 써모뉴클리어-리뷰3description: 심층적이고 적대적인 코드 리뷰. 중요하지 않은 변경 후,4 또는 병합 전에 diff를 검토, 감사 또는 강화하라는 요청을 받았을 때 사용하세요.5---67# 써모뉴클리어 리뷰89전체 diff와 관련 파일을 읽으세요. 대충 훑어보지 마세요.1011세 단계로 검토하세요:121. 정확성: 논리 오류, 에지 케이스, 경쟁 상태, off-by-one 오류.132. 안전성: 인젝션, 인증, 시크릿, 안전하지 않은 입력, 파괴적인 작업.143. 적합성: 기존 아키텍처와 일치하는가, 아니면 새로운 패턴을 추가하는가?1516각 발견 사항에 대해: 파일, 줄, 심각도, 한 줄 수정 방법.17마지막에 평결을 내리세요: SHIP 또는 BLOCK, 그리고 가장 먼저 수정해야 할 상위 3가지.
좋은 스킬을 위한 규칙:
- 파일을 짧게 유지하세요. 수백 줄 미만. 긴 참고 자료는 스킬이 가리키는 별도 파일로 옮기세요.
- 이름을 폴더와 일치시키세요. 그렇지 않으면 로드되지 않습니다.
- 트리거를 위한 설명을 작성하세요. "언제 사용" 케이스를 명시하세요.
- 에이전트가 스킬을 다시 작성하도록 절대 허용하지 마세요. 인간이 모든 줄을 관리합니다.
스킬은 워크플로가 복리 효과를 내는 방법입니다. 어떤 것을 잘 해결한 첫 번째에 저장하고 검색 가능하게 만드세요. 그 이후의 모든 세션에서는 공짜입니다.
대규모 실행: 플릿
하나의 루프가 작동하면 확장합니다.
각 작업자에게 두 가지를 제공하세요:
- 자체 git 워크트리(Worktree). 두 에이전트가 동일한 파일을 건드리지 않도록 합니다.
- 자체 터미널 창. 모니터링하고 메시지를 보낼 수 있습니다.
1tmux new-session -d -s fleet2for name in hilbert gauss poincare; do3 git worktree add -B "agent/$name" "../wt-$name" main4 tmux new-window -t fleet -n "$name" -c "../wt-$name" "$AGENT"5done
- 에이전트에 이름을 지정하세요. 15개를 실행할 때 "agent_7"은 쓸모가 없습니다.
- 이름을 사용하면 전체 플릿을 머릿속에 담을 수 있습니다. 이 에이전트는 데이터 레이어를 담당하고, 저 에이전트는 평가를 작성하고, 저 에이전트는 검토합니다.
- 가독성이 핵심입니다. 추적할 수 없는 플릿은 조종할 수 없는 플릿입니다.
- 그런 다음 협력하게 만드세요. 기본적으로 에이전트는 서로를 무시하고 형제 에이전트의 모든 것을 배경 소음으로 취급합니다.
비결은 에이전트 간 메시지를 사용자 턴으로 전달하는 것입니다. 모델은 사용자에게 응답하고 주변 신호는 대부분 무시하도록 훈련되어 있습니다.
1send() { tmux send-keys -t "fleet:$1" "$2" Enter; }2send hilbert "GET /search?q= returns [{id,title,url}]. UI를 연결하세요."
한 번의 움직임으로 격리된 프로세스 더미가 계약을 전달하고 서로의 블로킹을 해제하는 팀으로 변모합니다.
사용자는 최상위에 남아 있습니다. 리드에게 메시지를 보내면 리드가 작업자에게 전달합니다.
동적 워크플로: 조정을 코드로 컴파일하세요
루프는 조정을 모델 내부에 유지합니다. 모델이 각 단계를 결정하며, 이는 토큰을 소모하고 컨텍스트를 채웁니다.
동적 워크플로는 이를 뒤집습니다. 오케스트레이터가 작업자를 조정하는 스크립트를 작성하고, 별도의 런타임이 백그라운드에서 스크립트를 실행합니다.
핵심 아이디어는 상태가 어디에 살아있는지입니다. 루프, 분기 및 중간 결과는 모델의 메모리가 아닌 스크립트의 변수에 있습니다.
그것이 주는 이점:
- 조정 비용이 모델 토큰을 소모하지 않습니다. 일반 코드가 처리하기 때문입니다.
- 주요 컨텍스트가 깔끔하게 유지됩니다. 최종 결과만 돌아옵니다.
- 넓게 확장됩니다. 한 번에 수십 명의 작업자, 실행당 최대 천 명까지.
언제 사용해야 하는지:
- 패턴이 알려져 있고 검증이 객관적일 때.
- 작업이 넓고 반복적일 때. 많은 파일, 많은 케이스, 많은 엔드포인트.
- 무인 실행이 가능할 때.
언제 사용하지 말아야 하는지:
- 아무것도 결정되지 않았을 때. 그런 경우는 목표 루프이지 워크플로가 아닙니다.
- 작업이 하나의 일관된 추론 체인을 필요로 할 때. 그런 경우는 천 개가 아닌 하나의 강력한 에이전트가 필요합니다.
구체적인 예시. 200개의 파일을 새 API로 마이그레이션해야 한다고 가정해 보겠습니다:
1// 오케스트레이터가 이것을 한 번 작성합니다. 런타임이 모델 대신 실행합니다.2const files = await glob("src/**/*.ts");34const results = await mapLimit(files, 16, async (file) => {5 const r = await subagent(`${file}을(를) 새 API로 마이그레이션하세요. 테스트를 실행하세요.`);6 return { file, ok: r.testsPassed };7});89const failed = results.filter(r => !r.ok);10return `총 ${results.length}개 중 ${results.length - failed.length}개 마이그레이션 완료. ` +11 `재시도: ${failed.map(f => f.file).join(", ")}`;
이것이 무엇을 하는지 읽어보세요:
- 모델의 머리 속이 아닌 코드에서 200개의 파일을 나열합니다.
- 한 번에 16개의 서브 에이전트를 실행하며, 각각 하나의 파일을 마이그레이션하고 테스트를 실행합니다.
- 파일별로 성공 또는 실패를 일반 배열에 기록합니다.
- 하나의 짧은 요약을 반환합니다. 200개의 중간 기록은 컨텍스트에 절대 닿지 않습니다.
그것이 바로 핵심입니다. 모델은 스크립트를 작성하기 위해 한 번만 생각했습니다. 스크립트는 조정을 공짜로 수행했습니다.
가드레일: 플릿이 스스로를 잡아먹지 않도록 방지하는 장치
인간 병목 현상은 실제 작업을 수행하는 데 사용되었습니다. 인간 속도에서는 실수가 조기에 피해를 주고 진행하면서 수정합니다.
자신을 완전히 제거하면 작은 오류가 느낄 수 있는 것보다 빠르게 확대됩니다. 여기서 중복, 저기서 불필요한 추상화.
어느 날 아키텍처는 구부러지지 않을 것이고, 에이전트도 테스트를 작성했기 때문에 테스트를 신뢰할 수 없게 됩니다.
아래의 모든 가드레일은 병목 현상이 제공하던 수정을 대체합니다:
- 추측하기 전에 읽으세요. 모든 빌드 프롬프트에서 작업별 요청이 아닌 상시 규칙으로 만드세요.
- 상한선 및 종료. 모든 루프에는 반복 제한이 있습니다. 모든 에이전트에는 약 85% 근처에서 자동 일시 중지되는 토큰 예산이 있습니다. 동일한 오류로 3번 연속 막히면 에이전트를 종료하고 작업을 새 에이전트에 넘기세요.
- 하나의 파일, 하나의 소유자. 워크트리로 격리하세요. 두 에이전트가 동일한 파일을 편집하지 못하게 하세요.
- 임무를 다시 주입하세요. 긴 실행 중에는 몇 분마다 체크리스트를 사용자 메시지로 게시하여 에이전트가 컨텍스트가 채워짐에 따라 표류하지 않도록 하세요.
1while sleep 900; do2 send gauss "알림: 아직 작업 중입니까? 먼저 읽으세요. 각 변경 후 테스트를 실행하세요. 자신의 파일 안에 머무르세요."3done &
모든 것의 밑바탕에는 가장 깊은 지점이 있습니다:
- 이제 검증이 병목 현상이지 생성이 아닙니다.
- 에이전트는 확인할 수 있는 것보다 빠르게 그럴듯한 출력을 생성합니다.
- 그럴듯함은 정확함과 같지 않습니다.
검증이 생성만큼 빨라질 때까지 인간 검토는 오버헤드가 아닙니다. 그것은 안전 시스템입니다.
메모리: 당신이 장기 저장소입니다
모델은 단기 기억, 즉 컨텍스트 윈도우만 있으며 그 외에는 아무것도 없습니다. 그 윈도우를 지난 모든 것은 직접 전달하지 않으면 사라집니다.
따라서 자신과 유지하는 파일을 단기 기억만 있는 에이전트의 장기 기억으로 취급하세요.
두 가지 습관이 중요합니다.
첫째, 요약이 아닌 참조로 상태를 전달하세요:
- 컨텍스트가 가득 차면 게으른 수정은 요약하는 것입니다. 요약은 손실이 있으며 나중에 필요할 세부 사항을 버립니다.
- 대신 에이전트가 파일, 작업 기록 및 이전 출력을 다시 읽을 수 있도록 가리키세요. 중요한 것이 조용히 버려지지 않습니다.
둘째, 에이전트 외부에 지속적인 메모리를 유지하세요:
- 상태가 포함된 작업 파일.
- 진행 상황 로그.
- 커밋 기록.
- 패턴과 문제점을 수집하는 장기 노트 파일.
에이전트가 며칠 동안 실행될 것처럼 설계하세요. 좋은 압축을 통해 실제로 그렇게 될 것이기 때문입니다.
모델은 아직 자신에 대해 이것을 알지 못합니다. 그들은 마치 토큰을 소비하는 것이 치명적인 것처럼 하나의 짧은 예산 내에서 모든 것을 해결하려는 편향을 가지고 있습니다. 당신의 스캐폴딩이 그들이 흐름을 잃지 않고 오래 실행할 수 있게 해줍니다.
토폴로지: 몇 개의 에이전트와 어떤 형태로 배치할 것인가
더 많은 에이전트가 더 많은 출력을 의미하지는 않습니다. 특정 지점을 넘으면 오히려 줄어듭니다. 조정은 공짜가 아니며 추가하는 에이전트마다 비용이 증가하기 때문입니다.
중요한 규칙은 작업에 맞게 형태를 일치시키는 것입니다:
- 순차적이고 의존적인 추론은 더 적은 에이전트가 필요하며, 때로는 하나만 필요합니다. 단일 추론 체인을 분할하면 추론이 파편화되고 결과가 저하됩니다.
- 독립적이고 병렬적인 작업은 확장하는 것이 좋습니다. 평면 토폴로지, 깔끔한 파일 소유권. 이것이 병렬 처리가 효과를 발휘하는 곳입니다.
- 조정된 팀은 3~5명의 작업자를 원합니다. 토큰 비용은 크기에 따라 대략 선형적으로 증가합니다. 조정 비용은 더 나쁘게 증가합니다. 세 명의 집중된 작업자가 다섯 명의 분산된 작업자보다 낫습니다.
그렇다면 어떻게 수백 개를 실행할 수 있을까요? 하나의 거대한 대화가 스스로와 논쟁하는 것이 아닙니다.
깊이와 독립성으로 실행합니다:
- 실제로 대화하는 소수의 에이전트, 각각은 조정할 필요가 없는 경계가 명확한 하위 작업에 위임합니다.
- 각자 자신의 일을 하고 보고하는 독립적인 루프의 떼(Swarms).
확장은 위임 깊이와 독립성에서 비롯됩니다. 단일 스레드를 넓히는 것에서 절대 비롯되지 않습니다.
제어 파일: orchestration.md
저장소에서 에이전트가 코드를 작성하는 방법을 알려주는 파일을 아마 가지고 있을 것입니다. 스타일, 문제점, 아키텍처. 계속 유지하세요.
그러나 그것은 오케스트레이션에 대해 잘못된 질문에 답합니다.
orchestration.md 파일은 다른 질문에 답합니다. 여기서 작업이 어떻게 실행되어야 하는가?
다음을 다루는 인간이 작성한 계약입니다:
- 어떤 작업에 어떤 모드를 사용할지
- 어떤 모델 계층이 어디에 배치될지
- 가드레일은 무엇인지
- 언제 인간에게 에스컬레이션할지
모든 에이전트는 매 세션 시작 시 이를 읽고 접근 방식을 스스로 선택하는 데 사용합니다.
이것은 저장소에서 가장 레버리지가 높은 파일입니다. 세션마다 일관성 없이 다시 결정하는 머리 속의 모드 선택 결정을 플릿이 따르는 명세로 옮깁니다.
짧은 버전은 다음과 같습니다:
1# orchestration.md. 여기서 작업이 실행되는 방식입니다. 인간이 관리합니다. 에이전트는 편집할 수 없습니다.23모드를 선택하세요:4- 목표 루프 (감독): 모호하거나 디자인 작업. 완료 확인을 정의하세요.5- 검증 루프: 결정론적 게이트. 항상 반복 횟수와 비용에 상한선을 두세요.6- 구축 + 심판: 작업자가 구축하고, 다른 패밀리 심판이 승인합니다.7- 플릿 (3~5명): 상호 의존적인 하위 작업, 격리된 워크트리, 피어 메시징.8- 큐 및 리셋: 많은 작은 원자적 작업, 각각 새로운 컨텍스트.9- 동적 워크플로: 알려진 패턴, 객관적 게이트, 넓고 반복적. 코드 내 조정, 무인 실행.1011영향 반경별 모델 라우팅:12- 계획 및 아키텍처: 항상 최상위 티어.13- 구축, 엄격한 명세: 중간 티어, 병렬, 테스트로 검증.14- 구축, 느슨한 명세: 최상위 티어. 간격 메우기는 추론이기 때문.15- 검토 및 판단: 다른 패밀리. 절대 구현자의 모델을 사용하지 마세요.16- 탐색, 검색, 요약: 가장 저렴한 모델. 호출 가격이 아닌 병합 가능한 출력을 최적화하세요.1718가드레일:19- 에이전트당 토큰 예산. 약 85%에서 자동 일시 중지. 3번 막히면 종료 및 재할당.20- 1시간 이상 실행되는 모든 작업은 별도의 심판이 필요합니다. 작업자는 스스로 완료를 보고하지 않습니다.21- 가설을 세우기 전에 코드를 읽으세요. 첫 번째 편집 전에 서면으로 계획하세요.
파일을 지배하는 두 가지 규칙:
- 짧게 유지하세요.
- 에이전트가 다시 작성하도록 절대 허용하지 마세요.
가치는 모든 줄을 인간이 관리했다는 점입니다.
당신의 몫으로 남는 것
오케스트레이션은 에이전트가 실행에 있어 신뢰할 수 있게 만듭니다. 문제를 선택하지 않으며, 좋은 것이 무엇인지 알지 못합니다.
세 가지가 영구적으로 당신의 책임으로 남습니다.
첫째, 판단이 아닌 작업을 위임하세요:
- 명확한 성공/실패 기준이 있는 범위가 지정된 작업을 에이전트에 넘기세요. 상용구, 마이그레이션, 테스트 스캐폴딩, 그리고 직접 시도할 시간이 없었던 접근 방식.
- 아키텍처, 구축하지 않을 것에 대한 결정, 그리고 전체 컨텍스트 검토는 스스로 하세요.
- 에이전트는 평범한 아키텍처의 바다를 흡수했으며, 필요하지 않은 프로젝트에 무거운 패턴을 기꺼이 복사해 넣을 것입니다. '아니오'라고 말하는 것은 그들이 가지고 있지 않은 기능입니다.
둘째, 당신의 명세가 레버리지입니다:
- 여러 에이전트로 구성된 플릿(fleet)으로 확장할 때, 모호한 사고는 단순히 속도를 늦추는 것이 아니라 증폭됩니다.
- 하나의 모호한 요구사항이 수십 개의 병렬 실행으로 전파되어, 각각 다른 방향으로 잘못 흘러갑니다.
- 반면 정확한 명세는 정확한 구현으로 모든 곳에 배가됩니다.
이것이 강력한 엔지니어가 이러한 도구를 더 활용하는 이유입니다. 타이핑은 자동화되었고, 이해는 증폭되었습니다.
첫 번째 편집 전에, 모두가 동의하는 계획을 먼저 문서화하여 계획 모드(plan mode)에서 대부분의 시간을 보내십시오.
셋째, 의도적으로 과소 투자하십시오:
- 4명의 에이전트가 필요한 작업에 2명만 투입하십시오. 이러한 제약이 원하는 행동을 강제합니다.
- 수동으로 처리하는 대신 루프를 구축하면, 다음 번에는 해당 작업이 이미 자동화되어 있습니다.
- 예산을 수동 작업에서 토큰으로 전환하십시오. 초기에는 높은 투자가 필요하지만, 이후에는 한계 비용이 거의 0에 가깝습니다.
- 이렇게 하는 팀은 복리 효과를 봅니다. 그렇지 않은 팀은 매번 전체 비용을 지불합니다.
더 이상 소프트웨어를 직접 작성하는 것이 아닙니다. 소프트웨어를 작성하는 공장을 구축하는 것입니다.
공장에는 정확한 입력, 모든 스테이션에서의 품질 관리, 그리고 제품이 무엇이어야 하는지 아는 소유자가 필요합니다.
여기서 시작하세요
월요일에 백 개의 에이전트를 실행하려고 하지 마십시오. 단계적으로 진행하십시오:
- 검증 가능한 완료 지점이 있는 작업에서 하나의 목표 루프(goal loop)를 실행하십시오. 좋은 완료 점검(check)이 어떤 느낌인지 배우십시오.
- 1시간 이상 소요되는 작업에는 다른 모델 제품군의 심판(judge)을 추가하십시오. 자체 보고된 완료는 금지하십시오.
orchestration.md를 작성하십시오. 에이전트에게 먼저 읽도록 지시하십시오. 에이전트가 당신을 위해 모드를 선택하기 시작하는 것을 지켜보십시오.- 신중하게 확장하십시오. 하나의 병렬화 가능한 작업, 3~5명의 작업자, 격리된 작업 트리(worktrees), 토큰 예산을 설정하십시오.
- 모델을 라우팅하십시오. 최상위 모델은 계획 및 검토에, 저렴한 모델은 제한된 범위의 빌드 및 반복 작업에 사용하십시오. 병합 가능한 출력을 측정하십시오.
- 패턴이 검증되고 객관적으로 확인 가능해지면 무인 실행을 허용하십시오. 밤새 백로그를 처리하십시오.
시스템은 완벽할 필요 없이 방향성만 맞으면 됩니다:
- 제어 파일은 플릿이 스스로 방향을 잡을 수 있는 충분한 구조를 제공합니다.
- 심판이 예외 상황을 처리합니다.
- 알림 루프(reminder loop)가 메모리를 처리합니다.
- 당신의 안목이 위임할 수 없는 결정을 처리합니다.
프롬프팅은 작년의 기술이었습니다. 이것이 이제 필요한 기술입니다.
여기에 설명된 모든 시스템(목표 루프, 심판 루프, 플릿 런처, 메시지 버스, 알림 감시자, 모델 라우터)의 실행 가능한 버전은 동반 키트(companion kit)에 있습니다. 하나의 변수를 에이전트 CLI로 설정하고 시작하십시오.
면책 조항
이 글은 저자가 Claude Code 세션과 codex 세션을 사용하여 작성했습니다.
문법 및 서식 문제에 대해 저자와 Kimi K2.6 모델이 편집했습니다.
