Claude는 몰래 너프되지 않았을 가능성이 크다. Anthropic이 블랙박스를 너무 어둡게 만들었다

Claude Code 사용자들은 Opus 4.6이 예전보다 못해졌다고 느꼈지만, 공개된 증거만으로는 Anthropic이 모델 가중치를 몰래 낮췄다고 보긴 어렵다. 대신 adaptive thinking, effort 기본값, prompt cache TTL, context compaction, quota 정책 같은 운영 조건이 바뀌면서 체감 품질이 달라졌다는 쪽이 더 강하다.

가장 설득력 있는 অভিযোগ은 바이럴한 BridgeBench 차트가 아니라, 한 GitHub 이슈가 제기한 실제 작업 흐름의 변화다. 이 사용자는 6,852개 세션 파일과 17,871개 thinking block, 234,760개 tool call을 분석했다고 주장했고, 코드 읽기 횟수가 6.6회에서 2.0회로 감소하며 더 빨리 편집하고 더 자주 인간 수정이 필요해졌다고 보고했다. 다만 이 데이터는 한 사람의 환경에서 나온 것이어서, 모델 자체보다는 버전, 프롬프트, 캐시 상태, effort 설정, 컨텍스트 크기 같은 변수의 영향을 함께 봐야 한다.

Anthropic의 공개 설명은 오히려 문제의 본질을 드러낸다. 회사는 일부 사용자에게 medium effort 기본값을 적용했고, 이후 4월 7일에 API-key, Bedrock, Vertex, Foundry, Team, Enterprise 사용자들을 high effort로 이동시켰다. 즉, 같은 모델명이라도 실제로는 다른 운영 상태가 제공될 수 있었고, 사용자는 무엇이 바뀌었는지 확인하기 어려웠다.

캐시 정책도 불만을 키운 핵심 원인이다. Anthropic의 문서상 자동 캐시는 기본 5분 TTL이며, 1시간 옵션은 더 높은 쓰기 비용이 든다. 하지만 장시간 코드 작업처럼 중간에 테스트를 돌리고 기다리는 흐름에서는 캐시가 빨리 만료되면 다음 턴에서 비용과 지연이 커지고, 체감상 모델이 더 나빠진 것처럼 느껴질 수 있다.

결국 이 논란이 보여주는 것은 “Claude가 너프됐는가”보다 “사용자가 어떤 운영 조건의 제품을 사고 있는가”다. Anthropic은 모델 ID만이 아니라 effort level, adaptive-thinking 상태, cache TTL, quota accounting, compaction 이벤트 같은 세션 텔레메트리를 노출해야 하고, 팀들도 설정 고정과 반복 테스트, 읽은 파일 수, 수정 턴 수, 캐시 동작을 직접 측정해야 한다. frontier coding agent 시대에는 모델 이름보다 전달된 시스템이 실제 제품이다.