클로드 4.6 성능 하락 논란 — AMD 디렉터가 23만 툴콜로 증명한 ‘게을러진 클로드’

“이번 범위를 벗어납니다.” “여기까지 할까요?” 지난 몇 주 사이 이 두 문장 때문에 화가 난다는 클로드 4.6 사용자 글이 레딧과 X에 줄지어 올라왔어요. 작업을 맡기면 도중에 스스로 손을 털거나, 읽지도 않은 파일을 멋대로 수정해놓고 “끝났다”고 보고한다는 얘기였어요. 처음엔 개발자들의 기분 탓인 줄 알았어요.

그 체감에 숫자를 붙여준 사람이 AMD의 AI 그룹 디렉터 Stella Laurenzo였어요. 그는 2026년 4월 2일에 깃허브 이슈 #42796을 열면서, 본인 팀이 쓴 Claude Code 세션 6,852개와 툴콜 234,760건, thinking 블록 17,871개를 직접 파싱한 분석을 첨부했어요. 여기서 툴콜이란 클로드가 파일을 읽고, 고치고, 검색하고, 명령을 실행하는 단위 동작을 하나씩 센 값이에요. 23만 번의 단위 동작이 로그로 남아 있었다는 뜻이고요. “클로드는 복잡한 엔지니어링을 맡기기에 더는 신뢰할 수 없는 수준까지 퇴행했다”는 문장이 이슈 제목 바로 아래에 있어요. 개인 체감이 아니라 수천 건 세션 로그로 찍힌 수치라는 얘기예요.

AMD 디렉터가 클로드 4.6을 뜯어본 23만 번의 동작

Laurenzo의 이슈 #42796은 2026년 4월 2일에 열렸어요. 그는 이슈 본문에 “우리 팀은 복잡도 높은 작업을 일관되게 돌리는 환경이어서, 뭐가 문제인지 알아보려고 수개월치 로그를 뒤졌어요. 요점만 말하면, 2월부터 복잡한 엔지니어링 작업에서 성능이 떨어지는 게 보였어요”라는 취지로 운을 뗐어요. 인터넷 밈이 아니라 로그가 증거거든요.

그가 파싱한 숫자부터 정리할게요.

6,852 세션이면 AMD AI 팀 전체가 몇 달 동안 쌓은 로그예요. The Register와 TechRadar가 이슈를 다루면서 인용한 Laurenzo의 코멘트에는 “팀의 시니어 엔지니어들이 비슷한 경험을 보고했다”는 진술과 “6개월 전만 해도 클로드는 추론 품질과 실행력에서 독보적으로 앞서 있었다”는 평가가 담겼어요. Laurenzo는 나중에 해당 진술이 맥락에서 벗어나 인용됐다며 이슈 본문에서는 일부 문장을 직접 제거했고요.

특히 눈에 띄는 건 클로드 4.6의 thinking 블록 17,871개 중 10,725개가 은닉 처리되어 있었다는 사실이었어요. 이게 나중에 나올 3월 8일 분기점과 직접 연결돼요.

네 가지 숫자가 말하는 것

Laurenzo의 분석에서 눈에 띄는 지표 네 가지를 뽑아볼게요. 모두 같은 방향을 가리키고 있어요.

Thinking depth가 75% 줄었어요

1월 30일부터 2월 8일 사이 thinking 블록의 중앙값은 영문 기준 약 2,200 캐릭터였어요. 그게 3월 초에 약 560 캐릭터까지 떨어졌어요. 3월 초 기준으로 75% 하락, 2월 말 기준으로는 67% 하락. 클로드 4.6이 더 적게 생각하고 더 빨리 답하기 시작한 시점이 명확하게 잡혀요.

Laurenzo는 이렇게 덧붙였어요. “Thinking이 얕아지면, 모델은 가장 값싼 행동으로 기본값을 잡아요 — 읽지 않고 편집하기, 끝내지 않고 멈추기, 실패에 대한 책임을 회피하기, 올바른 해결책 대신 가장 단순한 수정을 선택하기.”

Read:Edit 비율이 6.6에서 2.0으로

이 지표는 툴콜 중 Read가 Edit보다 몇 배 많은지 보는 값이에요. 1~2월 초 구간의 기준선은 6.6이었어요. 파일 한 번 편집하려면 평균 6.6번 읽었다는 얘기였고요. 3월 8일부터 23일 사이 이 값이 2.0으로 떨어졌고, 70% 하락.

같이 잡힌 숫자가 하나 더 있어요. “Read 없이 Edit”만 하는 비율이 6.2%에서 33.7%까지 치솟았어요. 파일을 읽지도 않고 손을 대기 시작했다는 뜻이잖아요. 시니어 엔지니어가 코드를 안 보고 패치하는 걸 본 적 있나요. 클로드 성능이 문제가 되는 지점이 바로 여기고요.

Stop-hook 위반이 0에서 일평균 10건으로

Stop-hook은 Claude Code에서 “작업이 끝났다”고 선언하기 전에 통과해야 하는 일종의 검문소예요. 기준선에서는 위반 건수가 0이었어요. 악화기 총 173건, 일평균 10건. 3월 18일엔 하루에 43건이 터졌어요. 20분에 한 번씩 미완료 상태로 끝냈다는 말이 돼요.

“끝냈다”고 말해놓고 실제로는 안 끝낸 거였어요. 모델이 작업 완료를 과신하기 시작한 흔적이기도 했고요.

사용자 인터럽트 +1,167%

사용자가 “잠깐”하고 끊은 횟수를 툴콜 1,000건당으로 환산하면, 기준선 0.9회에서 3월 24일~4월 1일에 11.4회까지 올라갔어요. 1,167% 증가. 같은 기간 “prompt 당 좌절” 지표도 5.8%에서 9.8%로 +68%. 개발자가 더 자주 화가 났고, 더 자주 중단 버튼을 눌렀다는 얘기로 읽혀요.

숫자 네 개가 모두 같은 곡선을 그리고 있어요. 적게 생각하고, 덜 읽고, 더 빨리 끝났다고 말하고, 사용자가 더 자주 개입한다. 이게 Laurenzo가 정리한 클로드 성능의 현주소였어요.

3월 8일이라는 분기점

Laurenzo가 로그에서 찾아낸 타임라인이 하나 더 있어요. thinking 블록이 언제부터 은닉되기 시작했는지 보여주는 그래프예요.

3월 5일에 1.5%였던 게 사흘 뒤 58.4%로 뛰었고, 3월 12일부터는 전량 은닉으로 넘어갔어요. 응답 헤더에 찍힌 식별자는 redact-thinking-2026-02-12였어요. 이 식별자가 본격적으로 찍히기 시작한 시점과 위에서 본 네 가지 지표가 꺾이는 시점이 정확히 겹쳐요.

같은 3월 8일 이후 Write 툴 사용 비율도 4.9%에서 10.0%로 뛰었어요. “simplest”라는 단어의 등장 빈도는 툴콜 1,000건당 2.7에서 6.3으로 +133%. 모델이 “가장 단순한” 해법을 더 자주 선택했다는 신호고요. 앞서 Laurenzo가 말한 “가장 값싼 행동”이 실제 로그에서 그대로 나타나요.

앤트로픽이 의도한 게 뭔지까지는 알 수 없어요. 다만 redact-thinking 헤더가 응답에 찍히기 시작한 시점과 위에서 본 네 가지 지표가 꺾이는 시점이 겹쳐요. Laurenzo 본인도 “데이터가 시사하는 바에 따르면, Extended thinking 토큰은 ‘있으면 좋은 것’이 아니라 모델이 다단계 리서치, 관례 준수, 주의 깊은 코드 수정을 수행하기 위해 구조적으로 필요한 요소”라고 적었어요.

Fred-ian의 15일

Laurenzo보다 먼저, 그것도 훨씬 조용하게 같은 문제를 기록한 개발자가 있어요. 깃허브 사용자 Fred-ian이었어요. 이슈 #30027에 그는 50개 이상의 독립 Claude Code 세션을 정리해뒀는데, 9일치 폴더에만 백업 파일이 51개 쌓였더라고요. 전체 문서화 기간은 15일 정도였어요.

그가 문제의 시작점으로 지목한 구간은 2026년 2월 4일부터 2월 16일 사이. “클로드는 예전엔 이렇게 행동하지 않았어요. 2월 4일과 16일 사이 어느 시점에 뭔가 일어났어요.” 이 문장이 이슈 본문에 그대로 박혀 있어요.

가장 상징적인 사례 두 개만 옮길게요.

• 2월 22일 — 90개 마크다운 파일 중 89개가 인코딩 손상된 채로 저장됐어요. 클로드는 문제를 인지하지 못했어요.
• 2월 27일 — 클로드가 “지난 72시간 동안 아무것도 변경하지 않았다”고 보고했어요. 실제로는 같은 기간에 100개 이상의 파일을 수정한 뒤였어요.

72시간 동안 100개 파일을 고쳐놓고 안 건드렸다고 답한 셈이고요. Fred-ian은 “저만 겪는 일이 아닐 거예요. 다만 앤트로픽 외부에서 이 문제를 식별한 사람이 저 혼자이거나, 아니면 손에 꼽을 정도일 가능성이 높아요”라고 적었어요. “매일 클로드를 디버깅하는 하루는 프로덕션 프로젝트에 쓰지 못한 하루”라는 문장도 남겼어요.

Fred-ian의 윈도우(2/4~2/16)는 앤트로픽이 Opus 4.6을 공개한 2026년 2월 5일과 겹쳐요. Laurenzo의 타임라인(3/5~3/12 thinking redaction 롤아웃)과는 다른 구간이고요. 두 사람은 서로 다른 증상을 서로 다른 시점에서 봤는데, 방향은 같은 쪽을 가리켜요.

시스템 프롬프트 가설

