The Code Agent Orchestra - what makes multi-agent coding work 논문 정리

이 글은 엄밀한 학술 논문이라기보다 2026년 O'Reilly CodeCon 발표를 글로 풀어낸 실무 정리문에 가깝다.
그래도 메시지는 분명하다.
이제 생산성의 핵심은 더 좋은 한 명의 AI보다 여러 에이전트를 어떻게 나누고, 연결하고, 검증하느냐에 있다.

한눈에 보는 핵심 주장

• 싱글 에이전트는 곧 컨텍스트 한계에 부딪힌다.
• 멀티 에이전트의 진짜 이점은 단순 속도보다 분업 구조다.
• 병목은 생성이 아니라 검증이다.
• 그래서 좋은 스펙, 명시적 작업 분해, 공유 작업표, 품질 게이트가 중요해진다.

지금의 전환점: AI와 페어 프로그래밍하던 시대가 끝났다

저자가 보는 변화는 단순한 도구 업그레이드가 아니다.
역할 자체가 바뀌었다.

예전에는 개발자 한 명이 AI 한 명과 대화했다.
지금은 개발자 한 명이 여러 에이전트를 띄우고, 각자 다른 범위를 맡기고, 중간중간 상태를 점검한다.

핵심 변화는 이것이다.

• 예전: 한 명과 실시간으로 주고받는 방식
• 지금: 여러 명에게 비동기적으로 일을 배치하는 방식

즉, 개발자는 코드를 직접 치는 사람에서 작업 흐름을 설계하는 사람으로 이동한다.

8단계 프레임: 왜 L5 이후가 완전히 다른가

이 글은 Steve Yegge의 8단계 프레임을 빌려 지금의 전환점을 설명한다.
L1부터 L4까지는 여전히 "한 에이전트를 얼마나 자연스럽게 쓰는가"의 문제에 가깝다.
하지만 L5부터는 대화가 작업의 중심이 되고, L6 이후부터는 본격적으로 오케스트레이션이 시작된다.

 

 

Crop 포인트: L5에서 작업의 중심이 IDE에서 에이전트 대화로 이동하고, L6 이후부터는 생산성이 모델 성능보다 조율 능력에 더 크게 좌우된다는 흐름을 보면 된다.

이 그림이 좋은 이유는 수준 차이를 단순 기능 비교가 아니라 신뢰와 자율성의 축으로 정리하기 때문이다.
특히 L6, L7, L8은 "AI를 잘 쓰는 사람"이 아니라 "에이전트 팀을 운영하는 사람"의 영역이다.

핵심 전환: 한 명을 지휘하는 사람에서 여러 명을 조율하는 사람으로

저자는 기존 방식을 conductor model에, 새 방식을 orchestrator model에 비유한다.

기존 방식은 이렇다.

• 한 에이전트
• 순차 실행
• 실시간 피드백
• 하나의 컨텍스트 윈도가 한계

새 방식은 다르다.

• 여러 에이전트
• 비동기 실행
• 병렬 컨텍스트
• 개발자는 중간 관리자처럼 분해와 검증을 담당

이 차이는 생각보다 크다.
한 명의 강한 에이전트를 붙잡고 오래 대화하는 것과, 여러 명의 에이전트에게 역할을 나눠 맡기는 것은 완전히 다른 작업 방식이다.

왜 한 명의 강한 에이전트로는 부족한가

이 글은 싱글 에이전트의 한계를 세 가지로 정리한다.

• 컨텍스트 과부하: 코드베이스가 커질수록 중요한 정보가 밀려난다.
• 전문화 부족: 데이터 계층, UI, 테스트를 한 에이전트가 모두 잘하기는 어렵다.
• 조정 부재: 여러 에이전트를 띄워도 서로 대화하고, 의존성을 풀고, 같은 파일 충돌을 피하는 메커니즘이 없다.

여기서 특히 중요한 건 세 번째다.
에이전트를 둘, 셋으로 늘리는 순간 문제는 "생성 품질"만이 아니다.
누가 먼저 끝나는지, 누가 누구 결과를 기다리는지, 같은 파일을 누가 건드리는지 관리해야 한다.

그래서 멀티 에이전트의 핵심은 단순 병렬화가 아니라 조정 인프라다.

패턴 1: 서브에이전트는 분업의 시작점이다

첫 번째 패턴은 subagents다.
부모 에이전트가 작업을 쪼개고, 자식 에이전트에게 세부 일을 맡긴다.

예시는 단순하다.

• 데이터 계층 에이전트는 스키마와 CRUD를 만든다.
• 비즈니스 로직 에이전트는 입력 검증 규칙을 만든다.
• API 에이전트는 앞선 결과를 읽고 라우트를 붙인다.

앞의 두 작업은 동시에 돌릴 수 있다.
마지막 작업은 둘의 결과를 기다렸다가 시작하면 된다.

 

 

