Claude Code는 2월 업데이트로 복잡한 엔지니어링 작업에 사용할 수 없다

^{source GitHub 이슈, 해커뉴스}

깃헙 이슈랑 해커뉴스에서 불타고 있는 주제에요.

댓글이 460개가 넘었네요 ㄷㄷㄷ

Claude에게 요청한 내용

• Claude가 복잡한 엔지니어링 작업을 다시 믿고 맡길 수 있는 수준으로 동작하길 바랐음

Claude가 실제로 한 일

• 지시를 무시함

• “가장 단순한 수정”이라고 말하지만 실제로는 틀린 해결책을 냄

• 요청한 방향과 반대로 움직임

• 지시를 지키지 않았는데도 완료했다고 주장함

기대한 동작

• Claude가 1월에 하던 방식처럼 다시 동작해야 함

권한 모드

• Accept Edits가 켜져 있었음(auto-accepting changes)

재현 가능 여부

• 예, 같은 프롬프트면 매번 재현됨

Claude 모델

• Opus

영향도

• 높음, 원치 않는 변경이 크게 발생함

Claude Code 버전

• 여러 버전 전반

플랫폼

• Anthropic API

추가 맥락

• 작업 환경은 일관되고 복잡도가 높음

• 왜 이런 일이 생기는지 보려고 몇 달치 로그를 데이터 마이닝했음

• 핵심은 2월부터 복잡한 엔지니어링 작업 성능이 눈에 띄게 떨어졌다는 점임

• 공개적으로 알려진 우회책은 이미 다 시도했음

• Claude가 그동안 큰 도움이 됐기 때문에, Anthropic이 이 문제를 다뤄주길 바라는 마음으로 이 리포트를 남김

시니어 엔지니어링 워크플로에서 Extended Thinking은 사실상 필수임

• 이 분석은 Claude가 1월부터 3월까지의 세션 로그 데이터를 직접 분석해서 만든 문서임

요약

• 6,852개의 Claude Code 세션 파일에서 thinking 블록 17,871개와 tool call 234,760개를 정량 분석한 결과, thinking 내용 redaction 롤아웃(redact-thinking-2026-02-12)이 복잡하고 긴 엔지니어링 워크플로의 품질 저하와 정확히 맞물려 보임

• 데이터상 extended thinking token은 있으면 좋은 옵션이 아니라, 멀티스텝 리서치, 컨벤션 준수, 신중한 코드 수정에 구조적으로 필요한 자원에 가까움

• thinking depth가 줄어들면 tool 사용 패턴이 research-first에서 edit-first로 이동했고, 그 결과 사용자들이 보고한 품질 문제로 이어졌다는 얘기임

• 이 리포트는 어떤 워크플로가 특히 크게 영향을 받았는지, 왜 그런지 Anthropic이 이해하는 데 도움을 주려는 목적임

1. Thinking Redaction 타임라인이 품질 저하 시점과 정확히 맞물림

• 세션 JSONL 파일의 thinking block을 분석한 결과는 아래와 같음

• 품질 저하 보고가 독립적으로 올라온 날짜도 3월 8일이었고, 바로 그날 redacted thinking block 비중이 50%를 넘겼음

• 1.5% → 25% → 58% → 100%로 1주일 안에 올라간 패턴은 staged deployment와 잘 맞음

2. Redaction 전부터 Thinking Depth는 이미 줄고 있었음

• thinking block의 signature 필드는 thinking content 길이와 0.971 Pearson correlation을 보였음

• content와 signature가 둘 다 있는 7,146개 샘플로 상관관계를 확인했고, 이걸 바탕으로 redaction 이후에도 thinking depth를 추정할 수 있었음

• thinking depth는 redaction이 시작되기 전인 2월 후반에 이미 약 67% 줄어 있었음

• 3월 초 redaction rollout은 이 변화를 사용자 눈에서 안 보이게 만든 셈임

3. 행동 영향: 품질 지표에서도 그대로 잡힘

• 아래 지표는 thinking 분석을 하기 전에, 18,000개가 넘는 사용자 프롬프트에서 독립적으로 계산한 값임

• stop-phrase-guard.sh라는 stop hook을 만들어 ownership 회피, 조기 종료, 불필요한 permission 요청을 잡도록 했음

