Vibe Code Bench, 에이전트 팀 비용 1.8~5.1배 증가…점수 개선은 제한적

비용 및 성능 지표

Vibe Code Bench에서 GPT-6 Sol과 Claude Opus 5.5를 대상으로 단일 에이전트와 멀티 에이전트 팀의 성능을 비교한 사례 연구가 공개됐다. 연구 결과, 에이전트 팀은 단일 에이전트 대비 비용을 1.8배에서 5.1배까지 증가시켰으며, 통계적으로 유의미한 점수 개선은 GPT-6 Sol의 중간(medium) 추론 설정에서만 관찰됐다.

• GPT-6 Sol (medium): 단일 에이전트는 비용 $1.22, 점수 **77.6%**를 기록한 반면, 팀은 비용 $3.07, 점수 **84.9%**를 기록했다. 팀은 +7.3점의 개선을 보였으며 이는 통계적으로 유의미하다(p=0.005).
• GPT-6 Sol (max): 단일 에이전트는 비용 $4.82, 점수 **89.0%**를 기록했고, 팀은 비용 $8.54, 점수 **90.4%**를 기록했다. +1.4점의 상승은 통계적으로 유의미하지 않았다.
• Claude Opus 5.5 (medium): 단일 에이전트는 비용 $4.08, 점수 **91.5%**를 기록했으며, 팀은 비용 $9.10, 점수 **91.2%**를 기록했다. 팀은 -0.3점의 변화를 보였고 유의미하지 않았다.
• Claude Opus 5.5 (max): 단일 에이전트는 비용 $23.77, 점수 **89.8%**를 기록한 반면, 팀은 비용 $122.00, 점수 **93.2%**를 기록했다. +3.4점의 상승은 통계적으로 유의미하지 않았다.

런타임 및 비용 요인

팀 비용 증가의 주된 원인은 각 하위 에이전트로의 컨텍스트 재전송으로 인한 **캐시된 입력 토큰(cached input tokens)**이었다. Opus max 팀의 경우 앱당 캐시 토큰 중위값이 2억 2400만 개로, 단일 에이전트의 5500만 개보다 훨씬 높았다.

모델별 런타임 동작은 다음과 같이 갈렸다:

• GPT-6 Sol: 병렬 처리로 인해 팀이 더 빨랐다. medium 설정에서 팀은 11.4분으로 단일 에이전트(12.4분)보다 빠르며, max 설정에서는 팀이 27.4분으로 단일 에이전트(38.4분)보다 빨랐다.
• Claude Opus 5.5: 팀이 더 느렸다. 팀은 가장 느린 멤버를 기다리는 순차적 웨이브 방식으로 작동했다. max 설정에서 팀은 174.1분이 소요되어 단일 에이전트(74.7분)보다 훨씬 오래 걸렸다.

에이전트 팀 구조

리드 에이전트는 다른 위임 전략을 사용했다:

• GPT-6 Sol Lead: DB, API, UI 등 아키텍처에 따라 작업을 분할하고 즉시(약 1분 내) 하위 에이전트를 생성했다. 50회 실행 중 46회에서 헤드리스 브라우저를 통해 테스트를 수행해 스키마 불일치 같은 통합 버그를 식별했다.
• Claude Opus 5.5 Lead: 작업 시작 전 50회 중 40~42회에서 CONTRACT.md 파일(스키마, API 라우트, 파일 소유권 정의)을 생성했다. 하위 에이전트는 기본 구조 -> 기능 -> 테스트 순서의 순차적 웨이브로 생성됐다. max 설정에서는 앱당 하위 에이전트 수가 6.8개로 증가했으며 테스트 하위 에이전트가 포함됐다.

추론 노력 vs 팀 구조

고추론(high reasoning) 단일 에이전트와 중추론(medium reasoning) 팀을 비교하면 추론 노력 증가가 종종 더 효율적이었다:

• GPT-6 Sol: max 단일 에이전트(89.0%, $4.82)가 medium 팀(84.9%, $3.07)보다 성능이 좋았다. 추론 노력 증가(+11.4점)가 팀 구조 도입(+7.3점)보다 더 큰 개선을 가져왔다.
• Claude Opus 5.5: max 단일 에이전트(89.8%)는 medium 단일 에이전트(91.5%)보다 점수가 낮았다. max 팀(93.2%)이 최고 점수를 기록했지만 비용은 $122.00으로 매우 높았으며, 이는 medium 단일 에이전트 대비 3.4배의 비용 증가를 의미한다.

방법론 및 한계

연구는 GPT-6 Sol에 OpenAI Agents API를, Claude Opus 5.5에 Claude Code CLI 헤드리스 모드를 사용했다. 평가는 Vibe Code Bench 표준 UI 테스트 스위트를 기반으로 했다. 주요 한계점은 다음과 같다:

• 단일 실행 제약: 각 설정은 한 번만 실행되어 신뢰 구간은 앱 간 변동을 반영할 뿐, 반복 실행 간 변동은 반영하지 못한다.
• 프롬프트 차이: 팀 실행에는 위임 프롬프트가 포함되었으므로, 비교는 사실상 '단일 에이전트' vs '하위 에이전트 + 위임 프롬프트'였다.
• 하네스 차이: 서로 다른 도구를 사용함으로써 모델 효과와 하네스 효과가 혼합될 수 있다.