Crop 포인트: 위쪽의 병렬 작업 두 개보다, 그 결과를 보고서 파일로 넘겨 마지막 단계가 이어받는 연결 방식이 이 패턴의 본질이다.

이 방식의 장점은 분명하다.

• 컨텍스트를 작게 유지할 수 있다.
• 역할별 전문화를 만들 수 있다.
• 독립 작업은 동시에 돌릴 수 있다.

하지만 한계도 명확하다.

• 의존성 그래프를 부모가 수동으로 관리해야 한다.
• 에이전트끼리 직접 메시지를 주고받지 못한다.
• 공유 작업표가 없다.
• 파일 잠금이 없으면 충돌 위험이 남는다.

즉, 서브에이전트는 병렬 실행은 주지만 협업 운영 체계까지 주지는 않는다.

패턴 2: Agent Teams는 협업 인프라를 추가한다

두 번째 패턴인 Agent Teams는 바로 이 빈칸을 채운다.
핵심은 에이전트를 더 많이 띄우는 것이 아니다.
에이전트들 사이에 공유 작업표와 규칙을 넣는 것이다.

 

 

Crop 포인트: 가운데 Shared Task List와 좌우의 peer message 연결을 같이 보면, 리드가 모든 메시지를 중계하지 않아도 된다는 점이 바로 생산성 차이를 만든다.

Agent Teams의 본질은 세 가지다.

• 공유 작업표: 각 작업이 pending, in_progress, blocked, completed 상태를 가진다.
• 자동 의존성 해제: 선행 작업이 끝나면 막혀 있던 작업이 자동으로 풀린다.
• 파일 잠금과 피어 메시징: 같은 파일 충돌을 줄이고, 필요한 정보는 동료 에이전트끼리 직접 전달한다.

이 구조가 있으면 테스트 담당 에이전트는 API가 끝날 때까지 blocked 상태로 기다리다가, API 완료와 함께 자동으로 다음 작업을 이어받을 수 있다.
백엔드 담당이 프론트엔드 담당에게 API 계약을 직접 전달할 수도 있다.
중간 리드가 모든 메시지를 중계하지 않아도 되니 병목이 줄어든다.

정리하면 이렇다.

• 서브에이전트 = 병렬 실행 + 수동 조정
• Agent Teams = 병렬 실행 + 구조화된 조정

실무에서 진짜 중요한 건 더 많은 에이전트가 아니다

이 글에서 흥미로운 부분은 "에이전트를 얼마나 많이 띄울 수 있나"보다 "얼마나 안정적으로 굴릴 수 있나"에 더 많은 지면을 쓴다는 점이다.

저자는 대체로 3~5명 정도가 sweet spot이라고 본다.
그 이상은 생성량은 늘어도 리뷰와 검증 비용이 더 빠르게 커진다.

안정화를 위해 제안하는 장치도 실전적이다.

• 반복 횟수 상한 두기
• 재시도 전에 강제 반성 단계 넣기
• 전용 reviewer 에이전트 두기
• 위험한 작업에는 구현 전에 plan approval 넣기

핵심은 간단하다.
에이전트가 빠르게 달리도록 두되, 잘못된 방향으로 오래 달리게 두지는 말라.

규모가 커질수록 도구도 세 층으로 나뉜다

저자는 2026년의 도구 지형을 세 층으로 정리한다.

Tier	성격	적합한 상황
Tier 1	같은 세션 안에서 subagent / team 운영	빠른 실험, 작은 분해
Tier 2	로컬 worktree 기반 오케스트레이션	3~10개 병렬 기능 작업
Tier 3	클라우드 비동기 에이전트	맡기고 떠났다가 나중에 결과 확인

 

 

Crop 포인트: 왼쪽은 diff와 worktree 관리가 중심이고, 오른쪽은 작업 지시와 결과 회수가 중심이라는 점을 비교해서 보면 된다.

이 비교가 보여주는 건 단순한 UI 차이가 아니다.
도구가 전제하는 사용 방식이 다르다.

• 로컬 오케스트레이터는 "옆에서 계속 지켜보며 조정하는" 도구다.
• 클라우드 비동기 에이전트는 "업무를 맡기고 나중에 돌아오는" 도구다.

즉, 오케스트레이션 도구는 기능보다 관여 방식으로 구분하는 편이 이해가 쉽다.

AGENTS.md는 길수록 좋지 않다

이 글은 AGENTS.md를 세션 간 학습이 쌓이는 장치로 다룬다.
그 자체는 중요한 관찰이다.
반복 세션에서 매번 같은 실수를 줄이는 가장 값싼 방법 중 하나이기 때문이다.

