메타데이터
- 발신자: TLDR (Dev & Engineering)
- 원문 URL: https://martinfowler.com/articles/orchestrator-tax.html?utm_source=tldrnewsletter
- 발행일: 2026-07-29
- 카테고리: dev-engineering
직역 전문
.NET 코드베이스에서 Claude Code 세션을 진행하던 중, 문득 의구심이 들었다. 이미 4개의 서브에이전트가 응답 파이프라인 리팩토링 작업에 투입되어 실행 중이었고, 결과는 순서 없이 도착하고 있었으며, 세션은 코드 자체보다 이해하기 어려워지기 시작했다.
보통 이런 순간은 "아마 괜찮을 것"이라는 막연한 느낌을 더는 믿지 않게 되는 순간이다. 때로는 코드가 문제이고, 때로는 아키텍처가 문제이며, 가끔은 워크플로 자체가 점검을 받아야 한다. 이번에는 워크플로가 문제라고 판단했다.
처음에는 질문이 이미 명확하다고 생각했다. "서브에이전트 4개가 단순히 너무 많았던 것인가?"라는 프레이밍이 합리적으로 느껴졌다. 멀티 에이전트 시스템은 보통 명백한 생산성 향상으로 판매되며, 에이전트 하나가 도움이 된다면 넷은 더 도움이 되어야 한다. 하지만 에이전트가 추가될 때마다 토큰을 소비하고, 일정량의 작업을 반복하며, 오케스트레이터가 조율해야 할 또 하나의 정보 흐름을 더한다. 이는 병렬성과 비용 사이의 단순한 트레이드오프처럼 보였다.
멀티 에이전트 시스템에 대한 일반론적인 주장을 원한 것이 아니었다. 그 세션에 대한 답을 원했다. 그래서 코딩 작업을 멈추고 오케스트레이터에게 자신의 위임 결정을 최대한 사실에 기반하여 스스로 비판해 보라고 요청했다.
돌아온 답은 예상과 달랐다. 세션에서 가장 큰 비용은 4개의 서브에이전트를 실행한 데서 온 것처럼 보이지 않았다. 오히려 오케스트레이터 자신에게서, 정확히는 오케스트레이터가 다른 에이전트들의 상태를 확인하자고 제안했을 때 벌어진 일에서 비롯된 것으로 보였다.
사건의 본질은 병렬성이 아니었다
4개의 서브에이전트가 한 번에 시작되었다. 세 개는 실행 시간이 명확했다. 약 12분, 5분 30초, 7분이었다. 네 번째는 아직 실행 중이었다. 한 가지 관점에서 보면 이것만으로도 위임이 정당화된다. 세 작업이 동시에 실행되었으므로, 순차적으로 실행했을 때의 약 25분 대신 약 12분의 벽시계 시간(wall-clock time)이 걸렸다.
그러나 속도는 눈에 보이는 부산물일 뿐, 흥미로운 부분은 아니었다. 정작 찾고자 한 것은 비용이었고, 첫 직감은 위임 자체의 중복 작업, 즉 모든 서브에이전트가 파일을 읽고 컨텍스트를 재구성하며 독립적으로 작업을 이해하는 데서 비용이 발생했으리라는 것이었다.
가장 큰 놀라움은 거기서 나오지 않았다.
작업 도중 오케스트레이터가 실행 중인 에이전트들의 상태를 확인하자고 제안한 순간이 있었다. "에이전트들 상태 확인해봐"라는 사소하고 즉흥적인 프롬프트였다. 그 제안을 따랐다. 가벼운 요약 대신, 사용된 도구는 백그라운드 에이전트의 전체 원본 트랜스크립트를 통째로 가져왔다. 수만 토큰에 달하는 JSONL, 중간 추론 과정, 도구 출력이 메인 스레드로 통째로 수입되었다. 그리고 두 번째 상태 확인에서도 똑같은 일이 반복되었다.
여기에는 중요한 단서가 있다. 이 폴링(polling) 행위가 4개 에이전트의 중복 비용보다 더 컸다는 주장은 오케스트레이터가 자신의 실수를 스스로 채점한 것이다. 호출별 실제 토큰 계정이 없었으므로, 이 순위는 측정된 사실이 아니라 오케스트레이터의 진술로 취급해야 한다. 신뢰할 수 있는 부분은 더 좁다. 트랜스크립트 덤프는 실제였고, 벽시계 시간도 실제였으며, 상태 확인 경로가 크고 회피 가능한 비용을 명백히 유발했다는 점이다. 그것이 단일 최대 비용이었는지는 도구가 제대로 계측할 수 있을 때까지는 가설로 남는다.
더 중요했던 것은 찾고 있지 않았던 비용을 발견했다는 사실이다.
비용들은 모두 같지 않았다
세션을 하나의 "서브에이전트 비용" 덩어리로 취급하는 것을 멈추자, 그림은 서로 어울리지 않는 조각들로 갈라졌다.
첫째, 4개의 서브에이전트 중 2개는 응답 파이프라인의 같은 영역에서 작업하고 있었다. 작업과 파일은 달랐지만, 둘 다 시작하기 전에 같은 아키텍처, 같은 테스트 관례, 그리고 같은 주변 코드의 상당 부분을 이해해야 했다. 각각이 이 오리엔테이션 비용을 독립적으로 치렀다. 이는 위임에 반대하는 주장이 아니다. 작업이 너무 잘게 쪼개졌다는 주장이다.
둘째, 한 에이전트가 다른 자매 에이전트들이 같은 트리의 다른 곳에 쓰고 있는 동안 git stash와 git stash pop을 실행했다. 아무것도 깨지지는 않았지만, 위험은 구조적이었다. 저장소 전체에 영향을 미치는 작업은 단일 스레드 세션에서는 완전히 합리적이지만, 여러 작성자가 동시에 활성화된 순간부터는 정당화하기 훨씬 어려워지기 때문이다.
이 시점에서 상태 폴링, 중복 오리엔테이션, 안전하지 않은 git 작업이라는 점점 늘어나는 용의자 목록이 생겼다. 어느 것이 가장 큰 비용이었는지 순위를 매기려 했다. 그 답을 찾으려 할수록, 순위를 매기는 것 자체가 옳은 질문인지 확신이 서지 않았다.
희소 자원은 오케스트레이터의 작업 기억이다
트랜스크립트 폴링 사건은 토큰 비용과는 무관한 이유로 계속 신경 쓰였다. 토큰 청구서는 일회성이다. 한 번 지불하면 끝이다. 여기서 벌어진 일은 달랐다. 원본 트랜스크립트는 도구 호출이 끝난 후에도 오케스트레이터의 컨텍스트에 남아 있었고, 이후의 모든 턴이 그것을 계속 이어서 짊어졌다. 여전히 유용한지 여부와 무관하게.
그 순간 두 가지 매우 다른 종류의 비용을 마치 같은 것처럼 취급해 왔다는 것을 깨달았다. 토큰은 한 번 소비된다. 컨텍스트는 이후의 모든 결정에 영향을 미친다. 더는 단순히 토큰 소비량을 보고 있는 것이 아니었다. 오케스트레이터의 작업 기억의 질을 보고 있었다.
이 깨달음은 두 가지 별개의 아이디어를 담고 있었고, 이를 뭉뚱그리지 않고 분리해 보고자 한다. 첫 번째는 방금 설명한 것이다. 컨텍스트에 남은 오염은 이후의 모든 턴에 세금을 매긴다. 두 번째는 공간이 부족해지는 문제가 전혀 아니다. 컨텍스트에 담겨 주의를 다투는 것이 많아질수록, 여전히 여유 공간이 충분하더라도 모델이 지금 중요한 것을 골라내기가 더 어려워진다. 더 큰 컨텍스트 윈도우는 이를 해결하지 못한다. 그저 아무도 알아차리기 전에 노이즈가 쌓일 공간을 더 줄 뿐이다.
컨텍스트 윈도우는 앞으로 계속 커질 것이다. 그것은 기정사실이다. 중요한 것은 그 공간이 얼마나 넓은지가 아니라, 그 공간에 있는 것 중 모델의 주의를 받을 가치가 있는 것이 얼마나 되는지다. 서브에이전트가 제대로 사용된다면 풀어야 할 진짜 문제가 바로 이것이다.
이렇게 보면, 오케스트레이터는 긴 세션에 걸쳐 이해를 축적하는 시스템의 유일한 부분이다. 왜 어떤 설계 결정이 내려졌는지 기억하고, 아키텍처 제약을 계속 이어가며, 어떤 트레이드오프가 이미 논의되었는지 안다. 서브에이전트는 그렇지 않으며, 이는 의도된 설계다. 서브에이전트는 소모품이어야 한다. 탐색, 반복적인 파일 읽기, 실패한 접근법, 노이즈가 섞인 중간 추론은 워커 컨텍스트에 남아 있어야 하며 메인 스레드로 결코 돌아와서는 안 된다.
인지적 지역성이 병렬성의 목적을 바꾼다
이는 중복 오리엔테이션 문제를 재구성한다. 사실 이는 "두 에이전트가 같은 파일을 읽는" 문제가 아니었다. 작업이 필요로 하는 지식이 아니라 태스크 단위로 분할되었기 때문에, 두 에이전트가 독립적으로 같은 코드베이스의 정신 모델을 재구성한 것이었다. 이러한 구분을 "인지적 지역성(cognitive locality)"이라 부르기 시작했다. 같은 정신 모델을 필요로 하는 작업은 함께 있어야 한다. 그것들을 나누면 여러 에이전트가 처음부터 같은 이해를 다시 구축하도록 강제할 뿐이다.
병렬성은 여전히 중요하지만, 그것이 핵심은 아니다. 4개의 에이전트를 동시에 실행하는 것은 유용하지만 평범한 일이다. 진짜 이점은 그것들이 노이즈가 섞인 중간 추론을 메인 스레드 밖에 유지하고, 여전히 필요한 것만 반환한다는 데 있다. 그것이 서브에이전트가 제공해야 할 격리이며, 메인 스레드가 그 격리를 존중할 때만 유지된다.
지금의 작업 가설은 이렇다. 서브에이전트가 존재하는 진짜 이유는 시간을 절약해서가 아니라, 오케스트레이터가 붙잡고 있을 필요가 없는 추론을 오프로드하게 해줘서, 짊어질 것과 주의를 다투는 것을 줄여주기 때문이다. 격리를 제대로 하고, 인지적 지역성에 따라 작업을 국소화하면, 서브에이전트는 병렬성을 위해 감수하는 비용이 아니라 오케스트레이터의 작업 기억을 보호하는 도구가 된다. 다만 이것은 신념이지 측정치는 아니다. 실제로 측정한 것은 그 반대편, 즉 격리를 잘못했을 때의 비용이다.
세션을 상시 규칙으로 전환하기
다음 행보는 명백했다. 모든 세션이 불러오는 상시 지침 파일인 CLAUDE.md에 교훈을 새겨 넣는 것이었다.
방대한 시정 정책을 작성하기는 쉬웠을 것이다. 하지만 상시 지침 파일에 들어가는 한 줄 한 줄은 이후 모든 세션에서 다시 치러야 할 비용이다. 그래서 목격한 실패들을 다루는 가장 작은 규칙 집합으로 수정안을 압축했다. 각 규칙은 결국 같은 질문에 답하는 것이다. 이 정보 조각, 혹은 작업이 나뉜 이 방식이 오케스트레이터의 컨텍스트에 자리 잡을 자격이 있는가?
- 한 번의 실행 배치(wave)에는 2~4개의 에이전트를 선호한다. 오케스트레이터가 5개 이상을 원한다면, 먼저 파일이나 관례를 공유하는 작업들을 합쳐야 하는지 물어야 한다.
- 이미 알고 있는 것으로 답할 수 있을 때는 백그라운드 에이전트의 상태를 폴링하지 않는다. 가벼운 질문에 답하기 위해 전체 트랜스크립트를 가져오지 않는다.
- 동시 실행 에이전트 프롬프트 안에서 저장소 전체에 영향을 미치는 git 작업을 허용하지 않는다.
- 파일 소유권이 겹치는 것을 더 많은 에이전트를 생성하라는 신호가 아니라 통합 신호로 취급한다.
이 중 어느 것도 모든 경우에 오케스트레이터가 정확히 무엇을 해야 하는지 알려주지 않는다. 각각은 실행하기 전에 확인하거나 스스로에게 물어볼 무언가를 줄 뿐, 실행할 스크립트가 아니며, 그 자체로 심오한 것도 아니다. 이들의 유일한 진짜 가치는 모두 같은 목표, 즉 소모품 추론을 소모품으로 유지하고 세션 후반에 필요한 것을 위해 오케스트레이터의 컨텍스트에 공간을 남겨두는 것을 겨냥한다는 데 있다.
다음 실수는 더 많은 거버넌스였을 것이다
이후 세션에서 다른 종류의 공백이 드러났다. 원하는 작업의 종류에 맞춰 오케스트레이터에게 명시적인 스킬(한 경우는 코딩 가이드, 다른 경우는 설계 가이드)을 부여하고 시작했다. 메인 스레드에서 스킬이 활성화되면 생성된 서브에이전트가 자동으로 이를 따를 것이라 가정했다. 그렇지 않았다. 오케스트레이터가 명시적으로 전달하지 않는 한, 서브에이전트는 부모 세션에서 활성화된 스킬을 상속받지 않는다.
첫 직감은 스폰 전 확인 게이트를 추가하는 것이었다. 오케스트레이터가 멈춰서 어떤 에이전트를 실행하려는지, 각각이 어떤 스킬을 로드해야 하는지 나열하고 승인을 기다리게 하는 것이다.
그 버전을 유지하지 않은 것이 다행이다. 그것은 잘못된 문제를 해결했다. 확인 단계가 없어서 나쁜 스폰 계획이 새어 나갔다는 증거는 없었다. 스킬 전파에 관한 누락된 사실을 발견한 것이었고, 그것은 다른 종류의 공백이다. 보편적인 확인 게이트는 유사한 모든 세션에 왕복을 추가했을 것이고, 머지않아 그 프롬프트들을 자동으로 승인하기 시작했을 것이 거의 확실하다.
그 시점에서 거버넌스를 개선하고 있는 게 아니라 또 다른 의례를 추가하고 있을 뿐이라는 것을 깨달았다.
그리고 그것은 이전의 진짜 문제, 즉 오케스트레이터가 자기 컨텍스트를 오염시키는 문제도 잡아내지 못했을 것이다.
더 좁은 수정이 더 잘 유지되었다. 스폰하기 전에, 오케스트레이터는 각 에이전트의 작업과 관련된 활성 스킬이 무엇인지 명시하고, 전체 스킬을 인라인으로 붙여넣는 대신 서브에이전트에게 스킬 파일을 로드하도록 지시한다. 확인은 이미 마련된 동일한 배치 크기 임계값을 초과하거나 파일 소유권이 모호할 때만 필요하다.
이로써 규칙 자체보다 더 자주 쓰는 휴리스틱을 얻었다. 상시 지침 파일에 한 줄을 추가하기 전에, 웬만큼 유능한 오케스트레이터가 그 하나의 누락된 사실을 알기만 하면 올바른 결정을 내릴 것인지 물어보라.
그렇다면, 규칙은 그저 그 사실을 진술하면 된다. 만약 수정안이 승인, 체크포인트, 필수 단계 같은 의사결정 절차를 명시하기 시작한다면, 그것은 대개 작은 명확화로 충분했을 것을 프로세스로 인코딩하고 있다는 신호다.
이 휴리스틱이 더 어려운 사례에서도 살아남을지는 아직 모른다. 지금으로서는 흥미로운 사건 하나하나를 작은 관료제로 바꾸는 것을 막아준다.
지금 남은 것
거버넌스가 얼마나 있어야 충분한지에 대한 확고한 견해는 없으며, 이 글이 그런 결론을 낼 자격이 있다고도 생각하지 않는다.
대신 가진 것은 사람이 여전히 확고히 중심에 있는 작은 플라이휠이다. 세션이 공백을 드러낸다. 누군가 그것이 잘못됐다고 느껴야 하고, 충분히 오래 작업을 멈춰 점검해야 하며, 문제가 실제인지 그냥 노이즈인지 판단하고, 무엇이 상시 규칙이 될 자격이 있는지 판단해야 한다. 오케스트레이터는 여기서 그랬듯 자기 세션을 채점하고 단서를 드러낼 수 있지만, 스스로 그 판단을 내릴 수는 없다. 무엇을 성문화할지, 무엇을 그대로 둘지, 무엇이 과잉 반응일 수 있는지에 대한 선택은 여전히 사람의 몫이다. 다음 세션은 그 판단이 작업을 개선했는지 아니면 또 다른 낭비를 만들었는지 알려준다.
이번 라운드의 결과물은 CLAUDE.md의 현재 버전이다. 완성된 규정이 아니다. 이번 반복 이후의 캘리브레이션 상태일 뿐이다. 그 안의 임계값들(배치당 2~4개 에이전트, 통합 신호로서의 5개)은 그것을 작성할 당시 하던 작업에 맞춘 것이다. 이를 보편 상수처럼 제시하고 싶지 않으며, 그렇게 제시하는 오케스트레이션 글이 있다면 의심할 것이다. 이 값들은 Claude Sonnet 5를 기준으로 조정되었고, 다른 모델에서 어떻게 작동하는지는 테스트하지 않았다. 다른 모델은 합리적으로 다른 균형을 필요로 할 수 있다. 이 파일에는 그 이후로 몇 가지 규칙이 더 쌓였다. 이 파일을 템플릿이 아니라 샘플로 취급하고, 실제로 사용하는 모델과 워크플로에 맞게 수정하고 최적화하라. 중요한 것은 특정 파일이 아니라 그 뒤에 있는 습관, 즉 실패를 알아차리고, 그것이 실제로 무엇을 대가로 치렀는지 묻고, 그것을 잡아낼 규칙을 쓰는 것이다.
수년간 우리는 CPU, 메모리, 처리량을 중심으로 소프트웨어 시스템을 최적화해 왔다. LLM 도구의 첫 물결은 토큰을 지켜보도록 가르쳤다. 이번 세션은 장기 실행 에이전트 워크플로에서 지켜볼 가치가 있는 세 번째 것이 있다는 의심을 하게 만들었다. 바로 오케스트레이터 자신의 작업 기억의 질이다. 한 번 오염되면 세션이 끝날 때까지 계속 임대료를 청구하는 그 유일한 자원 말이다. 아직 확정된 법칙이라고는 생각하지 않는다. 지금까지는 유효했던 패턴일 뿐이다.
4계층 심층 요약
1. 핵심 주장
멀티 에이전트(서브에이전트) 시스템의 진짜 가치는 병렬 처리로 시간을 절약하는 데 있지 않다. 진짜 가치는 오케스트레이터(메인 스레드)의 컨텍스트, 즉 "작업 기억"을 오염시키는 노이즈와 불필요한 추론 과정을 밖으로 밀어내는 데 있다. 서브에이전트는 오케스트레이터의 한정된 주의(attention)를 보호하는 도구로 설계·운영되어야 하며, 이를 위해서는 언제 어떻게 위임할지에 대한 명시적인 규칙이 필요하다.
2. 근거
- 토큰 소비는 일회성 비용이지만, 컨텍스트 오염은 그 이후의 모든 턴에 반복적으로 세금을 매기는 지속적 비용이다.
- 컨텍스트 윈도우가 아무리 커져도, 그 안에 쌓인 노이즈가 모델의 주의를 분산시키는 문제 자체는 해결되지 않는다. 문제는 "공간 부족"이 아니라 "주의를 다투는 정보의 질"이다.
- 오케스트레이터만이 세션 전체에 걸쳐 설계 결정과 트레이드오프에 대한 이해를 축적하는 유일한 주체이며, 서브에이전트는 애초에 소모품으로 설계되어야 한다.
- "인지적 지역성(cognitive locality)" 개념: 같은 정신 모델을 필요로 하는 작업을 서로 다른 에이전트로 쪼개면, 각 에이전트가 동일한 이해를 처음부터 중복해서 재구축해야 한다.
3. 사례
- 필자는 .NET 리팩토링 작업에서 4개의 서브에이전트를 동시에 실행했는데, 세션이 코드보다 이해하기 어려워지는 것을 느끼고 오케스트레이터에게 스스로의 위임 결정을 비판하게 했다.
- 가장 큰 비용은 예상(서브에이전트 4개의 중복 작업)과 달리, 오케스트레이터가 "에이전트 상태 확인"이라는 가벼운 요청에 백그라운드 에이전트의 전체 원본 트랜스크립트(수만 토큰)를 통째로 가져와 메인 컨텍스트에 남긴 것이었다.
- 두 개의 서브에이전트가 같은 응답 파이프라인 영역을 다루면서 각자 같은 아키텍처와 관례를 독립적으로 재학습했고(오리엔테이션 비용 중복), 한 에이전트는 다른 에이전트들이 동시에 쓰기 작업 중인 저장소에서 git stash/pop 같은 저장소 전체 단위 작업을 실행해 구조적 위험을 만들었다.
- 이 경험을 CLAUDE.md의 상시 규칙(배치당 2~4개 에이전트, 상태 폴링 금지, 동시 실행 중 저장소 전체 git 작업 금지, 파일 소유권 중복 시 통합 신호로 처리)으로 압축했고, 이후 스킬이 서브에이전트에 자동 상속되지 않는다는 두 번째 공백을 발견했을 때는 과도한 승인 게이트 대신 "누락된 사실만 명시하면 되는가"라는 최소주의 휴리스틱을 적용했다.
4. 시사점
멀티 에이전트 오케스트레이션을 설계할 때는 에이전트 수를 늘리는 것 자체보다, 무엇을 메인 컨텍스트로 되돌릴지를 엄격히 통제하는 것이 훨씬 중요하다. 상태 확인, 로그 요약, 산출물 병합 같은 오케스트레이터-서브에이전트 인터페이스를 설계할 때 "가벼운 요약"과 "원본 전체 반환"을 구분하지 않으면, 병렬화로 얻은 이득이 컨텍스트 오염 비용에 쉽게 잠식될 수 있다. 또한 표준 운영 규칙(standing rules)은 많을수록 좋은 것이 아니라, 실제로 관찰된 실패를 정확히 겨냥한 최소한의 규칙일 때 가장 효과적이며, 모든 실수를 거버넌스 절차로 성문화하려는 유혹은 경계해야 한다.
핵심 요약 (20줄)
- 필자는 .NET 리팩토링 작업 중 4개의 서브에이전트를 동시에 운용하다가 세션이 코드보다 이해하기 어려워지는 순간을 겪었다.
- 처음에는 "서브에이전트가 너무 많았던 것 아닌가"라는 단순한 프레이밍으로 문제를 진단하려 했다.
- 필자는 코딩 작업을 멈추고 오케스트레이터에게 자신의 위임 결정을 사실에 기반해 스스로 비판하도록 요청했다.
- 예상과 달리 가장 큰 비용은 4개의 서브에이전트를 실행한 것 자체가 아니라 오케스트레이터의 상태 확인 행위에서 비롯된 것으로 나타났다.
- 오케스트레이터가 "에이전트 상태를 확인해보라"고 제안했을 때, 도구는 요약 대신 백그라운드 에이전트의 원본 트랜스크립트 전체를 가져왔다.
- 이 트랜스크립트에는 수만 토큰에 달하는 JSONL 로그, 중간 추론, 도구 출력이 통째로 포함되어 있었고 이런 일이 두 번 반복되었다.
- 필자는 이 폴링 비용이 최대 비용이라는 판단이 오케스트레이터 자신의 자기 채점이라는 점에서 검증된 사실이 아니라 가설이라고 신중하게 밝힌다.
- 세션을 하나의 비용 덩어리로 보지 않고 뜯어보자, 두 서브에이전트가 같은 응답 파이프라인 영역에서 동일한 아키텍처 이해를 독립적으로 중복 구축한 사실이 드러났다.
- 한 서브에이전트는 다른 에이전트들이 같은 저장소에 동시에 쓰기 작업을 하는 동안 git stash와 git stash pop 같은 저장소 전체 단위 작업을 실행해 구조적 위험을 만들었다.
- 필자는 토큰 비용과 컨텍스트 오염이 서로 다른 종류의 비용이라는 점을 깨달았는데, 토큰은 한 번 소비되지만 오염된 컨텍스트는 이후의 모든 턴에 계속 영향을 미친다.
- 컨텍스트에 쌓인 정보가 많아질수록 여유 공간이 충분해도 모델이 지금 중요한 것을 골라내기 어려워지며, 컨텍스트 윈도우 확장은 이 문제를 해결하지 못한다.
- 오케스트레이터는 세션 전체에 걸쳐 설계 결정과 제약을 기억하는 유일한 주체이며, 서브에이전트는 애초에 소모품으로 설계되어야 한다.
- 필자는 같은 정신 모델을 필요로 하는 작업을 나누면 여러 에이전트가 동일한 이해를 처음부터 재구축하게 된다는 개념을 "인지적 지역성"이라 명명했다.
- 필자의 새로운 결론은 서브에이전트의 진짜 가치가 시간 절약이 아니라 오케스트레이터가 짊어질 필요 없는 추론을 오프로드해 주의를 지켜주는 데 있다는 것이다.
- 이 교훈은 CLAUDE.md라는 상시 지침 파일에 최소한의 규칙 네 가지로 압축되어 기록되었다.
- 그 규칙은 한 배치당 2~4개 에이전트를 선호하고, 답을 이미 아는 경우 상태를 폴링하지 않으며, 동시 실행 중 저장소 전체 git 작업을 금지하고, 파일 소유권 중복을 에이전트 증설이 아닌 통합 신호로 취급하는 것이다.
- 이후 세션에서는 서브에이전트가 부모 세션의 활성 스킬을 자동으로 상속받지 않는다는 별개의 공백이 드러났다.
- 필자는 처음에 모든 에이전트 생성 전에 승인을 요구하는 확인 게이트를 만들려 했지만, 이는 증거 없는 문제에 대한 과잉 대응이라 판단해 채택하지 않았다.
- 대신 필자는 오케스트레이터가 관련 스킬을 명시하고 파일을 로드하도록 지시하는 좁은 수정안을 택했고, "누락된 사실 하나만 알려주면 유능한 오케스트레이터가 올바르게 판단할 것인가"라는 휴리스틱을 얻었다.
- 필자는 CPU와 메모리, 토큰에 이어 장기 실행 에이전트 워크플로에서 지켜야 할 세 번째 자원이 바로 오케스트레이터 자신의 작업 기억의 질이라고 결론짓는다.