코드 에이전트 오케스트라 – 멀티 에이전트 코딩은 무엇으로 구성되는가

https://addyosmani.com/blog/code-agent-orchestra

오늘 O’Reilly AI CodeCon에서 코드 에이전트를 오케스트레이션하는 방법에 대해 발표했습니다. 이 발표에서는 실제 소프트웨어 워크플로에서 AI 코드 에이전트를 조율하는 다양한 패턴을 다뤘습니다. 첫 서브에이전트를 띄우는 것부터, 신뢰성을 보장하는 품질 게이트를 둔 병렬 에이전트 팀 운영까지 모두 포함합니다. 이 글은 이러한 패턴을 실제로 적용해 보고 싶은 분들을 위한 발표 내용 정리입니다.

인터랙티브 슬라이드를 보거나, 자료 전체를 받고 싶다면 아래를 참고하세요:

우리가 있는 지점

예전에는 AI 하나와만 페어 프로그래밍을 했다면, 이제는 에이전트 팀을 관리하게 되었습니다.

6개월 전만 해도 대부분의 개발자는 하나의 AI 어시스턴트와 촘촘한 동기식 루프로 일했습니다. 프롬프트를 입력하고, 기다렸다가, 결과를 검토하고, 피드백을 주고, 반복하는 식이었죠. 작업의 상한선은 그 단일 컨텍스트 윈도에 들어갈 수 있는 것까지였습니다. 대화 스레드가 곧 작업 공간이었습니다.

이제 이 모델은 대체되었습니다. 오늘날 가장 생산적인 개발자는 각자 고유한 컨텍스트 윈도와 파일 범위, 책임 영역을 가진 여러 에이전트를 비동기적으로 조율하고, 개발자는 그 위에서 이를 오케스트레이션합니다. 더 이상 대화 스레드가 아니라, 코드베이스 전체가 당신의 캔버스가 됩니다. 이는 한 명의 연주자를 실시간으로 이끄는 ‘지휘자(conductor)’에서, 다양한 파트를 비동기적으로 조율하는 ‘오케스트레이터(orchestrator)’로 역할이 바뀌는 것과 같습니다. 이런 변화의 초기 징후에 대해서는 The Future of Agentic Coding에서 이야기한 바 있습니다.

이번 발표는 이 전환을 실제로 어떻게 할 것인지에 초점을 맞춥니다. 어떤 패턴과 도구를 쓰고, 어떤 품질 게이트와 어떤 규율이 필요할지에 대해 다룹니다.

AI 보조 코딩의 8단계

대부분의 개발자는 3~4단계에 머물러 있습니다. 오케스트레이션 계층은 6단계부터 시작하며, 거기까지 올라가는 데에는 5단계까지와는 완전히 다른 종류의 역량이 필요합니다.

Steve Yegge는 개발자가 AI 도구와 함께 성장해 나가는 여정을 8단계로 정리했는데, 지금 위치와 앞으로 나아갈 방향을 이해하는 데 유용한 프레임워크입니다.

이 발표는 5단계부터 8단계까지를 다룹니다. 여러분은 이 사다리에서 어디쯤 와 있나요?

전환: 지휘자에서 오케스트레이터로

지휘자 모델에서는 하나의 에이전트와 동기적으로 일하며, 컨텍스트 윈도가 곧 작업의 상한선입니다. 오케스트레이터 모델에서는 각자 컨텍스트 윈도를 가진 다수의 에이전트가 비동기적으로 일하는 동안, 당신은 그들을 계획하고 점검하는 역할을 맡습니다.

핵심적인 사고 방식의 전환은 페어 프로그래밍과 팀 운영의 차이입니다. 지휘자(conductor) 모델에서는 하나의 AI 에이전트를 실시간으로 안내합니다. 동기적이고 순차적이며, 당신의 컨텍스트 윈도가 곧 작업의 하드 리밋입니다. 이 모델에 맞는 도구로는 Claude Code CLI, Cursor의 인에디터(in-editor) 에이전트 모드 등이 있습니다.

오케스트레이터 모델에서는 하나의 앙상블 전체를 조율합니다. 여러 에이전트가 각자 컨텍스트 윈도를 가지고 비동기적으로 일합니다. 당신은 일을 설계하고, 역할을 나누고, 주기적으로 체크인합니다. 이 모델에 쓰이는 도구로는 Agent Teams, Conductor, Codex, Copilot Coding Agent 등이 있습니다.

실제 팀을 관리할 때와 마찬가지로, 이제는 다른 종류의 스킬이 필요합니다. 명확한 스펙, 작업 분해, 그리고 직접 코드를 쓰기보다는 산출물을 검증하는 역량이 요구됩니다.

단일 에이전트의 한계

모든 개발자는 단일 에이전트로 일할 때 결국 세 가지 벽에 부딪힙니다. 컨텍스트 과부하, 비전문화, 그리고 부재한 조율입니다. 서브에이전트는 앞의 두 가지를 해결하고, 에이전트 팀은 세 가지 모두를 해결합니다.

왜 에이전트 하나로는 모든 것을 처리할 수 없을까요? 세 가지 제약이 있습니다.

컨텍스트 과부하. 하나의 에이전트가 담을 수 있는 정보에는 한계가 있습니다. 코드베이스가 커질수록 단일 컨텍스트 윈도는 금방 포화 상태가 됩니다. 대화가 길어지면 중요한 세부 정보들이 빠져나가기 시작합니다.

비전문화. 하나의 에이전트가 데이터 레이어, API, UI, 테스트까지 모두 맡으면 만능이지만 그 어느 것도 뛰어나지 못한 상태가 됩니다. 오직 데이터 레이어만 담당하는 에이전트는, 코드베이스 전체를 동시에 다루는 범용 에이전트보다 훨씬 더 좋은 데이터베이스 코드를 작성합니다.

