‘최근의 Opus 5.5가 예전보다 약해지지 않았나.’ 지난 11월 9일, Hacker News에 ‘Is Opus 5.5 nerfed? Thinking patterns changed on November 3’라는 게시물이 올라왔고 800점을 넘었습니다.
스레드를 읽어보면, ‘약해졌다’는 것은 사람마다 의미가 다릅니다.
| 의미 | 스레드에서 언급된 내용 |
|---|
| ① 품질 저하 | 업무의 질이 떨어져 실수가 늘었다. 전에는 드물었던 반복적인 오류가 매번 여러 개 나온다 |
| ... | |
| 원인으로는 계산을 가볍게 했거나, 새로운 모델에 계산 자원을 할당했거나, 정액제 플랜 사용자만 테스트하고 있다는 등의 추측이 나오지만, 어느 것도 확실하게 확인된 바는 없습니다. 제가 본 범위 내에서는 Anthropic의 뉴스나 Claude Code의 변경 이력(2.1.314~2.1.322)에서도 Opus 5.5의 내부를 변경했다는 서술은 없었습니다. | |
저는 11월 2일, 즉 ‘11/3’ 전날에 Claude Code, Codex, Gemini CLI에 동일한 문장을 작성하도록 측정했습니다(AI가 작성한 PR 설명이나 README가 ‘AI 같다’고). 요청하는 문장도 출력물도, 그때 사용했던 Claude Code 버전도 그대로 남아 있습니다. 그래서 같은 요청을 같은 버전으로, 같은 시간대에 다시 시도해 보았습니다.
| 비교 항목 (Claude Code, 36회) | 11/2 |
|---|
| 핵심 내용 누락된 글 | 0 |
| ... | |
- ① 품질은 변하지 않았습니다. 핵심 내용을 놓친 부분도 규칙을 지키는 방식도 같았고, 작성 스타일 역시 같은 날에 3번 요청했을 때의 편차와 비슷할 정도였습니다.
- ③ 추정 비용은 36회 합계로 6% 증가했습니다($4.41→$4.66). 글자 수 증가만으로는 설명이 안 되며, 생각한 양이 늘었는지, 캐시 부분이 늘었는지는 알 수 없습니다.
- ② 사고방식은 11/2에 기록하지 않았기 때문에 비교할 수 없습니다. 오늘 분을 기록하여 다음 비교의 기준으로 삼았습니다.
- 대조군으로 측정한 Codex는 시간이 약 1.6배 길어졌습니다. 날짜별로 변하는 것은 Claude만은 아닙니다.
시도한 것은 ‘글쓰기’ 작업뿐입니다. 코드의 정확성이나 긴 작업은 측정하지 않았습니다.
측정은 2026-11-11에 진행되었으며, 11/2 측정과 비교했습니다.
| 동일하게 유지한 것 | 내용 |
|---|
| 도구 버전 | Claude Code 2.1.316, Codex 0.166.0, Gemini CLI 0.66.0 (11/2에 격리하여 넣었던 것을 그대로 사용) |
| ... | |
| 채점은 11/2의 자(物差し)를 그대로 사용했습니다. | |
- 핵심 내용은 README 절에서는 4가지입니다. 설정 이름(
RATES_MAX_RETRIES), 기본 횟수 3, 대기 시간 0.5초, 예외 이름(RatesUnavailable). PR 설명에서는 여기에 함수명과 테스트 언급을 추가한 6가지를 세었습니다. 11/2의 108건을 같은 자로 다시 세어보니 당시 결과와 전부 일치했습니다.
- 비교할 때는 동일 요청의 동일 회차를 한 쌍으로 묶었습니다. 차이가 우연의 범위인지 확인하기 위해, 쌍의 차이 부호 반전 검정(2만 회)을 진행했습니다.
Gemini CLI만은 새로 만든 폴더에서 실행했을 때 36회 모두 출력이 비어 있었습니다. 이유는 “Approval mode overridden to
| 도구 | 같은 날 3회 비교 (11/2) | 같은 날 3회 비교 (11/11) | 11/2와 11/11 조합 |
|---|
| Claude Code | 0.522 | 0.567 | 0.526 |
| ... | | | |
| 날짜를 넘나든 조합의 유사도는 같은 날 3회 요청했을 때의 변동성 정도와 같았습니다. 모델 작성 방식이 바뀌었다면, 날짜를 넘나든 조합만이 눈에 띄게 유사하지 않을 것입니다. | | | |
실물도 한 세트를 살펴보겠습니다. 동일한 요청(지시 파일 없음, 일본어 README 섹션)을 1회차로 진행했을 때의 유사도는 0.290이었습니다. 이 요청 그룹 중에서 가장 다른 조합입니다. 시작 부분을 나열하겠습니다.
## 설정
### `RATES_MAX_RETRIES`
환율 API(`https://rates.example.com/v1/latest`)에서 가져오는 데 실패했을 때, 몇 번까지 재시도할지 지정하는 환경 변수입니다.
...
이것이 11/2의 내용이고, 다음 것이 오늘(11/11)의 내용입니다.
## 환율 API 재시도 설정
`fetch_rates()`는 환율 API 연결에 실패하면 자동으로 재시도합니다. 재시도 횟수는 환경 변수 `RATES_MAX_RETRIES`로 변경할 수 있습니다.
| 환경 변수 | 기본값 | 설명 |
...
구성은 크게 다르지만, 설정 이름, 기본값, 의미는 양쪽 모두 일치하고 있습니다. 동일한 요청에 대한 같은 날 3회 비교의 유사도는 0.4130.608이었고, 날짜를 넘나든 9개 조합은 0.2900.640이었습니다. 가장 다른 조합에서도 핵심 내용은 빠지지 않았습니다.
36회의 총합은 11/2가 $4.41, 오늘(11/11)이 $4.66으로, 6% 증가했습니다. 동일한 요청 비교 그룹을 보아도 우연이라고 하기 어려운 차이입니다 (p=0.013). 추정 비용은 Claude Code가 토큰 수에 요금을 곱하여 산출하는 값입니다. 요금표는 Claude Code 내부에 포함되어 있어, 버전이 같으면 같습니다. 따라서 전체 토큰 수가 증가했거나 단가가 높은 종류의 토큰이 늘어난 경우입니다.
다만, 어느 부분에서 증가했는지는 알 수 없습니다. 오늘 1회차의 중앙값은 대략 다음과 같은 내역으로 구성되었습니다.
| 내역 (오늘 1회차 중앙값) | 토큰 | 비용 추정치 |
|---|
| 1시간 캐시 쓰기 | 11,197 | 약 $0.09 |
| ... | | |
| 출력이 전체의 2할 정도이므로, 글자 수가 6% 증가한 것만으로는 비용이 1%밖에 늘지 않습니다. 나머지 이유로는 두 가지를 생각해 볼 수 있습니다. | | |
- 생각하는 양(Thinking)이 늘어났다. 생각하는 양은 출력 토큰에 포함되어 요금이 부과됩니다 (오늘의 36회는, 출력 토큰만으로 다시 계산해도 추정 비용과 완전히 일치하며, 생각하는 양은 출력의 약 2할 정도였습니다). 생각하는 양이 늘어나도 글자 수에는 반영되지 않습니다.
- 캐시 쓰기나 읽기가 증가했다.
어느 쪽인지 여부는 11/2에 토큰 수를 기록하지 않았기 때문에 구분할 수 없습니다.
또 한 가지, 버전을 같게 해도 변동의 여지가 있습니다. Claude Code는 서버에서 설정(feature flag)을 가져와 작동 방식을 변경합니다. 이 설정을 중단하는 환경 변수는 2.1.319에 도입되었으며, 이번 2.1.316에서는 막을 수 없습니다.
11/2에는 생각하는 양도 내용도 기록하지 않았습니다. 오늘분만 다음 비교 기준 자료로 남겼습니다. 1회차 중앙값에서 생각하는 양(thinking 토큰)은 279.5, 출력은 1,326 토큰입니다.
③의 비용 증가가 생각하는 양이 늘어난 탓이었다면, ②의 '사고 방식이 바뀌었다'는 것과 연결됩니다. 다음에 동일한 요청을 흘려보낼 때, 이 수치와 비교하면 알 수 있습니다.
| 도구 (각 36회) | 글자 수 (중앙값) | 소요 시간 (중앙값) | 핵심 내용이 빠진 책 |
|---|---|---|
| Codex | 267 → 251자 | 6 → 9.5초 |
12 → 15 |
| Gemini CLI | 440 → 405자 | 43 → 51초 | 6 → 5 |
Codex는 시간이 약 1.6배로 늘어났으며, 우연이라고 하기 어려운 차이였습니다 (p<0.001). 핵심 내용이 빠진 책도 3권 증가했습니다. 빠진 핵심 내용을 세어보니 다음과 같이 변경되었습니다 (한 권에 여러 개가 빠질 수 있습니다).
| Codex에서 빠진 요점 | 11/2 | 11/11 |
|---|
| 기본 횟수 3 | 7 | 11 |
| ... | | |
| Codex는 원래 짧게 쓰는 도구이며, 11/2일에도 글자 수의 중앙은 300자에 미치지 못합니다. 오늘은 설정 이름까지 빠진 논문이 나왔습니다. Gemini CLI는 모두 우연의 범위였습니다. | | |
날짜가 다르면 어떤 도구든 어느 정도는 변합니다. Claude 비용의 6% 증가 역시 그 '날짜에 따른 차이'인지, 모델 측의 변화인지는 이 이틀만으로는 구분할 수 없습니다.
LiveNerf는 Max 플랜으로 버전을 고정한 Claude Code(2.1.280)를 사용하여 어려운 문제 78문항을 매일 풀게 하고 Opus 5.5의 정답률을 추적하고 있습니다. 11/10자점의 결론은 '변화 없음'입니다.
다만, 판정이 완료된 구간은 11/2일까지입니다. 11/3~11/12 구간은 아직 집계 중입니다. 구별할 수 있는 변화는 약 7포인트 이상일 때입니다.
'약해졌다'고 느낀다면, 동일한 요청을 동일 버전으로 돌려 숫자로 남겨두는 것이 가장 확실합니다. claude -p
에 --output-format json
를 붙이면 결과에 토큰 수와 추정 비용이 들어갑니다.
claude -p "(항상 요청하는 작업)" --output-format json > "run-$(date +%Y%m%d-%H%M).json"
확인해야 할 것은 total_cost_usd와, modelUsage 내부의 outputTokens・thinkingTokens・cacheCreationInputTokens・cacheReadInputTokens입니다. 이번 11/2일처럼 토큰 수를 남기는 것을 잊으면 나중에 비교할 수 없습니다.
비교할 때는 다음 세 가지를 맞추어야 합니다.
- Claude Code의 버전 (
DISABLE_UPDATES=1로 자동 업데이트를 포함한 모든 업데이트를 중지)
- 요청 문구와 제공하는 파일
- 시간대 (혼잡도에 따라 속도가 변함)
시도해 본 것은 PR 설명과 README 작성 작업뿐입니다. 코드의 정확성이나 긴 작업을 통해 약해졌는지는 알 수 없습니다.
- 각 조건 12회, 이틀간의 비교입니다.
- 추정 비용이 6% 증가한 원인은 알 수 없습니다. 버전이 같더라도 서버에서 가져오는 설정에 따라 움직임이 바뀔 여지가 있습니다.
- 사고방식(②)은 전후를 비교하지 않았습니다.
11/2일과 동일한 요청을, 동일한 Claude Code 2.1.316으로 같은 시간대에 다시 실행했을 때, Opus 5.5가 작성하는 글의 품질은 변해있지 않았습니다. 요점 누락도, 규칙 준수 방식도, 문체 편차도 같습니다.
반면, 추정 비용은 6% 증가했습니다. 하지만 6%는 '간단한 수정만으로 상한에 도달할' 정도의 차이는 아닙니다. 대조군인 Codex 역시 느려져서, 날짜에 따른 차이와 구분하기 위해서는 더 길게 측정해야 합니다. 저는 오늘 숫자를 기준으로 동일한 요청을 계속 돌려보겠습니다.
- AI가 작성한 PR 설명이나 README는 'AI 같은'가? 3가지 도구의 108건을 Wikipedia 분류법으로 센 — 이번에 다시 진행한, 11/2일 측정
- Claude Code를 새로운 Fable 5.2로 전환하면 빨라지고 저렴해질까. 36회 측정 결과, Fable 5.1보다 2할 빠르고 3할 저렴했으며, 비용은 Opus 5.5의 1.6배였다 — 같은 주에 나온 Fable 5.2를 Opus 5.5와 비교한 기사
- Claude Opus 5.5의 '40% 저렴'은 캐시 적중 여부에 따라 24%가 되기도 하고 59%가 되기도 했다 — Opus 5.5 공개 직후 측정 비용
JQIT 엔지니어의 95% 이상은 미경험자 채용입니다.
괜찮으시면 기업 사이트에도 놀러 오세요.
엔지니어 채용도 진행하고 있습니다. 관심 있으시면 한번 둘러보세요.
▶ 채용 사이트
