Opus 5.5가 나빠졌다는 느낌, ±10% 안에서 먼저 재 봅니다 — NerfBench처럼 오늘 기준 과제 세트를 고정합니다 | DAKER 커뮤니티

새 모델을 쓰다 보면 "요즘 좀 나빠진 것 같다"는 말이 꼭 나옵니다. BridgeMind 채널의 영상 Is Claude Opus 5.5 Nerfed? I Built NerfBench to Find Out.은 이 느낌을 숫자로 확인하려고 만든 벤치마크 NerfBench를 소개합니다. 결론부터 말하면 Opus 5.5는 첫 주 동안 출시일 기준 대비 94.2%에서 103.8% 사이를 오갔고, 영상 제작자는 이를 성능 저하가 아니라 정상 변동으로 판단했습니다. 대회에서 모델을 바꾸거나 같은 모델로 제출을 반복하는 참가자라면, 이 방식을 그대로 빌려 자기만의 기준 과제 세트를 오늘 고정해 둘 만합니다.

개발자가 모니터 속 100% 기준선 주변 변동 범위 안에서 흔들리는 성능 그래프를 보는 만화풍 생성 이미지와 제목 모델이 나빠졌다는 느낌, 같은 문제 세 번으로 확인합니다
설명용 생성 이미지입니다.

NerfBench는 출시일 점수를 100%로 놓고 변화만 봅니다

NerfBench는 한 번 실행할 때 50개 과제를 과제마다 세 번씩, 모두 150회 시도합니다. 과제는 버그 수정, 코드 추론, 보안 등 8개 범주에 걸쳐 있습니다. 영상 설명란은 이 구성을 "50 tasks, three attempts each, across eight categories"라고 정리합니다.

점수를 매기는 방식이 일반 벤치마크와 다릅니다. 모델이 처음 나왔을 때 돌린 결과를 100% 기준점으로 삼고, 이후 실행은 그 기준과 비교한 비율로 표시합니다. 이 비율을 영상에서는 power라고 부르며, 과제 성능과 사용한 토큰 수, 실행 전체 비용 세 가지로 계산합니다. 같은 과제를 똑같이 통과해도 토큰을 더 쓰면 점수가 내려가고, 덜 쓰면 올라갑니다.

몇 문제를 맞혔는지보다 출시일의 자기 자신과 비교해 어떻게 달라졌는지가 핵심입니다.

Opus 5.5 첫 주 결과는 모두 ±10% 안에 있었습니다

영상에서 공개한 Claude Opus 5.5의 첫 주 기록은 다음과 같습니다. 제작자는 일주일 동안 모델 4개를 대상으로 모두 12회를 실행했다고 밝혔고, 앞으로 모델마다 주 3회 실행할 계획이라고 말합니다.

실행 시점출시일 대비 점수비고
출시일100%기준점
9월 27일99.2%기준 대비 -0.8%
10월 1일103.8%기준보다 높음
10월 2일94.2%150회 중 114회 통과, "나빠졌다"는 반응이 많던 날
영상 속 라이브 실행96.5%150회 중 117회 통과

10월 1일과 10월 2일 사이에는 9.6%포인트의 차이가 있었습니다. 제작자는 이 정도면 작지 않은 흔들림이지만, 위아래 10% 안쪽은 정상 변동으로 보고 그 밖으로 벗어날 때만 성능이 떨어졌거나 좋아졌다고 분류한다고 설명합니다. 그 기준으로 보면 첫 주에는 성능 저하가 한 번도 확인되지 않았습니다.

위아래 10% 안쪽의 흔들림은 모델 변동으로 보고, 그 바깥만 성능 변화로 판단합니다.

같은 과제도 실행할 때마다 결과가 바뀝니다

NerfBench 화면은 과제별로 세 번의 시도 결과를 격자로 보여 줍니다. 영상 속 예시를 보면 난이도 10점 만점인 43번 과제는 10월 2일 실행에서 세 번 모두 실패했지만, 출시일 실행에서는 세 번 중 한 번 통과했습니다. 42번 과제는 출시일에는 세 번 모두 통과했고, 10월 2일에는 두 번 통과하고 한 번 실패했습니다.

라이브 실행에서도 같은 모습이 나옵니다. 1번 과제는 첫 시도에서 실패하고 나머지 두 번은 성공했고, 48번 과제는 세 번 모두 실패했습니다. 150개 시도는 동시에 돌아가며, 결과가 들어오는 대로 격자가 채워집니다. 한 번만 돌린 결과로 모델을 평가하면 이런 우연한 성공과 실패가 그대로 결론이 되기 쉽습니다. 과제마다 세 번씩 시도하는 이유가 여기에 있습니다.