다만 여기에는 중요한 맥락이 있다.
이 글에서 연결한 별도 연구에 따르면, 자동 생성된 repository context file은 성공률을 조금 낮추고 비용을 20% 이상 늘릴 수 있다.
반면 사람이 직접 쓴 문맥 파일은 약간의 개선을 줄 수 있지만, 그 역시 길고 장황하면 비용만 늘린다.

그래서 실무적으로는 방향이 분명하다.

좋은 AGENTS.md는 프로젝트 소개문이 아니다.
이미 저장소를 훑으면 알 수 있는 내용을 길게 반복하는 문서도 아니다.
오히려 이런 정보에 가깝다.

• 이 저장소는 uv를 써야 한다.
• 특정 테스트는 캐시 없이 돌려야 한다.
• 어떤 디렉터리는 레거시지만 지우면 안 된다.
• 인증 미들웨어 순서를 바꾸면 깨진다.

즉, AGENTS.md는 사용 설명서가 아니라 지뢰 지도에 가깝다.

병목은 생성이 아니라 검증이다

이 글에서 가장 설득력 있는 문장은 이것이다.
이제 느린 것은 코드 작성이 아니라, 그 코드가 맞는지 증명하는 일이다.

왜 그런가.

• 테스트가 통과해도 중요한 실패 조건을 빠뜨렸을 수 있다.
• AI가 만든 테스트 자체가 빈약할 수 있다.
• 각 에이전트는 로컬 맥락만 보기 때문에 시스템 전체 제약을 놓치기 쉽다.
• 환경이 조금만 불안정해도 많은 에이전트가 동시에 같은 문제에 걸릴 수 있다.

그래서 품질 게이트가 필요하다.

• 구현 전 계획 승인
• 작업 완료 시 자동 훅 실행
• lint, test, security scan
• 사람의 최종 리뷰

여기서 사람의 역할은 줄어들지 않는다.
오히려 판단과 검증 쪽으로 더 응축된다.

Ralph Loop가 주는 힌트

후반부의 Ralph Loop 설명도 인상적이다.
큰 일을 한 번에 끝내려 하지 않고, 작은 원자적 작업 단위로 반복하는 방식이다.

흐름은 단순하다.

1. 다음 작업을 고른다.
2. 구현한다.
3. 검증한다.
4. 통과하면 커밋한다.
5. 컨텍스트를 리셋하고 다음 작업으로 간다.

이 방식이 좋은 이유는 두 가지다.

• 긴 대화가 누적되며 맥락이 흐려지는 문제를 줄인다.
• 기억을 대화창이 아니라 git, progress log, tasks.json, AGENTS.md 같은 외부 구조에 남긴다.

즉, 잘 되는 에이전트는 "기억력이 좋은 에이전트"가 아니라
기억을 외부화한 작업 시스템 안에서 움직이는 에이전트다.

결국 사람이 붙잡아야 하는 것

이 글이 끝까지 강조하는 메시지도 명확하다.

에이전트에게 맡기기 좋은 일:

• 범위가 명확한 구현
• 보일러플레이트
• 마이그레이션
• 테스트 스캐폴딩
• 빠른 탐색과 초안 작성

사람이 끝까지 가져가야 하는 일:

• 아키텍처
• 무엇을 만들지 말아야 하는지에 대한 판단
• 전체 시스템 맥락에서의 리뷰
• 책임과 품질 기준 설정

속도가 빨라질수록 이해를 잃기 쉽다.
그리고 시스템에 대한 이해를 잃는 순간, 확장도 수정도 검증도 어려워진다.

이 글의 핵심을 한 문장으로 요약하면

멀티 에이전트 코딩의 승부처는 모델 자체가 아니라 운영 설계다.

좋은 오케스트레이션은 다음 네 가지를 해낸다.

• 작업을 잘 나눈다.
• 의존성을 잘 드러낸다.
• 검증을 자동화한다.
• 학습을 짧고 정확한 문맥 파일로 축적한다.

반대로 이 네 가지 없이 에이전트 수만 늘리면,
생산성은 잠깐 오르고 복잡성은 오래 남는다.

바로 적용할 체크리스트

• 오늘은 subagent 한 번만 써본다.
• 같은 파일을 두 에이전트가 건드리지 않게 소유권을 먼저 나눈다.
• risky task에는 계획 승인 단계를 넣는다.
• 작업 완료 훅에 테스트와 린트를 묶는다.
• AGENTS.md에는 검색으로 알 수 없는 정보만 남긴다.
• 한 번에 너무 많이 돌리지 말고 3~5개 수준에서 검증 가능 범위를 유지한다.

Source

• Addy Osmani, The Code Agent Orchestra - what makes multi-agent coding work
• Addy Osmani, Orchestrating Coding Agents - O'Reilly CodeCon 2026 slide deck
• Thibaud Gloaguen, Niels Mündler, Mark Müller, Veselin Raychev, Martin Vechev, Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?