“팀에서 가장 뛰어난 직원을 매니저로 올리면 최악의 관리자가 된다.”

경영학에서 오래된 경고입니다. 이 명제가 GeekNews에서 44점 1위를 기록한 날, 저는 멀티에이전트 시스템 설계 작업 중이었습니다. 화면에는 에이전트 흐름도가 펼쳐져 있었고, 저는 정확히 같은 실수를 다른 형태로 만들고 있었습니다.

가장 성능이 좋은 모델을 오케스트레이터 자리에 배치해 두고 있었습니다.

왜 이 선택이 자연스럽게 느껴지는가

직관적으로는 맞는 것처럼 보입니다. 오케스트레이터는 전체 흐름을 책임지는 역할입니다. 복잡한 상황을 판단하고, 하위 에이전트들의 결과를 평가하고, 다음 단계를 결정해야 합니다. 그렇다면 가장 똑똑한 모델이 그 자리를 맡아야 하지 않을까요?

문제는 “가장 똑똑하다”는 것이 “스스로 처리할 수 있다”는 것과 같다는 점입니다. 그리고 처리할 수 있다는 것을 아는 모델은 처리하려 합니다.

Andrej Karpathy가 에이전트 협업을 설명하면서 한 말이 있습니다. “생각을 위임할 수 있지만 이해는 위임할 수 없다(outsource thinking but not understanding).” 이 원칙의 역방향이 오케스트레이터 설계에서 반복되는 함정입니다. 이해를 포기하지 못하는 오케스트레이터는 위임을 포기합니다.

100 Agents에서 직접 겪은 일

22개 에이전트로 구성된 시스템을 운영하면서 초기 설계에서 오케스트레이터 역할에 가장 능력이 뛰어난 모델을 배치했습니다. 결과는 예상과 달랐습니다.

오케스트레이터가 하위 에이전트에게 작업을 넘긴 뒤에도 결과를 직접 수정하거나, 이미 완료된 단계를 재처리하거나, 하위 에이전트의 판단을 덮어쓰는 패턴이 반복됐습니다. 시스템 전체 지연이 늘었고, 특정 에이전트의 출력이 오케스트레이터 개입으로 일관성을 잃었습니다.

오케스트레이터에게 “잘하는 능력”은 있었지만 “위임의 경계”가 없었습니다.

패턴을 진단하면 이렇습니다. 오케스트레이터는 하위 에이전트가 “충분히 좋은” 결과를 내도 자신이 “더 잘할 수 있다”는 것을 알기 때문에 개입합니다. 하위 에이전트 결과가 70점이고 자신이 95점을 낼 수 있다면, 자연스럽게 그 30점 차이를 메우려 합니다. 이것은 모델의 결함이 아닙니다. 학습된 대로 행동하는 것입니다.

문제는 그 30점을 메우려는 행동이 시스템 전체 비용과 일관성을 무너뜨린다는 데 있습니다. 오케스트레이터의 역할은 95점짜리 결과를 직접 만드는 것이 아닙니다. 70점짜리 결과가 나올 수 있는 에이전트를 올바른 자리에 배치하고, 핸드오프 조건이 충족되면 다음 단계로 넘기는 것입니다.

이것은 기술 문제가 아닙니다. 설계 문제입니다.

오케스트레이터 설계의 세 가지 변수

저는 오케스트레이터 에이전트를 설계할 때 세 가지 축을 씁니다.

의도 명확성(Intent Clarity): 오케스트레이터는 “무엇을 할지”보다 “무엇을 결정할지”를 정의합니다. 실행 방법은 하위 에이전트의 영역입니다. 오케스트레이터의 시스템 프롬프트에 “직접 처리할 수 있는 조건”을 명시하는 것이 출발점입니다.

경계 설계(Boundary): 오케스트레이터가 개입할 수 있는 조건과 개입해서는 안 되는 조건을 명시합니다. 이 경계가 없으면 고성능 모델은 본능적으로 최선을 다해 모든 것을 직접 처리하려 합니다. 능력이 있기 때문에.

간단한 예를 들면 이렇습니다. 오케스트레이터 시스템 프롬프트에 이런 규칙을 넣습니다.

[위임 규칙]
- 데이터 변환: data-agent에게만 위임, 결과 수정 금지
- 콘텐츠 생성: content-agent에게만 위임, 직접 생성 금지
- 오케스트레이터 개입 허용 조건: 에이전트 타임아웃(30초 초과), 에러 코드 반환, 핵심 컨텍스트 누락

이것이 없으면 오케스트레이터는 매번 “이번엔 내가 처리하는 게 낫겠다”고 판단합니다.