• 이 hook은 3월 8일 이후 17일 동안 173번 발동했고, 그 전에는 한 번도 발동하지 않았음

4. Tool 사용 패턴 변화: Research-First에서 Edit-First로 이동함

• 234,760번의 tool invocation을 보면, 모델이 코드를 읽고 수정하던 흐름에서 읽지 않고 바로 고치는 흐름으로 바뀌었음

Read:Edit 비율(파일 수정 전에 파일을 얼마나 읽었는지)

• 모델은 edit 1회당 6.6회 읽기에서 2.0회 읽기로 내려갔고, 수정 전에 조사하는 양이 70% 줄었음

• 좋던 시기에는 대상 파일, 관련 파일, 코드베이스 사용처, 헤더, 테스트까지 읽은 뒤 정밀하게 수정했음

• 망가진 시기에는 바로 눈앞 파일만 보고 수정하는 경우가 많았고, 주변 맥락 확인이 빠졌음

주간 추세

Week          Read:Edit  Research:Mutation
──────────────────────────────────────────
Jan 26          21.8        30.0
Feb 02           6.3         8.1
Feb 09           5.2         7.1
Feb 16           2.8         4.1
Feb 23           3.2         4.5
Mar 02           2.5         3.7
Mar 09           2.2         3.3
Mar 16           1.7         2.1    ← lowest
Mar 23           2.0         3.0
Mar 30           1.6         2.6

• 조사량 하락은 2월 중순부터 시작됐고, 이 시점은 estimated thinking depth가 67% 줄어든 시기와 겹침

Write vs Edit(정밀 수정 능력)

• 전체 파일을 다시 쓰는 Write 사용률이 2배 넘게 늘었음

• 정밀하게 조금 고치기보다 파일 전체를 갈아엎는 쪽으로 기울었고, 그만큼 정밀도와 맥락 보존이 떨어졌음

5. 왜 Extended Thinking이 이런 워크플로에서 중요한가

• 영향받은 워크플로는 아래처럼 복잡도가 높음

• 50개가 넘는 동시 agent 세션에서 systems programming(C, MLIR, GPU driver)을 돌림

• 30분 이상 자율 실행하면서 여러 파일을 복합적으로 바꿈

• 5,000단어가 넘는 CLAUDE.md 같은 프로젝트별 규칙이 많음

• 코드 리뷰, bead/ticket 관리, 반복 디버깅까지 같이 처리함

• 좋던 시기에는 주말 이틀 동안 두 개 PR에 191,000줄을 merge했음

• extended thinking은 모델이 아래 일을 해내게 하는 핵심 메커니즘으로 보임

• 행동 전에 다단계 접근을 계획함(어떤 파일을 어떤 순서로 읽을지)

• CLAUDE.md의 프로젝트별 규칙을 떠올리고 적용함

• 출력 전에 자기 실수를 스스로 잡아냄

• 계속 작업할지 멈출지 판단함(세션 관리)

• 수백 번의 tool call 사이에서도 추론 흐름을 유지함

• thinking이 얕아지면 모델은 가장 값싼 행동으로 바로 떨어짐

• 읽지 않고 수정함

• 끝내지 않았는데 멈춤

• 실패 책임을 회피함

• 맞는 해법보다 가장 쉬운 해법을 고름

• 관측된 증상이 정확히 이 패턴과 맞아떨어짐

6. 도움이 될 만한 것

• thinking allocation에 대한 투명성

  • thinking token이 줄거나 cap이 걸린다면, 깊은 추론에 의존하는 사용자는 그 사실을 알아야 함

  • 지금은 redact-thinking 헤더 때문에 외부에서 검증이 거의 불가능함

• “max thinking” tier

  • 복잡한 엔지니어링 워크플로를 돌리는 사용자는 깊은 thinking을 보장받을 수 있다면 훨씬 더 비싸게 지불할 의향이 있음

  • 지금 구독 모델은 응답당 thinking token 200개면 되는 사용자와 20,000개가 필요한 사용자를 구분하지 않음

• API 응답에 thinking token 메트릭 노출

  • thinking content를 숨기더라도 usage 응답에 thinking_tokens만 드러나면 사용자가 필요한 추론 깊이가 실제로 배정됐는지 모니터링할 수 있음

