레슨 4: 오케스트레이터-워커: 분해 자체를 동적으로 만들기

학습 목표:

• 오케스트레이터-워커를 정의하고 병렬화와의 핵심 차이 짚어내기 — 지형은 비슷하지만 하위 작업이 미리 정의되어 있지 않고, 오케스트레이터가 구체적인 입력을 보고 정한다
• 모든 디스패치에 네 요소(목표, 출력 형식, 도구와 자료에 대한 안내, 작업 경계)를 갖추고, 규모 배분 규칙("몇 개를 띄우고 각자 얼마를 쓸 수 있는가")을 프롬프트에 써넣기
• 실제 프로덕션 시스템의 장부를 통째로 읽어 내기 — 90.2% 개선이 어디에서 나오는지, 15배 청구서가 왜 같은 메커니즘의 나머지 절반인지, 동기 실행이 무엇을 막는지, 비동기가 대신 짊어지라고 요구하는 세 가지 새 비용이 무엇인지

전제: 레슨 1~3 완료(이 레슨은 레슨 3 끝에서 답하지 않고 남겨 둔 질문을 이어받습니다) | 이전: 레슨 3 << | 다음: 레슨 5 >>

레슨 3이 남겨 둔 구멍

레슨 3에서 여러분은 섹셔닝을 작성했습니다. 작업을 독립적인 하위 작업으로 쪼개고, 동시에 돌리고, 결과를 코드로 집계했습니다. 그 코드를 다시 보십시오. 분할 로직은 어디에 있습니까? 여러분이 하드코딩한 배열 안에 있습니다. SECTIONS = ['security', 'performance', 'readability']. 세 갈래는 여러분이 코드를 쓸 때 정해졌고, 런타임은 그것을 실행할 뿐입니다.

이 방식은 하나의 뻣뻣한 가정 위에서 동작합니다. 작업을 어떻게 나눌지 이미 작성 시점에 알고 있다는 가정입니다. 코드 리뷰는 이 가정에 들어맞습니다. 리뷰 차원이 안정적이기 때문입니다. 리포지터리를 바꿔도 살펴보는 측면은 그대로입니다.

이제 다른 작업을 생각해 보십시오.

"이 코드베이스의 성능 문제를 조사해 주세요."

몇 조각으로? 어떤 조각으로? 하드코딩할 수 없습니다. 병목이 데이터베이스 쿼리에 있을 수도 있고, 그러면 ORM 호출 지점을 훑을 사람을 보내야 합니다. 핫 패스 루프에 있을 수도 있고, 그러면 프로파일러 출력을 읽을 사람을 보내야 합니다. 빌드 산출물 크기 문제라서 런타임과 무관할 수도 있습니다. 어떤 파일을 건드릴지, 어떤 방향을 조사할지는 이 구체적인 리포지터리, 이 구체적인 문제 설명을 본 다음에야 알 수 있습니다.

바꿔 말하면, 분해 자체를 런타임에 계산해야 합니다. 여러분의 코드는 더 이상 "어떤 조각으로 나눌 것인가"라는 결정을 쥐고 있지 않습니다. "어떻게 보내고, 어떻게 거둬들이고, 어떻게 종합할 것인가"라는 메커니즘만 쥐고 있습니다. 그 결정은 누가 내립니까? LLM입니다.

그것이 네 번째 패턴입니다.

정의, 그리고 병렬화와 무엇이 다른가

공식 자료는 한 문장으로 정의합니다. 오케스트레이터-워커 워크플로에서는 중앙의 LLM이 작업을 동적으로 쪼개고, 워커 LLM에게 위임하고, 그 결과를 종합합니다¹.

동작은 셋입니다. 분해, 위임, 종합. 가운데 것 — 위임 — 은 레슨 3에서 이미 작성했습니다. 팬아웃 코드는 거의 같습니다. 진짜 새로운 것은 첫 번째 동작입니다. 분해가 코드에서 모델의 손으로 옮겨 갑니다.

용도 설명은 더 정밀합니다. 이 워크플로는 필요한 하위 작업을 예측할 수 없는 복잡한 작업에 잘 맞습니다. 공식 예시는 코딩입니다. 변경이 필요한 파일의 개수와 각 변경의 성격이 대개 작업 자체에 달려 있기 때문입니다¹.

그다음이 기억해야 할 비교입니다. 자료는 이렇게 말합니다. 병렬화와 지형적으로 비슷하지만 핵심 차이는 유연성이다. 하위 작업이 미리 정의되어 있지 않고, 구체적인 입력에 근거해 오케스트레이터가 정한다¹.

