---
title: '코딩 에이전트 모델 교체 실험을 <em>마치며</em>'
tags:
  - ai
published: true
date: 2026-11-01 06:19:00
description: '실행 1,164회를 마치고 사내 벤치마크를 만든 과정과 결과를 돌아본다. 작업당 비용, Claude Code의 실행 환경, 오픈웨이트 모델에 대한 기대를 살펴보고 다시 실험한다면 바꾸고 싶은 조건을 적었다'
series: '코딩 에이전트 모델 교체 실험'
seriesOrder: 4
art:
  undraw: idea-to-plan
---

## Table of Contents

## 결정 하나에 든 비용

이번 실험에서 모델을 실행한 횟수는 모두 1,164회다. 실행 시간을 합치면 약 90시간이고, GLM 5.3의 청구액은 \$147.85, Sonnet 5.5의 토큰 사용량으로 계산한 비용은 약 \$32다. 함께 돌린 다른 모델 7종은 공개 단가로 계산할 수 없어 여기서는 제외했다. 문항을 만드는 데 나흘, 실행에 나흘이 들었다. 패치 리뷰와 글을 쓰는 데 걸린 시간은 별도다. 모델 교체에 대한 결정은 [3편](/2026/10/claude-code-model-swap-results)에 적었다. "이 호출 경로와 설정에서는 바꿀 근거를 찾지 못했다."

모델을 그대로 쓰기로 결정하기까지 꽤 많은 시간이 들었다. [1편](/2026/10/swe-bench-before-swapping-models)에서 공개 SWE-bench를 살펴보고, [2편](/2026/10/in-house-swe-bench-from-merged-prs)에서 사내 문항을 만든 뒤, 3편에서 결과를 비교했다. 이번 글에는 그 과정에서 새로 알게 된 점과 다시 실험한다면 바꾸고 싶은 것을 적었다. 앞의 세 편보다 개인적인 생각이 많이 들어 있다.

## 사내 문항으로 비교해 보니

코딩 에이전트에 쓰는 비용이 늘면 더 싼 모델을 찾아보게 된다. 그런데 지금 쓰는 모델이 더 낫다는 느낌만으로 교체 여부를 결정하기는 어렵다. 공개 점수를 참고하려고 해도 평가 예산과 추론 강도, 하네스가 제각각이었다. 내가 쓰는 조건에서도 비슷한 결과가 나올지 알고 싶어 시작한 실험이었다.

직접 재보니 단가에서 예상했던 것과 결과가 달랐다. GLM 5.3의 공개 단가는 Sonnet 5.5보다 입력 30%, 출력 56% 저렴하다. 하지만 같은 36문항을 3회 푸는 데 Sonnet은 약 \$13, GLM은 약 \$122가 들었다. 해결 1건당으로는 \$0.13 대 \$1.22다. GLM이 같은 작업에 턴과 토큰을 더 많이 썼기 때문이다. 단가가 낮아도 총비용은 커질 수 있다는 것은 알고 있었지만, 우리 코드에서 차이가 얼마나 나는지는 직접 돌려 보고 알았다.

다른 후보를 검토할 근거도 생겼다. 함께 돌린 GPT-6 Luna는 해결 수가 103 대 105로 Sonnet과 비슷했고, 36문항 1회 비용은 5분의 1 수준이었다. 회사의 검토 대상이 아니어서 3편에서는 참고 결과로만 적었지만, 비용을 줄이려면 더 살펴볼 만한 모델이었다. 이번에는 GLM으로 바꾸지 않기로 했어도, 같은 평가로 다른 후보를 검토할 수 있다.

한 번 만들어 둔 문항을 다시 쓸 수 있다는 점도 좋았다. 36문항과 채점기, 실행 스크립트가 있으니 다음 모델이 나오면 모델 ID만 바꿔 하루 안에 같은 표를 얻을 수 있다. 처음 준비하는 데는 나흘이 걸렸지만, 모델을 비교할 때마다 문항을 새로 만들 필요는 없다.

## 오픈웨이트 모델에 걸었던 기대

실험을 시작할 때는 오픈웨이트 모델에 기대가 있었다. 공개 점수에서 GLM 5.3은 Claude Opus 4.8과 비슷하거나 앞선 항목이 많았다. 사내에서 직접 호스팅해 쓸 수 있다면 비용을 줄이고 코드가 외부로 나가는 범위도 관리하기 좋을 것 같았다.

결과는 기대에 못 미쳤다. 기본 트랙의 해결 수는 비슷했지만, 명세 트랙은 42회 중 GLM이 35회, Sonnet이 42회였다. 턴 중앙값은 GLM이 61, Sonnet이 9.5였고 비용은 GLM이 9배 안팎이었다. 예산을 150턴으로 늘리면 명세 문항도 모두 해결로 채점됐다. 이 결과를 보면 같은 일을 마치는 데 얼마나 많은 턴과 토큰이 필요한지가 문제였다. 사람이 기다리며 쓰는 입장에서는 턴 6배와 비용 9배의 차이를 감수하기 어려웠다.

자체 호스팅한 오픈웨이트 모델 2종은 성능을 평가하지도 못했다. 서버가 Claude Code 요청의 최대 출력 토큰과 시스템 메시지 위치를 지원하지 않아 한 문항도 끝까지 돌지 않았다. curl로 보낸 최소 요청은 통과했지만, 그것만으로 Claude Code에서도 쓸 수 있다고 판단하기는 어려웠다.

추론 설정은 여전히 확인이 필요하다. GLM 결과의 `thinking_tokens`는 108회 모두 0이었고, 게이트웨이가 어떤 추론 강도를 적용했는지는 확인하지 못했다. 추론 강도를 맞춰 다시 비교하면 차이가 달라질 수 있다.

