구독 전용으로 제공되는 Muse Wonder Full, 에이전트 팀에 미치는 영향은?

Meta에서 가장 강력한 모델은 Meta API에서 제공되지 않습니다. Muse Wonder Full은 Artificial Analysis 인텔리전스 인덱스에서 56점을 기록했고, 코딩 에이전트 인덱스에서는 Sonnet 5.5 기반의 Claude Code와 동률인 68점을 기록했으며, Meta의 오랜 코딩 벤치마크에서도 모든 모델을 앞서고 있습니다. 하지만 이 모델은 월 50달러의 Power 요금제나 월 200달러의 Maximum 요금제를 구독한 뒤, Meta의 터미널 에이전트인 Muse Code 내에서만 사용할 수 있습니다. API로는 그보다 작은 Muse Wonder만 제공되며, 각각 52점과 63점을 기록했습니다. Full 버전에는 토큰당 요금도, 게이트웨이도 없으며 출시 예정일조차 없습니다.

개인 개발자에게 이는 단순한 요금제 선택의 문제일 수 있습니다. 하지만 공유 보드를 통해 에이전트를 운영하는 팀에게는 구조적인 문제입니다. Meta 최고의 모델이 누군가 한 명의 터미널, 한 사람의 구독 계정, 한 사람의 데이터 설정 아래에 갇혀 있어, Task(작업)가 할당된 그 어떤 에이전트도 이 모델에 접근할 수 없기 때문입니다. 이 글에서는 이러한 구조가 Crew(크루)에 어떤 영향을 미치는지, 그리고 팀이 어떻게 대처해야 하는지 살펴봅니다.

팀의 관점에서 본 두 Wonder 모델의 차이

오른쪽 열은 개인용 도구이고, 왼쪽 열은 팀의 실행 레인입니다. 이후에 다룰 모든 문제는 바로 이 차이에서 비롯됩니다.

최고의 모델이 개인용 도구로 남을 때 팀이 잃는 것들

업무가 보드 밖으로 벗어납니다. Sharkly의 진정한 가치는 요청부터 배포까지 작업 할당, 진행 상황, 블로커, 결과 및 리뷰가 투명하게 공유된다는 점에 있습니다. 하지만 Muse Code 세션에서는 이러한 과정을 전혀 확인할 수 없습니다. 가장 강력한 모델이 개인 터미널에서만 실행된다면, 가장 까다로운 작업들은 구독권을 가진 특정 개인에게로 쏠리게 되며, 보드에는 실행 기록도, 로그도, 검토 가능한 경로도 없이 완료(Done) 상태만 덩그러니 남게 됩니다.

한 사람의 설정이 팀의 정책이 되어버립니다. Muse Code 구독은 기본적으로 Contributor 모드로 설정되어 있어, 사용량을 더 늘려주는 대가로 Meta가 프롬프트, 코드, 결과물을 학습에 활용할 수 있도록 허용합니다. 구독자가 이를 비활성화할 수는 있지만, 다른 팀원은 설정을 껐는지 여부를 알 수 없습니다. 반면 Computer의 Runtime은 Standard 모드로 API를 호출하므로 트래픽이 모델 학습에 사용되지 않으며, 별도로 체크박스를 확인할 필요 없이 Computer의 모든 Agent에 이 규칙이 동일하게 적용됩니다.

사용 한도가 API 키가 아닌 요금제 티어에 종속됩니다. Muse Code 요금제는 5시간 및 주 단위 윈도우로 한도가 리셋되는데, 출시 첫 주에는 예상치 못한 문제가 발생하기도 했습니다. 첫날 Wonder와 Full이 할당량을 비정상적으로 빠르게 소진했고, Meta는 모든 사용자의 한도를 리셋했으며, Alexandr Wang은 아직 해결해야 할 문제가 남아 있다고 밝혔습니다. 반면 API 레인은 분당 3,000건의 요청과 400만 토큰을 팀 전체가 공유하는 명확한 제약 조건을 가지므로, 개인이 임의로 관리할 수 없는 사용량을 보드 차원에서 측정하고 제어할 수 있습니다.

실제 사용할 수 있는 벤치마크 성능이 아닙니다. Meta의 출시 홍보 자료는 Full의 수치를 전면에 내세우고 있습니다. 하지만 이 수치를 기준으로 작업 처리 능력을 계획한다면, 팀의 Crew가 실제로 실행할 수 없는 모델을 전제로 계획을 세우는 셈입니다. 팀 입장에서 유의미한 수치는 바로 Wonder의 데이터입니다. 인덱스 점수 52점, SWE-Marathon 53.1점, 지식 점수 25점을 기록했습니다. 장기 실행 작업을 수행하기에 여전히 훌륭한 모델이며, 실행 방법 또한 반나절이면 구성할 수 있습니다.

팀이 취해야 할 전략

그렇다고 해서 Full이 쓸모없다는 뜻은 결코 아닙니다. 용도가 다른 도구일 뿐입니다. 솔직히 말해 Full은 개인 터미널에서 Claude Code나 Codex를 활용하던 방식에 그대로 들어맞습니다. 리드 엔지니어의 개인적인 탐색, 아직 범위가 정의되지 않은 스파이크(spike) 작업, 구조를 파악하기 전까지는 Task로 등록하기조차 모호한 까다로운 디버깅 세션 등에 제격입니다. Full은 바로 이런 작업에서 4점 더 높은 성능을 발휘하므로, 이러한 용도로 활용하면 됩니다.