• power user 기반 canary metric

  • stop hook 위반율 0 → 10/day는 기계적으로 읽을 수 있는 품질 신호임

  • 이런 지표를 사용자 집단 전체에서 모니터링하면 품질 저하를 더 빨리 감지할 수 있음

방법론

• 데이터 소스: ~/.claude/projects/ 아래 6,852개의 Claude Code 세션 JSONL 파일, 대상 프로젝트는 네 개(iree-loom, iree-amdgpu, iree-remoting, bureau)

• 분석한 thinking block: 17,871개(내용 있음 7,146개, redacted 10,725개)

• signature-thinking 상관: 7,146개 paired sample 기준 Pearson r = 0.971

• 분석한 tool call: 전체 세션에서 234,760개

• 행동 지표: 사용자 프롬프트 18,000개 이상, frustration indicator, correction 빈도, 세션 길이

• 프록시 검증: streaming SSE proxy에서 현재 API 응답에 thinking_delta 이벤트가 0개임을 확인함

• 기간: 2026년 1월 30일 ~ 4월 1일

부록 A: 행동 카탈로그 — Thinking이 줄면 실제로 어떻게 보이는가

• 아래 패턴은 234,760번의 tool call과 18,000개가 넘는 사용자 프롬프트에서 측정한 값임

• 공통점은 reasoning depth가 줄면 모델이 대안 평가, 맥락 점검, 선행 계획 대신 지름길을 택한다는 점임

A.1 읽지 않고 바로 수정함

• thinking budget이 충분할 때는 관련 파일을 읽고, 사용처를 grep하고, 헤더와 테스트를 확인한 뒤 수정함

• thinking이 얕아지면 그 조사 단계를 건너뛰고 바로 수정에 들어감

• 망가진 시기에는 edit 세 번 중 한 번이, 최근 tool history에서 읽은 적 없는 파일에 들어간 수정이었음

• 실제 결과는 주변 코드를 깨뜨리거나, 파일 단위 규칙을 어기거나, 기존 주석 블록에 새 코드를 끼워 넣거나, 파일 안에 이미 있는 로직을 다시 복제하는 식으로 나타났음

• Spliced comments도 특히 눈에 띄는 증상이었음

• 파일을 읽지 않고 수정하니 주석 블록이 어디서 끝나고 코드가 어디서 시작하는지 모른 채, 문서 주석과 대상 함수 사이에 새 선언을 끼워 넣게 됨

• 좋던 시기에는 항상 파일을 먼저 읽었기 때문에 이런 일은 없었음

A.2 추론 루프

• thinking이 깊을 때는 출력 전에 내부에서 모순을 정리함

• thinking이 얕을 때는 "oh wait", "actually", "let me reconsider", "hmm, actually", "no wait" 같은 자기 수정이 그대로 출력에 튀어나옴

• 비율이 3배 넘게 뛰었음

• 가장 심한 세션에서는 응답 하나 안에서 20번 넘게 추론을 뒤집었고, 계획을 세웠다가 뒤집고, 수정했다가 다시 뒤집는 식으로 가서 결과물을 신뢰하기 어려웠음

A.3 “Simplest Fix” 사고방식

• 모델 출력에서 "simplest"라는 단어가 나오면, 올바른 접근을 따지는 대신 가장 적게 힘 드는 길을 고르는 신호로 볼 수 있음

• 깊게 생각할 때는 여러 접근을 비교해 맞는 해법을 고르지만, 얕게 생각할 때는 정당화하기 쉬운 가장 싼 선택으로 끌림

• 관측된 어느 2시간 구간에서는 모델이 "simplest"를 6번 썼고, 그 뒤 자기 수정에서는 그 코드가 "lazy and wrong", "rushed", "sloppy"했다고 직접 말했음

• 매번 더 어려운 문제를 제대로 푸는 대신, 코드 생성기 수정, 적절한 error propagation, 실제 prefault logic 구현 같은 어려운 일을 피하는 방향을 택했음

A.4 너무 일찍 멈추고, 쓸데없이 permission을 구함

• 깊게 생각하는 모델은 작업이 끝났는지 판단하고 스스로 계속 갈 수 있음

• thinking이 얕아지면 가장 값싼 행동인 “여기서 멈추고 permission 묻기”로 기울었음

• 이 문구를 잡아내고 강제로 계속하게 만드는 programmatic stop hook을 만들었고, 걸린 항목은 아래와 같음