제작자는 과제가 어떤 식으로 채점되는지 보여 주려고 41번 과제를 공개했습니다. 결제 원장(payment ledger)을 복구하는 과제이며, 요구 사항과 기대 출력, 통과와 실패를 가르는 기준을 BridgeBench 사이트의 글에서 볼 수 있다고 안내합니다.

API로 잰 점수와 구독 도구로 쓴 체감은 다를 수 있습니다

지금까지 NerfBench는 OpenRouter를 거쳐 high effort 설정으로 모델을 호출했습니다. 그런데 사람들이 실제로 궁금해하는 것은 매일 쓰는 Claude Code나 Codex 구독 환경에서의 성능이라는 요청이 많았다고 합니다. 그래서 영상 후반부에는 Claude Code 구독과 Codex 구독을 연결해 같은 과제를 그 하네스로 돌리는 새 기능을 보여 줍니다. 같은 Opus 5.5라도 OpenRouter로 호출한 실행과 Claude Code에서 돌린 실행을 별도 항목으로 기록합니다.

대회 참가자에게 이 구분은 꽤 실용적입니다. API로 잰 리더보드 점수와 에디터나 CLI 에이전트 안에서 느끼는 품질은 호출 경로, 추론 설정, 하네스가 다르기 때문에 서로 다를 수 있습니다. 비교하려면 경로를 하나로 고정하거나, 경로별로 따로 기록해야 합니다.

DAKER 해커톤 참가자가 오늘 고정해 둘 기준 세트

NerfBench의 규모를 그대로 따라 할 필요는 없습니다. 핵심은 같은 문제를 같은 조건으로 여러 번 돌리고, 처음 기록한 값과 비교하는 습관입니다. 해커톤이나 경진대회에서 모델을 바꾸거나 프롬프트를 고칠 때 다음 순서로 작은 기준 세트를 만들어 두면 "느낌"을 숫자로 바꿀 수 있습니다.

  1. 지금 작업에서 실제로 자주 맡기는 과제를 골라 입력과 기대 출력을 파일로 고정합니다. 버그 수정, 데이터 전처리 코드, 제출 파일 형식 검사처럼 통과 여부를 기계적으로 판단할 수 있는 것이 좋습니다.
  2. 오늘 쓰는 모델과 설정으로 과제마다 세 번씩 돌리고, 통과 수와 토큰 사용량을 함께 남깁니다. 이 값을 자기 기준점 100%로 둡니다.
  3. 모델을 바꾸거나 "요즘 이상하다"는 느낌이 들 때 같은 세트를 같은 경로로 다시 돌립니다. API 호출과 에이전트 도구 사용은 따로 기록합니다.
  4. 차이가 미리 정한 변동 범위 안이면 모델 탓을 하기 전에 프롬프트, 데이터, 코드 변경부터 확인합니다.

변동 범위를 꼭 10%로 잡을 필요는 없습니다. 10%는 NerfBench 제작자가 정한 값이며, 과제 수가 적을수록 실행마다 흔들림이 커질 수 있으니 처음 몇 번의 반복 결과를 보고 자기 범위를 정하는 편이 현실적입니다.

아직 일주일 된 실험이라는 점도 함께 봐야 합니다

영상에서 제작자는 NerfBench가 공개된 지 7일밖에 되지 않았고 앞으로 계속 다듬겠다고 말합니다. 스스로도 이것을 일종의 실험이라고 부르며, 지금까지는 성능 저하가 실제로 일어난 사례를 보지 못했다고 밝힙니다. 과제 세트와 변동 범위, power 계산 방식은 모두 제작자가 정한 것이므로, 이 결과를 특정 모델의 공식 성능 평가로 받아들이기보다는 반복 측정의 방법론으로 참고하는 편이 맞습니다.

그래도 "모델이 나빠졌다"는 말이 나올 때마다 같은 과제를 다시 돌려 보는 장치가 있다는 것 자체가 의미 있습니다. 대회 기간처럼 모델과 프롬프트를 자주 바꾸는 시기일수록 출시일 기준점 같은 자기 기준선이 판단을 지켜 줍니다.

여러분은 모델이 나빠졌다고 느낄 때 무엇으로 확인하십니까? 직접 쓰는 기준 과제나 반복 측정 방법이 있다면 댓글로 공유해 주십시오.

출처