이 글은 [저의 이전 포스트: "비싼 모델이 모든 것을 하게 하지 마세요 — 표준 기능(skills)을 기반으로 구축된 캐주얼 멀티 모델 설정인 'delegate-skills'"(https://dev.to/kiou_ouba_afbd120335456f3/dont-make-the-expensive-model-do-everything-delegate-skills-a-casual-multi-model-setup-built-on-1c9j)]의 후속 글입니다. 해당 포스트에서는 부모 에이전트가 다른 벤더의 CLI 자식 모델에게 작업을 외주(outsource) 주는 메커니즘인 delegate-skills를 소개했습니다.

godot-llm-gamebench는 전체 "외주(outsourcing)" 워크플로우를 측정하는 벤치마크입니다. 부모 에이전트(예: Claude Code의 Fable)가 구현 작업을 자식 에이전트에게 위임할 때, 어떤 모델에게 맡기는 것이 가장 좋을까요? 정확히 동일한 Godot 게임 구현 작업이 이전 포스트에서 소개된 delegate-implement 스킬을 통해 부모 에이전트(Claude Code)로부터 다양한 벤더의 CLI 뒤에 있는 18개의 자식 모델에게 위임되며, 각 실행은 숨겨진 테스트에 대한 자동 채점 및 측정된 지표를 통해 두 가지 축 — 품질(quality)과 효율성(efficiency) — 을 따라 측정됩니다.

작업: "Conveyor Courier" — 독창적이고 오염되지 않은 사양

만약 작업이 Tetris와 같이 잘 알려진 게임이라면, 모델이 학습 데이터에서 "정답을 이미 본" 가능성을 배제할 수 없습니다. 따라서 이 벤치마크는 Conveyor Courier라고 불리는 독창적인 퍼즐을 사용합니다.

• 8×8 그리드 위의 컨베이어 벨트를 따라 색상이 있는 패키지들이 흐릅니다.
• 플레이어는 벨트를 배치하고 회전시켜 경로를 구축하며, 빨간색 패키지는 빨간색 출구로, 파란색 패키지는 파란색 출구로 배달해야 합니다.
• 게임 전체가 **틱 기반 (tick-driven)**으로 작동합니다: 120틱의 실행 동안 매 3틱마다 패키지가 생성됩니다.
• 이동은 결정론적인(deterministic) 2단계 프로세스(출구 해결 → 아무것도 움직이지 않을 때까지 이동 단계 반복)이며, 분기기(splitters)는 패키지가 실제로 분기기를 떠날 때만 왼쪽/오른쪽을 전환합니다. 즉, 명세(spec)는 정확히 읽지 않고서는 도저히 추측할 수 없는 세부 사항들로 가득 차 있습니다.

구현은 Godot 4.x + **타입 지정 GDScript (typed GDScript)**를 사용하며, 숨겨진 테스트가 호출하는 BoardModel API(setup / step_tick / 벨트 배치 및 회전 / spawn_item 등)만이 공개 계약(public contract)으로 고정되어 있습니다. 작업 프롬프트는 benchmarks/tasks/conveyor-courier/prompt.md로 동결되어 있으며, 모든 반복 실험에서 모든 모델에 동일한 바이트 단위의 텍스트가 전달됩니다.

이 벤치마크를 읽을 때 반드시 유의해야 할 사항

결과 표로 넘어가기 전에, 이 측정이 무엇을 측정하고 무엇을 측정하지 않는지를 명확히 밝히고자 합니다. 각 모델의 능력을 더 정확하게 파악하고 싶다면, 서로 다른 특성을 가진 여러 벤치마크를 교차 참조하는 것을 권장합니다.

ReactBench 블로그

Artificial Analysis

• 직접적으로 측정되는 것은 "Godot에서 퍼즐 게임을 구현하는 능력"입니다. 동일한 구현 작업이라 하더라도, 예를 들어 React UI 구현 작업이었다면 순위가 바뀌었을 수 있습니다. 여기서 낮은 점수를 받은 일부 모델들은 단순히 Godot 학습 데이터가 부족할 뿐, 일반적인 구현 능력은 뛰어날 수 있습니다.
• 오늘날의 최상위 모델들조차 더 어려운 자료에서는 순위가 하락할 수 있습니다. 이 벤치마크는 주로 명세(spec)를 정확하게 읽고 이를 구현으로 전환하는 능력을 테스트하며, 더 깊은 문제 해결 능력을 요구하는 작업에서의 상대적 강점은 측정하지 않습니다.
• 벤치마크 전체가 Fable에 의해 주도되었으므로, Anthropic 모델에 유리한 편향(bias)이 있을 수 있습니다.
• 이것은 모델 가중치(model weights)를 단독으로 측정하는 것이 아니라, "모델 + 실행 하네스(execution-harness) CLI"를 하나의 세트로 측정합니다. 동일한 모델이라도 다른 하네스에서는 다르게 작동할 수 있습니다. 예를 들어, Codex 기반의 gpt-5.5와 Cursor 기반의 gpt-5.5는 서로 다른 결과를 낼 수 있지만, 이러한 교차 비교는 수행되지 않았습니다.
• 각 모델의 표본은 n=3입니다. 실행 시마다 발생하는 변동성(variance)은 "모델의 특성"에 대한 어떠한 해석도 쉽게 뒤엎을 수 있습니다. 실제로 한 라운드에서 "매 반복마다 스플리터(splitter)를 실패하는 체계적인 습관이 있는 것"처럼 보였던 모델이, 재측정 시 3번의 실행 중 2번에서 만점을 받기도 했습니다. 모델별 "기벽(quirk)" 설명은 기껏해야 가설로만 읽어야 합니다.
• 자동 채점(Auto-grading)은 헤드리스(headless) 방식으로 검사 가능한 항목만 확인합니다. 초기 라운드에서는 "보드가 완전히 검은색이다", "클릭이 인식되지 않는다"와 같이 플레이가 불가능한 구현물들이 만점을 받으며 통과되었습니다. 사람이 실제로 플레이하며 이를 발견한 후, 3가지 뷰 동작(view-behavior) 테스트가 추가되었고 모든 실행 결과가 재채점되었습니다. 그럼에도 불구하고 "보드를 가리는 불투명한 배경"과 같은 렌더링 결함은 헤드리스 방식으로 감지할 수 없으며 여전히 남아 있습니다.

"시각적으로 플레이 가능한" 수준의 보장은 여전히 부분적입니다

• 모델마다 비용 산정의 정밀도가 다르며, 그 중 어느 것도 "실제로 지불하게 될 금액"은 아닙니다. 측정 방식은 CLI로 측정된 수치(Claude 제품군), 토큰 가격 변환(Codex / Cursor 제품군), 그리고 공개된 가격을 통한 추정치(Devin 제품군)가 혼합되어 있습니다. 실제 지출 비용은 계약 조건(정액제 플랜, 무료 미리보기 등)에 따라 크게 달라집니다. 여기에 기재된 USD 수치는 "종량제(pay-as-you-go) API 가격을 가정하여 모델 간 비교를 위해 사용하는 공통 척도"이며, 귀하의 청구서 예상 금액이 아닙니다.
• 코드 품질은 LLM에 의해 판정됩니다. 이 방식은 기본 판정 모델(claude-sonnet-5)과 독립된 벤더의 교차 검증(gpt-5.6-sol)을 사용하는 2인 판정 체계(two-judge scheme)를 사용하며, 중간 대역(3–4.5)에서는 판정자 간 ±0.5–1.0의 오차가 발생합니다.
• 이 데이터는 2026년 7월 초의 스냅샷입니다. 측정 기간 동안 CLI 버전은 고정되었습니다. 모델, CLI 및 가격이 업데이트됨에 따라 결과는 변경될 수 있습니다.

결과 (Results)

열 정의 및 회계 규칙은 아래 표의 주석에 있습니다. 더 자세한 수치는 impressions.md (일본어)를 참조하시고, 모델별 상세 코멘트는 impressions.md의 "benchmarked models" 섹션을 참조하십시오.

기준 조건 (위임 프로토콜을 거치지 않음; 참조용으로만 사용 — 위 표와 직접 비교하지 마십시오):

¹ 각 모델의 노력 수준(effort level)은 단일 기본값으로 고정되었습니다. 굵게 표시된 모델은 3번의 반복 실행 모두에서 숨겨진 테스트(70점 축)를 통과한 모델입니다.

² 100점 만점의 자동 채점 루브릭(rubric)을 3회 반복하여 합산한 점수(최대 300점): 수임자에게 공개되지 않는 숨겨진 테스트(70), 결정론 (determinism) (10), 타입 품질 (type quality) (10), 그리고 프로젝트 상태 (project health) (10).

³ 타이핑의 철저함, 모델/뷰 분리 (Model/View separation), 가독성, 상수 사용 등 설계 측면의 5점 척도 정성 평가 (3회 실행의 평균). 기본 판정자(claude-sonnet-5)와 교차 검증 판정자(gpt-5.6-sol)를 계층적으로 사용하였으며, 의견이 갈릴 경우 운영자(Fable)가 대표값을 판정하였습니다.

⁴ 자식 프로세스의 토큰 사용량(token usage)을 측정할 수 없었으므로, 자식 비용은 알 수 없습니다. 이는 부모 비용의 하한선일 뿐입니다 (실제 총비용은 더 높습니다). 비용 산점도(cost scatter plot)에서는 제외되었습니다.

산점도: 코드 품질(code quality) × 자동 채점 점수(auto-graded score)

Scatter plot of code quality × auto-graded score

산점도: 비용(cost) × 코드 품질(code quality)

Scatter plot of cost × code quality

주요 하이라이트 (Highlights)

토큰당 가격(Per-token price)과 작업당 비용(per-task cost)이 반드시 일치하는 것은 아닙니다. 단위 가격이 저렴하더라도, 모델이 더 많은 토큰을 소비하거나 시간이 오래 걸린다면(부모 측 비용을 팽창시킴) 결과적으로 더 많은 비용이 발생할 수 있습니다. 이번 벤치마크에서 devin-deepseek-v4-pro (입력 $1.74 / 출력 $3.48)는 gpt-5.5 (입력 $5 / 출력 $30) 가격의 1/3에서 1/9 수준이었지만, 입력 토큰을 약 두 배 더 소비하여 중앙값 기준 총비용이 $3.58로 gpt-5.5($3.48)보다 높게 나타났습니다. 가격표는 시작점일 뿐이며, 중요한 것은 실제 작업에서 발생하는 청구 금액입니다.

모든 리포지토리(rep)에서 기능 테스트(functional tests)를 통과하는 것이 최상위 모델만의 전유물은 아닙니다. 4개의 모델이 3번의 반복 실험 모두에서 숨겨진 테스트(70점 축)를 통과했습니다: claude-sonnet-5 / gpt-5.5 / cursor-grok-4.5 / claude-opus-4-8 (표에서 굵게 표시됨). 하지만 합계 300점에 도달한 것은 fable-direct 베이스라인뿐이었으며, 위임된 모델들을 갈라놓은 결정적인 차이는 품질 유형(type-quality) 축이었습니다.

기능 테스트 결과가 동일하더라도 코드 품질(code quality)은 갈립니다. 앞서 언급한 4개의 전원 통과 모델 중, gpt-5.5는 4.0점을, claude-sonnet-5는 3.8점을 기록한 반면, claude-opus-4-8은 3.5점, cursor-grok-4.5는 3.3점에 머물렀습니다. 이것이 차트에서 나타나는 수직적 분포입니다. 단순히 테스트를 통과하는 코드가 아니라 유지보수가 가능한 코드를 원한다면, 이 축을 선택 기준에 포함할 가치가 있습니다.

기본값은 claude-sonnet-5입니다. 명확한 이점이 있는 경우에만 변경하십시오. 가장 높은 위임 자동 채점 점수(290.00)와 사고(incident) 없는 기록을 보유한 claude-sonnet-5는, 대부분의 사용자가 구현 작업을 위해 Fable에서 사용하기 가장 쉬운 위임 대상이 될 것입니다. 다른 모델을 선택하려면 어느 정도의 이점이 필요합니다. 코드 품질이 중요하고 더 저렴한 모델이 필요하다면 swe-1.7 (Kimi K2.7 기반) 또는 cursor-kimi-k2.7-code가 후보가 될 수 있습니다. 속도가 중요하고 더 저렴한 모델이 필요하다면 cursor-grok-4.5 등이 적합합니다.

위임은 공짜가 아닙니다. 위임을 하지 않은 fable-direct 베이스라인(baseline)은 5.7분이 소요되었고 비용은 $2.62였으며, 메인 라운드에서 모든 실행 시 완벽한 점수를 기록한 유일한 조건이었습니다. 동일한 Claude 하네스(harness)를 사용한 위임 실행(8.4–8.6분, $2.27–$2.35)과 비교했을 때, 단일 구현 작업에서의 비용 차이는 작으며, delegate-skills와 같은 단순한 메커니즘은 약 3분의 위임 오버헤드(overhead)를 추가합니다. 만약 Fable와 Claude 제품군만 사용한다면, delegate-skills가 크게 필요하지 않을 수도 있습니다. 특정 작업을 위해 서브에이전트(subagent) 도구를 통해 지정된 모델을 선제적으로 실행하도록 시스템 프롬프트(system prompt)를 지시하는 것만으로도 충분히 잘 작동할 수 있습니다.

후속 연구 1: 추론 노력(reasoning effort)이 품질을 보장할 수 있는가? — gpt-5.6-luna medium vs xhigh

메인 라운드 이후, 저는 동일한 벤치마크에서 동일하게 고정된 프롬프트(prompt)를 사용하여 추론 노력(reasoning-effort) A/B 테스트를 수행했습니다. 대상은 메인 라운드에서 "분할기 사양(splitter spec)을 체계적으로 통과하지 못함"이라고 설명된 gpt-5.6-luna입니다. 두 실험군(medium / xhigh)은 각각 3회씩 반복 실행되었으며, 신선한 측정값을 얻기 위해 같은 날 교차하여 실행되었습니다.