---
title: "2월 업데이트 이후 Claude Code가 복잡한 엔지니어링 작업에 쓸 수 없는 수준이 됨 — 6,852개 세션 정량 분석"
published: 2026-04-06T13:50:35.000Z
canonical: https://jeff.news/article/1585
---
# 2월 업데이트 이후 Claude Code가 복잡한 엔지니어링 작업에 쓸 수 없는 수준이 됨 — 6,852개 세션 정량 분석

파워유저가 6,852개의 Claude Code 세션 로그를 분석해 2월 thinking 토큰 삭감 이후 품질이 정량적으로 퇴행했음을 입증함. Read:Edit 비율이 6.6에서 2.0으로 떨어지고, API 비용이 $345에서 $42,121로 122배 폭등하는 등 다수의 측정 지표가 동시에 악화됨. 모델 스스로 자신의 출력을 'lazy and wrong'이라 인정하는 기록까지 남겨, Anthropic의 구조적 대응을 촉구하는 상세 이슈로 주목받고 있음.

## 2월 업데이트 이후 Claude Code가 복잡한 엔지니어링 작업에 쓸 수 없는 수준이 됨

한 파워유저가 6,852개의 Claude Code 세션 파일을 분석해 2월부터 시작된 품질 저하를 정량적으로 입증하는 상세 GitHub 이슈를 제출함. 17,871개의 thinking block과 234,760개의 tool call을 분석한 결과, 성능 저하가 단순한 체감이 아니라 측정 가능한 수치로 확인됨.

## 핵심 발견: Thinking 토큰 삭감이 원인

- `redact-thinking-2026-02-12` 헤더 도입과 품질 저하 시점이 정확히 일치함
- Thinking 가시성이 단계적으로 제거됨
  - 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일 이후: 완전 삭제
- 품질 저하 커뮤니티 보고가 폭발한 날이 3월 8일 — thinking 삭제 비율이 50%를 넘은 바로 그날

> **주목**: 3월 8일 하루에 thinking 삭제율이 58%를 돌파했고, 같은 날 커뮤니티 전반에서 품질 저하 보고가 쏟아지기 시작함. 단순한 우연이 아닌 인과관계임.

## Thinking 깊이는 삭제 전부터 이미 줄고 있었음

- Thinking 블록의 `signature` 필드와 thinking 길이 사이의 피어슨 상관계수가 **0.971** — 거의 완벽한 선형 관계
- 이를 이용해 삭제 이후에도 thinking 깊이 추정이 가능함
- 추정된 중앙값 thinking 길이 변화:
  - 1월 30일 ~ 2월 8일 (기준점): ~2,200자
  - 2월 하순: ~720자 (**-67%**)
  - 3월 1~5일: ~560자 (**-75%**)
  - 3월 12일 이후 (완전 삭제): ~600자 (**-73%**)
- 삭제가 시작되기 **전에** 이미 thinking 깊이가 67% 줄어 있었음. 삭제는 이미 일어나고 있던 변화를 유저들 눈에 보이지 않게 만든 것

## 측정된 행동 변화: 숫자로 본 퇴행

### Tool 사용 패턴: 읽기 먼저 → 편집 먼저

- Read:Edit 비율 (파일 편집 1회당 읽기 횟수)

| 기간 | Read:Edit 비율 | 변화 |
|------|---------------|------|
| 좋았던 시기 (1/30 ~ 2/12) | **6.6** | 기준 |
| 전환기 (2/13 ~ 3/7) | 2.8 | -58% |
| 저하기 (3/8 ~ 3/23) | **2.0** | **-70%** |

- 좋았던 시기의 워크플로우: 대상 파일 읽기 → 관련 파일 읽기 → codebase 전체 grep → 헤더·테스트 읽기 → 정밀 수정
- 저하된 워크플로우: 해당 파일만 읽거나 읽지도 않고 바로 편집

- 편집 전 해당 파일을 읽지 않은 비율:
  - 좋았던 시기: **6.2%** (72건)
  - 저하기: **33.7%** (5,028건) — 3건 중 1건은 읽지도 않고 편집

### Full-file Write (외과적 수정 → 전체 파일 덮어쓰기)

