원문 제목: The Orchestration Tax

원문 저자: Addy Osmani

편역: Peggy

편집자 주: AI 에이전트가 점점 더 저렴해지고 호출이 쉬워지면서, 소프트웨어 개발은 새로운 단계에 접어들고 있습니다. 문제는 더 많은 에이전트를 실행할 수 있는지 여부가 아니라, 인간이 그 결과물을 관리하고 판단하며 통합할 충분한 주의력을 가지고 있는지입니다.

이 글은 매우 통찰력 있는 개념인 '오케스트레이션 세금'을 제시합니다. 에이전트를 실행하는 비용은 낮습니다. 단 한 줄의 프롬프트나 한 번의 클릭만 있으면 됩니다. 하지만 진정으로 비용이 많이 드는 것은 후속 단계입니다. 결과가 올바른지 확인하고, 시스템 아키텍처에 미치는 영향을 이해하며, 서로 다른 에이전트 간의 충돌을 처리하고, 최종적으로 어떤 코드가 메인 브랜치에 병합될지 결정하는 작업입니다. 이러한 작업은 단순히 병렬화할 수 없으며, 여전히 하나의 직렬 리소스, 즉 인간의 판단력으로 돌아가야 합니다.

저자는 개발자를 AI 에이전트 시스템의 'GIL'에 비유합니다. 즉, 동시성 시스템의 최종 처리량을 제한하는 단일 스레드 잠금 장치입니다. 여러 에이전트가 동시에 실행될 수 있지만, 아키텍처 판단, 코드 리뷰, 충돌 병합 단계에 들어서면 반드시 개발자의 두뇌를 다시 거쳐야 합니다. 따라서 에이전트가 많다고 해서 반드시 생산성이 높아지는 것은 아니며, 단지 검토해야 할 작업 큐가 길어져 개발자가 더 빈번한 컨텍스트 스위칭과 인지 피로에 빠지게 할 수도 있습니다.

이것이 현재 AI 코딩 도구 열풍에서 간과되기 쉬운 점입니다. 효율성 감각과 실제 생산성이 항상 일치하는 것은 아닙니다. 화면 가득 에이전트 대시보드가 실행되면 '고생산성'이라는 착각을 불러일으킬 수 있습니다. 하지만 개발자가 이러한 변경 사항을 실제로 이해하고 검토하며 통합하지 않는다면, 시스템에 축적되는 것은 생산성이 아니라 기술 부채와 인지 부채일 수 있습니다.

따라서 이 글의 진정한 논의는 '더 많은 에이전트를 사용하는 방법'이 아니라 '인간의 주의력을 중심으로 워크플로를 재설계하는 방법'입니다. 에이전트 시대에 핵심 역량은 단순히 질문하고 작업을 할당하는 것이 아니라, 어떤 작업을 기계에 병렬 처리로 맡기고 어떤 작업을 인간의 판단에 유보해야 하는지, 언제 배치 리뷰를 수행하고 언제 오케스트레이션을 중단하고 하나의 핵심 문제에 다시 집중해야 하는지를 아는 것입니다.

AI는 소프트웨어 생산의 동시성 능력을 확장하고 있지만, 인간의 주의력은 여전히 시스템에서 가장 희소하고 복제할 수 없는 리소스입니다. 진정으로 성숙한 에이전트 워크플로는 모든 작업을 기계에 던지는 것이 아니라, 생산 시스템을 설계하듯 자신의 주의력 아키텍처를 신중하게 설계하는 것입니다.

이제 더 많은 AI 에이전트를 실행하는 것은 매우 쉬워졌습니다. 하지만 더 많은 에이전트가 동시에 실행된다고 해서 '당신'이 더 많아지는 것은 아닙니다. 당신의 인지 대역폭은 병렬화될 수 없습니다. 에이전트를 실제로 안내하고, 결과를 판단하며, 수정 사항을 통합하는 모든 판단력은 결국 동일한 직렬 프로세서, 즉 당신 자신을 통과해야 합니다.

소위 '오케스트레이션 세금'이란 본질적으로 이를 잊었을 때 치르는 대가입니다. 유일한 진정한 해결책은 동시성 시스템을 설계하듯이 당신의 주의력을 설계하기 시작하는 것입니다.

