Meta가 Anthropic을 따라잡은 순간

• 원문 제목: Meta just caught up with Anthropic
• URL: https://www.youtube.com/watch?v=DbWL6Zs2j_g
• 날짜: 2026-10-13
• 채널: t3dotgg (Theo - t3․gg)
• 영상 길이: 38분 02초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==Meta의 새 모델 Muse Wonderful Full은 Anthropic·OpenAI의 프런티어 모델과 실전 개발 작업에서 경쟁할 수 있는가?==

• Meta는 Spark 계열의 무난한 개선을 넘어, 장시간 코딩·에이전트 오케스트레이션·코드 리뷰에서 실제로 사용할 만한 모델을 내놓았다.
• Wonderful Full은 모든 벤치마크에서 최고는 아니지만, 낮은 멍청함(dumbness), 빠른 탐색, 읽기 쉬운 결과, 여러 에이전트를 조율하는 능력이 강점이다.
• 3D·공간 추론과 UI 생성은 약하고, 일반 API로 공개된 작은 Muse Wonder는 Full 버전보다 성능이 크게 낮다.
• 가격이 공개되지 않은 Full 버전의 경제성은 아직 판단할 수 없지만, Meta가 세 번째 프런티어 축으로 올라오면서 Anthropic과 OpenAI의 경쟁 구도가 바뀐다.

Meta의 성과는 단순한 벤치마크 순위 상승보다 실전 사용감에서 드러난다. Wonderful Full은 가장 어려운 설계 문제에서는 Opus에 밀리지만, 문제의 핵심 파일과 기존 PR을 빠르게 찾고, 과도한 추론과 엉뚱한 변경을 줄이며, 다른 모델을 적절히 호출한다. Theo는 최고 지능의 천장보다 낮은 실수율과 새로운 응답 스타일을 더 높게 평가하며, 일반 업무에는 Muse를 쓰고 위험한 설계에는 Opus를 병행하는 구성을 제안한다.

1. Meta의 모델 출시와 평가 조건

Muse Wonderful Full은 Meta가 기존 대형 연구소 밖에서 내놓은 모델 중 처음으로 프런티어급 장기 작업을 맡길 수 있다고 평가받은 사례다.

1.1. Spark에서 Wonder로의 도약

1. 예상 밖의 품질 상승

   1. Meta Muse Spark 1.2는 기대를 받았지만 평범한 모델에 가까웠고, Spark 1.3도 큰 인상을 남기지 못했다.
   2. Muse Wonder는 Theo가 며칠 동안 직접 사용한 뒤에도 계속 인상적이었으며, Artificial Analysis에서 Muse Wonderful Full이 OpenAI 모델 전체를 넘어 종합 3위권에 들어가는 결과를 보였다.
   3. Meta가 Anthropic이나 OpenAI가 아닌 연구소에서 Anthropic·OpenAI와 같은 급의 모델을 출시했다는 점 자체가 핵심 사건이다.

2. 후원과 독립성 공개

   1. Meta는 이 리뷰에 비용을 지급하지 않았고, Theo는 조기 테스트 권한만 받았다고 밝혔다.
   2. 실제 영상 후원자는 Browserbase이며, Meta 모델에 대한 긍정적 평가와 후원 관계를 분리했다.

1.2. 출시 제품이 둘로 갈린 문제

1. Muse Wonder와 Muse Wonderful Full의 분리

   1. Muse Wonder는 약 120 TPS로 실행되고 API로 제공되며 가격도 공개되어 있다.
   2. Muse Wonderful Full은 약 50 TPS로 실행되어 더 크고 느린 별도 모델처럼 보인다.
   3. Full 버전은 Muse Code 구독에서만 쓸 수 있고 API 가격이 공개되지 않아, 성능 대비 가격을 계산할 수 없다.

2. 가격 공개의 공백

   1. 일반 Muse Wonder의 가격은 입력 100만 토큰당 4달러, 출력 100만 토큰당 20달러, 캐시 읽기 100만 토큰당 0.20달러다.
   2. 이 가격은 Opus보다 약간 싸지만, Meta가 벤치마크에서 크게 홍보한 모델은 대부분 Wonderful Full이므로 일반 버전의 가격만으로 출시를 평가하기 어렵다.
   3. Full 버전은 일반 버전보다 훨씬 비쌀 가능성이 있으며, Opus 5.5보다 비싸다면 지불할 가치가 낮을 수 있다.
   4. Meta는 발표문에서 Full 버전의 벤치마크 점수는 보여줬지만 가격은 공개하지 않았다. 컴퓨트가 크게 부족한 상황이라 해도 최소한의 가격 지표는 제공했어야 한다.

2. 명확한 약점: 3D와 UI

Muse Wonderful Full은 범용 지능이 높아도 특정 후처리 학습이 필요한 능력에서는 취약하다.

2.1. 3D 작업의 실패

1. Blender·3D 생성물의 낮은 품질

   1. 트랙터 데모에서 Opus 5.5와 비교하면 Muse Wonderful Full의 3D 결과가 크게 뒤처진다.
   2. Blender에서 만든 모델은 형상·색상·조명 처리가 엉성하고, 특히 측면의 색과 빛을 다루는 방식이 나쁘다.
   3. Fish Slop 테스트에서는 이동과 핵심 게임 메커니즘은 Grok 4.7보다 나았지만, 애니메이션과 3D 모델 품질은 낮았다.
   4. Sonnet·Opus가 Muse를 압도했고 Fable도 더 나았지만, Fable의 3D 능력 자체는 최고 수준까지는 아니었다.

2. 지능과 3D 능력의 분리

   1. Meta도 모델의 제한 사항으로 시각·공간 추론, 특히 3D 작업을 명시했다.
   2. 스마트한 코딩 모델이 자동으로 3D에 강해지는 것은 아니다. 3D 모델링과 컴퓨터 사용 같은 능력은 특정 환경에서 후처리 학습으로 주입된다.
   3. 외부 회사가 만든 3D 훈련 환경을 여러 연구소에 판매하고 있으며, Kimmy K3 이후 프런티어 모델들이 비슷하게 3D 능력을 끌어올린 현상도 이 설명과 맞는다.
   4. Fable 5.1과 Opus 5.5는 전체 지능 차이가 약 5% 안팎이어도 3D 성능에서 큰 격차를 보인다. 전체적으로 더 똑똑한 모델이 3D에 약할 수 있고, 전체 능력이 낮아도 3D에 강하면 인상적일 수 있다는 뜻이다.

2.2. Skatebench와 UI 생성

1. Skatebench의 특이한 결과

   1. Skatebench는 강화학습이 모델을 오히려 망가뜨리는 듯한 이상한 결과가 있어 정식 핵심 벤치마크라기보다 모델 성향을 보는 재미있는 테스트로 사용됐다.
   2. Opus 5 Max는 84%, Opus 5.5 Max는 79%였고, Gemini 계열만 기존에 90%를 넘겼다.
   3. Gemini 3.1 Pro와 3.8 Flash High는 96%를 기록했고, Muse Wonderful Full도 95%를 기록했다.
   4. Gemini는 복잡한 문법, 내부적인 3D 변환 이해, 사진 속 대상의 픽셀 단위 라벨링에 강하며, 이 능력들이 합쳐져 스케이트보드 트릭 이름 맞히기에도 강해진다. Muse에서도 비슷한 특성이 관찰되어 다른 영역을 망가뜨린 것은 아닌지 확인하게 만들었다.

2. 끔찍한 UI 생성

   1. Muse는 Grok처럼 틀린 UI를 만드는 유형이 아니라, Sonnet 3.7처럼 동작은 하지만 디자인이 슬롭(slop)인 UI를 만든다.
   2. 커널 디버깅·아름다운 UI·게임 제작을 모두 한 모델에 맡길 범용성을 원한다면 Claude가 더 적합하다.
   3. Theo가 직접 만든 테스트 UI도 “죄악처럼 못생긴(sinfully ugly)” 결과였으며, 모델의 강점은 프런트엔드 미감이 아니다.

3. 실전 코딩에서 발견한 차별점

Muse Wonderful Full의 가치는 정답률 하나보다 문제를 읽고 적절한 범위에서 해결하는 방식에 있다.

3.1. Reskate와 Lust를 통한 코드 작업

1. Reskate·Thunder Store 감사

   1. Reskate는 Steam판 EA Skate를 위한 오픈소스 래퍼로, P2P 플레이·모드·옛날 맵을 지원한다.
   2. Thunder Store의 인덱싱이 느려서 전체 저장소를 감사하게 했고, Muse는 CDN 자체가 아니라 캐시되지 않는 데이터가 병목이라고 진단했다.
   3. Reskate 인덱스는 0.48MB이고 웜 엣지(warm edge)에서는 0.78초에 로드되므로, 문제는 콜드 경로와 규모가 커졌을 때 발생한다고 설명했다.
   4. Theo는 이 답변이 완벽한 PR이나 코드 변경을 내놓아서가 아니라, 흔한 Claude식 문체와 다른 “새로운 종류의 슬롭”으로 읽기 편했다는 점을 높게 평가했다.