부재한 조율. 설령 도우미 에이전트를 여러 개 띄운다고 해도, 그들끼리 소통하거나, 공통 작업 목록을 공유하거나, 의존성을 해결할 수 있는 수단이 없습니다. 조율에 필요한 기본 도구 없이 에이전트를 계속 추가할수록 오히려 일이 더 어려워집니다.

왜 멀티 에이전트인가?

병렬성, 전문화, 격리, 축적 학습은 단순히 더해지는 수준이 아니라 곱해집니다. 집중된 세 에이전트가, 하나의 범용 에이전트에게 같은 시간의 세 배를 주는 것보다 일관되게 더 좋은 성과를 냅니다.

멀티 에이전트로 전환해야 하는 이유는 네 가지가 서로 겹치며 커집니다.

병렬성 (약 3배 처리량) - 프론트엔드, 백엔드, 테스트를 세 에이전트가 동시에 구현합니다.
전문화 (집중된 컨텍스트) - 각 에이전트는 자신이 책임지는 파일만 봅니다. ⁠db.js⁠만 알고 있는 에이전트는, 코드베이스 전체를 만지며 일하는 에이전트보다 훨씬 더 좋은 데이터베이스 코드를 작성합니다.
격리 (안전한 실행) - Git worktree를 사용하면 각 에이전트가 자기만의 작업 디렉터리를 가집니다. 작업 중에 머지 충돌이 나지 않습니다.
축적 학습 - ⁠AGENTS.md⁠ 파일을 통해 세션을 거듭할수록 패턴과 함정이 쌓입니다. 한 번의 세션이 다음 세션을 조금씩 더 나아지게 만듭니다.

패턴 1: 서브에이전트 - 포커스된 위임

서브에이전트는 가장 단순한 멀티 에이전트 패턴이며, 가장 먼저 시도해볼 만한 방식입니다.

서브에이전트 패턴에서는 Task 도구를 사용해 부모 오케스트레이터가 특화된 자식 에이전트를 생성합니다. 부모는 작업을 여러 조각으로 쪼개고, 각 조각마다 서브에이전트를 만들며, 의존성 그래프는 직접 관리합니다.

구체적인 예를 들어보겠습니다. Claude Code에 이런 프롬프트를 준다고 해보죠. “Express와 SQLite를 사용해 Link Shelf라는 북마크 관리 앱을 만들어줘.” 부모 오케스트레이터는 이를 다음과 같은 세 개의 서브에이전트 브리프로 나눕니다.

Data Layer 서브에이전트 - 스키마와 CRUD 연산을 포함하는 ⁠db.js⁠를 만들고, 완료 시 ⁠DATA.md⁠ 보고서를 작성합니다.
Business Logic 서브에이전트 - 입력 규칙을 담은 ⁠validation.js⁠를 만들고, 완료 시 ⁠LOGIC.md⁠ 보고서를 작성합니다.
API Routes 서브에이전트 - ⁠DATA.md⁠와 ⁠LOGIC.md⁠를 읽고, Express 라우트를 정의하는 ⁠server.js⁠를 작성합니다.

앞의 두 서브에이전트는 서로 독립적이므로 병렬로 실행됩니다. 세 번째 에이전트는 둘의 결과에 의존하기 때문에, 두 보고서가 준비될 때까지 기다렸다가 시작합니다. 부모는 이 의존성 그래프를 수동으로 관리합니다.

데모 1: 서브에이전트가 Link Shelf를 구축하는 과정

데모 1: https://addyosmani.com/blog/code-agent-orchestra/#demo-1

이 데모에서는 부모가 프롬프트를 분해하고, Data와 Validation 서브에이전트를 병렬로 띄운 뒤, 두 보고서가 준비되면 API Routes 에이전트를 시작하는 과정을 볼 수 있습니다. 마지막에는 테스트까지 통과합니다.

서브에이전트가 해결하는 것: 에이전트별 컨텍스트 분리, 전문화, 독립 작업에 대한 병렬 실행, 그리고 총 사용 토큰 기준으로 대략 220k 정도로 비용 중립적인 점입니다.

아직 부족한 점: 부모가 의존성 그래프를 직접 관리해야 합니다. 에이전트끼리 서로 메시지를 주고받을 수 없습니다. 공유 작업 목록이 없습니다. 그리고 파일 범위를 엄격히 지키지 않으면 두 에이전트가 같은 파일을 수정해 버릴 수 있습니다.

요약하자면, 서브에이전트는 수동 조율을 전제로 병렬 실행을 가능하게 합니다. 단순한 분해에는 훌륭하지만, 조율 자체가 병목이 되기 시작하면 Agent Teams가 필요해집니다.

프로 팁: 계층형 서브에이전트 - 팀 안의 팀

위임을 한 단계에서 멈추지 마세요. 기능별 리드를 만들고, 그 리드가 자신의 전문가들을 다시 스폰하도록 하세요. 이렇게 하면 누구의 컨텍스트도 과도하게 커지지 않으면서, 분해 깊이를 3배까지 늘릴 수 있습니다.

오케스트레이터가 서브에이전트 여섯 개를 직접 띄우면, 오케스트레이터의 컨텍스트가 쓸데없이 조각납니다. 대신 기능 리드 두 명을 띄워 보세요. 각 리드는 다시 두세 명의 전문가 서브에이전트를 스폰합니다.

부모 오케스트레이터는 두 명의 에이전트와만 소통하므로, 자신의 컨텍스트가 깔끔하게 유지됩니다. 예를 들어 기능 리드 A는 “검색 기능을 구축하라”는 브리프를 받고, 자체적으로 Data, Logic, API 서브에이전트로 분해합니다. 부모는 그 세부 단계들을 볼 필요가 없습니다.

이는 실제 엔지니어링 조직 구조를 그대로 닮았습니다. VP of Engineering이 개별 엔지니어에게 직접 작업을 쪼개서 주지는 않습니다. 중간에 테크 리드 레이어가 있습니다.

패턴 2: Agent Teams - 진짜 병렬 실행

