제6장 — 기초 오케스트레이션 전략

LLM Primer IV: MCP로 설계하는 AI 인지를 챕터별로 따라가는 워크스루의 여섯 번째 글입니다. 다중 에이전트 시스템은 분산 시스템입니다 — 그 틀이 받아들여지면, 이 장의 설계 선택 대부분이 친숙해지고, 2024년과 2025년의 비싼 실패 대부분이 신비롭지 않게 됩니다.

이 장이 존재하는 이유

에이전트형 시스템에 관한 마케팅 언어는 에이전트가 많을수록 본질적으로 좋다고 — 더 많은 인지 마력, 더 많은 전문화, 더 많은 창발적 능력 — 시사합니다. 엔지니어링 현실은 대부분의 경우 그 반대입니다. 추가 에이전트는 라운드트립을 더하고, 직렬화 지점을 더하고, 한 에이전트의 출력이 다른 에이전트의 입력이 되는 자리를 더하며, 대화가 본궤도를 벗어날 새 기회를 더합니다. 알맞은 출발 질문은 「이것을 어떻게 에이전트 사이에 분배할까?」가 아니라 「알맞은 도구를 가진 단일 모델이 이를 한 번의 호출로 할 수 있는가?」입니다.

이 장은 가장 단순한 두 오케스트레이션 모양 — 순차와 동시 — 과 둘 중 어느 것보다 앞서 와야 할 선행 질문을 걸어 갑니다. 지난 두 해의 가장 비싼 프로덕션 실패 다수는 오케스트레이션의 실패가 아니었습니다. 단일 잘 도구화된 에이전트가 일을 처리했을 일을 다중 에이전트로 지은 시스템이었습니다 — 십분의 일 지연 시간과 어떤 조율 버그도 없이.

6.1 다중 에이전트가 실제로 도움이 되는 때

도구를 가진 단일 에이전트의 경우는, 작업이 잘 정의된 데이터 출처에 대한 잘 정의된 소수의 연산으로 분해될 때 가장 강합니다. 디프를 읽고, 린터를 돌리고, 컨벤션을 찾아보고, 코멘트를 쓰는 코드 리뷰 어시스턴트는 네 개의 도구를 가진 한 번의 모델 호출로 지을 수 있습니다. 두 번째 에이전트를 더하는 일은 능력을 더하지 않고 지연 시간을 도입합니다 — 모델은 이미 계획을 짜고 있으며, 다르게 계획하는 두 번째 모델은 개선이 아니라 조율 비용입니다.

다중 에이전트가 보상해 주는 세 가지 속성. 컨텍스트의 이질성 — 두 단계가 극적으로 다른 시스템 프롬프트, 도구, 참조 자료를 필요로 할 때, 둘을 한 윈도에 강제하면 모델의 어텐션이 희석됩니다. 연구-그리고-작성은 정전(正典)적 경우입니다. 검색은 폭과 검색 도구를 원하고, 작성은 산문과 도구 없음을 원합니다. 외부 점검에 대한 반복적 정제 — 출력이 검토되고 다시 쓰여야 할 수 있다면, 작성자와 검토자는 각자 자기 컨텍스트와 프롬프트를 원합니다. 독립적인 하위 작업에 대한 병렬성 — 요약할 다섯 개의 문서 출처, 모을 세 개의 관점, 분석할 열 개의 파일 — 인과적 의존성이 없는 일에 직렬로 돌리면 벽시계 시간을 낭비합니다.

다중 에이전트로 가기 전에 엔지니어는 그것을 동기하는 속성에 이름 붙일 수 있어야 합니다. 2025년 어느 대형 물류 회사의 회고는 일곱 에이전트짜리 고객 지원 오케스트레이션을 단일 Claude 에이전트와 여섯 개의 MCP 도구로 교체했습니다. 단일 에이전트 버전이 더 빠르고, 더 싸고, 해결 품질에서 더 높은 점수를 받았습니다. 「우리는 이걸 합칠 수 있는가?」는 어떤 오케스트레이션 리뷰에서도 상시 질문이어야 합니다.

6.2 순차 오케스트레이션: 파이프라인과 점진적 정제

순차 오케스트레이션은 가장 단순한 다중 에이전트 모양입니다. 한 에이전트의 출력이 다음 에이전트의 입력이 됩니다. 대부분의 프로덕션 「다중 에이전트」 시스템은 위장한 순차 파이프라인입니다. 강점은 읽기 쉬움입니다. 파이프라인은 화이트보드에 그릴 수 있고, 단계별로 테스트할 수 있으며, 입출력 계약의 연속으로 추론할 수 있습니다. 단계 사이의 계약이 핵심 산출물입니다 — 각 단계는 자기 입력 스키마를 선언하고, 오케스트레이터는 신뢰가 아니라 코드로 강제하며, 검증 실패는 조용한 전파가 아니라 재시도나 폴백을 촉발합니다.

정전적 사례는 연구-그리고-작성입니다. 웹 검색과 검색 도구를 가진 연구 에이전트가 구조화된 브리프를 생산하고, 도구 없는 작성 에이전트와 산문 프롬프트가 브리프를 기사로 바꿉니다. 작성 에이전트는 잘못된 시작, 버려진 출처, 긴 추론 사슬을 보지 않습니다. 브리프를 봅니다. 두 단계는 다른 모델을 쓸 수 있으며 — 연구에는 강한 추론, 작성에는 강한 산문 — 비용은 각자가 필요한 곳에서만 쌓입니다. 점진적 정제는 가까운 사촌입니다. 초안, 편집, 사실 확인, 재포매팅. 전문 운영자가 한 번에 모두 하려는 제너럴리스트를 이깁니다.