쓰인 표현은 "지형적으로 비슷하다"입니다. 모양이 비슷하다는 뜻입니다. 이 표현 앞에서 한 번 멈춰 볼 가치가 있습니다. 레슨 3의 섹셔닝과 이 레슨의 오케스트레이터-워커를 그림으로 그려 보면, 거의 같은 모양이 나옵니다. 노드 하나가 셋으로 퍼지고, 그것이 다시 하나로 모입니다. 모양이 사람을 속입니다. 차이는 그림에 있지 않고 그 결정이 언제 내려지는가에 있습니다.

마지막 행이 엔지니어링의 고통이 앉아 있는 자리입니다. 섹셔닝에서는 각 분기의 프롬프트를 손으로 다듬습니다. 반복해서 손보고, 차원마다 예시를 붙일 수 있습니다. 오케스트레이터-워커는 그렇게 할 수 없습니다. 디스패치 프롬프트는 오케스트레이터가 그 자리에서 생성하고, 여러분이 통제할 수 있는 것은 그것이 생성할 때 따르는 규칙뿐입니다. 이어지는 두 절이 그 규칙에 무엇이 담겨야 하는지를 설명합니다.

먼저 메커니즘을 뼈대로 적어 봅니다. 아래 코드는 이 레슨이 직접 만든 예시입니다. 1차 자료에는 공식 오케스트레이션 스크립트가 없으므로, 이것을 표준 구현으로 받아들이지 마십시오.

이것을 레슨 3의 팬아웃 코드와 한 줄씩 비교해 보면, 늘어난 것은 1단계뿐입니다. 그렇게 늘어난 한 단계가 시스템 전체의 예측 가능성을 대체합니다. 뒤쪽 절들의 회계를 항목별로 따져야 하는 이유도 그것입니다.

실제 프로덕션 시스템은 어떻게 생겼는가

패턴의 정의는 외우면서도 그것이 프로덕션에서 어떻게 생겼는지는 모를 수 있습니다. 이 레슨에는 유리한 점이 하나 있습니다. Anthropic이 자사 Research 기능에 대한 엔지니어링 회고를 공개했고, 그것이 프로덕션에서 돌아가는 오케스트레이터-워커 시스템입니다. 이 절과 이어지는 몇 절은 그 장부에서 가져옵니다.

아키텍처 인용: 이들의 Research 시스템은 오케스트레이터-워커 패턴의 멀티 에이전트 아키텍처를 씁니다. 리드 에이전트가 과정을 조율하면서 병렬로 동작하는 전문 서브에이전트들에게 위임합니다².

돌아가는 모습: 사용자가 질의를 보내면, 리드 에이전트가 그것을 분석하고, 전략을 세우고, 서브에이전트들을 띄워 서로 다른 측면을 동시에 탐색하게 합니다².

"그것을 분석하고, 전략을 세운다"에 주목하십시오. 앞 절에서 말한 런타임 결정이 바로 이것입니다. 사용자가 무언가를 묻고, 리드 에이전트가 그 자리에서 방향을 몇 개로 잡을지, 각각 무엇을 조사할지를 정합니다.

정의 인용을 하나 더 꺼낼 만합니다. 멀티 에이전트 시스템은 여러 에이전트(루프 안에서 자율적으로 도구를 쓰는 LLM들)가 함께 일하는 것입니다².

괄호 안이 낯익어야 합니다. 워커는 새로운 무언가가 아니라, 이 시리즈의 코스 7에서 여러분이 직접 작성한 하네스 루프입니다. 오케스트레이터-워커는 새로운 실행 단위를 들여오지 않습니다. "루프 하나가 또 한 무더기의 루프를 시작한다"를 들여옵니다. 그 루프를 쓰는 법은 이미 압니다. 이 레슨은 그것들을 연결하는 법을 가르칩니다.

같은 회고가 팬아웃이 왜 도움이 되는지도 설명합니다. 검색의 본질은 압축입니다. 방대한 말뭉치에서 통찰을 증류해 내는 일입니다. 서브에이전트는 각자의 컨텍스트 윈도우를 가지고 병렬로 동작하며 질문의 서로 다른 측면을 동시에 탐색한 뒤, 가장 중요한 토큰만 압축해 리드 리서치 에이전트에게 넘기는 방식으로 압축을 돕습니다. 또 각 서브에이전트는 관심사의 분리 — 각기 다른 도구, 프롬프트, 탐색 궤적 — 를 제공하며, 이것이 경로 의존성을 줄이고 철저하고 독립적인 조사를 가능하게 합니다².

