제7장 — 고급 협업 및 동적 패턴

LLM Primer IV: MCP로 설계하는 AI 인지를 챕터별로 따라가는 워크스루의 일곱 번째 글입니다. 토폴로지를 설계 시간에 그릴 수 없을 때 — 알맞은 다음 단계가 이전 단계가 무엇을 찾았는지에 달려 있을 때 — 제6장의 패턴은 더 이상 충분하지 않습니다.

이 장이 존재하는 이유

제6장의 패턴은 더 어려운 작업에서는 부채가 되는 아키텍처적 특징을 공유합니다. 토폴로지가 설계 시간에 고정된다는 점입니다. 엔지니어가 파이프라인을 그리고, 단계에 이름 붙이고, 누가 누구에게 먹이는지 결정하면 런타임은 결코 다시 고려하지 않습니다. 모양이 사전에 알려진 작업에는 이것이 강점입니다. 모양이 정말로 창발적인 작업 — 알맞은 전문가가 사용자가 실제로 무엇을 요청했는가에 달려 있는 곳, 계획 자체가 일이 진행되며 만들어져야 하는 곳 — 에는 고정된 토폴로지가 우리가 됩니다.

이 장은 동적 패턴을 걸어 갑니다. 에이전트가 합의를 향해 반복하는 라운드테이블, 런타임에 선택된 전문가에 위임하는 라우터, 작업이 펼쳐지며 계획을 짓는 마젠틱 오케스트레이션. 각각은 더 단순한 패턴이 줄 수 없는 능력을 사 옵니다. 각각은 더 단순한 패턴이 피하는 실패 모드 — 비종료, 잘못된 라우팅, 폭주 계획 — 를 도입합니다.

7.1 그룹 챗과 라운드테이블: 작성자-검토자, 다자 합의

그룹 챗 오케스트레이션은 여러 에이전트를 공유 대화 컨텍스트에 넣고 차례로 말하게 합니다. 가장 단순한 형태는 2-에이전트 작성자-검토자 루프입니다. 작성자가 후보를 생산하고, 검토자가 루브릭에 맞춰 평가하고, 작성자가 피드백에 따라 수정하며, 루프는 승인이나 턴 예산에서 종료됩니다. 언어 모델은 양쪽이 올바르게 프레임될 때 생산보다 평가에서 측정 가능하게 더 낫습니다 — 한 번의 호출에서 쓰고 자기 평가하라는 요청을 받은 모델은 자기 첫 시도를 옹호하는 경향이 있습니다. 같은 모델이 새 컨텍스트와 명확한 루브릭으로 같은 출력을 받으면 눈에 띄게 더 비판적입니다.

정직한 실패 모드는 셋입니다. 담합 — 작성자와 검토자가 모델과 프롬프트를 공유할 때 검토자는 무엇이든 승인합니다. 방어는 진짜 역할 분화, 이상적으로는 다른 모델입니다. 비종료 — 엄격한 검토자는 모든 후보를 거부합니다. 오케스트레이터는 가장 잘 본 것을 받아들이거나 에스컬레이션해야 합니다. 검토자 표류 — 공유 라운드테이블 컨텍스트에서 검토자는 작성자의 정당화가 쌓이는 동안 더 일찍이라면 거부했을 것을 승인하기 시작합니다. 2025년 후반의 한 현장 발견은 반직관적입니다. 가장 신뢰할 만한 작성자-검토자 시스템은 검토자가 후보가 어떻게 생산되었는지 보지 못하게 막습니다. 상태 없는 검토자 — 후보와 루브릭만 주어진 — 는 올바른 거부를 30~50% 늘립니다. 공유 컨텍스트는 기본값이 아니라 도구입니다.

다자 라운드테이블은 패턴을 여러 전문가와 사회자로 확장합니다. 비용이 빠르게 자랍니다. 토큰 지출은 공유 트랜스크립트와 함께 자라고, 지연 시간은 턴과 함께 자라며, 에이전트가 곁다리에 갇히는 일이 프로덕션에서 관찰됩니다. 그것을 작동시키는 규율 — 턴당 유계 토큰, 구조화된 턴 출력, 명시적 종료 루브릭 — 이 생산적 회의와 이메일이었어야 했던 회의의 차이입니다.

7.2 핸드오프와 라우팅: 동적 위임

핸드오프 오케스트레이션은 다른 접근을 취합니다. 한 번에 한 에이전트가 대화를 다루며, 활성 에이전트는 자기 일이 끝났거나 요청이 다른 전문 분야로 옮겨갈 때 넘길 수 있습니다. 라우터 — 보통 그 자체로 LLM — 는 대화 상태를 읽고 라우팅 결정을 출력합니다. 「현재와 머문다」 또는 「이 컨텍스트 요약과 함께 전문가 X에게 넘긴다」. 요약이 라우팅 층과 전문가 사이의 계약입니다.

가장 어려운 엔지니어링 문제는 핸드오프가 필요한 때를 인식하는 것입니다. 잘못된 라우팅이 가장 흔한 실패입니다. 라우터가 청구 질문을 기술 지원으로 보내고, 지원은 최선을 다하고, 사용자는 자기 관심사 어느 것도 다루지 않는 혼란한 답을 받습니다. 방어는 층을 이룹니다. 라우터가 사람에게 미루는 신뢰 임계값, 전문가가 취할 수 있는 명시적 「이건 내 분야가 아닙니다」 행동, 그리고 검토를 위해 모든 라우팅 결정을 기록.

