'어제는 됐는데 오늘은 왜 이래?'
AI 코딩 도구를 매일 쓰다 보면 한 번쯤 이런 경험 해보셨을 거예요. 지난주엔 한 번에 깔끔하게 짜주던 코드를 오늘은 엉뚱하게 짜거나, 분명 잘 따르던 지시를 갑자기 무시하는 거죠. 그러면 커뮤니티엔 어김없이 '모델 너프된 거 아니야?'라는 글이 올라오기 시작해요. 너프(nerf)는 원래 게임 용어인데요, 패치로 캐릭터나 무기 성능을 깎는 걸 말해요. AI 쪽에서는 '회사가 비용을 아끼려고 몰래 모델 성능을 낮췄다'는 의심을 표현할 때 써요.
문제는 이 논쟁이 대부분 느낌으로만 진행된다는 거예요. 누구는 확실히 멍청해졌다고 하고, 누구는 똑같다고 하고, 증거는 스크린샷 몇 장이 전부인 경우가 많죠. Livenerf는 바로 이 지점을 파고드는 오픈소스 프로젝트예요. 이름 그대로 'Opus 5.5가 지금 너프됐나?'라는 질문에 감이 아니라 꾸준히 쌓은 측정값으로 답해보자는 거예요.
핵심 아이디어: 같은 시험을 계속 보게 하기
원리 자체는 단순해요. 정해진 문제 세트를 모델에 주기적으로 풀게 하고, 그 점수를 시간 순서대로 기록하는 거예요. 매일 아침 같은 시간에 같은 체중계로 몸무게를 재는 것과 비슷해요. 체중계가 매번 바뀌거나 재는 시간이 들쭉날쭉하면 살이 찐 건지 알 수 없잖아요. 조건을 고정해야 변화가 보이거든요. (구체적인 문제 구성이나 실행 주기 같은 세부 구현은 저장소에서 직접 확인해보시는 걸 추천해요.)
그런데 LLM을 측정할 때는 체중계보다 까다로운 점이 하나 있어요. 바로 비결정성이에요. 이게 뭐냐면, 똑같은 질문을 넣어도 매번 조금씩 다른 답이 나온다는 뜻이에요. 모델은 다음 단어를 확률적으로 뽑기 때문에, 오늘 한 번 틀렸다고 해서 모델이 나빠졌다고 단정할 수 없어요. 그래서 제대로 측정하려면 같은 문제를 여러 번 돌려서 평균과 흩어진 정도(분산)를 함께 봐야 하고, 점수 변화가 우연한 흔들림인지 진짜 하락인지 통계적으로 구분할 수 있어야 해요. 이런 도구의 가치는 결국 '한 번 틀렸다'가 아니라 '며칠째 꾸준히 낮다'를 보여줄 수 있느냐에 달려 있어요.
왜 '너프됐다'는 느낌이 생길까
재밌는 건, 모델이 나빠졌다고 느끼는 이유가 한 가지가 아니라는 거예요.
첫째, 진짜로 뭔가 고장 난 경우가 있어요. 실제로 Anthropic은 2025년 9월에 사후 분석(postmortem) 보고서를 내고, 그해 8~9월에 걸쳐 세 가지 인프라 버그 때문에 일부 Claude 응답 품질이 떨어졌다고 인정했어요. 요청이 잘못된 서버로 라우팅되는 문제, 토큰 생성 과정의 설정 오류, 컴파일러 버그 같은 것들이었죠. 동시에 수요나 서버 부하 때문에 일부러 품질을 낮추는 일은 없다고도 밝혔고요. 여기서 포인트는, 모델 가중치(모델의 '뇌' 자체)는 그대로여도 그걸 서빙하는 인프라 문제로 체감 품질이 달라질 수 있다는 거예요.
둘째, 모델 바깥이 바뀐 경우예요. 채팅 앱이나 코딩 도구는 모델 앞에 시스템 프롬프트나 도구 설정을 붙여서 쓰는데, 이게 업데이트되면 모델은 같아도 행동이 달라져요.
셋째, 우리 쪽이 바뀐 경우예요. 처음엔 쉬운 걸 시켜보고 감탄하다가, 익숙해지면 점점 더 어려운 일을 맡기게 되잖아요. 대화가 길어져 컨텍스트가 지저분해진 것도 영향을 주고요. 이른바 '허니문 효과'가 끝나는 거죠.
Livenerf 같은 고정 벤치마크는 특히 셋째 경우를 걸러내는 데 유용해요. 문제가 고정돼 있으니 '내가 더 어려운 걸 시켜서' 같은 변수가 사라지거든요.
업계 맥락: 예전부터 있던 질문
이 질문은 사실 새롭지 않아요. 2023년에 스탠퍼드와 UC 버클리 연구진이 'ChatGPT의 행동은 시간에 따라 어떻게 변하는가'라는 논문을 냈는데, GPT-4의 3월 버전과 6월 버전이 특정 과제에서 꽤 다른 성능을 보였다는 결과로 큰 논쟁을 불렀어요. 측정 방식에 대한 반론도 많았고요. LMArena처럼 사람들이 모델을 비교 투표하는 리더보드도 있지만, 이런 곳은 주로 '어떤 모델이 더 나은가'를 보여주지, '같은 모델이 시간에 따라 변했나'를 추적하진 않아요. Livenerf는 시간 축에 집중한다는 점에서 결이 달라요.
한국 개발자에게 주는 시사점
LLM을 서비스에 붙여 쓰는 팀이라면 이 프로젝트에서 가져갈 게 많아요.
- 모델 버전을 고정하세요. API에서는 보통 별칭 대신 특정 스냅샷(날짜나 버전이 박힌 모델 ID)을 지정할 수 있어요. 별칭을 쓰면 어느 날 조용히 다른 모델로 바뀔 수 있거든요.
- 우리만의 평가 세트(eval)를 만드세요. 우리 서비스의 대표적인 프롬프트 20~50개와 기대 결과를 모아두고, 배포 전이나 주기적으로 돌리는 거예요. 일반 코드의 회귀 테스트(regression test)를 LLM 기능에 적용한다고 생각하면 돼요.
- 여러 번 돌려서 판단하세요. 한 번의 실패로 경보를 울리면 오탐이 넘쳐나요. 여러 번 샘플링해서 통과율로 보는 습관이 필요해요.
마무리
한 줄 정리: '너프됐다'는 느낌은 데이터로 검증할 수 있고, 그 방법은 우리 서비스에도 그대로 쓸 수 있어요.
여러분은 AI 도구가 '갑자기 멍청해졌다'고 느낀 적이 있나요? 그때 실제로 모델이 바뀐 걸까요, 아니면 우리가 시키는 일이 바뀐 걸까요? 팀에서 LLM 품질을 어떻게 모니터링하고 계신지도 궁금해요.
🔗 출처: Hacker News