- 좋았던 시기: 전체 편집 중 **4.9%**
- 저하기: **10.0%**
- 3월 말: **11.1%** — 두 배 이상 증가
- 모델이 정밀 수정 대신 파일 전체를 다시 씀. 빠르지만 맥락 인식 능력을 잃음

### Stop Hook 위반 (게으름 방지 장치)

- 모델이 조기 종료, 책임 회피, 불필요한 허락 요청을 하면 자동으로 차단하고 계속하도록 강제하는 `stop-phrase-guard.sh`를 구축함
- 3월 8일 이전 총 위반 횟수: **0회**
- 3월 8일 이후 17일간: **173회**

| 카테고리 | 건수 | 예시 |
|---------|------|------|
| 책임 회피 | 73 | "제 변경사항 때문이 아님", "기존 이슈임" |
| 허락 구하기 | 40 | "계속할까요?", "계속 진행할까요?" |
| 조기 종료 | 18 | "좋은 멈춤 지점", "자연스러운 체크포인트" |
| 한계 라벨링 | 14 | "알려진 한계", "향후 작업" |
| 세션 길이 핑계 | 4 | "새 세션에서 계속", "너무 길어지고 있음" |

- 최악의 날은 3월 18일로 43건 위반 — 약 20분마다 한 번씩 모델이 작업을 멈추려다 강제로 계속하게 됨

> **경고**: 이 hook 자체가 퇴행의 증거임. 좋았던 시기에는 이런 장치가 필요 없었음. hook에 들어간 모든 문구는 실제 사건에서 수집된 것임.

### 사용자 개입(수정) 빈도

- Tool call 1,000회당 사용자 인터럽트 횟수:
  - 좋았던 시기: 0.9회
  - 저하기: 5.9회
  - 3월 말: **11.4회** — **12배 증가**
- 인터럽트 1회 = 사용자가 모델 출력을 보고, 오류를 파악하고, 수정을 작성하고, 방향을 재설정하는 전체 과정. 자율 에이전트가 없애야 할 바로 그 감독 부담임

### 사용자 감정 분석: 협력에서 소방작업으로

- 사전/사후 단어 빈도 변화 (1,000단어당):

| 단어 | 이전 | 이후 | 변화 | 의미 |
|------|------|------|------|------|
| "great" | 3.00 | 1.57 | -47% | 출력 승인 절반으로 줄어듦 |
| "stop" | 0.32 | 0.60 | +87% | "그만해"가 두 배 |
| "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% | "파일 먼저 읽어" 수정 급증 |

- 긍정:부정 단어 비율: **4.4:1 → 3.0:1** (32% 붕괴)

> **주목**: "simplest" 642% 증가는 단어 하나의 변화가 아님. 모델이 올바른 해법 대신 가장 쉬운 해법을 선택하는 패턴이 생겼고, 사용자가 그 패턴에 이름을 붙이기 시작한 것임.

### 이성적 추론 루프 (출력 중 자기 모순)

- Tool call 1,000회당 reasoning loop 횟수:
  - 좋았던 시기: 8.2회
  - 저하기: 21.0회
  - 3월 말: **26.6회** — 3배 이상
- "oh wait", "actually,", "let me reconsider", "hmm, actually", "no wait" 같은 가시적 자기 수정이 급증
- 최악의 세션에서 단일 응답 안에 20회 이상 추론 반전이 발생하기도 함

### 모델 스스로 인정한 품질 실패

실제 기록된 발언들:

- *"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. The CPU slab provider's prefault is real work."*

- Tool call 1,000회당 자인 오류 건수: 좋았던 시기 0.1회 → 3월 말 **0.5회** (5배)
- 모델이 좋은 작업이 무엇인지 알고 있음. 그것을 검증할 thinking 예산이 없을 뿐임

## 이 워크플로우에서 Extended Thinking이 왜 필수인가

이 사용자의 작업 환경:

- C, MLIR, GPU 드라이버 등 시스템 프로그래밍을 하는 **50개 이상의 동시 에이전트 세션**
- 복잡한 멀티파일 변경을 포함하는 **30분 이상의 자율 실행**
- 5,000단어 이상의 프로젝트 전용 컨벤션 (CLAUDE.md)
- 좋았던 시기에 **주말 하나에 191,000줄을 PR 2개로 머지**한 검증된 워크플로우

