6개월 전 대부분의 개발자는 AI 에이전트 한 명과 대화했습니다. 지금 가장 생산성 높은 개발자들은 여러 에이전트를 동시에 돌리며 위에서 조율합니다. 코딩 도구를 쓰는 방식이 바뀐 게 아니라, 개발자라는 역할 자체가 바뀌고 있다는 게 구글 엔지니어링 디렉터 Addy Osmani의 진단입니다.

Osmani가 O’Reilly AI CodeCon에서 발표한 내용을 정리한 글입니다. 싱글 에이전트의 구조적 한계에서 출발해 멀티 에이전트 조율 패턴, 도구 생태계, 품질 관리까지 실전 경험을 담았습니다.

출처: The Code Agent Orchestra – what makes multi-agent coding work – Addy Osmani

Conductor에서 Orchestrator로

Osmani는 개발자와 AI 에이전트의 관계를 두 가지 모델로 구분합니다.

Conductor 모델은 개발자가 AI 에이전트 한 명을 실시간으로 이끄는 방식입니다. 프롬프트를 입력하고, 결과를 받고, 피드백하고, 반복합니다. 동기적이고 순차적이며, 대화창 하나가 작업 공간의 전부입니다. Claude Code CLI나 Cursor처럼 에디터 안에서 에이전트와 주고받는 방식이 여기 해당합니다.

Orchestrator 모델은 근본적으로 다릅니다. 개발자는 코드를 직접 짜지 않고, 여러 에이전트에게 작업을 분해해 할당한 뒤 비동기로 결과를 검토합니다. 각 에이전트는 자신만의 컨텍스트 창과 담당 영역을 갖고 동시에 작동합니다. 개별 연주자를 실시간 지도하는 지휘자가 아니라, 각 파트가 자율적으로 연주하는 앙상블을 설계하는 역할입니다.

이 전환이 필요한 이유는 Conductor 모델에 구조적 천장이 있기 때문입니다. 코드베이스가 커질수록 하나의 컨텍스트 창으로는 전체를 담을 수 없고, 데이터 레이어·API·UI·테스트를 한 에이전트가 동시에 처리하면 전문성이 희석됩니다. 에이전트를 여럿 띄워도 이들이 서로 소통하거나 의존성을 추적할 방법이 없습니다.

멀티 에이전트가 단순히 더 빠른 게 아닌 이유

Orchestrator 모델의 이점은 단순 합산이 아닙니다. Osmani가 꼽는 네 가지 이유입니다.

병렬 처리: 프론트엔드, 백엔드, 테스트를 각각 담당하는 에이전트가 동시에 돌면 처리량이 최대 3배까지 늘어납니다.

전문화: 각 에이전트는 자신이 맡은 파일만 봅니다. db.js만 담당하는 에이전트가 전체 코드베이스를 떠안은 에이전트보다 훨씬 나은 데이터베이스 코드를 작성합니다.

격리: 에이전트마다 별도의 git worktree에서 작업하니 파일 충돌이 없습니다.

복합 학습(Compound Learning): 발견된 패턴과 주의사항을 AGENTS.md에 축적합니다. 한 세션에서 배운 것이 다음 세션의 실수를 막고, 팀 전체가 시간이 지날수록 똑똑해집니다.

세 가지 조율 패턴

서브에이전트: 시작하기 가장 쉬운 방식

부모 Orchestrator가 작업을 분해해 자식 에이전트들에게 브리프를 전달합니다. 북마크 앱을 만든다면 이렇게 나뉩니다.

1. 데이터 레이어 에이전트 → db.js 작성 후 DATA.md 리포트 생성
2. 비즈니스 로직 에이전트 → validation.js 작성 후 LOGIC.md 리포트 생성
3. API 라우트 에이전트 → 위 두 리포트를 읽은 후 server.js 작성

첫 두 에이전트는 독립적이라 병렬 실행되고, 세 번째는 앞 둘이 끝난 다음 시작합니다. 병렬성과 전문화는 얻지만, 의존성 그래프는 개발자가 수동으로 관리해야 하고 에이전트 간 직접 소통은 없습니다.

에이전트 팀: 조율 기능을 시스템 안으로

