# 코드 에이전트 오케스트라 - 멀티 에이전트 코딩을 제대로 작동시키는 법

> Clean Markdown view of GeekNews topic #28303. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28303](https://news.hada.io/topic?id=28303)
- GeekNews Markdown: [https://news.hada.io/topic/28303.md](https://news.hada.io/topic/28303.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-08T10:05:02+09:00
- Updated: 2026-04-08T10:05:02+09:00
- Original source: [addyosmani.com](https://addyosmani.com/blog/code-agent-orchestra/)
- Points: 39
- Comments: 2

## Summary

역시 **Addy Osmani**의 글입니다. 단일 에이전트와 동기적으로 작업하던 **컨덕터 모델**에서, 여러 에이전트가 각자의 컨텍스트 윈도우를 갖고 비동기로 움직이는 **오케스트레이터 모델**로의 전환을 다루고 있습니다. 서브에이전트, 에이전트 팀, 계층적 위임이라는 세 가지 패턴을 정리했고, 병목이 코드 생성이 아니라 **검증(Verification)으로 이동했다**는 지적이 핵심입니다. 위에서 다룬 agent-skills와 함께 읽으면 그의 전체 그림이 보입니다.

## Topic Body

- 단일 AI 어시스턴트와 동기적 루프로 협업하던 방식에서, 여러 에이전트가 각자의 **컨텍스트 윈도우와 파일 범위**를 가지고 비동기적으로 동작하는 오케스트레이터 모델로의 전환이 2026년 현재 진행 중  
- 서브에이전트(Subagents), **에이전트 팀(Agent Teams)**, 계층적 위임 등 3가지 핵심 패턴이 멀티 에이전트 코딩의 기본 구조를 이루며, 각각 병렬성·전문화·격리·복합 학습이라는 효과를 제공  
- **공유 태스크 리스트와 피어 투 피어 메시징**이 에이전트 팀의 핵심 조율 메커니즘으로, 의존성 자동 해제와 병목 방지를 가능하게 함  
- 2026년 기준 도구 생태계는 인프로세스 서브에이전트(Tier 1), 로컬 오케스트레이터(Tier 2), 클라우드 비동기 에이전트(Tier 3)의 세 계층으로 구분되며, 대부분의 개발자는 세 계층 모두를 용도에 맞게 혼합 사용  
- 병목은 코드 생성이 아닌 **검증(Verification)** 으로 이동했으며, 플랜 승인·훅(Hooks)·AGENTS.md를 통한 품질 게이트와 인간 리뷰가 멀티 에이전트 체계의 신뢰성을 결정하는 핵심 요소  
  
---  
  
### 현재의 전환: 지휘자에서 오케스트레이터로  
  
- 6개월 전까지 대부분의 개발자는 단일 AI 어시스턴트와 동기적으로 작업했으며, 단일 **컨텍스트 윈도우**가 작업의 상한선이었음  
- 현재 가장 생산적인 개발자들은 각자의 컨텍스트 윈도우와 파일 범위, 책임 영역을 가진 여러 에이전트를 비동기적으로 조율하는 방식으로 전환됨  
- **컨덕터(Conductor) 모델**: 단일 에이전트를 실시간 동기 방식으로 안내; Claude Code CLI, Cursor 에디터 내 에이전트 모드가 대표 도구  
- **오케스트레이터(Orchestrator) 모델**: 각자의 컨텍스트 윈도우를 가진 여러 에이전트를 비동기 조율; Agent Teams, Conductor, Codex, Copilot Coding Agent가 대표 도구  
- 오케스트레이터로서는 명확한 스펙 작성, 작업 분해, 결과물 검증이라는 새로운 역량이 필요함  
  
### AI 지원 코딩의 8단계  
- **[오케스트레이션]**  
  - **L8 — 나만의 오케스트레이터 구축**: 에이전트 생성·라우팅·관리를 직접 코드로 작성하는 코디네이션 레이어를 스스로 구현  
  - **L7 — 에이전트 10개 이상, 수동 관리**: "이런, 엉망이 됐다." 잘못된 컨텍스트가 잘못된 에이전트에게 전달되며 "Claude Code가 Claude Code를 실행하면 어떨까?"라는 질문이 시작됨  
  - **L6 — 에이전트 멀티플렉싱**: 기다리기 지루해서 에이전트를 하나씩 더 실행, 여러 스트림 사이를 오가다 멈출 수 없는 상태  
- **[에이전트 우선]**  
  - **L5 — 에이전트 우선, IDE는 나중**: 에이전트 대화가 주작업 공간, IDE는 코드 확인용  
  - **L4 — diff가 사라지고 대화가 주도**: 매번 diff를 검토하지 않고, 에이전트 행동을 관찰하며 방향 제시에 집중  
- **[IDE 시대]**  
  - **L3 — YOLO 모드**: 에이전트가 IDE에서 자유롭게 실행, 신뢰 상승  
  - **L2 — IDE 내 에이전트, 권한 수동 승인**: 모든 파일 변경을 직접 허가, 완전 수동 제어  
  - **L1 — AI 없음**: 전통적인 개발 워크플로우  
- Steve Yegge가 정리한 AI 도구 활용 8단계 프레임워크 기준으로, 대부분의 개발자는 **레벨 3~4에 머물러 있음**  
- 오케스트레이션 계층은 레벨 6부터 시작하며, 레벨 5까지 올라온 역량과는 **근본적으로 다른 스킬셋**을 요구  
- 이 내용은 레벨 5~8을 다룸  
  
### 단일 에이전트의 한계  
- **컨텍스트 과부하**: 단일 에이전트는 보유 가능한 정보량이 제한되며, 대규모 코드베이스는 단일 컨텍스트 윈도우를 압도함  
- **전문화 부재**: 데이터 레이어, API, UI, 테스트를 모두 처리하는 에이전트는 제너럴리스트에 불과하며, 데이터 레이어만 전담하는 에이전트가 훨씬 우수한 DB 코드 작성  
- **조율 부재**: 헬퍼 에이전트를 추가해도 서로 소통·태스크 공유·의존성 해결이 불가능하며, 조율 프리미티브 없이 에이전트를 늘릴수록 관리 난이도가 높아짐  
- 서브에이전트는 처음 두 문제를, **에이전트 팀**은 세 가지 문제 모두를 해결  
  
### 멀티 에이전트의 이유  
  
- **병렬성 (3배 처리량)**: 프론트엔드·백엔드·테스트 에이전트가 동시에 작업  
- **전문화 (집중된 컨텍스트)**: 각 에이전트는 자신이 담당하는 파일만 인식; `db.js`만 아는 에이전트가 전체 코드베이스를 다루는 에이전트보다 더 나은 DB 코드 작성  
- **격리 (안전한 실행)**: Git 워크트리가 각 에이전트에게 독립적인 작업 디렉터리 제공, 병합 충돌 없음  
- **복합 학습**: `AGENTS.md` 파일이 세션 간 패턴과 주의사항을 축적하여 매 세션이 다음 세션을 개선  
- 집중된 에이전트 3개가 3배 오래 작업하는 제너럴리스트 에이전트 1개보다 일관되게 높은 성과  
  
### 패턴 1: 서브에이전트 — 집중된 위임  
  
- Task 도구를 사용해 부모 오케스트레이터에서 **전문화된 자식 에이전트를 생성**; 가장 단순한 멀티 에이전트 패턴으로 먼저 시도해볼 것  
- 구체적 예시: Claude Code에 "Express와 SQLite로 북마크 매니저 Link Shelf를 구축하라"는 프롬프트를 주면, 부모 오케스트레이터가 세 서브에이전트 브리프로 분해  
  - **데이터 레이어 서브에이전트**: `db.js` 구축 후 `DATA.md` 보고서 작성  
  - **비즈니스 로직 서브에이전트**: `validation.js` 구축 후 `LOGIC.md` 보고서 작성  
  - **API 라우트 서브에이전트**: `DATA.md`와 `LOGIC.md`를 읽은 후 `server.js` 구축  
- 처음 두 서브에이전트는 독립적으로 병렬 실행, 세 번째는 두 보고서 완료 후 시작; 부모가 의존성 그래프를 수동 관리  
- 서브에이전트의 한계: 부모가 의존성 그래프를 수동 관리해야 하며, 에이전트 간 피어 메시징·공유 태스크 리스트 없음; 파일 범위 관리가 느슨하면 충돌 발생 가능  
- 총 약 22만 토큰으로 비용 중립적 수준  
- ## 계층적 서브에이전트 (팀의 팀)  
  - 오케스트레이터가 6개 서브에이전트를 직접 생성하는 대신, **피처 리드 2명을 생성**하고 각 피처 리드가 자체적으로 전문가 2~3명을 생성하는 구조  
  - 부모 오케스트레이터는 두 에이전트만 관리하여 컨텍스트를 깔끔하게 유지; 피처 리드 A는 "검색 기능 구축"이라는 브리프를 받아 자체적으로 분해  
  - 실제 엔지니어링 조직의 운영 방식과 동일한 원리: VP가 개별 엔지니어에게 직접 태스크를 배정하지 않고 테크 리드를 통해 전달  
  
### 패턴 2: 에이전트 팀 — 진정한 병렬 실행  
- Claude Code의 실험적 기능으로, `export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` 명령으로 활성화  
- **아키텍처 3계층**:  
  - 팀 리드(Team Lead): 작업 분해, 태스크 리스트 생성, 결과 종합  
  - **공유 태스크 리스트**: 상태(pending, in_progress, completed, blocked)·의존성 추적·파일 잠금  
  - **팀원(Teammates)**: 각자 독립적인 Claude Code 인스턴스, 자체 컨텍스트 윈도우 보유, tmux 분할 패널에서 실행  
- 팀원은 공유 리스트에서 태스크를 자율 선택하며, **피어 투 피어 메시징**으로 직접 소통(리드를 거치지 않음)  
- 한 팀원이 태스크 완료 후 완료 표시를 하면, 이에 의존하던 블로킹된 태스크가 자동으로 잠금 해제  
- `Ctrl+T`로 태스크 리스트의 시각적 오버레이 토글 가능  
- ## 에이전트 팀 핵심 메커니즘  
  - **공유 태스크 리스트**: 백엔드 팀원이 검색 API를 완료로 표시하면, 블로킹된 테스트 작성 태스크가 자동으로 pending 상태로 전환; 파일 잠금으로 동시 편집 방지  
  - **피어 메시징**: 백엔드 에이전트가 프론트엔드 에이전트에게 API 계약을 직접 전달 — "GET /search?q= returns [{id,title,url}]"; 리드가 조율 병목이 되는 것을 방지  
  - 팀원이 유휴 상태가 되면 리드에게 자동 알림  
- ## 에이전트 팀 핵심 권장 사항  
  - **3~5명의 팀원**이 최적점; 토큰 비용은 팀 규모에 비례해 선형 증가  
  - **플랜 승인**: 팀원이 구현 전 플랜을 작성하면 리드가 검토·승인 또는 거부; 코드가 존재하기 전에 아키텍처 문제를 발견하는 것이 훨씬 저렴함  
  - 집중된 팀원 3명이 산만한 팀원 5명보다 일관되게 우수한 성과  
- ## 에이전트 팀 신뢰성 팁  
  - **루프 가드레일 + 반성 단계**: 모든 팀원에게 `MAX_ITERATIONS=8` 상한선 설정; 각 재시도 전 "무엇이 실패했나? 어떤 구체적 변경이 수정을 가져올까? 같은 접근 방식을 반복하고 있나?"라는 반성 프롬프트 강제 → 교착 에이전트 발생 대폭 감소  
  - **전담 @reviewer 팀원**: Claude Opus 4.6(읽기 전용)을 reviewer로 지정, lint·테스트·보안 스캔 도구만 사용, 매 TaskCompleted 이벤트에 자동 트리거; 빌더 3~4명당 reviewer 1명 비율; 리드는 항상 검토 완료된 코드만 수신  
  
### 패턴 3: 규모에서의 오케스트레이션  
  
- 5개, 10개, 20개 이상의 에이전트를 여러 레포와 피처에 걸쳐 관리할 때는 **전용 오케스트레이션 도구**가 필요  
- **Tier 1 — 인프로세스 서브에이전트·팀**: Claude Code 서브에이전트·에이전트 팀; 단일 터미널 세션, 추가 도구 불필요; 여기서 시작  
- **Tier 2 — 로컬 오케스트레이터**: 독립된 워크트리에서 여러 에이전트 실행, 대시보드·diff 리뷰·병합 제어 유지; 알려진 코드베이스에서 3~10개 에이전트에 최적; Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, Cursor Background Agents  
- **Tier 3 — 클라우드 비동기 에이전트**: 태스크 배정 후 노트북을 닫고 PR을 기다리는 방식; 클라우드 VM에서 실행; Claude Code Web, GitHub Copilot Coding Agent, Jules by Google, Codex Web by OpenAI  
- 2026년 대부분의 개발자는 세 계층 모두 사용: Tier 1(인터랙티브 작업), Tier 2(병렬 스프린트), Tier 3(야간 백로그 처리)  
  
### 도구 스포트라이트  
- ## Conductor by Melty Labs  
  - Mac에서 멀티 에이전트 오케스트레이션을 시작하는 가장 빠른 방법; 각각 독립된 git 워크트리에서 **여러 Claude Code·Codex 에이전트를 병렬 실행**  
  - 시각적 대시보드와 diff 우선 리뷰 UI 제공; API 비용만 부담(무료); macOS 전용(Apple Silicon·Intel)  
  - 동일 레포에서 3~8개 피처를 병렬 작업하며 시각적 감독이 필요한 경우에 최적  
- ## Claude Code Web  
  - `claude.ai/code`에서 접근; 완전 브라우저 기반, 터미널 불필요; GitHub 레포 연결 후 태스크 설명 입력 → Anthropic 관리 클라우드 VM에서 실행  
  - 중간 스티어링, 자동 PR 생성, iOS 앱 접근 지원  
  - **팀(터미널)은 에이전트와 함께 작업**하는 방식, **웹(브라우저)은 위임하고 자리를 비우는** 방식  
- ## GitHub Copilot Coding Agent  
  - IDE의 Copilot 에이전트 모드(동기·인터랙티브)와 구별; GitHub의 **Copilot Coding Agent는 완전 비동기**  
  - 모든 GitHub 이슈를 `@copilot`에 배정하거나 Agents 패널에서 시작 → GitHub Actions 환경에서 드래프트 PR 생성  
  - 태그 전에 **자체 리뷰 루프** 실행; Claude Code·Codex 등 서드파티 에이전트도 동일 패널에서 접근 가능; Slack, Jira, Linear, Azure Boards에서 트리거 가능  
- ## Jules by Google  
  - Google의 비동기 클라우드 코딩 에이전트, **Gemini 기반**; GitHub 레포 연결 → 태스크 설명 → Jules가 플랜 생성 → 승인 후 클라우드 VM에서 실행 → 전체 추론 과정과 터미널 로그가 포함된 PR 반환  
  - 오디오 체인지로그, 중간 태스크 중단, GitHub 이슈를 직접 파이핑하는 Jules Tools CLI 제공  
  - 레포의 `AGENTS.md`를 추가 설정 없이 자동으로 읽음  
- ## OpenAI Codex Web  
  - 각 태스크가 GitHub 레포가 사전 로드된 **독립된 샌드박스 컨테이너**에서 실행  
  - Web, CLI(오픈소스), macOS 앱, IDE 익스텐션, GitHub 통합을 ChatGPT 계정으로 연결하는 서피스 에코시스템 보유  
  - **검증 가능한 증거(Verifiable Evidence)** 기능: 모든 태스크에 대해 터미널 로그와 테스트 출력의 인용을 반환하여 실행 내역 감사 가능  
- ## Cursor Cloud Agents + Glass  
  - 웹, 데스크톱 앱, Slack, Linear, GitHub, API, PWA(cursor.com/agents 설치)에서 에이전트 시작 가능  
  - **Glass**: Cursor의 새 인터페이스로, 에이전트 관리를 기본 화면으로, 기존 에디터는 필요 시 접근하는 보조 도구로 전환  
  - 전체 생태계 전반에서 **컨트롤 플레인이 주요 경험**이 되고 에디터가 그 아래 하나의 악기가 되는 패턴을 반영  
- ## Vibe Kanban  
  - "둠스크롤링 갭"(에이전트 작업 중 2~5분의 공백) 해결; 태스크 카드 생성 후 "In Progress"로 드래그하면 각자의 워크트리·브랜치 생성  
  - 보드 내에서 diff 리뷰 및 실행 중 에이전트에 피드백 전송 가능; Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI 등 지원; 크로스 플랫폼(Mac, Windows, Linux), 무료, BYOK  
  
### 규모 확장을 위한 팁  
- ## 멀티 모델 라우팅  
  - 모든 태스크에 가장 비싼 모델이 필요하지 않음; `MODEL_ROUTING.md` 파일을 생성하여 역할별 라우팅:  
    - 플랜·아키텍처 → 저렴한 Gemini/Claude/OpenAI 모델  
    - 구현 → Sonnet, Opus 또는 Codex  
    - 리뷰 → 전용 보안 모델  
- ## 워크트리 라이프사이클 스크립트  
  - 세 가지 셸 앨리어스로 반복 작업 자동화:  
    - `agent-spin <feature>`: 워크트리 + 브랜치 생성 + 에이전트 시작  
    - `agent-merge <feature>`: 리베이스 + 리뷰 + PR 생성  
    - `agent-clean`: 완료된 워크트리 제거  
  - 약 12줄의 bash; Conductor가 이를 시각적으로 처리  
- ## 인간이 작성한 AGENTS.md만 허용  
  - ETH Zurich Gloaguen et al.의 연구에서 **LLM이 생성한 AGENTS.md 파일은 이점이 없으며** 평균 ~3% 성공률 저하, 추론 비용 20% 이상 증가를 유발함을 확인  
  - **개발자가 작성한 컨텍스트 파일**은 ~4% 성능 향상 제공  
  - 에이전트가 `AGENTS.md`에 직접 쓰는 것을 절대 허용하지 말 것; 리드가 모든 줄을 승인해야 함  
  - 명확한 섹션으로 간결하게 유지: STYLE, GOTCHAS, ARCH_DECISIONS, TEST_STRATEGY  
  
### 품질 게이트: 신뢰하되 검증하라  
- ## 세 가지 품질 게이트  
  - **플랜 승인**: 팀원이 코딩 시작 전 플랜 작성 → 리드가 검토·승인 또는 거부 → 구현; 나쁜 플랜을 수정하는 비용이 나쁜 코드를 수정하는 비용보다 훨씬 저렴  
  - **훅(Hooks)**: 라이프사이클 이벤트의 자동화된 체크; `TeammateIdle` 훅은 에이전트가 작업을 중단하기 전 모든 테스트 통과 여부 확인; `TaskCompleted` 훅은 완료 표시 전 lint·테스트 실행; 훅이 실패하면 에이전트는 통과할 때까지 계속 작업  
  - **AGENTS.md를 통한 복합 학습**: 발견된 패턴·주의사항·스타일 선호를 포착; 모든 에이전트가 세션 시작 시 읽고 매 세션마다 추가됨  
- ## 병목은 검증으로 이동  
  - 에이전트가 인상적인 출력을 놀라운 속도로 생성할 수 있음; 그 출력이 정확한지 확신하는 것이 어려운 부분  
  - 변경 전 통과하는 테스트가 변경으로 인한 회귀를 잡아낼 것을 보장하지 않음  
  - 에이전트는 기술적으로 유효하지만 중요한 케이스를 놓치는 테스트를 작성할 수 있음  
  - **컨텍스트 윈도우 한계**로 인해 대규모 코드베이스에서 작업하는 에이전트는 현재 뷰 밖의 중요한 제약을 놓칠 수 있음  
  - 단일 개발자에게는 성가신 엣지 케이스인 불안정한 환경이, 40개 에이전트가 동시에 같은 불안정한 테스트를 마주칠 때는 **시스템적 블로커**가 됨  
  - 검증 인프라가 생성 역량을 따라잡을 때까지 인간 리뷰는 선택적 부가 비용이 아닌 **안전 시스템**  
  
### Ralph Loop와 자기 개선 에이전트  
- ## Ralph Loop 패턴  
  - Geoffrey Huntley와 Ryan Carson이 대중화; "잠자는 동안 배송"의 배후 패턴; Carson의 독립 도구 `ralph`(snarktank/ralph)가 핵심 루프를 구현하며, Antfarm 프로젝트는 OpenClaw 위에 멀티 에이전트 오케스트레이션을 추가  
  - **5단계 사이클**: Pick(tasks.json에서 다음 태스크 선택) → Implement(변경 수행) → Validate(테스트·타입·lint 실행) → Commit(체크 통과 시 커밋 및 태스크 상태 업데이트) → **Reset(에이전트 컨텍스트 초기화 후 다음 태스크로)**  
  - 핵심 인사이트: 각 반복마다 리셋함으로써 혼동 누적 방지; 작고 범위가 명확한 태스크는 하나의 거대한 프롬프트보다 환각이 적고 더 깔끔한 코드 생성  
  - **안전 장치**: 자동 재시도를 위해 오류를 피드백으로 전달하되, 3회 이상 교착 상태 시 종료 및 재배정; 항상 피처 브랜치에서 작업; 반복·시간·토큰 상한선 설정; 에이전트가 PR 생성 → 병합 전 인간 리뷰  
  - 컨텍스트 리셋 간 4가지 메모리 채널 유지: git 커밋 히스토리, 진행 로그, 태스크 상태 파일(tasks.json), 장기 의미 기억으로서의 AGENTS.md  
- ## 에이전트를 시간이 지날수록 더 스마트하게  
  - **REFLECTION.md를 통한 자기 반성**: 매 태스크 후 "무엇이 놀라웠나, AGENTS.md에 추가할 패턴 하나, 프롬프트 개선 하나"를 작성하도록 강제; 리드가 검토하고 승인된 학습 내용을 병합  
  - **토큰 예산과 종료 기준**: 에이전트별 상한선 설정(예: 프론트엔드 18만 토큰, 백엔드 28만 토큰); 예산의 85%에서 자동 일시정지 및 리드 알림; 동일 오류에서 3회 이상 교착 시 종료하고 새 에이전트에 재배정  
  - **Beads / 영구 메모리**: Gastown의 "beads" 패턴 — 전체 출처를 가진 모든 결정과 결과의 불변·git 기반 기록; 에이전트가 태스크 그래프와 SQL 주소 가능한 데이터 플레인을 통해 과거 beads 조회; 단순 벡터 기반 RAG가 아닌 구조화된 쿼리 가능한 제도적 기억  
  
### 이 모든 것을 작동시키는 규율  
- ## 인간의 병목은 버그가 아니라 피처였음  
  - 인간 속도로 코드를 작성할 때는 일찍 고통을 느낌; 테스트 실패, 코드 리뷰 지적, 중복 발견 — 고통이 즉각적이어서 진행하면서 수정  
  - 오케스트레이션된 에이전트 군단에서는 자연스러운 병목이 없음; 작은 실수(코드 냄새, 중복, 불필요한 추상화)가 따라잡을 수 없는 속도로 복합 증폭됨  
  - 루프에서 빠져나온 상태이므로 아키텍처가 새 기능을 허용하지 않게 될 때까지 고통을 느끼지 못함  
  - **모든 품질 게이트(플랜 승인, 훅, 토큰 예산, 인간 리뷰)** 가 존재하는 이유: 없으면 에이전트 코딩으로 스스로를 막다른 골목에 몰아넣게 됨  
- ## 태스크를 위임하되 판단은 보유할 것  
  - **에이전트에게 맡겨야 하는 것**: 명확한 합격/불합격 기준이 있는 범위가 명확한 태스크, 보일러플레이트, 마이그레이션, 테스트 스캐폴딩, 직접 시도할 시간이 없는 접근법 탐색  
  - **직접 보유해야 하는 것**: 아키텍처와 API 설계(에이전트는 훈련 데이터에서 많은 나쁜 아키텍처를 학습해 엔터프라이즈 패턴을 스타트업에 그대로 적용할 수 있음), **만들지 않을 것을 결정하는 일**(No라고 말하는 것은 에이전트에게 없는 기능), 전체 시스템 컨텍스트로 에이전트 출력 리뷰  
  - **자신의 시스템에 대한 이해를 잃으면** 수정·확장·오작동 감지 능력을 잃음  
- ## 스펙이 레버리지  
  - 50개 에이전트를 병렬로 오케스트레이션할 때, 모호한 사고는 단순히 속도를 늦추는 것이 아니라 **수십 개의 병렬 실행 전체에 증폭**됨  
  - 평범한 출력과 탁월한 출력의 차이는 거의 전적으로 **스펙의 품질**에 달려 있음  
  - 모호한 스펙은 전체 플릿에 오류를 증폭; 명확한 아키텍처·통합 경계·엣지 케이스·불변 조건이 있는 정밀한 스펙은 전체에 걸쳐 정밀한 구현으로 증폭  
  - 코드를 타이핑하는 기계적 작업은 자동화되는 중; 시스템을 이해하는 인지적 작업은 자율적 작업자 전체 플릿에 걸쳐 **증폭**됨  
  
### 팩토리 모델  
- 더 이상 단순히 코드를 작성하는 것이 아닌, **소프트웨어를 만드는 팩토리를 구축하는 단계**  
- **6단계 생산 라인**: Plan(수용 기준이 있는 스펙 작성) → Spawn(팀 생성 및 에이전트 배정) → Monitor(5~10분마다 진행 상황 확인·블로커 해결, 호버링 금지) → Verify(테스트 실행·코드 리뷰; 검증이 병목) → Integrate(브랜치 병합·충돌 해결) → Retro(새 패턴으로 AGENTS.md 업데이트; 복합 학습)  
- **실용적 팁**:  
  - WIP 한도 설정: 의미 있게 리뷰할 수 있는 것보다 많은 에이전트 실행 금지; 3~5개가 최적점  
  - 종료 기준 정의: 동일 오류에서 3회 이상 교착 시 중단 및 재배정  
  - 비동기 체크인: 5~10분마다 진행 상황 확인; 에이전트가 자율적으로 작업하게 할 것  
  - 파일 하나에 오너 하나: 두 에이전트가 동일 파일을 편집하지 않도록; 충돌은 속도를 죽임  
  
### 오늘 시작할 5가지 패턴  
  
1. **서브에이전트로 분해**: Task 도구로 특정 브리프와 파일 소유권이 있는 집중된 자식 에이전트 생성; 설정 불필요; 오늘 시작  
2. **에이전트 팀으로 병렬성**: `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` 활성화; 리드 + 팀원 3명 생성; 공유 태스크 리스트로 조율  
3. **Git 워크트리로 격리**: 각 에이전트에 자체 워크트리 제공; 병합 충돌 없음; Conductor가 자동 처리  
4. **신뢰를 위한 품질 게이트**: 위험한 변경에 플랜 승인 요구; 태스크 완료 시 테스트를 실행하는 훅 추가; 검증 없이 에이전트 출력 신뢰 금지  
5. **AGENTS.md로 복합 학습**: 패턴·주의사항·스타일 선호 문서화; 매 세션이 읽고 업데이트; 지식이 복합 증폭됨

## Comments



### Comment 54940

- Author: kurthong
- Created: 2026-04-08T20:56:38+09:00
- Points: 3

엔지니어들의 특성인지 왜 그럴듯한 얘기를 깊이 없이 구구절절 늘어 놓는지 모르겠습니다. 저도 관심있는 주제여서 자세히 읽어보았는데 알맹이는 없네요

### Comment 54909

- Author: stroke33
- Created: 2026-04-08T11:21:17+09:00
- Points: 1

하악 클코를 사용하는 궁극적인 이유 - 멀티에이전트로 나만의 오케스트레이션  
  
지금 5개 에이전트 운영중인데 토큰이 겁내 빨리 사라져서 눈물남.