저는 이전에 Google I/O에서 Richard Seroter, Aja Hammerly, Ciera Jaspan과 함께 소프트웨어 엔지니어링의 현재 모습과 앞으로 어떻게 진화할지에 대해 논의하는 원탁 토론에 참여했습니다. 마무리 단계에서 Richard가 물었습니다: 개발자들이 이 이야기를 듣고 가장 가져가서 바꿔야 할 한 가지는 무엇일까요?

저는 몇 달 동안 계속 생각해온 한 가지를 말했습니다: 스스로 바쁘다고 느끼는 것이 실제 생산성과 결코 같지 않다는 점입니다. 20개의 에이전트를 동시에 실행하고 엄청 바쁘다고 느낄 수 있습니다. 하지만 그것이 20개의 에이전트에 해당하는 작업량을 전달했다는 의미는 아닙니다.

그 대화 초반에 Richard는 이 문제에 이름을 붙였습니다. 그는 말했습니다: "방금 말씀하신 것이 바로 오케스트레이션 세금입니다. 당신은 머릿속에서 20개의 에이전트를 성공적으로 관리할 수 없습니다."

그의 말은 완전히 옳았습니다. 저는 이 개념을 더 완전히 풀어서 설명하고 싶습니다. 이것은 자기 훈련의 문제가 아니라 아키텍처의 문제이기 때문입니다.

그 원탁 토론에서 제가 거의 즉흥적으로 내뱉은 한 문장이 계속 제 머릿속에 맴돌았습니다: 여러 에이전트를 실행한다고 해서 세상에 당신이 하나 더 생기는 것은 아닙니다.

사람들이 계산하지 않는 비대칭성

에이전트 워크플로우에는 숨겨진 비대칭성이 존재합니다.

에이전트를 시작하는 것은 매우 저렴합니다. 키보드를 한 번 두드리거나 프롬프트 한 줄을 작성하면 됩니다. 하지만 에이전트의 루프를 완료하는 것은 결코 저렴하지 않습니다. 누군가는 반환된 결과가 올바른지 확인하고, 다른 에이전트가 수정한 내용과 다시 조정해야 합니다.

그 사람이 바로 당신입니다. 그리고 당신은 단 한 명뿐입니다.

지난달 저는 《당신의 병렬 에이전트 상한선》에서 이 문제의 일부를 다뤘습니다. 주로 어떤 병렬 스레드가 조용히 실패하고 있는지 알 수 없는 환경적 불안감에 대해 논의했습니다. 이 글은 그러한 비용 뒤에 숨은 구조에 대해 이야기하고자 합니다.

Agent 개발을 동시성 시스템으로 보기 시작하면, 인간 자체가 그 시스템의 한 구성 요소에 불과하다는 사실을 깨닫게 됩니다. 아주 느린 직렬 구성 요소 말이죠.

당신이 바로 그 단일 스레드 리소스입니다

동시성 코드를 작성해본 적이 있다면, 이 문제를 이해하는 직관은 이미 가지고 있을 겁니다. 다만 그 직관을 엉뚱한 곳에 사용해왔을 뿐입니다.

Python에는 GIL(Global Interpreter Lock)이 있습니다. 원하는 만큼 많은 스레드를 생성할 수 있지만, 한 번에 하나의 스레드만 Python 바이트코드를 실행할 수 있습니다. 모두가 이 잠금을 먼저 획득해야 하기 때문입니다.

당신은 당신의 AI Agent의 GIL입니다.

Agent들은 모두 동시에 실행될 수 있습니다. 하지만 시스템 아키텍처를 진정으로 이해하거나 병합 충돌을 해결해야 하는 작업이 있다면, 반드시 이 잠금을 먼저 획득해야 합니다. 그리고 이 잠금은 단 하나뿐이며, 당신이 쥐고 있습니다.

Amdahl의 법칙은 이를 매우 정확하게 설명합니다: 병렬화로 인한 속도 향상의 한계는 여전히 직렬로 완료되어야 하는 작업 부분에 달려 있습니다. 프로세스에서 병렬화할 수 없는 부분이 크다면, 아무리 많은 코어를 투입해도 결국 단단한 상한선에 부딪히게 됩니다.

Agent 개발에서 이 직렬 부분은 바로 판단력입니다.

8개의 Agent를 실행한다고 해서 판단 시간이 빨라지지는 않습니다. 단지 당신이 처리하기를 기다리는 대기열만 길어질 뿐입니다.

이는 성능 공학에서 아주 오래된 사실이지만, 여전히 많은 사람들이 놀라워합니다: 병목이 아닌 부분을 최적화해도 전체 처리량은 향상되지 않습니다. 단지 병목 앞에 아직 완료되지 않은 작업만 더 쌓일 뿐입니다.

