올해 1월, Claude Code를 처음 실전에 투입했을 때를 떠올려보면 솔직히 놀라웠다. 단순한 코드 자동완성이 아니라, 복잡한 아키텍처 결정에 대한 분석적 의견까지 내놓는 수준이었다. 그런데 지금은 다르다. 같은 도구인데 체감 품질이 확연히 떨어졌다는 이야기가 현장 곳곳에서 나온다. 이건 기분 탓이 아니었다.
브런치에 올라온 현장 리포트(brunch.co.kr)가 이를 수치로 뒷받침한다. 외부 보고서를 인용한 이 글에 따르면, Claude Code의 Thinking 토큰이 2월 이후 기존 대비 73% 이상 감소한 것으로 추정된다. 사고 깊이가 줄었다는 뜻이다. 실제로 1월 수준의 Claude Code는 "인문학적 소양을 갖춘 고급 개발자" 같았다면, 지금은 "소프트웨어 전공 이과생" 수준으로 체감된다는 묘사가 나온다. 과장처럼 들리지만, Sonnet으로 해소 안 되는 버그를 Opus에 던지면 빠르게 해결되는 현상을 반복 경험한 사람이라면 고개를 끄덕일 것이다.
이 품질 변동의 배경은 명확하다. Anthropic은 지금 B2B 확대에 전력을 다하고 있다. AI타임스 보도에 따르면, Anthropic은 제너럴 애틀랜틱·블랙스톤 등 주요 사모펀드와 손잡고 약 2억 달러(2,900억 원)를 투자해 기업용 AI 컨설팅 합작법인(JV) 설립을 추진 중이다. 단순 모델 공급을 넘어 기업 운영 전반에 AI를 이식하는 컨설팅 역할까지 맡겠다는 것이다. OpenAI도 동일한 방향으로 움직이고 있다. 이 구도에서 소비자·개발자 대상 무제한 고성능 Thinking 토큰 제공은 우선순위가 뒤로 밀릴 수밖에 없다. 결국 지금의 품질 조정은 사업 전략의 결과다.
문제는 이 사실을 팀 설계에 반영하는 팀이 거의 없다는 것이다. 47개 AI 도구를 직접 테스트한 RawPickAI의 리뷰어가 지적한 핵심도 같은 맥락이다. 대부분의 리뷰는 "마케팅 페이지를 다시 쓴 것"에 불과하다. 실제 사용 마찰—Cursor의 자동완성이 탁월하지만 $20/월 Pro 플랜이 부담스럽다는 점, Claude가 장문 분석엔 뛰어나지만 특정 요청을 거부한다는 점—은 기능 목록에 등장하지 않는다. 품질 변동 리스크도 마찬가지다. 도입 시점에 측정한 성능이 3개월 후에도 유지된다는 보장은 어디에도 없다.
그렇다면 AI-First 팀은 이 변동성을 어떻게 설계에 흡수해야 하는가. 세 가지를 현장에서 적용해볼 만하다.
첫째, 모델 티어를 하드코딩하지 말고 라우팅 가능한 구조로 설계하라. Sonnet이 충분한 작업과 Opus가 필요한 작업을 명시적으로 분리해두면, 모델 품질이 조정되더라도 파이프라인 전체를 뜯어고칠 필요가 없다. 특정 모델에 전체 워크플로우를 의존시키는 순간, 그 모델의 품질 변동이 팀 전체의 생산성 변동이 된다.
둘째, 업무 명세의 정밀도를 높이는 것이 품질 변동의 완충재다. 브런치 리포트가 지적한 것처럼, Thinking 토큰이 줄어든 환경에서도 명확한 스펙과 Agent 역할 분리가 갖춰진 팀은 상대적으로 타격이 적다. 반대로 "대충 프롬프트 넣으면 알아서 해줄 것"이라는 기대에 의존한 워크플로우는 모델 품질이 조금만 낮아져도 즉시 무너진다.
셋째, 성능 기준선(baseline)을 주기적으로 재측정하라. 도입 시점에 설정한 품질 기대치를 분기마다 재검증하지 않으면, 품질 저하를 팀원 역량 문제로 오진하는 일이 생긴다. 실제로 "요즘 Claude Code 왜 이렇지?"라는 현장 피드백이 나오기 전에 벤치마크가 먼저 포착해야 한다.
한 가지 더 냉정하게 짚고 싶다. AI 도구 품질 변동 리스크는 Claude Code만의 문제가 아니다. RawPickAI의 47개 도구 리뷰에서도 드러났듯, 코드 에디터 카테고리는 현재 Cursor·Windsurf·GitHub Copilot·Tabnine이 치열하게 경쟁 중이며 그 격차는 마케팅이 말하는 것보다 훨씬 좁다. 이 말은 오늘의 1위가 내일의 1위라는 보장이 없다는 뜻이기도 하다. 도구 하나에 팀 전체의 워크플로우를 묶어두는 것 자체가 리스크다.
Anthropicn의 B2B 전략이 가속화될수록, 소비자·스타트업 대상 고성능 무제한 제공보다는 엔터프라이즈 계층을 위한 프리미엄 티어 분리가 강화될 가능성이 높다. 이미 그 신호는 Thinking 토큰 감축에서 나타나고 있다. 앞으로 더 높은 성능이 필요한 팀은 더 높은 비용을 지불해야 할 것이다. 이것은 나쁜 소식이 아니다. 단, 그 비용 구조를 미리 설계에 반영한 팀과 그렇지 않은 팀의 ROI 격차는 벌어질 것이다.
결국 AI 도구의 성능은 고정값이 아니라 변수다. 팀 설계에서 이 변수를 상수로 취급하는 순간, 리스크는 이미 시작된 것이다. 오늘 내일 당장 해볼 수 있는 것은 하나다. 지금 쓰고 있는 AI 도구의 성능 기준선을 명문화하고, 다음 분기에 다시 측정할 날짜를 캘린더에 박아두는 것. 거기서부터 품질 변동 리스크 관리는 시작된다.