20개. 에이전트를 20개 실행한다고 해서 그것이 곧 20개 분량의 작업이 배포되는 것을 의미하지는 않는다. 고속도로 차선을 20개로 늘려도 톨게이트가 하나뿐이라면 결국 모든 차는 그 앞에서 멈춰 서야 하는 것과 같다. 그런데 우리는 그동안 에이전트의 실행 능력, 즉 '얼마나 많이 시킬 수 있는가'에만 집중해 왔다. AI 에이전트를 띄우는 비용은 낮아졌지만, 그들이 쏟아낸 결과물을 검토하고 기존 코드와 병합하는 인간의 주의력은 여전히 한정된 자원이다. Addy Osmani는 이 지점에서 발생하는 병목 현상을 '오케스트레이션 세금'이라 정의한다. 에이전트가 병렬로 움직여도 결국 최종 승인이라는 좁은 문을 통과해야 하는 구조적 한계가 드러나고 있다. 최근 AI 에이전트 도구들이 쏟아지며 누구나 수십 개의 워크플로우를 동시에 가동할 수 있게 됐지만, 역설적으로 인간이 느끼는 피로는 커졌다. 매번 다른 작업 맥락을 다시 불러와야 하는 문맥 전환 비용이 기하급수적으로 증가하기 때문이다. 결국 생산성의 핵심은 에이전트를 얼마나 많이 돌리느냐가 아니라, 인간의 주의력을 어떻게 배치하느냐의 문제로 옮겨가고 있다.

에이전트 20개와 '오케스트레이션 세금'의 구조

개발자가 화면에 20개의 AI 에이전트를 띄우는 일은 클릭 몇 번으로 끝난다. 하지만 에이전트가 쏟아낸 수십 개의 결과물을 일일이 확인하고 정확성을 따지며 기존 코드의 아키텍처와 일관성이 있는지 검토하고 병합 충돌을 해결하는 과정은 여전히 사람의 판단이 필수적이다. 테스트 코드를 작성하거나 화면 캡처를 생성하는 것처럼 기계가 스스로 증명할 수 있는 독립적인 작업은 백그라운드에서 빠르게 처리된다. 그러나 최종적으로 이 결과물들을 하나의 제품으로 합치는 과정은 병렬화되지 않는다. 시스템의 전체 처리 속도는 결국 가장 느린 구간인 인간의 판단 속도에 수렴한다.

애디 오스마니(Addy Osmani)는 여러 작업 흐름을 조율하는 데 드는 이 숨은 비용을 오케스트레이션 세금(Orchestration Tax)이라 정의한다. 이는 사용자의 집중력 문제가 아니라 시스템 설계의 구조적 문제다. 파이썬의 GIL(Global Interpreter Lock, 여러 스레드가 있어도 한 번에 하나만 코드를 실행하게 만드는 장치)처럼 인간의 주의력은 한 번에 하나의 작업만 처리하는 직렬 구성 요소로 작동한다. 에이전트를 20개 실행한다고 해서 개발자가 20명이 되는 것은 아니다. 진짜 이해와 판단이 필요한 순간에는 모든 에이전트의 결과물이 사람의 주의력이라는 하나의 잠금을 얻기 위해 순서대로 대기해야 한다.

생산성의 지표는 이제 에이전트의 실행 수가 아니라 실제로 검토되고 병합되어 배포 가능한 작업량으로 전환된다. 에이전트가 바쁘게 움직이는 상태를 생산적인 상태로 착각하기 쉽지만 실상은 다르다. 인간의 인지 대역폭은 에이전트 수에 비례해 늘어나지 않는다. 에이전트의 작업물을 확인하기 위해 빈번하게 화면을 전환하면 매번 다른 작업 맥락을 다시 불러와야 하므로 인지적 피로가 급격히 커진다. 검토 과정이 얕아지면 에이전트가 만든 코드를 충분히 이해하지 못한 채 그대로 받아들이는 상황이 발생한다. 이 과정에서 나중에 수정하기 어려운 코드상의 기술 부채와 개발자가 시스템을 이해하지 못한 채 변경 사항만 누적하는 인지 부채가 함께 쌓인다.