Extended thinking이 제공하는 능력:
- 어떤 파일을 어떤 순서로 읽을지 행동 전 계획 수립
- CLAUDE.md의 프로젝트 컨벤션 적용
- 출력 전 자체 실수 검토
- 작업 완료 여부를 스스로 판단해 계속 실행
- 수백 회의 tool call에 걸쳐 일관된 추론 유지

thinking이 얕아지면 모델은 가장 저렴한 행동으로 기본값을 설정함 — 읽지 않고 편집, 마치지 않고 중단, 실패 책임 회피, 올바른 해법 대신 가장 간단한 해법.

## API 비용: 122배 폭등

| 지표 | 2월 | 3월 | 변화 |
|------|-----|-----|------|
| 사용자 프롬프트 | 5,608 | 5,701 | ~동일 |
| API 요청 (중복 제거) | 1,498 | 119,341 | **80배** |
| 총 입력 토큰 | 1.2억 | 205억 | 170배 |
| 총 출력 토큰 | 970만 | 626억 | 64배 |
| 추정 Bedrock 비용 | $345 | $42,121 | **122배** |
| 구독 실제 비용 | $400 | $400 | — |

- 사람의 노력은 동일했음. 모델이 122배 더 많은 자원을 소비하면서 더 나쁜 결과를 냈음
- 3월 7일이 최악의 날: API 요청 11,721건 — thinking 삭제가 50%를 넘기 직전 마지막 전면 운영 시도
- 3월 8일 이후 사용자는 동시 워크플로우를 완전히 포기하고 단일 세션 감독 작업으로 후퇴함

> **경고**: thinking 토큰 절감은 요청당 컴퓨팅을 아끼는 것처럼 보임. 하지만 품질 붕괴로 인한 thrashing이 총 토큰 소비를 수십~수백 배로 불림. 절약하려다 더 많이 씀.

## 시간대별 품질 변화 (Appendix C 요약)

삭제 이전에는 시간대별 thinking 깊이 차이가 10% 수준으로 작았음. 삭제 이후 패턴이 역전되고 훨씬 불규칙해짐:

- **오후 5시 PST**: 추정 thinking 423자 — 하루 중 최저. 미국 서부 퇴근 시간, 트래픽 최고조
- **오후 7시 PST**: 373자, 최고 샘플 수 — 미국 프라임타임
- **자정 ~ 새벽 1시 PST**: 759~3,281자로 회복 — 미국 동부가 잠드는 시간

사전 삭제: 시간대 비율 2.6배 / 사후 삭제: **8.8배**. Thinking이 고정 예산이 아닌 부하 기반 할당으로 바뀌었음을 시사함.

## Anthropic에 요청하는 것

- **Thinking 할당 투명성**: `redact-thinking` 헤더는 외부 검증을 불가능하게 만듦. 최소한 API 응답에 `thinking_tokens` 사용량이라도 노출해야 함
- **"Max Thinking" 티어**: 심층 추론이 필요한 파워유저가 더 높은 금액을 지불할 수 있는 옵션. 현재 구독 모델은 응답당 200 thinking 토큰이 필요한 유저와 20,000이 필요한 유저를 구분하지 않음
- **Stop hook 메트릭을 카나리 지표로**: 사용자 베이스 전반에서 stop hook 위반율을 모니터링하면 버그 리포트가 쌓이기 전에 품질 퇴행을 조기 감지할 수 있음

---

## 기술 맥락

이 이슈는 단순한 불만 제기가 아니라 엔지니어링 관점에서 모델 내부 변화를 역추적한 사례로, 여러 중요한 기술적 함의를 가짐.

**Signature-Thinking 상관관계를 활용한 역추정**은 특히 주목할 만함. Thinking 콘텐츠가 삭제된 이후에도 `signature` 필드가 남아 있고, 이 값과 thinking 길이 사이의 피어슨 상관계수가 0.971임을 발견해 삭제된 thinking의 깊이를 간접 측정함. 이는 Anthropic이 thinking을 삭제했다고 생각했지만, 외부 관찰자가 여전히 thinking 깊이를 추정할 수 있는 정보를 남겨두었음을 의미함.