"독립적인 컨텍스트 윈도우" — 이 계산은 레슨 3에서 이미 해 봤습니다. 여기서는 다른 역할로 다시 등장합니다. 용량만이 아니라 격리입니다. 세 조사는 서로의 중간 단계를 볼 수 없으므로, 서로의 실수에 끌려가 항로를 벗어나지 않습니다.

장부의 앞면: 90.2%와 그 80%

이 회고에서 가장 유명한 숫자는 동시에 가장 자주 잘못 인용되는 숫자이기도 합니다. 전체 인용은 이렇습니다. 이들의 내부 평가에 따르면 멀티 에이전트 리서치 시스템은 여러 독립적인 방향을 동시에 좇아야 하는 너비 우선 질의에서 특히 뛰어납니다. 리드 에이전트로 Claude Opus 4를, 서브에이전트로 Claude Sonnet 4를 쓴 멀티 에이전트 시스템이 자사 내부 리서치 평가에서 단일 에이전트 Claude Opus 4를 90.2% 앞섰습니다².

이 조건들 중 하나라도 빼고는 이 숫자를 인용할 수 없습니다:

• 자사 내부 리서치 평가에서 — 공개 벤치마크가 아니며, 재현할 수 없고, 여러분의 작업 분포와 닮았는지도 알 수 없습니다.
• Opus 4 리드 + Sonnet 4 서브에이전트 — 그 특정한 조합의 결과입니다. 다른 모델 조합에 대해서는 아무것도 약속하지 않습니다.
• 너비 우선 질의에서 특히 뛰어나다 — 여러 독립적인 방향을 동시에 요구하는 질의입니다. 의존이 깊은 작업(각 단계가 앞 단계의 결론을 기다리는)은 이 진술의 범위에 없습니다.

인용에 관한 규율이 하나 더 있습니다. 이 숫자는 멀티 에이전트를 단일 에이전트와 비교한 것이지, "구조화된 오케스트레이션 대 루프"를 비교한 것이 아닙니다. 이것으로 "제어 흐름을 코드로 옮기는 편이 모델이 루프를 돌게 두는 것보다 낫다"를 주장할 수는 없습니다. 그것은 다른 주장이고, 이 레슨의 1차 자료 중 어느 것도 그 둘을 비교하지 않습니다. 이 레슨은 "계획을 누가 쥐는가"라는 축을 거듭 쓰지만, 그 축 위에는 1차 벤치마크 데이터가 없고 엔지니어링 트레이드오프만 있습니다.

멀티 에이전트가 대체로 효과적인 이유는 무엇일까요? 회고가 덜 낭만적인 설명을 내놓습니다. 다만 그 근거 분석은 90.2%를 낸 평가가 아니라 다른 평가에서 나왔다는 점에 유의하십시오. 멀티 에이전트 시스템이 동작하는 주된 이유는 문제를 풀기에 충분한 토큰을 쓰도록 돕기 때문입니다. BrowseComp 평가(찾기 어려운 정보를 브라우징 에이전트가 찾아내는 능력을 시험합니다) 분석에서 세 요인이 성능 분산의 95%를 설명했고, 토큰 사용량 하나만으로 80%를 설명했으며, 나머지 두 설명 요인은 도구 호출 횟수와 모델 선택이었습니다². 이 발견이 병렬 추론 용량을 늘리기 위해 별도의 컨텍스트 윈도우를 가진 에이전트들에게 일을 분산하는 자사 아키텍처를 뒷받침한다고 이들은 말합니다².

95%와 80%라는 수치는 BrowseComp 분석에서만 성립합니다. 일반적인 결론인 양 다른 곳으로 옮기지 마십시오.

그래도 이 메커니즘 설명에는 실용적인 쓸모가 있습니다. 여러분의 작업이 그만큼의 토큰을 필요로 하지 않는다면, 오케스트레이터-워커가 주는 이득의 근거 자체가 사라집니다. (이것은 메커니즘 진술로부터 끌어낸 엔지니어링 판단이지, 95%/80% 수치의 직접적인 귀결이 아닙니다.) 문서 한 번 찾아보면 답이 나오는 질문은 워커 셋을 보낸다고 더 정확해지지 않습니다. 더 비싸질 뿐입니다.

장부의 뒷면: 4배와 15배

이 두 숫자는 레슨 1에 나왔습니다. 여기 전체 인용이 있습니다. 같은 회고가 곧바로 이어서 말합니다. 단점이 있습니다. 실제로 이런 아키텍처는 토큰을 빠르게 태웁니다. 이들의 데이터에서 에이전트는 대체로 채팅 상호작용의 약 4배 토큰을, 멀티 에이전트 시스템은 채팅의 약 15배 토큰을 씁니다. 경제적으로 성립하려면 멀티 에이전트 시스템은 향상된 성능 값을 치를 만큼 작업의 가치가 높은 작업을 요구합니다².

