GeekNews에서 44포인트를 받은 글이 있었습니다.

제목은 “최고의 직원을 관리자로 올리면 왜 실패하는가”였습니다.

이 질문은 에이전트 오케스트레이션에 그대로 적용됩니다.

실행 능력과 조율 능력은 다른 레이어다

에이전트를 처음 도입할 때 자연스럽게 드는 생각이 있습니다. “가장 잘하는 에이전트에게 전체를 맡기자.” 단일 고성능 모델에 큰 태스크를 통째로 주고 알아서 해결하게 하는 패턴입니다.

여기서 생기는 문제는 단순합니다. 실행 능력이 높은 에이전트일수록 자신이 직접 처리하려는 경향이 강해집니다. 오케스트레이터의 역할은 실행이 아닙니다. 무엇을 어느 에이전트에게 줄 것인지, 결과를 어떤 순서로 검증할 것인지, 어디서 흐름을 멈출 것인지를 결정하는 일입니다. 이것은 다른 종류의 능력입니다.

최고의 엔지니어를 팀장으로 올렸을 때 팀 전체 성과가 오히려 줄어드는 현상과 구조가 같습니다.

분리가 성능을 만든다

Grok은 2026년 4월 4.20 업데이트에서 4개의 특화 에이전트(조정·팩트체크·논리·창의)를 병렬 검증 구조로 묶었습니다. 결과는 환각률 65% 감소였습니다. 하나의 뛰어난 모델보다, 역할을 분리한 4개 에이전트의 교차 검증이 훨씬 안전했습니다.

OpenAI의 세금 처리 에이전트 사례도 방향이 같습니다. 단일 에이전트 구조에서 25%에 머물던 정확도가, production trace에 피드백을 붙인 eval 루프를 돌리자 6주 만에 86%까지 올랐습니다. 잘하는 에이전트를 고른 것이 아니라, 검증 흐름을 설계한 결과였습니다.

두 사례의 공통점은 분명합니다. 오케스트레이터는 실행에서 한 발 물러나 있어야 합니다.

이해는 위임할 수 없다

안드레이 카파시는 이렇게 표현했습니다.

“Outsource thinking, not understanding.”

생각(thinking)은 에이전트에게 맡길 수 있습니다. 하지만 이해(understanding) — 어느 흐름이 맞는지, 어디가 어긋났는지를 감지하는 레이어 — 는 위임이 안 됩니다.

오케스트레이터가 이해 레이어를 가지고 있어야 한다는 말입니다. 가장 잘하는 에이전트는 자신이 실행하는 일에 집중합니다. 전체 흐름을 조율하는 역할은 실행에서 한 발 빠진 주체가 해야 합니다. PM이 그 자리를 맡아야 하는 이유가 여기 있습니다.

오케스트레이터 설계에서 기억할 세 가지

멀티에이전트 구조를 짤 때 실제로 도움이 됐던 원칙입니다.

태스크 범위를 좁게 정의한다. 에이전트마다 처리 범위가 넓을수록 실수가 퍼집니다. 범위를 좁히면 검증이 쉬워집니다.

검증 에이전트를 실행 에이전트와 분리한다. Grok의 65% 수치는 이 분리의 효과입니다. 실행과 검증이 같은 에이전트 안에 있으면 자기 출력을 스스로 검토하는 구조가 됩니다.

흐름을 멈추는 조건을 명시한다. 언제 멈출지 모르는 오케스트레이터는 자율이 아니라 방임입니다. 멈춤 조건이 설계 안에 있어야 합니다.

잘하는 에이전트를 어디에 쓸 것인가

오케스트레이터 역할을 설계할 때 드는 질문이 있습니다. 그러면 잘하는 에이전트는 어디에 써야 하는가.

정확한 자리가 있습니다. 좁고 명확하게 정의된 태스크에 넣는 것입니다. 오케스트레이터가 설계한 흐름 안에서 특정 구간의 실행을 맡겼을 때, 뛰어난 에이전트의 성능이 제대로 발현됩니다.

잘하는 에이전트를 모으는 것과, 그 에이전트들이 제 역할을 하도록 구조를 만드는 것은 다른 작업입니다. 첫 번째는 선택의 문제이고, 두 번째는 설계의 문제입니다.

지금 당신의 시스템에서 오케스트레이터 역할은 누가 담당하고 있습니까?