이것은 https://github.com/adrianco/retort/blob/main/experiments-blog.md에서 자동 생성된 분석 보고서의 스냅샷입니다.

발행일 2026-07-30 · 수정일 2026-07-30 — Adrian Cockcroft

논쟁을 위한 것이 아닌 인덱스입니다. Retort는 **56개의 실험 그룹과 13개의 언어에 걸쳐 1,014회의 점수가 매겨진 실행(scored runs)**을 수행했습니다. 이 페이지는 각 그룹의 목적이 무엇이었는지, 상세 내용을 어디에서 읽을 수 있는지, 그리고 — 오래된 수치를 읽을 때 가장 중요한 부분인 — 당시 하네스(Harness) 자체가 무엇을 하고 있었는지를 설명합니다. 몇몇 발표된 수치들은 모델이 변경되어서가 아니라, 툴링(Tooling)이 수정되었기 때문에 변동되었습니다.

상세 내용은 docs/past-experiments.md에 있습니다. 현재 권장 사항: optimal-blog.md 및 기계 판독이 가능한 optimal.json. 에이전트(Agents)에게 무엇을 구축하도록 요청했는지, 그리고 각 실행에 대해 가장 빠르고 가장 느린 통과 실행은 무엇인지: tasks-blog.md. 다음 단계: docs/future-experiments.md.

카테고리

두 후보는 실행 전 거부되었습니다: Ornith-1.0-35B (시각 최적화, 에이전트에 적대적인 샘플링 (agent-hostile sampling)) 및 Poolside Laguna XS 2.1 (메인라인 서빙에 포함되지 않은 아키텍처). 저렴한 비용으로 제외된 후보 또한 여전히 결과이기에, 두 후보 모두 gate-probe 증거와 함께 docs/past-experiments.md 끝부분에 기록되어 있습니다.

발표된 수치를 변화시킨 하네스 (Harness) 변경 사항

한 실험의 수치를 다른 실험의 수치와 비교하기 전에 이 내용을 확인하십시오. 이 중 모델이 변경된 경우는 없습니다.

계속해서 반복되는 형태는 다음과 같습니다: 실패하는 모델과 고장 난 하네스 (harness)는 점수상으로 동일하게 나타납니다. retort diagnose는 이 둘을 분리하기 위해 존재하며, 확립된 규칙은 놀라운 0점 수치가 발견되면 이를 발표하기 전에 수동으로 재현해야 한다는 것입니다. 전체 사후 분석 (post-mortems)은 Historical: harness bugs & the local re-baseline saga에서 확인할 수 있습니다.

철회된 결론들

수정 사항이 원본보다 더 유용하기 때문에 계속 공개해 둡니다.

• "Opus 5는 모든 곳에서 어려운 과제를 통과하는 유일한 모델이다" (exp-46) — exp-48에 의해 철회됨. Fable 5는 13개 언어 중 9개 언어에서 실행(run)된 적이 없었습니다. 실행되었을 때는 약 절반의 비용으로 통과했습니다. 실행되지 않은 셀과 통과할 수 없는 셀은 표에서 동일하게 보입니다.
• "최신 Claude 버전은 꾸준히 더 많은 턴(turns)을 소모한다" — exp-49에 의해 수정됨. 세 세대는 약 9~13턴에 머물러 있습니다. 겉으로 드러난 추세는 재현되지 않는 하나의 오래된 실험 수치에서 비롯되었습니다.
• "사고 수준(Thinking level)이 버전 간 비용 격차를 설명한다" — 이를 테스트하기 위해 수행된 실험에 의해 철회됨. 이를 유도했던 단 한 번의 실행(max에서 33턴)은 재현되지 않았습니다: 14턴, 그 다음은 18턴이었습니다.
• "gpt-oss는 3.6배의 속도로 Go 게임에서 80B 모델과 대등하다" (exp-47, n=3) — n=5에서 Go 점수가 0.80으로 떨어지면서 삭제됨.
• "로컬의 어려운 과제 장벽(hard-task wall)은 턴 제한(turn cap) 때문이다" (exp-50의 전체 전제) — 틀렸습니다. api_calls는 턴과 1:1 관계이며 3:1이 아니므로, 아무것도 잘려 나가지(truncated) 않았습니다. 장벽은 실재합니다.

이 다섯 가지 중 네 가지는 단 한 번의 실행을 결과로 오독한 데서 비롯되었습니다.

가장 느린 성공적인 실행

tasks-blog.md는 각 과제에 대해 가장 빠르고 가장 느린 통과 실행(passing run)을 보여줍니다. 느린 쪽이 더 교훈적입니다. 왜냐하면 그곳에서도 아무것도 실패하지 않기 때문입니다.

이 두 가지는 모두 동일한 과제 — rest-api-crud, python, 도서 CRUD API — 이며, 둘 다 requirement_coverage = 1.00 점수를 기록합니다.

