AI 모델이 몰래 나빠졌는지 어떻게 알 수 있을까?

새 모델이 나오면 한두 달 뒤에 꼭 같은 글이 올라옵니다. "요즘 Opus가 멍청해졌다", "출시 때랑 다른 모델 같다." 9월 말 Hacker News 첫 페이지에는 아예 제목이 Livenerf: Has Opus 5.5 been nerfed yet?인 프로젝트가 올라와 300점을 넘겼습니다. 출시 일주일 된 모델이 벌써 약해졌는지 묻는 저장소입니다.

이 논쟁은 늘 같은 자리에서 끝납니다. 한쪽은 체감을 말하고, 다른 쪽은 벤치마크 점수가 떨어진 적이 없다고 답합니다. Livenerf의 README는 이것을 "vibes versus vibes"라고 부릅니다. 저는 이 논쟁에서 누가 맞는지보다, 둘 다 틀린 방식으로 재고 있다는 점이 더 흥미롭습니다.

체감이 맞거나, 벤치마크가 맞는다는 오해

체감 쪽의 약점은 분명합니다. 출시 직후에는 쉬운 일부터 시켜 보고 감탄합니다. 익숙해지면 더 어려운 일을 맡기고, 모델이 원래 가진 한계에 부딪힙니다. HN 토론에서도 모델이 나빠진 것이 아니라 사용자가 모델의 복잡도 한계에 도달한 것이라는 지적이 여러 번 나왔습니다.

그렇다고 벤치마크 쪽이 이긴 것도 아닙니다. 2025년 9월 Anthropic이 낸 사후 분석이 반례입니다. 8월부터 9월 사이 서로 겹친 인프라 버그 세 개가 Claude의 응답 품질을 떨어뜨렸습니다. 짧은 요청이 100만 토큰용 서버로 잘못 라우팅되는 버그는 가장 심한 날 Sonnet 4 요청의 16%에 영향을 줬고, Claude Code 사용자의 약 30%가 한 번 이상 품질이 떨어진 응답을 받았습니다.

같은 글에서 Anthropic은 수요나 시간대나 서버 부하 때문에 모델 품질을 낮추는 일은 절대 없다고 밝혔습니다. 동시에 자신들의 평가가 사용자가 겪은 품질 저하를 잡아내지 못했다고 인정했습니다. 모델이 한 번의 실수에서 곧잘 회복했기 때문입니다. 의도적인 너프는 없었지만 품질 저하는 실제로 있었고, 벤치마크는 그것을 보지 못했습니다.

너프라는 말이 가리키는 여러 원인

Livenerf README는 사람들이 너프라고 부르는 것의 후보를 나열합니다. 양자화, 같은 이름 뒤의 더 작은 모델, 낮춰진 추론 노력(effort), 라우팅 변경. 그리고 아무 일도 없었는데 사람들이 잡음에서 패턴을 읽는 경우입니다. 여기에 Anthropic 사후 분석이 보여 준 인프라 버그를 더해야 합니다.

제가 보기에 사용자 입장에서는 이 원인들을 구분할 방법이 거의 없습니다. 사용자가 보는 것은 답이 나빠졌다는 결과뿐입니다. 원인을 가리려면 결과부터 믿을 만하게 재야 합니다.

출시 첫날의 기준선

Livenerf가 한 일은 단순합니다. Opus 5.5가 나온 2026년 9월 22일에 시계를 시작했습니다. 지금까지 이 논쟁이 끝나지 않은 이유를 README는 깨끗한 출시일 기준선이 아무에게도 없었기 때문이라고 설명합니다. 나중에 나빠졌다고 주장하려면 처음이 어땠는지 기록이 있어야 합니다.

문제 선정도 흥미롭습니다. GPQA Diamond, MMLU-Pro, 경시대회 수학, AIME 문제 2,336개를 각각 네 번씩 풀게 했더니 Opus 5.5는 첫 시도에 약 93%를 맞혔고, 97%의 문제는 항상 맞히거나 항상 틀렸습니다. 이런 문제는 모델이 조금 나빠져도 결과가 변하지 않으니 측정에 쓸모가 없습니다. 가끔만 맞히는 78문제만 골라 측정판(panel)을 만들었습니다. 변화가 가장 먼저 드러나는 경계에 있는 문제들입니다.