두 절의 숫자를 나란히 놓아 보십시오. 한쪽에 90.2%(특정 조건 아래), 다른 쪽에 15배. 앞 절이 분명히 했듯 성능 이득은 주로 토큰을 쓰는 데서 나오므로, 더 큰 청구서는 부작용이 아니라 같은 메커니즘의 나머지 절반입니다.

"작업의 가치가 그에 맞아야 한다"를 어떻게 실무로 옮깁니까? 사실 이것은 기술 질문에 앞서 사업 질문에 답하라는 요구입니다. 이 조사가 성공하면 그것은 얼마짜리입니까? 답이 "엔지니어 한 명의 30분을 아낀다"라면 15배 청구서는 아마 남지 않습니다. 답이 "프로덕션 장애를 막는다"라면 이야기가 달라집니다.

회고는 더 단단한 경계도 그어 둡니다. 모든 에이전트가 같은 컨텍스트를 공유해야 하거나 에이전트 사이 의존이 많은 일부 영역은 오늘의 멀티 에이전트 시스템에 잘 맞지 않습니다. 예를 들어 대부분의 코딩 작업은 리서치보다 진짜로 병렬화 가능한 작업이 적고, LLM 에이전트는 아직 실시간으로 다른 에이전트를 조율하고 위임하는 데 능하지 않습니다². 반대로 이들은 멀티 에이전트 시스템이 대규모 병렬화를 수반하는 가치 있는 작업, 단일 컨텍스트 윈도우를 넘어서는 정보, 수많은 복잡한 도구와의 접속에서 뛰어나다는 것을 확인했습니다².

여기 두 문장은 함께 읽어야 합니다. 그러지 않으면 오해합니다. 공식 패턴 자료는 "하위 작업을 예측할 수 없다"의 예시로 코딩을 듭니다¹. 반면 멀티 에이전트 회고는 대부분의 코딩 작업이 리서치보다 진짜로 병렬화 가능한 작업이 적다고 말합니다². 둘은 모순이 아니라 서로 다른 것을 말합니다. 앞의 것은 분해를 동적으로 계산해야 한다는 말이고, 뒤의 것은 계산된 하위 작업이 전부 동시에 돌지는 않을 수 있다는 말입니다. 동적 분해가 병렬성의 필연을 뜻하지는 않습니다. 오케스트레이터가 하위 작업 다섯 개를 계산한 뒤 셋은 순차로, 둘은 병렬로 돌리는 일은 얼마든지 가능합니다.

위임 프롬프트의 네 요소

이 레슨에서 가장 기억해야 할 엔지니어링 규율입니다. 원문 인용은 짧습니다.

"Teach the orchestrator how to delegate. In our system, the lead agent decomposes queries into subtasks and describes them to subagents. Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries. Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information"².

(오케스트레이터에게 위임하는 법을 가르치십시오. 각 서브에이전트에는 목표, 출력 형식, 쓸 도구와 자료에 대한 안내, 그리고 명확한 작업 경계가 필요합니다. 상세한 작업 설명이 없으면 에이전트들은 일을 중복하고, 빈틈을 남기고, 필요한 정보를 찾아내지 못합니다.)

네 요소이며, 어느 것도 선택 사항이 아닙니다.

목표 — 이 워커가 내놓아야 할 결론이 무엇인가. "성능을 조사하라"가 아니라 "self-time이 가장 높은 런타임 CPU 핫스팟 3개를 찾아라"입니다. 목표는 달성 여부를 판정할 수 있을 만큼 좁아야 합니다.

출력 형식 — 돌아오는 산출물이 어떻게 생겼는가. 필드, 항목 수 상한, 정렬 순서. 이 항목은 오케스트레이터의 종합 단계를 얼마나 쉽게 쓸 수 있는지를 그대로 결정합니다. 워커 셋이 산문 세 문단을 돌려주면 종합은 모델이 그것을 다시 읽는 데 기댈 수밖에 없습니다. 같은 스키마를 따르는 JSON을 돌려주면 종합의 절반은 코드로 할 수 있습니다.

도구와 자료에 대한 안내 — 어떤 도구를 써도 되는지, 어디를 볼지. 이 항목은 비용 통제이자 표류 방지입니다. 웹 검색 도구를 주지 않으면 존재하지도 않는 것을 검색하러 갈 수 없습니다.

작업 경계 — 하지 말아야 할 것을 명시하는 항목. 가장 빠뜨리기 쉽고, 워커끼리 충돌하는지를 가장 직접적으로 결정합니다. "src/server/는 보지 마라, 거기는 다른 워커의 영역이다" — 이런 한 문장이 사후 중복 제거보다 효과적입니다.

