목차
이 글은 Anthropic 엔지니어링 블로그에 2026년 4월 23일 게재된 “An update on recent Claude Code quality reports” 를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/april-23-postmortem
한 줄로 말하면 #
“Claude Code가 멍청해졌다"는 신고 뒤에 또 세 가지 별개 변경이 있었다. 7개월 만에 같은 패턴이 반복됐다.
어떤 문제를 해결하려 했나 #
2026년 3~4월, 사용자들이 같은 종류 불평을 올리기 시작했습니다.
“Claude Code가 덜 똑똑해진 것 같아요.” “앞에서 한 말 자꾸 잊는데요.” “같은 작업이 토큰을 훨씬 많이 잡아먹어요.”
이게 #9에서 본 2025년 9월 사후분석 의 데자뷰입니다. 그때도 세 인프라 버그가 겹쳐 사일런트 품질 저하를 만들었었죠. 7개월 만에 같은 일이 다른 형태로 또 일어났습니다.
세 가지 근본 원인 #
1. 추론 강도 기본값 변경 (3/4 ~ 4/7) #
지연 문제 해결을 위해 Claude Code의 추론 노력 기본값을 high → medium 으로 낮춤.
- 영향: Sonnet 4.6, Opus 4.6
- 4/7 사용자 피드백 받아 되돌림
- 새 기본값: Opus 4.7은
xhigh, 다른 모델은high
2. 프롬프트 캐싱 버그 (3/26 ~ 4/10) #
유휴 세션 최적화 구현 결함. 사고(thinking) 기록을 한 번만 비워야 하는데 계속 비워서, 세션 내내 컨텍스트가 새어나갔습니다.
- 한 번 트리거되면 세션 전체에 지속
- 영향: Sonnet 4.6, Opus 4.6
- v2.1.101에서 수정 (4/10)
- 내부 실험과 CLI 표시 변경이 처음에 문제를 가렸음
3. 시스템 프롬프트 verbosity 변경 (4/16 ~ 4/20) #
추가된 지시 한 줄: “도구 호출 사이 텍스트는 25단어 이하로 유지하라.”
- 광범위 평가에서 3% 성능 하락
- 영향: Sonnet 4.6, Opus 4.6/4.7
- 4/20 되돌림
#9 사후분석과 비교 — 같은 패턴, 다른 형태 #
| 측면 | #9 (2025-09) | #24 (2026-04) |
|---|---|---|
| 버그 수 | 3개 | 3개 |
| 종류 | 라우팅·TPU·컴파일러 (인프라) | 추론 설정·캐싱·프롬프트 (소프트웨어) |
| 내부 평가가 잡았나 | ❌ | ❌ |
| 사용자 신호가 진실 | ✅ | ✅ |
| 합쳐서 만든 혼란 | “어떤 사용자만 이상함” | “전체적으로 멍청해진 느낌” |
7개월 사이 인프라는 #9에서 배운 대로 안정화됐는데, 이번엔 소프트웨어 변경 쪽에서 같은 패턴이 나왔습니다. “여러 변경이 겹쳐 평가가 못 잡는 사일런트 저하” 의 표면만 바뀐 거예요.
무엇을 바꿨나 #
- 내부 직원이 공개 빌드 사용 확대 — 사내 빌드와 공개 빌드 격차 줄이기
- Code Review 도구 다중 저장소 컨텍스트 지원
- 시스템 프롬프트 변경마다 모델별 광범위 평가 의무화
- 지능에 영향 줄 변경에 soak period와 점진적 롤아웃 적용
- 프롬프트 변경 감사를 위한 새 도구로 통제 강화
핵심 패턴: #9에서 약속한 “운영 환경 상시 평가"가 이번엔 인프라가 아닌 소프트웨어 변경에도 적용되도록 확장.
핵심 결론 #
품질 저하 신고가 들어올 때 사람들은 본능적으로 “하나의 큰 버그” 를 찾으려 합니다. 이 글이 다시 한 번 보여주는 답은 다릅니다.
“한 번 사고에서 배운 교훈을 한 영역에만 적용한 줄 알았는데, 사실은 같은 패턴이 다른 영역에서 반복될 수 있다는 걸 다시 배웠다.”
여러 작은 변경이 겹쳐서, 각각은 미미하지만 합쳐지면 사용자가 분명히 느끼는 저하를 만듭니다. 평가는 개별 변경을 잡아도 조합을 못 잡고, 그래서 사용자 신호가 항상 가장 빠른 탐지기예요.
내 작업에 적용한다면 #
시나리오 1 — 일반적인 데이터 분석 과정 #
분석 시스템에서도 비슷한 사일런트 저하가 일어납니다. 작은 변경 셋이 겹쳐 결과가 미묘하게 어긋나죠.
[흔한 사일런트 저하]
- 정제 임계값 살짝 조정
- 모델 하이퍼파라미터 약간 변경
- 평가 메트릭 정의 미세 수정
→ 각각은 별일 아닌데, 합쳐지면 결과가 다른 분석이 됨
[postmortem 정신 적용]
[변경 감사]
- 분석 파이프라인 변경마다 디프와 영향 평가 기록
- 변경 사이 soak period 두고 회귀 점검
[광범위 평가]
- 변경마다 단일 케이스 아닌 평가셋 전체 비교
- 평균만 보지 말고 분포 변화 점검
[사용자 신호]
- 결과를 받는 의사결정자에게 "위화감" 신고 채널 열기
- 자동 평가가 통과해도 위화감 보고는 1급 입력
[변경 롤백 용이성]
- 분석 코드/설정을 버전 관리, 빠르게 되돌릴 수 있게핵심: 분석 시스템의 신뢰성은 “여러 작은 변경의 조합 효과를 항상 의심하는 습관” 에서 옵니다.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
운영 자동화에서도 같은 패턴이 가장 위험한 사일런트 장애를 만듭니다.
[흔한 사일런트 운영 저하]
- CDN 설정 약간 변경
- 캐시 정책 미세 조정
- 빌드 옵션 살짝 수정
→ 각각은 별일 아닌데, 사용자 체감 속도가 점점 나빠짐
[postmortem 정신 적용]
[변경 감사 도구]
- 모든 운영 변경을 추적 가능하게 (Git, 변경 로그)
- 변경 사이 soak period 적용
[상시 운영 평가]
- 배포 전이 아니라 운영 중에도 핵심 페이지/응답시간 지속 측정
- 인프라 노이즈(#19)를 고려한 통제된 비교
[사용자 신호 1급]
- "이상해요?" 버튼 + 자유 서술 채널
- 모니터링 초록불이어도 사용자 신호는 별도로 점검
[조합 영향 검증]
- 변경 하나만 평가하지 말고, 최근 변경 누적 영향을 정기 점검핵심: 운영 자동화의 안정성은 “같은 종류 사고가 다른 형태로 반복될 수 있다” 는 인정에서 옵니다. 사후분석은 그 종류의 사고 자체를 막진 못해도, 사용자 신호를 듣는 체계는 다음 사고를 빨리 잡게 해줍니다.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
