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를 갖춘 제품 냄새가 잘 나지 않음
Hacker News 의견들
1시간 이상 유휴 세션에서 예전 thinking을 지워 지연을 줄였다는 설명이 잘 납득되지 않음
나는 세션을 몇 시간, 며칠씩 비워뒀다가도 전체 컨텍스트 그대로 다시 이어 쓰는 편이라 이 기능이 핵심이었음
기본 thinking 수준을 낮춘 건 어느 정도 이해해도, 시스템 프롬프트가 계속 바뀌는 부분은 내가 의도적으로 refresh 주기를 고를 수 있게 파악해야 할 듯함
문제는 세션을 1시간 넘게 idle 상태로 두면 다시 프롬프트를 보낼 때 N개 전부가 캐시 미스가 난다는 점임
이 corner case가 사용자 토큰 비용을 과도하게 키웠고, 극단적으로 900k tokens 컨텍스트였다면 한 번 복귀할 때 캐시에 900k+ 토큰을 다시 써야 해서 특히 Pro 사용자 rate limit를 크게 깎아먹었음
그래서 X 같은 곳에서 사용자 교육도 해보고, 오래된 대화에 돌아오면
/clear를 권하는 제품 내 팁도 여러 번 넣어봤고, idle 뒤에 오래된 tool 결과·오래된 메시지·thinking 일부를 생략하는 방법도 시험했는데 그중 thinking 제거가 가장 성능이 좋았음그걸 배포하는 과정에서 블로그에 적힌 버그가 의도치 않게 들어갔고, 질문 있으면 더 답하겠다고 함
정말로 출력 품질을 희생해서라도 idle 세션의 지연 감소가 낫다고 믿었거나, 아니면 실제 목적은 비용 절감인데 블로그에서는 latency를 그럴듯한 명분으로 쓴 것처럼 보임
컨텍스트를 다시 불러오는 동안 로딩 표시를 더 분명히 보여주는 쪽이 훨씬 자연스러웠을 듯함
예전에는 CC를 동료처럼 두고 문제를 좀 고민하다가, 계획을 업데이트하고, 샤워하면서 생각했다가, 새 조언을 던지는 식으로 썼고 적어도 하루 정도는 정적인 대화라고 여겼음
그런데 기준이 1시간이라면 너무 짧아서 anthropic 플랜을 계속 유지할지 다시 생각하게 됨
우연이라기보다 비용을 크게 낮추는 변경이었을 가능성이 높아 보임
한도를 다 써서 세션을 쉬게 둔 뒤 다시 돌아오는 사용자가 많다면 이건 예외가 아니라 거의 기본 사용 패턴에 가까움
이 정도로 두들겨 맞는 건 좀 의외임
글 자체는 비교적 명확하고 솔직했고 충분히 그럴듯하게 읽혔음
성능 저하는 실제였고 짜증났지만, 동시에 뒤에서 정확히 무슨 일이 벌어지는지 보이지 않는 불투명성과 자의적인 토큰 비용 청구 구조를 드러내기도 했음
LLM API를 직접 다뤄본 입장에서는 오래 비운 대화를 다시 이어갈 때 추가 비용과 지연이 생긴다는 게 자명했지만, TUI에서는 이 점을 더 눈에 띄게 알려줄 필요는 있어 보임
그래서 지금 설명이 나와도 반감이 큰 것임
품질 하락 일부는 모델이 실제로 나빠진 게 아니라 비결정성 때문에 생기는 체감 차이일 수도 있다고 봄
몇 주 전 Claude에게 개인용 생산성 앱을 만들게 하려고 원하는 동작을 긴 글로 설명하고 구현 계획을 써달라 했는데, 첫 결과물은 모호했던 한 부분만 빼면 정말 훌륭했음
그 모호함을 고친 뒤 기존 계획을 수정시키지 않고 새 채팅에서 처음부터 다시 시켜봤더니, 모델 설정은 그대로였는데 결과가 훨씬 나빴고 그다음 두 번도 망했으며 네 번째 시도에서야 처음 수준으로 돌아왔음
그래서 같은 작업을 그냥 다시 시키는 게 종종 더 좋은 출력을 얻는 방법일 수 있다고 느꼈고, 다만 자기 토큰으로 결제하면 금방 비싸질 수 있음
모델이 주기적으로 나빠진다고 느끼는 패턴이 있지만, 실제로는 한계에 깊게 부딪히는 순간이 늦게 올 뿐일 수도 있음
그리고 한 번 운 나쁜 출력을 겪고 나면 그 이후로는 계속 그것만 보이게 됨
Anthropic 입장에서는 이런 사용 패턴이 토큰 소비를 늘리니 반길 만한 그림이기도 함
비결정성은 원래 계속 있었고, 널리 보고된 최근 품질 저하는 별개의 현상일 수 있음
나는 Opus 4.7에서 이미 마음이 떠났음
OpenAI가 우리 엔터프라이즈 쪽에 정말 집요하게 들어오려 하고 있고, 여름까지 무제한 토큰까지 제안했음
그래서 GPT5.4를 extra high effort로 지난 30일 써봤는데, 특별 대우를 받는 건지 모르겠지만 거의 실수를 못 봤음
reasoning trace도 가끔은 웃음이 날 정도로 좋았고, 내가 지시를 빼먹은 부분까지 미리 따라가면서 데이터 무결성을 100% 맞추는 데 필요한 요소를 챙겨줬음
이런 온갖 꼼수성 변경은 Anthropic이 compute 제약이 심해서, 줄이려고 무리수를 두기 때문일 가능성이 큼
그래서 5.5가 얼마나 더 좋아질지 기대됨
작업의 90%는 5.4를 medium으로 돌리고, medium이 버거워 보일 때만 high로 올리는 편이 훨씬 집중도 있고 변경도 최소화됨
게다가 조금 더 저렴함
최근 Claude가 자기 내부 프롬프트에 답하는 식의 출력을 자주 냄
예를 들면 괄호 안 문장이 프롬프트 인젝션 시도라서 무시하겠다고 하거나, 자기 일반 가이드라인을 숨기라는 시도처럼 보여 따르지 않겠다고 하거나, 그런 방식은 원래 늘 적용하고 있어서 불필요하다고 말함
나는 그런 시도를 전혀 하지 않았는데도 응답 끝에 이런 문구를 자주 붙임
내부 가이드라인 중 뭔가 조잡한 부분이 있고, 그걸 내 질문과 제대로 구분하지 못하는 듯함
이유를 물으면 필요 없다고 생각했다고 답함
회사들이 토큰 churn을 늘리는 쉬운 방법 같기도 함
그러면 모델이 무언가를 단정하고, 그걸 기억으로 저장하고, 다시 그 기억을 보고 더 쌓아 올리는 자기강화 루프가 생기며, 내가 멈추라고 명시해도 계속될 때가 있음
너무 높은 reasoning effort에서 나는 냄새일 수도 있어서, 해당 프롬프트는 추론 강도를 조금 낮추면 나아질 가능성이 있어 보임
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시간 이상 걸릴 가능성이 매우 높음
자기들 사용 습관을 사용자 전체 행동으로 착각하는 게 제품 개발의 흔한 함정임
대형 frontier lab들이 취한 블랙박스 접근은 결국 사람들을 떠나게 만들 것임
이렇게 근본 동작을 바꾸면서 미리 알리지도 않고 나중에야 해명하면, 사용자들은 결국 자체 호스팅 모델 쪽으로 갈 수밖에 없음
바닥이 계속 흔들리는 기반 위에서는 파이프라인, 워크플로, 제품을 안정적으로 쌓을 수 없음
Anthropic 쪽 Claude Code 담당자들이 댓글을 읽는 듯한데, 며칠 전 theo t3.gg가 Claude가 멍청해졌는지 다룬 영상을 봤음
톤은 거칠고 심한 말도 했지만, 특히 harness bloat 관련 지적은 꽤 정확하다고 느꼈음
이제는 새 기능 추가를 잠시 멈추고, 다듬기와 최적화를 강하게 밀어붙여야 한다고 봄
그렇지 않으면 더 가볍고 최적화된 대안을 찾는 사람이 많아질 것이고, 핵심은 harness를 더 좋게 만들고 토큰 소모를 줄이는 것임
https://youtu.be/KFisvc-AMII?is=NskPZ21BAe6eyGTh
벤더 락인은 계속 경계하고 있었지만 그 사건이 좋은 경고가 됐고, 아마 opencode+openrouter를 먼저 볼 듯함
일부 콘텐츠 제작자와 OpenAI 사이에는 돈이든 영향력이든 뒤에서 오가는 게 분명해 보임
git reset --hard면 해결될 일처럼 보이기도 함이건 핵심 제품 완성도보다 기능 추가에 집착한 결과 같음
Anthropic은 시니어 제품 리더가 몇 명 더 있으면 좋겠다는 생각이 자주 들고, “Escaping the Build Trap” 같은 관점이 필요해 보임
지금은 기능을 빨리 붙일 수 있다고 해서 꼭 붙여야 하는 건 아님
유명한 책을 들먹였다고 해서 뻔한 제품 조직 사고를 말하려는 건 아니고, 좋은 제품 감각은 좋은 엔지니어링과는 다른 재능인데 Anthropic은 최근 그 부분이 부족해 보임
그래서 이런 기능을 붙이지 않으면 시스템이 망가지거나 신규 고객을 못 받게 되고, 둘 다 받아들이기 어려우니 선택의 여지가 크지 않았을 수도 있음
오히려 vibe coding 서사를 너무 밀어붙이는 게 문제 같고, 그 때문에 인터뷰 요청을 거절하는 후보도 있다고 함
모델 자체의 확률성도 문제지만, 이제는 자기들 소프트웨어를 스스로도 제대로 추론하지 못하는 단계처럼 보임
레버와 다이얼이 너무 많고, 코드도 아무도 전체를 이해하지 못할 가능성이 큼
더 나쁜 건 Dario 등의 발언을 보면 경영진이 이런 품질 우려에 별 공감이 없어 보인다는 점임
SWEs가 교체 대상이라는 인식 아래에서 도구에 guard rail을 두자는 요구가 무시되거나 오히려 억제되는 느낌이 있고, 결국 Claude Code는 처음부터 과학 실험처럼 출발해서 아직 성숙한 best practice를 갖춘 제품 냄새가 잘 나지 않음