2. Lust 컴파일러 프로젝트

   1. Lust는 Rust의 하위 집합으로, 100배 빠른 컴파일을 목표로 하는 개인 프로젝트다.
   2. Rust로 Typer 컴파일러를 다시 쓴 뒤, 자체 언어용 컴파일러를 만들어 TS Rust를 그 언어로 다시 컴파일하려는 실험을 진행했다.
   3. 장기 실행 스레드는 115개가 넘는 에이전트를 병렬로 띄워 작업을 나눴다.
   4. Muse와 Opus를 각각 실행하고 변경 결과를 심사하는 블라인드 판정단을 구성했다. Opus는 더 정확하고 깊은 작업을 했고, Muse는 더 많은 작업을 더 빨리 했다.
   5. 세 명의 블라인드 판정자는 모두 Opus를 선택했으며 평균 점수는 50점 만점에 Opus 41점, Muse 30점이었다. 해당 특정 과제에서는 Opus 버전의 빌드가 약 2.5배 빨랐고 Muse 버전에는 버그가 있었다.

3.2. 일상 작업·리뷰·판정 역할

1. Muse의 실전 결과

   1. Muse는 예외가 통과하면 안 되는 상황을 통과시키던 여러 문제를 고치고, 드라이버 계층을 수정하고, 이름 관련 버그를 해결했다.
   2. Opus의 수정 사항을 검토하며 209개의 프로브(probe)를 작성했고, 수정 그룹을 명확하게 제시했다.
   3. 판정자로서는 공정하게 평가했고 자기 결과를 1위가 아닌 2위로 놓을 정도로 자기편향이 적었다.
   4. 두 모델이 서로의 계획을 검토하게 하면 Muse 계획을 기본으로 삼고 Opus의 피드백을 더하는 경우가 자주 나왔다. 반대로 Muse가 Opus 계획을 택하는 경우도 있었다.

2. 역할 분담 결론

   1. Muse는 대부분의 작업, 수정 작업, 표준 라이브러리, 퍼징(fuzzing), 코드 리뷰에 적합하다.
   2. Opus는 잘못된 설계의 비용이 큰 어려운 작업, T2 속도 병합, 트레이트 시스템 수정 같은 하드코어 문제를 맡는 편이 낫다.
   3. 양쪽 모델이 서로의 작업을 검토하고 모든 리뷰를 수정 사항으로 되돌리면 효율적인 조합이 된다.
   4. Opus는 Muse를 B+, 자신을 A-로 평가했다. Muse는 품질이 더 낮지만 더 빠르고, Opus는 품질이 높지만 더 느리고 비싸다는 판단이다. 다만 Muse Wonderful Full의 실제 비용은 아직 모른다.

4. 에이전트 오케스트레이션과 ‘낮은 멍청함’

Muse Wonderful Full은 다른 모델과 장시간 작업을 조율하는 능력에서 Meta의 이전 모델과 다른 모습을 보인다.

4.1. 위임 프롬프트와 대규모 조율

1. 좋은 연구 서브에이전트 프롬프트

   1. T3 Code 저장소의 여러 부분을 분석하도록 세 개의 위임 에이전트를 띄웠다.
   2. 한 에이전트는 T3 코드의 계약·프로바이더·에이전트 통합 계층을 조사하고, MCP·프로바이더·에이전트가 서버와 연결되는 방식을 실제 구현으로 설명하도록 지시받았다.
   3. 검색 결과는 후보를 찾는 데만 쓰고, 실제 파일을 열지 않은 주장은 인용하지 말며, 분석 단계에서는 파일을 수정하지 말라는 제약도 포함됐다.
   4. Muse는 스스로 이런 구체적이고 검증 가능한 프롬프트를 작성하며, 다른 모델에게 일을 시키고 메시지를 전달하는 지휘관 역할을 안정적으로 수행했다.