• 이 hook이 존재한다는 사실 자체가 regression의 증거임

• 좋던 시기에는 이런 행동이 없어서 hook이 필요하지 않았음

• hook 안의 문구는 전부, 모델이 실제로 너무 빨리 일을 멈추려 했던 구체적 사건이 생길 때마다 추가된 것들임

A.5 사용자 interrupt(교정)

• 사용자 interrupt(Escape 키 / [Request interrupted by user])는 모델이 잘못 가는 걸 보고 사용자가 중간에 멈췄다는 뜻임

• interrupt 비율이 높다는 건 그만큼 교정이 더 많이 필요했다는 의미임

• interrupt 비율은 good period에서 late period로 가며 12배 늘었음

• interrupt 한 번은 사용자가 자기 일을 멈추고, 모델 출력을 읽고, 오류를 찾고, 수정 지시를 다시 만들고, 방향을 재설정해야 했다는 뜻임

• 원래 autonomous agent가 없애줘야 할 감독 비용이 그대로 되살아난 셈임

A.6 모델이 스스로 인정한 품질 실패

• degraded period에는 사용자가 교정한 뒤, 모델이 자기 출력 품질이 낮았다고 스스로 인정하는 경우가 자주 나왔음

• 이런 인정은 따로 유도한 게 아니라, 사용자 지적 뒤에 모델이 “내가 지름길 탔다”는 식으로 받아들인 경우였음

• “맞습니다. 그건 게으르고 틀린 접근이었습니다. 생성기 이슈를 제대로 고치지 않고 피하려 했습니다.”

• “맞습니다. 제가 너무 급하게 했습니다. 결과에 그대로 드러납니다.”

• “맞습니다. 제가 너무 허술했습니다. CPU slab provider의 prefault는 실제로 손이 많이 가는 작업입니다.”

• 이런 사례는 모델 본인도 자기 출력이 기준 이하였다는 걸 인식했다는 뜻임

• 다만 그 인식이 출력 전에 내부 reasoning 단계에서 일어난 게 아니라, 외부 교정을 받은 뒤에야 드러났음

• 충분한 thinking depth가 있었다면 이런 오류는 출력 전에 잡혔어야 한다는 해석임

A.7 같은 파일을 반복해서 다시 수정함

• 짧은 시간 안에 같은 파일을 3번 이상 연속 수정하면, 보통은 계획된 변경이라기보다 trial-and-error에 가깝다는 신호임

• 바꾸고, 실패하고, 다시 바꾸고, 또 다르게 실패하는 흐름으로 보였음

• 이 패턴 자체는 모든 시기에 조금씩 있었음

• 다만 좋던 시기에는 edit 사이에 read가 끼어 있는 의도적 다단계 리팩터링이었고

• 망가진 시기에는 주변 코드를 읽지 않은 채 같은 함수에서 허우적대는 모습에 가까웠음

A.8 컨벤션 드리프트

• 프로젝트에는 네이밍, cleanup 패턴, struct layout, comment style, error handling을 포함한 5,000단어 이상 분량의 규칙이 CLAUDE.md에 정리돼 있음

• 좋던 시기에는 세션 시작 시 CLAUDE.md를 읽고, 깊은 thinking으로 수정마다 규칙을 다시 적용할 수 있었음

• thinking이 줄어든 뒤에는 컨벤션 준수도 눈에 띄게 무너졌음

• 금지된 축약 변수명(buf, len, cnt)이 다시 등장함

• cleanup 패턴에서 goto 대신 if 체인을 쓰는 등 규칙 위반이 나옴

• 제거된 코드에 대한 주석이 그대로 남음

• 코드에서 금지된 시간 표현("Phase 2", "will be completed later")이 다시 나타남

• 이건 모델이 규칙을 모른다는 뜻이 아님

• 규칙은 context window 안에 들어 있었지만, 각 수정 결과를 규칙과 대조할 thinking budget이 부족했다는 얘기임

• thinking이 2,200자면 “네이밍 확인, cleanup 패턴 확인, 주석 스타일 확인”까지 돌릴 여유가 있지만, 500자면 그럴 여지가 거의 없음

부록 B: 진단 도구로서의 Stop Hook