Agent를 추가하는 것은 원래 제약 조건이 아닌 부분을 최적화하는 것입니다. 진정한 제약 조건은 리뷰 단계이며, 전체 시스템의 처리량은 바로 이 단계의 처리량과 정확히 같습니다.

오케스트레이션 세금(Orchestration Tax)이란, Agent의 생산 능력과 당신이 실제로 병합할 수 있는 것 사이의 구조적 격차입니다. 이는 단일 스레드 리소스로 동시성 시스템을 관리하려고 할 때 발생합니다.

억지로 버틴다고 구조적 한계가 해결되지는 않습니다

그 원탁 토론에서 제가 이런 말을 한 적이 있습니다: 제 도구가 이렇게 효율적이라고 느낀 적은 없었지만, 이렇게 지친 적도 없었습니다.

이 두 감정은 모두 완전히 진실하며, 같은 원인에서 비롯됩니다.

이 피로감에는 매우 구체적인 원인이 있습니다: 바로 직렬 프로세서를 지속적으로 100%로 압박하고, 어떤 여유도 주지 않을 때 느껴지는 감정입니다.

당신이 이미 주의 범위를 벗어난 Agent를 다시 확인할 때마다 컨텍스트 전환 비용을 지불해야 합니다. 뇌를 비우고 처음부터 다른 컨텍스트를 다시 로드해야 합니다.

CPU는 마이크로초 단위로 이 작업을 수행할 수 있지만, 그럼에도 아키텍트는 잦은 전환을 피하려고 합니다. 반면 당신은 몇 분이 걸리며, 컨텍스트를 완벽하게 복원할 수 없습니다.

5개의 Agent는 1배의 작업량을 5번 반복하는 것이 아닙니다. 이는 5번의 콜드 스타트 방식 컨텍스트 재로드와 함께, 백그라운드에서 지금 어떤 Agent를 확인해야 할지 끊임없이 고민하는 뇌 프로세스가 추가된 것입니다.

구조적 한계를 '더 열심히' 한다고 해결할 수 없습니다. 이 세금은 항상 내야 합니다.

억지로 버티려 하면 결국 다른 형태로 나타납니다. 코드 리뷰가 점점 얕아지거나, '인지적 항복' 상태에 빠져 자신의 판단을 내리는 데 너무 많은 주의력이 소모되니 Agent가 작성한 코드를 그냥 받아들이게 됩니다.

당신은 이 세금을 능동적으로 내거나, 아니면 어둠 속에서 시스템에 대한 이해가 서서히 무너지는 것을 방치해야 합니다.

시스템을 설계하듯 주의력을 설계하라

따라서 당신은 자신의 주의력을 희소한 직렬 자원으로 대우해야 합니다.

분산 시스템을 설계할 때 병목 현상을 전혀 고려하지 않지는 않을 것입니다. 그렇다면 당신의 뇌에도 동일한 존중을 주십시오.

다음은 저에게 실제로 효과가 있었던 방법들입니다:

UI 능력이 아닌 리뷰 능력에 따라 Agent 팀을 확장하라.

좋은 동시성 시스템은 백프레셔 메커니즘을 사용해 큐가 무한히 증가하는 것을 방지합니다. 생산자는 소비자의 처리 능력에 맞춰 속도를 늦춥니다.

당신의 Agent 수는 생산자이고, 리뷰 능력은 소비자입니다. 올바른 병렬 Agent 수는 당신이 진지하게 코드 리뷰를 완료할 수 있는 수입니다. 대부분의 사람에게 이는 보통 낮은 한 자릿수에 불과합니다.

AI 도구는 당연히 20개의 Agent를 실행하게 할 것입니다. 하지만 그것은 단지 UI 기능일 뿐, 당신이 실제로 이를 관리할 능력이 있다는 의미는 아닙니다.

작업을 분류하라.

Richard가 이 문제를 어떻게 처리할지 물었을 때, 저는 이 방법을 언급했습니다. 작업을 두 더미로 나눕니다.

첫 번째 더미는 상대적으로 독립적인 작업으로, 클라우드 백엔드에서 실행되는 Agent에게 맡기고 싶습니다. 이러한 작업은 비동기적으로 실행될 수 있으며, 보통 마지막 단계에서 제가 한 번만 검토하면 됩니다.

