---
title: 'Claude Code의 모델을 GLM 5.3으로 바꾸면 생기는 일'
tags:
- ai
published: true
date: 2026-11-01 06:18:00
description: '사내 문항 36개를 Claude Sonnet 5.5와 GLM 5.3으로 3회씩 풀었다. 216회의 해결률, 한도 중단, 비용, 패치 결함을 비교하고 공개 벤치마크와의 조건 차이를 살펴본 뒤 모델 교체 여부를 판단한다'
series: '코딩 에이전트 모델 교체 실험'
seriesOrder: 3
art:
undraw: ai-agent
---
## Table of Contents
## 61회가 한도에서 멈췄고, 그중 53회는 테스트를 통과했다
GLM 5.3은 108회 실행 중 61회가 60턴 한도에 걸려 멈췄다. 그런데 그중 53회는 중단 시점의 코드가 테스트를 통과해 해결로 채점됐다. 해결 수만 보면 Claude Sonnet 5.5가 108회 중 105회, GLM 5.3이 100회로 5회 차이다. 하지만 작업 과정은 꽤 달랐다. Sonnet은 절반이 10턴 안에 끝났고, GLM은 절반 이상이 한도에서 끊겼다.
[2편](/2026/10/in-house-swe-bench-from-merged-prs)에서는 사내 WebSocket 패키지의 병합 PR 20건으로 문항 36개를 만들고, Claude Code를 돌릴 환경을 준비한 과정을 다뤘다. 이번에는 그 환경에서 Claude Sonnet 5.5와 GLM 5.3으로 36문항을 3회씩 풀었다. 이 216회의 해결률, 중단 양상, 턴과 시간, 비용, 패치 리뷰 결과를 바탕으로 모델 교체 여부를 판단해 보려 한다. 판단 범위는 이 패키지와 호출 경로다. 공개 벤치마크의 조건과 함께 실행한 다른 모델 5종의 결과도 비교에 참고했다.
> 실행은 2026년 10월 26일에 했다. 두 모델 모두 사내 LLM 게이트웨이를 거쳐 클라우드 제공자가 호스팅하는 모델을 Claude Code `claude -p`로 호출했다. 문항당 25분과 60턴, 허용 도구 목록, 프롬프트, 채점기는 2편과 같다. 추론 설정은 두 모델 모두 따로 지정하지 않았다. Claude Code는 자동 업데이트되는 상태로 사용했고, 실행일 기준 최신 배포본은 2.1.310이다(2편 참고). 실행별 집계는 [blog-experiments의 swe-bench-inhouse](https://github.com/yceffort/blog-experiments/tree/main/swe-bench-inhouse)에 있고, 이 글의 해결 수, 턴, 시간, 토큰, 도구 호출, 자동 지표 표는 그 CSV에서 다시 만들 수 있다. 공개 벤치마크 수치는 2026년 10월 30일에 각 문서와 리더보드에서 확인한 값이다.
## 무엇을 어떻게 비교했나
사내 코드를 보낼 수 있는 호출 경로가 정해져 있었고, 그 경로에서 쓸 수 있는 오픈웨이트 후보가 GLM 5.3이었다. 1편에서 후보로 적었던 Qwen은 적절한 호출 경로가 없어 이번 비교에서 제외했다. 기준 모델은 현재 Claude Code에서 쓰고 있는 Claude Sonnet 5.5다.
| 조건 | 값 |
| ---- | ------------------------------------------------------------------------------------- |
| 문항 | 기본 트랙 22, 명세 트랙 14 |
| 반복 | 모델마다 문항당 3회, 모두 108회. 회차마다 처음부터 다시 풂 |
| 한도 | 문항당 25분, 60턴 |
| 도구 | Read, Edit, Write, Grep, Glob 과 pnpm, npx, node, ls, cd, git diff/status/log 만 허용 |
| 격리 | 작업 디렉터리를 홈 밖에 두어 개인 지침 제외 |
| 채점 | 실제 PR 의 테스트로 판정. 에이전트가 고친 테스트 파일은 제외 |
| 품질 | tsc, eslint, 포맷 위반이 정답 상태보다 늘어난 수. 1회차 36문항은 블라인드 패치 리뷰 |
| 비용 | 같은 108회의 토큰 × 공개 단가. GLM 은 청구액으로 교차 확인 |
명세 트랙에서는 인터페이스 명세가 고칠 위치를 상당 부분 알려 주므로, 해결률은 기본 트랙과 나눠 집계했다. 턴 수는 Claude Code가 보고한 `num_turns`를 썼고, 60턴 한도 도달 여부는 결과의 `subtype`이 `error_max_turns`인지로 판단했다[^1].
## 결과를 해석할 때 고려한 조건
같은 36문항을 같은 하네스와 한도로 풀었지만, 결과를 해석할 때 고려할 조건이 몇 가지 있다.
문항은 패키지 하나의 병합 PR 20건에서 나온 36개다. 같은 PR에서 쪼갠 문항은 코드 영역을 공유하므로 독립 표본이 아니고, 문항 수도 적어 해결률의 몇 퍼센트포인트 차이에 의미를 두기 어렵다. 그래서 어떤 문항을 풀고 어디서 멈췄는지를 중심으로 봤다. 이 패키지의 결과로 사내 TypeScript 업무 전체를 판단하기도 어렵다.
문항당 25분과 60턴이라는 한도 중에서 실제로 실행을 중단시킨 것은 60턴이었다. 개인 지침을 격리한 실행에서는 25분에 걸린 경우가 없었다. GLM이 60턴에서 중단된 61회는 턴당 중앙값 6.6초로, 7분 안팎에 끊겼다. 같은 속도가 유지된다고 가정하면 25분 동안 약 230턴을 돌 수 있다. 뒤에서 살펴볼 한도 완화 실험에서도 150턴을 주자 GLM은 명세 14문항이 모두 해결로 채점됐다.
이번에는 정해진 턴 안에서 몇 문항을 얼마에 푸는지 보고 싶었다. 턴마다 모델이 컨텍스트 전체를 다시 읽으므로 턴을 늘리면 토큰 사용량과 비용도 늘어난다. 60턴은 이를 제한하려고 첫 시험 실행에서 정한 값으로, 공개 평가 기준을 따른 것은 아니다. 이 한도를 바꾸면 GLM의 해결 수도 달라진다.
추론 설정은 두 모델 모두 Claude Code 기본값으로 뒀다. Sonnet에는 Medium이 적용되고, 게이트웨이가 GLM에 어떤 추론 강도를 적용했는지는 확인하지 못했다. 결과 `usage`의 `thinking_tokens`는 GLM이 108회 모두 0, Sonnet이 합계 7만 4천이었다. 게이트웨이가 GLM의 추론 토큰을 보고하지 않은 것인지, 추론 없이 동작한 것인지는 이 값으로 구분할 수 없다. 두 모델의 추론 강도를 같게 맞추지는 못했다.
비용은 두 모델이 같은 108회에서 쓴 토큰에 각 모델의 공개 단가를 곱해 계산했다. 실제 호출 경로의 단가와는 다르므로, 이 실험에만 쓴 GLM은 청구액과도 비교해 추정이 크게 어긋나지 않았는지 확인했다.
소요 시간은 두 모델의 실행 시각과 동시 실행 수가 달라 참고값으로만 봤다. 패치 리뷰는 1회차 72개만 진행했다. 리뷰어인 Claude가 비교 대상인 Sonnet과 같은 회사의 모델이라는 점도 고려해, 점수보다는 내가 직접 확인한 결함을 중심으로 살펴봤다.
## 공개 벤치마크는 평가 조건이 달랐다
실험에 앞서 공개 자료에서 두 모델을 같은 조건으로 비교할 수 있는 항목을 찾아봤지만 거의 없었다. Anthropic의 Sonnet 5.5 시스템 카드는 SWE-Bench Pro, Multilingual, Multimodal과 Terminal-Bench 4.0을 최대 추론 강도로 5회 평가한 평균을 보고한다. Z.ai의 GLM-5.3 모델 카드에는 SWE-bench 계열 항목이 없다. 공통 항목은 DeepSWE v1.1 하나인데 하네스와 한도가 다르고, Terminal-Bench는 버전이 다르다. 비교 대상으로 삼은 Claude 모델도 서로 달랐다.
| 벤치마크 | Sonnet 5.5 | GLM 5.3 | 비교 가능 여부 |
| ---------------------- | ------------------------------ | ---------------------------- | --------------------------------- |
| SWE-Bench Pro | 81.3 | 없음 | 불가 |
| SWE-Bench Multilingual | 90.3 | 없음 | 불가 |
| DeepSWE v1.1 | 71.0 (5회 평균, 하네스 미표기) | 66.9 (mini-swe-agent, 6시간) | 같은 벤치마크, 다른 하네스와 한도 |
| Terminal-Bench | 4.0 에서 70.6 | 2.1 에서 88.2, 3.0 에서 28.3 | 버전이 달라 불가 |
| 비교 대상 모델 | Sonnet 5, Opus 5.5 | Opus 4.8 | 서로 다른 Claude 모델과 비교 |
실행 예산도 실제 사용 조건과 차이가 컸다. GLM 카드의 각주에 따르면 Terminal Bench 3.0은 600 에이전트 턴과 10시간, DeepSWE는 6시간 제한으로 평가했다. 추론 강도는 따로 지정하지 않으면 최대로 동작하며, Sonnet 카드도 최대 추론 강도에서 평가한 결과다. 이 점수로는 "넉넉한 예산과 최대 추론 강도에서 얼마나 푸는가"를 살펴볼 수 있다. 나는 Claude Code를 기본 설정으로 쓸 때 우리 코드의 버그를 고치는 데 얼마나 기다려야 하고, 비용은 얼마나 드는지가 궁금했다. 이를 알아보려면 직접 실행해 봐야 했다. 제3자 리더보드와 Artificial Analysis의 상세 수치는 뒤의 "공개 벤치마크의 수치와 조건"에 모았다.
## 기본 트랙의 해결 수는 비슷했고, 명세 트랙에서 차이가 났다
| 항목 | Claude Sonnet 5.5 | GLM 5.3 |
| ---------------------------------------- | --------------------------------: | ----------------------: |
| 기본 트랙 해결 (66회 중) | 63 | 65 |
| 명세 트랙 해결 (42회 중) | **42** | 35 |
| 회차별 기본 / 명세 | 22, 20, 21 / 14, 14, 14 | 21, 22, 22 / 11, 12, 12 |
| 3회 모두 해결한 문항 (기본 22 / 명세 14) | 20 / 14 | 21 / 11 |
| 한 번도 못 푼 문항 | 없음 | 1개 (명세) |
| 회차마다 결과가 바뀐 문항 | 2개 | 3개 |
| 60턴 한도에서 중단된 실행 | 0회 | 61회 (그중 해결 53회) |
| 못 푼 실행의 이유 | 끝까지 작업했지만 테스트 실패 3회 | 60턴 한도에서 중단 8회 |
기본 트랙의 해결 수 차이 2회에 큰 의미를 두기는 어려웠다. 같은 문항을 세 번 풀어도 Sonnet은 2문항, GLM은 3문항에서 결과가 바뀌었다. 1회차만 보면 Sonnet 22 대 GLM 21이었는데, 3회 합계는 63 대 65로 뒤집힌다. 기본 트랙에서는 두 모델이 비슷한 수준으로 풀었다고 봤다.
명세 트랙에서는 Sonnet이 42회 모두 풀었고 GLM은 35회다. GLM이 못 푼 8회 가운데 7회가 명세 트랙이다. 36문항 전체의 회차별 결과를 격자로 그리면 다음과 같다. 문항 식별자는 PR 단위로 묶은 익명 기호이고, 숫자가 붙은 것은 한 PR을 주제별로 쪼갠 문항이다. 칸의 숫자는 해결한 실행의 턴 수, X는 실패, 빗금은 60턴 한도에서 중단된 실행이다.
같은 내용을 표로 적으면 다음과 같다. 칸의 숫자는 해결한 실행의 턴 수, X는 실패, \* 는 60턴 한도에서 중단된 실행이다.
| 문항 | 트랙 | f2p | Sonnet 1 / 2 / 3회차 | GLM 1 / 2 / 3회차 |
| ---- | ---- | --: | -------------------- | ------------------ |
| A1 | 기본 | 1 | 20 / 17 / 12 | 61\* / 53 / 61\* |
| A2 | 기본 | 1 | 7 / 9 / 10 | 77 / 61\* / 61\* |
| A3 | 기본 | 1 | 4 / 4 / 4 | 41 / 26 / 31 |
| B1 | 기본 | 1 | 12 / 17 / 18 | 44 / 46 / 42 |
| B2 | 기본 | 1 | 4 / 4 / 4 | 36 / 62 / 41 |
| C | 기본 | 2 | 11 / 12 / 11 | 61\* / 61\* / 61\* |
| D1 | 기본 | 1 | 3 / 3 / 3 | 21 / 57 / 19 |
| D2 | 기본 | 2 | 3 / 3 / 3 | 18 / 17 / 16 |
| E1 | 기본 | 2 | 8 / 9 / 8 | 31 / 32 / 25 |
| F | 기본 | 1 | 5 / 5 / 6 | 72 / 63 / 70 |
| G | 기본 | 4 | 8 / 10 / 10 | 53 / 61\* / 63 |
| H | 기본 | 3 | 7 / 5 / 7 | 61\* / 59 / 53 |
| I | 기본 | 1 | 11 / 8 / 12 | 61\* / 61\* / 61\* |
| J | 기본 | 2 | 6 / 9 / 7 | 61\* / 71 / 61\* |
| K1 | 기본 | 2 | 19 / 15 / 16 | 61\* / 61\* / 61\* |
| K2 | 기본 | 2 | 6 / 6 / 5 | 48 / 29 / 57 |
| K3 | 기본 | 1 | 6 / 5 / 5 | 59 / 48 / 58 |
| K4 | 기본 | 2 | 16 / X 12 / X 12 | X\* / 61\* / 65 |
| K5 | 기본 | 4 | 7 / 8 / 6 | 61\* / 61\* / 61\* |
| L1 | 기본 | 1 | 7 / 6 / 7 | 35 / 44 / 34 |
| L2 | 기본 | 1 | 7 / 7 / 7 | 58 / 62 / 57 |
| L3 | 기본 | 2 | 10 / X 11 / 9 | 61\* / 61\* / 61\* |
| B3 | 명세 | 1 | 9 / 11 / 10 | 61\* / 61\* / 61\* |
| B4 | 명세 | 3 | 11 / 11 / 11 | 61\* / 61\* / 61\* |
| M | 명세 | 10 | 4 / 4 / 4 | 22 / 51 / 24 |
| E2 | 명세 | 2 | 14 / 15 / 18 | 61\* / 61\* / 61\* |
| E3 | 명세 | 13 | 45 / 40 / 45 | 61\* / 61\* / 61\* |
| N | 명세 | 13 | 31 / 33 / 36 | 61\* / 61\* / 61\* |
| O | 명세 | 3 | 8 / 6 / 6 | 61\* / 67 / 61\* |
| P1 | 명세 | 5 | 19 / 20 / 20 | X\* / X\* / 61\* |
| P2 | 명세 | 19 | 21 / 25 / 23 | 61\* / 61\* / 61\* |
| P3 | 명세 | 8 | 20 / 20 / 18 | 64 / 61\* / 61\* |
| Q | 명세 | 17 | 60 / 62 / 55 | X\* / 61\* / X\* |
| L4 | 명세 | 20 | 34 / 29 / 29 | 61\* / 61\* / 61\* |
| L5 | 명세 | 3 | 6 / 6 / 8 | 56 / 61\* / 61\* |
| R | 명세 | 12 | 46 / 44 / 51 | X\* / X\* / X\* |
함수 하나를 고치는 문항에서도 턴 차이가 났다. 버전 문자열 자르기와 로그 마스킹 문제인 D1, D2를 Sonnet은 3턴에 끝냈고 GLM은 16~57턴을 썼다. D1의 문제 설명은 다음과 같다. 2편의 예시처럼 식별자는 바꿨고, 채점은 PR이 추가한 테스트 1개와 기존 테스트 216개로 한다.
```text
# 3자리 버전 구성 요소가 고정 헤더 슬롯을 넘칩니다
## 현상
설정 함수의 `device.osVersion`, `device.appVersion` 에 3자리 이상인 버전 구성 요소가
있으면(예: `osVersion: '100.2'`, `appVersion: '1.2.100'`), 해석된 설정의 해당 값이
`'100'` 처럼 3글자로 남습니다. 고정 헤더의 버전 슬롯은 구성 요소마다 2바이트 고정폭이라,
이 값이 들어가면 헤더 레이아웃이 밀립니다.
## 재현
`configure({ url, auth, device: { osVersion: '100.2', appVersion: '1.2.100' } })` 를
호출한 뒤 `getConfig().device` 를 보면 `os.major` 가 `'100'`, `app.patch` 가 `'100'` 입니다.
## 기대 동작
- 해석된 설정의 각 버전 구성 요소(`os.major`, `os.minor`, `app.major`, `app.minor`,
`app.patch`)는 항상 정확히 2글자여야 합니다.
- 짧은 값을 채우는 기존 규칙은 그대로 두고, 3글자 이상이면 앞의 2글자만 남깁니다.
예: `'100.2'` 의 major 는 `'10'`, `'1.2.100'` 의 patch 는 `'10'`.
```
GLM이 60턴 안에 스스로 끝낸 실행은 기본 트랙에 몰려 있었다. 명세 트랙에서 세 번 모두 스스로 끝낸 문항은 M뿐이다. M은 f2p가 10개지만, 2편에서 설명했듯 9개가 연쇄 실패여서 실제로는 한 가지 동작만 고치면 된다. 두 모델 모두 이 문항을 명세 트랙에서 가장 적은 턴으로 풀었다. 테스트 개수만으로 난이도를 판단하기 어려운 사례다.
Sonnet의 실패 3회는 모두 60턴 안에 스스로 작업을 마친 결과였다. K4에서 두 번은 새 테스트를 통과시키는 대신 기존 테스트 1개를 깨뜨렸고, L3에서 한 번은 새 테스트 1개와 기존 테스트 8개에 실패했다. GLM의 실패 8회는 모두 60턴 한도에서 중단됐다. 더 실행하면 풀었을지는 다음 절의 한도 완화 실험에서 다룬다.
R은 GLM이 세 번 모두 못 푼 유일한 문항이다. 새 옵션의 의미가 연결 단위에서 구독 단위로 바뀌어 13개 파일을 고쳐야 했다. Sonnet도 이 문항에는 44~51턴을 썼다. 문제 설명에서 현상 부분만 옮기면 다음과 같다. 기대 동작은 아홉 항목이고, 인터페이스 명세의 한 항목은 2편에 실었다.
```text
# 같은 대상을 구독하는 화면끼리 PUSH 전달 주기가 서로 영향을 줍니다
## 현상
PUSH 합치기 윈도우는 구독 단위가 아니라 연결 전체에 하나만 적용됩니다. `subscribe` 의
`options.legacyWindowTime` 은 구독별 옵션처럼 보이지만, 소켓을 처음 여는 구독이 준 값이
이후 모든 구독에 적용됩니다. 이미 소켓이 열려 있으면 나중에 다른 값을 줘도 무시됩니다.
그 결과 같은 대상을 보는 차트(모든 건이 필요)와 목록의 한 행(윈도우당 최신값 하나면 충분)이
서로 다른 전달 주기를 가질 수 없습니다. 어느 쪽이 먼저 구독했는지에 따라 둘 다 매 건을
받거나 둘 다 합쳐진 값만 받습니다.
```
## 해결률은 한도에 따라 달라지는 값이다
GLM의 108회 중 61회가 60턴 한도에서 중단됐다. 명세 트랙은 42회 중 36회, 기본 트랙은 66회 중 25회다. 중단된 실행 중 53회는 그 시점의 코드가 테스트를 통과했다. 모델이 "다 됐다"고 판단하기 전에 실행이 끊겼지만 채점 기준은 충족한 것이다. 따라서 테스트 통과 기준으로는 100/108이고, 스스로 작업을 마친 실행만 세면 47회다. 이 글의 해결 수는 채점 결과대로 100회로 집계하고, 그중 53회는 중단된 코드라는 점을 함께 표시한다.
테스트를 통과한 중단 패치에서도 정리가 덜 된 부분이 보였다. 1회차에서 중단된 GLM 패치 20개 중 16개가 테스트를 통과했는데, 이 16개의 리뷰 종합 점수는 5점 만점에 3.5였다. 스스로 작업을 마친 16문항의 4.31보다 낮았다. 패치에는 스크래치 테스트 파일이나 어떤 스크립트에서도 사용하지 않는 일회성 확인 스크립트가 남아 있었고, 요청과 무관한 패키지의 잠금 파일 해시가 바뀐 경우도 있었다. 실제 사용 중에 "이쯤이면 됐겠지" 하고 실행을 끊었다면, 테스트 통과 여부와 별개로 이런 변경을 검토해야 했을 것이다.
한도를 늘렸을 때의 결과도 있다. 2편의 첫 실행 중에 명세 트랙 14문항을 60분과 150턴으로 늘려 1회씩 실행한 참고 실험이다. 첫 실행의 조건(개인 지침 포함, 다른 호출 경로)이라 본 비교와 합산하지 않고 따로 적는다.
| 항목 (명세 14문항, 60분, 150턴, 1회) | Sonnet 5.5 | GLM 5.3 | DeepSeek V4.1 Flash | Qwen3.8-27B |
| ------------------------------------ | ---------: | ------: | ------------------: | --------------------------- |
| 해결 | 14/14 | 14/14 | 14/14 | 11/11 (3회 게이트웨이 오류) |
| 턴 중앙값 | 19 | 73.5 | 82 | 71 |
| 60턴을 넘긴 실행 | 0 | 8 | 8 | 7 |
| 150턴 한도에서 중단된 실행 (해결) | 0 | 1 (1) | 1 (1) | 1 (1) |
| 14문항 소요 시간 | 0.3시간 | 2.4시간 | 2.2시간 | 2.6시간 (11문항) |
25분과 60턴 조건에서 오픈웨이트 모델 3종이 명세 트랙을 풀지 못한 27회는 모두 시간이나 턴 한도에 걸렸다. 한도를 늘린 뒤에는 실행한 문항이 채점 기준으로 모두 해결됐다. 그중 세 모델 각각 1회는 150턴 한도에서 중단된 시점의 코드가 통과한 것이다. 세 모델이 세 번 모두 못 풀었던 R은 DeepSeek이 159턴에 스스로 끝냈고, GLM은 150턴 한도에서 중단됐지만 그 시점의 코드가 테스트를 통과했다.
GLM 카드가 Claude Opus 4.8과 비슷하거나 높은 점수를 보고한 조건은 600턴과 10시간, 6시간 같은 예산이었다. 이번 참고 실험에서도 예산을 늘리면 GLM이 더 많은 문항을 풀었다. 다만 정해진 턴 안에서 작업을 마치는지를 보면 두 모델의 차이가 컸다. 해결 수보다 턴과 시간에서 그 차이가 더 뚜렷했다.
## 턴 6.4배, 시간 15.8배, 입력 토큰 13.5배
Sonnet은 108회 중 54회가 10턴 안에 끝났고, GLM은 10턴 안에 끝난 실행이 없다. 중앙값으로 보면 Sonnet 9.5턴에 GLM 61턴이다. 한도에 걸린 실행은 Claude Code가 61턴으로 보고하므로 GLM의 중앙값이 한도보다 크게 나온다[^1].
| 항목 | Claude Sonnet 5.5 | GLM 5.3 | 배수 |
| ------------------------------------- | ----------------: | ----------------: | -----: |
| 턴 중앙값 | 9.5 | 61 | 6.4배 |
| 턴 중앙값 (기본 / 명세) | 7 / 20 | 61 / 61 | |
| 문항당 소요 시간 중앙값 | 23초 | 363.5초 | 15.8배 |
| 소요 시간 중앙값 (기본 / 명세) | 19초 / 43.5초 | 325.5초 / 414.5초 | |
| 36문항 1회 소요 시간 | 0.4시간 | 3.5~3.8시간 | |
| 도구 호출 수 (3회 합) | 1,434 | 6,701 | 4.7배 |
| 실행당 입력측 토큰 중앙값 (캐시 포함) | 14만 | 360만 | 25.7배 |
| 입력측 토큰 합 (3회, 캐시 포함) | 2,559만 | 3억 4,671만 | 13.5배 |
| 출력 토큰 합 (3회) | 54만 | 428만 | 7.9배 |
GLM의 61회는 60턴에서 끊긴 값이므로 이 배수들은 하한이다. 도구 호출도 많았다. 실행당 중앙값으로 Sonnet은 Edit 3회, Read 2회, Bash 1회를 썼고, GLM은 Read 22회, Bash 21회, Edit 10회를 썼다. Sonnet은 문제 설명에서 지목한 파일을 한두 번 읽고 고친 뒤 테스트를 한 번 돌리는 경우가 많았다. GLM은 같은 파일을 여러 번 읽고 테스트를 반복하는 경우가 많았다.
테스트 파일을 고친 실행도 GLM은 108회 중 97회, Sonnet은 9회였다. 프롬프트에 "테스트를 고쳐도 되지만 채점에는 반영되지 않는다"고 적어 뒀지만, GLM은 대부분의 실행에서 테스트 파일 수정에도 턴을 썼다.
허용 목록 밖의 도구 호출은 Sonnet에서 148회, GLM에서 382회 거부됐다. 거부된 호출에도 턴이 쓰인다. GLM 출력에는 도구 이름으로 ``라는 문자열을 보낸 호출도 20회 있었다. 도구 호출 형식이 깨진 것으로, 해당 호출은 모두 실패했다. 함께 돌린 다른 모델 5종에서는 같은 문제가 없었다.
입력측 토큰 중 캐시 읽기가 차지한 비율은 Sonnet 91%, GLM 97%였다. 턴을 거듭할수록 파일 내용과 테스트 출력이 컨텍스트에 쌓이고, 다음 턴에서 이를 다시 읽는다. GLM은 턴 수뿐 아니라 턴마다 읽는 컨텍스트도 컸다. 턴당 입력측 토큰은 Sonnet이 약 1만 7천, GLM이 약 5만 9천으로 3.5배 차이가 났다. 3회 합계에서 총 턴 수는 1,542 대 5,898로 약 3.8배였다. 여기에 턴당 입력 토큰 차이인 약 3.5배를 곱하면 전체 입력 토큰의 차이인 약 13.5배가 된다.
## 단가가 낮아도 비용은 더 들었다
비용은 두 모델이 같은 108회에서 쓴 토큰에 각 모델의 공개 단가를 곱해 계산했다. GLM은 이 실험에만 쓴 모델이라 청구액으로 교차 확인할 수 있었다.
| 항목 (108회 토큰 × 공개 단가) | Claude Sonnet 5.5 | GLM 5.3 |
| ---------------------------------------------- | ----------------: | --------: |
| 108회 합계 | 약 \$13.3 | 약 \$122 |
| 36문항 1회 평균 | 약 \$4.4 | 약 \$40.7 |
| 해결 1건당 | 약 \$0.13 | 약 \$1.22 |
| 실제 청구액 (스모크 테스트와 재실행 일부 포함) | 해당 없음 | \$147.85 |
Sonnet은 [Anthropic 공개 단가](https://platform.claude.com/docs/en/about-claude/pricing)를 적용했다. 2026년 10월 30일 기준으로 100만 토큰당 입력 \$2, 출력 \$10, 캐시 읽기 \$0.10, 5분 캐시 쓰기 \$2.50이다. GLM은 Artificial Analysis가 Z.ai API 기준으로 제시한 입력 \$1.40, 출력 \$4.40을 쓰고, 캐시 읽기에는 같은 페이지의 81% 할인을 적용했다.
GLM은 입력측 토큰의 97%가 캐시 읽기라 캐시 할인을 어떻게 적용하느냐에 따라 비용이 달라진다. 할인율을 바꿔 계산해 봐도 검토한 가정에서는 모두 Sonnet의 5배 이상이었다[^2]. 청구액 \$147.85에는 본 실행 외에 스모크 테스트와 끊긴 뒤 다시 돌린 사용량이 조금 섞여 있고, 호출 경로의 단가도 Z.ai API와 다르다. 그래도 토큰 기준으로 계산한 \$122와 금액 규모가 비슷해 추정이 크게 어긋나지 않았다고 봤다.
GLM은 명세 트랙 해결률이 낮았고 비용도 더 들었다. 공개 단가는 GLM이 입력 30%, 출력 56% 저렴하지만, 입력 토큰을 13.5배 쓰면서 총비용은 오히려 커졌다. 뒤에서 살펴볼 Artificial Analysis의 과제당 비용에서도 비슷한 차이가 나타난다. 단가만으로는 실제 작업에 드는 비용을 예상하기 어려웠다.
이 비용은 61회가 60턴에서 끊긴 상태의 값이다. 한도 완화 실험에서 오픈웨이트 모델의 명세 14문항 비용은 60턴 조건의 1.5~3배였다. 한도를 늘려 GLM이 명세 트랙을 모두 풀더라도 해결 1건당 비용 격차는 지금의 \$0.13 대 \$1.22보다 더 벌어진다.
## 테스트를 통과한 패치에도 버그가 있었다
자동 채점으로 확인한 것은 PR의 테스트를 통과했는지까지다. 1편에서 인용한 연구에서도 테스트를 통과한 패치에 결함이 남을 수 있다고 지적했다. 이를 확인하려고 1회차 36문항의 패치 72개를 리뷰했다. 문항마다 두 패치에 P와 Q 라벨을 무작위로 붙여 작성 모델을 가리고, 문제 설명과 정답 패치, base 코드와 함께 Claude에게 보여 줬다.
평가 항목은 정확성, 변경 범위, 기존 코드와의 일관성, 단순성, 코드 정리 상태(디버그 잔재나 죽은 코드), 종합이며 각각 1~5점이다. 종합 점수는 항목별 평균 대신 "이 PR 을 승인하겠는가"를 기준으로 매기게 했다. 5점은 그대로 승인, 3점은 수정 요청 후 승인, 1점은 반려다. 3점 이하를 준 항목에는 패치 원문을 인용한 근거를 남기도록 했고, 실제 버그(high)로 분류한 지적은 내가 패치와 base 코드를 열어 다시 확인했다. 점수보다는 이렇게 직접 확인한 결함을 중심으로 봤다.
| 항목 | Claude Sonnet 5.5 | GLM 5.3 |
| -------------------------------------------------------- | ---------------------: | ---------------------: |
| 정확성 | 4.44 | 4.19 |
| 변경 범위 | 4.94 | 4.03 |
| 기존 코드와의 일관성 | 4.39 | 4.19 |
| 단순성 | 4.42 | 3.61 |
| 코드 정리 상태 | 4.50 | 4.17 |
| **종합** | **4.28** | 3.64 |
| 종합 (기본 / 명세) | 4.23 / 4.36 | 4.00 / 3.07 |
| 종합 (GLM 이 스스로 끝낸 16문항) | 4.56 | 4.31 |
| 종합 (GLM 이 60턴에서 중단됐지만 테스트는 통과한 16문항) | 4.00 | 3.50 |
| 종합 (GLM 이 60턴에서 중단되고 테스트도 실패한 4문항) | 4.25 | 1.50 |
| 두 패치 중 더 낫다고 본 문항 수 | 26 | 10 |
| 지적 수 (high / medium / low) | 2 / 9 / 19 | 3 / 26 / 26 |
| 실제 버그로 확인된 결함 | 2건 (스스로 끝낸 코드) | 3건 (모두 중단된 코드) |
| 그중 테스트를 통과한 패치 | 2건 | 0건 |
"더 낫다고 본 문항 수" 26 대 10에는 리뷰 규칙상 동률이어도 하나를 골라야 했던 경우가 들어 있다. 메모에 "우열을 가릴 수 없다", "사실상 동률", "근소한 차이"라고 적힌 13문항을 빼면 17 대 6이다.
GLM의 1회차 패치 36개 중 20개는 60턴에서 중단된 코드였다. 종합 점수 차이 0.64도 상당 부분 이 문항들에서 나왔다. 중단됐지만 테스트를 통과한 16문항은 평균 3.50으로 "수정 요청 후 승인"에 가깝고, 테스트도 실패한 4문항은 1.50으로 반려에 가깝다. GLM이 스스로 끝낸 16문항에서도 Sonnet의 점수가 더 높았지만 차이는 줄었다.
실제 버그로 확인된 결함은 5건이다. Sonnet의 2건은 작업을 끝낸 코드이고 테스트를 통과했다.
- Sonnet은 연결 전에 등록한 구독이 로그인 뒤 서버로 두 번 전송되는 문제를 고치면서, 로그인 직후 대기열에서 구독 요청만 지우고 해제 요청은 남겼다. 연결 전에 같은 대상을 구독, 해제, 다시 구독하면 대기열에는 구독, 해제, 구독이 쌓이는데 수정 후에는 해제만 남는다. 로그인 뒤 현재 구독 목록을 다시 보낸 다음 남아 있던 해제가 전송되어, 앱은 구독 중이라고 알고 있지만 서버는 구독을 푼 상태가 된다. 정답은 구독과 해제를 모두 지운다. 테스트는 이 순서를 다루지 않아 통과했다. 코드로 확인했고 실행해서 재현하지는 않았다. 같은 문항에서 GLM은 두 종류를 모두 지워 안전하게 고쳤지만, 리뷰어는 그 코드가 장황하고 변경 이력 파일까지 건드렸다고 적었다.
- Sonnet은 특정 메시지를 구독해도 콜백이 호출되지 않는 문제를 고치면서, 비어 있을 수 있는 값의 타입을 그대로 참조하는 타입 표현을 썼다. 동작은 맞지만 `tsc`를 돌리면 TS18048 오류가 난다. vitest는 타입을 검사하지 않아 테스트는 통과했고, 타입 검사를 거치는 빌드나 CI에서 막힌다.
GLM의 3건은 모두 60턴에서 중단됐고 테스트도 실패한 코드다.
- GLM은 새 메시지 종류를 지원하는 문항에서 메시지 형식 정의 파일은 추가했지만, 실행 중에 메시지를 해석할 때 읽는 정의 묶음에는 등록하지 않았다. 그 메시지를 받아도 해석하지 못하고 테스트 2개가 실패했다.
- GLM은 닫힘 이벤트를 놓친 소켓을 정리하는 문항에서 필요한 함수 두 개를 만들어 놓고 정리하는 곳에서 부르지 않은 채 60턴에 걸렸다. 그 위치에는 `// TEMP-BUGGY-REVERT`라는 임시 주석이 남아 있었다. 주석 이름대로 수정 전 동작을 확인하려고 잠시 되돌린 상태로 보인다.
- GLM은 구독자마다 전달 주기를 따로 두는 문항에서, 한 구독자의 콜백 안에서 다른 구독자를 해제하면 방금 해제한 구독자에게도 데이터가 전달되는 코드를 냈다. 문제 설명이 막으라고 한 동작이고 테스트 1개가 실패했다.
GLM의 결함 세 건은 한도에서 중단된 코드에서 발견됐다. Sonnet의 결함 두 건은 모델이 작업을 마쳤고 테스트까지 통과한 코드에 남아 있었다. 두 모델 모두 테스트 결과와 별개로 패치를 검토할 필요가 있었다.
테스트를 통과한 중단 패치 중에서는 L3를 자세히 살펴봤다. 끊긴 연결에서 다시 구독하면 연결을 복구하고, 끊긴 상태에서 해제하면 서버에 프레임을 보내지 않도록 고치는 문항이다. Sonnet은 1회차에 10턴으로 끝냈고 리뷰 종합 점수는 5점이었다. GLM은 61턴에서 중단됐지만 테스트는 통과했다.
GLM 패치에도 재구독 시 연결 복구와 해제 프레임 생략은 구현되어 있었다. 다만 스크래치 테스트 파일이 남아 있었고, 연결을 되살리는 호출에서 기존 코드가 전달하던 묶음 전달 옵션이 빠져 있었다. 테스트는 그 옵션을 확인하지 않았다. 리뷰 종합 점수는 3점으로 수정 요청 후 승인에 해당했다.
다른 문항에서도 비슷한 지적이 있었다. 모의 소켓 도우미 문항(B3)에는 npm 스크립트 어디에서도 사용하지 않는 일회성 확인 스크립트와, 오류를 로그만 남기고 무시하는 예외 처리가 들어갔다. 디버그 도구 문항(O)에서는 요청과 무관한 패키지의 잠금 파일 해시가 바뀌었다. 모두 중단 시점의 패치에서 확인한 것이다.
수정을 요청할 만한 지적(medium)도 살펴봤다. Sonnet에서는 주로 변경 범위와 기존 코드의 재사용이 문제였다. 요청 하나를 정리 대상에서 빼면 되는 작업에 요청 식별자를 세 모듈에 걸쳐 전달하고, 네 개의 저장소에서 항목을 꺼냈다 넣는 구조를 만든 경우가 있었다. 기존 정리 헬퍼와 같은 작업을 반복문 안에 다시 쓰거나, 기존 키 생성 헬퍼 대신 새 규칙을 만들어 두 규칙이 어긋날 위험을 만든 경우도 있었다. 상태를 모듈 전용 변수에 두어 테스트에서 초기화할 수 없게 된 패치도 있었다.
GLM에서는 주석과 변경 규모에 관한 지적이 많았다. 3점 이하 평가의 근거 중 21건이 수정 규모에 비해 설명 주석이 많다는 내용이었다. 한 곳의 호출 순서만 바꾸는 데 20줄 가까운 주석과 예외 처리가 붙거나, 한 줄짜리 필터로 충분한 함수가 디버그 로그를 포함해 40줄이 된 경우다.
메시지 정의 묶음 파일을 다시 생성하면서 기존 항목을 키 순서로 정렬해 100줄 가까운 무관한 diff를 만든 패치도 있었다. 10줄짜리 로직을 위해 새 파일과 테스트용 초기화 함수, 긴 문서 주석을 추가하기도 했다. 서버가 아직 정의되지 않은 값을 보내면 속성 접근에서 예외가 나는 방어 누락도 하나 있었다. 타입상 불가능한 값이라고 가정한 코드였다.
## 자동 지표는 서로 엇갈린다
| 항목 (3회 전체, 정답 상태보다 늘어난 수) | Claude Sonnet 5.5 | GLM 5.3 |
| ---------------------------------------- | ----------------: | -----------: |
| tsc 오류 | 3 | 7 |
| eslint 오류 | 44 | 9 |
| 포맷 위반 파일 | 15 | 12 |
| 변경 파일 수 중앙값 (정답은 2) | 1 | 2 |
| 변경 줄 수 중앙값 (테스트 제외) | 19 | 45 |
| 정답 패치 대비 변경 크기 중앙값 | 0.5배 | 1.0배 |
| 추가한 주석 줄 (합 / 실행당 중앙값) | 407 / 1 | 2,590 / 15.5 |
타입 오류와 변경 크기, 주석은 GLM이 많았고 린트 오류는 Sonnet이 많았다. Sonnet의 린트 오류 44건 중 27건은 import 정렬 규칙 위반이다. 그중 24건이 Q 문항에서 3회 모두 8건씩 나온 결과였다. 이 규칙은 `eslint --fix`로 자동 수정할 수 있다. 이를 제외해도 Sonnet은 17건, GLM은 7건으로 Sonnet의 오류가 더 많았다. 린트 오류가 하나라도 생긴 실행은 Sonnet 19회, GLM 3회였다. 모두 코드 형식 규칙이라 결함 수에는 넣지 않았다.
변경 크기의 중앙값은 Sonnet이 정답 패치의 0.5배, GLM이 1.0배였다. 가운데 절반의 실행은 Sonnet이 0.25배에서 0.88배 사이, GLM이 0.54배에서 1.6배 사이에 들어갔다. 정답 패치에도 리팩터링과 주석 정리가 섞여 있어 변경량만으로 품질을 판단하기는 어렵다. 다만 리뷰에서도 Sonnet이 변경 범위 점수에서 4.94 대 4.03으로 더 좋은 평가를 받았다.
추가한 주석 줄 수의 중앙값은 Sonnet 1줄, GLM 15.5줄이었다. 가장 많이 추가한 실행은 각각 34줄과 158줄이다. GLM 패치에 설명 주석이 많다는 리뷰 지적이 실제 집계에서도 드러났다.
## 다른 모델은 어땠나
같은 격리 조건과 한도로 사내 게이트웨이의 다른 모델 5종도 실행했다. 회사의 검토 대상은 아니었지만 같은 문항을 푼 결과여서 함께 적는다. Gemini 3.7 Flash와 3.8 Flash는 실행이 두 번 끊겨 3회를 채우지 못했다.
| 모델 | 실행 수 | 기본 해결 | 명세 해결 | 턴 중앙값 | 60턴 중단 (해결) | 36문항 1회 소요 | tsc 새 오류 | 36문항 1회 비용 |
| --------------------- | ------: | --------: | --------: | --------: | ---------------: | --------------: | ----------: | --------------: |
| Claude Sonnet 5.5 | 108 | 63/66 | 42/42 | 9.5 | 0 (0) | 0.4시간 | 3 | 약 \$4.4 |
| GPT-6 Luna | 108 | 65/66 | 38/42 | 32 | 14 (11) | 1.7시간 | 39 | 약 \$0.8 |
| Gemini 3.1 Pro | 108 | 56/66 | 33/42 | 19 | 3 (0) | 1.5시간 | 10 | 약 \$19.3 |
| Gemini 3.1 Flash Lite | 108 | 50/66 | 27/42 | 19.5 | 10 (6) | 0.9시간 | 39 | 약 \$5.6 |
| Gemini 3.7 Flash | 66 | 40/44 | 17/22 | 57.5 | 28 (19) | 3.9~4.0시간 | 3 | 약 \$22.2 |
| Gemini 3.8 Flash | 70 | 30/44 | 15/26 | 61 | 48 (23) | 3.9~4.1시간 | 2 | 약 \$22.2 |
| GLM 5.3 | 108 | 65/66 | 35/42 | 61 | 61 (53) | 3.5~3.8시간 | 7 | 약 \$40.7 |
비용 열은 Sonnet과 GLM이 공개 단가, 나머지 다섯 모델이 사내 게이트웨이 단가표로 계산한 값이라 기준이 섞여 있다. 이 표에서는 모델별 실패 양상을 중심으로 봤다.
GPT-6 Luna는 해결 수가 Sonnet과 비슷하고(103 대 105) 비용은 5분의 1 수준이었다. 이 두 지표로 보면 유력한 대안이다. tsc 새 오류 39건은 108회 중 3회에서 나왔고, 그중 한 실행에서 30건이 발생했다. 자주 실패하기보다 일부 실행에 오류가 몰린 양상이다. 60턴 한도에 걸린 실행은 14회, 테스트 파일을 고친 실행은 91회로 GLM과 비슷했고, Sonnet과 비슷한 수의 문항을 풀면서 턴은 3배 넘게 썼다.
Gemini 3.1 Pro는 다른 모델과 실패의 성격이 달랐다. 못 푼 19회 중 16회는 스스로 작업을 마쳤지만 답이 틀린 경우였다. 턴 중앙값은 19로 Sonnet 다음으로 적었지만, 36문항당 비용은 약 \$19로 7종 중 GLM과 Gemini Flash 2종(약 \$22) 다음으로 높았다. 캐시 읽기 비율이 65%로 낮아 할인을 받지 못한 입력 토큰이 많았기 때문이다. 포맷 위반 파일 134개와 eslint 오류 124건은 7종 중 최다였고, 새로 추가한 `any`도 19개였다.
Gemini 3.1 Flash Lite도 못 푼 31회 중 27회가 틀린 답을 낸 경우였다. `any`를 29개 추가해 이 항목에서는 최다였으며, 캐시 읽기 비율은 26%로 가장 낮았다. 허용 목록 밖의 도구 호출로 거부된 횟수도 522회로 가장 많았다.
Gemini 3.7 Flash와 3.8 Flash는 GLM처럼 한도에서 중단되는 경우가 많았다. 풀지 못한 실행은 모두 60턴 한도에 걸렸고, 3.8 Flash는 70회 중 15회가 코드를 한 줄도 바꾸지 못한 채 중단됐다. 해결률이 같아도 "틀린 답을 빨리 내는 모델"과 "답을 내기 전에 멈추는 모델"을 사용하는 방식은 달라진다. 완료된 패치가 틀렸다면 리뷰와 수정이 필요하고, 한도에 걸렸다면 더 실행할 가치가 있는지 판단해야 한다.
2편에서 버린 첫 실행에는 Qwen3.8-27B와 DeepSeek V4.1 Flash도 있었다. 첫 실행의 조건이라 본 비교에 넣지 않았지만, 양상은 GLM과 비슷했다. 기본 트랙은 66회 중 각각 60회와 64회로 Sonnet과 비슷했고, 명세 트랙은 42회 중 32회와 33회였으며, 명세 트랙에서 못 푼 실행은 전부 시간이나 턴 한도에 걸린 것이었다.
## 공개 벤치마크의 수치와 조건
앞에서 짧게 적은 공개 자료의 수치와 조건을 여기에 모았다. 모두 2026년 10월 30일에 확인한 값이다.
Anthropic의 [Sonnet 5.5 시스템 카드](https://www.anthropic.com/claude-sonnet-5-5-system-card)는 SWE-Bench Pro 81.3, SWE-Bench Multilingual 90.3, SWE-Bench Multimodal 54.3, DeepSWE v1.1 71.0, Terminal-Bench 4.0 70.6을 보고한다. 표의 각주에 따르면 별도 표기가 없는 결과는 적응형 추론을 최대 강도로 켜고 5회 평균한 값이다. Terminal-Bench 4.0은 Claude Code의 `--bare` 모드에서 최대 추론 강도로 쟀고, 5회 시행 기준 표준오차가 ±2.5점이라고 적혀 있다. 비교 대상은 Sonnet 5(SWE-Bench Pro 63.2), Opus 5.5(89.9), GPT-6 Sol이고, SWE-bench Verified는 없다. [발표문](https://www.anthropic.com/news/claude-sonnet-5-5)에는 Claude Code의 기본 추론 강도가 Medium이라는 문장이 있다. 시스템 카드의 점수는 최대 강도로 잰 값이므로, Claude Code를 기본값으로 쓰는 사람이 체감하는 성능과는 조건이 다르다.
Z.ai의 [GLM-5.3 모델 카드](https://huggingface.co/zai-org/GLM-5.3)에는 SWE-bench 계열 항목이 없다. 대신 Terminal Bench 2.1 88.2, Terminal Bench 3.0 28.3, DeepSWE v1.1 66.9, SWE-Marathon 42.5, FrontierSWE 78.1, NL2Repo 58.0을 보고하고, 비교 대상으로 Claude Opus 4.8을 놓았다. 여섯 항목 중 넷에서 GLM이 앞서고 둘(SWE-Marathon 48.8, NL2Repo 69.7)에서 Opus 4.8이 앞선다. 각주의 조건을 보면 Terminal Bench 2.1은 Claude Code 2.1.207에서 6시간 제한으로, Terminal Bench 3.0은 Claude Code에서 600 에이전트 턴과 10시간 제한으로, DeepSWE는 mini-swe-agent에서 6시간 제한으로 쟀다. 추론 강도는 지정하지 않으면 최대로 동작한다고 적혀 있다.
제3자 리더보드도 확인했다. Scale AI의 SWE-Bench Pro 공개 리더보드에는 두 모델 모두 없었다. 새 저장소의 문항으로 매달 평가하는 SWE-rebench에도 두 모델은 없었고, 이전 세대인 Sonnet 5(해결률 56.8%, 문항당 \$1.43)와 GLM-5.2(62.9%, \$1.40)만 있었다. 이전 세대에서는 GLM의 해결률이 높고 비용은 비슷했지만, 이번 세대에도 그럴지는 이 결과만으로 알 수 없다.
[Vals.ai의 SWE-bench Verified](https://www.vals.ai/benchmarks/swebench) 페이지에는 GLM 5.3이 95.40%(문항당 \$0.34, 14분 1초, 958k 토큰, Mini-SWE-agent)로 6위에 있고 Sonnet 5가 79.60%(\$1.49)로 27위에 있지만, Sonnet 5.5는 없다. 이 페이지는 2026년 9월 1일 기준이고 "성능이 포화되어 새 모델은 더 돌리지 않는다"는 보관 표시가 붙어 있다. GLM 5.3의 SWE-bench Verified 점수는 내가 찾은 범위에서 이것이 유일했고, 모델 카드에는 실려 있지 않다.
두 모델이 같은 조건으로 함께 평가된 곳은 [Artificial Analysis](https://artificialanalysis.ai/leaderboards/models)의 Intelligence Index뿐이었다. 코딩 전용 지표는 아니지만 추론 강도별로 값이 나뉘어 있어 참고했다. Sonnet 5.5의 모든 행에는 "with fallback"이 붙어 있다. 안전장치에 걸린 요청은 대체 모델이 답한 조건이다.
| 모델 (추론 강도) | Intelligence Index | 과제당 비용 | 출력 속도 (토큰/초) |
| ---------------------------------- | -----------------: | ----------: | ------------------: |
| Sonnet 5.5 (max, with fallback) | 54 | \$10.02 | 139 |
| Sonnet 5.5 (high, with fallback) | 41 | \$1.64 | 106 |
| Sonnet 5.5 (medium, with fallback) | 30 | \$0.78 | 100 |
| Sonnet 5.5 (low, with fallback) | 25 | \$0.51 | 99 |
| GLM 5.3 (max) | 32 | \$5.01 | 78 |
| GLM 5.3 (low) | 23 | \$1.57 | 74 |
같은 페이지에서 Sonnet 5.5의 단가는 입력 \$2, 출력 \$10이고, GLM 5.3은 Z.ai API 기준 입력 \$1.40, 출력 \$4.40이다. 최대 추론 강도끼리 비교하면 GLM의 과제당 비용은 Sonnet의 절반이다. 하지만 Claude Code 기본값인 medium의 Sonnet(\$0.78)과 비교하면 6배가 넘는다. 낮은 토큰 단가에도 과제당 비용이 높은 것은 그만큼 많은 토큰을 썼기 때문이다. 코딩 에이전트 작업의 비용으로 그대로 적용할 수는 없지만, 단가가 낮아도 실제 비용이 커질 수 있다는 점은 이번 실험과 비슷하다.
## 이 호출 경로와 설정에서는 바꿀 근거를 찾지 못했다
이번 조건에서는 Claude Code의 모델을 GLM 5.3으로 바꿀 근거를 찾지 못했다. 기본 트랙의 해결 수는 비슷했지만 명세 트랙 해결률, 턴과 시간, 비용, 리뷰 점수에서는 Sonnet이 앞섰다. 한도를 늘리면 GLM도 명세 트랙을 풀지만, 비용은 60턴 조건에서 이미 9배 안팎이었고 한도를 늘리면 더 벌어진다. 이 패키지와 호출 경로에서 Claude Code 기본 설정, 25분과 60턴을 적용했을 때는 기존 모델을 유지하는 편이 낫다고 판단했다.
이 결과가 공개 벤치마크와 모순된다고 생각하지는 않는다. GLM 카드의 점수는 수백 턴과 여러 시간을 주고 최대 추론 강도로 평가한 값이다. 이번 한도 완화 실험에서도 GLM은 예산을 더 받으면 어려운 문항을 풀었다. Artificial Analysis에서도 비슷한 수준의 점수를 낼 때 GLM의 과제당 비용이 Sonnet medium보다 몇 배 높았다. 실제로 사람이 기다리며 쓰는 환경에서는 "결국 풀 수 있다"는 것과 함께 "몇 턴에, 얼마에 푸는가"를 봐야 했다. 이번 실험에서는 그 차이가 공개 점수에서 느꼈던 것보다 컸다.
판단이 달라질 조건도 있다. 밤새 돌리는 일괄 수정처럼 사람이 기다리지 않는 작업에서는 턴과 시간이 덜 중요하다. 그래도 비용은 GLM이 높았다. GLM 카드에는 추론 강도를 지정하지 않으면 최대로 동작한다고 적혀 있으므로, 강도를 낮춘 GLM이 턴과 토큰을 얼마나 덜 쓰는지는 재 볼 만하다.
한두 파일을 고치는 기본 트랙만 보면 해결 수는 비슷하지만 턴 중앙값은 7 대 61이다. 검토 대상 밖이었던 GPT-6 Luna는 해결 수가 비슷하면서 비용이 낮았다. 이번 비교에서 GLM 5.3을 선택하지 않았어도, 다른 모델로 바꿀 가능성은 남아 있다.
1편을 쓸 때는 모델 카드의 점수만으로 교체 여부를 판단하기 어려워 우리 코드에서 직접 재보고 싶었다. 이제는 다음 모델이 나와도 같은 36문항을 같은 한도로 다시 실행할 수 있다. 문항을 유지하고 모델 ID만 바꾸면 하루 안에 같은 표를 얻을 수 있으므로, 모델을 바꿀 필요가 생겼을 때 이번 결과와 비교해 보려고 한다.
[^1]: Claude Code가 보고하는 `num_turns`는 설정한 한도보다 크게 나오는 경우가 있다. 60턴 한도에 걸린 실행은 61로 보고됐고, 한도에 걸리지 않고도 60을 넘겨 보고된 실행이 GLM에서 11회 있었다. 그래서 한도 도달 여부는 `num_turns`가 아니라 `subtype`이 `error_max_turns`인지로 판단했다.
[^2]: 캐시 읽기를 입력 단가의 10%로 잡으면 약 \$80, 할인 없이 정가로 계산하면 약 \$504다. Sonnet의 캐시 읽기 단가를 \$0.20으로 올려 잡아도 \$15.6이다.