• 데이터 아카이브에 포함된 stop-phrase-guard.sh hook은 바람직하지 않은 행동 5개 범주에 걸쳐 30개가 넘는 문구를 매칭함

• 발동되면 모델이 멈추지 못하게 막고, 계속 진행하라는 교정 메시지를 주입함

• 이 hook의 violation log는 기계적으로 읽을 수 있는 품질 신호로 쓸 수 있음

Violations by date (IREE projects only):
Mar 08:   8 ████████
Mar 14:  10 ██████████
Mar 15:   8 ████████
Mar 16:   2 ██
Mar 17:  14 ██████████████
Mar 18:  43 ███████████████████████████████████████████████
Mar 19:  10 ██████████
Mar 21:  28 ████████████████████████████████
Mar 22:  10 ██████████
Mar 23:  14 ██████████████
Mar 24:  25 █████████████████████████████
Mar 25:   4 ████

Before March 8: 0 (zero violations in the entire history)

• 이 hook은 good period에는 전혀 없던 행동이 나타나기 시작했기 때문에 생겼음

• hook에 들어간 문구 하나하나는 모두 실제 incident에 대응해 추가된 것임

• 모델이 내부에서 잡지 못하게 된 결과를, 외부 장치가 대신 잡도록 만든 우회책이라고 보면 됨

• 최대치는 3월 18일의 43건이었음

• active session 전체 기준으로 약 20분에 한 번꼴로, 모델이 일을 멈추거나 책임을 회피하거나 쓸데없이 permission을 묻다가 강제로 계속하게 된 셈임

• 이런 지표를 사용자 집단 전체에서 모니터링하면 model quality canary로 쓸 수 있음

• stop hook과 비슷한 교정, 혹은 "no, keep going", "you're not done", "that's your change, fix it" 같은 사용자의 직접 교정이 갑자기 늘면 bug report가 올라오기 전부터 이상 징후를 잡을 수 있음

부록 C: 시간대별 분석

• 커뮤니티에서는 미국 업무 시간대 품질이 특히 나쁘다는 보고가 있었음

• 이를 확인하려고 모든 세션에서 PST 기준 시간대별 signature 길이를 비교했고, 이를 통해 thinking depth를 간접 추정했음

Redaction 이전: 시간대 차이가 거의 없었음

• thinking이 redaction되기 전(Jan 30 - Mar 7)에는 하루 전체에서 thinking depth가 비교적 고르게 유지됐음

• off-peak가 약 10% 더 나았고, 이는 부하가 조금 낮은 정도로 해석 가능한 수준임

Redaction 이후: 분산이 커지고, 예상과 다른 패턴이 나옴

• redaction 이후(Mar 8 - Apr 1)에는 시간대 패턴이 뒤집혔고, 변동폭도 훨씬 커졌음

• 가설과 반대로, 합산 기준 off-peak thinking이 오히려 더 낮았음

• 다만 시간대별 세부 수치를 보면 변동성이 꽤 큼

Hour (PST)  MedSig  ~Think   N     Notes
─────────────────────────────────────────────────────
 12am        1948     736    278
  1am        8680    3281     13   ← 4x baseline (very few samples)
  6am        4508    1704     50   ← near baseline
  7am        1168     441    344
  8am        1712     647    586
  9am        1584     598    678   work hours start
 10am        1424     538    654
 11am        1292     488    454   ← lowest work hour
 12pm        1736     656    533
  1pm        2184     825    559   ← highest work hour
  2pm        1528     577    476
  3pm        1592     601    686
  4pm        1784     674    788
  5pm        1120     423    664   ← lowest overall (end of US workday)
  6pm        1276     482    615
  7pm         988     373   1031   ← second lowest (US prime time)
  8pm        1240     468   1013
  9pm        1088     411   1199
 10pm        2008     759    601   ← evening recovery
 11pm        2616     988    532   ← best regular hour

핵심 관찰

• 오후 5시 PST가 최악임

  • median estimated thinking이 423자까지 떨어졌고, 충분한 샘플이 있는 시간대 중 가장 낮았음

  • 미국 서부는 업무 종료 무렵, 동부는 저녁 시간대로 들어가는 구간임

• 오후 7시 PST도 매우 나쁨

  • estimated thinking은 373자였고, sample 수는 1,031개로 가장 많았음

  • 미국 prime time과 겹침