Agent Teams는 서브에이전트가 갖추지 못한 조율 기능을 추가합니다. 의존 관계가 붙은 공유 작업 목록, 팀 동료 간 메시징, 충돌을 막기 위한 파일 잠금이 그 핵심입니다.

Agent Teams는 진정한 병렬 실행을 위한 Claude Code의 실험적 기능입니다. 다음 설정으로 활성화합니다:

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

아키텍처는 세 층으로 구성됩니다.

Team Lead (리드) - 맨 위에서 작업을 분해하고, 작업 목록을 만들고, 결과를 종합합니다.
Shared Task List (공유 작업 목록) - 중간층에서 각 작업의 상태(대기, 진행 중, 완료, 차단)를 관리하고, 의존성을 추적하며, 파일 잠금을 적용합니다.
Teammates (팀원) - 맨 아래에서 각각 독립적인 Claude Code 인스턴스로, 각자 컨텍스트 윈도를 가진 채 tmux 분할 화면으로 동작합니다.

팀원들은 공유 작업 목록에서 스스로 작업을 가져갑니다. 서로 직접 메시지를 주고받습니다. 팀 리드를 경유하지 않습니다. 팀원이 작업을 완료해 상태를 변경하면, 그 작업에 의존하던 차단 상태의 작업들은 자동으로 풀립니다. 언제든 ⁠Ctrl+T⁠를 눌러 작업 목록을 시각적인 오버레이로 볼 수 있습니다.

데모 2: Agent Teams가 검색 기능을 병렬로 구현하는 과정

데모 2: https://addyosmani.com/blog/code-agent-orchestra/#demo-2

이 데모는 하이라이트입니다. 우선 동작 중인 Link Shelf 앱이 있고, Claude Code에 하나의 프롬프트만 줍니다. “검색 기능을 추가하는 세 명짜리 에이전트 팀을 만들어줘.” 리드는 Backend, Frontend, Test 팀원을 스폰합니다. 백엔드 팀원은 검색 API 엔드포인트 작업을 시작하고, 프론트엔드 팀원은 검색 UI 작업을 시작합니다. 테스트 팀원은 처음에는 차단 상태로, API가 준비되기를 기다립니다. 백엔드가 완료되고 API 계약을 프론트엔드에 전달하면, 테스트 작업이 자동으로 차단 해제되고, 세 팀원이 동시에 각자 일을 이어갑니다.

데모 3: Agent Team 간 커뮤니케이션 자세히 보기

데모 3: https://addyosmani.com/blog/code-agent-orchestra/#demo-3

이 짧은 데모는 커뮤니케이션 메커니즘에 집중합니다. ⁠Ctrl+T⁠ 작업 목록 오버레이, 백엔드가 API 엔드포인트를 완료 상태로 바꾸면서 테스트 작업의 차단 상태가 자동으로 풀리는 모습, 그리고 백엔드 에이전트가 리드를 거치지 않고 프론트엔드 에이전트에게 직접 API 계약을 보내는 피어 메시지를 확인할 수 있습니다.

Agent Teams: 동작 메커니즘

Agent Teams를 가능하게 하는 두 가지 핵심 메커니즘은, 의존성까지 자동으로 처리되는 공유 작업 목록과, 리드를 병목으로 만들지 않는 피어 간 메시징입니다.

공유 작업 목록은 각 작업에 상태를 부여합니다. 대기(pending), 진행 중(in_progress), 완료(completed), 차단(blocked)입니다. 차단 상태의 작업은 명시적인 의존성을 가집니다. 백엔드 팀원이 검색 API 작업을 완료(completed)로 표시하면, 이에 의존하던 테스트 작성 작업은 자동으로 대기(pending) 상태로 전환되고, 팀원 중 하나가 이를 가져갑니다. 파일 잠금은 두 팀원이 동시에 같은 파일을 수정하지 못하도록 막습니다.

또 하나의 핵심은 피어 간 메시징입니다. 백엔드 에이전트는 프론트엔드 에이전트에게 직접 API 계약을 전달합니다. 예를 들어, “GET /search?q= 는 [{id,title,url}] 형태를 반환한다.” 같은 식이죠. 이 통신은 리드를 거치지 않습니다. 팀원이 유휴 상태가 되면 리드는 자동으로 이를 알게 됩니다. 이런 피어 투 피어 접근 방식 덕분에 리드는 조율의 병목 지점이 되지 않습니다.

Agent Teams: 핵심 요약

팀원 수는 3~5명이 가장 적절합니다. 토큰 비용은 팀 규모에 비례해 늘어나지만, 집중된 세 명이 분산된 다섯 명보다 일관되게 더 좋은 결과를 냅니다.

조율을 갖춘 진짜 병렬성 - 단순히 동시에 돌리는 것이 아닙니다. 의존성이 있는 공유 작업 목록 덕분에 작업은 올바른 순서로 진행됩니다.
피어 메시징으로 병목 방지 - 팀원끼리 직접 소통합니다. 백엔드는 리드를 거치지 않고 바로 프론트엔드에 API 계약을 알려줍니다.
위험한 작업에 대한 계획 승인(Plan approval) - 팀원에게 구현에 앞서 계획을 먼저 쓰게 합니다. 리드는 이를 검토해 승인 혹은 반려하며, 코드가 만들어지기 전에 아키텍처 문제를 잡아냅니다.
알맞은 팀 규모 - 팀원 3~5명이 스위트 스폿입니다. 팀 규모가 커질수록 토큰 비용은 선형적으로 증가합니다.

Agent Teams 프로 팁: 신뢰성과 안정성

루프 가드레일과 강제된 자기 성찰(reflection)은 에이전트가 같은 곳에서 계속 막히는 상황을 크게 줄입니다. 모든 작업 완료 시 자동으로 트리거되는 전담 @reviewer 팀원이 있으면, 리드는 항상 ‘검증 완료된 코드’만 받게 됩니다.

