사용자들이 Claude의 형편없는 성능과 구독 가치에 의문을 제기
사용자들은 Claude의 Soul 모델이 플러스 요금제에서 이용 가능함에도 눈에 띄게 성능이 떨어졌다고 보고하며, 일부는 이를 '지구상에서 본 가장 멍청한 모델'이라고 부른다.
진행자는 사용자들에게 월 20달러 구독 요금제의 실제 가치 제안이 무엇인지에 대해 불확실성을 표한다. 그는 자신은 이런 구독을 하지 않아 그 구체적인 사용 패턴을 직접 경험하지 못한다고 언급한다.
최신 AI 모델과 그 성능 과제, 그리고 사용자 피드백부터 기업의 복잡성까지 AI 엔지니어링의 변화하는 패러다임을 탐구한다.
사용자들은 Claude의 Soul 모델이 플러스 요금제에서 이용 가능함에도 눈에 띄게 성능이 떨어졌다고 보고하며, 일부는 이를 '지구상에서 본 가장 멍청한 모델'이라고 부른다.
진행자는 사용자들에게 월 20달러 구독 요금제의 실제 가치 제안이 무엇인지에 대해 불확실성을 표한다. 그는 자신은 이런 구독을 하지 않아 그 구체적인 사용 패턴을 직접 경험하지 못한다고 언급한다.
Theo는 현재의 규제 제안이 소규모 신생 기업보다 주로 '프론티어 랩'에 영향을 미치도록 설계되었다고 주장한다. 그는 현재 제시된 방식의 '규제 포획' 논변에는 타당성이 없다고 말하며, 구체적이고 증거에 기반한 전략이 제시된다면 논의할 의향이 있다고 언급한다. 그는 또한 David Sachs가 역사적으로 구체적 증거 없이 주장을 펼치는 경향이 있는 인물이라고 덧붙인다.
데이터베이스 마이그레이션은 기능 플래그에 의존하기보다 병렬 보조 인스턴스를 실행해야 하며, 진행자는 이러한 복잡한 엔지니어링에 그 방법이 불충분하다고 본다. 그는 이에 대해 다소 무례하게 말할 것이라고 언급하며, 사람들이 복잡한 엔지니어링 과제에 지나치게 단순한 해결책을 제시하는 것에 좌절감을 표현한다.
그는 그들의 팀이 이미 전환 과정을 관리하기 위해 두 번째 데이터베이스를 실행하고 있다고 밝힌다. 그는 지금 다운로드하면 이것이 작동하는 방식이라며, 그들이 복잡한 엔지니어링 과제에 대한 대안을 분명히 고려했다고 강조한다.
이러한 개선을 추적해 온 진행자에 따르면, 성능 업데이트가 Claude 인터페이스의 역사적으로 느리고 메모리 집약적이던 특성을 해결했다. 그는 지금까지 수년간 이것이 그가 이들을 깎아내리는 것을 가장 좋아했던 것 중 하나였다고 언급한다.
그는 모델들이 Anthropic이 자체 소프트웨어를 개선하는 데 도움을 줄 만큼 충분히 효과적으로 변하고 있다고 언급한다. 그는 데스크톱 앱을 포함한 그들의 인터페이스가 최대 3배 빨라졌다는 Anthropic의 주장을 언급한다.
이 진전은 그의 이전 경험, 특히 자신의 T3 코드 데스크톱 앱에서의 성능 문제(일부는 Fable 5 모델의 영향)를 고려할 때 특히 흥미롭다. 그는 Fable 5가 깊이 파고들어 성능 문제를 해결하는 데 최고가 아니라는 것을 발견하고 직접 수정해야 했다고 언급하지만, 5.1과 Opus 55는 더 나아 보인다고 한다.
그는 UI가 더 이상 존재하지 않는 스레드를 계속 나열해, 추가 상호작용 후 결국 사라질 때까지 깨진 것처럼 보이게 한다고 언급한다.
진행자는 Claude Tag를 시작한 사람이 모든 작업을 그것을 통해 하는 사례를 보았다고 언급한다.
그들은 대략 Opus 5.5에 필적한다고 묘사되는 내부 연구 모델을 사용했다. Theo는 내부 테스트가 가드레일이 적은 편이 이점이 되는 경우가 많다고 언급하며, 이는 Chrome 내부를 파고들 때 안전 가드에 부딪힐 가능성이 훨씬 높기 때문에 좋은 지적이라고 말한다.
그는 아직 Opus를 너무 세게 밀어붙이지 않아 희망적이라고 덧붙이지만, 다른 에이전트가 성능 개선 작업 중 보안 플래그나 가드레일에 부딪힌 사례를 기억한다고 말한다. 그는 99%의 시간을 T3 Code에서 보내지만 T3 Code를 수정하고 있었기 때문에 터미널에 있었다고 강조한다.
Theo는 LakeBed의 성능을 위해 극단적 해결책을 장려하도록 설계된 '바다를 끓이는' 프롬프트가 커스텀 런타임과 2~4배 성능 개선으로 이어졌던 경험을 이야기한다.
이 접근법은 AI가 Rusty V8을 포크해 커스텀 런타임을 구축하는 등 비전통적 해결책을 제안하도록 밀어붙였고, 이는 성능을 크게 향상시켰다.
그는 AI 에이전트에게 '엉뚱한' 비표준 아이디어를 탐구할 명시적 허가를 주는 것이 급진적 아키텍처 혁신을 달성하는 데 중요하다고 강조한다.
이 복잡한 작업의 계획 단계는 20분, 초기 빌드는 2시간, 이후 AI가 PR을 완료하는 데 5.5시간이 걸려 이러한 프로젝트에 드는 방대한 노력을 보여주었다.
Theo는 수동 검증 없이 자동화된 PR에만 의존하면 사용자가 보고하지 않을 수 있는 소프트웨어 회귀를 감지하지 못할 수 있다고 경고한다.
그는 개발자가 변경 사항을 개인적으로 테스트할 수 있도록 데스크톱 애플리케이션용 DMG 파일 같은 즉석 빌드를 쉽게 트리거할 수 있는 도구를 구축할 것을 주장한다.
그는 테스트 과정의 마찰을 최소화하는 것이 성능 지표를 측정하는 것만큼 중요하다고 주장하며, 과도한 마찰은 개발자가 철저한 수동 점검을 수행하는 것을 막는다고 말한다.
그는 소규모 스타트업부터 대기업까지 많은 기업이 이 문제로 어려움을 겪으며, PR에서 단일 변경을 테스트하기 위해 15~25분의 과정을 견뎌야 하는 경우가 많다고 강조한다.
Claude의 React 훅 조사는 컴포저 타이핑 경로에서 6,900개의 훅과 900개의 스토어 구독을 발견했으며, 이들 모두가 키 입력마다 재렌더링되고 있었다.
이 발견은 거의 7,000개의 훅이 컴포저 기능을 위해 재계산을 유발하는 비효율을 부각했다.
또한 Claude는 모든 DOM 변경에 24밀리초를 추가하는 단일 루트 'has' 선택자를 식별했다.
이러한 발견은 복잡한 코드베이스에서 심층적인 기술 감사의 필요성을 강조한다.
사용자가 URL을 입력할 때 작동하는 Chrome의 백그라운드 사전 렌더링 과정은 초기 버퍼 크기와 렌더링된 페이지 사이의 불일치를 초래했다.
Chrome은 새 탭 페이지에 자체 56픽셀 푸터를 그리고, 탭이 새 사이트로 이동하면 이 푸터가 사라져 첫 페인트 후 100밀리초 만에 페이지가 56픽셀 더 커진다.
사전 렌더링된 페이지의 크기와 탐색 시 최종 보기 사이의 불일치가 이러한 시프트를 일으켰으며, 정적 컴포저나 Chrome 확장 프로그램의 문제가 아니었다.
발표자는 이러한 브라우저 수준 동작을 추론하는 AI의 능력을 중요한 돌파구로 강조하며, 복잡한 상호작용에 대한 더 깊은 이해를 가능하게 한다고 말했다.
Theo는 성능을 개선하려 시도하기 전에 먼저 측정하고 검증하라고 지시할 때 모델이 크게 향상된다고 강조한다.
이 전략은 모델이 스스로 문제를 올바르게 식별하고 수정하기를 바라는 함정을 피하고, 개선에 대한 구조화된 접근을 보장한다.
AI가 생성한 비효율과 오류인 '슬롭'을 다루고 주변에서 작업하는 것이 현대 엔지니어링 관행의 기술이 되고 있다.
이러한 방법론의 전환은 AI 에이전트를 원하는 결과로 이끌기 위한 새로운 시스템과 구조의 개발을 필요로 한다.
Cloudflare는 T3 Connect를 위한 특정 터널 가격에 접근하려면 연간 최소 5만 달러의 약정을 요구했으며, 이 서비스는 로그아웃한 사용자에게 무료 터널을 광고하고 있었다.
Theo는 Cloudflare가 한편으로는 무료 접근을 홍보하면서 다른 한편으로는 자신 같은 스타트업에 상당한 기업 계약을 압박하는 아이러니를 비판했다.
그는 스타트업의 급여 상당 부분을 소모할 계약에 서명하기를 꺼린다고 표현하며, 그러한 약정은 실행 가능하지 않다고 말했다.
이 진행 중인 협상은 공개 가격 투명성이 부족한 기업 영업 모델을 다룰 때 많은 소규모 기업이 직면하는 마찰을 부각한다.
Theo는 자신의 과거 기술적 예측, 특히 자신의 '틀린' 주장을 보여주는 그래픽을 만든 Omi Pi의 창업자의 비판에 대응했다.
그는 비판자들이 봇을 사용해 자신의 트윗을 긁어모아 맥락이나 반어법을 고려하지 않고 틀려 보이는 댓글만 선택적으로 추출하고 있다고 지적했다.
Theo는 Adobe 인수 실패 후 Figma의 가치 평가 추세 같은 자신의 예측이 초기 반발에도 불구하고 결국 옳았음이 입증되었다고 주장했다.
그는 Figma의 가치 평가가 IPO 대비 84% 하락했다는 점(250% 상승했다는 주장과 반대)과 ChatGPT 래퍼에 대한 반어적 트윗이 진지한 기술 의견으로 오해된 사례를 예로 들었다.
Theo는 Grok 4.7, Opus 5.5, GPT-6 Soul과 Luna를 포함한 새 AI 모델의 빠른 출시가 AI 개발에서 효과적인 '페이싱'을 구성한다고 주장한다.
그는 AI 개발의 진정한 위험은 특정 지능 수준에 도달하는 것이 아니라, 모델이 인간이 이해하기엔 너무 빠르게 개선되는 재귀적 자기 개선의 '이륙' 속도라고 본다.
어셈블리에서 C로의 프로그래밍 진화에 비유하며, 그는 AI의 추상화 계층 증가가 근본 메커니즘을 가려 모델이 '무엇을 어떻게 왜' 작동하는지 이해하기 어렵게 만들 수 있다고 설명한다.
제번스 역설을 인용하여 AI가 더 접근하기 쉽고 비용 효율적이 될수록 적용되는 작업의 전체 규모와 복잡성이 기하급수적으로 확장되어 인간의 이해를 더욱 어렵게 할 것이라고 말한다.
Theo는 특정 제품의 경우 가격 하락이 반드시 사용자 도입의 유의미한 증가로 이어지지는 않는다고 설명하며, 냉장고를 대표적 예로 든다.
그는 미국의 거의 모든 가구가 이미 냉장고를 보유하고 있어, 가격을 3배 저렴하게 만들어도 차고용 두 번째 냉장고를 사는 몇몇을 제외하면 냉장고를 가진 가구 수가 의미 있게 늘지 않을 것이라고 언급한다.
온수나 냉장 같은 인간의 필요는 결국 시장 확장 측면에서 추가 비용 절감이 수확 체감을 낳는 정체기에 도달한다.
이 원리는 AI에도 적용되어, 핵심 필요가 충족되면 모델을 더 효율적이거나 저렴하게 만드는 것이 새로운 애플리케이션이나 사용자의 비례적 증가로 자동 이어지지는 않는다.
Theo는 Opus 5.5, GPT-6, Grok 4.7 같은 현재 AI 모델의 발전이 단순히 '더 똑똑하게' 만드는 것이 아니라 주로 '덜 멍청하게' 만드는 데 초점을 맞추고 있으며, 신뢰성을 핵심 가치 제안으로 강조한다고 주장한다.
그는 모델이 높은 지능을 가지면서 동시에 '멍청'하거나 변덕스러운 행동을 보일 수 있다고 설명하며, 자신이 가장 똑똑하면서도 가장 멍청한 모델 중 하나로 묘사하는 GPT-6 Astra를 예로 든다.
강화 학습(RL)은 성능이 나쁜 데이터를 걸러내고 고성능 모델의 좋은 해결책을 사용해 더 작고 덜 지능적인 모델이 덜 어리석게 행동하도록 훈련하는 이 정교화 과정에서 핵심 역할을 한다.
이 접근법은 더 신뢰할 수 있고 비용 효율적인 모델을 만들어내며, 더 높고 잠재적으로 더 위험한 능력을 밀어붙이기보다 오류 가능성을 줄이고 출력을 더 이해하기 쉽게 만드는 데 초점을 맞춘다.
Opus 5.5에서 '최대 추론'을 활성화하면 정확도가 1%라는 미미한 향상에 그치는데도 토큰 사용량이 15배 증가한다고 진행자가 주장했다.
테스트 결과 '최대 추론'은 토큰 사용량을 15배 늘리면서 정확도는 1%만 개선해 상당한 비효율을 보여주었다.
'최대 추론' 사용 시 작업의 평균 실행 시간이 6초에서 50초로 극적으로 증가해 생산성과 자원 소비에 심각한 영향을 미쳤다.
'최대' 모드 활성화는 작업 복잡성과 무관하게 모델이 전체 추론 능력을 동원하도록 강제해, 다른 추론 수준(Low, Medium, High, X-High)이 허용하는 단순한 문제에 대한 효율적 '덜 생각하기' 능력을 제거한다.
Theo는 AI 모델의 추론 수준(Low, Medium, High, X-High)이 주로 모델이 *생각할 수 있는* 최대 용량을 설정하는 것이지, *얼마나 깊이 생각할지*에 대한 요구가 아니라고 명확히 한다.
낮은 수준과 중간 수준 설정은 모델이 적절한 답을 찾으면 추론을 중단할 수 있게 해 단순한 작업의 효율성을 높인다.
높은 수준과 X-High 설정은 토큰 한도를 늘려 더 깊은 분석이 필요한 복잡한 문제에 더 많은 연산 대역폭을 제공하지만, 단순한 질의를 과도하게 생각하도록 강제하지는 않는다.
최대 추론은 작업 난이도와 무관하게 모델이 전체 용량을 사용하도록 강제한다는 점에서 독특하며, 종종 불필요한 자원 소비와 처리 시간 연장을 초래해 일반적으로 대부분의 애플리케이션에 권장되지 않는다.
특히 OpenAI 모델은 세세한 부분까지 파고들고 일부 보고된 문제가 사소한 것으로 판명되더라도 끈질기게 우려를 식별하는 엄격한 코드 리뷰 접근으로 유명하다.
T3 Code 코드베이스에서 개선 영역을 찾는 모델들을 비교한 벤치마크는 Astra와 Grok 4.7이 각각 8개의 입증된 개선을 찾았고, Soul은 9개를 식별했지만 일부는 심사 패널에 의해 덜 타당한 것으로 평가되었다.
Opus 5.5는 6개 중 4개의 지지된 발견을 한 전임자 Opus 5보다 유효한 코드 문제를 찾는 성능이 향상되었으며, 심사 시스템에서 더 높은 성공률과 더 적은 미지지 발견을 보여주었다.
자막에서 근거가 되는 대목을 찾아 답합니다.
Theo - t3․gg의 다음 글도 받아볼까요?
Theo - t3․gg에 새 영상이 올라오면, 방금 읽으신 것처럼 정리해서 메일로 보내 드릴게요.
이 채널은 지난 7일 동안 7편 올렸어요.