2. 프런티어급으로 느껴지는 이유

   1. 수많은 위임 작업을 동시에 운영하고, 긴 작업에서 어느 모델을 어느 단계에 투입할지 결정하는 능력은 Anthropic·OpenAI 밖의 모델이 자주 약했던 영역이다.
   2. Muse는 장기 작업을 맡겨도 되는 최초의 비(非)Anthropic·비(非)OpenAI 모델처럼 보이며, 단순히 더 똑똑한 모델이 아니라 세 번째 프런티어 스타일을 제시한다.
   3. Theo는 오디오 장비 리뷰어가 다른 스피커와 완전히 다른 소리를 내는 제품을 더 좋아할 수 있는 것처럼, 모델을 많이 평가하는 사람에게 ‘다름’ 자체가 편향으로 작용할 수 있다고 인정했다.
   4. Muse는 기존 Claude의 말투와 행동을 단순 복제하지 않았다. Meta가 Claude에서 얻은 데이터가 많더라도 결과가 Claude 증류판처럼 느껴지지 않는 점이 매력으로 작용했다.

4.2. 낮은 지능과 낮은 멍청함은 다른 축이다

1. 평가 축의 분리

   1. 똑똑함과 멍청함은 서로 다른 특성이라서, 매우 똑똑하면서도 황당한 실수를 자주 하는 모델이 있을 수 있다.
   2. Astra는 똑똑하지만 멍청한 사례가 많아 멍청함 10/10으로 평가됐다.
   3. Opus는 똑똑함 10/10, 멍청함 3/10 정도다.
   4. Muse Wonderful Full은 지능의 천장이 8~9/10으로 Opus보다 낮지만, 멍청함은 1~2/10으로 더 낮다.

2. 실수의 종류

   1. Muse는 UI와 3D 결과가 못생기고 약하지만, 존재하면 안 되는 폴더를 지우거나 저장소를 망가뜨리는 식의 황당한 실수를 거의 하지 않았다.
   2. 4~5일 동안 Muse의 한계를 밀어붙인 동안 발생한 이상한 경험이, Soul과 Astra를 영상 준비 과정에서 30분 사용하며 겪은 이상한 경험보다 적었다.
   3. 일상 개발에서는 최고 난도의 정답보다 망가진 상태를 만들지 않는 높은 바닥(floor)이 더 유용할 때가 있다.

5. T3 Code 원격 업데이트 버그 사례

같은 버그를 Opus·Soul·Muse에 맡기자 모델의 지능보다 읽기 방식과 범위 통제가 더 중요한 차이를 만들었다.

5.1. 문제의 구조와 Opus의 처리

1. 버그 발생 경로

   1. T3 Code에는 모든 원격 머신과 프로바이더를 한 번에 업데이트하는 기능이 추가됐다.
   2. 화면 아래 버튼을 누른 뒤 확인을 누르는 두 번의 클릭으로 실행되지만, 원격 머신의 T3 Code 런타임 자체는 업데이트하지 않았다.
   3. Opus는 실행 이력을 보고 이미 업데이트된 것으로 오해했지만, 수동으로 업데이트한 이력을 알려주자 버그를 찾아 수정했다.

2. Opus의 장단점

   1. 로그·수정·검사를 모두 기록하고 PR을 열었으며, 필요한 경우 Soul을 리뷰에 호출했다.
   2. 다만 결과 보고서가 지나치게 길었고, 로그에 있는 모든 내용을 다시 늘어놓아 핵심 원인과 조치가 묻혔다.
   3. npm에 접근할 수 없을 때 검사가 조용히 실패한다는 사실 등은 정확했지만, 사용자가 가장 먼저 알아야 할 정보가 앞에 정리되지 않았다.

5.2. Soul과 Muse의 처리 비교

1. Soul의 잘못된 수정

   1. Soul은 사이드바의 원격 업데이트 선택 규칙을 새 흐름과 연결하지 못했고, 프롬프트에 적힌 “새 업데이트 전체 흐름”이라는 핵심을 놓쳤다.
   2. 프록시와 비동기 질문 도구가 충돌하자 로컬에서 고쳤다고 보고했지만, 원격 서버에 어떤 앱 버전을 배포해야 하는지 해결하지 않았다.
   3. npm 검사가 대기·실패하면 사이드바에서 원격 서버를 제외하도록 바꿨는데, 실제 해결책은 로컬 앱을 먼저 업데이트한 뒤 현재 버전을 원격 서버에 밀어 넣는 순서를 보장하는 것이다.
   4. 잘못된 수정은 로컬 앱만 업데이트하고 Muse·Cursor·Claude·Codex의 원격 환경을 오래된 버전으로 남길 수 있었다.

