Claude Code가 4월 들어 이상해졌다고 느끼신 적 있으시죠?
Opus 4.7 말투가 어색해서 4.6으로 내려본 분 계시죠?
그런데 4.6도 마찬가지였던 경험 있으시죠?
Claude Code에서 Opus 4.7 말투가 이상해서 4.6으로 내렸다고 5일 전 블로그에 썼다. 오진이었다. 4월 23일 Anthropic 공식 포스트모템을 읽고 나서야 모델이 아니라 시스템 프롬프트 조정이 원인이었다는 걸 알았다. 4.6에도 같은 버그가 영향을 줬다. 다운그레이드는 해법이 아니었다. 이 글은 내 오진 복기와, Anthropic이 evals로 못 잡은 품질 회귀를 개인이 감지하는 방법 정리다.
먼저 요약 — 도입부만 읽으실 분을 위해
- 모델이 아니라 프롬프트 조정이 원인. 4.6·4.7 모두 영향받았다. 다운그레이드는 헛수고였다.
- 방어 수단은 체감 일지와 회귀 테스트 두 가지. 아래 템플릿 3줄·10줄로 오늘부터 쓸 수 있다.
Anthropic이 인정한 3가지 실수
공식 포스트모템에 따라 세 변경을 표로 정리한다. 각각 다른 팀에서 다른 목적으로 들어간 변경이 겹쳐 “broad·inconsistent degradation”처럼 보였다는 것이 Anthropic의 설명이다.
| # | 변경 내용 | 기간 | 영향 모델 | 체감 증상 |
|---|---|---|---|---|
| 1 | Claude Code 기본 reasoning high → medium 낮춤 |
3월 4일 ~ 4월 7일 (34일) | Sonnet 4.6, Opus 4.6 | 복잡 작업에서 “덜 생각함” |
| 2 | 1시간 idle 세션 older thinking 클리어 버그 | 3월 26일 ~ 4월 10일 (15일) | Sonnet 4.6, Opus 4.6 | 세션 중간부터 반복·망각 |
| 3 | Verbosity 줄이는 system prompt 추가 | 4월 16일 ~ 4월 20일 (4일) | Sonnet 4.6, Opus 4.6, Opus 4.7 | 코딩 품질 하락, 설명 부족 |
4월 20일 v2.1.116에서 3개 모두 해결됐고, 4월 23일 모든 구독자 usage limit이 리셋됐다. 핵심 포인트는 세 변경 모두 모델이 아니라 Claude Code 운영 레이어 조정이었다는 것이다.
교훈 1: 모델이 아니라 시스템 프롬프트다
나는 4월 중순 Opus 4.7 말투가 이상하다고 판단해 4.6으로 내렸다. 공식 발표를 보면 1·2·3번 버그 모두 4.6에도 영향을 줬다. 1번(추론 강도(reasoning effort) 하향)과 2번(유휴 세션 정리 버그)은 오히려 4.6·Sonnet 4.6 전용이기까지 했다. 다운그레이드가 다른 버그를 더 많이 노출시켰을 가능성이 있다.
이건 모델 번호가 아닌 운영 레이어가 체감 품질을 결정한다는 뜻이다. 한 달 사이 세 개의 운영 변경(추론 강도·세션 관리·시스템 프롬프트)이 각각 다른 의도로 들어갔고, 사용자는 모델 버전 A/B 테스트가 아니라 이 운영 변경의 누적 효과를 겪었다.
단, 이번 포스트모템이 4.7 본연의 성능까지 해명해준 건 아니다. 시스템 프롬프트 회귀가 걷힌 4월 20일 이후에야 4.6 vs 4.7 본래 비교가 가능해진 상태다. 그 판단은 이번 글 범위 밖이고, 다음 글에서 따로 검증할 주제다. 이번에 정리되는 건 “다운그레이드는 해법이 아니었다”까지다. 모델 번호는 이번 사건에서 비신호였고, 다음에는 모델 번호가 아니라 시스템 프롬프트 변경 공지를 먼저 확인할 것이다.
교훈 2: evals가 못 잡는다, 개인이 잡아야 한다
공식 발표는 “내부 평가(evals)가 초기에는 문제를 재현하지 못했다”고 인정했다. 3월 초부터 사용자 reports가 들어왔는데 Anthropic 내부 테스트 인프라는 4월 중순까지 잡지 못했다. “정상 편차(normal variation)와 구별이 어려웠다”는 해명인데, 이건 곧 체감 품질과 벤치마크 점수 사이에 구멍이 있다는 말이다. 비슷한 일이 또 생겨도 내부 평가는 못 잡는다.
왜 개인이 먼저 잡을 수 있는가? 내부 평가는 평균값을 본다. 대규모 테스트 케이스의 합산 점수가 normal variation 안에 있으면 “문제 없음”으로 판정된다. 반면 개인은 본인 워크로드 편차를 본다. 같은 블로거가 같은 프롬프트로 같은 결과를 기대하는데 출력이 미묘하게 달라지면, 평균에 묻힌 회귀도 개인 작업 루틴에서는 튀어 보인다. 이번 사건의 “세션 중간부터 반복·망각” 증상이 대표적이다. 평균 성능 그래프에는 찍히지 않지만 매일 30분씩 Claude Code 쓰는 사람은 며칠 만에 감지한다.
개인이 갖춰야 할 방어 수단은 두 가지다. 하나는 체감 일지 — 평소 작업의 감각 변화를 하루 3줄씩 기록하는 것. 다른 하나는 회귀 테스트 — 동일 조건에서 돌려 출력 품질을 비교할 수 있는 고정 프롬프트 하나를 유지하는 것. 둘 다 복잡할 필요 없고, 아래 템플릿이 출발점이다.
체감 일지 — 하루 3줄, 주 1회 회고
2026-04-24 | Claude Code Opus 4.7 | Blogger API 스크립트 수정
체감: 요청 안 한 리팩터를 과하게 시도함
판정: 평소보다 지시 준수 약함, 회귀 테스트 돌리기
저장 위치는 메모 앱·노션·Obsidian 어디든 상관없다. 중요한 건 작업 종료 직후 30초 안에 쓰는 것. 하루 걸러 쓰면 감각이 흐릿해진다. 주 1회(예: 일요일 저녁) 지난 7일치를 훑고 “평소와 다름” 판정이 3회 이상 쌓이면 회귀 테스트로 검증한다.
회귀 테스트 — 고정 프롬프트 1개
본인 워크로드에서 결과가 항상 비슷하게 나와야 하는 작업을 하나 고른다. 예시:
"아래 Python 함수에 pytest 3개 써줘. 함수 수정은 하지 마."
def add(a, b):
return a + b
평시 결과를 스크린샷으로 저장해둔다. 회귀 의심 시 같은 프롬프트를 돌리고 출력을 비교한다. 기준 셋: 테스트 3개 정상 생성 · 함수 미수정 · 코멘트 스타일 유지. 이 셋이 깨지면 뭔가 바뀐 것이다.
예상 질문 3가지
Q. 지금 Claude Code 바로 써도 되나?
A. 최신 버전(claude --version)이 v2.1.116 이상인지만 확인하면 된다. 이하면 업데이트하고 쓰면 된다.
Q. 체감 일지·회귀 테스트는 유료 구독자만 해야 하나?
A. 아니다. 무료·Pro·Max 관계없이 Claude Code 운영 변경은 동일하게 적용된다. 유료일수록 손해가 크니 더 필요하다.
Q. 다음 회귀는 언제쯤 올 것 같나?
A. 모른다. Anthropic은 “similar issues are much less likely”라고만 했다. “less likely”지 “not”이 아니다. “일어나지 않는다”로 해석하지 않는 한 방어 루틴을 돌려두는 쪽이 안전하다.
다음 회귀를 위한 준비
이번 포스트모템의 진짜 교훈은 “모델 다운그레이드는 해법이 아니다” 하나다. 체감 품질을 바꾸는 건 모델 번호보다 운영 레이어(시스템 프롬프트·세션 관리·추론 강도)다. 이번 정정 이후 내 검증 루틴은 셋으로 고정한다. ① 변경 공지 체크(Anthropic status·엔지니어링 블로그 RSS 구독). ② 체감 일지 하루 3줄. ③ 회귀 테스트 주 1회 실행. 이 조합을 2~3개월 돌려본 뒤 어떤 패턴이 실제 회귀를 잡았는지 후속 글로 공유할 계획이다. 같은 사건을 다르게 체감한 분이 있다면 댓글로 공유해달라.
관련 글
- Claude Opus 4.7 말투, 나는 4.6으로 내렸다 — 5일 써본 솔직한 판정 (이 글이 이번 포스트모템으로 정정 대상이 됐다)
- Claude Opus 4.7 시스템 프롬프트 3가지 핵심 변화 — 한국 사용자 체감 기준
- Claude Code 모델 선택법 — 작업 유형별 정답 (Opus 4.7 업데이트)
글쓴이 — Jason (cd4761)
8년 차 프론트엔드 개발자. 해고 후 AI 개발 도구 실측 기록을 남긴다. Claude Code·Opus 4.7·로컬 LLM 벤치마크 글 다수. 문의는 블로그 댓글로.
태그: #ClaudeCode #Anthropic #Opus47 #포스트모템 #품질회귀 #AI개발도구
댓글
댓글 쓰기