회고의 실패 사례는 거의 교과서적입니다. 예를 들어 한 서브에이전트는 2021년 자동차 칩 위기를 탐색하고 있었고, 다른 둘은 효과적인 분업 없이 2025년 현재의 공급망을 조사하는 일을 중복했습니다².

워커 셋 중 둘은 중복이고 하나는 무관한 연도로 달려간 것 — 이것이 "일을 중복하고, 빈틈을 남긴다"가 구체적으로 어떤 모습인지입니다.

이미 배운 것과 이어 봅니다. 이 시리즈의 코스 6은 멀티 에이전트 협업을 가르치며 이 네 항목을 이미 쪼개 두었고(목표, 범위, 자료, 출력 형식이라 불렀습니다), 레슨 2에서도 언급했습니다. 이 레슨은 그 두 곳이 하지 않은 일을 합니다. 네 요소를 오케스트레이터가 그 자리에서 생성하는 디스패치라는 자리에 되돌려 놓는 것입니다. 이제 여러분은 각 디스패치의 내용을 통제하지 못하고, 오케스트레이터가 생성할 때 따르는 규칙만 통제합니다. 네 요소는 여전히 체크리스트로 작동합니다. 디스패치를 쓰고 나서 하나씩 세어 넷이 다 있는지 확인하십시오.

복잡도에 맞춰 노력을 조절하기: 배분 규칙을 프롬프트에 써넣기

네 요소는 "각 워커가 무엇을 하는가"를 해결합니다. 질문 하나가 남습니다. 몇 개를 띄우고, 각자 얼마를 쓸 수 있는가.

이 숫자 묶음은 코스 6의 도입부에 나왔습니다. 여기서는 쓰임이 다릅니다. 멀티 에이전트를 쓸지 판단하기 위해서가 아니라, 오케스트레이터의 프롬프트에 써넣어 스스로 할당량을 배분하게 하기 위해서입니다. 회고의 진단은 직설적입니다. 에이전트는 작업마다 적절한 노력을 판단하기 어려워하므로, 이들은 규모 배분 규칙을 프롬프트에 심었습니다. 단순한 사실 확인은 에이전트 1개에 도구 호출 310회면 되고, 직접 비교는 서브에이전트 24개에 각 10~15회가 필요할 수 있으며, 복잡한 리서치는 책임이 명확히 나뉜 서브에이전트를 10개 넘게 쓸 수도 있습니다².

이 숫자들에 대한 인용 규율이 하나 있습니다. 이것의 정체는 "이들이 자기 프롬프트에 심은 규칙"이지, 업계 표준도 아니고 여러분이 그대로 베낄 척도도 아닙니다. 여러분의 작업 분포, 도구 속도, 모델은 전부 이들과 다릅니다. 진짜로 옮겨 갈 수 있는 것은 관행 자체입니다. 배분 규칙을 오케스트레이터 프롬프트에 명시적으로 써넣고, 오케스트레이터가 스스로 절제하기를 기대하지 마십시오.

써넣지 않으면 어떻게 됩니까? 회고가 장면을 제공합니다. 멀티 에이전트 시스템은 단일 에이전트 시스템과 핵심적으로 다른 점들이 있는데, 그중 하나가 조율 복잡도의 급격한 증가입니다. 초기 에이전트들은 단순한 질의에 서브에이전트 50개를 띄우거나, 존재하지 않는 자료를 찾아 웹을 끝없이 뒤지거나, 과도한 업데이트로 서로의 주의를 흩뜨리는 에러를 냈습니다².

"단순한 질의에 서브에이전트 50개를 띄운다" — 앞 절의 장부로 환산해 보면 이해가 됩니다. 이들의 데이터로 멀티 에이전트는 채팅의 약 15배 토큰인데², 이런 식으로 팬아웃이 폭주하면 그 배수는 훨씬 위로 올라갑니다. 할당량 규칙은 인색함이 아니라 비용과 작업 가치를 같은 자릿수에 붙들어 두는 수단입니다.

이 규칙을 여러분의 오케스트레이터 프롬프트에 어떻게 씁니까? 이들의 모양을 따르되 척도는 여러분 것을 채우십시오. 작업을 몇 개 등급으로 나누고, 등급마다 서브에이전트 개수 상한과 서브에이전트당 도구 호출 상한을 정하고, "상한을 넘으면 지금까지 찾은 것을 돌려주고 더 진행하지 마라" 같은 조항을 덧붙이십시오. 이것으로 폭주 확률을 낮출 수는 있지만, 그래도 여전히 프롬프트일 뿐입니다. 비결정론적인 모델에게 프롬프트에 쓰인 상한은 언제나 조언에 그칩니다. 진짜 관문은 코드 쪽에 있습니다. 뼈대의 pool에 있는 LIMIT입니다. 프롬프트 계층은 "모델의 자각"을 맡고, 코드 계층은 "폴백"을 맡습니다. 둘 다 필요합니다.

