무료 executor가 가장 비싸게 먹힌 이야기: Opus + 로컬 Qwen으로 40회 시도하여 측정했더니 모든 태스크에서 최고 비용 발생

「강력한 모델로 계획을 세우게 하고, 저렴한 모델에게 실행을 맡긴다」. 에이전트 코딩 (Agent Coding)의 비용 절감 레시피로서 거의 정석입니다.

저도 그렇게 믿고 검증했습니다. Opus 4.7에게 오케스트레이터 (Orchestrator) 역할을 맡기고, 로컬에서 구동 중인 Qwen 3.5-9B (토큰 과금 제로)에게 코드 편집을 맡깁니다. 이렇게 하면 Opus 단독 사용보다 저렴해질 것이라 생각했습니다.

결과는 정반대였습니다.

「무료」일 것이라 예상했던 구성 (Opus + Qwen)이, 3가지 코드 수정 태스크 전부에서 최고 비용을 기록했습니다. Opus 단독보다 비싸고, Opus + Haiku보다 비싸며, 당연히 Haiku 단독보다 압도적으로 비쌉니다. 「로컬에서 구동하니까 저렴할 것」이라고 믿고 GPU PC를 맞춘 저로서는 상당히 난처한 상황입니다.

40회 시도분의 수치와 원인을 논문 형태로 정리하여 Zenodo에 올렸습니다. DOI는 다음과 같습니다: 10.5281/zenodo.20978074 / GitHub

이 기사에서는 그 40회 시도 동안 무엇이 일어났는지, 왜 「무료」가 가장 비싸게 먹혔는지를 실측 기반으로 작성합니다.

40회 시도 × 4개 구성 × 3개 태스크, 결정적 판정기 (mypy + ruff + pytest의 exit code만 사용)로 측정했습니다. LLM-as-judge는 일절 사용하지 않았습니다.

• 「Opus가 계획을 세우고 + Qwen이 실행하는」 구성은 3개 태스크 전부에서 클라우드 최고 비용을 기록했습니다. Opus 단독보다 높습니다.
• 원인은 executor의 토큰 비용이 아니라, 오케스트레이터 측의 prompt cache 재로드입니다. Opus가 Qwen의 반환값을 매 턴마다 다시 읽어들이는 양이 불어나면서, Opus 단독일 때보다 입력 볼륨이 1.4~5.3배로 커집니다.
• Haiku 단독은 최대 태스크 기준 Opus 단독보다 5.5배 저렴합니다. 다만 25%의 확률로 실패합니다. 클라우드 전체로 보면 Opus + Haiku가 가장 균형이 좋습니다.

「executor의 토큰이 무료니까 저렴할 것이다」라는 직관이 왜 빗나가는지, 그 이유를 끝까지 설명하겠습니다.

arm	orchestrator	executor	역할 분담
A	Opus 4.7	(단독)	1개 모델로 전부 수행
...
4개 arm 모두 Anthropic SDK를 통해 동일한 도구군을 사용할 수 있습니다. str_replace_editor (view/create/str_replace/insert) 및 bash (120초 타임아웃). 오케스트레이터 (B, C)에는 delegate_to_executor 도구가 하나 추가되어 있을 뿐입니다.

Anthropic prompt caching은 모든 arm에서 동일한 설정을 적용합니다: system / tools / 최근 user message에 cache_control: ephemeral을 붙입니다. temperature나 seed는 설정하지 않으므로, 시도 간의 편차는 샘플링의 랜덤성 그 자체입니다.

모두 typer 리포지토리의 commit b210c0e (v0.26.8) 위에서 구동했습니다. MIT license이며, 각 시도는 git checkout -- . && git clean -fd로 리셋한 후 시작됩니다.

T1 — 결함 수정: AST로 25개의 에러를 주입 (mypy 10건 + ruff 10건 + pytest collection 실패 5건). fully green 상태로 복구.

T2 — 리팩토링: get_params_from_function을 typer/utils.py에서 새로운 모듈 typer/_param_extractor.py로 이동. 모든 import 소스를 업데이트. 테스트는 모두 pass 상태를 유지.

T3 — 기능 추가: get_version_banner(prefix, uppercase) -> str을 구현하여 typer/__init__.py에서 export. SHA-256으로 핑거프린트된 테스트 파일을 통과.

mypy + ruff check + pytest의 exit code가 0이 되면 성공, 그렇지 않으면 실패로 간주합니다. 태스크마다 verify-T2.sh / verify-T3.sh를 사용합니다.

구조 체크(함수가 새로운 모듈로 이동했는지, 핑거프린트된 테스트가 수정되지 않았는지 등)도 추가했습니다.

LLM에게 "이대로 괜찮아?"라고는 일절 묻지 않았습니다. 판정은 결정론적(Deterministic)이며 재현 가능합니다.