루프 가드레일 + Reflection 단계. 모든 팀원에게 ⁠MAX_ITERATIONS=8⁠이라는 상한을 둡니다. 각 재시도 전에 다음과 같은 성찰 프롬프트를 강제로 거치게 합니다.

“무엇이 실패했는가? 어떤 구체적인 변경이 이 문제를 해결할 수 있는가? 같은 접근을 반복하고 있지는 않은가?”

이 한 단계만으로도, 같은 잘못된 접근을 무한히 반복하는 루프에 빠질 가능성이 크게 줄어듭니다. 이런 장치 없이 두면, 에이전트는 동일한 실패 전략을 끝없이 되풀이합니다. 반면, 성찰 단계를 거치면 스스로 방향을 고쳐 잡을 수 있습니다.

전담 @reviewer 팀원. 다음과 같은 제약을 둔 상시 리뷰어를 하나 띄웁니다.

모델: Claude Opus 4.6 (read-only)
도구: lint, test, security-scan만 사용
트리거: TaskCompleted 이벤트가 발생할 때마다 자동 실행
비율: 빌더 3~4명당 리뷰어 1명

이렇게 하면 리드는 항상 리뷰를 통과한 코드만 보게 됩니다. 사실상 팀 안에 상시 CI 품질 게이트가 내장된 셈입니다.

패턴 3: 대규모 오케스트레이션

5, 10, 20개 이상의 에이전트를 여러 레포와 기능에 걸쳐 관리하려면, 전용 오케스트레이션 도구가 필요합니다. 2026년의 도구는 모두 세 가지 계층 중 하나에 속합니다. 상황에 맞는 계층을 골라 쓰세요.

2026년 도구 생태계는 크게 세 가지 계층으로 나뉩니다.

1단계(Tier 1): 프로세스 내부 서브에이전트와 팀

Claude Code 서브에이전트와 Agent Teams가 여기에 해당합니다. 단일 터미널 세션 안에서 돌아가고, 추가 툴링이 필요 없습니다. 여기서 시작하는 것이 좋습니다.

2단계(Tier 2): 로컬 오케스트레이터

로컬 머신에서 여러 에이전트를 개별 worktree로 띄웁니다. 대시보드, diff 리뷰, 머지 컨트롤을 통해 사람이 루프 안에 계속 남아 있게 합니다. 하나의 레포에서 3~10개 에이전트를 병렬로 돌릴 때 적합합니다. 대표적인 도구는 Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, Cursor Background Agents 등이 있습니다.

3단계(Tier 3): 클라우드 비동기 에이전트

작업을 할당하고 노트북을 덮었다가, 준비된 풀 리퀘스트로 돌아오는 방식입니다. 에이전트는 클라우드 VM에서 돌아갑니다. 터미널도, 로컬 설정도 필요 없습니다. Claude Code Web, GitHub Copilot Coding Agent, Google의 Jules, OpenAI의 Codex Web 등이 여기에 속합니다.

2026년 대부분의 개발자는 이 세 계층을 모두 쓰게 될 것입니다. 상호작용성이 필요한 작업에는 1단계를, 병렬 스프린트에는 2단계를, 하룻밤 사이에 백로그를 비울 때는 3단계를 활용하는 식입니다.

도구 스포트라이트

Conductor by Melty Labs

Conductor는 Mac에서 멀티 에이전트 오케스트레이션을 시작하는 가장 빠른 방법입니다. 각 에이전트는 자체 git worktree에서 Claude Code 또는 Codex로 동작하며, Conductor는 이를 시각 대시보드와 diff 중심 리뷰 UI로 보여줍니다. 도구 자체는 무료이고, API 비용만 지불하면 됩니다. 현재는 macOS 전용(Apple Silicon 및 Intel)입니다. 가장 빛을 발하는 지점은 동일 레포에서 3~8개 기능을 병렬로 진행하면서 시각적으로 관리할 때입니다.

Claude Code web

⁠claude.ai/code⁠에서 제공되는 Claude Code Web은 Claude Code의 3단계(Tier 3) 버전으로, 완전히 브라우저 기반이며 터미널이 필요 없습니다. GitHub 레포를 연결하고 작업을 설명하면, Anthropic이 관리하는 클라우드 VM에서 작업이 실행됩니다. 실행 도중에도 방향을 조정할 수 있고, 자동 PR 생성과 iOS 앱 접근도 지원합니다. 핵심적인 사고 방식은 이렇습니다. Teams(터미널)는 에이전트와 함께 ‘옆에서’ 일하는 용도이고, Web(브라우저)은 일을 ‘맡기고 자리를 떠나는’ 용도입니다.

GitHub Copilot coding agent

중요한 구분점이 있습니다. IDE 내 Copilot 에이전트 모드는 동기적이고 인터랙티브합니다. 반면 GitHub Copilot Coding Agent는 완전 비동기입니다. 어떤 GitHub 이슈든 ⁠@copilot⁠에게 할당하거나 Agents 패널을 사용하면, GitHub Actions 환경에서 작업하여 초안 PR을 만들어 줍니다. 또한 이제는 스스로 리뷰 루프를 돌린 후 당신을 태그합니다. Claude Code와 Codex를 비롯한 서드파티 에이전트들도 동일한 Agents 패널을 통해 접근 가능하며, Slack, Jira, Linear, Azure Boards에서도 트리거할 수 있습니다.

Jules by Google

Jules는 Gemini 기반 Google의 비동기 클라우드 코딩 에이전트입니다. 워크플로는 다음과 같습니다. GitHub 레포를 연결하고 작업을 설명하면, Jules가 먼저 계획안을 생성합니다. 이 계획을 당신이 승인해야 실제 코드 작성이 시작됩니다. 그런 다음 클라우드 VM에서 작업이 실행되고, 충분한 reasoning과 터미널 로그를 포함한 PR이 돌아옵니다. 오디오 체인지로그, 작업 중간 인터럽트, GitHub 이슈를 바로 파이프라인에 태울 수 있는 Jules Tools CLI 같은 기능이 특징입니다. 추가 설정 없이도 레포에 있는 ⁠AGENTS.md⁠를 자동으로 읽어 활용합니다.