동기 실행의 병목, 그리고 비동기의 값

이 절은 오늘의 아키텍처가 아직 풀지 못한 문제를 다룹니다. 원문은 두 문단으로 옵니다.

첫 문단, 현재 상태: 동기 실행은 병목을 만듭니다. 현재 이들의 리드 에이전트는 서브에이전트를 동기적으로 실행하며, 서브에이전트 한 묶음이 끝날 때까지 기다린 뒤에야 다음으로 넘어갑니다. 이것은 조율을 단순하게 만들지만 에이전트 사이 정보 흐름에 병목을 만듭니다. 예를 들어 리드 에이전트는 서브에이전트를 조향할 수 없고, 서브에이전트끼리 협력할 수 없으며, 서브에이전트 하나가 검색을 끝내기를 기다리는 동안 시스템 전체가 막힐 수 있습니다².

"할 수 없다"가 셋이고, 각각이 실제 손실에 대응합니다.

• 리드 에이전트가 도중에 방향을 틀 수 없다 — 2분째에 워커 C의 방향이 틀렸다는 것을 이미 알 수 있지만, 묶음이 끝날 때까지 기다려야 무언가를 할 수 있습니다.
• 서브에이전트끼리 협력할 수 없다 — 워커 A가 이미 무언가를 찾아냈는데 워커 B는 그것을 모르고, 지금 그것을 다시 검색하고 있을 수도 있습니다.
• 묶음 전체가 가장 느린 것에 막힌다 — 3분에 끝난 워커 둘이 25분에 타임아웃되는 하나와 함께 25분까지 기다립니다.

둘째 문단, 다른 길의 값: 비동기 실행은 추가적인 병렬성을 가능하게 합니다. 에이전트들이 동시에 일하고, 필요할 때 새 서브에이전트를 만들 수 있습니다. 그러나 이 비동기성은 결과 조율, 상태 일관성, 서브에이전트 전반의 에러 전파에 어려움을 더합니다².

이 문장의 어조에 주목하십시오. 1차 자료는 이 세 항목을 과제로 나열하고 있지, 해결된 문제로 두고 있지 않습니다. 그러므로 이 레슨은 "공식 권장 비동기 오케스트레이션 방안"을 주지 않습니다. 그런 것은 없습니다. 여러분이 직접 비동기로 간다면, 이 셋은 여러분이 짊어질 몫입니다.

• 결과 조율: 워커들이 조금씩 돌아옵니다. "언제쯤 충분히 모였다고 보고 종합을 시작할 것인가"는 여러분이 정의해야 할 판단입니다.
• 상태 일관성: 리드 에이전트가 도중에 조사 범위를 바꿨는데, 돌고 있는 워커들은 여전히 옛 범위를 씁니다. 양쪽의 전제가 갈라졌습니다.
• 에러 전파: 워커 하나가 실패했는데 그 중간 출력은 이미 새 워커를 띄우는 데 쓰였습니다. 그 사슬에서 누가 다시 돌아야 하고 누구의 결과가 무효인지 — 여기에는 명시적인 규칙이 필요합니다.

이 레슨의 레벨 2 연습은 구체적인 타임라인 위에서 이 각각의 사례를 하나씩 들라고 요구할 것입니다.

창발 행동, 그리고 마지막 1마일

같은 회고에서 엔지니어링 교훈 몇 개를 더 가져옵니다. 각각은 짧지만, 각각이 프로덕션 장애 하나 값을 합니다.

멀티 에이전트 시스템에는 창발 행동이 있으며, 이것은 따로 프로그래밍하지 않아도 생깁니다. 예를 들어 리드 에이전트에 가한 작은 변경이 서브에이전트의 행동을 예측할 수 없게 바꿀 수 있습니다. 성공하려면 개별 에이전트의 행동만이 아니라 상호작용 패턴을 이해해야 합니다². 같은 회고가 더 냉정한 문장을 덧붙입니다. 전통적인 소프트웨어에서 버그는 기능 하나를 망가뜨리거나, 성능을 떨어뜨리거나, 장애를 냅니다. 에이전트 시스템에서는 작은 변경이 큰 행동 변화로 연쇄하며, 그 때문에 오래 도는 프로세스에서 상태를 유지해야 하는 복잡한 에이전트의 코드를 쓰기가 대단히 어려워집니다².

