모델 4개 묶은 오케스트레이션, 단일 모델에 완패

강한 모델에게 지휘를 맡기고 값싼 모델에게 일을 시키라는 통념이 실측에서 뒤집혔다. 데이터 인프라 회사 퀘즈마(Quesma)의 바르토시 코트리스(Bartosz Kotrys)가 클로드 코드(Claude Code) 안에 클로드 모델 4개를 역할별로 묶어 터미널 벤치(Terminal-Bench) 2.1을 돌린 결과, 단일 모델보다 두 배 가까운 비용을 쓰고도 더 낮은 점수를 받았다. 실패 원인 네 가지가 낱낱이 공개돼, 멀티에이전트를 설계하는 사람이라면 곱씹을 가치가 있다.

무슨 일인가

실험 구성은 이렇다. 페이블 5(Fable 5)가 계획과 위임만 하는 오케스트레이터, 하이쿠(Haiku) 4.5가 읽기 전용 정찰, 오푸스(Opus) 5가 실제 편집·빌드 실행, 소네트(Sonnet) 5가 검증을 맡았다. 별도 프레임워크 없이 지침 파일과 에이전트 정의 파일 3개만으로 묶은 순수 배선 실험이다. 89개 실전 터미널 과제를 5회씩 시도하는 공식 조건에서 결과는 정답률 78%, 리더보드 7위, 비용 1,178달러였다. 같은 벤치마크 1위인 클로드 코드+페이블 5 단일 구성은 83.8%를 기록했다.

핵심 짚어보기

역효과는 네 갈래였다. 첫째, 위임 구조 자체가 모델의 거절을 유발했다. 보안 관련 과제 3개(비밀번호 복구 등)를 실행 담당 오푸스가 다섯 번 모두 거부했는데, 같은 모델에게 직접 시키면 셋 다 풀었다. 맥락이 잘린 채 전달된 지시가 수상해 보였던 것이다. 이 3개만 인정받았어도 80.5%로 3위에 올랐다. 둘째, 선택 사항으로 둔 검증 단계를 오케스트레이터가 건너뛰었고, 검증 없이 넘어간 작업의 성공률은 절반으로 떨어졌다. 셋째, 가장 비싼 모델이 호출량이 가장 많은 자리(실행 담당)에 앉으면서 비용이 치솟았다. 넷째, 위임 횟수가 6회를 넘어가면 비용은 4배 가까이 들면서 성공률은 절반이 됐다.

1인기업 실전 적용 포인트

• 기본값은 단일 모델: 자동화 파이프라인을 짤 때 처음부터 다단 위임 구조를 만들지 말자. 이 벤치마크 상위권은 전부 단일 모델 구성이었다.
• 검증은 강제로: 리뷰·검수 단계를 '필요하면 하라'고 두면 실제로는 생략된다. 콘텐츠 발행 자동화라면 검수를 옵션이 아니라 발행 통과 조건으로 박아야 한다.
• 위임 깊이에 상한: 에이전트 간 핸드오프가 5~6회를 넘으면 중단하고 사람이 개입하거나 단일 세션으로 재시작하는 회로 차단기를 넣자.
• 역할과 단가 맞추기: 호출량이 많은 자리에 싼 모델을 배치하는 게 상식이지만, 실제 호출량 분포는 돌려보기 전엔 모른다. 실행 로그로 확인한 뒤 재배치하는 게 맞는 순서다.

전망 / 주의점

이 실험이 멀티에이전트 무용론은 아니다. 비교 공정성을 위해 지시문을 의도적으로 최소화한 실험이라, 프롬프트를 다듬으면 격차는 줄어들 수 있다. 다만 구조를 더한다고 성능이 따라오는 게 아니라, 구조가 새로운 실패 지점을 만든다는 교훈은 일반적이다. 에이전트 팀을 꾸리기 전에, 그 팀이 정말 필요한지부터 작은 벤치마크로 확인하는 습관이 필요하다.

출처: Quesma Blog (https://quesma.com/blog/tbench-orchestrator-refuses/)