OpenAI Codex web

Codex Web은 이 영역에서 가장 널리 사용되는 도구 중 하나입니다. 각 작업은 GitHub 레포가 미리 로드된 독립 샌드박스 컨테이너에서 돌아갑니다. Web, CLI(오픈소스), macOS 앱, IDE 확장, GitHub 연동 등 다양한 인터페이스가 존재하며, 모두 ChatGPT 계정 하나로 연결됩니다. verifiable evidence 기능은 각 작업에서 실행된 터미널 로그와 테스트 결과를 인용(citation) 형태로 반환해, 정확히 무슨 일이 일어났는지 감사를 가능하게 합니다.

Cursor Cloud Agents + Glass

Cursor의 에이전트 기본 개념을 그대로 유지하되, 실행 환경을 로컬 대신 격리된 클라우드 VM으로 옮긴 형태입니다. 웹, 데스크톱 앱, Slack, Linear, GitHub, API는 물론, cursor.com/agents를 PWA로 설치해 휴대폰에서 에이전트를 시작할 수도 있습니다. Glass는 에디터가 아닌 에이전트 관리가 기본 인터페이스가 되도록 새로 디자인된 UI로, 필요할 때만 기존 에디터를 꺼내 쓰게 합니다. 이는 생태계 전체에서 나타나는 더 큰 패턴을 반영합니다. 제어면(control plane)이 주 인터페이스가 되고, 에디터는 그 아래의 여러 악기 중 하나가 되는 방향입니다.

Vibe Kanban

Vibe Kanban은 에이전트가 작업 중인 2~5분 동안 당신이 할 일이 없어지는 “둠스크롤링 공백(doomscrolling gap)” 문제를 해결합니다. 자세한 프롬프트와 함께 태스크 카드를 만들고, “In Progress” 칼럼으로 끌어다 놓으면, 각 카드마다 자체 worktree와 브랜치가 할당됩니다. 보드 안에서 diff를 리뷰하고, 실행 중인 에이전트에게 피드백을 보낼 수 있습니다. Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI 등 다양한 도구를 지원하며, Mac/Windows/Linux 모두에서 동작하는 BYOK(Bring Your Own Key) 방식의 무료 도구입니다.

확장에 대한 프로 팁

멀티 모델 라우팅을 적용하면 품질을 유지한 채 비용을 줄일 수 있습니다. 사람 손으로 다듬은 AGENTS.md는 길이에 상관없이 기계가 생성한 것보다 가치가 높습니다. 연구에 따르면 AI가 작성한 규칙은 이득이 없을 뿐 아니라 성공률을 소폭(평균 약 3%) 떨어뜨릴 수도 있습니다.

멀티 모델 라우팅

모든 작업에 가장 비싼 모델을 쓸 필요는 없습니다. 계획 수립과 아키텍처 설계는 더 저렴한 Gemini/Claude/OpenAI 모델로 라우팅합니다. 구현은 Sonnet, Opus 또는 Codex로 보내고, 리뷰는 전용 보안/검토 모델에 맡깁니다. 다음과 같은 ⁠MODEL_ROUTING.md⁠ 파일을 만들어 두세요.

Planning       -> Gemini 
Implementation -> Claude Opus or Sonnet 
Review         -> etc.
Tests          -> etc.

Worktree 라이프사이클 스크립트

세 개의 셸 alias만으로 반복적인 잡무를 자동화할 수 있습니다.

agent-spin <feature>   # worktree + 브랜치 생성 + 에이전트 시작
agent-merge <feature>  # rebase + 리뷰 + PR 생성
agent-clean            # 완료된 worktree 삭제

대략 12줄짜리 bash 스크립트로 해결할 수 있습니다. Conductor는 이런 일을 시각 UI로 대신 해 줍니다.

사람이 관리하는 AGENTS.md

이게 핵심입니다. 연구에 따르면 (Gloaguen 외, ETH Zurich), LLM이 생성한 ⁠AGENTS.md⁠ 파일은 아무런 이득을 주지 못할 뿐 아니라, 평균 약 3% 정도 성공률을 떨어뜨리고 추론 비용은 20% 이상 증가시키는 것으로 나타났습니다. 반대로 개발자가 직접 작성한 컨텍스트 파일은 약 4% 정도의 성과 향상을 가져옵니다.

에이전트가 ⁠AGENTS.md⁠를 직접 수정하게 두지 마세요. 리드가 한 줄 한 줄 승인해야 합니다. 대신 다음처럼 짧고 명확한 섹션으로 유지하세요:

## STYLE
- 훅을 사용하는 함수형 컴포넌트를 사용한다
- named export를 우선적으로 사용한다

## GOTCHAS
- 동시에 읽기 작업을 처리하려면 SQLite에서 WAL 모드가 필요하다
- 인증을 위해서는 Express 미들웨어의 순서가 중요하다

## ARCH_DECISIONS
- 모든 상태는 SQLite에 저장하고, 인메모리 캐시는 사용하지 않는다
- 각 기능 모듈마다 하나의 Express 라우터를 사용한다

## TEST_STRATEGY
- API 라우트에 대해서는 유닛 테스트보다 통합 테스트를 우선한다
- HTTP 검증에는 supertest를 사용한다

품질 검증 장치: 신뢰하되, 검증은 필수

세 가지 품질 게이트가 에이전트 출력에 신뢰성을 부여합니다. 계획 승인(plan approval)은 코드가 생기기 전에 잘못된 아키텍처를 걸러내고, 훅(hook)은 모든 라이프사이클 이벤트마다 자동 검사를 강제하며, ⁠AGENTS.md⁠는 세션을 거듭하며 학습을 누적시킵니다.