결국 에이전트의 규모는 도구의 인터페이스가 허용하는 최대치가 아니라 개인이 제대로 리뷰할 수 있는 속도에 맞춰 설정해야 한다. 아키텍처 설계나 복잡한 버그 수정처럼 판단이 핵심인 작업은 처음부터 병렬화하지 않는 것이 효율적이다. 기계가 검증할 수 있는 부분은 에이전트가 테스트나 증거를 먼저 제시하게 하여 사람의 판단 부담을 줄여야 한다. 위임의 핵심은 더 많은 일을 맡기는 능력이 아니라 맡겨도 되는 일과 직접 판단해야 하는 일을 명확히 가르는 능력에 있다. 사람의 주의력을 시스템 내의 제한된 자원으로 보고 그에 맞춰 작업을 배치하는 설계가 필요하다.

파이썬 GIL과 인지 부채: 주의력이라는 단일 잠금

에이전트는 병렬로 실행되지만 인간의 검토는 직렬로 이뤄진다. 파이썬의 GIL(Global Interpreter Lock, 전역 인터프리터 잠금)은 여러 스레드가 존재해도 한 번에 하나의 스레드만 파이썬 바이트코드를 실행하도록 제한하는 장치다. AI 에이전트 시스템에서도 이와 같은 잠금 현상이 발생한다. 에이전트 20개를 동시에 가동해 결과물을 쏟아내도, 이를 이해하고 병합하는 판단 과정은 결국 한 사람의 주의력이라는 단일 통로를 지나야 한다. 성능 공학의 원리에 따르면 병렬 처리의 속도 향상은 병렬화되지 않는 부분에 의해 제한된다. 인간이 시스템 내에서 가장 느린 직렬 구성 요소로 작동하며 전체 처리량을 결정하는 병목이 된다.

개발자가 시스템을 완전히 이해하지 못한 채 변경 사항을 누적하면 인지 부채가 쌓인다. 이는 나중에 수정하기 어려운 코드 자체의 결함인 기술 부채와는 다른 개념이다. 에이전트가 생성한 코드를 충분히 검토하지 않고 얕게 받아들이는 상황이 반복될 때 인지 부채는 급격히 증가한다. 기술 부채가 코드의 물리적 엉킴이라면 인지 부채는 개발자의 머릿속에서 시스템 지도가 사라지는 상태다. 두 가지 부채가 동시에 누적되면 개발자는 자신이 만든 시스템의 동작 원리를 파악하지 못한 채 변경 사항만 계속 얹게 된다. 주의력이라는 자원이 부족한 상태에서 무리하게 에이전트 수를 늘리는 행위는 결국 시스템 제어권을 상실하는 위험으로 이어진다.

작업 성격에 따라 위임 범위를 분리하는 전략이 필요하다. 테스트 코드 작성이나 화면 캡처 생성처럼 기계가 스스로 증명할 수 있는 작업은 백그라운드 에이전트에 맡긴다. 반면 아키텍처 설계나 복잡한 버그 수정처럼 인간의 판단이 핵심인 작업은 병렬화하지 않고 직접 수행한다. 에이전트의 규모를 도구가 허용하는 최대치가 아니라 개발자가 실제로 리뷰할 수 있는 속도에 맞춘다. 주의력을 판단에 집중시키고 기계적 검증은 에이전트가 테스트 결과나 증거로 먼저 보여주게 만드는 방식이다. 위임의 핵심은 얼마나 많은 일을 맡기느냐가 아니라, 맡겨도 되는 일과 직접 판단해야 하는 일을 가르는 기준을 세우는 능력에 있다.

에이전트 수를 20개까지 확장해도 생산성이 정체되는 결과는 단순한 성능 부족의 문제가 아니다. 개별 AI의 역량보다 이들을 관리하고 연결하는 오케스트레이션 세금이 임계점을 넘어서며 효율을 갉아먹는 구조적 병목이 발생했기 때문이다.

단순히 에이전트 숫자를 늘려 과업을 분담하는 방식은 조율 비용의 기하급수적 증가라는 한계에 부딪힌다. 이제 AI 도입의 성패는 투입 규모의 확장이 아니라 조율 비용을 얼마나 낮추느냐에 달려 있다.