06장. 멀티 에이전트 오케스트레이션 패턴

단일 모델 호출 한 번으로 끝나는 작업은 아키텍처를 고민할 필요가 없다. 그러나 작업이 여러 단계로 나뉘고, 단계마다 판단이 갈리며, 여러 갈래를 병렬로 처리한 뒤 결과를 합쳐야 하는 순간부터 "어떤 구조로 묶을 것인가"가 시스템의 정확도와 비용, 신뢰성을 결정한다. CCA-F 시험에서 가장 큰 비중(27%)을 차지하는 에이전트 아키텍처와 오케스트레이션 도메인은 바로 이 선택을 묻는다. 즉 "이 작업에 어떤 패턴이 정답인가"와 "왜 더 단순한 구조로는 안 되는가"를 동시에 요구한다.

이 장은 그 선택을 두 개의 실행 표면(execution surface) 위에서 정리한다. 하나는 Claude API와 도구 사용(tool use)을 직접 조합해 루프를 내가 돌리는 워크플로우 방식이고, 다른 하나는 Anthropic이 에이전트 루프와 컨테이너를 호스팅하고 코디네이터가 서브에이전트에 위임하는 Managed Agents 방식이다. 시험은 단일 호출에서 워크플로우로, 다시 에이전트로 올라가는 의사결정 트리에서 멈춰야 할 지점을 정확히 짚는지를 본다. 가장 단순한 계층에서 시작해, 작업이 그것을 정말로 요구할 때만 위로 올라가라는 것이 핵심 원칙이다.

이 장을 마치면 프롬프트 체이닝과 라우팅으로 코드 주도 워크플로우를 설계할 수 있고, 오케스트레이터-워커 패턴으로 동적 분해 작업을 다룰 수 있으며, Managed Agents의 코디네이터-서브에이전트 구조로 작업을 분해하고, 멀티 에이전트 실행 전체를 프로비넌스(provenance) 관점에서 추적·감사할 수 있다. 또한 각 패턴이 실패하거나 과잉설계가 되는 경계를 시험 출제 관점에서 식별할 수 있다.