이 분석은 새로운 실험이 필요할 때마다 업데이트되는 스냅샷입니다:
https://github.com/adrianco/retort/blob/main/levels-blog.md

발행일 2026-07-31 · 업데이트일 2026-07-31 — Adrian Cockcroft

--effort low|medium|high|xhigh|max는 retort에서 가장 새롭고 가장 큰 비용 레버(cost lever)이지만, 가장 이해도가 낮은 부분입니다. versions-blog.md는 이것이 비용을 발생시킨다는 점을 확립했습니다. 이 페이지는 총합에서 추론하는 것이 아니라, 아카이브된 에이전트 로그(agent logs)를 읽어내어 _모델이 그 시간 동안 무엇을 하는지_에 대해 다룹니다.

요약하자면: 다이얼(dial)의 상단 아래 단계에서 Opus 5는 **더 많이 작성(writes more)**합니다. 다이얼의 최상단에 도달하면 작성을 멈추고 **수정(revising)**을 시작합니다. 즉, 자신의 코드를 다시 읽고, 자신의 테스트를 다시 실행하며, 이미 작성한 내용을 편집합니다. 이 전환점이 비용 곡선이 시간 곡선을 벗어나는 지점이며, 일상적인 작업(routine task)에서는 게이트(gate)가 확인할 수 있는 어떠한 이득도 얻지 못합니다.

데이터: adrianco/experiment-55, Claude Opus 5 및 GPT-5.6 Terra, python 및 go, 5가지 effort 레벨, 일상적인 작업(bookshop)에 대한 2회의 반복(replicates), 어려운 작업(brazil)에 대한 1회의 반복. 아래의 모든 수치는 실행당 데이터베이스와 아카이브된 _agent_stdout.log 파일로부터 재계산되었습니다.

다이얼, 처음부터 끝까지

일상적인 작업, python 환경에서의 Claude Opus 5, 레벨당 2회 반복의 평균:

시간, 비용, turns, tokens, lines, tests 등 모든 것이 단조 증가(monotonically)합니다. 단 하나 움직이지 않는 열은 프로젝트 점수가 매겨지는 열입니다: requirement_coverage는 모든 레벨에서 1.00입니다. 작업은 76센트에 2분 만에 완전히 구현되며, 33분과 19달러가 더 지나도 여전히 정확하게 완전히 구현된 상태입니다.

곡선의 형태가 다르다는 점에 주목하십시오. 실제 시간(Wall clock)은 최저에서 최고치까지 17배 증가하지만, 비용은 25배, 토큰은 35배 증가합니다. 비용이 시간보다 더 빠르게 증가하는 이유는 단순히 턴(turn)의 수가 늘어나서가 아니라, 턴당 작업 강도가 심화되기 때문입니다.

행동 양식의 전환: 작성(Writing)에서 수정(Revising)으로

총합 수치만으로는 무엇이 변했는지 알 수 없습니다. 도구의 조합(tool mix)이 이를 말해줍니다. 동일한 실행(run)에 대해, 실행당 평균 도구 호출(tool calls)은 다음과 같습니다:

xhigh까지 패턴은 안정적이며 특별할 것이 없습니다. Opus는 파일을 작성하고, 테스트를 몇 번 실행한 뒤 멈춥니다. 작성(Write)이 수정(Edit)보다 약 3:1 비율로 더 많습니다. 더 높은 노력(effort)은 단순히 동일한 작업의 반복을 의미합니다. 예를 들어 low가 5개의 파일을 작성했다면, high는 12개의 파일을 작성합니다.

max 단계에서는 작업의 형태가 바뀝니다. 수정(Edit)이 작성(Write)보다 2.4:1 비율로 더 많아지며, 읽기(Read)는 18배(2 → 36) 급증하고, Bash 호출은 6배(14 → 86) 급증합니다. 이는 더 이상 해결책을 만들어내는 것이 아니라, 이미 가지고 있는 해결책을 감사(auditing)하는 단계입니다. 즉, 자신의 모듈을 다시 읽고, 테스트 스위트(suite)를 다시 실행하며, 조정(adjusting)합니다. 턴당 도구 호출(tool calls per turn) 또한 ~0.95(다이얼을 높이는 내내 턴당 하나의 동작)에서 2.02로 상승하며, 이는 병렬 동작을 배치(batching)하기 시작했음을 의미합니다.