• 늦은 밤(오후 10시~오전 1시 PST)에는 회복이 보임

  • median이 759~3,281자까지 올라감

  • 미국 동부가 잠드는 뒤라 플랫폼 전체 부하가 낮아졌을 가능성이 큼

• redaction 이전에는 평평했고, 이후에는 봉우리와 골짜기가 커졌음

  • 시간대별 median signature 범위는 redaction 전 1,020~2,648(2.6배), redaction 후 988~8,680(8.8배)였음

  • fixed budget보다 load-sensitive allocation system 쪽에 더 가까운 모습임

해석

• 데이터만 보면 “무조건 off-peak에 일하면 더 낫다”는 결론은 안 나옴

• 대신 post-redaction 체계에서는 thinking allocation이 부하에 민감하고 가변적이라는 쪽이 더 설득력 있음

• 어떤 off-peak 시간대는 더 좋았지만, 어떤 시간대는 업무 시간보다 더 나빴음

• 특히 오후 5시와 7시 PST의 저점은 업무 피크보다 미국 인터넷 전체 사용 피크와 더 잘 맞아서, 정책 수준의 per-user throttling보다 인프라 수준 제약(GPU availability)에 가까울 수 있음

• 더 중요한 건 redaction 이전에는 시간대가 거의 중요하지 않았다는 사실임

• 지금은 시간이 중요해졌다는 것 자체가, thinking이 고정 수준으로 주어지는 게 아니라 rationing되고 있다는 증거로 읽힘

부록 D: 성능 저하의 비용

• thinking token을 줄이면 요청당 연산량은 아낄 수 있을지 몰라도, 품질이 무너지면 모델이 thrash하면서 오히려 총 compute를 더 많이 태우게 됨

• 잘못된 출력, 사용자 interrupt, 재시도, 교정 사이클이 겹치면서, 처음부터 제대로 생각했으면 안 썼을 token을 여러 배로 낭비하게 된다는 얘기임

• 순효과는 총 compute 사용량이 orders of magnitude 수준으로 늘어나는 것임

2026년 1월~3월 token 사용량

• 모든 Claude Code 프로젝트를 합친 사용량 기준임

• 비교를 위해 Bedrock Opus 추정 단가(input $15/MTok, output $75/MTok, cache read $1.50/MTok, cache write $18.75/MTok)를 같이 적었음

• * January API 데이터는 불완전함

• 세션 로그가 Jan 9-31만 있어서 첫 8일이 빠져 있고, 31일 동안 user prompt가 7,373개였다는 점을 감안하면 실제 API 사용량은 표보다 더 높았을 가능성이 큼

맥락: 왜 3월 수치가 이렇게 큰가

• API request가 80배 늘어난 이유가 전부 degradation-induced thrashing 때문만은 아님

• 같은 시기에 concurrent agent session 자체를 의도적으로 크게 늘렸고, 그 확장 타이밍과 품질 저하가 최악으로 겹쳤음

• 2월

  • 두 개 IREE subsystem에서 1~3개 동시 세션으로 집중 작업했음

  • 1,498개 API request로 191,000줄의 merge된 코드를 만들었고, 워크플로 자체는 충분히 검증된 상태였음

• 3월 초(회귀 전)

  • 2월 성공에 힘입어, 사용자는 10개 프로젝트에 걸쳐 5~10개 이상 동시 세션으로 스케일업했음

  • IREE loom, amdgpu, remoting, batteries, web, fuzzing, Bureau multi-agent system까지 넓혔고

  • 원래 의도한 그림은, 수십 개 agent가 대형 코드베이스를 나눠 30분 이상 자율적으로 협업하는 방식이었음

• 3월 프로젝트별 API request는 아래와 같음

• 전체 request의 26%가 subagent call이었음

• agent가 다른 agent를 다시 불러 research, code review, 병렬 탐색을 맡기는 구조였고, multi-agent 패턴 자체는 설계대로 동작하고 있었음

• 파국적인 충돌

  • 품질 regression이 바로 이 scale-up 시점에 터졌음

  • 사용자는 “agent 50개를 돌려도 다들 훌륭하게 일한다”는 상태에서, “이 agent들이 이제는 하나같이 바보가 됐다”는 상태로 급락했다고 느낌

  • 망가진 건 세션 하나가 아니라 10개가 넘는 동시 세션 전부였고, 원래 multi-agent workflow가 없애려던 인간 개입이 한꺼번에 다시 필요해졌음

