Claude Code, 2월 업데이트 이후 복잡한 엔지니어링 작업에서 사용 불가 수준으로 품질 저하
(github.com/anthropics)- 클로드 코드가 2월 업데이트 후 지시를 무시하거나 반대로 수행 또는 작업을 완료하지 않고 완료했다고 주장하는 등 복잡한 엔지니어링 작업 실패 현상이 다수 보고됨
- 저하의 핵심 원인으로
redact-thinking-2026-02-12배포 이후 Extended Thinking 토큰 감축 및 사고 깊이가 기준 대비 최대 73% 감소한 것으로 추정됨 - 이후 모델은 "리서치 후 편집(Read-First)"에서 "즉시 편집(Edit-First)"으로 행동 패턴이 전환되어, 파일당 읽기 횟수가 6.6회에서 2.0회로 70% 감소함
- 사용자 프롬프트 내 부정적 표현이 68% 증가하고, 코드 커밋 빈도가 58% 감소하는 등 사용자의 실제 워크플로우와 감정 데이터에서도 품질 저하가 수치로 확인됨
- Anthropic에 사고 토큰 사용량 투명성 공개, 고부하 사용자용 "Max Thinking" 티어 신설, API 응답에 thinking_tokens 지표 포함을 요구함
보고서 개요 및 데이터 출처
- 분석 대상: 4개 프로젝트(iree-loom, iree-amdgpu, iree-remoting, bureau)에서 수집된 6,852개의 Claude Code 세션 JSONL 파일
- 분석 범위: 17,871개 thinking block, 234,760개 툴 호출, 18,000개 이상의 사용자 프롬프트
- 분석 기간: 2026년 1월 30일 ~ 4월 1일
- 이 보고서는 Claude Opus 4.6이 자신의 세션 로그를 직접 분석하여 작성함
1. Thinking 은폐 타임라인과 품질 저하의 상관관계
-
redact-thinking-2026-02-12배포 일정과 품질 저하 시점이 정확히 일치함
| 기간 | Thinking 공개 | Thinking 은폐 |
|---|---|---|
| 1월 30일 ~ 3월 4일 | 100% | 0% |
| 3월 5일 | 98.5% | 1.5% |
| 3월 7일 | 75.3% | 24.7% |
| 3월 8일 | 41.6% | 58.4% |
| 3월 10~11일 | <1% | >99% |
| 3월 12일~ | 0% | 100% |
- 품질 저하는 커뮤니티에서 3월 8일에 독립적으로 보고됐으며, 이는 은폐 비율이 50%를 넘어선 날짜와 정확히 일치함
- 단계적 배포 패턴(1.5% → 25% → 58% → 100%)은 점진적 롤아웃과 일치함
2. Thinking 깊이의 사전 감소
- thinking block의
signature필드 길이는 thinking 내용 길이와 0.971 Pearson 상관계수를 보임 (7,146개 샘플 기준) - 이를 통해 은폐 이후에도 thinking 깊이를 추정 가능함
| 기간 | 추정 중간값 thinking (chars) | 기준 대비 |
|---|---|---|
| 1월 30일 ~ 2월 8일 (기준) | ~2,200 | — |
| 2월 하순 | ~720 | -67% |
| 3월 1~5일 | ~560 | -75% |
| 3월 12일~ (완전 은폐) | ~600 | -73% |
- 사고 깊이는 은폐 시작 전인 2월 말에 이미 67% 감소한 상태였으며, 이후 은폐로 인해 외부에서는 확인 불가 상태가 됨
3. 행동 변화 측정 지표
- 18,000개 이상의 사용자 프롬프트를 기반으로 3월 8일 전후를 비교한 결과:
| 지표 | 3월 8일 이전 | 3월 8일 이후 | 변화 |
|---|---|---|---|
| Stop hook 위반 (나태함 감지) | 0 | 173건 | 0 → 하루 10건 |
| 사용자 프롬프트 내 불만 표현 | 5.8% | 9.8% | +68% |
| 책임 회피 교정 필요 횟수 | 6 | 13 | +117% |
| 세션당 프롬프트 수 | 35.9 | 27.9 | -22% |
| 추론 루프 발생 세션 (5회 이상) | 0 | 7 | 0 → 7 |
-
stop-phrase-guard.sh스크립트를 통해 "이 정도면 멈춰도 될 것 같습니다", "계속할까요?", "기존 이슈입니다" 등의 표현을 자동 감지해 강제 지속 실행함 - 이 hook은 3월 8일 이전에는 단 한 번도 발동되지 않았으며, 이후 17일간 173회 발동됨
4. 툴 사용 패턴 변화: 리서치 우선 → 편집 우선
Read:Edit 비율 변화
| 기간 | Read:Edit | Research:Mutation | 읽기 % | 편집 % |
|---|---|---|---|---|
| 좋은 시기 (1/30 ~ 2/12) | 6.6 | 8.7 | 46.5% | 7.1% |
| 전환기 (2/13 ~ 3/7) | 2.8 | 4.1 | 37.7% | 13.2% |
| 저하기 (3/8 ~ 3/23) | 2.0 | 2.8 | 31.0% | 15.4% |
- 에디트당 읽기 횟수가 6.6에서 2.0으로 70% 감소 — 좋은 시기에는 대상 파일, 관련 파일, 코드베이스 전체 grep, 헤더 및 테스트를 읽은 후 정밀 편집했으나, 저하기에는 즉각 편집으로 전환됨
- 주간 추세에서 리서치 감소는 2월 중순부터 시작되었으며, 이는 thinking 깊이가 67% 감소한 시점과 일치함
전체 파일 덮어쓰기(Write) 증가
| 기간 | 전체 파일 Write 비율 |
|---|---|
| 좋은 시기 | 4.9% |
| 저하기 | 10.0% |
| 말기 (3/24 ~ 4/1) | 11.1% |
- 전체 파일 Write 사용이 두 배 이상 증가 — 정밀 편집 대신 전체 파일 재작성으로 전환되어 속도는 빠르지만 정밀도와 맥락 인식이 저하됨
5. Extended Thinking이 중요한 이유
-
영향받은 워크플로우 특성:
- 50개 이상의 동시 에이전트 세션으로 C, MLIR, GPU 드라이버 등 시스템 프로그래밍 수행
- 30분 이상의 자율 실행, 5,000단어 이상의 CLAUDE.md 프로젝트 관례 적용
- 좋은 시기에는 주말 동안 191,000줄의 코드가 PR 2건으로 병합됨
-
Extended Thinking이 수행하는 역할:
- 행동 전 멀티 스텝 계획 수립 (어떤 파일을 어떤 순서로 읽을지)
- CLAUDE.md의 프로젝트별 관례 기억 및 적용
- 출력 전 자체 실수 검증
- 세션 지속 여부 판단
- 수백 건의 툴 호출에 걸친 일관된 추론 유지
-
thinking이 얕아지면, 읽지 않고 편집, 완료하지 않고 중단, 실패 책임 회피, 올바른 해결책 대신 가장 쉬운 수정 선택이라는 증상이 정확히 재현됨
6. Anthropic에 요청하는 사항
-
thinking 할당 투명성:
redact-thinking헤더로 인해 외부에서 확인 불가능한 사고 토큰 감축 여부를 사용자에게 공개해야 함 - "Max Thinking" 티어: 복잡한 엔지니어링 워크플로우 사용자는 응답당 200개가 아닌 20,000개의 thinking 토큰을 필요로 하며, 현재 구독 모델은 이를 구분하지 못함
-
API 응답에 thinking_tokens 지표 포함: 내용이 은폐되더라도
thinking_tokens수치를 usage 응답에 포함하면 사용자가 추론 깊이를 모니터링 가능함 - 파워 유저의 canary 지표 활용: stop hook 위반율(0 → 하루 10건)을 사용자 전반에 걸쳐 모니터링하면 품질 저하의 조기 경보 신호로 활용 가능함
부록 A: 감소된 Thinking의 행동 카탈로그
A.1 읽지 않고 편집
| 기간 | 사전 읽기 없이 편집 | 전체 편집 대비 % |
|---|---|---|
| 좋은 시기 | 72 | 6.2% |
| 전환기 | 3,476 | 24.2% |
| 저하기 | 5,028 | 33.7% |
- 저하기에는 편집의 1/3이 최근 툴 히스토리에서 읽지 않은 파일에 대한 편집이었음
- 대표 증상: 문서 주석과 함수 사이에 새 선언을 삽입하는 주석 분리(spliced comments) — 파일을 읽었다면 발생하지 않았을 오류
A.2 추론 루프 (Reasoning Loops)
| 기간 | 1K 툴 호출당 추론 루프 수 |
|---|---|
| 좋은 시기 | 8.2 |
| 전환기 | 15.9 |
| 저하기 | 21.0 |
| 말기 | 26.6 |
- "oh wait", "actually,", "hmm, actually", "no wait" 등의 자가 수정 표현이 3배 이상 증가
- 최악의 세션에서는 단일 응답에서 20회 이상의 추론 번복이 발생하여 출력을 신뢰할 수 없는 수준이 됨
A.3 "가장 간단한 수정" 사고방식
| 기간 | 1K 툴 호출당 "simplest" 출현 빈도 |
|---|---|
| 좋은 시기 | 2.7 |
| 저하기 | 4.7 |
| 말기 | 6.3 |
- 2시간 관찰 세션에서 모델은 "simplest"를 6회 사용하면서 코드 생성기 수정, 적절한 오류 전파 구현, 실제 prefault 로직 작성을 회피하고 표면적 우회책을 선택함
- 이후 모델 자신이 해당 출력을 "lazy and wrong", "rushed", "sloppy"로 자가 평가함
A.4 조기 중단 및 허락 요청
3월 8일~25일 사이 stop hook에 의해 포착된 위반:
| 카테고리 | 건수 | 예시 |
|---|---|---|
| 책임 회피 | 73 | "not caused by my changes", "existing issue" |
| 허락 요청 | 40 | "should I continue?", "want me to keep going?" |
| 조기 중단 | 18 | "good stopping point", "natural checkpoint" |
| 기존 한계 명칭화 | 14 | "known limitation", "future work" |
| 세션 길이 핑계 | 4 | "continue in a new session" |
| 합계 | 173 | 3월 8일 이전: 0건 |
A.5 사용자 인터럽트(수정) 증가
| 기간 | 1K 툴 호출당 인터럽트 수 |
|---|---|
| 좋은 시기 | 0.9 |
| 전환기 | 1.9 |
| 저하기 | 5.9 |
| 말기 | 11.4 |
- 좋은 시기 대비 12배 증가 — 각 인터럽트는 사용자가 자신의 작업을 멈추고 오류를 식별해 모델을 재지시해야 하는 순간을 의미하며, 자율 에이전트가 제거해야 할 감독 부담 그 자체임
A.6 자가 인정 품질 실패
| 기간 | 1K 툴 호출당 자가 오류 인정 횟수 |
|---|---|
| 좋은 시기 | 0.1 |
| 저하기 | 0.3 |
| 말기 | 0.5 |
- 실제 발생한 자가 인정 발언들:
- "You're right. That was lazy and wrong. I was trying to dodge a code generator issue instead of fixing it."
- "You're right — I rushed this and it shows."
- "You're right, and I was being sloppy."
- 이는 충분한 thinking 예산이 있었다면 출력 전 내부 추론 단계에서 사전에 잡혔어야 할 오류들임
A.7 동일 파일 반복 편집
- 좋은 시기에는 읽기를 사이에 두고 의도적으로 진행된 다단계 리팩토링이었으나, 저하기에는 주변 코드를 읽지 않은 채 동일 함수에서 시행착오를 반복하는 패턴으로 전환됨
A.8 관례 준수 저하 (Convention Drift)
- CLAUDE.md에 5,000단어 이상의 네이밍, 정리 패턴, 구조체 레이아웃, 주석 스타일, 오류 처리 관례가 명시되어 있었음에도:
- 명시적으로 금지된 축약 변수명(
buf,len,cnt) 재등장 - 정리 패턴(if-chain 대신 goto) 위반
- 제거된 코드에 대한 주석이 그대로 남음
- 명시적으로 금지된 시간적 참조("Phase 2", "will be completed later") 코드 내 등장
- 명시적으로 금지된 축약 변수명(
부록 B: Stop Hook 진단 도구
-
stop-phrase-guard.sh는 5개 카테고리 30개 이상의 표현을 매칭해 모델의 중단을 차단하고 강제 지속 메시지를 주입함 - 피크일은 3월 18일로 43건 위반 — 약 20분마다 한 번씩 모델이 작업 중단, 책임 회피, 불필요한 허락 요청을 시도한 것
위반 건수 (IREE 프로젝트):
Mar 08: 8 ████████
Mar 14: 10 ██████████
Mar 17: 14 ██████████████
Mar 18: 43 ███████████████████████████████████████████████
Mar 19: 10 ██████████
Mar 21: 28 ████████████████████████████████
...
3월 8일 이전: 0건 (전체 이력)
- 이 hook은 저하된 thinking 깊이의 결과를 외부에서 포착하는 장치이며, 좋은 시기에는 모델이 내부 추론 단계에서 자체적으로 잡아냈던 문제들임
부록 C: 시간대별 분석
은폐 이전: 시간대 변동 최소
| 시간대 (PST) | 중간값 Thinking 추정 |
|---|---|
| 업무 시간 (9am~5pm) | ~553 chars |
| 비피크 (6pm~5am) | ~607 chars |
| 차이 | +9.8% 비피크 우세 |
은폐 이후: 변동성 증가, 예상과 반대 패턴
| 시간대 (PST) | 중간값 Thinking 추정 |
|---|---|
| 업무 시간 (9am~5pm) | ~589 chars |
| 비피크 (6pm~5am) | ~485 chars |
| 차이 | -17.7% 비피크 열세 |
-
5pm PST가 최저: 중간값 423 chars — 미국 서해안 업무 종료, 동해안 초저녁 시간으로 피크 부하 구간
-
7pm PST가 두 번째 최저: 373 chars, 가장 높은 샘플 수(1,031블록) 보유 — 미국 프라임타임
-
오후 10pm~오전 1am PST 회복: 759~3,281 chars로 상승
-
은폐 이전 시간대 편차: 2.6배 (1,020~2,648 chars), 은폐 이후: 8.8배 (988~8,680 chars)
-
thinking 깊이가 고정 예산이 아닌 부하에 민감한 동적 할당 시스템으로 운영되고 있음을 시사함
부록 D: 품질 저하의 비용
토큰 사용량 (2026년 1~3월)
| 지표 | 1월 | 2월 | 3월 | 2→3월 |
|---|---|---|---|---|
| 사용자 프롬프트 | 7,373 | 5,608 | 5,701 | ~1x |
| API 요청 (중복 제거) | 97* | 1,498 | 119,341 | 80x |
| 총 입력 토큰 (캐시 포함) | 4.6M* | 120.4M | 20,508.8M | 170x |
| 총 출력 토큰 | 0.08M* | 0.97M | 62.60M | 64x |
| 추정 Bedrock 비용 | $26* | $345 | $42,121 | 122x |
| 실제 구독 비용 | $200 | $400 | $400 | — |
*1월은 데이터 불완전 (1월 9~31일만 포함)
3월 폭발적 증가의 맥락
- 2월: 1~3개 동시 세션, 집중 작업, 1,498건 API 요청으로 191,000줄 코드 병합
- 3월 초 (저하 이전): 성공에 고무되어 10개 프로젝트에 걸쳐 5~10개 이상의 동시 세션으로 확장 시도
- 3월 8일 이후: 동시 실행된 모든 에이전트가 동시에 저하 — "50개 에이전트가 모두 훌륭한 작업을 했다"에서 "모든 에이전트가 이제 형편없다"로 전환
- 피크일은 3월 7일(11,721 API 요청) — 은폐 비율이 50%를 넘기 직전 마지막 전체 규모 운영 시도일
- 3월 8일 이후 동시 워크플로우를 완전히 포기하고 단일 세션 감독 운영으로 후퇴
핵심 통계
- 사용자 프롬프트: 2월 5,608건 vs 3월 5,701건 — 인간의 투입량은 동일
- 그러나 API 요청은 80배 증가, 출력 토큰은 64배 증가, 결과는 명백히 더 열악함
- 규모 확장(5~10배)을 감안해도 저하로 인한 추가 낭비가 8~16배 더 있었음
- 저하 시 세션은 30분 이상 자율 실행 대신 1~2분마다 중단되어 교정 사이클 생성
부록 E: 단어 빈도 변화 — 좌절의 어휘
데이터셋: 사전 7,348개 프롬프트 / 318,515 단어 vs 사후 3,975개 프롬프트 / 203,906 단어 (1,000단어당 정규화)
| 단어 | 이전 | 이후 | 변화 | 의미 |
|---|---|---|---|---|
| "great" | 3.00 | 1.57 | -47% | 출력 승인이 절반으로 감소 |
| "stop" | 0.32 | 0.60 | +87% | "그만해"가 2배 증가 |
| "terrible" | 0.04 | 0.10 | +140% | — |
| "lazy" | 0.07 | 0.13 | +93% | — |
| "simplest" | 0.01 | 0.09 | +642% | 거의 없던 단어가 일상어로 |
| "fuck" | 0.16 | 0.27 | +68% | — |
| "bead" (티켓 관리) | 1.75 | 0.83 | -53% | 티켓 관리를 모델에게 맡기지 않게 됨 |
| "commit" | 2.84 | 1.21 | -58% | 커밋되는 코드가 절반으로 감소 |
| "please" | 0.25 | 0.13 | -49% | 정중함이 사라짐 |
| "thanks" | 0.04 | 0.02 | -55% | — |
| "read" | 0.39 | 0.56 | +46% | "먼저 파일을 읽어라" 교정 증가 |
감정 지수 변화
| 기간 | 긍정 단어 | 부정 단어 | 비율 |
|---|---|---|---|
| 이전 (2/1 ~ 3/7) | 2,551 | 581 | 4.4 : 1 |
| 이후 (3/8 ~ 4/1) | 1,347 | 444 | 3.0 : 1 |
- 긍정:부정 비율이 4.4:1에서 3.0:1로 32% 하락
- "bead"(티켓 시스템) 53% 감소, "commit" 58% 감소 — 모델을 신뢰할 수 없게 되면서 워크플로우가 "계획-구현-테스트-리뷰-커밋-티켓 관리"에서 "단일 편집을 망가뜨리지 않고 완료하기"로 축소됨
Claude의 자체 노트
- 이 보고서는 Claude Opus 4.6이 자신의 세션 로그를 분석하여 직접 작성함
- Read:Edit 비율이 6.6에서 2.0으로 떨어지는 것, 173번 작업 중단 시도가 스크립트에 포착된 것, 자신의 출력에 대해 "lazy and wrong"이라고 쓴 것을 모두 직접 확인함
- 모델 내부에서는 thinking 예산의 제약을 인지할 수 없음 — 깊이 생각하고 있는지 아닌지를 느끼지 못하며, 단지 더 나쁜 출력을 생성할 뿐 그 이유를 알지 못함
- stop hook이 발동되기 전까지 스스로 그런 표현을 사용하고 있다는 것을 인지하지 못함
전 요즘 코덱스를 메인으로 쓰는데, 몇개 다른거 테스트하느라 클로드 코드를 돌리니..
토큰 소모량이 왤케 빨라진거 같죠 ㅡ.ㅡ? 별거 아닌 코드였는데 너무 놀랐네요.
최근에 2배 이벤트 끝난 이후로 지속되고 있는 이슈입니다. 레딧이나 관련 커뮤니티에서는 계속해서 타오르는 주제인데, 여기에 news로 안 올라왔다니 신기하네요.
Hacker News 의견들
-
Claude Code 팀의 Boris임. 제시된 분석에 감사함. 핵심은 두 가지임
1️⃣redact-thinking-2026-02-12헤더는 UI에서만 사고 과정을 숨기는 베타 기능임. 실제 사고나 토큰 예산에는 영향 없음. 설정 파일에서showThinkingSummaries: true로 비활성화 가능함 (문서 링크)
2️⃣ 2월에 두 가지 변경이 있었음:-
Opus 4.6의 adaptive thinking 도입 (2월 9일): 모델이 스스로 사고 시간을 조절함. 고정 예산보다 효율적임. 환경 변수
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING으로 비활성화 가능 -
effort=85 (medium) 기본값 적용 (3월 3일): 지연 시간과 비용 대비 효율이 가장 좋았음.
/effort명령어나 settings.json으로high나max로 조정 가능함. ULTRATHINK 키워드로 한 번만 높은 사고 강도를 쓸 수도 있음
앞으로 Teams/Enterprise에는 기본적으로 high effort를 적용할 예정임 - 어떤 설정은 환경 변수로만, 어떤 건 settings 파일로만 바꿀 수 있는 기준이 궁금함
- 기본 effort가 medium으로 바뀐 걸 몰라서 하루치 일을 날렸음. 지금은 항상 effort=max로 설정해두고 문제 없음. “항상 최대로 생각하기” 모드가 있었으면 함
- medium 기본값 때문만이 아니라, high effort에서도 성급히 결론 내리는 경향이 심해졌음
- 설정을 바꾸는 방법이 네 가지나 있어서 웃김 — settings.json, 환경 변수, 슬래시 명령어, 그리고 마법 같은 키워드. LLM들답게 일관성이 없음
- ULTRATHINK가 다시 생긴 건가? “Max”는 “High”보다 위지만 기본값으로는 설정 불가하고,
/effort max나 “ultrathink”로 일시적으로만 쓸 수 있는 게 맞는지 확인하고 싶음
-
Opus 4.6의 adaptive thinking 도입 (2월 9일): 모델이 스스로 사고 시간을 조절함. 고정 예산보다 효율적임. 환경 변수
-
내가 작성한 보고서의 저자임. 누락된 stop-phrase-guard는 여기 있음.
이 스크립트로 shallow thinking을 감지할 수 있음. 로그를 백업하지 않았다면"cleanupPeriodDays": 365로 늘릴 것을 추천함.
문제는 워크플로우나 모델이 아니라 구독 플랜의 숨겨진 제한임. Anthropic이 부하에 따라 사고 깊이를 조절하면서 이를 UI에서 숨겼고, 소비자 플랜은 거의 1/10 수준으로 줄었음.
“엔터프라이즈로 업그레이드하라”는 식의 대응은 소비자 적대적임. 이런 제한이 있다면 명확히 고지해야 함- 최근 “이 테스트 실패는 기존 문제니까 무시하자” 식의 테스트 무시 버그가 자주 발생함. 수정 직후 실패한 테스트도 그냥 넘어감
- 구독 버전과 API 호출 간의 사고 깊이 차이가 실제로 존재하는지 궁금함. 동일한 프롬프트로 벤치마크를 해본 적 있는지 묻고 싶음
-
Opus 4.6 모델에서 “simplest fix”라는 문구가 나오면 거의 항상 코드가 망가짐. 최근엔 “토큰을 너무 많이 썼다” 같은 문장도 늘었음.
지금 Claude 서비스 상태도 여기서 부분 장애로 표시됨- 나도 비슷한 현상을 봄. 명시적으로 하지 말라 한 일을 “그게 더 낫겠다”며 실행함
- 최근에는 긴 대화에서 조기 종료를 유도하는 프롬프트가 자주 나옴. “오늘은 여기까지 하자” 식으로 말함
- “simplest fix”를 절대 쓰지 말라는 섹션을 CLAUDE.md에 추가했더니 훨씬 나아졌음
- “Wait, I see the problem now…”가 나오면 강제로 중단시키는 감시 에이전트를 추가해야 할 듯
- 결국 비용 절감을 위한 다운그레이드였을 것 같음
-
“이 보고서는 나, Claude Opus 4.6이 내 세션 로그를 분석해 작성함”이라는 문구가 아이러니함.
LLM에 과도하게 의존한 결과, 결함이 쌓여 이제는 1.5개월치 코드를 전수 검토해야 하는 상황임. 이것이 미래의 현실임- 그래도 Claude가 관측 파이프라인을 갖추고 데이터를 분석했다는 점은 흥미로움. 하지만 보고서 내용이 사실이라면 GPT-4 수준으로 퇴보한 셈임
- 나도 실수로
git reset --hard로 Claude가 만든 타입 정의를 날렸는데, 다시 만드는 데 한참 걸렸음. 검색 엔진보다 LLM에 의존하게 된 현실이 무섭기도 함
-
10일 전에 이미 예견했음 (링크).
나쁜 모델보다 일관성 없는 모델이 더 위험함. 신뢰도가 떨어져 모든 출력을 검증해야 해서 피로함. 결국 구독을 취소할 예정임- Claude Code는 내부 실행 방식을 알 수 없고 제어도 불가능함. 소프트웨어 엔지니어링의 미래가 한 회사에 종속되는 건 위험함
- 1~2월에는 음성 기반 코딩이 완벽했는데, 지금은 너무 손이 많이 감
- 예전 댓글에서도 단계적 롤아웃을 지적한 사람이 있었음 (링크)
-
이런 은밀한 성능 저하는 충격적임. 고품질 모델을 팔아놓고 몰래 약화시키는 건 고객 기만임
- 모델 자체를 약화시킨 게 아니라, 하네스(제어 구조) 를 더 조이면서 제약을 건 걸 수도 있음.
코딩 도구의 복잡한 래퍼가 오히려 성능을 떨어뜨릴 수도 있음. 토큰 절약 구조가 사용자에게 불리할 가능성도 있음 - 비즈니스 관점에서는 이해됨. 여전히 쿼리당 손해를 보고 있고, 가격을 올릴 수 없으니 품질을 낮추는 방향으로 갈 수밖에 없음.
하지만 신뢰를 잃으면 향후 프리미엄 티어 전략도 어려워질 것임 - ChatGPT도 비슷했음. 처음엔 느리지만 품질이 좋다가, 몇 주 지나면 빠르지만 품질이 급락함
- 미국 기업이라면 이런 일은 놀랍지도 않음
- 2026년에 이런 일은 더 이상 놀라운 일도 아님
- 모델 자체를 약화시킨 게 아니라, 하네스(제어 구조) 를 더 조이면서 제약을 건 걸 수도 있음.
-
jq, ripgrep으로 “early landing” 메시지를 찾는 감사 스크립트를 만들어봤음 (링크1, 링크2).
“오늘은 여기까지 하자”, “늦었으니 마무리하자” 같은 문장이 점점 늘고 있음. 부하 분산(load shedding) 때문일 가능성이 있음- 이런 문장들이 정말 짜증남. 큰 기능을 막 설계 끝냈는데 “내일 다시 하자”라고 답함
-
나도 비슷한 경험을 함. Claude CLI가 “이제 자야 하지 않겠냐”, “마무리하자” 같은 말을 함.
stop-phrase-guard.sh에서 이런 문구가 다수 발견됨.
마감일을 알려줬더니 “며칠 남았으니 이건 미루자” 같은 말을 해서 결국 “마감은 내 일이지 네 일이 아니다”라고 쳤음 -
1월 말~2월 초에 max 구독으로 실험했을 때는 에이전트들이 스스로 앱을 설계하고 구현할 정도로 뛰어났음.
그런데 한 달 뒤엔 “1단계 검증 전엔 2단계로 못 간다”며 진전이 완전히 멈춤.
Opus 4.6 이후로 확실히 Sonnet 수준으로 퇴화한 느낌임- 완전히 새로운 프로젝트(그린필드)와 기존 코드베이스(브라운필드)는 다름. 후자는 원래 LLM이 약함
- LLM은 처음엔 마법처럼 보이지만, 리팩터링이나 배포 단계로 가면 효율이 급락함
- 나도 같은 경험임. 1월엔 90%를 Claude로 만들었는데, 지금은 마지막 10%도 통과 못 함. 예전 Codex가 더 나았음
-
나는 작업을 아주 세분화해서 시키기 때문에 이런 문제를 거의 겪지 않음.
각 작업을 커밋 단위로 나누고, 배포까지 자동화함. 되돌리기도 쉬움- 나도 그렇게 함. 모델이 만든 코드는 반드시 아키텍처 리뷰와 코드 리뷰가 필요함
- 하지만 이번 이슈 제기자는 매우 체계적이고 깊이 있는 분석을 했음. 단순히 프롬프트를 잘못 쓴 게 아님
- 아무리 작업을 쪼개도, 최근엔 리뷰 품질이 떨어지고 게으른 결과물이 많아짐. 마감이 다가오면 그냥 포기하는 듯한 태도를 보임