원본: GeekNews — The Orchestration Tax (AI 에이전트 시대의 오케스트레이션 세금)
한 줄 요약: 에이전트는 병렬로 실행되지만 결과를 검토하고 판단하는 사람의 주의력은 직렬이라, 에이전트를 늘려도 생산성이 비례해서 오르지 않는다.
---
에이전트를 4개로 늘렸는데 더 바빠졌습니다
클립납치단은 실제로 멀티에이전트 시스템을 운영합니다.
PD, 리서처, 작가, 캡컷 에이전트가 각자 역할을 맡고 디스코드 채널로 연결됩니다. 처음에 이 시스템을 설계할 때는 "에이전트들이 각자 돌아가면 내가 할 일이 줄겠지"라고 생각했습니다.
실제는 달랐습니다.
에이전트가 각자 작업을 진행하면, 그 결과를 검토하고 다음 지시를 내리는 게 내 몫이 됩니다. 에이전트가 4개이면 검토할 것도 4배입니다. Addy Osmani의 글이 "오케스트레이션 세금"이라고 부르는 문제가 정확히 이겁니다.
---
에이전트를 늘려도 생산성이 안 오르는 이유
혹시 이런 경험 있으신가요?
Claude Code에 여러 작업을 동시에 맡겼는데, 결과를 확인할 때마다 "이게 뭘 한 건지" 다시 맥락을 불러오는 데 시간이 걸립니다. 작업은 병렬로 돌아가고 있는데 정작 자신은 더 바빠진 느낌입니다.
이 글의 핵심 통찰은 파이썬 GIL에 비유입니다. 여러 스레드가 있어도 한 번에 하나만 실행하게 만드는 잠금. 에이전트는 동시에 돌지만, 진짜 이해와 판단이 필요한 순간에는 모두 사람의 주의력이라는 하나의 잠금을 기다립니다.
이 병목을 제대로 관리하지 않으면 두 가지가 동시에 쌓입니다. 기술 부채와 인지 부채. 코드 품질 문제와 "내가 이 시스템을 얼마나 이해하고 있나"의 문제가 함께 커집니다.
핵심 스킬 1: 에이전트 규모는 내가 검토할 수 있는 속도로 맞춘다
10개를 동시에 띄울 수 있다고 10개를 돌릴 필요가 없습니다. 검토 주기를 먼저 정하고, 그 시간 안에 제대로 볼 수 있는 만큼만 병렬로 실행합니다.
핵심 스킬 2: 작업을 분류한다 — 자동화 가능한 것과 판단이 필요한 것
테스트 작성, 포맷 변환, 문서 생성 같이 기계가 검증할 수 있는 작업은 백그라운드 에이전트에 맡깁니다. 아키텍처 결정, 버그의 근본 원인 파악, 방향 설정은 병렬화하지 않습니다. 이 구분이 없으면 에이전트가 만든 결과를 충분히 이해하지 않은 채 받아들이게 됩니다.
핵심 스킬 3: 검토를 묶어서 처리한다
에이전트 결과가 나올 때마다 바로 확인하면 맥락 전환 비용이 계속 쌓입니다. 일정 시간 후에 한꺼번에 검토하면 전환 비용을 줄일 수 있습니다.
---
클립납치단 멀티에이전트 시스템에서 실제로 적용한 것
이 문제를 직접 겪고 나서 시스템을 바꿨습니다.
에이전트마다 "자율 처리 가능한 것"과 "반드시 승인이 필요한 것"을 명확히 구분했습니다. 예를 들어 작가 에이전트가 초안을 쓰는 것은 자율 처리입니다. 하지만 발행 전 최종 검토나 방향 전환은 반드시 한 사람이 확인하게 했습니다.
그리고 에이전트 간 라우팅을 구조화했습니다. PD를 거치지 않으면 작업이 시작되지 않는 구조. 각 에이전트의 결과가 PD라는 단일 지점을 통해 흐르도록 했습니다. 병렬 처리와 직렬 판단을 섞어서 설계한 것입니다.
"더 많이 맡기는 능력보다, 맡겨도 되는 일과 직접 판단해야 하는 일을 가르는 능력이 중요하다"는 말이 이 시스템을 운영하면서 가장 크게 와닿은 문장입니다.
에이전트 수를 늘리는 것보다 검토 루프를 설계하는 것이 먼저입니다.