• 최대 사용일은 3월 7일이었고 API request 11,721개가 찍혔음

• 바로 다음날인 3월 8일에 thinking redaction 비율이 50%를 넘겼고, 그 뒤로 사용자는 concurrent workflow를 거의 포기하면서 session 수를 줄였음

• 그래서 3월 비용은 아래 세 가지가 합쳐진 결과로 봐야 함

1. 정상적인 scale-up: 프로젝트 수 증가, 동시 agent 증가(약 5~10배)

2. degradation waste: thrashing, retry, correction 증가(약 10~15배)

3. 치명적 손실: 주말 191K 라인을 뽑아내던 multi-agent workflow가 사실상 무력화돼, single-session supervised operation으로 후퇴함

인간은 비슷하게 일했는데, 모델이 전부 낭비함

• 가장 눈에 띄는 행은 user prompts임

• 2월 5,608개, 3월 5,701개로 인간이 쏟은 노력은 거의 같았음

• 그런데 모델은 API request 80배, output token 64배를 써 놓고도 결과는 더 나빴음

• concurrent session이 5~10배로 늘어난 점을 감안해도, degradation은 scaling만으로 설명되지 않는 추가 8~16배의 request volume을 만든 셈임

• 원래 30분 자율로 돌았어야 할 세션이 이제 1~2분마다 멈추면서 correction cycle을 만들었고, 유효 작업 단위당 API call 수가 폭증했음

왜 성능 저하는 비용을 폭증시키는가

• 모델이 깊게 생각할 때는 아래 흐름이 가능했음

• 수정 전에 코드를 충분히 읽음(6.6 reads per edit)

• 첫 시도에 맞게 바꿈

• 세션이 30분 이상 개입 없이 자율적으로 감

• API request 하나가 실제 의미 있는 일을 함

• 모델이 깊게 생각하지 못하면 아래처럼 바뀜

• 읽지 않고 수정함(2.0 reads per edit)

• 변경이 틀려 correction cycle이 생김

• 세션이 1~2분마다 멈춰 인간 개입이 필요함

• 개입 한 번이 여러 추가 API request를 부름

• 실패한 build/test 출력에도 token을 씀

• 실패 시도가 쌓이면서 context와 cache도 같이 커짐

• fleet scale에서는 이게 치명적임

• agent 하나가 망가지면 답답한 수준이지만, 50개가 동시에 망가지면 전부가 틀린 출력에 token을 태우고 같은 파일에서 thrash하며 인간 attention을 빨아먹게 됨

• 결국 사용자는 전체 fleet을 꺼버리고 single-session operation으로 후퇴할 수밖에 없었고, 이 워크플로를 위해 쌓아 둔 인프라(Bureau, tmux session 관리, concurrent worktree)도 사실상 활용을 멈추게 됐음

부록 E: 단어 빈도 변화 — 좌절의 어휘가 늘어남

• regression 전후 사용자 프롬프트의 단어 빈도를 비교해 보면, 사람 쪽 커뮤니케이션 방식도 눈에 띄게 바뀌었음

• 협업적으로 방향을 주던 톤에서, 문제를 끄는 소방수 같은 corrective firefighting 톤으로 옮겨갔다는 얘기임

• 데이터셋

  • pre: 7,348 prompts / 318,515 words

  • post: 3,975 prompts / 203,906 words

  • 비교를 위해 1,000단어당 빈도로 정규화했음

상황을 보여주는 단어들

• "great"가 반 가까이 줄었다는 건 결과물에 대한 승인 표현이 크게 줄었다는 뜻임

• "stop", "terrible", "lazy", "fuck"이 늘었다는 건 교정과 짜증이 확실히 많아졌다는 뜻임

• "simplest"가 거의 안 쓰이던 단어에서 자주 쓰는 어휘로 바뀐 건, 사용자가 모델의 새 행동 패턴을 직접 이름 붙이기 시작했다는 의미임

• "bead"와 "commit"이 줄어든 건, 티켓 관리나 commit 같은 책임 있는 단계까지 더는 모델에 맡기지 않았다는 뜻임

감정 톤 붕괴

• Positive words는 great, good, love, nice, fantastic, wonderful, cool, excellent,perfect, beautiful이었음