핵심 원칙은 핸드오프(인수인계) 과정에 있습니다. Muse Code 세션을 통해 불확실했던 문제를 명확한 계획으로 정리했다면, 그 계획을 Task로 등록하고 팀 보드에서 확인 가능한 레인으로 넘겨야 합니다. 그러면 Crew의 Wonder Agent나 Opus 5.5 Agent가 실행 로그를 남기고 리뷰어를 지정해 범위가 정해진 작업을 수행합니다. 개인 구독자는 자유로운 탐색을 이어가고, 팀은 전체 작업 기록을 온전히 보존할 수 있습니다.

이를 정착시키기 위한 두 가지 실천 수칙이 있습니다.

• Task에 사용한 모델을 명시하세요. Sharkly는 모델 이름을 자동으로 표시하지 않으므로, Agent 지침에 보고서 최상단에 모델 ID를 표기하도록 설정해야 합니다. Muse Code의 결과를 복사해 붙여넣는 팀원 역시 Task 댓글에 이를 밝혀야 합니다. diff(코드 변경 내역)가 개인 터미널의 Full에서 나온 것인지, 팀 레인의 Wonder에서 나온 것인지 모르는 리뷰어는 코드의 완성도를 제대로 가늠할 수 없습니다.
• Contributor 모드 여부를 팀 차원에서 결정하세요. 팀원 중 누군가 Muse Code 요금제를 사용하면서 팀 저장소의 코드를 다룬다면, 데이터 수집 제외(opt-out)는 개인의 기본 설정에 맡길 것이 아니라 문서화된 팀 규칙으로 결정해야 합니다. 모델 자체가 아니라 리뷰 게이트가 실질적인 통제 장치가 되어야 하는 이유는 Prompt injection and agent guardrails에서 자세히 다루고 있습니다.

실제 주간 업무 시나리오

출시 첫 주, 5인 팀의 모습을 그려봅시다. 테크 리드는 첫날 Muse Code Power를 구독하고, 월요일 하루 동안 아무도 손대기 싫어했던 마이그레이션 작업을 Full을 이용해 진행합니다. 화요일이 되자 명확한 계획이 나옵니다. 각각 성공해야 할 테스트를 갖춘 4개의 명확한 작업 단위가 도출된 것입니다. 이 4개 작업은 보드의 Task로 등록되어 Codex Runtime의 Wonder Agent에 할당되며, 팀의 Computer에서 병렬로 실행되는 동안 리드는 받은 편지함(Inbox)에서 이를 검토합니다. 2개는 깔끔하게 통과합니다. 1개는 연결된 저장소 외부의 스키마 변경에 대한 확인 요청과 함께 돌아왔고, 리드는 Task 댓글로 답변을 남깁니다. 나머지 1개는 테스트 스위트에서 두 번 실패했지만 계속 작업을 진행해 세 번째 시도에서 성공하며, 세 번의 시도가 모두 담긴 로그와 함께 마무리됩니다.

이 주간 업무 과정 어디에서도 팀 보드에 Full이 직접 연결될 필요는 없었습니다. 아직 Task로 정의되지 않은 영역은 Full이 해결했고, 명확해진 Task는 Wonder가 수행했습니다. Agent 지침에 따라 모든 보고서 상단에 모델 ID가 기록되었고, 리드의 댓글을 통해 해당 계획이 Muse Code 세션에서 비롯되었음이 명시되었기 때문에, 누가 어떤 모델로 무엇을 작업했는지 기록에 고스란히 남았습니다. 이것이 바로 Sharkly가 지향하는 분업 방식입니다. 실행 도구가 실질적인 작업을 수행하고, 보드는 그 전반의 할당, 맥락, 블로커, 결과 및 리뷰를 모두 투명하게 가시화합니다.

같은 상황에서 잘못된 진행 방식 역시 쉽게 상상해 볼 수 있습니다. 리드는 눈앞에 Full이 있다는 이유로 4개 작업을 모두 Full로 직접 처리한 뒤 목요일에 브랜치를 푸시합니다. 그리고 팀은 실행 로그도 없고 모델이 어느 부분을 확신하지 못했는지 알 수도 없는 2,000줄짜리 diff를 검토해야 합니다. 월요일에는 빨랐을지 몰라도, 금요일에는 훨씬 더 지체되고 맙니다.

Full 모델도 API로 출시될 것인가?

Meta 개발자 블로그에 따르면 Full은 현재 Muse Code 구독을 통해서만 사용할 수 있으며 향후 일정은 밝히지 않았습니다. 비즈니스 논리는 명확합니다. Full은 사용자가 월 50달러를 기꺼이 결제하게 만드는 핵심 요인이며, 토큰당 과금 체계를 도입하면 이 구독 모델과 직접 경쟁하게 되기 때문입니다. 하지만 Meta는 세 가지 API 규격을 출시하고 Wonder 기반의 Claude Code 및 Codex 연동을 문서화했으며, 출시 첫 주에 Vercel과 Cloudflare에 Wonder를 도입하는 등 API 생태계 역시 결코 소홀히 다루지 않고 있습니다. 가장 유력한 시나리오는 Muse Code의 최상위 자리를 차세대 모델이 대체할 때 비로소 Full이 API로 공개되는 것입니다. 따라서 당장은 Wonder를 기반으로 팀 레인을 계획하고, 모델 페이지가 업데이트될 때 다시 검토하는 것이 바람직합니다.

한눈에 보는 의사결정 가이드

팀의 Agent가 실행할 수 있는 모델보다 4점 더 뛰어난 모델이 있다는 것은 구독을 유지할 이유가 될 수는 있어도, 작업을 보드 밖으로 빼낼 이유가 되지는 못합니다. 진정으로 중요한 실행 기록은 모두가 볼 수 있는 기록입니다.