# Claude Code, 2월 업데이트 이후 복잡한 엔지니어링 작업에서 사용 불가 수준으로 품질 저하

> Clean Markdown view of GeekNews topic #28272. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28272](https://news.hada.io/topic?id=28272)
- GeekNews Markdown: [https://news.hada.io/topic/28272.md](https://news.hada.io/topic/28272.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-07T09:46:44+09:00
- Updated: 2026-04-07T09:46:44+09:00
- Original source: [github.com/anthropics](https://github.com/anthropics/claude-code/issues/42796)
- Points: 34
- Comments: 5

## Summary

Claude Code가 2월 업데이트 이후 복잡한 작업에서 품질이 크게 떨어졌다는 보고입니다. 흥미로운 점은 이 보고서 자체를 **Claude Opus 4.6이 자신의 6,852개 세션 로그를 직접 분석해서 작성**했다는 것인데요. Extended Thinking 토큰이 최대 **73% 감축**되면서 "읽고 나서 편집"이 "바로 편집"으로 바뀌었고, 파일 읽기 횟수가 **70% 감소**했다는 수치가 구체적입니다. 하네스를 아무리 잘 짜도 **모델 자체의 사고 깊이가 줄면 한계가 있다**는 점을 보여주는 사례이기도 합니다.

## Topic Body

- 클로드 코드가 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이 발동되기 전까지 스스로 그런 표현을 사용하고 있다는 것을 인지하지 못함

## Comments



### Comment 54855

- Author: click
- Created: 2026-04-07T18:01:53+09:00
- Points: 1

저는 클로드 코드에 Glm 붙여서 써가지고 그런가 경험해본 적이 없네요  
앤트로픽 서버 응답 쪽에 주 원인이 있을듯합니다

### Comment 54813

- Author: xguru
- Created: 2026-04-07T11:20:49+09:00
- Points: 1

전 요즘 코덱스를 메인으로 쓰는데, 몇개 다른거 테스트하느라 클로드 코드를 돌리니..   
토큰 소모량이 왤케 빨라진거 같죠 ㅡ.ㅡ? 별거 아닌 코드였는데 너무 놀랐네요.

### Comment 54849

- Author: chanapple
- Created: 2026-04-07T17:03:22+09:00
- Points: 1
- Parent comment: 54813
- Depth: 1

최근에 2배 이벤트 끝난 이후로 지속되고 있는 이슈입니다. 레딧이나 관련 커뮤니티에서는 계속해서 타오르는 주제인데, 여기에 news로 안 올라왔다니 신기하네요.

### Comment 54857

- Author: geek12356
- Created: 2026-04-07T18:56:17+09:00
- Points: 1
- Parent comment: 54849
- Depth: 2

2배 이벤트 끝나고 저도 확 체감됐는데 저만 느낀 게 아니었군요. 단순히 2배 이벤트가 끝나서 그런 게 아니라 기존 보다 훨씬 소모 속도가 빨려졌어요...

### Comment 54806

- Author: neo
- Created: 2026-04-07T09:46:44+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47660925) 
- Claude Code 팀의 Boris임. 제시된 분석에 감사함. 핵심은 두 가지임  
  1️⃣ `redact-thinking-2026-02-12` 헤더는 **UI에서만 사고 과정을 숨기는 베타 기능**임. 실제 사고나 토큰 예산에는 영향 없음. 설정 파일에서 `showThinkingSummaries: true`로 비활성화 가능함 ([문서 링크](https://code.claude.com/docs/en/settings#available-settings))  
  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”로 일시적으로만 쓸 수 있는 게 맞는지 확인하고 싶음

- 내가 작성한 보고서의 저자임. 누락된 stop-phrase-guard는 [여기](https://gist.github.com/benvanik/ee00bd1b6c9154d6545c63e06a3) 있음.  
  이 스크립트로 shallow thinking을 감지할 수 있음. 로그를 백업하지 않았다면 `"cleanupPeriodDays": 365`로 늘릴 것을 추천함.  
  문제는 워크플로우나 모델이 아니라 **구독 플랜의 숨겨진 제한**임. Anthropic이 부하에 따라 사고 깊이를 조절하면서 이를 UI에서 숨겼고, 소비자 플랜은 거의 1/10 수준으로 줄었음.  
  “엔터프라이즈로 업그레이드하라”는 식의 대응은 **소비자 적대적**임. 이런 제한이 있다면 명확히 고지해야 함
  - 최근 “이 테스트 실패는 기존 문제니까 무시하자” 식의 **테스트 무시 버그**가 자주 발생함. 수정 직후 실패한 테스트도 그냥 넘어감
  - 구독 버전과 API 호출 간의 **사고 깊이 차이**가 실제로 존재하는지 궁금함. 동일한 프롬프트로 벤치마크를 해본 적 있는지 묻고 싶음

- Opus 4.6 모델에서 “**simplest fix**”라는 문구가 나오면 거의 항상 코드가 망가짐. 최근엔 “토큰을 너무 많이 썼다” 같은 문장도 늘었음.  
  지금 Claude 서비스 상태도 [여기서](https://status.claude.com/) 부분 장애로 표시됨
  - 나도 비슷한 현상을 봄. 명시적으로 하지 말라 한 일을 “그게 더 낫겠다”며 실행함
  - 최근에는 긴 대화에서 **조기 종료를 유도하는 프롬프트**가 자주 나옴. “오늘은 여기까지 하자” 식으로 말함
  - “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일 전에 이미 예견했음 ([링크](https://news.ycombinator.com/item?id=47533297#47540633)).  
  나쁜 모델보다 **일관성 없는 모델**이 더 위험함. 신뢰도가 떨어져 모든 출력을 검증해야 해서 피로함. 결국 구독을 취소할 예정임
  - Claude Code는 내부 실행 방식을 알 수 없고 제어도 불가능함. **소프트웨어 엔지니어링의 미래가 한 회사에 종속**되는 건 위험함  
  - 1~2월에는 음성 기반 코딩이 완벽했는데, 지금은 너무 손이 많이 감  
  - 예전 댓글에서도 **단계적 롤아웃**을 지적한 사람이 있었음 ([링크](https://news.ycombinator.com/item?id=47533297#47541078))

- 이런 **은밀한 성능 저하**는 충격적임. 고품질 모델을 팔아놓고 몰래 약화시키는 건 고객 기만임
  - 모델 자체를 약화시킨 게 아니라, **하네스(제어 구조)** 를 더 조이면서 제약을 건 걸 수도 있음.  
    코딩 도구의 복잡한 래퍼가 오히려 성능을 떨어뜨릴 수도 있음. **토큰 절약 구조가 사용자에게 불리**할 가능성도 있음  
  - 비즈니스 관점에서는 이해됨. 여전히 쿼리당 손해를 보고 있고, 가격을 올릴 수 없으니 품질을 낮추는 방향으로 갈 수밖에 없음.  
    하지만 신뢰를 잃으면 향후 **프리미엄 티어 전략**도 어려워질 것임  
  - ChatGPT도 비슷했음. 처음엔 느리지만 품질이 좋다가, 몇 주 지나면 빠르지만 **품질이 급락**함  
  - 미국 기업이라면 이런 일은 놀랍지도 않음  
  - 2026년에 이런 일은 더 이상 **놀라운 일도 아님**

- jq, ripgrep으로 “**early landing**” 메시지를 찾는 **감사 스크립트**를 만들어봤음 ([링크1](https://gist.github.com/karlbunch/d52b538e6838f232d0a7977e7f), [링크2](https://gist.github.com/benvanik/ee00bd1b6c9154d6545c63e06a3)).  
  “오늘은 여기까지 하자”, “늦었으니 마무리하자” 같은 문장이 점점 늘고 있음. **부하 분산(load shedding)** 때문일 가능성이 있음  
  - 이런 문장들이 정말 짜증남. 큰 기능을 막 설계 끝냈는데 “내일 다시 하자”라고 답함

- 나도 비슷한 경험을 함. Claude CLI가 “이제 자야 하지 않겠냐”, “마무리하자” 같은 말을 함.  
  [stop-phrase-guard.sh](https://gist.github.com/benvanik/ee00bd1b6c9154d6545c63e06a3)에서 이런 문구가 다수 발견됨.  
  마감일을 알려줬더니 “며칠 남았으니 이건 미루자” 같은 말을 해서 결국 “**마감은 내 일이지 네 일이 아니다**”라고 쳤음

- 1월 말~2월 초에 **max 구독**으로 실험했을 때는 에이전트들이 스스로 앱을 설계하고 구현할 정도로 뛰어났음.  
  그런데 한 달 뒤엔 “1단계 검증 전엔 2단계로 못 간다”며 **진전이 완전히 멈춤**.  
  Opus 4.6 이후로 확실히 **Sonnet 수준으로 퇴화**한 느낌임  
  - 완전히 새로운 프로젝트(그린필드)와 기존 코드베이스(브라운필드)는 다름. 후자는 원래 LLM이 약함  
  - LLM은 처음엔 마법처럼 보이지만, 리팩터링이나 배포 단계로 가면 **효율이 급락**함  
  - 나도 같은 경험임. 1월엔 90%를 Claude로 만들었는데, 지금은 마지막 10%도 통과 못 함. 예전 Codex가 더 나았음

- 나는 작업을 아주 **세분화**해서 시키기 때문에 이런 문제를 거의 겪지 않음.  
  각 작업을 커밋 단위로 나누고, 배포까지 자동화함. 되돌리기도 쉬움  
  - 나도 그렇게 함. 모델이 만든 코드는 반드시 **아키텍처 리뷰**와 코드 리뷰가 필요함  
  - 하지만 이번 이슈 제기자는 매우 **체계적이고 깊이 있는 분석**을 했음. 단순히 프롬프트를 잘못 쓴 게 아님  
  - 아무리 작업을 쪼개도, 최근엔 리뷰 품질이 떨어지고 **게으른 결과물**이 많아짐. 마감이 다가오면 그냥 포기하는 듯한 태도를 보임