Anthropic이 Claude를 몰래 낮췄다는 논란 — 파워 유저 반발의 진짜 맥락

“왜 갑자기 Claude가 이상해진 거지?”

3월 중순부터 이런 말이 AI 개발자 커뮤니티에서 자주 들렸다. Reddit의 r/ClaudeAI, Hacker News, X에서 비슷한 불만이 쌓였다. 모델이 지시를 무시하거나, 예전엔 잘 처리하던 복잡한 워크플로우에서 오류가 늘었다는 보고가 이어졌다. 처음엔 “그냥 내가 프롬프트를 잘못 쓴 건가?” 하고 넘기는 사람이 많았다. 나도 그 중 하나였다.

이 블로그는 Claude로 자동화되어 있다 — 리서치, 포스트 작성, 내부링크 삽입, 다국어 번역, 빌드, 배포까지. 3월 중순부터 지시를 건너뛰거나, 번역 품질이 갑자기 흔들리거나, 내부링크 조건이 빠지는 경우가 눈에 띄게 늘었다. 그때마다 SKILL.md를 다시 들여다보고, 프롬프트 구조를 손봤다. 지시를 더 명확하게 다시 써봤고, 파일 분량을 줄여봤고, 컨텍스트를 정리해봤다. 효과가 없었다.

4월 14일, Fortune이 이 현상을 기사로 다뤘다. 이틀 뒤 Axios가 추가 분석을 냈다. VentureBeat도 “Anthropic이 Claude를 nerfing하고 있는가?”라는 제목으로 합세했다. Gizmodo는 “Anthropic Is Jacking Up the Price for Power Users Amid Complaints Its Model Is Getting Worse”라는 꽤 직접적인 제목의 기사를 냈다. 그제야 퍼즐 조각이 맞춰졌다.

내 프롬프트 문제가 아니었다. 그리고 아마 당신의 프롬프트 문제도 아니었을 것이다.

지난 3월, Anthropic이 조용히 바꾼 것

3월 초, Anthropic은 Claude의 기본 “effort” 레벨을 조용히 낮췄다. 기존 기본값은 “high effort”였는데, 이를 “medium effort”로 변경했다.

이 사실을 공개적으로 인정한 건 Claude Code를 이끄는 Anthropic 임원 Boris Cherny였다. 그는 변경이 “사용자들이 Claude가 너무 많은 토큰을 쓴다는 피드백을 했기 때문”이라고 밝혔다. 그러면서 이 변경이 “changelog에 공개됐고, 사용자에게 다이얼로그로도 표시됐다”고 덧붙였다. “sneaky한 게 아니라 obvious하고 explicit한 변경이었다”는 주장이다.

이 설명이 기술적으로는 맞을 수 있다. 하지만 많은 사용자가 그 다이얼로그를 놓쳤거나 changelog를 읽지 않았다. 그 사실 자체가 이미 커뮤니케이션 실패를 의미한다. “공개했다”는 사실과 “사용자가 실제로 인식했다”는 사실은 다른 이야기다.

effort 레벨이 무엇인지 짚고 가자. Claude는 응답을 생성할 때 얼마나 “깊게 생각할지”를 조절하는 내부 파라미터를 가지고 있다. High effort는 더 많은 연산을 쓰고, 지시를 세밀하게 따르며, 복잡한 요청을 더 잘 처리한다. Medium effort는 더 빠르고 저렴하지만, 그만큼 지시를 단순화하거나 건너뛸 가능성이 높아진다. 이 파라미터는 API를 사용하는 개발자가 명시적으로 설정할 수 있었다. 문제는 기본값이 바뀌었다는 것이다. 직접 “high effort”를 지정하지 않은 사람들은 자동으로 medium으로 내려갔다.

여기서 중요한 포인트가 하나 있다. 엔터프라이즈 계약을 가진 기업 고객 입장에서 생각해보자. 수십 명의 직원이 Claude를 업무에 쓰고 있고, 팀별로 다양한 워크플로우가 구축되어 있다. 이 상황에서 API 기본값이 바뀌었다고 해서 모든 사람이 그 사실을 인식하고 설정을 조정하기를 기대하는 건 현실적이지 않다. 유저가 직접 건드리지 않은 기본값은 “계속 그대로 유지된다”는 신뢰 위에서 운영되는 게 정상이다.