이 지점에서 스스로 부과한 추가 작업들이 나타나며, 오직 여기서만 나타납니다. 10번의 Python 실행 전반에 걸쳐, 변이 테스트(mutation testing), 하위 에이전트 위임(subagent delegation), 그리고 수기로 작성된 OpenAPI 문서는 오직 두 번의 max 실행에서만 발생하며, low부터 xhigh까지는 전혀 나타나지 않습니다. 이는 가장 느린 통과 실행(slowest passing run)이 포함하고 있었던 내용과 일치합니다: 도서 CRUD API를 위한 7개 모듈 패키지, 요청하지 않은 ruff 린팅(linting), 그리고 변이 테스트였습니다.

전환점은 다이얼의 위치가 아니라 작업의 난이도를 추적합니다. 어려운 작업에서는 동일한 반전이 두 단계 더 일찍 발생합니다:

이러한 차이가 측정된 응답에 나타나는가?

여유 공간(headroom)이 있는 경우에만 나타납니다. 테스트 커버리지(test-coverage) 점수 측정기가 이미 천장에 도달해 있지 않은 go에서의 동일한 다이얼을 비교해 보십시오:

그 외의 모든 지표는 평이하거나 오히려 악화됩니다. requirement_coverage는 10개 셀 모두에서 1.00입니다. 유지보수성(Maintainability)은 노력에 따라 개선되지 않습니다. Python의 경우 low에서 0.96, max에서 0.89를 기록하는데, 이는 944줄의 코드가 192줄보다 단순히 유지보수하기 더 많기 때문입니다.

동일한 다섯 가지 이름이 벤더(vendor)마다 다른 의미를 갖는다

GPT-5.6 Terra에 대해 동일한 스윕(sweep)을 실행하면 다이얼의 영향이 거의 나타나지 않습니다:

두 CLI는 동일한 다섯 가지 단어를 수용하므로, 이 요소가 비교 가능한 것처럼 보입니다. 하지만 그렇지 않습니다. max는 한 벤더에게는 가벼운 자극(nudge)이지만, 다른 벤더에게는 체제 변화(regime change)입니다. 벤더 간 비교를 수행할 때는 반드시 _수준(level)_을 명시적으로 고정하고 비용을 보고해야 합니다. 이름이 일치한다고 해서 동작까지 일치하는 것은 아니기 때문입니다.

다이얼(dial)을 실제로 어떻게 조절해야 하는가

• 일상적인 작업에는 low로 두십시오. 10개 셀 모두 1.00점을 기록했습니다. low는 2분 만에 76센트로 작업을 완료했습니다. 이보다 높은 설정은 이미 정답인 답변을 수정하는 데 비용을 지불하는 것과 같습니다.
• 측정된 응답에 여유 공간(headroom)이 있을 때 높이십시오 — Go 언어의 커버리지(coverage) 이득은 실재합니다. 이것이 xhigh로 올려야 하는 이유이며, 이득은 max보다는 이미 xhigh에서 나타나고 있습니다.
• max는 한 단계 더 높은 설정이 아니라, 다른 모드로 취급하십시오. 이 단계는 모델이 스스로를 감사(auditing)하기 시작하고, 비용이 초선형적(super-linear)으로 증가하며, 아무도 요청하지 않은 작업을 수행하는 단계입니다.

주의 사항

n의 크기가 작습니다. 서점(bookshop) 셀당 2회 반복, Brazil 셀당 1회 반복되었습니다. Go max 행은 n=1(13.3분, $4.21)이며 자신의 xhigh(18.4분, $6.70)보다 낮은 수치를 기록했습니다. 이는 실제 역전 현상이라기보다는 누락된 반복 측정값 때문일 가능성이 매우 높으므로, Go max 수치는 위의 어떤 주장에도 사용되지 않았습니다.

Brazil 스윕(sweep)이 불완전합니다. Opus 5는 계정이 사용 한도에 도달하기 전 low/medium/high를 실행했습니다; xhigh와 max는 실행되지 않았습니다. Brazil 테이블은 처음 세 단계의 형태만 갖추고 있으며, 가장 비용이 많이 드는 두 셀이 누락되어 있습니다.

이번 분석에 영향을 미쳤기에 기록해 두는 하나의 측정 함정입니다. Claude Code JSONL 로그에는 하나 이상의 result 레코드가 포함될 수 있습니다 — 여기의 24개 Opus 실행 중 2개가 그러합니다. 마지막 레코드에서만 num_turns를 읽으면 수치가 과소 계산됩니다: 45.6분 동안 진행된 max 실행은 그 방식으로 읽었을 때 94를 보고하지만, 실제 총합은 116 + 94 = 210입니다. tasks-blog.md와 experiments-blog.md의 이전 버전은 94를 게시했으나, 현재는 둘 다 수정되었습니다. 직접 계산한 tool_use 블록(해당 실행의 경우 256개)이 더 신뢰할 수 있는 측정치이며, 위의 도구 혼합(tool-mix) 테이블에서도 이를 사용합니다.