Plan approval. 팀원들이 코딩을 시작하기 전에 반드시 계획부터 작성하게 만드세요. 리드는 이 접근 방식을 검토한 뒤 승인하거나 반려합니다. 나쁜 코드를 고치는 것보다, 나쁜 계획을 고치는 편이 훨씬 저렴합니다. 플로우는 다음과 같습니다:

teammate >>> writes plan >>> lead review >>> approve/reject >>> implement

Hooks. 라이프사이클 이벤트마다 자동으로 도는 체크입니다. ⁠TeammateIdle⁠ 훅은 에이전트가 일을 멈추기 전에 모든 테스트가 통과했는지를 검증합니다. ⁠TaskCompleted⁠ 훅은 작업을 완료로 표시하기 전에 lint와 테스트를 실행합니다. 훅이 실패하면, 에이전트는 통과할 때까지 계속 수정 작업을 합니다:

task done >>> hook runs npm test >>> pass? allow | fail? keep working

AGENTS.md를 통한 복리 학습. 이 파일은 발견된 패턴, 주의해야 할 점, 팀의 스타일 선호를 담습니다. 모든 에이전트는 세션 시작 시 이 파일을 읽고, 매 세션은 여기에 무언가를 추가합니다. 첫 번째 세션에서 테스트 패턴을 하나 배웠다면, ⁠AGENTS.md⁠에 추가되고, 두 번째 세션은 같은 실수를 피하게 됩니다.

이제 병목 지점이 달라졌다

이제 병목은 생성이 아니라 검증입니다. 에이전트는 놀라운 속도로 인상적인 출력을 만들어낼 수 있습니다. 그 출력이 실제로 올바른지 자신 있게 판단하는 것이 진짜 어려운 부분입니다.

변경 이전에 통과하던 테스트가, 변경 이후에 생기는 회귀(regression)를 반드시 잡아준다는 보장은 없습니다. 에이전트는 문법상/형식상 문제없는 테스트 코드를 쓸 수 있지만, 실제로 중요한 케이스를 놓칠 수 있습니다. 컨텍스트 윈도의 한계 때문에, 대형 코드베이스에서 일하는 에이전트는 자신의 현재 뷰 밖에 있는 중요한 제약사항을 놓치기 쉽습니다. 게다가 한 개발자에게는 “가끔 걸리는 짜증 나는 플래키 테스트”였던 것이, 40개의 에이전트가 동시에 그 플래키 테스트를 밟기 시작하면 시스템 전체를 가로막는 장애가 됩니다.

검증 인프라가 생성 능력 수준을 따라잡기 전까지, 인간 리뷰는 선택적 오버헤드가 아닙니다. 안전장치 그 자체입니다. 눈부신 에이전트 출력에 대한 올바른 반응은 “겉보기에 좋아 보이니 믿자”가 아닙니다. 대신, 그 결과를 엄밀히 평가할 수 있는 아키텍처적 이해와 테스트 설계 능력을 갖추는 것입니다.

Demo 4: 품질 게이트와 스스로 성장하는 에이전트

데모 4: https://addyosmani.com/blog/code-agent-orchestra/#demo-4

이 데모는 앞서 설명한 내용을 모두 엮어 보여줍니다. 세 가지에 주목하세요.

첫째, 계획 승인 플로우입니다. 한 팀원이 즐겨찾기(favorites) 기능 추가를 제안하면서 계획을 제출하고, 리드는 그 계획에 데이터베이스 마이그레이션 단계가 빠져 있다는 점을 발견해 반려합니다. 이후 팀원은 계획을 수정합니다.

둘째, 작업 완료 시 발동하는 훅입니다. ⁠TaskCompleted⁠ 훅이 깜빡 잊고 남겨둔 ⁠console.log⁠를 잡아내고, 에이전트는 해당 로그를 제거한 뒤에야 작업이 완료로 인정됩니다.

셋째, 마지막에 ⁠AGENTS.md⁠가 새로운 항목으로 업데이트되는 장면입니다. “기존 테이블에 컬럼을 추가할 때는 항상 ALTER TABLE 마이그레이션을 포함할 것.” 이 학습 내용은 이후 모든 세션에 그대로 이어집니다.

Ralph 루프와 스스로 진화하는 에이전트들

Ralph Loop 패턴은 개발을 작은 원자적(atomic) 작업들로 쪼개고, 에이전트를 ‘상태는 비우되 반복(iterative)’되는 루프 안에서 실행합니다. 각 반복은 ‘작업 선택 → 구현 → 검증 → 통과 시 커밋 → 컨텍스트 리셋 후 반복’으로 이루어집니다. 이렇게 하면 컨텍스트 폭주를 피하면서도 외부 메모리를 통해 연속성을 유지할 수 있습니다.

Geoffrey Huntley와 Ryan Carson이 널리 알린 Ralph Loop는, 말 그대로 “자는 동안에도 배포가 되는(shipping while you sleep)” 패턴의 핵심입니다. Carson의 단일 바이너리 도구 ⁠ralph⁠(snarktank/ralph)는 이 코어 루프를 구현하고 있고, 그의 Antfarm 프로젝트는 OpenClaw 위에 멀티 에이전트 오케스트레이션을 쌓되 같은 패턴을 활용합니다. 핵심 아이디어는 도구를 가리지 않고 일반화됩니다.

다섯 단계의 사이클은 다음과 같습니다.

Pick - ⁠tasks.json⁠에서 다음 작업을 선택한다.
Implement - 변경 사항을 구현한다.
Validate - 테스트, 타입 체크, 린트를 실행한다.
Commit - 모든 검사를 통과하면 커밋하고 작업 상태를 갱신한다.
Reset - 에이전트 컨텍스트를 깨끗이 지우고, 다음 작업으로 다시 시작한다.

핵심 통찰은 ‘상태는 비우되 반복한다’는 점입니다. 각 반복마다 컨텍스트를 리셋함으로써 혼란이 누적되는 것을 막습니다. 큰 한 번의 프롬프트로 거대한 일을 시키는 것보다, 잘 경계가 설정된 작은 작업들을 여러 번 돌리는 편이 훨씬 깨끗한 코드와 더 적은 환각(hallucination)을 만들어 냅니다.