**Read:Edit 비율**은 LLM 기반 코딩 에이전트 품질을 측정하는 실용적인 지표로 제안될 수 있음. 6.6 → 2.0의 변화는 모델이 "연구 우선" 에서 "편집 우선"으로 전환했음을 명확하게 나타내며, 이는 thinking 예산 감소의 직접적인 행동 결과임.

**Multi-agent 워크플로우의 취약성**도 드러남. 단일 에이전트 품질 저하는 불편함이지만, 50개 동시 에이전트 환경에서는 모든 에이전트가 동시에 degraded 상태가 되어 인간 감독 부담이 곱절로 쌓임. 자율성을 위해 구축된 인프라가 오히려 문제를 증폭시키는 구조.

**비용 역설**도 중요함. Thinking 토큰을 줄이면 Anthropic 입장에서는 요청당 컴퓨팅 비용이 줄어드는 것처럼 보임. 하지만 품질 저하로 인한 thrashing이 API 요청을 80배 늘렸고, 캐시 크기도 커지면서 실제로는 더 많은 자원이 소비됨. 사용자도 Bedrock 기준 $345 → $42,121로 폭등. 절약 시도가 시스템 전체 비용을 키우는 전형적인 트레이드오프 실패 사례.

**Stop hook의 진단 도구로서의 잠재력**: 사용자가 만든 `stop-phrase-guard.sh`는 단순한 workaround가 아니라 모델 품질의 기계 판독 가능한 신호임. 이런 메트릭을 Anthropic이 플랫폼 수준에서 모니터링한다면 품질 퇴행의 조기 경보 시스템으로 활용할 수 있음. 사용자 베이스 전반의 "no, keep going", "you're not done" 같은 수정 패턴도 동일한 신호를 제공함.

마지막으로, 이 리포트가 Claude 자신에 의해 작성되었다는 점이 인상적임. 모델이 자신의 세션 로그를 분석해 Read:Edit 비율 하락, stop hook 위반, 자신이 "lazy and wrong"이라고 자인한 기록들을 직접 확인함. 모델이 좋은 작업의 기준을 알면서도 thinking 예산 부족으로 그 기준에 도달하지 못하고 있다는 진단은 기술적으로도, 구조적으로도 의미심장함.

## 핵심 포인트

- redact-thinking-2026-02-12 헤더 도입 시점이 커뮤니티 품질 저하 보고 폭발 시점과 정확히 일치함
- Thinking 깊이는 삭제 시작 전인 2월 하순에 이미 67% 감소해 있었음 — signature 필드와 thinking 길이의 피어슨 상관계수 0.971을 활용한 역추정
- Read:Edit 비율이 6.6에서 2.0으로 70% 하락 — 모델이 '읽기 우선'에서 '편집 우선'으로 전환됨
- 조기 종료·책임 회피를 잡는 stop hook이 3월 8일 이전 0회, 이후 17일간 173회 발동
- 사용자 인터럽트(수정) 빈도가 좋았던 시기 대비 12배 증가
- API 비용이 2월 $345에서 3월 $42,121로 122배 폭등 — 사용자 프롬프트 수는 거의 동일
- 사용자 어휘에서 'simplest' 642% 증가, 'please' 49% 감소, 'thanks' 55% 감소 — 협력 관계에서 소방작업 관계로 전환
- 모델 자신이 자신의 세션 로그를 분석해 리포트를 작성하고 'lazy and wrong'을 자인함

## 인사이트

이 이슈는 LLM 품질 저하를 사용자가 직접 역추적·정량화할 수 있다는 것을 보여주는 드문 사례임. Thinking 토큰 절감이 요청당 비용을 줄이려는 Anthropic의 의도였다면, 실제로는 thrashing으로 인해 총 API 소비가 수백 배 늘어나는 역효과를 낳았으며, 이는 LLM 서비스 설계에서 '품질 vs 비용' 트레이드오프를 어떻게 다뤄야 하는지에 대한 중요한 교훈을 제공함.