2. Muse의 진단

   1. Muse는 “한 번의 실패한 웹 요청 때문에 흐름 전체가 깨졌다”는 핵심을 처음에 제시했고, 작업 트리에는 코드 변경을 만들지 않았다.
   2. npm 공개 여부 확인이 Effect HTTP 클라이언트를 사용하고, 요청에 두 개의 trace 헤더를 넣는다는 구현을 직접 확인했다.
   3. 현재 코드를 테스트 fetch로 실행해 두 헤더가 실제 요청에 포함된다는 것도 검증했다.
   4. 이미 열린 두 PR이 같은 한 줄 변경으로 문제를 해결한다는 사실을 찾았고, 그중 다른 사람이 올린 더 작고 깨끗한 PR을 병합하라고 제안했다. Opus와 Soul은 이 기존 PR을 찾지 못했다.
   5. Muse의 보고서는 훨씬 짧고 읽기 쉬웠으며, 다른 모델의 PR을 재활용해 불필요한 변경을 줄였다. Theo는 이 유형의 버그 보고와 기존 PR 탐색을 앞으로 Muse에 계속 맡길 계획이다.

6. 코드베이스 감사 벤치마크와 효율성

모델의 실전 성능은 저장소·작업 유형에 따라 달라지지만, Wonderful Full은 정확도와 시간·토큰 사용량의 균형이 좋다.

6.1. T3 Code·Lakebed·TS Rust 감사

1. 아키텍처 감사

   1. T3 Code 전체 아키텍처를 감사한 비공식 벤치마크에서 Opus 5.5가 압도적으로 앞섰고 Sonnet 5.5도 예상보다 잘했다.
   2. Soul과 Astra가 뒤를 이었으며 Muse Wonderful Full은 이 그룹 바로 아래였다.
   3. 일반 Muse Wonder는 Wonderful Full의 거의 절반 수준으로 떨어져, Full과 일반 버전 사이에 30%가 넘는 분석 품질 차이가 났다.
   4. API를 평소 도구에 연결한 사용자들이 나쁜 결과를 보고하는 이유는 일반 Muse Wonder를 사용하기 때문일 가능성이 높다. 일반 버전은 가격 대비 매력도도 낮다.

2. Lakebed 감사

   1. Theo의 클라우드 제품 Lakebed 감사에서는 Soul이 모든 판정자에게 9/10을 받아 가장 좋은 분석을 냈다.
   2. 일반 Muse Wonder는 5.75점으로 크게 낮았고, Opus 5.5·Astra·Sonnet은 서로 가까운 점수를 기록했다.
   3. Sonnet이 Opus보다 높게 나온 점은 이 벤치마크가 완벽한 측정법이 아님을 보여준다.

3. 실행 시간

   1. Wonderful Full은 Lakebed 감사 결과를 약 16분에 만들었고 Soul보다 거의 절반, Opus보다 훨씬 짧았다.
   2. Sonnet은 같은 작업에 80분이 걸렸다.
   3. TS Rust 감사에서도 Wonderful Full은 약 17분에 Fable 5.1과 거의 같은 점수를 냈다.
   4. 일반 Muse Wonder는 약 5분 9초로 가장 빨랐지만 점수가 낮아 속도만으로 우위를 주장할 수 없었다.

6.2. 토큰 효율과 모델별 리뷰

1. 토큰 사용량

   1. 비용을 모르는 Wonderful Full은 가격 대비 지능을 산출할 수 없지만, Opus 5.5 X High와 거의 같은 점수를 더 적은 토큰으로 냈다.
   2. Wonderful Full은 Max 계열로 표시되어 비교에서 제외되기도 했지만, Max를 제외하면 5.5 X High 바로 아래의 최고 득점 모델이었다.
   3. Gemini 4 Argan은 약간 더 많은 토큰을 사용했고, Opus·Fable 등 주요 모델은 더 많은 토큰을 사용했다. Sonnet은 토큰 사용량이 가장 높았다.
   4. 일반 Muse Wonder는 과제당 약 54.2K 토큰, Wonderful Full은 약 53.8K 토큰으로 거의 같았다. 지능 차이가 큰 두 모델이 비슷한 토큰을 쓰는 점은 이상한 결과다.