서브에이전트에서 빠진 조율을 내재화한 패턴입니다. 팀 리드가 공유 태스크 리스트를 만들고, 팀원들이 자율적으로 작업을 가져갑니다. 결정적인 차이는 피어-투-피어 메시징입니다. 백엔드 에이전트가 API 명세를 완성하면 리드를 거치지 않고 프론트엔드 에이전트에게 직접 전달하고, 대기 중이던 테스트 에이전트는 그 순간 자동으로 언블록됩니다. 리드가 병목이 되지 않는 구조입니다.

적정 팀 규모는 3~5명. 토큰 비용은 팀 크기에 선형 비례하지만, 집중된 에이전트 셋이 분산된 다섯보다 일관되게 낫다는 게 Osmani의 관찰입니다.

대규모 오케스트레이션: 도구 생태계 3티어

개인 터미널을 넘어 팀 단위, 클라우드 규모로 확장할 때는 목적에 맞는 도구를 선택해야 합니다. Osmani는 2026년 현재 도구 생태계를 세 티어로 분류합니다.

Tier 1 (인터랙티브): Claude Code 서브에이전트·에이전트 팀. 터미널 한 세션 안에서 실시간으로 함께 작업합니다.

Tier 2 (로컬 오케스트레이터): Conductor, Vibe Kanban 등. 내 기기에서 여러 에이전트를 병렬로 돌리되, 대시보드와 diff 리뷰로 사람이 루프 안에 머뭅니다. 3~10개 에이전트, 익숙한 코드베이스에 적합합니다.

Tier 3 (클라우드 비동기): Claude Code Web, GitHub Copilot Coding Agent, Jules(Google), Codex Web(OpenAI). 작업을 지시하고 노트북을 닫으면, 에이전트가 클라우드 VM에서 실행해 PR을 열어줍니다. 백로그를 밤새 소화하는 데 쓸 수 있습니다.

대부분의 개발자는 세 티어를 병행해서 쓰게 됩니다. 인터랙티브 작업은 Tier 1, 병렬 스프린트는 Tier 2, 백로그 처리는 Tier 3으로요.

빠를수록, 검증이 더 중요해진다

멀티 에이전트 시스템에서 병목은 생성이 아니라 검증으로 이동합니다. Osmani가 강조하는 품질 게이트는 세 가지입니다.

계획 승인: 에이전트가 코드 작성 전 계획을 먼저 제출하면, 리드가 검토 후 승인 또는 반려합니다. 잘못된 아키텍처는 코드가 생기기 전에 잡는 게 훨씬 저렴합니다.

훅(Hooks): 태스크 완료 시점에 자동으로 테스트·린트를 실행합니다. 통과하지 못하면 에이전트가 계속 작업합니다. 사람이 검토할 때는 이미 통과한 코드만 올라옵니다.

AGENTS.md: 발견된 패턴과 주의사항을 축적하는 파일입니다. 단, ETH 취리히 연구팀에 따르면 AI가 작성한 AGENTS.md는 효과가 없거나 성공률을 소폭 낮추는 반면, 개발자가 직접 쓴 것은 약 4% 성능을 개선합니다. 이 파일만큼은 사람 손으로 관리해야 한다는 뜻입니다.

개발자의 역할이 바뀐다

Osmani가 이 글 전반에 걸쳐 가장 강하게 주장하는 건 역할의 변화입니다. 개발자는 코드를 직접 짜는 사람에서 코드를 만드는 공장을 설계하고 운영하는 사람으로 이동합니다.

에이전트가 잘하는 건 평가 기준이 명확한 작업입니다. 보일러플레이트, 마이그레이션, 테스트 스캐폴딩처럼 맞고 틀림이 분명한 것들. 반면 아키텍처 설계, 무엇을 만들지 않을 결정, 시스템 전체 맥락을 갖고 검토하는 일은 여전히 사람의 영역입니다. 에이전트는 훈련 데이터에서 본 엔터프라이즈 패턴을 맥락과 무관하게 적용하는 경향이 있습니다.

코드 생성이 빨라질수록 사양(spec)의 품질이 더 중요해집니다. 모호한 지시는 수십 개의 에이전트를 통해 서로 다른 방향으로 증폭되고, 정밀한 지시는 정밀한 구현으로 이어집니다. Orchestrator를 잘 운영하는 개발자가 더 강해지는 이유입니다.

원문에는 계층형 서브에이전트 구성, Ralph Loop 패턴, 멀티 모델 라우팅 전략, 각 도구별 상세 비교 등 더 깊은 내용이 담겨 있습니다.

참고자료: The Future of Agentic Coding – Addy Osmani