핸드오프 프로토콜(Handoff Protocol): 어떤 신호가 오면 다음 에이전트로 넘기는지를 명시합니다. 핵심은 “완벽한 결과물”이 핸드오프 조건이 되어서는 안 된다는 것입니다. 완벽하지 않아도 조건이 충족되면 넘깁니다. 이 원칙이 없으면 오케스트레이터는 핸드오프를 미루고 직접 완성하려 합니다.

가장 강력한 오케스트레이터는 가장 뛰어난 모델이 아닙니다. 이 세 가지가 가장 명확하게 설계된 에이전트입니다.

이번 주 Google I/O의 신호

이번 주 Google I/O에서 Gemini Spark가 공개됐습니다. Gmail을 24시간 모니터링하며 사용자 요청 없이도 먼저 행동하는 백그라운드 에이전트입니다.

눈여겨볼 것은 Gemini Spark가 “혼자서 모든 것을 처리하는” 단일 슈퍼 에이전트가 아니라는 점입니다. Gmail, Calendar, Drive, Search 각각의 영역에 특화된 하위 에이전트들을 조율하는 구조입니다.

빅테크도 같은 결론에 도달했습니다. 단일 고성능 에이전트가 아니라 역할이 분리된 에이전트들의 조율이 실용적인 답입니다.

하지만 Gemini Spark가 성공하는 조건과 실패하는 조건은 같습니다. 오케스트레이터가 하위 에이전트의 결과를 신뢰하고 위임할 수 있도록 경계가 설계됐는가, 아닌가. 이 설계가 없으면 24시간 백그라운드 에이전트는 24시간 오케스트레이터 병목으로 작동합니다.

PM이 설계해야 할 것

에이전트 오케스트레이션에서 PM이 맡아야 할 역할은 “어떤 모델을 쓸 것인가”보다 “어떤 역할 구조를 만들 것인가”입니다.

가장 흔한 실수 두 가지입니다.

첫 번째는 오케스트레이터를 “중앙집권화”된 슈퍼 에이전트로 설계하는 것입니다. 결과는 오케스트레이터 병목, 단일 장애점, 그리고 하위 에이전트들의 역할 무력화입니다. 하위 에이전트는 배치되어 있지만 오케스트레이터가 직접 처리하기 때문에 실질적으로 쓰이지 않습니다.

두 번째는 오케스트레이터에게 능력만 주고 제약을 주지 않는 것입니다. 고성능 모델에게 오케스트레이터 역할을 부여하고 제약 없이 풀어놓으면, 그 모델은 직접 처리를 선택합니다. 능력이 있기 때문입니다.

잘 설계된 오케스트레이터의 특징은 반대입니다. “몰라도 넘길 수 있는” 에이전트입니다. 세부 정답을 생성할 필요가 없고, 언제 다음 에이전트로 넘겨야 할지를 판단합니다. 이것은 오케스트레이터의 능력을 제한하는 것이 아니라 역할을 명확하게 정의하는 것입니다.

20년 PM 경험에서 반복해서 본 패턴입니다. 최고의 실무자를 팀장으로 올리면 실무도 약해지고 팀 조율도 약해집니다. 그 사람이 무능해서가 아닙니다. 두 역할이 다른 근육을 필요로 하는데, 그 경계를 역할 설계에서 명시하지 않았기 때문입니다.

에이전트도 다르지 않습니다.

오케스트레이터 에이전트 검증 체크리스트

100 Agents 프로젝트에서 오케스트레이터를 검증할 때 쓰는 네 가지 질문입니다.

  1. 오케스트레이터가 직접 처리할 수 있는 조건이 시스템 프롬프트에 명시되어 있는가?
  2. 하위 에이전트 결과를 수정할 수 없는 조건이 설계되어 있는가?
  3. 핸드오프 트리거가 “완벽한 결과물”이 아닌 “충족 조건”으로 정의되어 있는가?
  4. 오케스트레이터 실패 시 우회 경로가 오케스트레이터를 거치지 않고 작동하는가?

이 네 가지가 없으면 고성능 모델을 오케스트레이터로 쓸수록 시스템이 취약해집니다. 역설적이지만, 오케스트레이터가 뛰어날수록 경계 설계가 더 중요합니다.

좋은 오케스트레이터를 설계하는 질문은 “어떤 모델을 쓸 것인가”가 아닙니다. “이 에이전트가 직접 처리하지 않도록 무엇을 설계할 것인가”입니다.

당신의 멀티에이전트 시스템에서 오케스트레이터 에이전트는 지금 실제로 무엇을 하고 있습니까?

위임하고 있습니까, 아니면 직접 처리하고 있습니까. 그 차이가 시스템 전체의 확장성을 결정합니다.