최근 Claude Code 품질 보고에 대한 업데이트

• 최근 한 달간 체감된 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에 정리돼 있음
• 설계상으로는 세션이 한 시간 넘게 유휴 상태였다면, 이전 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를 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에서 확인 가능함
• 이런 장황함은 어려운 문제에서 더 똑똑하게 만들지만, 출력 토큰 수도 늘림
• 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 도구를 개선하고, 이 개선판을 고객에게도 배포할 예정임
• 시스템 프롬프트 변경에는 더 엄격한 통제 절차를 추가함
  • Claude Code의 모든 시스템 프롬프트 변경에 대해 모델별로 폭넓은 평가를 수행함
  • 각 줄의 영향을 이해하기 위한 ablation을 계속 진행함
  • 프롬프트 변경을 더 쉽게 리뷰하고 감사할 수 있는 새 도구도 구축함
• CLAUDE.md에는 모델별 변경이 해당 모델에만 적용되도록 하는 가이드를 추가함
• 지능과 상충할 수 있는 모든 변경에는 soak period, 더 넓은 평가 세트, 점진적 롤아웃을 붙여 문제를 더 빨리 잡도록 함
• 제품 결정과 그 배경을 더 자세히 설명하기 위해 X에 @ClaudeDevs를 만들었고, 같은 업데이트를 GitHub의 중앙화된 스레드에도 공유할 예정임
• /feedback 명령이나 온라인의 구체적이고 재현 가능한 예시를 통해 전달된 정보가 문제 식별과 수정으로 이어짐
• 모든 구독자의 usage limits 초기화는 이날 다시 적용됨

[GN⁺]

Hacker News 의견들

• 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를 갖춘 제품 냄새가 잘 나지 않음