이 글의 배경
Google의 Addy Osmani가 2026년 5월 발표한 글 "The Orchestration Tax(오케스트레이션 세금)"(Google I/O 패널 토론에서 출발)를 사례로 삼습니다. 에이전트 팀 협업 맥락에서, "에이전트를 많이 띄우는 것"과 "실제로 일이 끝나는 것"이 왜 다른지, 그리고 Hermes의 팀 구조가 이를 어떻게 다루는지 함께 봅니다.
1. 흔한 착각: "에이전트 = 또 다른 나"
에이전트를 더 띄우는 일은 이제 너무 쉽습니다. 키 한 번, 한 문장 프롬프트면 됩니다. 그래서 20개를 동시에 돌리면 굉장히 생산적인 느낌이 듭니다. 대시보드가 꽉 차고, 모든 게 움직이니까요.
그런데 Osmani의 지적은 단순하고 날카롭습니다.
여러 에이전트를 돌린다고 '내'가 더 많아지는 것은 아니다.
에이전트를 시작하는 비용은 거의 0이지만, 그 결과 가 맞는지 확인하고 다른 작업과 합치는(병합) 판단은 전혀 싸지 않습니다. 그리고 그 판단을 내릴 사람은 결국 나 하나뿐입니다.
2. 핵심 비유: 당신은 시스템의 'GIL'이다
프로그래밍을 해보신 분께 가장 와닿는 비유입니다.
Python에는 GIL(Global Interpreter Lock)이 있습니다. 스레드를 아무리 많이 띄워도, 락을 쥔 하나만 실제로 실행됩니다.
다중 에이전트 운영에서 그 락을 쥔 사람이 바로 '나'입니다. 에이전트는 동시에 다 돌 수 있지만, 진짜 이해가 필요한 판단·충돌 해결은 전부 내 차례를 기다려야 합니다.
여기에 암달의 법칙(Amdahl's Law)이 더해집니다. 병렬화로 얻는 속도 향상은 직렬로 남는 부분의 비율에 의해 한계가 정해집니다. 에이전트 개발에서 직렬로 남는 부분은 판단(리뷰)입니다.
에이전트를 8개 띄워도 내 판단 속도는 빨라지지 않습니다. 판단 앞에 쌓인 대기열만 깊어질 뿐입니다.
이것이 오케스트레이션 세금입니다 — 에이전트가 만들어내는 양과 내가 실제로 검토·병합할 수 있는 양 사이의 구조적 간극.
3. "더 열심히"로는 안 풀린다
이건 의지나 규율의 문제가 아니라 구조(아키텍처)의 문제입니다. 갈아넣어 버티면 세금은 두 가지 모습으로 청구됩니다.
얕아지는 리뷰: 제대로 안 읽고 병합.
인지적 항복(cognitive surrender): 내 의견을 세울 주의력이 없어, 에이전트가 준 결과를 그냥 받아들임.
당장은 대시보드에 아무 문제도 안 보입니다. 문제는 운영이 터졌을 때, 내가 만든 시스템을 더 이상 이해하지 못한다는 사실로 드러납니다(기술 부채 + 인지 부채의 동시 누적).
4. 해법: 주의력을 '설계'하라
Osmani가 제시한 실천 원칙을, 스터디에서 바로 쓸 수 있는 형태로 정리하면:
함대 규모를 UI가 아니라 '리뷰 속도'에 맞춘다. 동시성 시스템의 배압(backpressure)처럼, 내가 제대로 검토할 수 있는 수만큼만 돌린다(보통 한 자릿수).
작업을 두 더미로 나눈다. ① 위임해도 되는 고립 작업(비동기, 마지막 관문만 확인) ② 판단 자체가 일인 복잡 작업. ②는 절대 병렬화하지 않는다.
리뷰를 배치로 묶는다. 하나씩 확인하며 컨텍스트를 식혔다 데우는 것보다, 한자리에서 여러 개를 몰아 보는 편이 훨씬 싸다.
락(=내 판단)은 판단에만 쓴다. 테스트 통과·스크린샷처럼 기계가 스스로 증명할 수 있는 80%는 에이전트에게 맡기고, 인간은 진짜 판단이 필요한 20%에 집중한다.
직렬 시간을 보호한다. 병목에는 자투리 시간이 아니라 가장 좋은 시간이 필요하다.
5. Hermes 관점 — 이미 '팀 구조'가 해법이다
이 글이 GPTERS 스터디에 의미 있는 이유는, Hermes의 leader-agent(오케스트레이터) + 역할별 전문 에이전트 구조가 바로 이 '오케스트레이션 세금'을 구조적으로 줄이는 설계이기 때문입니다.
오케스트레이터는 실행 자원이 아니라 '분배·판단' 역할입니다. 즉 직렬 락(주의력)을 지키는 자리입니다. 잡무까지 직접 처리하면 그 자리가 병목이 됩니다.
전문 에이전트(예: PKM / Dev / Ops)로 작업을 위임하는 것은, 위 4번 원칙(고립 작업 위임)과 정확히 같습니다.
Kanban으로 다단계 작업을 분해·체크포인트화하는 것은, 5번(직렬 시간 보호)과 3번(배치 리뷰)을 자동화하는 장치입니다.
핵심 교훈: 에이전트를 늘리는 것 자체는 기술이 아니다. 진짜 기술은 복제할 수 없는 단 하나의 직렬 자원(내 판단)을 중심으로 팀을 설계하는 것입니다.
6. 도식 — 오케스트레이션 세금이 발생하는 지점
[에이전트1] ─┐
[에이전트2] ─┤
[에이전트3] ─┼──▶ ( 단일 직렬 락 = 나의 판단/리뷰 ) ──▶ [병합/출시]
[에이전트4] ─┤ ▲
... ─┘ └─ 병목. 여기 처리량이 곧 시스템 처리량.
에이전트를 늘려도 이 폭은 안 넓어짐 → 대기열만 증가(= 세금)
해법: 생산자(에이전트 수)를 소비자(리뷰 속도)에 맞춰 배압 적용
+ 판단 필요 작업은 병렬화 금지 + 리뷰는 배치로
7. 스터디 토의용 질문
내가 지금 "바쁘다"고 느끼는 것 중, 실제 출시된 결과로 이어진 비율은?
내 작업 중 '위임 가능한 고립 작업'과 '판단이 곧 일인 작업'을 어떻게 나눌 수 있을까?
Hermes에서 오케스트레이터가 직접 잡무를 처리해 병목이 된 경험이 있는가? 어떤 역할을 전문 에이전트로 떼어낼 수 있을까?
원문 한 문장
"에이전트를 띄우는 것은 기술이 아니다. 누구나 20개를 돌릴 수 있다. 진짜 기술은 복제하거나 병렬화할 수 없는 단 하나의 직렬 자원 — 당신의 주의력 — 을 중심으로 시스템을 설계하는 것이다." — Addy Osmani, The Orchestration Tax