## Claude Code를 돌리며 새로 알게 된 것

Claude Code를 평소에도 쓰고 있었지만, 여러 모델을 같은 조건으로 실행하려니 미처 확인하지 않았던 설정이 많았다. 가장 큰 영향을 준 것은 지침 파일을 찾는 범위였다. 작업 디렉터리의 상위 디렉터리를 파일 시스템 루트까지 훑기 때문에, `HOME`과 `CLAUDE_CONFIG_DIR`을 바꿔도 홈 아래에서 실행하면 개인 지침이 들어갔다. 이 문제로 첫 실행 488회를 비교에서 뺐다.

도구 권한과 턴 수도 예상과 다른 부분이 있었다. `--allowedTools`는 권한 확인을 생략할 도구 목록이고, 도구 자체를 제한하는 옵션은 `--tools`였다. 허용 목록 밖의 호출이 거부되어도 턴은 쓰였고, 거부 횟수는 모델마다 2배 이상 달랐다. `num_turns`가 한도보다 크게 보고되거나 1로 보고되는 경우도 있어 한도 도달 여부는 `subtype`으로 확인했다. 보조 모델 변수도 같은 모델로 맞춰야 비교 대상이 아닌 모델의 토큰이 섞이지 않았다.

Claude Code의 종료 상태만으로 문제를 해결했는지 판단할 수도 없었다. 60턴에서 끊겼는데 테스트는 통과한 실행이 53회였다. Claude Code가 오류로 종료했는지만 봤다면 이 실행들은 미해결로 세었을 것이다. 해결 여부는 채점기로 확인하고, 한도에 걸렸는지는 별도로 기록한 이유다.

호출 경로는 실행 전에 확인했어야 했다. 1편에도 사내 코드를 보낼 수 있는 범위를 확인해야 한다고 적었지만, 실제로는 게이트웨이에 등록된 모델 ID만 보고 시작했다. 실행이 끝난 뒤에야 적절하지 않은 경로로 호출된 모델이 있다는 것을 알았고, 해당 결과는 비교에서 제외했다.

## 아직 살펴보지 못한 벤치마크

3편에서 두 모델의 공개 점수를 모으다 보니 SWE-bench Verified 점수를 찾기 어려웠다. Vals.ai는 성능이 포화되어 새 모델은 돌리지 않는다는 보관 표시를 붙였고, Sonnet 5.5 시스템 카드와 GLM-5.3 모델 카드에도 Verified 점수가 없었다. 모델 카드에서 보이는 이름은 SWE-Bench Pro, SWE-Bench Multilingual, Terminal-Bench, DeepSWE, SWE-Marathon, FrontierSWE, NL2Repo 등이었다. 새 저장소의 문항으로 매달 평가하는 SWE-rebench도 있었다.

이 가운데 평가 조건까지 읽은 것은 1편에서 다룬 SWE-bench 계열과 3편에서 각주를 확인한 Terminal-Bench, DeepSWE 정도다. 3편에서 본 모델 카드의 평가에는 수백 턴과 여러 시간의 예산, 최대 추론 강도가 쓰였다. 나머지는 아직 이름과 점수만 봤다. 무엇을 어떤 하네스로 재는지, Claude Code를 기본 설정으로 쓰는 환경과 얼마나 비슷한지는 아직 모른다.

## 다시 한다면 바꿀 것

다음 실험에서는 사내 코드를 보낼 수 있는 호출 경로인지 확인하고, 개인 지침을 격리한 상태에서 실제 하네스로 문항 하나를 끝까지 실행해 보려고 한다. 전체 비교에 쓸 문항과 한도는 그 뒤에 정한다.

60턴 한도는 첫 시험 실행에서 정했다. 개인 지침을 격리한 뒤에는 25분 한도에 걸린 실행이 없었고, 실제로 실행을 중단시킨 것은 턴 한도였다. 두 모델의 추론 강도를 맞추고 25분 한도만 두어 같은 36문항을 다시 풀게 하면, 명세 트랙의 해결 수 차이에 60턴 한도가 얼마나 영향을 줬는지 더 살펴볼 수 있다.

비교 대상에는 GPT-6 Luna도 포함해 명세 트랙과 패치 리뷰까지 같은 기준을 적용하고 싶다. 패치 리뷰어를 비교 대상과 다른 회사의 모델로 바꿔도 점수가 유지될지 궁금하다. 문항은 이번에 쓴 WebSocket 패키지의 36개에 더해, UI 컴포넌트처럼 성격이 다른 패키지에서도 만들어 볼 만하다.

아직 읽지 못한 벤치마크도 SWE-bench를 살펴봤을 때처럼 문항과 채점기부터 따라가면서, 평소 Claude Code로 하는 작업과 얼마나 비슷한지 살펴볼 생각이다.

## 다음 모델도 같은 문항으로

실험 전에는 공개 점수와 토큰 단가를 주로 봤다. 이번에는 우리 코드의 작업 하나를 끝내는 데 드는 비용과 시간도 직접 재봤다. GLM의 단가가 낮아도 턴과 토큰을 많이 써서 총비용이 커졌고, 한도를 늘려도 해결 1건당 비용 차이는 줄지 않았다. 모델을 고르는 데 직접 도움이 된 결과였다.

같은 모델도 하네스와 한도, 개인 지침의 유무에 따라 결과가 달라졌다. 모델을 바꾸지는 않았지만, 다음 비교에서는 이번에 만든 36문항과 채점기를 그대로 쓸 수 있다.