실제로 이 변경이 얼마나 조용히 이뤄졌는지를 보면, Cherny가 Reddit에서 이 문제에 직접 답변하기 전까지 “Anthropic이 어떤 변경을 했는지”를 공식 채널에서 적극적으로 알리려는 움직임은 없었다. 사용자들이 문제를 제기하고 기사가 나오고 나서야 임원이 직접 나와서 설명했다. 이 순서가 많은 사람에게 “몰래 바꿨다”는 인상을 심었다.

”Medium Effort”가 실제 워크플로우에서 의미하는 것

추상적으로 들릴 수 있으니 구체적인 예를 들자.

Claude Code에서 복잡한 리팩토링을 맡겼다고 해보자. High effort라면 파일 간 의존성을 꼼꼼히 추적하고, 영향 범위를 파악한 뒤 변경을 진행한다. 타입 오류 하나가 여러 모듈에 전파되는지, 변경이 테스트를 깨트리는지를 미리 확인한다. Medium effort라면? “대충 이 파일만 바꾸면 되겠지”라는 판단이 늘어난다. 테스트를 돌려봐야 발견되는 종류의 버그가 생긴다.

직접 체감한 예도 있다. 이 블로그 자동화 워크플로우는 꽤 복잡한 지시 체계를 가지고 있다. 포스트 작성 규칙, 내부링크 삽입 기준, 언어별 번역 방식이 여러 파일에 담겨 있다. 3월 중순 이후, 이 지시들이 부분적으로 무시되는 빈도가 늘었다. “내부링크 최소 2개”라는 조건이 빠지거나, 번역이 기계적으로 느껴지거나, 포스트 분량이 갑자기 줄어드는 일이 생겼다. 당시 내 진단은 “프롬프트가 너무 길어져서 후반부를 잘 읽지 못하나?”였다. 지금 돌이켜보면 3월 초의 effort 레벨 변경과 타이밍이 정확히 일치한다.

더 흥미로운 역설도 있다. 파워 유저들 중 일부는 이 기간 동안 오히려 토큰 소비가 4배〜10배 늘었다고 보고했다. 이유는 단순하다. 성능이 낮아지면 응답이 부정확해지고, 재시도가 늘어난다. 지시를 제대로 따르지 못하면 사용자가 다시 요청해야 하고, 그 과정에서 더 많은 토큰이 소비된다. “토큰 절약”을 위해 effort를 낮췄는데 오히려 반대 결과가 나온 경우가 생긴 것이다. The Register는 이와 별개로 “Anthropic admits Claude Code quotas running out too fast”라는 기사를 냈다. Anthropic 측도 “예상보다 훨씬 빠르게 사용 한도에 도달하는 것이 팀의 최우선 문제”라고 인정했다.

자동화 파이프라인에서 이런 비정상 동작을 탐지하기란 쉽지 않다. 단일 요청에서 눈에 띄는 오류가 아니라, 긴 시간 동안 결과물의 품질이 서서히 낮아지는 형태로 나타나기 때문이다. 이 변화를 빠르게 알아챈 사람들은 대부분 결과물을 정기적으로 벤치마킹하거나, 품질 평가 자동화를 갖추고 있던 경우였다.

Claude Code를 사용하는 개발자들 사이에서는 구체적인 사례들이 공유됐다. 멀티 파일 리팩토링에서 이전엔 빠뜨리지 않던 의존성 업데이트를 건너뛰는 경우, 테스트 파일 업데이트를 포함하지 않고 소스만 바꾸는 경우, 에러 핸들링 코드를 단순화해버리는 경우 등이 보고됐다. 한 사용자는 “이전엔 알아서 처리하던 엣지 케이스를 이제는 직접 명시해줘야 한다”고 표현했다. 모델이 덜 “proactive”해졌다는 인상이다.

이 차이는 간단한 작업에서는 거의 감지되지 않는다. 복잡한 지시 체계를 가진 워크플로우, 여러 단계를 거치는 자동화 파이프라인, 그리고 수십 개의 파일에 걸친 작업에서 두드러진다. 즉, 가장 큰 비용을 지불하며 Claude를 가장 복잡하게 쓰는 사람들이 가장 큰 타격을 입은 셈이다.

파워 유저들이 분노한 이유 — 투명성의 문제

기술적 변경 자체보다 더 많은 사람이 분노한 건 투명성 문제였다.

LLM 서비스를 사용한다는 건 어느 정도 “블랙박스”를 받아들이는 계약이다. 모델이 정확히 어떻게 작동하는지 몰라도, 기대 수준의 성능이 유지된다는 전제하에 구독료를 내고 워크플로우를 구축한다. 팀을 교육하고, 도구를 통합하고, 프로세스를 짠다.

Anthropic은 이 기대 수준을 통보 없이 변경했다. 사용자가 직접 설정한 게 아니었다. 기업이 기본값을 낮추고, 그 사실을 changelog에 묻어뒀다.

Claude Code 사용량 분석에서 내가 정리했듯이, Claude Code를 프로덕션 워크플로우에 통합할수록 모델 행동의 예측 가능성이 핵심 요소가 된다. 어제와 오늘의 결과가 달라지면, 그게 내 코드 문제인지 모델 변경인지 디버깅하는 데 시간이 든다. 자동화 파이프라인일수록 그 비용은 더 크다.

Boris Cherny의 반박이 오히려 역효과를 냈다. “obvious and explicit”이라고 말하는 시점에, 이미 수백 명의 사용자가 “몰랐다”고 공개적으로 말하고 있었다. 기업 입장에서는 ‘공개했다’는 사실이 중요하겠지만, 그게 실제로 사용자에게 전달됐는지가 더 중요하다. 둘은 다른 이야기다.

많은 기업 고객은 매주 changelog를 읽지 않는다. 그들은 “API를 호출하면 이전과 비슷하게 작동할 것”이라는 암묵적 계약을 믿는다. 이번 변경은 그 계약을 깼다. 좀 더 정확하게 말하면, 그 계약이 원래부터 없었다는 걸 이번에 많은 사람이 인식하게 됐다는 게 더 맞을 수도 있다.

커뮤니티 반응 중 흥미로운 패턴이 하나 있었다. 많은 사람들이 “이 변화를 알아챈 방법”을 이야기했는데, 대부분 결과물이 이상해진 것을 먼저 발견하고 나서 원인을 역추적했다는 것이다. “코드 리뷰를 부탁했는데 이전보다 얕아졌다”, “복잡한 문서를 요약시켰는데 중요한 내용이 빠졌다”는 식의 경험이 반복됐고, 그 다음에야 검색을 통해 effort 레벨 변경 사실을 알게 됐다. 사용자가 모델 행동 변화를 추적하는 도구가 사실상 없다는 것이 이번에 다시 한번 확인됐다.

가격 인상이 불에 기름을 부었다

타이밍이 최악이었다.

성능 저하 논란이 한창이던 4월 16일, Anthropic은 엔터프라이즈 구독 정책을 바꿨다. 기존에는 유저당 월 최대 $200 정액제였는데, 이를 “$20/유저/월 기본료 + 컴퓨트 사용량 기반 요금”으로 전환한다고 발표했다.

The Register는 이를 “Anthropic ejects bundled tokens from enterprise seat deal”이라고 표현했다. 번들 토큰을 없애고 종량제로 전환한 것이다. 사용량이 예측 가능하고 제한적인 팀에게는 오히려 더 쌀 수 있지만, 헤비 유저나 자동화 파이프라인을 대규모로 운영하는 팀에게는 비용이 크게 올라갈 수 있다.

성능은 낮아졌는데, 요금 체계는 더 복잡하고 대규모 사용 시엔 더 비싸질 수 있는 구조로 바뀐 거다. Gizmodo의 제목이 많은 사용자의 감정을 정확하게 담았다: “Anthropic Is Jacking Up the Price for Power Users Amid Complaints Its Model Is Getting Worse.”

물론 Anthropic 입장도 이해는 간다. 플랫 피 구조는 헤비 유저에게 절대적으로 유리하고, 서비스 제공자 입장에서는 지속 불가능할 수 있다. 종량제 전환 자체는 합리적인 비즈니스 결정일 수 있다. 사용량 예측이 어려운 플랫 피 모델보다, 사용한 만큼 내는 구조가 장기적으로 공정하다는 논리도 있다. 문제는 순서다. 신뢰가 흔들리는 시점에 가격 인상을 발표하면, 그 합리성이 제대로 전달되지 않는다.

타이밍을 다르게 했다면 어땠을까. effort 레벨 변경을 충분히 공지하고, 사용자 피드백을 반영해 default를 다시 개선한 다음, 가격 정책 변경을 별도로 발표했다면? 이 세 개의 이슈가 동시에 폭발하지 않았을 것이다. 각각의 결정이 독립적으로 평가받을 기회가 있었을 것이다. 지금은 세 가지가 하나로 묶여서 “Anthropic이 퇴보하고 있다”는 프레임으로 읽히고 있다.

컴퓨트 부족설과 AI 서비스의 구조적 압박

이 논란에는 하나 더 큰 맥락이 있다.

LLM 인프라 사업은 돈을 태우는 사업이다. Anthropic, OpenAI, Google DeepMind 모두 데이터센터 용량 확보에 수십억 달러를 쏟고 있다. Fortune 기사에 따르면, Anthropic은 경쟁사 대비 데이터센터 확보 규모가 상대적으로 작다는 분석이 있다. 이 부분은 내가 직접 확인할 수 없는 내용이고, 공식 발표가 아닌 분석이다. Anthropic의 공식 재무 공시나 인프라 투자 내역은 비공개다. 다만 Fortune과 Axios 같은 매체가 이 맥락을 함께 다뤘다는 건 주목할 만하다. 단순한 커뮤니티 추측이 아니라, 업계 취재를 바탕으로 한 분석이라는 점에서다.

여기서 나온 추측이 “Anthropic이 컴퓨트 부족으로 인해 effort 레벨을 조정했다”는 것이다. 내부적으로 Mythos 같은 차세대 모델 개발에 컴퓨트를 집중 투입하고, 기존 서비스의 effort 레벨을 낮춰 운영 비용을 절감했다는 해석이다. Anthropic은 이 추측을 공식적으로 부인하지 않았다.

내가 확신할 수 있는 건 아니다. 하지만 “비용 압박에 따라 서비스 품질이 조용히 조정된다”는 게 이 산업에서 거의 논의되지 않는 영역이라는 건 사실이다.

Claude Code 에이전틱 워크플로우 패턴 5가지를 작성하면서도 느꼈지만, 에이전트 시스템을 복잡하게 구축할수록 모델의 작은 성능 변화가 전체 워크플로우에 미치는 영향이 기하급수적으로 커진다. Orchestrator-subagent 구조를 여러 레이어로 쌓으면, effort 레벨 하나가 전체 파이프라인의 신뢰도를 떨어뜨릴 수 있다. 이번에 많은 Claude Code 사용자들이 직접 확인한 셈이다.

사용자는 “모델이 업그레이드될수록 더 좋아진다”는 기대를 가지고 있다. 실제로는 비용 압박에 따라 서비스 품질이 달라질 수 있다. 이 두 가지 사실은 동시에 사실일 수 있다. 새 버전의 모델이 더 강력해지는 동시에, 현재 운영 중인 버전의 서비스 품질이 비용 이유로 조정될 수 있다. 버전이 업그레이드되지 않은 채 기본 동작 방식만 조용히 바뀌는 것 — 이 구조적 간극을 AI 서비스 업계가 어떻게 다뤄가는지가, 앞으로 이 산업의 신뢰도를 결정하는 핵심 변수가 될 것이다.

개발자가 지금 해야 할 것들

이 사태에서 실질적인 교훈을 뽑는다면 세 가지다.

첫째, effort 레벨을 명시적으로 설정하라. Claude API를 직접 호출하는 개발자라면, 기본값에 의존하지 말고 매개변수로 직접 effort를 명시해두는 게 좋다. 예를 들어 Claude Code의 설정 파일에서 default-model-settings에 "thinking": { "type": "enabled", "budget_tokens": 10000 } 같은 방식으로 명시적으로 처리 깊이를 고정할 수 있다. 기본값은 언제든 바뀔 수 있다는 걸 이번에 확인했다. 중요한 워크플로우일수록 모든 파라미터를 명시적으로 고정해야 한다.

둘째, 결과물 품질을 정기적으로 측정하라. LLM 서비스 품질이 조용히 바뀌었을 때 빠르게 감지하려면, 기준점이 있어야 한다. 핵심 태스크 샘플을 일정 주기로 자동 실행하고, 결과물을 이전과 비교하는 간단한 벤치마크만 있어도 이번 같은 변화를 훨씬 빨리 알아챌 수 있었다. 완벽한 평가 시스템이 필요한 게 아니다. 예를 들어 “지시한 조건이 결과물에 모두 반영됐는가”를 자동으로 체크하는 스크립트만 있어도, 이번 논란에서 보름은 일찍 이상을 감지할 수 있었을 것이다. 변화 감지가 목적이니까, 과도하게 복잡한 시스템을 만들 필요는 없다.

셋째, 공급자 의존도를 분산시키는 걸 진지하게 고려하라. 단일 LLM 제공사에 모든 워크플로우를 의존하면, 그 제공사의 가격 정책이나 성능 조정이 곧 내 인프라 리스크가 된다. 아직 많은 팀이 “Claude 아니면 OpenAI”로 단일화해서 쓰고 있다. 그게 단기적으로 편리하지만, 장기적으로는 협상력도, 리스크 헷지도 없는 구조다. 모든 걸 이중화할 필요는 없지만, 핵심 워크플로우 하나쯤은 다른 모델로도 동작하도록 설계해두는 게 좋다. 이번처럼 주요 제공사가 성능을 조정하거나 가격을 바꿀 때, 대안이 있다는 것 자체가 협상에서 유리하고, 장애 대응에서도 유리하다. LiteLLM 같은 추상화 레이어를 쓰면 제공사 전환 비용을 크게 낮출 수 있다.

내 입장: 투명성이 없으면 신뢰도 없다

나는 이 사태에 대해 명확한 입장을 가지고 있다.

Anthropic의 기술적 결정 자체보다, 그 결정을 커뮤니케이션한 방식이 잘못됐다.

사용자 피드백에 대응해 토큰 사용량을 줄이려 했다는 명분은 이해한다. effort 레벨을 낮추면 토큰이 줄어든다는 것도 맞다. 이 결정이 악의적이었다고 보기는 어렵다. 하지만 기본값이 바뀌었을 때, 특히 성능에 직접 영향을 주는 기본값이 바뀌었을 때는, 모든 사용자에게 이메일로 고지하거나 제품 내 배너로 명확히 알려야 한다. Changelog 한 줄이 커뮤니케이션의 전부라면, 그건 기준에 미치지 못한다. 기존 사용자 기대를 낮추는 변경은 그 어떤 이유가 있더라도 적극적인 고지가 필요하다. 아마 Anthropic도 이번에 그 기준을 다시 세울 것이다.

더 근본적인 문제는 따로 있다. AI 서비스 제공사가 성능과 비용 사이의 트레이드오프를 사용자 모르게 조절할 수 있는 구조 자체다. 이건 Anthropic만의 문제가 아니다. OpenAI도, Google도 다 비슷한 구조를 가지고 있다. 우리는 단일 공급자에 깊이 의존한 AI 인프라를 구축하고 있고, 그 공급자가 서비스 레벨을 조용히 바꿔도 이를 감지하고 대응할 수단이 마땅치 않다.

이번 논란은 조용히 수그러들 것이다. Anthropic이 effort 레벨 설정 옵션을 더 명확하게 제공하거나, 기본값 변경 시 사용자 고지 정책을 강화하면 된다. 일부 개선 조치는 이미 발표됐다는 보도도 있다. 아마 몇 달 지나면 이번 사태는 “한때 논란이 있었다”는 각주 정도로 기억될 것이다.

하지만 AI 인프라를 구축하는 사람이라면, 이번 사태를 하나의 신호로 봐야 한다. LLM API 위에 프로덕션 시스템을 구축하는 건 이제 일상이 됐다. 그 위에 올라가는 책임도 일상이 되고 있다. 공급자 SLA를 자체적으로 모니터링하는 것이 선택이 아니라 필수가 되어가고 있다.

“AI가 점점 좋아지고 있다”는 내러티브는 맞다. 동시에, 이미 쓰고 있는 AI가 조용히 달라질 수 있다는 것도 맞다. LLM 서비스가 인프라로 자리 잡을수록, 인프라에 적용하던 관리 원칙 — 변화 감지, SLA 모니터링, 공급자 다양화 — 을 그대로 적용해야 한다. 두 이야기가 공존한다는 걸 이번 논란이 보여줬다.