arm	task	n_succ/total	wall (s)	iters	cost ($)	success rate
A Opus solo	T1	3/3	253	36	1.74	1.00
...	6	0.17	1.00
B Opus+Qwen	T1	3/4	484	38	2.27	0.75
B Opus+Qwen	T2	3/3	443	27	1.38	1.00
...	1.67	1.00
C Opus+Haiku	T2	3/3	275	20	0.92	1.00
C Opus+Haiku	T3	3/3	145	11	0.38	1.00
D Haiku solo	T1	3/4	758	89	0.30	0.75
D Haiku solo	T2	3/4	507	70	0.23	0.75
D Haiku solo	T3	3/3	208	29	0.08	1.00

굵은 글씨는 열 내 최상위 값입니다. 40회 시도 시 Anthropic에 지불한 총액은 $35.98였습니다. 논문 작성 비용으로는 저렴한 편이었습니다.

주목해야 할 행은 arm B입니다. 3개 태스크 모두에서 cost ($)가 클라우드 arm 중 최고($2.27 / $1.38 / $0.42)를 기록했습니다. Qwen의 토큰 비용은 0원인데도, Opus 단독 사용 시보다 비용이 높습니다.

Opus 측의 토큰 소비(input + cache_read_input)를 arm별로 비교하면 다음과 같습니다.

arm role	T1 (Opus 측 in+cache_r)	T2	T3
A (Opus solo)	534,586	226,474	13,320
...	B/A 비 (Opus 측만): T1에서 1.38배, T2에서 1.39배, T3에서 5.26배.

executor (Qwen)의 토큰은 무료입니다. 하지만 Opus 스스로가 읽어야 하는 토큰량이 단독으로 실행할 때보다 1.4~5.3배로 불어납니다.

이유는 무엇일까요? delegate_to_executor를 통해 Qwen에게 편집을 맡기면, Qwen은 stdout 요약(summary)을 반환합니다(제 구현에서는 최대 4,000자에서 절삭). 그 요약이 매 턴마다 Opus 측의 컨텍스트(Context)에 쌓여갑니다. Anthropic의 프롬프트 캐시(Prompt Cache)는 최신 메시지를 cache_write하고, 다음 턴에서 cache_read로 다시 읽어옵니다. 30~80 턴이 진행되는 동안, Opus는 "Qwen이 무엇을 했는지에 대한 요약"을 몇 번이고 반복해서 다시 읽게 됩니다.

그 다시 읽기 과정에서 cache_read 단가($1.50/M token = Opus input의 10%)가 추가됩니다. executor가 무료일지라도, orchestrator는 무료가 아닙니다. 당연하게 들리겠지만, 문장에 "무료"라는 단어가 포함되면 인간은 판단을 멈추기 쉽습니다. 저도 그랬습니다.

정확히 말하면: orchestrator의 비용은 executor의 생(raw) 토큰 수가 아니라, orchestrator가 그것을 몇 번이나 다시 읽느냐에 비례한다. LLM 이야기가 아니라 중간 관리직에 관한 이야기라고 착각할 법한 결론이지만, 정말 그렇습니다.

가장 극단적인 사례가 T3(가장 작은 태스크, 약 6 iter)입니다.

이 또한 프롬프트 캐시의 동작으로 설명할 수 있습니다. 베이스 컨텍스트(Base context: system + tools + 초기 프롬프트)는 첫 번째 턴에서 cache_write되며, 이후에는 cache_read를 통해 저렴하게 읽힙니다. 긴 태스크(T1, T2)에서는 이 베이스 컨텍스트가 누적 입력량 중 차지하는 비율이 작습니다.

하지만 짧은 태스크에서는 다릅니다. base context가 누적 입력에서 차지하는 비율이 큽니다. 그래서 "executor의 요약(summary)도 돌아오고, base도 매 턴 읽히기 때문에" 발생하는 오버헤드가 영향을 미칩니다. T3에서만 B/A 비율이 5.3배라는 극단적인 수치가 나오는 이유가 바로 이것입니다.

반대로 C (Opus + Haiku)는 T1과 T2에서 cache_read footprint가 A보다 작아집니다 (T1에서 0.79배, T2에서 0.70배). Haiku가 실제로 실질적인(substantive) 작업을 수행해주어, Opus가 직접 하지 않아도 되는 만큼 비용이 절감됩니다. 이는 executor가 제대로 작동하는 케이스이며, 요약(summary)만 비대해지는 Qwen 케이스와는 정반대의 상황입니다.

"강력한 오케스트레이터(orchestrator) + 저렴한 에그제큐터(executor)" 조합이 반복적인 툴 루프(tool loop)에서 효과를 보기 어려운 이유는, 1-shot이라면 문제가 없더라도 수십 턴을 돌리는 반복 루프(iterative loop)에서는 오케스트레이터의 cache_read 비용이 지배적이 되기 때문입니다.

이번 실험은 그런 의미에서 arm B가 패배하기 쉬운 조건으로 설계되었습니다:

executor의 반환값이 자유 형식(free-form)임 (Qwen의 stdout 요약이 최대 4000자). "구조화된 diff 1개만 반환하라"고 제한한다면, Opus 측의 누적 컨텍스트는 작아질 것입니다. -
태스크가 순차적임 (T1/T2/T3는 모두 1회 시도 내에서 병렬화할 수 없음). "동시에 3곳을 수정해도 좋다"는 태스크라면 오케스트레이션(orchestration)의 비용을 회수할 가능성이 생깁니다.

executor의 반환값을 타이트하게 제한하여 arm B를 재실행하는 것은 다음 실험에서 측정할 계획입니다. 아마 T3에서는 역전할 것이고, T1에서는 미미할 것입니다.

제가 이번 수치를 보고 자신의 에이전트 코딩 운영에 적용한 판단은 다음과 같습니다:

태스크가 몇 번의 이터레이션(iteration) 내에 끝난다면 Opus solo가 가장 저렴하다. T3에서 클라우드 arm 중 최고 성능 ($0.17 / 69초 / 6 iter). "Opus는 비싸다"는 단발성으로 보았을 때의 이야기이며, 루프 전체로 보면 per-iteration 효율이 중요합니다. -
태스크가 수십 번의 이터레이션이 필요하다면, per-iteration 비용이 저렴한 모델이 유리하다. T1에서 Haiku solo가 달러 기준으로 5.5배 저렴합니다. 다만 25%의 실패율이 있으므로, 재시도(retry) 비용을 포함하면 4.2배로 줄어듭니다. -
클라우드만으로 완결하고 싶다면 Opus + Haiku가 가장 균형 잡힌 선택이다. T1에서는 Opus solo와 대등하고, T2에서는 최저가이며, T3에서도 근소한 차이를 유지합니다. Haiku 단독 사용 시의 실패 리스크를 감수하고 싶지 않다면 이곳이 안전한 선택입니다. -
로컬 Qwen으로 "무료"를 취하고 싶다면, executor의 반환값 크기를 구조적으로 제한하라. free-form 형태의 stdout을 반환하게 하면, 오케스트레이터 측이 cache_read 비용으로 인해 과다 지출됩니다.

"강력한 모델 + 저렴한 모델" 조합은 설계의 자유도가 생각보다 좁습니다. executor가 무엇을 얼마나 반환할지까지 포함하여 설계하지 않으면, "오케스트레이터 비용이 비싸지는" 현상이 재발합니다. 저는 이 현상이 재발하는 것을 보고 측정 오류를 의심하며 3번이나 반복한 끝에 포기했습니다.

솔직하게 밝히는 한계점(Limitations)입니다:

n=3/cell로 모집단 추정치로서는 약합니다. p-value (Mann-Whitney U)는 정규 근사(normal approximation)를 적용했을 때 소표본 하한인 0.050입니다. 효과 크기 (Cliff's delta)는 신뢰해도 좋으나, p-value의 미세한 차이를 과대 해석하지는 마십시오. -
3개 태스크 모두 typer 리포지토리(repository) 상에서 수행되었습니다. 일반화하기 위해서는 다른 코드베이스(codebase)에서도 실행해 볼 필요가 있습니다. harness를 포함하여 MIT 라이선스로 공개할 예정이므로 재현은 쉬울 것입니다. -
오케스트레이터의 시스템 프롬프트에 "직접 편집하지 말고 위임(delegate)하라"고 명시되어 있습니다. 현실적인 배포 형태이긴 하지만, 결과에 영향을 미치는 교란 요인(confounder)입니다.

베이스 환경은 Ubuntu 22.04, Python 3.10+, uv 0.4+, anthropic Python SDK 0.83+입니다. arm B는 Ollama 0.4+에서 qwen3.5:9b를 사용했습니다. arm A/C/D만 사용한다면 Ollama는 필요하지 않습니다.

git clone https://github.com/kenimo49/free-executor-paradox
cd free-executor-paradox
# arm A의 T3를 1회 실행(1 trial)
...

자세한 내용은 repo의 README와 paper PDF를 확인해 주세요. harness, breakage injection, runner, analysis가 모두 포함되어 있습니다.

agentic coding (에이전트 기반 코딩)의 비용 논의는 executor (실행기)의 가격에 치우치기 쉽지만, 진짜 지배적인 요인은 orchestrator (오케스트레이터)가 무엇을 몇 번이나 읽느냐입니다. 이번 Qwen은 하나의 사례일 뿐이며, 앞으로 등장할 모든 로컬 모델에 동일한 문제가 따라붙을 것입니다 (executor가 free (무료)일지라도, orchestrator의 cache_read (캐시 읽기)는 free가 되지 않습니다).

숫자로 증명할 수 있는 결론은 강력하기 때문에, 논문 형태로 작성하여 Zenodo에 게시했습니다. "우리 codebase (코드베이스)에서도 결과가 같았다", "우리는 반대였다"라며 재현 실험(reproduction)을 해주는 사람이 나타나는 것이 가장 기쁜 결말입니다.

논문 (Zenodo): When Free Executors Cost More — DOI 10.5281/zenodo.20978074 -
코드 + 데이터 + harness: https://github.com/kenimo49/free-executor-paradox -
GitHub Release: v1.0.0