두 번째 더미는 복잡한 작업으로, 실제 작업 자체가 판단입니다. 예를 들어, 이상한 버그나 아키텍처 설계 같은 것들입니다.

가장 큰 실수는 두 번째 유형의 작업까지 병렬화하려는 것입니다. 여러 복잡한 작업을 병렬로 처리한다고 해서 생산량이 늘어나지 않으며, 오히려 그 잠금 장치가 반복적으로 경쟁되어 모든 결과가 나빠집니다.

일괄 리뷰.

매번 컨텍스트 스위칭은 높은 비용을 초래합니다. 한 번에 4개의 Agent 결과를 리뷰하는 것이, 하나를 보고 다른 일을 한 후 다시 콜드 스타트로 돌아와 다른 것을 보는 것보다 훨씬 저렴합니다.

Agent에게 더 긴 리드(lead)를 주세요. 작업을 약간 축적한 후, 하나의 배치로 처리하세요.

이 잠금 장치를 판단에만 사용하세요.

머신이 스스로 검증할 수 있는 일에 두뇌를 낭비하지 마세요. Agent가 통과 가능한 테스트를 작성하거나 스크린샷을 생성하도록 하세요.

지루하지만 검증 가능한 80%를 스스로 증명하게 하세요. 그러면 당신의 희소한 주의력은 진정으로 인간의 판단이 필요한 20%에만 집중될 수 있습니다.

직렬 시간을 보호하세요.

병목 현상은 당신의 최고의 시간을 필요로 하며, Agent 점검 사이에 남은 조각 시간이 아닙니다.

때로는 가장 높은 레버리지의 행동은 오케스트레이션을 완전히 중단하는 것입니다: Agent로 가득 찬 컴퓨터를 끄고, 오직 하나의 문제에 집중하며, 전체 과정에서 그 잠금 장치를 단단히 유지하는 것입니다.

오케스트레이션은 실제 작업이 아닙니다. 그것은 작업 주변에서 발생하는 오버헤드일 뿐입니다.

Aja는 아키텍처 능력이 이제 가장 시급한 기술이 되었다고 지적합니다: 어떤 작업이 Agent에 적합한지, 어떤 작업이 너무 큰지 알아야 합니다.

저는 한 가지를 더 추가하고 싶습니다: 당신 자신도 이 시스템의 구성 요소입니다. 당신의 주의력은 알려진, 매우 낮은 직렬 처리량을 가지고 있습니다. 시스템은 이 숫자를 존중하거나, 조용히 기준을 낮춰 이를 우회할 것입니다.

바쁘다고 생산적인 것은 아니다

이것은 매우 중요합니다. 왜냐하면 이러한 실패 모드는 당신 자신에게 거의 보이지 않기 때문입니다.

20개의 실행 중인 에이전트가 있으면 '생산성이 폭발한다'는 느낌이 듭니다. 대시보드는 가득 차 있고, 모든 것이 움직이고 있습니다. 하지만 이 느낌은 실제로 고품질 코드를 메인 브랜치에 병합하는 것과는 이미 괴리가 있습니다.

한계까지 바쁘게 움직이면서도 실제 산출물은 거의 없을 수 있습니다. 내부 경험상 이 둘은 거의 동일합니다.

Ciera는 Margaret-Anne Storey의 부채에 관한 연구를 언급했습니다. 우리는 기술 부채와 인지 부채에 대해 이야기했습니다.

지불되지 않은 오케스트레이션 세금은 이 두 가지 부채를 동시에 쌓이게 합니다.

직접 제대로 읽지 않은 것을 병합합니다. 코드베이스에 대한 멘탈 모델이 완전히 구식이 됩니다. 이러한 문제는 오늘 대시보드에 나타나지 않습니다. 프로덕션 환경에서 장애가 발생할 때 드러납니다. 그때 시스템을 바라보며 갑자기 그것이 어떻게 작동하는지 더 이상 알지 못한다는 것을 깨닫게 됩니다.

따라서 진정한 결론은: 에이전트를 실행하는 것이 능력이 아니라는 것입니다. 누구나 20개를 실행할 수 있습니다.

진정한 능력은 복제할 수 없고 병렬화할 수 없는 직렬 리소스를 중심으로 시스템을 설계하는 것입니다.

이 리소스는 바로 당신의 주의력입니다.

프로덕션 환경에서 의존하는 모든 핵심 구성 요소를 설계하듯이 설계하세요.

[원문 링크]

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia