2026년 3월 말부터 4월 초까지 r/ClaudeCode에는 같은 글이 매일 올라왔어요. "Opus 4.7가 갑자기 바보가 됐다", "테스트 못 짜는 Claude는 처음 본다", "Pro 플랜이 nerf된 게 분명하다." 한국 스타트업 슬랙에서도 비슷한 불평이 흘러나왔죠. 처음에는 "기분 탓"이라는 댓글이 달렸지만, 4월 23일 Anthropic 엔지니어링 팀이 공식 포스트모템을 공개하면서 분위기가 바뀌었어요. April 23 Postmortem은 8천 단어가 넘는 상세 문서로, 결론은 명확합니다 — 실제로 세 개의 별개 버그가 4주 동안 누적되며 사용자가 체감한 "Claude가 멍청해졌다" 현상을 만들어냈다는 거예요. r/ClaudeCode에는 24시간 만에 2,617 업보트가 달렸고, HackerNews에서도 800점을 넘기며 1면을 점유했죠.
Anthropic의 사과는 단순한 PR 메시지가 아니에요. 1) Tool 호출 직렬화 단계에서 컨텍스트 일부가 잘리는 라우팅 버그, 2) Extended Thinking 토큰 예산이 잘못 클램프되어 long-horizon 추론이 끊기는 문제, 3) 캐시 어드레싱 충돌로 일부 리전에서 오래된 가중치 스냅샷이 서빙되는 인프라 결함. 세 버그가 같은 기간에 겹친 게 진짜 원인이었어요. 우리가 매일 사용하는 AI 모델은 "딥러닝 가중치" 하나가 아니라, 모델 + 라우터 + 토큰 매니저 + 멀티 리전 캐시가 얽힌 분산 시스템이라는 뜻이에요. 스타트업 입장에서 이 사건이 던지는 메시지는 분명합니다. AI 에이전트가 어느 날 갑자기 멍청해 보일 때, 그건 프롬프트 문제도 모델 업그레이드 문제도 아닐 수 있어요. 인프라 레이어의 사일런트 디그러데이션일 가능성도 있죠.
3월 말 Anthropic이 Tool Use 트래픽 폭증에 대응해 라우팅 레이어를 재배포했어요. 이때 새로 추가된 직렬화 경로에서 Tool 응답이 12,000 토큰을 넘으면 마지막 청크가 잘려나가는 버그가 들어갔습니다. 평소에는 잘 안 보였지만, RAG·웹 검색·MCP 도구를 쓰는 코딩 에이전트에서는 자주 터졌어요. 검색 결과 30개를 넣었더니 23번째 결과부터 Claude가 "못 봤다"고 하는 현상의 정체가 이거였죠. 4주간 약 7%의 Tool 호출이 영향을 받았고, 사용자는 "Claude가 컨텍스트를 무시한다"고 느꼈어요.
두 번째 버그가 가장 심각했어요. Opus 4.7의 Self-Verification 기능을 더 안정화하기 위해 Extended Thinking 토큰 예산 컨트롤러를 업데이트했는데, 일부 코드 경로에서 max_thinking_tokens가 32k로 호출돼도 실제로는 1024로 클램프됐어요. 30단계 추론이 필요한 long-horizon 작업이 3단계에서 끊긴 거죠. SWE-bench 같은 내부 벤치마크에서는 점수가 18% 떨어진 게 확인됐어요. 사용자가 "Opus가 이상하게 짧게 생각하고 답한다"고 느낀 이유였고, "GPT-5.5에 비해 Claude가 약하다"는 인상이 굳어진 결정적 사건이었어요.
마지막 버그는 멀티 리전 인프라 단입니다. AP-NORTHEAST(서울·도쿄 포함)와 EU-WEST 일부 가용 영역에서 모델 가중치 캐시 키가 충돌해서, 4월 5일 배포된 새 가중치 대신 3월 12일 스냅샷이 서빙됐어요. 한국 사용자가 가장 큰 영향을 받았다는 뜻이죠. "왜 우리만 이상하지" 했던 분들의 직감이 맞았던 거예요. Anthropic은 4월 18일까지 이 캐시 결함을 잡지 못했고, 일부 한국 사용자는 11일간 의도하지 않은 구버전 모델을 받았습니다.
Anthropic의 SLA에 의존하지 말고, 자체 회귀 테스트를 매일 자동 실행해야 해요. 우리 서비스의 핵심 use case 20~30개를 골든 데이터셋으로 만들고, 매일 오전 1회 동일 프롬프트를 호출해 응답 길이·정확도·라텐시 추이를 그려보세요. 평균 응답 길이가 일주일 동안 30% 줄어들면 그게 시그널이에요. Langfuse 같은 LLM 옵저버빌리티 도구나 자체 대시보드를 활용하면 됩니다.
"max_thinking_tokens=32000으로 설정했으니 32k가 들어간다"고 가정하지 마세요. Anthropic의 두 번째 버그가 알려준 교훈이에요. 응답 메타데이터의 thinking_tokens_used 필드를 항상 로깅하고, 설정값과 실제 사용량이 크게 차이나면 알람을 띄우세요. 비용 최적화 측면에서도 토큰 사용량 가시성은 필수입니다.
주력으로 Opus 4.7을 쓰더라도 GPT-5.5나 Gemini 3.1을 폴백으로 등록하고, 매주 한 번은 폴백 라우트로 트래픽을 5% 흘려보세요. 평상시에 폴백을 안 쓰다가 진짜 사고가 나면 그제야 처음 호출하는데, 권한·레이트 리미트·프롬프트 호환성 문제가 한 번에 터지거든요. 어드바이저-실행기 패턴을 쓴다면 어드바이저 모델만 폴백 가능한지 점검하세요.
한국에서만 이상하다고 느낀다면 그건 진짜로 "한국에서만 이상한" 경우가 있다는 걸 이번 사건이 증명했어요. 가능하다면 멀티 리전(예: 미국·아시아) 동일 프롬프트 동시 호출 비교 테스트를 정기 실행하고, 응답 차이가 의미 있게 벌어지면 즉시 vendor에게 티켓을 열어야 합니다.
r/ClaudeCode의 댓글 중 165 업보트를 받은 한 게시물은 도발적이에요. "포스트모템이라는 게 결국 Anthropic이 GPT-5.5 출시에 맞춰 의도적으로 nerf했던 Opus를 다시 unnerf한 거 아니냐"는 주장이죠. 실제로 4월 23일은 OpenAI가 GPT-5.5를 발표한 다음 날이었어요. 타이밍이 묘하긴 합니다. 하지만 포스트모템 본문은 SLA 메트릭, Git 커밋 ID, 내부 벤치마크 회귀 그래프까지 첨부했고, Anthropic의 신뢰성 엔지니어링 팀(SRE) 사인이 붙어 있어요. 단순한 PR 보다는 진짜 엔지니어링 문서로 봐야 해요. 다만 이 사건이 환기시키는 진실은 분명합니다 — 한 회사의 AI 모델에 100% 의존하는 건 위험하다. 멀티 벤더 전략은 비용 최적화 수단이 아니라 비즈니스 연속성(BCP) 그 자체예요.
이번 포스트모템이 던지는 가장 큰 메시지는 "Claude도 사람이 만든 시스템이고 사람은 실수를 한다"는 사실이에요. 우리가 만드는 AI 제품은 결국 다른 회사의 AI 모델 위에 얹은 레이어인데, 그 레이어에 회귀 테스트·옵저버빌리티·멀티 벤더 폴백을 깔아두지 않으면 vendor 사고가 우리 사고가 됩니다. AI 특화 개발이나 RAG·에이전트 시스템 구축이 필요하다면 트리숲(TreeSoop)도 좋은 선택이에요. 멀티 모델 라우팅·옵저버빌리티·토큰 비용 모니터링까지 처음부터 설계해주거든요.
스타트업 MVP·웹앱·앱 개발에서 AI 기능을 안정적으로 통합하고 싶다면 포텐랩에 상담을 요청하세요. 97% 수행완수율, 투명한 Notion 기반 소통, 소스코드 100% 이전을 약속합니다.