모델만 빼고 전부 고정하기

모델의 무작위성은 끌 수 없습니다. 그래서 Livenerf는 나머지를 전부 고정합니다. 프롬프트를 얼리고, 채점을 정확 일치로 하고, 원시 로그를 영구히 남깁니다. 그리고 Claude Code CLI 버전을 고정합니다. README의 설명은 이렇습니다. Claude Code가 업데이트되면 하니스가 바뀌고, 바뀐 하니스는 바뀐 모델과 정확히 똑같아 보인다는 것입니다.

저는 이 문장이 이 프로젝트에서 가장 쓸모 있는 교훈이라고 봅니다. 우리가 "모델이 변했다"고 느끼는 순간의 상당수는 모델이 아니라 모델을 감싼 도구, 시스템 프롬프트, 설정이 변한 것일 수 있습니다. 모델을 재려면 그 바깥을 먼저 멈춰야 합니다.

정확도보다 먼저 움직이는 토큰 수

Livenerf는 정확도와 함께 답 하나에 쓰인 출력 토큰 수를 추적합니다. 검증 실험에서 추론 노력을 낮게 두면 출력 토큰이 62% 줄고 정확도는 8.3포인트(±4.5) 떨어졌습니다. 중간으로 두면 토큰이 26% 줄고 정확도는 4.2포인트(±3.9) 떨어졌습니다. 토큰의 변화가 정확도의 변화보다 훨씬 크고 분명합니다.

모델이 조용히 덜 생각하기 시작하면 정확도가 움직이기 전에 토큰 수에서 먼저 드러난다는 것이 README의 주장입니다. 이것은 개인이나 작은 팀도 따라 할 수 있는 신호입니다. 정답을 채점할 준비가 안 되어 있어도, 같은 요청에 대한 출력 토큰 수는 API 응답에 이미 들어 있습니다.

이 측정으로도 잡지 못하는 것

Livenerf는 한계를 숨기지 않습니다. 하루 한 번 측정판 전체를 돌리면 10일 구간마다 약 7.5포인트의 정확도 변화를 잡을 수 있습니다. 그보다 작은 변화는 잡음과 구분되지 않습니다. 검증에서 Opus 5.5 자리에 Opus 5를 넣었을 때도 99% 기준으로 구분하지 못했습니다. 같은 계열의 이전 모델로 바꿔치기하는 정도의 변화는 이 도구로는 보이지 않는다는 뜻입니다.

측정은 30일 동안 이어지고, 첫 판정은 10월 말에나 나옵니다. 그 결과가 너프가 있었다고 나올지 없었다고 나올지는 저도 모릅니다. 다만 결과가 어느 쪽이든 체감 대 체감으로 끝나던 논쟁에 처음으로 기록이 생깁니다.

우리 제품에 옮겨 올 세 가지 습관

모델을 제품에 쓰는 입장에서 가져올 것은 셋입니다. 첫째, 모델 ID를 별칭이 아니라 버전으로 고정합니다. 이것은 모델 출시 연표 글에서 적은 결론과 같습니다. 둘째, 우리 업무에서 가끔만 성공하는 요청 몇십 개를 골라 두고 정기적으로 돌립니다. 항상 성공하는 쉬운 예시는 아무것도 알려 주지 않습니다. 셋째, 같은 요청의 출력 토큰 수를 운영 지표로 봅니다.

그리고 바꾼 것은 기록합니다. 시스템 프롬프트를 고친 날, SDK를 올린 날, 설정을 바꾼 날을 남겨 두지 않으면 품질이 달라졌을 때 모델을 탓할지 우리를 탓할지 가릴 수 없습니다. 모델이 몰래 나빠졌는지 알고 싶다면, 우리 쪽에서 몰래 바뀐 것이 없다는 것부터 증명할 수 있어야 합니다.