The Orchestration Tax

3줄 요약

1. Addy Osmani가 2026년 Google I/O 패널(함께한 패널리스트: Richard Seroter, Aja Hammerly, Ciera Jaspan) 뒤에 정리한 X Article. 다중 AI 에이전트 워크플로우에서 인간이 치르는 비가시적 비용을 오케스트레이션 세금(orchestration tax) 이라 명명한다.
2. 에이전트를 시작하는 비용은 거의 0이지만 결과를 검토·병합하는 작업은 직렬이며 그 직렬 자원은 정확히 한 명, 본인 자신이다. Python GIL과 암달의 법칙 비유로, 에이전트를 늘려도 판단 속도가 빨라지지 않으며 병목 앞에 쌓이는 대기열만 길어진다는 점을 짚는다.
3. 처방은 의지가 아니라 아키텍처에서 온다 — 함대 규모는 UI가 아니라 검토 속도에 맞추고, 작업을 직렬·병렬로 분류하고, 리뷰를 배치하고, 검증 가능한 80%는 기계에 떠넘기고, 직렬 시간을 보호하라.

이 글의 정체

• 저자: Addy Osmani (Google Chrome 엔지니어링 리드)
• 형식: X(트위터) 장문 포스트(X Article)
• 시점: 2026년 Google I/O 직후 게시
• 출발점: 패널 끝에 Richard Seroter가 “당신이 오케스트레이션 세금 이라 부른 그것"이라고 명명한 개념을, Osmani가 본격적으로 풀어 쓴 글
• 메인 주장: 다중 에이전트의 실패 모드는 규율 문제가 아니라 아키텍처 문제 다

비대칭 — 사람들이 가격을 매기지 않는 것

에이전트 워크플로우에는 사람들이 가격을 매기지 않는 비대칭이 있다.

에이전트를 시작하는 비용은 매우 싸다. 키 한 번, 문장 하나면 된다. 그러나 에이전트의 루프를 닫는 비용은 전혀 싸지 않다. 누군가는 결과가 올바른지 확인해야 하고, 다른 에이전트들이 건드린 부분과 화해시켜야 한다. 그 누군가는 당신이다. 그리고 당신은 정확히 한 명이다.

Osmani는 같은 문제의 다른 단면을 이전 글 “Your parallel Agent limit"에서 다룬 적이 있다고 밝힌다 — 그 글이 조용히 실패하고 있을 한 줄기 병렬 스레드에 대한 주변광 같은 불안 에 관한 것이었다면, 이번 글은 그 비용의 형태 아래에 있는 구조 에 관한 것이다.

에이전트 개발을 동시성 시스템으로 보기 시작하면, 인간은 그 시스템 안의 한 컴포넌트일 뿐이라는 것을 깨닫게 된다. 느린, 직렬 컴포넌트.

당신은 단일 스레드 자원이다

Osmani는 동시성 코드를 짜본 사람이라면 직관을 이미 갖고 있을 것이라며 두 가지 비유를 든다.

비유 1: Python GIL. Python에서 스레드는 얼마든지 띄울 수 있지만, 파이썬 바이트코드를 실행하려면 한 번에 한 스레드만 GIL을 잡을 수 있다. 당신은 AI 에이전트들의 GIL이다. 에이전트들은 모두 동시에 돌 수 있다. 그러나 그들의 작업이 아키텍처에 대한 진짜 이해 나 머지 충돌 해결 을 요구하는 순간, 그 작업은 락을 획득해야 한다. 락은 하나다. 그것을 잡고 있는 것이 당신이다.

비유 2: 암달의 법칙(Amdahl’s Law). 병렬화로 얻는 속도 향상은 직렬로 남아 있는 부분의 비율 에 의해 상한이 정해진다.

파이프라인의 큰 덩어리가 병렬화될 수 없다면, 코어를 아무리 던져도 단단한 상한에 부딪힌다. 에이전트 개발에서 직렬 비율은 판단 이다. 8개 에이전트를 띄운다고 당신의 판단 시간이 줄어들지는 않는다. 판단 단계로 들어가는 대기열만 훨씬 깊어진다.