2. 미병합 PR 8건 리뷰

   1. Opus 5.5는 총 23개를 찾아 21개가 유효했고, 1개는 개연성 있는 지적, 1개는 오판이었다. 독창적인 문제를 가장 많이 찾았지만 PR마다 사소한 nit을 평균 한 개씩 추가하고 의도된 동작을 버그로 지목한 경우도 있었다.
   2. Soul 61은 9개를 찾아 7개가 유효하고 2개가 무효였다. nit은 전혀 없었지만 작은 PR 네 개 중 세 개에서는 실제 문제가 있어도 아무것도 찾지 못했다.
   3. Muse는 16개를 찾아 다섯 개가 독창적인 지적이었다. 다른 모델과의 중복이 가장 많아 단독 리뷰어로 쓰기 좋고, Opus가 놓친 busy reopen 토큰 폐기 문제를 찾았다.
   4. Muse의 고유 지적 대부분은 심각도가 낮았고, PR 설명에 이미 적힌 공백을 수정하라고 한 사례도 있었다. 그래도 Opus의 과잉 지적과 Soul의 과소 지적 사이에서 좋은 중간 지점이었다.

7. 10개 에이전트의 제품 우선순위 조사

코드·GitHub 이슈·PR·토론을 함께 조사하면 Muse의 직관과 가독성이 Opus의 깊이와 다른 가치를 만든다.

7.1. Opus와 Muse의 조사 방식

1. Opus 조사

   1. Opus는 10개 에이전트를 사용해 공개 이슈·PR·토론과 코드베이스를 깊게 조사했다.
   2. 10시 33분에 시작해 11시 04분에 결과를 내는 데 약 30분이 걸렸다.
   3. 결과는 “T3 Code에서 다음에 무엇을 할 것인가”를 정리했지만, 항목마다 문장이 많고 같은 내용을 반복해 읽기 어려웠다.
   4. Ship v2를 안정적으로 출시하는 일이 우선이고, 작성보다 병합이 병목이며, 사용자는 새 기능보다 신뢰성을 원하고, 실행 중 멈춘 서버 자원 회수가 가장 큰 고통이라는 핵심은 잡았다.

2. Muse 조사

   1. Muse는 10개 연구 에이전트를 사용하고 한 명의 비판 에이전트가 상위 주장을 반증하려 했다.
   2. 핵심 Git 수치와 코드 검사를 다시 직접 실행해 근거를 확인했다.
   3. 10시 24분에 시작해 10시 31분에 완료됐고, 리셋으로 발생한 추가 시간을 합쳐도 약 17분으로 Opus의 절반 정도였다.
   4. Muse는 거대한 Meta 코드베이스에서 학습했는지는 알 수 없지만, 어디를 먼저 확인해야 하는지 아는 직관이 강하고 불필요한 파일·토큰을 덜 소비했다.

7.2. Muse가 제시한 우선순위

1. 결정해야 할 방향

   1. P0가 출시될 때까지 새 프로바이더와 서비스를 동결한다. 프로바이더 범위가 상위 이슈 군집을 만든다.
   2. 제목 검색에서 Claude 관련 이슈가 118건, Codex 관련 이슈가 76건 잡혔다는 수치가 근거로 제시됐다.
   3. 레거시 사이드바를 제거한다. 두 사이드바를 동시에 유지하면 모든 수정이 두 번 필요하다.
   4. Discussion은 실제 출시 상태를 확인하기 전까지 검증되지 않은 수요로 취급한다. Discussion은 자동으로 닫히지 않으므로 그것만 보고 리뷰 병목을 단정하면 안 된다.

2. P0: 다음 2주에 처리할 일

   1. 서버 멈춤 두 건 수정: 한 프로바이더가 멈춘 워커 하나를 붙잡으면 Effect 워커 네 개 전체가 막히므로, 타임아웃이 난 워커를 프로바이더별로 격리한다.
   2. PR 쿼터·페이로드 소모 중단: Bitbucket이 100분 동안 2,800회, GitLab이 12.5시간 동안 22,423회 호출됐다. 포커스 시 재조회하지 말고 PR별 캐시를 두며 쿼터 오류에는 백오프한다.
   3. 프로바이더 최초 사용 문제 수정: 코드에는 내장 모델이 29개만 보이는데 프로바이더가 제때 모델 목록을 보내지 않아 잘못된 모델 세트가 표시된다.
   4. 스코프 고립 문제를 뿌리에서 해결: 개별 스코프를 임시로 고치는 대신 시스템 수준에서 고친다.
   5. 데이터 손실·결제 화면을 일주일간 재현: 환경 파일 삭제, 설정 변경 되돌림, 취소 후에도 구독 결제가 계속된다는 신고는 건수가 적지만 심각도가 높다. 근거가 얇으므로 현재 나이틀리 버전에서 먼저 재현한다.