일상 업무에 미치는 영향: 오케스트레이터의 프롬프트를 바꿨다면 평가 스위트 전체를 다시 돌려야 합니다. 오케스트레이터 자신의 출력만 확인해서는 안 됩니다. 코스 10의 평가 활주로가 여기서 쓰입니다. 작은 변경이 서브에이전트를 항로에서 밀어냈는지 볼 수 있는 유일한 계기입니다.

마지막 1마일이 여정의 대부분이 되곤 합니다: AI 에이전트를 만들 때 마지막 1마일이 여정의 대부분이 되곤 합니다. 개발자 머신에서 돌아가는 코드베이스를 신뢰할 만한 프로덕션 시스템으로 만들려면 상당한 엔지니어링이 필요합니다. 에이전트 시스템에서 에러가 복리로 쌓이는 성질 때문에, 전통적인 소프트웨어에서는 사소한 문제가 에이전트를 통째로 탈선시킬 수 있습니다².

동반하는 관행이 둘입니다. 이들은 Claude 위에 지은 AI 에이전트의 적응성을, 재시도 로직과 정기 체크포인트 같은 결정론적 안전장치와 결합합니다². 또 돌고 있는 에이전트를 방해하지 않기 위해 레인보 배포를 씁니다. 옛 버전과 새 버전을 동시에 돌리면서 트래픽을 점진적으로 옮기는 방식입니다².

레인보 배포 — 이것은 코스 9의 도입부에서 배포 업데이트를 크래시 시나리오로 삼으며 언급한 문제로 이어집니다. 평범한 웹 서비스는 재시작하면 사용자가 한 번 다시 시도하고 끝입니다. 20분째 돌고 있던 에이전트가 재시작에 끊기면, 20분의 작업과 이미 쓴 토큰을 함께 잃습니다. 오래 도는 작업을 배포하는 것은 무상태 서비스를 배포하는 것과 같지 않습니다.

조준: 다섯 패턴 중 가장 비싼 것

여기까지 다섯 패턴 중 넷을 봤습니다. 비용으로 줄을 세우면 오케스트레이터-워커가 지금까지 중 가장 비쌉니다. 병렬화의 오버헤드 위에, "분할을 모델이 계산하게 하는" 호출이 하나 더 얹히고, "그 분할이 잘못 계산될 수 있다"는 위험이 더해집니다.

그러니 시작하기 전에 세 가지를 순서대로 물으십시오.

첫째, 분할을 하드코딩할 수 있는가? 그렇다면 레슨 3으로 돌아가 섹셔닝을 쓰십시오. 섹셔닝에서는 각 분기의 프롬프트를 손으로 다듬습니다. 오케스트레이터-워커에서는 디스패치를 모델이 그 자리에서 생성합니다. 전자가 품질 상한이 높고 디버깅도 쉽습니다. 미리 정의할 수 있다면 동적으로 만들지 마십시오.

둘째, 이 작업이 그만한 돈값을 하는가? 이들의 데이터로 멀티 에이전트는 채팅의 약 15배 토큰이며², 경제적으로 성립하려면 작업의 가치가 그 증가분을 치를 만큼 높아야 합니다². 이것은 기술 판단이 아니라 사업 판단이지만, 코드를 쓰기 전에 내려야 합니다.

셋째, 확신이 없다면 먼저 측정하라. 패턴 묶음 전체에 대한 공식 자료의 마무리 입장은 이렇습니다. 이 구성 요소들은 규범이 아닙니다. 성공의 열쇠는 성능을 측정하고 구현을 반복해 다듬는 것이며, 결과를 눈에 띄게 개선함이 증명될 때에만 복잡도를 더해야 합니다¹. 코스 10이 그 활주로를 줬습니다. 먼저 여러분의 실제 작업 집합을 단일 루프로 돌려 기준선을 잡고, 그다음 오케스트레이터-워커가 그것을 끌어올리는지 판단하십시오. 기준선이 없으면 "나아진 것 같다"와 "15배를 써서 같은 결과를 얻었다"는 여러분 눈에 똑같아 보입니다.

이 레슨은 "내보내고 거둬들이는" 것까지만 다뤘습니다. 돌아온 작업의 품질이 낮으면 어떻게 하는지, 다른 에이전트가 그것을 리뷰해야 하는지, 그리고 이 네 패턴을 어떻게 조합하는지 — 그것이 레슨 5의 내용입니다.

💻 연습

정리