두 가지 다른 실패 모드가 프로덕션 설계를 형성합니다. 핸드오프 루프 — 전문가 A가 B에게 보내고, B가 A에게 다시 보냅니다 — 는 반복된 핸드오프를 탐지해 다른 해결을 강제하는 것으로 방어합니다. 컨텍스트 손실 — 각 핸드오프 요약은 손실 있고, 다음 전문가는 사용자가 이미 제공한 정보를 물을 수 있습니다 — 는 전문가의 컨텍스트 밖에 전체 대화를 저장하고, 요약을 주된 페이로드로, 전체 이력을 요청 시 가용하게 두어 방어합니다. 전문가 수가 자라면 평평한 라우터는 깨지기 쉬워집니다. 2025년에 떠오른 패턴은 계층적 라우팅입니다 — 거친 라우터가 범주를 고르고, 범주별 라우터가 전문가를 고릅니다. 두 단계가 프로덕션의 좋은 지점입니다.

7.3 마젠틱 오케스트레이션: 일이 펼쳐지며 만들어지는 계획

분해가 시작 시 알려지지 않은 작업 — 데이터베이스가 왜 느린지 조사, 익숙하지 않은 시스템 디버그, 복잡한 주제 연구 — 에는 앞선 패턴 중 어느 것도 충분하지 않습니다. Microsoft의 Magentic-One 프레임워크 이름을 딴 마젠틱 오케스트레이션은 관리자 에이전트가 작업 원장을 들고 일이 진행되며 그것을 갱신하는 패턴 집합입니다. 원장은 명시적 슬롯을 가집니다. 원래 목표, 현재 이해(정제될 수 있는), 우선순위가 있는 열린 하위 작업, 결과가 있는 완료된 하위 작업, 계획 수정을 요구할 수 있는 발견, 그리고 정지 조건. 관리자는 매 단계 원장을 읽고, 다음 디스패치를 결정하고, 결과를 다시 통합합니다.

강점은 진정한 열린 결말입니다. 「데이터베이스가 왜 느린지 조사」는 사전에 분해될 수 없습니다 — 다음 하위 작업은 병목이 네트워크인지, 쿼리 계획인지, 핫 행인지에 달려 있습니다. 어떤 고정 파이프라인도 이를 다룰 수 없고, 어떤 정적 핸드오프 토폴로지도 관련 전문 분야가 사전에 무엇인지 모르고는 올바르게 라우팅할 수 없습니다.

비용은 이 장에서 모든 차원에서 가장 심각합니다. 지연 시간, 토큰, 엔지니어링 노력, 운영적 위험. 토큰 지출은 원장이 매 턴 읽히기 때문에 초선형적으로 자랍니다. 카탈로그된 실패 모드는 날카롭습니다. 폭주 계획 — 관리자가 닫는 것보다 빠르게 하위 작업을 열어 원장이 무한 자라남. 목표 표류 — 관리자가 배우며 사용자의 의도에서 멀어지는 방향으로 목표를 재공식화함. 계획 휘저음 — 모든 새 발견이 계획 수정을 촉발해, 진전을 만들 만큼 오래 어떤 약속도 유지되지 않음. 떠오른 패턴은 유계 마젠틱 루프입니다. 열린 하위 작업, 전체 작업자 호출, 벽시계 시간에 예산을 두고, 어떤 경계든 닿으면 에스컬레이션. 경계 없는 프로덕션 마젠틱 시스템은 가끔 관리자가 어떤 실용적 예산 안에서도 풀 수 없었던 작업에 수백 달러어치 토큰을 태웁니다.

7.4 패턴들 중에서 고르기

세 질문이 그것들 중에서 고릅니다. 토폴로지가 사전에 알려져 있습니까? 그렇다면 제6장의 정적 패턴에 머무십시오. 일이 외부 점검에 대한 반복으로 보상받습니까? 그렇다면 작성자-검토자 루프가 알맞은 추가입니다 — 어떤 다른 패턴 안에든 내장할 수 있습니다. 계획은 얼마나 열린 결말입니까? 명확한 경계라면 핸드오프나 순차가 처리합니다. 진정으로 창발적이라면 마젠틱이 필요한 패턴이며, 그 비용과 함께 받아들입니다.

2025년 한 금융 서비스 회사의 사례가 교훈적 경고담입니다. 팀이 프레임워크의 유연성에 흥분해서 골랐던 마젠틱 고객 온보딩 워크플로가 고정 순차 파이프라인으로 교체되었습니다. 온보딩당 비용이 약 7달러에서 80센트로 떨어졌고, 완료율이 개선되었습니다. 더 구체적인 도구가 통할 일에 가장 일반적인 도구를 손에 잡는 패턴은 소프트웨어 엔지니어링에서 새롭지 않으며, 일반성이 토큰으로 지불되기 때문에 다중 에이전트 오케스트레이션에서 날카롭게 드러납니다.

제7장이 준비하는 것

제6장과 제7장은 에이전트가 조율하는 방식을 명세합니다. 에이전트가 어디서 도는지, 언어 모델이 도구와 어떻게 같은 자리에 있는지, 또는 배포 토폴로지가 프로세스, 기계, 네트워크 경계 수준에서 어떻게 보이는지를 명세하지 않습니다. 동일한 오케스트레이션 패턴을 가진 두 시스템이 극적으로 다르게 배포될 수 있습니다 — 다른 지연 시간 프로파일, 다른 비용 구조, 다른 보안 자세. 제8장이 그 차원을 다룹니다.

다음 → 제8장: 배포 레이아웃. MCP가 물리적으로 배포될 수 있는 세 가지 크게 다른 방식 — model-with-server, model-in-client, 하이브리드 — 와 지연 시간, 비용, 운영 복잡도의 실제 트레이드오프, 그리고 각각이 일으키기 쉬운 종류의 실패.