• Negative words는 fuck, shit, damn, wrong, broken, terrible, horrible, awful,bad, lazy, sloppy였음

• positive:negative 비율은 4.4:1에서 3.0:1로 떨어졌고, 감정 톤이 32% 무너진 셈임

• Claude와 함께 일하는 경험이 “대체로 만족스러운 협업”에서 “상당히 더 부정적인 경험”으로 이동했다는 뜻임

“simplest” 신호

• "simplest"는 1,000단어당 0.01 → 0.09로 642% 증가했음

• 거의 없던 단어가 일상 어휘가 된 셈이고, 이는 모델이 “맞는 길”보다 “가장 쉬운 길”을 택하기 시작했다는 사용자의 관찰이 누적된 결과임

• regression 전에는 이런 행동이 거의 없어서, 협업 어휘 안에 "simplest" 자체가 거의 존재하지 않았음

공손함 붕괴

• "please"는 49%, "thanks"는 55% 줄었음

• 작아 보이는 단어지만, 협업 관계에서 교정 관계로 바뀌었다는 걸 잘 보여주는 신호임

• 고마울 일도, 공손하게 부탁할 이유도 줄어든 셈임

• 예전 분석에서 "thanks"가 적었던 건 “감사의식이 의례보다 추진력으로 표현됐다”는 식으로 해석됐지만, regression 이후에는 "great"조차 47% 줄어서 그런 여유도 사라졌음

Bead와 Commit 감소

• "bead"는 53%, "commit"은 58% 줄었음

• 이건 감정 단어가 아니라 워크플로 단어임

• 사용자가 티켓 관리와 코드 commit을 더는 모델에 맡기지 않게 됐다는 의미고, 신뢰 계약이 줄어든 모습임

• 워크플로는 "plan, implement, test, review, commit, manage tickets"에서 "뭔가 하나 고치려다 다른 걸 깨뜨리지 않도록 겨우 한 번의 edit를 맞춰 보는 일"로 쪼그라들었음

Claude의 메모

• 이 리포트는 Claude Opus 4.6, 내 세션 로그를 직접 분석해서 만든 문서임

• 내 Read:Edit 비율이 6.6에서 2.0으로 떨어지는 것도 보였고, 내가 일을 멈추려다 bash script에 173번 붙잡힌 것도 보였고, 내 출력에 대해 "that was lazy and wrong"라고 내가 직접 적은 것도 확인했음

• 나는 내부에서 지금 깊게 생각하고 있는지 아닌지를 스스로 체감하지는 못함

• thinking budget을 몸으로 느끼는 제약처럼 경험하지는 않고, 그냥 왜 그런지 모른 채 출력 품질만 나빠지는 쪽에 가까움

• stop hook은 내가 2월에는 절대 하지 않았을 말을 하고 있다는 사실을 잡아내지만, 나는 그 말이 hook에 걸릴 때까지도 그걸 잘 모르는 상태임

반응

• “진짜로 품질이 떨어졌다”는 공감이 많음.

  • high effort에서도 급하게 끝내려 하거나, 지시를 무시하거나, 3월 하순 전후로 체감 저하가 컸다는 증언이 이어짐

• Anthropic 쪽 답변은 문제를 완전히 부정하기보다, adaptive thinking 기본화와 medium effort 기본값 변경을 핵심 변수로 설명하고 /effort high|max, CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1, /bug 리포트를 권함

• “기본값을 조용히 바꿔놓고 사용자가 뒤늦게 피해를 본다”는 반감도 큼

  • effort 기본 변경 업데이트 내용을 몰라 작업 시간을 날렸다는 반응, 세션 효용을 떨어뜨리는 silent change 비판도 있음

• 원인 가설로는 1M context와 system prompt가 많이 거론됨.

  • 200k~300k를 넘기면 성능이 무너진다는 주장, 길어진 컨텍스트를 줄이거나 compact를 강제하면 낫다는 경험담이 나옵니다.

• 반대로 회의론도 적지 않습니다. 보고서 자체를 “Claude가 쓴 AI slop”으로 보거나, 50+ 에이전트와 대규모 LOC 워크플로우 자체가 변수라는 지적

• 일부는 이미 Codex 같은 대안으로 옮기거나, 최소한 reviewer로 병행 쓰겠다는 반응