이로부터 따라오는 오래된 성능 공학의 사실:

비병목 부분을 최적화해도 처리량은 늘지 않는다. 병목 앞에 쌓이는 미완료 작업의 산만 키울 뿐이다.

에이전트를 추가하는 것은 애초에 제약이 아니었던 부분 을 최적화하는 행위다. 제약은 검토 단계이고, 시스템 전체 처리량은 정확히 그 단계의 처리량과 같다. 오케스트레이션 세금이란 에이전트의 생산량과 실제로 머지할 수 있는 양 사이의 구조적 격차다.

갈아 넣는 것으로는 구조적 한계가 풀리지 않는다

Osmani는 패널에서 “도구 덕분에 이렇게까지 생산적이라고 느낀 적이 없지만, 또 이렇게까지 지친 적도 없다"고 말했다고 적는다. 두 절반은 같은 원인을 공유한다.

피로의 정체는 컨텍스트 스위치 비용이다. CPU도 같은 비용을 치르지만 단위가 마이크로초이고, 그래도 아키텍트들은 이걸 피하려 애쓴다. 인간은 분 단위로 치르며, 한 번도 같은 컨텍스트로 완벽히 돌아오지 못한다.

5개의 에이전트는 1배 작업을 다섯 번 한 것이 아니다. 다섯 번의 콜드 리로드에, 어느 에이전트를 다음에 봐야 할지 끊임없이 걱정하는 백그라운드 뇌 프로세스를 더한 것이다.

구조적 한계는 노력으로 풀 수 없으며, 세금은 어떻게든 지불된다. 갈아 넣으려 할 때 한계는 얕은 코드 리뷰 또는 인지적 항복(cognitive surrender) 으로 모습을 드러낸다 — 자기 의견을 형성할 주의력이 더 이상 남아 있지 않아 그냥 에이전트 코드를 받아들이게 되는 상태. 둘 중 하나다. 세금을 의도적으로 내거나, 시스템이 조용히 당신 코드베이스에 대한 이해를 무너뜨리거나.

주의를 아키텍트하라 — 다섯 가지 처방

Osmani가 실제로 효과 봤다고 적은 다섯 가지.

1. 함대 규모는 UI가 아니라 리뷰 속도에 맞춘다

좋은 동시성 시스템은 백프레셔(backpressure)를 쓴다 — 큐가 무한히 자라지 않도록 생산자가 소비자 속도에 맞춘다. 에이전트 수가 생산자이고, 검토 속도가 소비자다.

병렬 에이전트의 올바른 수는 제대로 코드 리뷰할 수 있는 수 다. 우리 대부분에게 그것은 낮은 한 자릿수 다. AI 도구는 기꺼이 당신이 20개를 띄우게 해 주겠지만, 그것은 UI 기능에 불과하다.

2. 작업을 분류한다

두 더미를 따로 둔다.

가장 큰 실수는 두 번째 더미를 병렬화하려는 것이다. 복잡한 작업을 여러 개 동시에 해도 출력이 늘지 않는다. 락만 흔들리고 결과는 모두 나빠진다.

3. 리뷰를 배치한다

컨텍스트 스위치 비용은 매번 비싸다. 한 자리에서 4개 에이전트를 같이 검토하는 것이, 하나 보고 다른 일 하다가 차갑게 돌아오는 것보다 훨씬 싸다. 에이전트에게 긴 줄을 줘서, 일이 좀 쌓이게 두고, 배치로 처리하라.

4. 락은 오직 판단에만 쓴다

뇌를 기계가 스스로 검증할 수 있는 것 에 낭비하지 않는다. 에이전트에게 통과하는 테스트를 작성하게 하거나 스크린샷을 생성하게 한다. 지루한 80%는 에이전트가 스스로 증명할 수 있으므로, 희소한 주의력은 진짜 인간이 필요한 20% 에만 쓴다.

