Opus 5.5는 너프됐는가 — 체감을 측정으로 바꾸려는 livenerf의 설계
Opus 5.5는 너프됐는가 — 체감을 측정으로 바꾸려는 livenerf의 설계
호스팅 모델이 「출시 후 조용히 나빠진다」는 의심은 음모의 문제인가, 아니면 고객 쪽에 관측 수단이 없다는 문제인가?
도입
2026년 9월 29일(UTC) 해커뉴스에 「Livenerf: Has Opus 5.5 been nerfed yet?」라는 글이 올라와 926점을 받았다. 링크된 것은 GitHub 저장소 ninjahawk/livenerf다. 저장소 설명은 한 줄이다. 출시 후 모델 능력을 추적하는 벤치마크. README는 자신을 「작고, 지루하고, 추가만 가능한(append-only) 벤치마크」라고 부르며, 단 하나의 질문에 답하려 한다고 적는다. 모델은 출시된 뒤에 나빠지는가.
배경은 익숙하다. 새 모델이 나오면 처음 며칠은 「아인슈타인과 일하는 것 같다」는 감탄이 쏟아지고, 한두 주 뒤에는 「요즘 멍청해졌다」는 글이 올라온다. 일주일 전인 9월 21일에도 「Fable 5 – Median thinking declined in August」라는 글이 428점을 받으며 같은 논쟁을 일으켰다. README의 문제 제기는 이 반복을 정확히 겨눈다. 저하가 양자화일 수도, 같은 이름 뒤의 더 작은 모델일 수도, 추론 노력(effort)의 축소나 라우팅 변경일 수도 있다. 혹은 아무 일도 없었고 사람들이 잡음에서 패턴을 찾고 있을 수도 있다. 그런데 아무도 깨끗한 「0일차 기준선」을 갖고 있지 않았기 때문에, 모든 논쟁은 「느낌 대 느낌」으로 끝난다는 것이다.
Claude Opus 5.5는 2026년 9월 22일에 나왔다. livenerf는 그날 시계를 켜고 30일 동안 매일 같은 문제 세트를 돌리겠다고 선언했다. 이 글은 livenerf가 무엇을 재는지보다, 왜 그렇게 재야 하는지에 주목한다. 호스팅 모델의 드리프트는 결국 관측 가능성(observability)의 문제이고, livenerf의 설계 선택 하나하나가 그 문제의 어려움을 보여 주기 때문이다.
현상 분석: livenerf는 무엇을, 어떻게 재는가
먼저 사실 관계를 정리한다. 아래는 9월 29일 시점 README와, 같은 방법론을 유지하는 이후 판에서 확인한 내용이다.
측정 대상은 「API의 Opus 5.5」가 아니다. v0은 API 키 없이 Claude Max 구독으로 headless Claude Code(claude -p)를 호출한다. README는 이 점을 굵게 강조한다. livenerf가 재는 것은 구독을 통해 Claude Code로 서빙되는 Opus 5.5이며, 그것이 대부분의 너프 보고가 실제로 가리키는 대상이고, 원시 API 모델과 같지 않다는 것이다. 프레임워크는 영국 AI Security Institute의 오픈소스 평가 도구 Inspect이고, 통계는 Anthropic의 Evan Miller가 쓴 「Adding Error Bars to Evals」를 따른다. README의 표현으로는 「자가 제작한 것이 없으니 논쟁할 거리도 없다」.
일정은 이렇다. 1일차는 출시 약 2.5일 뒤인 9월 24일 22:10 UTC였다. 하루 한 번, 30일 동안 돈다. 1~10일차가 기준선이고, 그 뒤로 10일짜리 창이 두 개 이어진다. 따라서 「변했다」고 판정할 수 있는 가장 이른 시점은 10월 24일 전후다. 9월 29일 README의 진행 기록은 30일 중 6일 수집, 누락 없음, 6일 모두 동일한 하네스 해시와 고정된 CLI 2.1.280에서 90샘플 전량 실행이었다.
가장 흥미로운 것은 문제 세트(패널)를 고르는 방식이다. GPQA Diamond, MMLU-Pro, 경시 수학, AIME 2025–26에서 2,336문항을 골라 문항마다 4번씩 풀게 했다. Opus 5.5는 첫 시도에서 약 93%를 맞혔고, 97%의 문항은 「항상 맞히거나 항상 틀렸다」. 남은 78문항, 즉 「가끔 맞히는」 문항만이 패널이 된다. 이유는 정보량이다. 항상 맞히는 문항은 하락을 보여 줄 수 없고, 돌리는 만큼 토큰만 낭비한다. README는 통과율 p인 문항이 샘플당 p(1−p)의 정보를 갖는다는 로짓 이동 모델을 근거로 든다.
여기서 저자는 자기 선택 편향까지 측정했다. 「가끔 맞힌다」는 이유로 뽑힌 문항은 실제보다 50대 50에 가까워 보인다. 새로 샘플링하자 이 문항들의 통과율은 54.7%에서 62.0%로 올라갔고, 검정력 계산에는 새 값을 썼다. 그 결과 하루 한 번 전체 패널을 돌리면 10일 창마다 약 7.5포인트의 정확도 변화를 검출할 수 있으며, 비용은 주간 플랜의 약 3.6%라고 한다.
다음은 검증이다. README는 「알려진 저하를 볼 수 있음을 증명하기 전에는 어떤 무변화 결과도 믿지 않는다」고 적는다. 일종의 양성 대조다. effort를 high에서 low로 낮추자 출력 토큰은 62% 줄고 정확도는 8.3±4.5포인트 떨어졌다. medium으로 낮추자 토큰 26% 감소, 정확도 4.2±3.9포인트 하락이었다. 동시에 한계도 그대로 적었다. Opus 5.5 자리에 Opus 5를 넣었을 때는 99% 수준에서 구별되지 않았다(−3.8±6.3포인트, 토큰 −23%). 같은 계열 모델로의 이 정도 교체는 검증 분량의 샘플로는 잡지 못한다는 고백이다.
판정 규칙은 사전 등록(pre-registration)되어 있다. 변화로 부르려면 99% 구간이 연속 두 개의 10일 창에서 0을 배제하고, 효과가 3포인트 이상이며, 대조군이 같은 방향으로 움직이지 않아야 한다. 대조군은 claude-opus-5로, 같은 하네스에서 패널의 GPQA 문항을 매일 함께 돈다. 둘이 같이 움직이면 바뀐 것은 Opus 5.5가 아니라 하네스나 플랫폼이라는 논리다. 채점은 완전 일치만 쓰고 LLM 심사자는 절대 쓰지 않는다. 심사자도 드리프트하기 때문이다. 개선도 하락과 같은 크기로 보고하고, 무변화 결과도 공개한다고 약속한다.
심층 분석: 왜 이렇게까지 해야 하는가
livenerf의 설계를 하나씩 뜯어보면, 각 선택이 「제3자가 호스팅 모델의 회귀를 감시할 때 무엇이 어려운가」에 대한 답이라는 것이 보인다.
첫째, 비결정성. README는 Opus 5.5에서 같은 답을 두 번 얻을 수 없다고 못박는다. 샘플링 파라미터는 사라졌고 thinking도 끌 수 없다. 그래서 모델을 결정적으로 만드는 대신 나머지 전부를 결정적으로 만든다. 프롬프트 동결, CLI 고정, 정확한 채점기, 원시 로그 영구 보존. 9월 21일 Fable 5 스레드에서 한 이용자가 「같은 프롬프트를 보낼 때마다 다른 답이 오는 시스템에서 반복 가능한 테스트를 어떻게 만드느냐」고 물었는데(직접 인용은 아니고, 코멘트의 요지를 요약), livenerf의 답은 「단일 출력이 아니라 분포를 재고, 그 분포가 움직이는지 본다」이다. 이번 스레드에서 LeoPanthera가 남긴 「n=1은 쓸모없다, 출력은 결정적이지 않다」는 짧은 코멘트(직접 인용은 아니고, 코멘트의 요지를 요약)가 체감 보고 전반에 대한 가장 간결한 반론이었다.
둘째, 하네스 드리프트. README는 CLI 고정을 「선택 사항이 아니다」라고 쓴다. Claude Code 업데이트는 하네스를 바꾸고, 바뀐 하네스는 바뀐 모델과 똑같아 보이기 때문이다. 이 경고는 추상적인 것이 아니다. Anthropic이 2026년 4월 23일 공개한 사후 분석은 Claude Code 품질 저하 보고를 세 가지 변경으로 추적했다. 3월 4일 기본 추론 노력을 high에서 medium으로 낮춘 결정(4월 7일 원복), 3월 26일 유휴 세션의 오래된 thinking을 지우는 최적화에 버그가 있어 매 턴마다 지워 버린 문제(4월 10일 수정), 4월 16일 장황함을 줄이려 넣은 시스템 프롬프트 지시가 코딩 품질을 해친 문제(4월 20일 원복)다. 같은 글은 API는 영향을 받지 않았다고 밝힌다. 다시 말해 「모델」은 그대로였는데 사용자가 겪는 품질은 분명히 떨어졌다. livenerf가 하네스 해시와 CLI 버전을 매 실행에 기록하고 hermetic 호출(도구, MCP, 설정, 훅, CLAUDE.md, 메모리 없이 한 턴)을 고집하는 이유가 여기 있다.
셋째, 측정 지표 자체의 선택. README가 정확도 다음으로 가장 신경 쓴다고 밝힌 2차 신호는 샘플당 출력 토큰 수다. 모델이 조용히 덜 생각하기 시작하면 정확도보다 먼저 토큰에서 드러난다는 것이다. 검증 결과가 이를 뒷받침한다. effort medium은 정확도를 4.2포인트 낮췄지만 그 오차 막대는 3.9포인트였고, 토큰은 26%나 줄었다. 정확도로는 겨우 보이는 변화가 토큰으로는 선명하다. Fable 5 스레드의 제목이 「중앙값 thinking 감소」였다는 점, 그리고 거기서 「thinking 토큰은 클라이언트에 돌려주지 않는데 어떻게 재느냐」는 질문(직접 인용은 아니고, 코멘트의 요지를 요약, CamperBob2)이 나왔다는 점을 함께 놓으면, 무엇을 볼 수 있느냐가 곧 무엇을 감시할 수 있느냐를 정한다는 것이 드러난다. 다만 해당 트윗 원문은 이번에 확인하지 못했으므로 그 수치는 여기서 다루지 않는다.
넷째, 서빙 경로의 잡음. README에 따르면 안전 분류기가 때때로 Opus 5로 답하거나 생물학과 일부 수학 문항을 거부한다. 이런 샘플은 기각하고 집계하며, 영향을 받은 문항은 제외한다. 「Opus 5.5에게 물었는데 답한 것은 다른 모델」인 경우가 실제로 존재한다는 것, 그리고 그것이 측정기에서 보인다는 것은 사용자 체감 논쟁에서 자주 빠지는 요소다.
해커뉴스의 반응은 크게 세 갈래였다. 첫째는 「너프는 없다」 진영이다. solenoid0937은 모델이 너프되는 것이 아니라 사람들이 새로운 지능 수준에 익숙해지는 것이라는 「핫테이크」를 남겼고(직접 인용은 아니고, 코멘트의 요지를 요약), johnfn은 새 모델마다 감당할 수 있는 복잡도의 천장이 있어 출시 직후엔 뭐든 되는 것 같다가 며칠 뒤 그 천장에 부딪힌다는 설명을 내놓았다(직접 인용은 아니고, 코멘트의 요지를 요약). 자기 스택을 GPU부터 채팅 UI까지 직접 운영하며 아무것도 바꾸지 않았는데도 「너프됐다」는 불만을 받았다는 nsarrazin의 경험담(직접 인용은 아니고, 코멘트의 요지를 요약)은 이 진영의 가장 강한 증거였다. semiquaver는 자기 회사가 Azure와 AWS Bedrock으로만 Claude를 쓰는데, 너프 벤치들이 왜 다른 추론 제공자를 비교점으로 쓰지 않느냐고 물었다(직접 인용은 아니고, 코멘트의 요지를 요약).
둘째는 「너프는 있다」 진영이다. 이들의 근거는 대부분 개인 경험이었고, 일부는 Anthropic이 과거에 하네스 버그를 인정했다는 사실을 들었다. gobdovan은 실제 회귀 사례가 있지만 그것은 너프라기보다 「사고(incident)」로 부르는 것이 정확하다며 앞서 언급한 4월 23일 사후 분석을 링크했다(직접 인용은 아니고, 코멘트의 요지를 요약). HawtAds는 상위 제공자를 가까이 추적하는데, GPU 런타임 계층의 버그나 업데이트 하나로 출력이 깨질 수 있고 가중치가 바뀌거나 양자화될 필요는 없다고 적었다(직접 인용은 아니고, 코멘트의 요지를 요약).
셋째가 방법론 비판이다. zeroonetwothree는 README 스스로 Opus 5와 5.5를 구별하지 못한다고 했다면 쓸모가 없다고 지적했다(직접 인용은 아니고, 코멘트의 요지를 요약). 10일 창이 너무 길다는 질문에는 ninjahawk1 계정이 답했다. 창 길이는 민감도와 검출 속도의 절충이고, 짧으면 잡음이 크고 길면 몇 주가 걸리며, 창은 매일 굴러가고 두 창 연속으로 사전 등록된 99% 기준을 넘어야 판정한다는 것, 그리고 10일이 신성한 숫자는 아니어서 데이터가 쌓이면 재검토하겠다는 것이었다(직접 인용은 아니고, 코멘트의 요지를 요약). 공격적인 비판도 있었다. octoberfranklin과 quikoa는 고정 간격으로 같은 요청이 오면 제공자가 쉽게 감지해 그 요청만 너프하지 않을 수 있다고 했고, nullbio는 캐시가 측정을 오염시킬 가능성을 제기했다(모두 직접 인용은 아니고, 코멘트의 요지를 요약). 패널 문항을 비공개로 두고 해시만 공개하는 livenerf의 방침은 첫 번째 우려를 일부 덜지만, 매일 같은 시간대에 같은 문항을 보낸다는 패턴 자체를 숨기지는 못한다.
전망과 시사점: 고객이 관측 수단을 갖는다는 것
livenerf가 결국 보여 주는 것은 「너프가 있느냐 없느냐」의 답이 아니라, 그 질문에 답하는 데 드는 비용이다. 2,336문항을 걸러 78문항을 남기고, 하네스를 얼리고, 양성 대조와 대조군을 두고, 판정 규칙을 미리 공개 커밋하고, 30일을 기다린다. 그래도 같은 계열 모델 교체는 잡지 못할 수 있다고 스스로 적는다. 개인 개발자가 「오늘 좀 멍청한데」라고 느끼는 것과 이것 사이에는 엄청난 간극이 있다.
이 간극은 신뢰의 비대칭을 그대로 보여 준다. 제공자 쪽은 공식 입장을 반복해 왔다. Anthropic은 2025년 9월 17일 사후 분석에서 「수요, 시간대, 서버 부하 때문에 모델 품질을 낮추는 일은 절대 없다」고 썼고, 2026년 4월 글에서도 「모델을 의도적으로 저하시키지 않는다」고 밝혔다. 동시에 같은 두 글은 실제로 품질이 떨어진 사례를 상세히 공개했다. 2025년 8~9월의 세 가지 인프라 버그 가운데 컨텍스트 창 라우팅 오류는 처음에 Sonnet 4 요청의 0.8%에 영향을 줬지만 8월 29일의 부하 분산 변경으로 확대돼, 최악의 시간대인 8월 31일에는 16%에 달했고, 해당 기간 요청한 Claude Code 사용자의 약 30%가 최소 한 번 잘못된 서버로 라우팅됐다. 두 글 모두 초기 보고가 「사용자 피드백의 정상 변동과 구별하기 어려웠다」고 적는다. 제공자 내부에서도 신호와 잡음을 가르기 어려웠다는 뜻이다.
그렇다면 의도 여부와 무관하게, 고객은 「품질이 변했는가」를 독립적으로 확인할 수단을 필요로 한다. 서버 운영에서 응답 시간과 오류율을 고객이 직접 측정하듯, 모델의 출력 품질도 고객 쪽 관측 대상이 되어야 한다는 것이다. livenerf의 README가 「너프」라는 말 대신 「드리프트」와 「변화」라는 말을 쓰고, 출시 주간이 오히려 최악의 주간일 수 있다며 양방향 검정을 고집하는 것은 이 관점과 맞닿아 있다. 원인을 가정하지 않고 변화만 잰다. 원인은 그 다음 문제다.
다만 몇 가지 한계는 남는다. 첫째, livenerf가 재는 것은 지식 문제의 정확도다. 사용자 불만의 상당수는 장기 코딩 세션, 권한 요청 빈도, 사용량 소진 속도에 관한 것이었다. 스레드에서도 quota 미터가 같은 작업에 다르게 깎인다는 관찰(user3939382), 코드베이스가 커지면서 같은 모델이 더 많은 토큰을 읽게 되는 것을 너프로 오인한다는 지적(throwitaway222), 할당량이 끝나 갈 때 더 나쁜 모델이 오느냐가 진짜 질문이라는 물음(saejox)이 나왔다(모두 직접 인용은 아니고, 코멘트의 요지를 요약). 이것들은 livenerf 패널 밖에 있다. 둘째, 단일 계정, 단일 하네스, 단일 시간대의 측정이다. 계정 단위나 부하 시간대 단위의 차별이 있다면 이 설계로는 보이지 않는다. 셋째, 출시 후 약 2.5일 뒤에 시작했으므로 「진짜 0일차」는 아니다. codr1은 기준선이 출시 후 3~5일이어야 한다고 했는데(직접 인용은 아니고, 코멘트의 요지를 요약), livenerf의 기준선은 그보다 넓은 10일이다.
그럼에도 이 프로젝트가 남기는 형식은 재사용 가능하다. 「가끔 맞히는 문항만 고른다」, 「정확도와 함께 토큰을 본다」, 「하네스를 고정하고 해시를 남긴다」, 「같은 하네스에 대조 모델을 함께 돌린다」, 「판정 규칙을 데이터보다 먼저 커밋한다」. 회사가 자사 제품에 LLM을 넣고 있다면, 이 다섯 줄은 공급자 계약서의 SLA 조항보다 실질적인 보호 장치가 될 수 있다.
(10월 17일 추기: README의 10월 17일 진행 기록에 따르면 30일 중 25일이 수집됐고, 110일차 기준선은 780샘플에 0.584±0.036, 1120일차 첫 창은 780샘플에 0.592±0.037로 기준선 대비 +0.007±0.018, 대조군 +0.035±0.049, 판정은 「변화 없음」이었다. 출력 토큰 중앙값은 588에서 606이었다. 기준선에서 실현된 최소 검출 효과는 창당 6.6포인트로 예측치 7.5보다 작았다. 19일차는 Max 주간 미터가 소진돼 API 크레딧으로 돌렸다고 기록되어 있다.)
결론
「Has Opus 5.5 been nerfed yet?」이라는 질문에 9월 30일 시점의 정직한 답은 「아직 판정할 수 없다」다. livenerf 스스로 첫 판정 가능 시점을 10월 24일 전후로 잡았기 때문이다. 그러나 이 저장소가 926점을 받은 이유는 답이 아니라 질문의 형식을 바꿨기 때문일 것이다. 「느낌 대 느낌」의 논쟁을 「사전 등록된 규칙 대 데이터」의 문제로 옮겼다.
그 과정에서 드러난 것은 너프 논쟁의 양쪽 모두가 불완전한 정보 위에 서 있다는 사실이다. 사용자는 n=1의 체감으로 저하를 주장하고, 제공자는 「의도적으로 낮추지 않는다」고 말하면서도 하네스 변경과 인프라 버그로 품질이 떨어진 사례를 사후에야 공개해 왔다. 의도가 없었다는 말은 결과가 없었다는 말이 아니다.
README에는 이 저장소의 상당 부분이 측정 대상인 Claude의 도움으로 작성됐다는 고백이 있다. 그래서 채점기는 순수 함수이고, 임계값은 사전 등록되어 있으며, 원시 데이터는 공개된다고 한다. 「작성자를 믿을 필요가 없어야 한다, 인간이든 아니든」. 호스팅 모델과 그 고객 사이의 관계에 그대로 적용해도 좋은 문장이다. 당신의 팀은 지금 쓰고 있는 모델이 지난달과 같은 모델인지 확인할 수단을 갖고 있는가.
출처: