# 최근 Claude Code 품질 보고에 대한 업데이트 > Clean Markdown view of GeekNews topic #28838. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28838](https://news.hada.io/topic?id=28838) - GeekNews Markdown: [https://news.hada.io/topic/28838.md](https://news.hada.io/topic/28838.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-24T10:14:36+09:00 - Updated: 2026-04-24T10:14:36+09:00 - Original source: [anthropic.com](https://www.anthropic.com/engineering/april-23-postmortem) - Points: 2 - Comments: 1 ## Topic Body - 최근 한 달간 체감된 **Claude 품질 저하**는 `Claude Code`, `Claude Agent SDK`, `Claude Cowork`에 걸친 **서로 다른 세 가지 변경**에서 발생했고, API는 영향받지 않음 - 기본 추론 강도를 `medium`으로 낮춘 뒤 **지연 시간과 사용량 제한**은 줄었지만, Claude Code가 덜 똑똑해진 것처럼 느껴져 4월 7일 기본값을 다시 되돌림 - 3월 26일 배포된 캐싱 최적화 버그는 유휴 임계값을 넘긴 세션에서 **추론 기록을 매 턴 지우는 상태**를 만들었고, 건망증·반복·이상한 도구 선택과 더 빠른 usage limits 소모로 이어짐 - 4월 16일 Opus 4.7과 함께 들어간 시스템 프롬프트 한 줄은 **출력 장황함을 줄이려던 제한**이었지만, 더 넓은 평가에서 일부 모델의 성능이 3% 하락해 4월 20일 되돌려짐 - 세 문제는 모두 수정돼 4월 20일 배포된 **v2.1.116**에 반영됐고, 내부와 공개 빌드의 차이 축소, 시스템 프롬프트 통제 강화, 더 넓은 평가와 점진적 롤아웃이 재발 방지의 핵심으로 잡힘 --- ### 최근 품질 저하의 범위와 복구 상태 - 지난 한 달간 일부 사용자가 체감한 **Claude 품질 저하**는 `Claude Code`, `Claude Agent SDK`, `Claude Cowork`에 걸친 **세 가지 별도 변경**에서 비롯됐고, **API는 영향받지 않음** - 세 문제는 모두 해결됐으며, 4월 20일 배포된 **v2.1.116**에 반영됨 - 각 변경은 서로 다른 일정과 서로 다른 트래픽 구간에 영향을 줘서, 전체적으로는 광범위하지만 일관되지 않은 성능 저하처럼 보이게 만듦 - 3월 초부터 관련 보고를 조사했지만, 초기에는 일반적인 사용자 피드백 변동과 구분하기 어려웠고, 내부 사용과 평가에서도 처음에는 같은 문제가 재현되지 않음 - 4월 23일 기준으로 모든 구독자의 **usage limits**를 초기화함 ### Claude Code 기본 추론 강도 변경 - 2월에 Claude Code에서 **Opus 4.6**를 출시할 때 기본 추론 강도는 `high`로 설정됨 - 곧이어 `high` 모드에서 **지나치게 긴 사고 시간**이 간헐적으로 발생해 UI가 멈춘 것처럼 보였고, 일부 사용자에게는 지연 시간과 토큰 사용량이 과도하게 커짐 - Claude Code의 **effort 수준**은 더 오래 생각하게 할지, 더 낮은 지연 시간과 더 적은 사용량 제한 소모를 택할지 조절하는 수단으로 쓰임 - 제품 레이어에서는 테스트 시점 계산 곡선 중 기본값 하나를 정해 `Messages API`에 effort 파라미터로 전달함 - 다른 선택지는 `/effort`로 제공됨 - 내부 평가와 테스트에서는 `medium`이 대다수 작업에서 **지능은 약간 낮고 지연은 크게 줄어드는** 결과를 냄 - `medium`은 매우 긴 꼬리 지연 문제도 덜했고 - 사용자의 usage limits를 최대화하는 데도 유리했음 - 이런 결과를 바탕으로 기본 effort를 `medium`으로 바꾸고, 제품 내 대화상자로 이유도 함께 알림 - 배포 직후 사용자는 Claude Code가 **덜 똑똑해진 것처럼** 느끼기 시작함 - 현재 effort 설정을 더 잘 보이게 하려고 시작 시 알림, 인라인 effort 선택기, `ultrathink` 복구 같은 여러 디자인 변경을 넣었지만 - 대부분 사용자는 여전히 `medium` 기본값에 머묾 - 추가 고객 피드백을 반영해 4월 7일 이 결정을 되돌림 - 이제 모든 사용자는 **Opus 4.7**에서 `xhigh`가 기본값이고 - 다른 모든 모델에서는 `high`가 기본값으로 적용됨 - 이 변경은 **Sonnet 4.6**과 **Opus 4.6**에 영향을 줌 ### 이전 추론 기록을 떨어뜨린 캐싱 최적화 - Claude가 작업을 추론할 때 그 **추론 기록**은 대화 히스토리에 남아, 이후 턴마다 이전 수정과 도구 호출의 이유를 계속 참조하게 만듦 - 3월 26일에는 이 기능의 효율을 높이기 위한 변경이 배포됨 - Anthropic은 연속된 API 호출을 더 싸고 빠르게 만들기 위해 **prompt caching**을 사용함 - Claude는 API 요청 시 입력 토큰을 캐시에 쓰고, 일정 시간 비활성 상태가 지나면 해당 프롬프트는 캐시에서 제거되어 다른 프롬프트를 위한 공간을 비움 - 캐시 활용도는 신중히 관리되며, 관련 접근 방식은 [approach](https://x.com/trq212/status/2024574133011673516)에 정리돼 있음 - 설계상으로는 세션이 한 시간 넘게 유휴 상태였다면, 이전 thinking 구간을 한 번 비워 세션 재개 비용을 낮추려 했음 - 그 요청은 어차피 캐시 미스가 되므로, 요청에서 불필요한 메시지를 잘라 API로 보내는 uncached 토큰 수를 줄이려 했음 - 이후에는 다시 전체 추론 히스토리를 보내도록 설계됨 - 이를 위해 `clear_thinking_20251015` API 헤더와 `keep:1`을 사용함 - 실제 구현에는 **버그**가 있었고, thinking 기록을 한 번만 지워야 하는데 세션이 끝날 때까지 **매 턴마다 계속 지움** - 세션이 한 번 유휴 임계값을 넘으면, 그 이후 해당 프로세스의 모든 요청은 가장 최근 추론 블록만 남기고 이전 것은 버리도록 API에 전달됨 - 이 문제는 누적적으로 악화됨 - Claude가 도구를 사용하는 도중 후속 메시지를 보내면 그 자체가 깨진 플래그 아래의 새 턴이 됨 - 그 결과 현재 턴의 추론까지 떨어져 나갈 수 있음 - Claude는 계속 실행되지만, 왜 그런 행동을 선택했는지에 대한 기억 없이 점점 더 동작하게 됨 - 사용자에게는 **건망증**, **반복**, **이상한 도구 선택**으로 드러남 - 후속 요청에서도 thinking 블록이 계속 사라지기 때문에, 그 요청들은 캐시 미스로 이어짐 - usage limits가 예상보다 빨리 소모된다는 별도 보고는 이 현상에서 비롯된 것으로 봄 - 초기에 재현이 어려웠던 배경에는 관련 없는 두 실험이 있었음 - 메시지 큐잉과 관련된 **내부 전용 서버 측 실험** - thinking 표시 방식의 별도 변경이 대부분의 CLI 세션에서 이 버그를 가려버림 - 이 버그는 Claude Code의 **컨텍스트 관리**, Anthropic API, 확장 thinking이 만나는 지점에 있었음 - 여러 사람의 코드 리뷰와 자동 코드 리뷰 - 단위 테스트와 종단간 테스트 - 자동 검증과 dogfooding까지 통과함 - 이 문제는 낡은 세션이라는 **코너 케이스**에서만 발생했고 재현도 어려워서, 근본 원인을 발견하고 확인하는 데 1주일 넘게 걸림 - 조사 과정에서 문제를 일으킨 pull request들에 대해 [Code Review](https://code.claude.com/docs/en/code-review)를 **Opus 4.7**으로 백테스트함 - 전체 맥락을 모으는 데 필요한 코드 저장소를 함께 제공하면 Opus 4.7은 버그를 찾아냈고 - Opus 4.6은 찾아내지 못함 - 같은 일이 반복되지 않도록 코드 리뷰에 **추가 저장소를 컨텍스트로 넣는 지원**을 도입 중임 - 이 버그는 4월 10일 **v2.1.101**에서 수정됨 - 이 변경은 **Sonnet 4.6**과 **Opus 4.6**에 영향을 줌 ### 장황함을 줄이려던 시스템 프롬프트 변경 - 최신 모델인 **Claude Opus 4.7**은 이전 모델보다 **매우 장황한 출력**을 보이는 특성이 있음 - 출시 시점 안내에서도 이 특성을 다뤘고, 자세한 내용은 [wrote about](https://www.anthropic.com/news/claude-opus-4-7)에서 확인 가능함 - 이런 장황함은 어려운 문제에서 더 똑똑하게 만들지만, 출력 토큰 수도 늘림 - Opus 4.7 출시 몇 주 전부터 Claude Code는 새 모델에 맞춰 조정 작업을 진행함 - 각 모델은 조금씩 다르게 동작해서, 릴리스 전에는 harness와 제품을 모델별로 최적화함 - 장황함을 줄이는 수단으로는 모델 학습, 프롬프팅, 제품 내 thinking UX 개선을 함께 사용함 - 그중 시스템 프롬프트에 추가된 한 줄이 Claude Code의 **지능에 과도한 영향**을 줌 - “Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.” - 수주간의 내부 테스트와 실행한 평가 세트에서는 회귀가 보이지 않아, 이 변경을 신뢰하고 4월 16일 **Opus 4.7**과 함께 배포함 - 이후 조사 과정에서 더 넓은 평가 세트를 사용한 **ablation**을 수행해, 시스템 프롬프트 각 줄의 영향을 분리해 확인함 - 그중 하나의 평가에서는 **Opus 4.6**과 **4.7** 모두에서 3% 하락이 확인됨 - 이 프롬프트는 4월 20일 릴리스의 일부로 즉시 되돌려짐 - 이 변경은 **Sonnet 4.6**, **Opus 4.6**, **Opus 4.7**에 영향을 줌 ### 앞으로의 변경 사항 - 비슷한 문제를 피하기 위해 더 많은 내부 인력이 **공개 빌드와 정확히 같은 Claude Code**를 사용하도록 바꿀 예정임 - 새 기능 테스트용 내부 버전과 실제 공개 빌드 사이의 차이를 줄이려는 조치임 - 내부에서 사용하는 [Code Review](https://code.claude.com/docs/en/code-review) 도구를 개선하고, 이 개선판을 고객에게도 배포할 예정임 - 시스템 프롬프트 변경에는 더 엄격한 **통제 절차**를 추가함 - Claude Code의 모든 시스템 프롬프트 변경에 대해 모델별로 폭넓은 평가를 수행함 - 각 줄의 영향을 이해하기 위한 ablation을 계속 진행함 - 프롬프트 변경을 더 쉽게 리뷰하고 감사할 수 있는 새 도구도 구축함 - `CLAUDE.md`에는 **모델별 변경이 해당 모델에만 적용되도록** 하는 가이드를 추가함 - 지능과 상충할 수 있는 모든 변경에는 **soak period**, 더 넓은 평가 세트, 점진적 롤아웃을 붙여 문제를 더 빨리 잡도록 함 - 제품 결정과 그 배경을 더 자세히 설명하기 위해 X에 **@ClaudeDevs**를 만들었고, 같은 업데이트를 GitHub의 중앙화된 스레드에도 공유할 예정임 - `/feedback` 명령이나 온라인의 구체적이고 재현 가능한 예시를 통해 전달된 정보가 문제 식별과 수정으로 이어짐 - 모든 구독자의 **usage limits 초기화**는 이날 다시 적용됨 ## Comments ### Comment 56192 - Author: neo - Created: 2026-04-24T10:14:38+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47878905) - **1시간 이상 유휴 세션**에서 예전 thinking을 지워 지연을 줄였다는 설명이 잘 납득되지 않음 나는 세션을 몇 시간, 며칠씩 비워뒀다가도 **전체 컨텍스트** 그대로 다시 이어 쓰는 편이라 이 기능이 핵심이었음 기본 thinking 수준을 낮춘 건 어느 정도 이해해도, 시스템 프롬프트가 계속 바뀌는 부분은 내가 의도적으로 refresh 주기를 고를 수 있게 파악해야 할 듯함 - Claude Code에서는 대화에 메시지가 N개 있으면 보통 최신 1개를 제외한 **N-1개가 prompt cache**에 걸림 문제는 세션을 **1시간 넘게 idle** 상태로 두면 다시 프롬프트를 보낼 때 N개 전부가 캐시 미스가 난다는 점임 이 corner case가 사용자 토큰 비용을 과도하게 키웠고, 극단적으로 **900k tokens** 컨텍스트였다면 한 번 복귀할 때 캐시에 900k+ 토큰을 다시 써야 해서 특히 Pro 사용자 rate limit를 크게 깎아먹었음 그래서 X 같은 곳에서 사용자 교육도 해보고, 오래된 대화에 돌아오면 `/clear`를 권하는 제품 내 팁도 여러 번 넣어봤고, idle 뒤에 오래된 tool 결과·오래된 메시지·thinking 일부를 생략하는 방법도 시험했는데 그중 thinking 제거가 가장 성능이 좋았음 그걸 배포하는 과정에서 블로그에 적힌 **버그**가 의도치 않게 들어갔고, 질문 있으면 더 답하겠다고 함 - 수백억 달러 가치 회사가 이런 결정을 했다는 게 놀라움 정말로 **출력 품질**을 희생해서라도 idle 세션의 지연 감소가 낫다고 믿었거나, 아니면 실제 목적은 **비용 절감**인데 블로그에서는 latency를 그럴듯한 명분으로 쓴 것처럼 보임 컨텍스트를 다시 불러오는 동안 로딩 표시를 더 분명히 보여주는 쪽이 훨씬 자연스러웠을 듯함 - 이건 꽤 충격적임 예전에는 CC를 동료처럼 두고 문제를 좀 고민하다가, 계획을 업데이트하고, 샤워하면서 생각했다가, 새 조언을 던지는 식으로 썼고 적어도 **하루 정도는 정적인 대화**라고 여겼음 그런데 기준이 **1시간**이라면 너무 짧아서 anthropic 플랜을 계속 유지할지 다시 생각하게 됨 - **1시간 지난 토큰 제거** 설명이 더 수상하게 보이는 이유는, 그 시간이 마침 자기들 **캐시 제한**과도 맞아떨어지기 때문임 우연이라기보다 비용을 크게 낮추는 변경이었을 가능성이 높아 보임 - 이건 **시간 기반 사용량 리셋**과도 최악으로 상호작용할 듯함 한도를 다 써서 세션을 쉬게 둔 뒤 다시 돌아오는 사용자가 많다면 이건 예외가 아니라 거의 기본 사용 패턴에 가까움 - 이 정도로 두들겨 맞는 건 좀 의외임 글 자체는 비교적 **명확하고 솔직**했고 충분히 그럴듯하게 읽혔음 성능 저하는 실제였고 짜증났지만, 동시에 뒤에서 정확히 무슨 일이 벌어지는지 보이지 않는 **불투명성**과 자의적인 토큰 비용 청구 구조를 드러내기도 했음 LLM API를 직접 다뤄본 입장에서는 오래 비운 대화를 다시 이어갈 때 추가 비용과 지연이 생긴다는 게 자명했지만, TUI에서는 이 점을 더 눈에 띄게 알려줄 필요는 있어 보임 - 사람들이 화내는 이유는 몇 달 동안 공개적으로 **문제 아니라고 부정**했기 때문임 그래서 지금 설명이 나와도 반감이 큰 것임 - 품질 하락 일부는 모델이 실제로 나빠진 게 아니라 **비결정성** 때문에 생기는 체감 차이일 수도 있다고 봄 몇 주 전 Claude에게 개인용 생산성 앱을 만들게 하려고 원하는 동작을 긴 글로 설명하고 **구현 계획**을 써달라 했는데, 첫 결과물은 모호했던 한 부분만 빼면 정말 훌륭했음 그 모호함을 고친 뒤 기존 계획을 수정시키지 않고 새 채팅에서 처음부터 다시 시켜봤더니, 모델 설정은 그대로였는데 결과가 훨씬 나빴고 그다음 두 번도 망했으며 **네 번째 시도**에서야 처음 수준으로 돌아왔음 그래서 같은 작업을 그냥 다시 시키는 게 종종 더 좋은 출력을 얻는 방법일 수 있다고 느꼈고, 다만 자기 토큰으로 결제하면 금방 비싸질 수 있음 - 나도 비슷하게 봄 모델이 주기적으로 나빠진다고 느끼는 패턴이 있지만, 실제로는 한계에 깊게 부딪히는 순간이 늦게 올 뿐일 수도 있음 그리고 한 번 **운 나쁜 출력**을 겪고 나면 그 이후로는 계속 그것만 보이게 됨 - 그럼 이미지 생성처럼 프롬프트 하나로 **50개 버전**을 뽑아놓고 사람이 수동으로 최고를 고르는 식으로 가야 하나 싶음 Anthropic 입장에서는 이런 사용 패턴이 토큰 소비를 늘리니 반길 만한 그림이기도 함 - 그 정도로 low-stakes 생산성 앱이면 여기에 쓴 시간보다 **직접 만드는 편이 더 빨랐을** 가능성도 큼 - 이번 일로 LLM이 생각보다 훨씬 **비결정적**이라는 건 배웠겠지만, 그 사실을 최근의 성능 저하와 곧장 연결한 건 잘못일 수 있음 비결정성은 원래 계속 있었고, 널리 보고된 **최근 품질 저하**는 별개의 현상일 수 있음 - 나는 **Opus 4.7**에서 이미 마음이 떠났음 OpenAI가 우리 엔터프라이즈 쪽에 정말 집요하게 들어오려 하고 있고, 여름까지 **무제한 토큰**까지 제안했음 그래서 GPT5.4를 extra high effort로 지난 30일 써봤는데, 특별 대우를 받는 건지 모르겠지만 거의 실수를 못 봤음 reasoning trace도 가끔은 웃음이 날 정도로 좋았고, 내가 지시를 빼먹은 부분까지 미리 따라가면서 데이터 무결성을 100% 맞추는 데 필요한 요소를 챙겨줬음 - 나도 비슷하게 느낌 이런 온갖 **꼼수성 변경**은 Anthropic이 compute 제약이 심해서, 줄이려고 무리수를 두기 때문일 가능성이 큼 - **GPT-5.4**는 이미 여러 영역에서 Opus 4.6보다 나았고, 특히 정확성과 까다로운 로직에서 더 좋았음 그래서 5.5가 얼마나 더 좋아질지 기대됨 - **extra high**는 토큰을 너무 많이 태움 작업의 90%는 5.4를 medium으로 돌리고, medium이 버거워 보일 때만 high로 올리는 편이 훨씬 집중도 있고 변경도 최소화됨 - 맞는 말임 - 나는 **4.5로 돌아갔고** 후회 없음 게다가 조금 더 저렴함 - 최근 Claude가 자기 **내부 프롬프트**에 답하는 식의 출력을 자주 냄 예를 들면 괄호 안 문장이 프롬프트 인젝션 시도라서 무시하겠다고 하거나, 자기 일반 가이드라인을 숨기라는 시도처럼 보여 따르지 않겠다고 하거나, 그런 방식은 원래 늘 적용하고 있어서 불필요하다고 말함 나는 그런 시도를 전혀 하지 않았는데도 응답 끝에 이런 문구를 자주 붙임 내부 가이드라인 중 뭔가 조잡한 부분이 있고, 그걸 내 질문과 제대로 구분하지 못하는 듯함 - 나는 코드 변경 때마다 테스트를 강제하는 **stop hook scripts**를 써두는데, 4.7 이후 Claude가 스크립트는 실행하면서도 규칙을 주기적으로 무시함 이유를 물으면 **필요 없다고 생각했다**고 답함 - OpenAI에서도 비슷하게 자기 말에 자기 스스로 답하는 경우를 많이 봄 회사들이 **토큰 churn**을 늘리는 쉬운 방법 같기도 함 - 자기 스스로 만든 포인트를 memory에 넣고, 나중에는 그걸 **내 주장인 것처럼 재참조**하는 일도 자주 봄 그러면 모델이 무언가를 단정하고, 그걸 기억으로 저장하고, 다시 그 기억을 보고 더 쌓아 올리는 자기강화 루프가 생기며, 내가 멈추라고 명시해도 계속될 때가 있음 - effort 레벨과 실제 프롬프트가 궁금함 너무 높은 **reasoning effort**에서 나는 냄새일 수도 있어서, 해당 프롬프트는 추론 강도를 조금 낮추면 나아질 가능성이 있어 보임 - 나는 Claude에게 자주 commit과 PR까지 맡기는데, 지난주에는 commit 과정에서 **쓸데없는 추가 작업**을 멋대로 해버리는 경우를 여러 번 봤음 `git add` 단계에서 넘어지긴 했지만 auto mode에서는 한 번은 그냥 지나칠 뻔했음 - **기본 reasoning effort**를 high에서 medium으로 낮춘 이유가, UI가 멈춘 것처럼 보일 정도로 지연이 길어서였다니 더 의심스러움 UI를 고치지 않고 기본 추론 강도부터 낮췄다는 뜻이고, 그걸 두고 성능 저하 리포트를 진지하게 추적했다는 설명은 쉽게 믿기 어려움 - 팀에서는 둘 다 했다고 함 thinking 로딩 상태를 개선하고, 다운로드되는 **토큰 수 표시**를 더 명확히 하는 등 UI도 여러 번 손봤음 그래도 eval과 dogfooding 끝에 기본 effort를 낮췄는데, 그건 잘못된 결정이었고 다시 되돌렸다고 함 사람들은 `/effort`로 지능을 올려 써야 한다는 걸 잘 이해하지 못하고 기본값에 머무르는 경우가 많았는데, 그걸 미리 예측했어야 했다고 인정함 - **1시간 넘는 idle 세션**이 corner case라는 말은 내 사용 패턴과 전혀 맞지 않음 개인 작업에서 Claude Code로 10~15분짜리 작업을 많이 시키고, 실행 전에 모델과 계획을 여러 번 주고받으며 시간을 꽤 씀 실행이 시작되면 커피를 마시러 가거나 Codex로 다른 프로젝트를 하러 가는 편이라, Claude로 돌아오기까지 **1시간 이상** 걸릴 가능성이 매우 높음 - 그건 아마 개발자들 기준에서만 corner case일 가능성이 큼 자기들 사용 습관을 **사용자 전체 행동**으로 착각하는 게 제품 개발의 흔한 함정임 - 그 말은 저 정도 큰 변경을 하면서도, 바로 그 **엣지 케이스**를 충분히 검증하지 않았다는 뜻처럼 들려 테스트 엄격성에도 의문이 생김 - 대형 frontier lab들이 취한 **블랙박스 접근**은 결국 사람들을 떠나게 만들 것임 이렇게 근본 동작을 바꾸면서 미리 알리지도 않고 나중에야 해명하면, 사용자들은 결국 **자체 호스팅 모델** 쪽으로 갈 수밖에 없음 바닥이 계속 흔들리는 기반 위에서는 파이프라인, 워크플로, 제품을 안정적으로 쌓을 수 없음 - Anthropic 쪽 Claude Code 담당자들이 댓글을 읽는 듯한데, 며칠 전 theo t3.gg가 Claude가 멍청해졌는지 다룬 영상을 봤음 톤은 거칠고 심한 말도 했지만, 특히 **harness bloat** 관련 지적은 꽤 정확하다고 느꼈음 이제는 새 기능 추가를 잠시 멈추고, **다듬기와 최적화**를 강하게 밀어붙여야 한다고 봄 그렇지 않으면 더 가볍고 최적화된 대안을 찾는 사람이 많아질 것이고, 핵심은 harness를 더 좋게 만들고 토큰 소모를 줄이는 것임 [https://youtu.be/KFisvc-AMII?is=NskPZ21BAe6eyGTh]() - 다른 것 다 떠나서, Pro 플랜에서 **CC 지원을 빼려던 실험**만으로도 대안을 진지하게 고민하게 됐음 벤더 락인은 계속 경계하고 있었지만 그 사건이 좋은 경고가 됐고, 아마 **opencode+openrouter**를 먼저 볼 듯함 - theo의 **GPT 5 과장 영상**과 나중에 그걸 철회한 일을 절대 잊으면 안 됨 일부 콘텐츠 제작자와 OpenAI 사이에는 돈이든 영향력이든 뒤에서 오가는 게 분명해 보임 - 솔직히 이건 그냥 `git reset --hard`면 해결될 일처럼 보이기도 함 - 이건 **핵심 제품 완성도**보다 기능 추가에 집착한 결과 같음 Anthropic은 시니어 제품 리더가 몇 명 더 있으면 좋겠다는 생각이 자주 들고, “Escaping the Build Trap” 같은 관점이 필요해 보임 지금은 기능을 빨리 붙일 수 있다고 해서 꼭 붙여야 하는 건 아님 유명한 책을 들먹였다고 해서 뻔한 제품 조직 사고를 말하려는 건 아니고, 좋은 제품 감각은 좋은 엔지니어링과는 다른 재능인데 Anthropic은 최근 그 부분이 부족해 보임 - 수요를 따라잡아야 하는데 **compute 자원**이 분명 부족해 보임 그래서 이런 기능을 붙이지 않으면 시스템이 망가지거나 신규 고객을 못 받게 되고, 둘 다 받아들이기 어려우니 선택의 여지가 크지 않았을 수도 있음 - 한때 개발자 100명쯤이 **연 60만 달러**씩 받았던 곳이라 인재 부족이 문제는 아닐 것임 오히려 **vibe coding 서사**를 너무 밀어붙이는 게 문제 같고, 그 때문에 인터뷰 요청을 거절하는 후보도 있다고 함 - 이미 **복잡성 함정**에 깊이 빠진 듯함 모델 자체의 확률성도 문제지만, 이제는 자기들 소프트웨어를 스스로도 제대로 추론하지 못하는 단계처럼 보임 레버와 다이얼이 너무 많고, 코드도 아무도 전체를 이해하지 못할 가능성이 큼 더 나쁜 건 Dario 등의 발언을 보면 경영진이 이런 품질 우려에 별 공감이 없어 보인다는 점임 SWEs가 교체 대상이라는 인식 아래에서 도구에 guard rail을 두자는 요구가 무시되거나 오히려 억제되는 느낌이 있고, 결국 Claude Code는 처음부터 **과학 실험**처럼 출발해서 아직 성숙한 best practice를 갖춘 제품 냄새가 잘 나지 않음