이 패턴을 신뢰할 수 있게 만들어주는 안정장치들은 다음과 같습니다. 오류를 피드백해 자동 재시도를 허용하되, 같은 곳에서 3회 이상 막히면 루프를 종료하고 다른 에이전트에게 재할당합니다. 항상 기능 브랜치에서 작업합니다. 반복 횟수, 시간, 토큰 사용량에 대해 하드 리밋을 둡니다. 에이전트는 PR까지만 열고, 최종 머지는 당신이 리뷰 후 진행합니다.

각 반복 간에도 네 가지 채널의 메모리는 계속 유지됩니다. git 커밋 히스토리, 진행 로그, 작업 상태 파일(⁠tasks.json⁠), 그리고 장기 의미 메모리로서의 ⁠AGENTS.md⁠입니다. 처음에는 단 하나의 루프를 밤새 돌리는 것부터 시작하세요. 그다음에는 열 개 브랜치에서 열 개 루프를 돌리는 수준으로 확장할 수 있습니다.

시간이 지날수록 에이전트를 더 똑똑하게 만드는 방법

REFLECTION.md 제안서를 통한 자기 성찰(Self-Reflection). 매 작업이 끝날 때마다, 에이전트가 ⁠REFLECTION.md⁠를 작성하도록 강제합니다. 내용은 “무엇이 나를 놀라게 했는가?”, “⁠AGENTS.md⁠에 추가할만한 패턴 하나”, “프롬프트를 어떻게 개선할 수 있는지 한 가지”입니다. 리드는 이 제안들을 검토한 뒤 승인된 것만 병합합니다. 이렇게 해야만 복리 학습이 실제로 복리처럼 쌓입니다. 즉, 즉흥적인 깨달음이 아니라 체계적인 방식으로요.

토큰 예산과 종료 기준(Token Budgeting and Kill Criteria). 에이전트별로 단단한 예산을 설정합니다. 예를 들어, 프론트엔드는 180k 토큰, 백엔드는 280k 토큰과 같이 정합니다. 예산의 85%에 도달하면 자동으로 일시 중지하고 리드에게 알립니다. 동일한 오류에서 3회 이상 막히면 해당 에이전트를 종료하고 새 에이전트에게 재할당합니다.

Beads / 영속 메모리(Persistent Memory). Gastown의 “beads” 패턴은 모든 결정과 결과를 전체 출처 정보와 함께 기록한, 변경 불가능한 git 기반 레코드입니다. 에이전트들은 과거 beads를 태스크 그래프와 SQL로 질의 가능한 데이터 플레인을 통해 조회합니다. 이는 전통적인 벡터 기반 RAG와는 다른 형태로, 평평한 하나의 마크다운 파일을 훨씬 넘어서는 구조화된 “조직의 기억(institutional memory)”에 가깝습니다.

이 시스템이 돌아가게 만드는 규율

인간이 병목이던 시절의 느린 속도는 사실 버그가 아니라 기능이었습니다. 인간 속도에서는 실수가 천천히 누적되고, 그 과정에서 느끼는 고통이 일찍 수정을 이끌어냅니다. 하지만 에이전트 군단과 함께라면, 작은 실수들이 당신이 감당할 수 없는 속도로 불어나기 시작합니다.

사람이 직접 코드를 느리게 쓸 때는, 문제를 빨리 체감합니다. 테스트가 깨지고, 코드 리뷰가 무언가를 걸러내고, 중복을 발견합니다. 불편함이 즉각적으로 느껴지기 때문에 그때그때 고치게 됩니다.

반면, 에이전트 군단을 오케스트레이션하는 상황에서는 자연스러운 병목이 사라집니다. 작은 코드 스멜, 사소한 중복, 불필요한 추상화 같은 것들이 감당 불가능한 속도로 쌓입니다. 당신이 루프 밖으로 빠져나왔기 때문에, 고통을 느끼기도 전에 이미 너무 늦어집니다. 어느 날 새로운 기능을 추가하려고 보면, 아키텍처가 이를 허용하지 않습니다. 테스트 역시 똑같이 신뢰할 수 없게 되는데, 그 테스트 역시 에이전트가 썼기 때문입니다.

그래서 모든 품질 게이트가 중요한 것입니다. 계획 승인, 훅, 토큰 예산, 인간 리뷰는 “있으면 좋은 것”이 아니라, 없으면 결국 에이전트 주도의 코드베이스가 스스로를 막다른 골목으로 몰아가게 됩니다.

실행은 에이전트에 위임하되, 최종 판단은 직접

에이전트에게는 통과/실패 기준이 뚜렷한 범위 지정 작업, 보일러플레이트, 마이그레이션, 테스트 스캐폴딩을 맡기세요. 당신이 계속 쥐고 있어야 할 것은 아키텍처, 무엇을 만들지 ‘않을지’를 결정하는 일, 전체 컨텍스트를 가진 리뷰, 그리고 좋은 시스템을 판별하는 미감(taste)입니다.

에이전트는 스스로 결과를 평가할 수 있는, 평가 함수가 명확한 작업에서 특히 뛰어납니다. 보일러플레이트, 마이그레이션, 테스트 스캐폴딩, 그리고 사람이 손으로 해보기에는 너무 시간이 많이 드는 다양한 접근 실험 등에는 진심으로 강력합니다.

반대로, 당신이 반드시 직접 해야 할 것은 아키텍처와 API 설계입니다. 에이전트는 학습 데이터에서 수많은 나쁜 아키텍처 또한 함께 보았고, 그런 패턴을 신생 스타트업 코드베이스에 아무렇지 않게 카고컬트(cargo-cult)할 수 있습니다. 또, 무엇을 만들 ‘필요가 없는지’를 결정하는 일 역시 사람의 역할입니다. “아니오”라고 말하는 기능은 에이전트에게 없습니다. 마지막으로, 전체 시스템 문맥을 가진 상태에서 에이전트 출력을 리뷰하는 일 역시 당신 몫입니다. 에이전트는 언제나 국소적인 뷰만 가질 수 있습니다.