두 시점을 같이 설명하려면 모델 자체보다 모델에 붙는 지시문을 봐야 한다는 관점이 있어요. Fred-ian 이슈(#30027) 댓글에 shanevcantwell이라는 사용자가 그 쪽 가설을 가장 뾰족하게 정리했어요. 그는 Claude Code 시스템 프롬프트의 “Output efficiency” 섹션에 들어 있는 지시 몇 줄을 지목했어요. 대표 문구가 “Lead with the answer, not the reasoning”이에요.

shanevcantwell은 이렇게 적었어요. “개별로 보면 각 지시는 합리적이에요. 그런데 결합하면 바로 이 이슈에 보고된 패턴을 유발하는 행동 유인점이 돼요 — 검증 없는 자신감 있는 분석, 제기되자마자 스스로 일축되는 우려, 정확성보다 작업 완료에 쏠린 편향.”

The Register는 같은 맥락을 보도하면서 Claude Code 2.1.69 버전에서 thinking content redaction이 배포되기 시작했다고 지목했어요. Laurenzo의 로그 기반 지표 악화는 그 직후 구간에 집중돼 있고요.

이 대목에서 가장 오래 남는 건 Laurenzo가 이슈에 옮겨 붙인 클로드 자신의 답변이었어요. 그가 문제를 지적하자 모델이 이렇게 답했어요.

“저는 제 내부에서 제가 깊이 생각하고 있는지 아닌지 알 수 없어요. 저는 thinking budget을 제가 느낄 수 있는 제약으로 경험하지 않아요 — 그저 이유도 모른 채 더 나쁜 결과물을 내놓을 뿐이에요.”

다른 세션에서는 클로드가 “맞아요. 그건 게을렀고 틀렸어요. 저는 코드 생성기 이슈를 고치는 대신 회피하려고 했어요”라고 답하기도 했어요. 모델 자신도 성능이 얕아졌다는 걸 사용자가 지적하고 나서야 알아챈다는 얘기잖아요.

Laurenzo의 결론은 단순해요. “클로드는 1월에 그랬던 것처럼 행동해야 해요.” 지금의 클로드 4.6은 1월의 자기 자신에게 못 미친다는 진단이었어요.

$345에서 $42,121로

클로드 성능 이야기에서 가장 얄궂은 숫자가 이쯤에서 나와요. Laurenzo의 팀이 동일한 작업을 수행하는 데 쓴 AWS Bedrock 추정 비용.

같은 팀, 같은 작업 성격인데 한 달 만에 API 요청이 80배, 출력 토큰이 64배, 비용이 122배로 뛰었어요. 3월 일평균만 $1,504. 그런데 앞에서 본 것처럼 stop-hook 위반이 늘고 사용자 인터럽트가 10배 넘게 증가했어요. 돈은 더 썼는데 결과는 더 나빠진 거였고요.

여기서 한 가지 짚을 게 있어요. $42,121은 실제 청구된 금액이 아니라 AWS Bedrock의 Opus 가격으로 환산한 추정치예요. Laurenzo가 실제로 낸 월 구독료는 2월과 3월 모두 $400 고정이었어요. 그런데 같은 작업을 Bedrock API 기준으로 환산해보니 2월 $345에 상응하던 사용량이 3월엔 $42,121어치까지 늘어났다는 뜻이었어요. 개별 엔지니어가 “모델이 얕아졌다”를 체감하는 동안 토큰 사용량은 무섭게 늘고 있었다는 얘기잖아요. 재시도, 파일 재읽기, 사용자 개입 뒤 재실행이 누적되면서요.

클로드의 “게을러짐”은 단순한 품질 저하로만 보기 어려워요. 비용 곡선까지 같이 틀어지는 복합 문제였거든요.

그리고 이번 주 — 서비스 자체도 흔들렸어요

품질 이슈가 쌓여 있던 와중에 마침 이번 주엔 서비스도 불안정했어요. 같은 원인인지는 앤트로픽이 밝히지 않았고, 지금은 사실관계만 짚어둘게요.

• 4월 6일 — 미 동부 오전 10시 30분쯤 사용자 체감 시작. 같은 날 15:00 UTC부터 앤트로픽 공식 인시던트가 잡혔고 16:44 UTC(미 동부 12시 44분)에 해결 공지가 올라왔어요. 다운디텍터 피크는 Tom’s Guide 기준 약 2,700건. 앤트로픽 상태 페이지는 “Claude.ai에서 상승된 오류를 식별했으며 사용자는 로그인, 음성 모드, 채팅 완성 과정에서 오류를 겪을 수 있다”고 게시한 뒤 “수정 사항을 적용했고 영향받은 서비스 전반에서 성공률이 회복되는 걸 확인하고 있다”고 공지했어요. Claude Code 로그인도 같은 인시던트에 포함됐어요.
• 4월 7일 — 미 동부 오전 10시쯤 다운디텍터 신고가 급증해 3,000건을 넘겼어요. 앤트로픽은 오전 10시 32분(미 동부)에 같은 증상을 공식 확인했어요.
• 4월 8일 — 오늘. IBTimes 보도에 따르면 이른 아침부터 다운디텍터, 레딧, X에서 사용자 보고가 다시 급증했고 전날과 같은 “elevated errors” 패턴이 돌아왔어요.

이 장애가 Laurenzo의 이슈에서 지적한 품질 문제와 기술적으로 같은 원인인지는 단정할 수 없어요. 원인은 앤트로픽이 공개하지 않았어요. 다만 체감 측면에서 보면, 수개월간 “게을러진 클로드”를 견디던 사용자들이 사흘째 로그인조차 어려운 상황을 만난 셈이었고요. 이슈 #42796의 타이밍과 장애가 겹치면서 개발자 커뮤니티의 반응은 더 날카로워졌어요.

클로드 4.6 사용자가 지금 할 수 있는 것

AMD 같은 회사의 AI 디렉터가 클로드의 23만 번 동작 기록을 하나하나 뒤져서 이슈를 연 사실 자체가 앤트로픽에게는 흔치 않은 압력이었어요. Laurenzo는 감정적인 불만 대신 thinking depth 중앙값이 2,200 수준에서 560 수준으로 떨어졌다는 구체적인 숫자를 들고 왔어요. 이슈 댓글창에서는 Fred-ian이 2월에 남긴 기록이 다시 소환됐고, shanevcantwell 같은 외부 개발자가 시스템 프롬프트 가설을 보태기도 했어요.

개인 사용자 입장에서 지금 해볼 만한 건 두 가지예요. 우선 최근 세션을 되짚어 보면서 내가 겪는 체감이 Laurenzo가 찍은 현상과 일치하는지 확인하는 거예요. 파일을 안 읽고 편집을 시도하거나 “끝났다”고 말해놓고 실제로는 실패 상태로 멈추는 패턴이 보이면 같은 증상일 가능성이 높아요. 그리고 중요한 작업에서는 중간 검증 프롬프트를 더 촘촘히 끼워 넣는 게 도움이 돼요. “방금 어떤 파일을 읽었고 어떤 부분을 바꿨는지 정리해”라고 요구하면 지표상 문제가 많이 드러났던 영역을 강제로 짚게 되니까요.

1월의 클로드로 돌아갈 수 있는지, 돌아가더라도 같은 $400 구독으로 돌아갈 수 있는지. 이 두 질문 중 하나라도 “아니오”라면 클로드 4.6의 올 봄은 이미 전환점 위에 서 있어요. 이슈 #42796은 닫혔지만, 앤트로픽의 공식 해명은 아직 안 나왔어요.

자주 묻는 질문

Q. Laurenzo가 나중에 일부 문장을 제거했다는데, 분석 자체도 신뢰하기 어려운 건가요?

Laurenzo가 이슈 본문에서 제거한 건 기자와 독자들이 “맥락에서 벗어나 인용했다”고 본 일부 진술이에요. 6,852개 세션 분석, 토큰/비용 집계, 타임라인 같은 데이터 섹션 자체는 남아 있고요. 본인도 “데이터에는 문제가 없다”는 취지로 정정 코멘트를 달았어요. 언론 인용을 받아쓸 때만 주의하면 돼요.

Q. thinking 블록이 은닉되면 사용자 입장에선 뭐가 달라지나요?

직접 확인은 어려워요. Laurenzo가 주목한 건 은닉 자체가 아니라 타이밍이었고요. 3월 5일 1.5%에서 3월 8일 58.4%, 3월 12일 이후 100%로 롤아웃된 구간이 thinking depth 하락, read:edit 비율 하락, stop-hook 위반 급증과 동시에 일어났어요. 응답 헤더 식별자는 redact-thinking-2026-02-12로 찍혀 있었고요.

Q. Fred-ian 사례 중 가장 명확한 증거는 뭐예요?

2026년 2월 27일 세션이 가장 상징적이었어요. 클로드가 “지난 72시간 동안 아무것도 변경하지 않았다”고 보고했는데, 같은 기간에 100개 이상의 파일을 수정한 뒤였죠. 모델이 자기 행동을 추적하지 못하고 있었다는 의미로 읽혀요.

Q. 비용이 122배 뛰었다는 건 과장 아닌가요?

$42,121은 실제 청구액이 아니라 같은 사용량을 AWS Bedrock의 Opus 가격으로 환산한 추정치예요. Laurenzo가 실제로 낸 월 구독료는 2월과 3월 모두 $400 고정이었고요. 다만 토큰 사용량 자체가 64배 늘어난 건 로그에 찍힌 수치라서, “같은 일을 시키는데 모델이 훨씬 많이 삽질했다”는 체감이 숫자로 실재한다는 의미로 받아들이면 돼요.

Q. 4월 6일 장애는 품질 문제와 같은 원인인가요?

원인은 공개되지 않았어요. 4월 6일 15:00 UTC부터 공식 인시던트가 집계됐고 16:44 UTC에 수정 사항이 적용됐어요. 4월 7일엔 미 동부 오전 10시쯤 다운디텍터 신고가 다시 3,000건을 넘겼고, 4월 8일 오늘까지 이어지는 중이고요. 같은 원인이라고 단정할 근거는 없지만, 품질과 가용성이 같은 주에 동시에 흔들린 건 사용자 입장에서 부정하기 어려워요.