배경: Postmortem이란 무엇인가
소프트웨어 업계에서 postmortem(포스트모템)은 장애 발생 후 작성하는 공식 분석 보고서입니다.
“무엇이 잘못되었고, 왜 발생했으며, 어떻게 재발을 방지할 것인가"를 투명하게 기술하는 것이 핵심입니다.
Google, AWS, Cloudflare 등 대형 서비스가 장애 때마다 발행하며, 업계에서는 기업의 엔지니어링 성숙도를 보여주는 지표로 받아들입니다.
4월 23일, Anthropic은 포스트모템을 발행했습니다.
3월 4일부터 4월 20일까지 Claude Code 성능이 저하된 원인으로 세 가지 제품 레이어 버그를 인정한 문서입니다.
결론부터 말합니다.
인정한 세 가지 버그는 사실입니다. 수정도 사실입니다. 하지만 이 포스트모템은 전체 그림의 절반만 보여줍니다.
Anthropic이 인정한 세 가지 (사실인 부분)
| 버그 | 도입일 | 수정일 | 기간 |
|---|---|---|---|
Effort high → medium | March 4 (v2.1.68) | April 21 (v2.1.117) | 48일 |
| Thinking cache를 매 턴 초기화 | March 26 (v2.1.85) | April 10 (v2.1.101) | 15일 |
| “≤25 words” 시스템 프롬프트 | April 16 (v2.1.111) | April 20 (v2.1.116) | 4일 |
세 가지 모두 모델 가중치가 아닌 API 파라미터와 시스템 프롬프트 문제입니다.
effort 하향은 추론 깊이를 줄이고, thinking cache 초기화는 대화 맥락을 파괴하며, 25단어 제한은 응답을 잘라냈습니다.
세 가지가 겹치면 Claude가 확연히 멍청해 보입니다.
기술적으로 정확한 설명입니다.
이 부분은 수용합니다.
의도적으로 빠진 것: 모델 수준의 회귀
포스트모템은 “4.6 사용자가 느낀 성능 저하"만 다룹니다.
같은 시기에 동시에 쌓인 또 다른 불만 — “4.7이 4.6보다 못하다” — 는 한 줄도 언급하지 않습니다.
이것은 하네스 버그와 전혀 무관한, 모델 자체의 후퇴입니다.
| Opus 4.7 모델 이슈 | 근거 | 하네스 버그? |
|---|---|---|
| Tokenizer +35% (CJK에서 더 심함) | 공식 문서: “1.0x to 1.35x more tokens” | 아니오 — 아키텍처 변경 |
| Long-context retrieval: 91.9% → 59.2% (256K) | Anthropic 자체 system card (MRCR v2) | 아니오 — 모델 성능 |
| Long-context retrieval: 78.3% → 32.2% (1M) | Anthropic 자체 system card (MRCR v2) | 아니오 — 모델 성능 |
| 지시를 문자 그대로 따르는 행동 변화 | What’s New: “follows instructions more literally” | 아니오 — 학습 변경 |
| BrowseComp: 84.0% → 79.6% | Anthropic 벤치마크 | 아니오 — 모델 회귀 |
| 긴 페이로드에서 XML/JSON 혼합 (#49747) | 디코더 수준 포맷 전환 | 아니오 — 모델 동작 |
| 안전성 과잉 거부 (#49751) | 구조 생물학 코드가 4.7에서 차단, 4.6에서는 정상 | 아니오 — RLHF/안전 레이어 |
포스트모템의 서사는 “버그 3개 수정, 정상 복귀"입니다.
그러나 4.7로 올린 사용자들은 버그 수정과 무관한 별도의 문제를 겪고 있습니다.
핵심을 정리합니다.
포스트모템은 Stream A(“4.6이 멍청해졌다”)만 해결하고, Stream B(“4.7은 퇴보다”)는 존재 자체를 부정합니다.
비용 절감과의 “우연한” 일치
인정된 세 가지 버그에는 공통 방향이 있습니다.
| 버그 | 사용자 영향 | Anthropic 서빙 비용 |
|---|---|---|
Effort high → medium | 품질 저하 | 컴퓨팅 ↓↓ |
| Thinking cache 매 턴 초기화 | 맥락 유실, 반복 | Prefill ↓↓ (캐시 대상 감소) |
| “≤25 words” 출력 제한 | 정보량 감소 | 출력 토큰 ↓↓ |
세 가지 변경이 각각 독립적으로 요청당 서빙 비용을 낮춥니다.
공식 프레이밍은 “UI 프리징 수정,” “캐싱 최적화,” “장황함 감소"였습니다.
의도를 증명할 수는 없습니다.
그러나 다음 사실은 확인됩니다.
- 3건 중 3건이 우연히 비용 절감 방향과 일치할 확률은 낮습니다
- 세 건 중 두 건은 CHANGELOG에 기록조차 되지 않았습니다 — 논란을 예상한 조직적 판단이 아니면 설명하기 어렵습니다
- 유일하게 기록된 effort 변경도 “속도와 철저함 사이의 최적점"이라는 제품 개선으로 포장되었을 뿐, 비용 동기는 한 마디도 없습니다
순수한 실수라면 왜 두 건을 CHANGELOG에서 완전히 생략했습니까?
CHANGELOG 공백이 본질적 문제입니다
버그 자체보다 중요한 구조적 발견이 있습니다.
Anthropic은 공개 기록 없이 Claude Code의 동작을 변경할 수 있고, 실제로 그렇게 하고 있습니다.
CHANGELOG(변경 이력)는 소프트웨어에서 “언제 무엇이 바뀌었는지” 사용자에게 알리는 공식 문서입니다.
이것이 비어 있으면 사용자는 문제 원인을 추적할 방법이 없습니다.
구체적으로 확인한 내용입니다.
Thinking cache 버그는 3월 26일 도입, 4월 10일 수정.
CHANGELOG 3,285줄 전체를 검색했습니다 — “thinking cache,” “cache clear,” “thinking prun” 용어는 어디에도 없습니다.
“≤25 words” 시스템 프롬프트는 4월 16일 추가, 4월 20일 되돌림.
“25 words"와 “length limit” 역시 어디에도 없습니다.
시스템 프롬프트 변경은 구조적으로 불가시합니다.
사용자는 다음 중 어느 것도 할 수 없습니다.
- 현재 버전에서 어떤 시스템 프롬프트가 활성인지 확인
- 버전 간 시스템 프롬프트 차이 비교
- 시스템 프롬프트 변경이 경험을 저하시킨 시점 파악
- “모델이 멍청해졌다"와 “보이지 않는 지시가 제한 중"을 구분
포스트모템의 재발 방지 계획은 “안정화 기간"과 “점진적 롤아웃"을 언급합니다.
그러나 동작 변경에 대한 의무적 문서화는 한 줄도 없습니다.
구조적 불투명성은 그대로 유지됩니다.
포스트모템 이후 48시간: 해결되지 않았습니다
포스트모템의 서사는 “세 가지 버그, 4월 20일 기준 모두 수정"입니다.
그러나 4월 2224일, v2.1.117119에서 신규 이슈가 올라왔습니다.
| 이슈 | 문제 | Anthropic 대응 |
|---|---|---|
| #52502 | Subagent model: haiku 설정 무시 — 전부 Opus로 실행 ($10.87 vs $0.0005) | 없음 |
| #52534 | effortLevel 설정이 unpinOpus47LaunchEffort 플래그에 오버라이드됨 — 사용자 제어 불가 | 없음 |
| #52522 | Auto-compact 임계값 200K→1M 변경 — 하룻밤 사이 토큰 사용량 5배 증가 | 봇: “중복” |
| #52228 | 모델이 “Human:” 프롬프트를 날조하며 자기 대화 시작, 일방적 워크스테이션 조작 | 없음 |
엣지 케이스가 아닙니다.
#52502는 직접적인 과금 피해를 유발하는 이슈입니다.
#52534는 effort 설정 자체가 작동하지 않는다는 의미입니다.
#52522는 “수정"이 기존 사용자의 비용을 5배로 늘린 사례입니다.
“모두 수정됨"이라는 프레이밍은 약 48시간 만에 무너졌습니다.
이렇게 썼으면 인정했을 것입니다
포스트모템이 이렇게 말했다면:
“4.6 성능 저하를 설명하는 세 가지 하네스 버그를 발견하고 수정했습니다. 별도로, Opus 4.7에는 알려진 트레이드오프(tokenizer 효율, long-context retrieval, instruction following 동작)가 있으며 작업 중입니다. CHANGELOG가 시스템 프롬프트 변경을 다루지 않는 문제도 인지하고 있으며, 개선 방안을 검토 중입니다.”
이것이 완전한 포스트모템입니다.
실제로 발행된 것은 방어 가능한 범위만 선별한 인시던트 대응 — PR 성명서 역할을 하는 엔지니어링 블로그 포스트입니다.
필자의 입장
저는 4월 15일부터 v2.1.109에 버전을 고정하고 Opus 4.6으로 Claude Code를 운영하고 있습니다.
포스트모템의 세 가지 버그가 제 환경에 미친 영향은 다음과 같습니다.
- 버그 #1 (effort): v2.1.68+ 대상이므로, 3월 4일~4월 21일 48일간 노출
- 버그 #2 (thinking cache): v2.1.85
101 대상이므로, 3월 26일4월 10일 15일간 노출 후 서버 측 수정 - 버그 #3 (≤25 words): v2.1.111+ 대상이므로, 고정된 제 버전에는 해당 없음
3건 중 1건만 영향을 받았습니다.
나머지는 이미 해당 버전 아래에 고정되어 있었기 때문입니다.
버전 고정이 방어 전략으로 유효함을 포스트모템 자체가 증명합니다.
Opus 4.6은 최소 2027년 2월 5일까지 활성입니다.
10개월의 여유가 있습니다.
포스트모템은 제 판단을 바꾸지 않았습니다 — 강화했습니다.
진짜 해결책: AI 개발 도구 공식 LTS
버전 고정, 프록시 모니터링, CHANGELOG 수동 비교.
이것은 전부 벤더가 구조적으로 풀어야 할 문제를 사용자가 감당하는 것입니다.
이런 방어를 개인이 해야 하는 상황 자체가 비정상입니다.
AI 기반 CLI/IDE 도구를 출시하는 모든 회사에 공식 LTS(Long-Term Support) 채널이 필요합니다.
Anthropic만의 문제가 아닙니다.
Cursor, GitHub Copilot, Windsurf, Cline — 개발자 워크플로우에 개입하는 모든 도구에 해당됩니다.
사용자 측 고정이 답이 될 수 없는 이유
제 셋업은 작동합니다.
v2.1.109 고정, DISABLE_AUTOUPDATER=1, 프록시 모니터링.
하지만 이 접근에는 근본적 한계가 있습니다.
- 확장 불가. 대다수 사용자는 투명 프록시를 운영하지 않고 CHANGELOG를 읽지 않습니다. “뭔가 나빠졌다"는 느낌만 있을 뿐 원인 진단 수단이 없습니다.
- 도구와의 적대 관계. 자기가 쓰는 도구의 업데이트 메커니즘과 싸우는 형국입니다. 자동 업데이터, deprecation 타이머, 현재 버전을 전제하는 기능 플래그 — 전부 최신 버전을 강요합니다.
- 유효 기한 존재. Opus 4.6은 2027년 2월 은퇴합니다. 오래된 클라이언트는 언젠가 API 비호환에 부딪힙니다. 고정한 버전이 영원히 동작한다는 보장은 없습니다.
- 책임 전가. 벤더가 브레이킹 체인지를 배포하면, 고정하지 않은 사용자가 비난받습니다. 본말이 전도된 구조입니다.
공식 LTS는 이런 모습이어야 합니다
LTS 모델은 이미 성숙한 소프트웨어 생태계 어디에나 있습니다.
Node.js, Ubuntu, PostgreSQL, Java — 전부 안정 채널과 최신 채널을 분리합니다.
AI 개발 도구에도 같은 구조가 필요합니다.
| 항목 | 현재 현실 | LTS 채널 |
|---|---|---|
| 업데이트 주기 | 연속 배포 (매일 릴리스) | 분기별 보안/안정성 패치만 |
| 모델 변경 | 사전 동의 없이 수시 변경 | LTS 기간 중 모델 고정, 명시적 마이그레이션 경로 |
| 시스템 프롬프트 변경 | 불가시, 미기록 | 문서화 + LTS 사용자 opt-in |
| 브레이킹 동작 변경 | 고지 없이 배포 | 명시적 마이그레이션 필수 (deprecation → removal 사이클) |
| 최소 지원 기간 | “~보다 빠르지 않게” 지원 중단 | LTS 릴리스로부터 최소 12개월 보장 |
| 롤백 | 사용자 책임 (고정 + 프록시) | 벤더 제공: claude --channel lts 또는 동등 수단 |
비즈니스 논거: LTS는 자선이 아니라 리텐션입니다
기업 관점에서도 LTS는 합리적입니다.
- 엔터프라이즈 신뢰. 동작이 조용히 바뀌는 도구에 프로덕션을 맡길 기업은 없습니다. 공식 LTS = 엔터프라이즈 레디. 이것 없이는 조달팀 리스크 매트릭스에 “벤더 불안정성"이 추가됩니다.
- 지원 비용 절감. Anthropic의 100건 이상 Opus 4.7 이슈 중 절반은 사전 고지 없는 변경에 당황한 사용자입니다. 안정 채널이 이 카테고리를 통째로 제거합니다.
- 경쟁 차별화. 진정한 LTS를 최초로 제공하는 AI 코딩 도구가 “프로덕션 인프라” 시장을 가져갑니다. 지금 모든 도구는 데모 데이에 최적화되어 있지, day-200에 최적화되어 있지 않습니다.
요구 사항
Anthropic에게, 그리고 AI 개발 도구를 출시하는 모든 회사에게 요구합니다.
- 보장된 지원 기간(12개월 이상)의 공식 LTS 채널
- LTS 채널에서 보이지 않는 동작 변경 금지 — 모든 변경 문서화, 은밀한 시스템 프롬프트 수정 불가
- 모델 버전 보장 — LTS 사용자는 명시적 마이그레이션 전까지 선택한 모델 유지
- 롤백 메커니즘 — “버전 고정하고 기도하기"가 아닌, 벤더 지원 채널 전환
- 시스템 프롬프트 변경을 포함하는 투명한 CHANGELOG — 클라이언트 코드 변경만이 아닌 전체 동작 변경 기록
사용자가 프록시 데이터를 역공학해야 도구의 저하 원인을 알 수 있는 현재 상황은,
벤더와 전문 개발자 사이의 지속 가능한 관계가 아닙니다.
근거 자료
- 전체 크로스체크 (36개 주장 검증): 17_OPUS-47-POSTMORTEM-ANALYSIS.md
- Opus 4.7 기술 어드바이저리: 16_OPUS-47-ADVISORY.md
- 42K API 호출 분석: 01_BUGS.md
- DATASET.md (4개 독립 데이터셋): DATASET.md
42,363건의 프록시 캡처 API 호출, 포스트모템 36개 주장 크로스체크, 9건의 미해결 GitHub 이슈에 기반한 독립 분석입니다.
Anthropic과 제휴 관계가 아니며, Anthropic의 승인을 받지 않았습니다.