5. 직렬 시간을 보호한다

병목은 당신의 가장 좋은 시간 을 필요로 하지, 에이전트 체크인 사이의 자투리 시간이 아니다.

때로 가장 큰 레버리지는 오케스트레이션을 완전히 멈추는 것이다. 에이전트가 가득한 노트북을 닫고, 한 가지 문제에 대해 락을 끝까지 잡고 깊이 생각하는 것. 오케스트레이션은 진짜 일이 아니다. 일 주변의 오버헤드다.

패널에서 Aja Hammerly는 아키텍처가 지금 가장 시급한 스킬 이라고 짚었다고 한다 — 무엇이 한 에이전트 안에 들어갈 일이고 무엇이 너무 큰지 아는 능력. 여기에 Osmani가 더하는 한 줄:

당신은 그 시스템 안의 한 컴포넌트다. 당신의 주의력은 알려진, 낮은 직렬 처리량을 가진다. 시스템은 그 수치를 존중하거나, 조용히 당신의 기준을 낮춤으로써 그 수치를 우회한다.

바쁨 vs 생산성 — 안에서는 분간이 안 된다

이 글의 가장 무거운 부분은 실패 모드가 본인 눈에 보이지 않는다 는 지적이다.

20개의 에이전트가 돌면 어마어마한 생산성처럼 느껴진다. 대시보드는 가득 차 있고 모든 것이 움직인다. 그러나 그 느낌은 실제로 main에 좋은 코드를 머지하는 것 과 분리되어 있다. 당신은 최대로 바쁘면서도 거의 아무것도 만들지 못할 수 있다. 안에서는 같게 느껴진다.

Ciera Jaspan은 Margaret-Anne Storey의 부채(debt) 연구를 끌어왔다고 한다. 기술 부채와 인지 부채에 관한 것. 지불되지 않은 오케스트레이션 세금은 둘을 동시에 누적하는 방식이다.

• 잘 읽지 않은 코드를 머지한다
• 코드베이스에 대한 멘탈 모델이 완전히 낡는다
• 오늘 대시보드에는 아무것도 나타나지 않는다
• 프로덕션이 깨졌을 때, 시스템을 들여다보면서 “내가 이걸 어떻게 동작시키는지 더 이상 모르겠다"는 순간에 비로소 드러난다

가장 흥미로운 지점

이 글의 진짜 매서운 한 줄은 오케스트레이션 세금을 내지 않으면 시스템이 알아서 당신의 기준을 낮춰 우회한다 는 통찰이다. 즉 직렬 자원의 한계를 인정하지 않으면 시스템은 한계를 사라지게 만들지 않고, 품질을 사라지게 만든다. 이것은 단순한 시간 관리 격언이 아니라, 동시성 시스템 설계에서 백프레셔가 없는 곳에서는 데이터 손실·정확성 저하가 조용히 일어난다는 사실의 직접적 사례다.

또 하나 — 바쁨과 생산성의 분리 는 AI 에이전트가 등장하면서 갑자기 생긴 문제가 아니다. 카프카 컨슈머가 처리 못 한 메시지가 큐에 쌓이는 그래프를 본 적이 있다면 같은 그림이다. 다만 이번에 컨슈머가 나 자신 일 뿐이며, 본인을 모니터링하는 대시보드는 없다.

마지막 문장이 이 글의 정본이다:

에이전트를 띄우는 것은 스킬이 아니다. 누구나 20개를 띄울 수 있다. 진짜 스킬은 복제할 수도 병렬화할 수도 없는 하나의 직렬 자원을 중심으로 시스템을 설계하는 것 이다. 그 자원은 당신의 주의력이다. 프로덕션에서 의존하는 다른 모든 것처럼 아키텍트하라.

출처

저자: Addy Osmani (Google Chrome) 형식: X Article 패널 출처: Google I/O — Richard Seroter, Aja Hammerly, Ciera Jaspan과의 공동 패널 원문: https://x.com/addyosmani/status/2059844244907696186