정직한 비용은 셋입니다. 지연 시간 — N 단계 파이프라인의 바닥은 단계 런타임의 합과 같습니다. 긴 파이프라인은 정의상 대화형 지연 시간에서 자기를 배제합니다. 오류 증폭 — 단계당 95%인 4단계 파이프라인은 끝에서 끝까지 81%이고, 8단계는 66%입니다. 유계 재시도가 있는 단계별 검증이 수학을 운영 가능하게 유지합니다. 단계 사이의 정보 손실 — 각 출력은 필연적으로 작업 컨텍스트보다 좁고, 작성 에이전트가 나중에 필요하다고 깨닫는 정보는 브리프 스키마가 엄격히 요구된 것보다 더 풍부하지 않다면 사라집니다.

6.3 동시 오케스트레이션: 산, 수집, 다관점

동시 오케스트레이션은 여러 에이전트를 병렬로 돌리고 출력을 합칩니다. 정의적 속성은 작업 동안의 인과 의존성 없음입니다 — 의존성은 합치는 단계에만 있습니다. 때로는 산-수집, 때로는 에이전트를 위한 맵-리듀스라 부르지만 토폴로지는 같습니다.

세 가지 사용 사례가 이 패턴을 동기합니다. 독립적인 하위 작업에 대한 병렬성 — 다섯 출처를 병렬로 읽고, 다음에 한 합성자. 벽시계 시간은 가장 느린 독자에 합성자를 더한 것이지, 합이 아닙니다. 다관점 분석 — 같은 입력을 재무 분석가 프롬프트, 법무 검토자 프롬프트, 제품 전략가 프롬프트에 주되, 출력이 단지 미용적 변종이 아니라 진짜로 다른 프레이밍을 가지도록. 신뢰성을 위한 앙상블링 — 같은 프롬프트를 여러 에이전트에 걸쳐 돌리고 출력을 투표나 평균. 틀린 답이 3배의 토큰 청구서보다 훨씬 비쌀 때 변호할 수 있습니다.

합치는 단계가 엔지니어링 노력이 보상받는 자리입니다. 길고 모순된 입력을 받은 순진한 합성자는 병목이 됩니다. 세 패턴이 그것을 개선합니다. 합성자가 산문을 다시 읽는 대신 결정적으로 필드를 병합할 구조화된 중간 출력, 부채살이 자라면서 각 합치는 에이전트가 유계 수의 입력을 보도록 하는 계층적 축소, 그리고 합성자가 조용히 편을 들기보다 의견 차이에 라벨을 붙이는 충돌 표면화.

산-수집이 알맞은지에 대한 진단 질문: 한 병렬 에이전트에게 다른 에이전트가 지금 생산 중인 것을 알리면 출력이 바뀌겠습니까? 그렇다면 그 일은 독립적이지 않았고 패턴이 틀렸습니다 — 순차적 의존성이나 제7장의 동적 패턴이 필요합니다.

6.4 조율의 정직한 수학

모든 오케스트레이션 패턴은 런타임에 신뢰할 수 없는 작업자 위의 분산 워크플로입니다. 호출당 실패율 1~5%는 품질 모델에서도 일반적입니다 — JSON 파싱 실패, 계약 위반, 환각된 도구 이름, 조용한 건너뛰기. 파이프라인을 통해 곱하면, 단계당 2%인 8단계는 끝에서 끝까지 85%입니다. 완화책은 구조적입니다. 유계 재시도를 촉발하는 단계별 검증, 입력·출력·지연 시간·토큰 지출·통과한 검증 게이트를 기록하는 단계별 관측 가능성, 그리고 소진된 재시도 예산이 전체 흐름을 무너뜨리는 대신 우아하게 저하되도록 하는 유계 폴백.

지연 시간 예산은 바닥뿐 아니라 천장도 필요합니다 — 사용자는 평균에 신경 쓰지 않고 긴 꼬리에 신경 씁니다. 비용 예산은 앞서 모델이 필요합니다. 2단계 파이프라인은 1단계 등가물의 약 1.5배 비용, 다섯 가지에 걸친 산-수집은 5~8배, 라운드테이블은 10배 이상. 일부 시스템은 상호작용당 비용이 상호작용의 가치를 넘어서기에 스케일에서 실행 가능하지 않습니다. 청구서가 도착한 뒤가 아니라 설계 시간에 산수를 하십시오.

제6장이 준비하는 것

순차와 동시는 빌딩 블록입니다. 작업 토폴로지가 사전에 알려져 있고 작업자의 역할이 고정될 때 대부분의 다중 에이전트 사용 사례를 처리합니다. 둘은 가정을 공유합니다. 설계 시간의 누군가가 에이전트가 무엇이고 어떻게 연결되는지를 결정했다는 가정. 오케스트레이션은 정적입니다. 파이프라인은 어떤 사용자 요청이 도착하기 전에 그려집니다. 제7장은 그 가정을 치웁니다.

다음 → 제7장: 고급 협업 및 동적 패턴. 라운드테이블, 핸드오프 라우팅, 마젠틱 오케스트레이션 — 토폴로지가 설계가 아니라 요청별로 만들어져야 할 때 무엇이 일어나는지, 그리고 더 단순한 패턴이 피하는 실패 모드(비종료, 잘못된 라우팅, 폭주 계획).