• 오케스트레이터-워커는 중앙의 LLM이 작업을 동적으로 쪼개고 워커 LLM에게 위임하고 그 결과를 종합하는 워크플로이며, 필요한 하위 작업을 예측할 수 없는 복잡한 작업에 잘 맞는다¹
• 병렬화와 지형적으로 비슷하지만 핵심 차이는 유연성이다. 하위 작업이 미리 정의되어 있지 않고 구체적인 입력에 근거해 오케스트레이터가 정한다¹ — 모양은 같고 결정의 시점이 다르다
• 워커는 새로운 무언가가 아니다. 멀티 에이전트 시스템은 여러 "루프 안에서 자율적으로 도구를 쓰는 LLM"이 함께 일하는 것이고, 리드 에이전트가 과정을 조율하며 병렬로 동작하는 전문 서브에이전트에게 위임한다²
• 90.2%는 그 온전한 맥락 안에서만 성립한다. 자사 내부 리서치 평가, Claude Opus 4 리드 + Claude Sonnet 4 서브에이전트, 너비 우선 질의에서 특히 뛰어남². 메커니즘 설명은 멀티 에이전트가 주로 충분한 토큰을 쓰도록 돕는다는 것이며, BrowseComp 분석에서 세 요인이 분산의 95%를 설명했고 토큰 사용량 하나가 80%를 차지했다²
• 청구서는 같은 장부의 반대쪽이다. 이들의 데이터로 에이전트는 채팅의 약 4배, 멀티 에이전트는 약 15배 토큰을 쓰며, 경제적으로 성립하려면 작업의 가치가 그것을 치를 만큼 높아야 한다²
• 각 서브에이전트에는 목표, 출력 형식, 쓸 도구와 자료에 대한 안내, 그리고 명확한 작업 경계가 필요하다. 상세한 작업 설명이 없으면 에이전트들은 일을 중복하고, 빈틈을 남기고, 필요한 정보를 찾아내지 못한다² — 코스 6의 "자족적인 위임 프롬프트"가 이 네 항목으로 펼쳐진다
• 에이전트는 적절한 노력을 판단하기 어려워하므로 배분 규칙을 프롬프트에 써넣어라. 이들의 척도는 단순한 사실 확인 에이전트 1개에 310회, 직접 비교 서브에이전트 24개에 각 10~15회, 복잡한 리서치는 책임이 명확히 나뉜 서브에이전트 10개 이상이다². 규칙을 쓰지 않았을 때의 결과도 이들이 겪었다 — 단순한 질의에 서브에이전트 50개를 띄우고, 존재하지 않는 자료를 찾아 웹을 끝없이 뒤지고, 과도한 업데이트로 서로의 주의를 흩뜨린다²
• 동기 실행은 조율을 단순하게 만들지만 정보 흐름을 막는다. 리드 에이전트는 도중에 방향을 틀 수 없고, 서브에이전트끼리 협력할 수 없으며, 서브에이전트 하나에 시스템 전체가 막힐 수 있다². 비동기는 더 많은 병렬성을 가능하게 하지만 결과 조율, 상태 일관성, 서브에이전트 전반의 에러 전파를 값으로 치른다 — 이 셋은 1차 자료에서 과제이지 해결된 해법이 아니다²
• 멀티 에이전트 시스템에는 창발 행동이 있다. 리드 에이전트에 가한 작은 변경이 서브에이전트의 행동을 예측할 수 없게 바꿀 수 있고, 개별 에이전트만이 아니라 상호작용 패턴을 이해하는 것이 중요하다². 마지막 1마일이 여정의 대부분이 되곤 하며, 개발자 머신에서 돌아가는 코드베이스를 신뢰할 만한 프로덕션 시스템으로 만들려면 상당한 엔지니어링이 필요하다². 동반 관행은 결정론적 안전장치(재시도 로직, 정기 체크포인트)²와 레인보 배포 — 두 버전을 동시에 돌리며 트래픽을 점진적으로 옮겨, 돌고 있는 에이전트를 방해하지 않는 것²이다
• 지금까지 배운 네 패턴 중 가장 비싸다. 시작하기 전에 분해를 정말로 미리 정의할 수 없는지 확인하고(가능하다면 레슨 3의 섹셔닝으로 돌아가라), 그다음 작업의 가치가 15배를 감당할 수 있는지 확인하라. 확신이 없으면 코스 10의 활주로로 먼저 기준선을 측정하라 — 결과를 눈에 띄게 개선할 때에만 복잡도를 더한다¹

>> 레슨 5: 리뷰 회로, 그리고 패턴을 그래프로 조합하기

Footnotes

1. Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

2. How we built our multi-agent research system — Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸ ↩²⁹ ↩³⁰ ↩³¹ ↩³² ↩³³ ↩³⁴ ↩³⁵ ↩³⁶ ↩³⁷ ↩³⁸