기능은 적게 만들되, 제대로 된 것만 만드세요. 코드 생성 속도는 유혹적인 노래입니다. 이해를 유지할 수 있을 만큼 속도를 늦추어야 합니다. 당신이 자기 시스템에 대한 이해를 잃는 순간, 그 시스템을 고치거나 확장하거나, 심지어 망가졌는지조차 알 수 있는 능력을 잃게 됩니다.

스펙이 곧 레버리지

50명의 에이전트를 병렬로 오케스트레이션할 때, 모호한 사고는 단순히 속도를 늦추는 정도가 아니라, 그대로 증폭됩니다. 애매한 요구사항은 수십 개의 병렬 실행에 퍼져, 각각을 조금씩 다른 잘못된 방향으로 밀어냅니다. 뛰어난 엔지니어일수록 에이전트에서 얻는 레버리지도 더 커집니다. 줄어들지 않습니다.

평범한 결과와 탁월한 결과를 가르는 차이는 거의 전적으로 스펙의 품질에서 나옵니다. 애매한 스펙은 오류를 전체 플릿에 복리로 전파합니다. 반대로 아키텍처, 통합 경계, 엣지 케이스, 불변 조건이 명확히 정의된 정교한 스펙은, 곳곳에서 정교한 구현으로 복리처럼 증식합니다.

이제 스펙은 더 이상 단순한 프롬프트가 아닙니다. 스펙은 곧 제품 사고(product thinking)를 문서화한 것입니다. 그래서 뛰어난 소프트웨어 엔지니어가 이 도구들에서 더 큰 레버리지를 얻는 것입니다. 타이핑이라는 기계적인 작업은 자동화되고 있지만, 시스템을 이해하는 인지 작업은 오히려 수십 명의 자율적인 작업자 플릿 전체에 증폭되고 있습니다.

팩토리 모델

당신은 이제 더 이상 코드만 쓰는 사람이 아닙니다. 소프트웨어를 생산하는 공장(factory)을 짓고 있습니다. 그 공장에는 “Plan → Spawn → Monitor → Verify → Integrate → Retro”라는 생산 라인이 있습니다.

공장에는 품질 관리가 있고, 프로세스 문서가 있으며, 입력이 정밀하게 명세되지 않으면 출력이 잘못 나옵니다. 환경이 불안정하면 공장은 멈춰섭니다. 이 모든 특성은 에이전트 중심의 소프트웨어 개발에 그대로 대응됩니다.

여섯 단계의 생산 라인은 다음과 같습니다.

Plan - 명확한 수용 기준(acceptance criteria)을 갖춘 스펙을 작성합니다. 스펙이 곧 레버리지입니다.
Spawn - 팀을 구성하고 에이전트를 할당합니다.
Monitor - 5~10분 간격으로 진행 상황을 확인하고, 막힌 부분을 풀어줍니다. 과도하게 들러붙지는 않습니다.
Verify - 테스트를 돌리고 코드를 리뷰합니다. 병목은 생성이 아니라 검증입니다.
Integrate - 브랜치를 머지하고, 충돌을 해결합니다.
Retro - ⁠AGENTS.md⁠에 새 패턴을 추가합니다. 학습을 복리로 쌓습니다.

공장을 운영할 때의 실질적인 팁은 다음과 같습니다.

WIP 한도 설정(WIP limits): 의미 있게 리뷰할 수 있는 양보다 더 많은 에이전트를 돌리지 마세요. 3~5명이 스위트 스폿입니다.
종료 기준 정의(kill criteria): 한 에이전트가 같은 오류에서 3회 이상 막히면, 멈추게 하고 다른 에이전트에 재할당하세요.
비동기 체크인: 5~10분 간격으로 진행 상황을 확인하고, 나머지는 에이전트가 자율적으로 일하게 두세요.
One file, one owner: 같은 파일을 두 에이전트가 동시에 수정하게 만들지 마세요. 충돌은 속도를 박살냅니다.

이 프레임워크에 대한 더 자세한 내용은 The Factory Model을 참고하세요.

지금 바로 시작할 수 있는 5가지 패턴

이번 내용에서 꼭 가져가야 할 다섯 가지를 정리하면 다음과 같습니다.

분해를 위한 서브에이전트(Subagents for decomposition). Task 도구를 사용해, 명확한 브리프와 파일 소유권을 가진 포커스된 자식 에이전트를 스폰하세요. 추가 설정은 필요 없습니다. 오늘 당장 여기서 시작할 수 있습니다.
병렬성을 위한 Agent Teams. ⁠CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1⁠을 활성화하고, 리드 + 팀원 3명으로 팀을 구성하세요. 공유 작업 목록으로 조율합니다.
격리를 위한 Git worktrees. 각 에이전트에 자체 worktree를 부여하세요. 머지 충돌 없이 깔끔하게 통합할 수 있습니다. Conductor 같은 도구는 이를 시각적으로 대신 처리해 줍니다.
신뢰를 위한 품질 게이트(Quality gates for trust). 위험한 변경에는 계획 승인을 필수로 요구하고, 작업 완료 시 테스트를 자동으로 실행하는 훅을 추가하세요. 검증 없이 에이전트 출력을 신뢰하지 마세요.
복리 학습을 위한 AGENTS.md. 패턴, 주의사항, 스타일 선호를 문서화하세요. 모든 세션이 이를 읽고, 모든 세션이 여기에 무언가를 추가합니다. 지식은 이렇게 복리로 쌓입니다.

오늘은 패턴 1부터 시작하세요. 다음 주에는 Agent Teams로 올라가고, 그 위에 품질 게이트와 복리 학습 레이어를 차근차근 쌓아 올리면 됩니다.