느린 실행은 실패도 아니고, 태만(slop)도 아닙니다. 유지보수성(maintainability), 관용성(idiomaticity), 그리고 커버리지(coverage) 측면에서는 더 나은 점수를 기록합니다. 이 모델은 7개의 모듈로 구성된 패키지를 구축했고, 요청하지 않았음에도 스스로 ruff를 실행했으며, 하위 에이전트(subagent)를 생성하고, 도서 CRUD API에 대해 **변이 테스트 (mutation testing)**를 수행했습니다. 심사위원(judge)의 5가지 발견 사항은 모두 명세(spec)를 넘어서는 범위를 설명하는 info입니다: PATCH 엔드포인트, 필터링/정렬/페이지네이션(pagination), GET /openapi.json에서 제공되는 직접 작성된 304행의 OpenAPI 3.0 문서, SQLite의 WAL 저널링(journaling) 및 busy-timeouts, 그리고 NUL 바이트와 SQLite 정수 범위에 대한 유효성 검사(validation)가 그것입니다.

그 누구도 이것들을 요구하지 않았습니다. 작업(task)은 5개의 엔드포인트, 상태 확인(health check), 그리고 최소 3개의 테스트를 요구했을 뿐입니다.

실제로 문제가 되는 것은 게이트(gate)가 그 차이를 식별하지 못한다는 점입니다. 두 경우 모두 requirement_coverage가 1.00이므로, 이 프로젝트 전체의 핵심 지표인 합격 비율(pass-proportion)은 44초가 걸린 0.86달러짜리 실행과 46분이 걸린 25달러짜리 실행을 동일하게 평가합니다. 이는 자체 정의에 따르면 정확한 결과이지만, 비용(cost)을 옆에서 함께 읽지 않는 한 페이지에서 가장 오해를 불러일으키는 수치입니다. 이 둘을 실제로 구분해 주는 지표는 534배의 차이를 보이는 token_efficiency입니다.

다이얼(dial)은 비용뿐만 아니라 분산(variance)도 발생시킵니다. exp-55 내에서, 동일한 Opus 5 python 셀을 두 번 실행했을 때:

low 설정에서는 두 반복(replicate) 결과가 15% 이내로 일치하지만, max 설정에서는 1.9배의 차이가 나며 비용 또한 1.9배 차이가 납니다. 10개 중 10개의 셀 모두 1.00 점수를 기록합니다. 이 작업에서 사고 다이얼(thinking dial)은 측정 가능한 이득은 전혀 주지 않으면서 비용을 25배로 증폭시키고, 최고 설정에서는 예측 불가능해집니다. n=2인 상태에서 분산에 대한 주장은 시사하는 바는 있으나 확립된 것은 아닙니다 — 하지만 비용만큼은 의문의 여지가 없습니다. 한편, GPT-5.6 Terra는 동일한 10개의 셀을 1.4분에서 4.0분 사이에 0.10~0.33달러로 실행했으며, 이 역시 전 과정에서 1.00을 기록했습니다.

로그가 보여주는 한 가지가 더 있습니다. 느린 실행(slow run)은 초기 턴(turns) 동안 호스트 인터프리터를 탐색하는 데 시간을 보냈으며, 사전 설치된 FastAPI가 고장 난(broken) 상태(pydantic v1은 Python 3.14에서 모델을 빌드할 수 없음)임을 발견했고, 그 대신 Flask를 선택했습니다. 이는 환경이 다시 측정값에 영향을 미치고(leaking) 있는 사례이며, 현재 워크스페이스당 깨끗한 가상 환경(venv)을 프로비저닝(provisioning)함으로써 해결된 python 누락 문제와 동일한 유형의 문제입니다.

수치 읽기

**통과 비율 (Pass-proportion)**은 명세(spec)를 완벽하게 구현한 실행의 비율을 의미합니다. 즉, 고정된 체크리스트의 모든 요구사항을 충족하고, 실제로 실행되는 테스트를 포함하며, 독립적인 LLM 판사(judge)에 의해 검증된 경우를 말합니다. 요구사항을 하나라도 놓친 실행은 0.9가 아니라 0점을 받습니다. 하나의 셀을 읽을 때는 관리되지 않는 단일 실행이 완전히 정확하게 나올 확률로 이해해야 합니다.

수치를 신뢰하기 전에 확인해야 할 세 가지가 있습니다: n (많은 셀이 1~3회의 실행 횟수를 가지며, 이 프로젝트에서 n=1일 때의 결과는 반복적으로 뒤집혔습니다), 판사 (the judge) (실험 53번 이후부터 master.db에 실험별로 기록됨; requirement_coverage는 한 모델의 의견이며, 동일한 방식으로 채점된 실험들 사이에서만 풀(pool)을 형성함), 그리고 언어 혼합 (the language mix) (전체 언어 평균은 서로 다른 언어 세트에서 실행된 모델들을 암묵적으로 비교하게 되므로, 언어별 매트릭스(per-language matrix)가 동일 조건에서의 비교(like-for-like) 관점입니다).