에이전트 설계를 처음 시작하는 팀이 가장 먼저 묻는 질문이 있습니다.

“어떤 모델을 써야 할까요?”

틀린 방향에서 시작하는 질문입니다.

AgentRadio가 최근 공개한 실측 결과가 이것을 명확히 보여줬습니다. 조정(coordination)·팩트체크(fact-check)·논리(logic)·창의(creative) 역할로 분화된 4개 에이전트 팀이, 동일 작업에서 단독 Claude Opus 4.8보다 일관되게 나은 결과를 냈습니다.

모델을 더 좋은 것으로 교체한 게 아닙니다. 역할을 설계한 것입니다.

데이터는 같은 곳을 가리킵니다

AgentRadio 결과 하나만 있었다면 흥미로운 예외로 넘길 수 있었습니다. 그런데 비슷한 시기에 스탠퍼드 연구팀이 다른 실험에서 같은 결론에 도달했습니다.

3만 7천 개 에이전트를 이용해 가상 바이오테크 회사 전체를 시뮬레이션한 실험이었습니다. 연구 가설 수립부터 임상 설계, 규제 준비까지 전 과정을 에이전트 팀으로 처리했습니다. 단일 모델이 같은 과제를 처리할 때와 결과가 달랐습니다.

arXiv 논문(2608.07457)은 이 차이의 근거를 “집단 동역학(collective dynamics)“이라고 명명했습니다. 역할이 분화된 에이전트들이 서로 상호작용할 때 단독 실행에는 존재하지 않는 검증 루프와 오류 보정이 자연스럽게 생긴다는 것입니다.

Grok는 이 원리를 제품에 적용했습니다. 4.20 버전에서 동일한 응답을 4개 특화 에이전트가 병렬로 검증하게 했더니, 환각률이 65% 감소했습니다. 모델 가중치가 바뀐 게 아닙니다. 검증 구조가 바뀐 것입니다.

세 데이터 포인트가 하나의 결론으로 수렴합니다. 역할 설계 > 모델 선택.

왜 팀이 이기는가

단일 최강 모델에는 구조적 한계가 있습니다.

하나의 모델이 “작업 실행”과 “결과 검증”을 동시에 담당할 때, 자기 오류를 스스로 잡아내는 능력은 제한적입니다. 사람도 자신이 쓴 글을 바로 교정하기 어려운 이유와 같습니다. Karpathy가 에이전트 설계 원칙으로 지적한 것처럼 “에이전트의 자기 검증은 약하다(self-verification is weak)”. 역할 분리는 이 약점을 구조로 보완하는 접근입니다.

역할이 분화되면 세 가지가 달라집니다.

첫째, 과제 특화 압력이 작동합니다. 각 에이전트의 시스템 프롬프트와 컨텍스트가 좁아집니다. “모든 것을 잘 하라”는 지시보다 “팩트체크만 집중하라”는 지시가 실제 팩트체크 성능을 높입니다. 역할 범위가 좁을수록 모델의 주의(attention)가 집중됩니다.

둘째, 병렬 실행이 가능해집니다. 조정 에이전트가 구조를 짜는 동안 팩트체크 에이전트는 이미 클레임을 검증하고 있습니다. 단일 모델이 순차적으로 처리해야 하는 흐름과 속도가 다릅니다. 스탠퍼드의 3.7만 에이전트 실험이 가상 바이오테크 회사 전체를 현실적인 시간 안에 시뮬레이션할 수 있었던 핵심 이유 중 하나입니다.

셋째, 외부 검증이 내장됩니다. 창의 에이전트가 생성한 결과를 논리 에이전트가 별도 실행으로 평가합니다. 자기 참조 오류(self-reference error)가 차단됩니다. 생성한 주체와 검증하는 주체가 다르면, 검증은 형식이 아니라 실질이 됩니다.

PM이 물어야 할 진짜 질문

에이전트 도입 프로젝트에서 가장 많은 예산이 모델 선택에 들어가는 이유가 있습니다. 모델은 보이고, 역할은 보이지 않기 때문입니다.

Anthropic의 Claude Code든, OpenAI의 Codex든 — 동일 모델을 써도 어떤 팀은 결과를 만들고, 어떤 팀은 잘 짜인 데모 이상을 넘지 못합니다. 차이는 역할 설계에 있습니다.

PM이 에이전트 시스템을 설계할 때 실제로 물어야 할 질문은 세 가지입니다.

어디서 단독 실행이 실패하는가?

에이전트가 작업을 끝까지 처리하다가 품질이 떨어지는 지점을 먼저 찾아야 합니다. 그 지점이 역할 분리가 필요한 곳입니다. 팩트가 많은 구간, 판단이 필요한 구간, 창의가 필요한 구간은 요건이 다릅니다. 단일 모델에 전 구간을 맡기는 것은 팀에서 가장 뛰어난 한 사람에게 기획·개발·QA를 혼자 담당하게 하는 것과 같습니다.

어디서 검증 루프가 끊기는가?

에이전트가 생성한 결과를 같은 에이전트가 평가한다면, 검증은 형식에 그칩니다. 생성과 검증을 다른 역할로 분리하는 순간, 실질적인 품질 제어가 시작됩니다. 셀렉트스타가 NH농협 프로젝트에서 검증 사이클을 60일에서 50분으로 단축한 것도 이 원리를 적용했기 때문입니다. 검증 전담 에이전트를 흐름에 배치했을 뿐인데 전체 사이클 시간이 달라졌습니다.

핸드오프 조건이 명시되어 있는가?

역할 분리가 설계됐어도, 각 에이전트가 언제 다음 에이전트에게 넘겨줄지 조건이 불명확하면 루프가 발생합니다. “초안 완성 시 핸드오프”가 아니라 “팩트체크 통과 + 길이 기준 충족 시 핸드오프”처럼 명시적 전이 조건이 필요합니다. 조건이 모호하면 에이전트는 반복하거나 건너뜁니다.

오케스트레이션 설계가 제품의 본체입니다

IBM은 이번 분기 AI 격차를 진단하며 이렇게 결론 내렸습니다. “AI 격차는 모델 격차가 아니라 운영 모델 격차다.”

에이전트 도입이 가속되는 지금, 이 말의 무게가 달라집니다.

모델이 상향 평준화되면서 동일 가격대 모델들 간 성능 차이가 빠르게 좁혀지고 있습니다. Claude Opus, GPT-5.5, Gemini 3.5 Pro — 어떤 모델을 쓰느냐보다 어떻게 역할을 나누고 검증을 배치하느냐가 결과를 결정하는 시대로 넘어가고 있습니다. AgentRadio 실측은 이 흐름의 증거 데이터입니다.

에이전트 시스템의 경쟁력은 모델이 아니라 오케스트레이션에서 나옵니다. 좋은 오케스트레이터는 최강 단독 에이전트보다 낫습니다.

팀 설계가 모델 선택보다 먼저 와야 하는 이유입니다.

당신의 에이전트 시스템에서 생성과 검증을 같은 모델이 담당하고 있나요? 역할 분리가 어디서 시작해야 하는지, 구체적으로 그려본 적 있으신가요?