3. P1·P2 정리

   1. P1은 규모가 작고 명확한 수정들을, P2는 나중에 하거나 지금 하지 않을 일을 묶었다.
   2. 각 항목 앞에 중요한 문장을 굵게 배치하고, 영향·근거·크기를 짧게 붙여 Opus의 장문 보고서보다 우선순위를 읽기 쉽게 만들었다.

주요 발언 모음

“이 모델은 똑똑함의 천장은 조금 낮지만, 멍청함은 더 낮다. 그냥 멍청한 일을 하지 않는다.”

“Muse는 더 많은 일을 더 빨리 하고, Opus는 더 정확하고 깊게 일한다.”

“지능과 3D 능력은 직접 연결되지 않는다. 3D는 특정 작업을 위해 따로 훈련된다.”

“이 모델은 바보 같은 실수를 하기보다 못생긴 결과를 낸다. 프런트엔드와 3D에는 약하지만 시스템을 망가뜨리지는 않는다.”

“벤치마크는 이미 존재하는 더 작은 PR을 찾아 병합하라고 말하는 이런 유용함을 제대로 측정하지 못한다.”

“Meta가 따라잡았다는 사실 자체가 중요하다. 세 번째 플레이어가 생기면 미래의 경쟁은 훨씬 강해진다.”

핵심 데이터 & 수치

• 영상 길이: 38분 02초.
• 모델 처리 속도: Muse Wonder 약 120 TPS, Muse Wonderful Full 약 50 TPS.
• 일반 Muse Wonder 가격: 입력 100만 토큰 4달러, 출력 100만 토큰 20달러, 캐시 읽기 100만 토큰 0.20달러.
• Skatebench: Opus 5 Max 84%, Opus 5.5 Max 79%, Gemini 계열 96%, Muse Wonderful Full 95%.
• Reskate 인덱스: 0.48MB, 웜 엣지 로드 0.78초. 병목은 콜드 경로와 확장 시 데이터 캐시다.
• Lust 에이전트: 작업 과정에서 115개 이상 에이전트를 사용했다.
• Lust 비교: 블라인드 판정단 평균 Opus 41/50, Muse 30/50. 해당 작업에서 Opus 빌드가 약 2.5배 빨랐고 Muse 결과에는 버그가 있었다.
• Muse 리뷰 프로브: Opus 수정 사항에 209개 프로브를 작성했다.
• Lakebed 감사 시간: Wonderful Full 약 16분, Sonnet 약 80분.
• TS Rust 감사 시간: Wonderful Full 약 17분, 일반 Muse Wonder 약 5분 9초.
• 과제당 토큰: Wonderful Full 약 53.8K, 일반 Muse Wonder 약 54.2K.
• 미병합 PR 8건 리뷰: Opus 23개 지적(21개 유효), Soul 61 9개(7개 유효), Muse 16개(독창적 5개).
• 제품 우선순위 조사: Opus 약 30분, Muse 약 17분. Muse는 10개 연구 에이전트와 1개 비판 에이전트를 사용했다.
• 호출량 문제: Bitbucket 100분에 2,800회, GitLab 12.5시간에 22,423회.
• 내장 모델 표시 문제: 코드에는 29개 모델만 표시됐다.

결론 및 시사점

1. 모델 선택은 지능의 최고점과 바닥을 함께 봐야 한다: Opus는 설계·깊이·독창적 버그 탐색에서 우위지만, Muse Wonderful Full은 낮은 멍청함과 읽기 쉬운 결과로 일상 개발의 신뢰성을 높인다.
2. 일반 Muse Wonder와 Wonderful Full을 구분해야 한다: API로 쉽게 접근할 수 있는 일반 버전은 가격도 애매하고 Full 대비 품질 하락이 커서, 온라인 데모와 실제 사용 경험이 엇갈릴 수 있다.
3. 전문 작업에는 전문 후처리가 필요하다: 3D와 UI는 전체 지능만으로 해결되지 않으며, 공간·시각 훈련과 디자인 데이터가 별도로 필요하다.
4. 에이전트 시스템은 ‘무엇을 아는가’보다 ‘어디를 먼저 보는가’가 중요하다: Muse는 10개 에이전트를 빠르게 지휘하고 기존 PR을 찾아 불필요한 변경을 줄이는 직관을 보여줬다.
5. 혼합 워크플로가 현실적인 최적해다: Muse를 표준 라이브러리·퍼징·리뷰·일반 수정에 쓰고, Opus를 설계·트레이트 시스템·고위험 변경에 투입하며 서로의 결과를 검토하게 하면 속도와 품질을 함께 얻을 수 있다.
6. 구독을 즉시 바꿀 근거는 없다: Wonderful Full의 구독 사용량과 가격이 공개되지 않았으므로 Cloud Code 구독을 취소할 이유는 없고, API 키가 끊기면 구독을 시험해 본 뒤 사용량 제한에 따라 판단하는 편이 합리적이다.
7. 경쟁 구도 변화가 가장 큰 의미다: Meta가 Anthropic·OpenAI에 가까워지면 세 번째 프런티어 연구소가 생긴다. Anthropic과 OpenAI가 경쟁 속에서 지능과 가격을 개선해 온 것처럼, Meta의 진입은 전체 생태계의 발전을 압박한다.
8. 다음 변수는 Google이다: Gemini 4 Argan의 공개가 지연되는 동안 Meta가 먼저 실전 경쟁력을 입증했다. Meta의 출시가 과대평가인지, Gemini가 다음 반격을 할지는 후속 모델과 실제 가격 공개가 결정한다.

핵심 요약 (20줄)

1. Meta가 Anthropic과 OpenAI 밖에서 처음으로 프런티어급 장기 코딩 모델로 평가받을 만한 Muse Wonderful Full을 출시했다.
2. Theo는 Muse Wonder를 며칠간 사용한 뒤 Spark 계열과 달리 실제 개발 업무에서 계속 손이 가는 모델이라고 판단했다.
3. Muse Wonder는 약 120 TPS로 API에 제공되고 Wonderful Full은 약 50 TPS로 구독에만 제공된다.
4. 일반 Muse Wonder의 가격은 입력 100만 토큰 4달러, 출력 100만 토큰 20달러, 캐시 읽기 0.20달러다.
5. Wonderful Full은 여러 벤치마크에서 Fable·Astra·Opus를 추월했지만 가격이 공개되지 않아 가격 대비 성능을 계산할 수 없다.
6. Muse Wonderful Full은 3D 모델링과 공간·시각 추론에서 약하고 Blender 결과물의 색상과 조명이 엉성하다.
7. Skatebench에서는 95%를 기록해 Gemini 계열의 96%에 근접했지만, 이 결과가 3D 생성 능력을 보장하지는 않는다.
8. UI 생성도 강점이 아니며 Claude가 커널 디버깅·UI·게임을 모두 맡기는 범용 작업에는 더 적합하다.
9. Reskate 감사에서 Muse는 CDN보다 캐시되지 않는 콜드 경로와 확장 상황이 느림의 원인이라고 정확히 짚었다.
10. Lust 컴파일러 실험에서 Opus는 더 정확하고 깊었고 Muse는 더 많은 작업을 더 빠르게 처리했다.
11. 세 블라인드 판정자는 특정 Lust 작업에서 Opus를 41점, Muse를 30점으로 평가했고 Muse 결과에는 버그가 있었다.
12. Muse는 115개가 넘는 에이전트를 조율하고 연구 서브에이전트에 실제 구현 확인과 무수정 분석을 지시했다.
13. Muse의 가장 큰 장점은 최고 지능보다 황당한 실수가 적은 낮은 멍청함과 읽기 쉬운 결과다.
14. Theo의 체감 평가는 Astra의 멍청함 10/10, Opus 3/10, Muse Wonderful Full 1~2/10이었다.
15. 원격 업데이트 버그에서 Muse는 실패한 웹 요청과 trace 헤더를 확인하고 이미 존재하는 더 작은 수정 PR을 찾아냈다.
16. T3 Code 아키텍처 감사에서 일반 Muse Wonder는 Wonderful Full보다 30% 넘게 낮은 분석 품질을 보였다.
17. Lakebed 감사에서 Wonderful Full은 약 16분, Sonnet은 80분이 걸렸고 일반 Muse Wonder는 5.75점에 그쳤다.
18. 8개 미병합 PR 리뷰에서 Opus는 23개, Soul 61은 9개, Muse는 16개의 지적을 내놓아 Muse가 두 극단 사이의 중간 지점이 됐다.
19. Muse는 10개 연구 에이전트와 비판 에이전트를 사용해 Opus보다 약 절반 시간에 읽기 쉬운 T3 Code 우선순위 보고서를 만들었다.
20. Meta의 따라잡기는 세 번째 프런티어 경쟁자를 만들며 Anthropic·OpenAI·Google의 다음 모델과 가격 경쟁을 더 치열하게 만든다.