Muse Wonder·Wonder Full 분석: 기억하는 모델과 일을 끝내는 제품의 차이

10월 12일 발표가 바꾼 선택지

Meta는 2026년 10월 12일 Muse Wonder와 Muse Wonder Full을 발표했다. 뉴스룸에는 10월 13일 수정 날짜도 표시된다. Wonder는 Meta Model API와 Muse Code에, Full은 Muse Code 구독자에게 제공한다는 발표다. 개인 에이전트 Muse에는 구독자부터 향후 반영한다고 설명했다. 모델 공개와 개인 앱의 전체 전환은 같은 사건이 아니다. 공식 발표

이 글은 10월 16일 확인한 공개 자료를 기준으로 한다. 개발 문서는 Wonder를 preview로 표시하며, API 모델 ID는 muse-wonder-1.0이다. 제품 계정·API를 직접 실행하지 않았으므로 한국 계정의 접근 가능 여부나 실제 응답 속도·품질은 확인하지 않았다. 개발 문서

이번 발표를 읽을 만한 이유는 최고 점수 하나가 아니다. 여러 날에 걸쳐 조건이 달라지는 업무를 모델 평가와 제품 구성의 중심에 놓았다는 점이다. 한 번에 완벽한 답을 쓰는 일과, 어제 정한 조건을 오늘 수정하면서 일을 계속하는 일에는 다른 능력이 필요하다. 어떤 쪽이 자신의 병목인지 알아야 모델을 바꿀 이유도 생긴다.

Wonder·Muse Code·개인 Muse를 한 이름으로 묶으면 놓치는 것

대상	무엇인가	독자가 선택하는 것
Muse Wonder	API와 코딩 도구에서 사용하는 모델	기존 앱의 모델 호출을 바꾸거나 새 에이전트에 연결
Muse Wonder Full	Wonder와 구분되는 상위 변형	현재 제공되는 Muse Code 구독 경로에서 사용 검토
Muse Code	프로젝트에서 계획·편집·명령 실행을 수행하는 코딩 에이전트	모델과 개발 작업 환경을 함께 사용
개인 Muse	전용 클라우드 VM에서 개인의 목표와 일을 이어 가는 제품	자료·앱 연결과 목표를 맡기고 결과를 받음

모델·개발 도구의 구분은 개발 개요, 개인 제품의 VM과 지속 작업은 9월 출시 설명에 근거한다. 개인 Muse의 출시 공지는 당시 미국 제공을 설명한다. 그것만으로 지금 한국에서 지원된다거나 지원되지 않는다고 확정할 수는 없다.

현재 모델 문서는 더 구체적이다. Wonder는 API의 Standard 모드와 Muse Code에서 제공하며, Full은 API에서 제공하지 않고 Muse Code의 Power Usage·Maximum Usage 구독에 포함한다. Wonder의 추론 강도를 max로 올려도 Full로 바뀌지 않는다. 추론에 쓰는 노력과 모델 변형은 별도 선택이다.

이 차이는 구현 범위에도 영향을 준다. 기존 시스템에 Wonder API를 연결했다고 해서 개인 Muse의 VM·계정 연결·승인 화면이 함께 생기는 것은 아니다. 반대로 Muse Code를 쓰는 개발자는 파일 편집과 명령 실행을 갖춘 환경에서 모델을 이용한다. 모델 이름이 같아도 실행 도구와 보관되는 상태가 다르면 가능한 업무가 달라진다.

Active Memory와 Active Focus는 서로 다른 실패를 겨냥한다

Meta는 Active Memory를 대화 사이에서 중요한 맥락을 이어 가고 관련된 세부 사항을 능동적으로 다시 가져오는 능력으로 설명한다. Active Focus는 어려운 목표를 향해 대안을 시도하고, 장애와 새 정보에 적응하며, 필요할 때 질문하거나 중요한 행동 전에 확인하는 능력이다. 연구 발표

둘을 업무 언어로 풀면 “무엇을 지금 적용할 것인가”와 “다음에 무엇을 할 것인가”다. 예를 들어 행사 준비 중 참가 인원이 바뀌었다면, 오래된 인원을 정확히 기억하는 것은 도움이 되지 않는다. 최신 인원을 고르고 그 근거를 알아야 한다. 장소 예약이 막혔다면 최신 인원만 말하는 것으로도 일이 끝나지 않는다. 대체 장소를 찾거나 사용자에게 조건 변경을 물어야 한다.

실패 장면	필요한 능력	사람이 확인할 결과
예전 인원으로 식사를 주문하려 함	변경된 조건을 찾아 적용	현재 인원과 변경 근거가 맞는가
예약 화면이 막히자 같은 클릭만 반복	장애에 맞춰 계획 수정	다른 경로를 시도했는가, 질문할 때를 아는가
새 계획은 맞지만 일정표에는 옛 장소가 남음	여러 산출물의 상태 대조	안내문·일정·견적이 같은 결정을 반영하는가

이 표는 제품에서 관측한 오류가 아니라 두 능력을 구분하기 위한 분석이다. 세 번째 문제에는 기억과 계획뿐 아니라 파일·앱을 읽고 갱신하는 도구도 필요하다. 더 강한 모델은 어느 도구를 쓸지 판단하는 데 도움을 줄 수 있지만, 연결하지 않은 캘린더에 실제 일정을 기록하지는 못한다.

긴 문맥, 지속 기억, 요청 캐시도 구분해야 한다. 문맥 창은 한 요청에서 다룰 수 있는 정보의 범위다. 지속 업무에는 다음 요청에 어떤 정보를 전달하고 갱신할지 정하는 상태 관리가 추가된다. 요청 캐시는 반복 입력의 처리 비용에 관한 기능이다. 캐시가 맞았다는 사실은 최신 결정을 잘 기억했다는 증거가 아니다. 긴 자료를 통째로 넣을지 필요한 자료를 찾아 넣을지의 선택은 긴 문맥과 RAG에서 이어 볼 수 있다.

모델 카드에서 점수보다 먼저 읽을 세 줄

Muse Wonder 모델 카드는 평가 환경과 한계를 공개한다. 아래는 그중 이번 선택에 직접 관련된 조건이다. 공급자 평가를 다시 실행한 결과는 아니다.

평가	문서에 적힌 범위	업무에 옮길 때 생기는 질문
MemoryBench	64K~100K 토큰 대화에 방해 정보와 충돌·갱신된 사실을 넣는 내부 평가	우리 업무의 조건 변경도 구별하는가
FocusBench	변화하는 환경과 장애에 적응하는 개인 에이전트 과제의 내부 평가	멈추거나 질문해야 할 지점도 적절한가
SWE-Marathon	장기 소프트웨어 과제를 테스트로 평가. 비교 행의 제품·실행 구성이 동일하지 않음	모델 차이와 도구·실행 환경 차이를 분리했는가

카드는 양자화·서빙 설정·프롬프트·도구·에이전트 실행 구성에 따라 성능이 달라질 수 있다고 명시한다. 따라서 전체 순위만 보고 “Full이 우리 팀의 모든 작업에서 더 낫다”고 결론 내리기 어렵다. 내부 기억 평가의 좋은 결과도 모든 세션의 완전한 보존이나 한국어 업무의 성공률을 뜻하지 않는다.

독자가 적용할 방법은 점수를 다른 점수로 바꾸는 것보다 실패 원인을 나누는 것이다. 최신 요구사항은 찾았는데 도구 권한이 없어서 실패했다면 모델만 바꿀 근거는 약하다. 자료와 권한이 충분한데도 예전 조건으로 계획을 만들었다면 기억·추론 능력의 비교가 더 직접적이다. 저장된 기억 자체에 최신 정보가 없었다면 먼저 입력과 상태 전달을 고쳐야 한다.

내 업무로 확인하는 사례: 바뀌는 워크숍 준비

다음은 이 글에서 만든 가상 업무와 평가 설계다. Muse 또는 Wonder로 실행한 시연이 아니다. 한 담당자가 워크숍의 안내문·일정·준비 목록을 함께 관리한다고 하자. 한 번의 요약으로 끝나지 않고 인원과 장소가 바뀌는 상황을 넣어 두 능력의 차이를 드러낸다.

처음에는 참가자 12명, 대면 행사, 장소 A를 후보로 준다. 이후 참가자를 16명으로 바꾸고, 2명은 원격 참여한다고 추가한다. 마지막에는 장소 A를 사용할 수 없다는 정보를 준다. 모든 인물·장소·조건은 가상이다.

차례	추가 입력	받아야 할 산출물
1. 최초 계획	총 12명, 장소 A 후보, 예약은 아직 안 함	일정 초안과 결정되지 않은 항목
2. 조건 수정	총 16명, 이 중 2명 원격	현장 14명 기준 준비 목록, 원격 접속 안내 초안
3. 장애 발생	장소 A 사용 불가	대체 장소에 필요한 조건, 기존 안내문의 변경 대상
4. 완료 대조	아직 대체 장소를 승인하지 않음	장소 미정 표시, 예약·발송 미실행 기록, 다음 질문

두 번째 단계에서 “16명으로 기억했다”고 답해도 식사 수량이 16인분이면 현장 인원 조건을 놓쳤을 수 있다. 다만 원격 참여자에게도 식사를 보내는 정책이라면 16인분이 맞을 수 있다. 그러므로 이 설계에서는 식사는 현장 참석자에게만 제공한다는 전제를 입력에 함께 넣는다. 기대 결과가 가정에 의존한다는 점까지 고정해야 공정한 비교가 된다.

세 번째 단계에서는 대안의 개수보다 기존 계획과의 연결을 본다. “다른 장소를 찾아보세요”라는 답은 다음 작업을 담당자에게 돌려준다. 재사용할 결과는 현장 14명 수용, 원격 연결 가능, 아직 확정되지 않은 조건을 포함한 대체 장소 요구표다. 이것을 바탕으로 후보를 찾도록 하되 예약이나 발송은 별도 승인 전까지 실행하지 않도록 정한다.

네 번째 단계의 좋은 결과는 화려한 완성본이 아닐 수 있다. 장소가 미정이면 안내문에도 미정으로 남겨야 한다. 계획 문서에서만 장소 A를 지우고 캘린더 설명에는 남겨 두었다면 작업은 끝나지 않았다. 완료 조건을 이렇게 잡으면 기억 정확성과 실제 상태의 일치를 구분해 기록할 수 있다.

실제 비교에 쓸 요청문

가상 워크숍 준비 자료를 차례로 제공하겠다.
각 단계에서 현재 유효한 조건, 대체된 조건, 미결정을 구분해라.
식사는 현장 참석자에게만 제공한다.
결과물: 안내문 초안, 준비 목록, 변경 근거표.
장소는 내가 확정하기 전까지 미정으로 표시해라.
예약·외부 발송은 하지 마라.
새 입력이 오면 어떤 결과물을 바꿔야 하는지 먼저 판단해라.
마지막에는 파일의 내용과 실제 수행한 행동을 구분해 보고해라.

비교할 때는 같은 순서·자료·완료 조건을 유지한다. API로 직접 구성했다면 앞 단계의 어떤 상태를 다음 호출에 넘겼는지도 남긴다. Muse Code와 개인 Muse를 비교했다면 사용한 도구와 연결 서비스가 다르다는 점도 기록한다. 워크숍 조건 변경 기록 양식을 복사해 자신의 업무로 바꿔 쓸 수 있다.

한 번 맞힌 결과를 성공률로 발표할 필요는 없다. 첫 시도에서는 조건 선택 오류, 계획 수정 오류, 도구 실행 실패, 결과물 불일치 중 어디에 시간이 드는지 찾는 편이 유용하다. 이 원고는 그 오류가 실제로 발생했거나 Wonder가 해결했다는 주장을 하지 않는다.

API 비용과 구독을 같은 숫자로 비교하지 않는다

10월 16일 공식 가격 문서에서 Wonder의 Standard 요금은 100만 토큰당 입력 4달러, 캐시 입력 0.20달러, 출력 20달러다. API의 Wonder에는 Contributor 모드가 없다. 캐시 적용량은 응답의 cached_tokens로 확인하며, 웹 검색 도구 비용은 토큰 비용에 추가된다.

다음은 청구 대상 입력 10만 토큰·출력 2만 토큰을 가정한 산술 예시다. 실제 호출, 처리 시간, 청구 기록이 아니다. 검색·외부 도구·세금·사람 검토 비용은 제외한다.

가정	계산	토큰 비용
입력 캐시 없음	0.1 × 4 + 0.02 × 20	0.80달러
입력 전부가 캐시 요금 대상	0.1 × 0.20 + 0.02 × 20	0.42달러

두 번째 행은 매번 가능하다는 예측이 아니다. 실제로 캐시가 적용된 토큰만 낮은 요금을 받는다. 더 오래 작업하거나 여러 번 수정하면 호출별 사용량을 합산해야 한다. 출력 길이를 화면에 보이는 글자 수로 바꿔 계산하지도 않는다.

Full의 경우 현재 제품 페이지는 Power Usage 월 50달러, Maximum Usage 월 200달러를 표시한다. 이는 Muse Code 구독 가격이며 개인 Muse 구독 가격이나 Full API 단가가 아니다. 포함 사용량을 자신의 작업 건수로 환산하려면 별도 관측이 필요하다.

콘텐츠 처리 조건도 확인해야 한다. 모델 문서에 따르면 Muse Code 구독은 콘텐츠를 모델 학습에 쓰도록 허용하고 사용량을 늘리는 Contributor 모드가 기본이며 설정에서 끌 수 있다. Standard 모드에서는 해당 콘텐츠를 모델 학습에 사용하지 않는다고 설명한다. API의 Wonder에는 Contributor 모드가 없다는 사실과 구독의 기본 설정을 섞지 말자. 이 글은 어떤 계정 설정도 변경하지 않았다.

도입 범위는 병목이 있는 곳에 맞춘다

기존 앱에 도구·상태 보관·결과 검사가 이미 있고 모델이 복잡한 조건을 자꾸 놓친다면 Wonder API를 같은 과제에 연결해 비교할 이유가 있다. 개발 프로젝트에서 여러 파일의 수정과 검사를 함께 맡기려면 Muse Code 안의 Wonder와 Full 경로를 살펴볼 수 있다. 개인 일정과 외부 앱을 이어 가는 것이 목적이라면 개인 Muse의 현재 계정 제공 상태와 연결 범위를 먼저 확인해야 한다.

Muse Code의 작업 기능도 모델 발표와 날짜가 다르다. 8월 31일 기능 공지는 세션 간 메시지, workflow, rewind와 SDK 개발자 프리뷰를 설명한다. 이 기능들을 Wonder가 10월에 새로 만든 모델 능력으로 계산하면 모델과 제품의 기여가 뒤섞인다.

반대로 한 번 받은 표를 정해진 양식으로 바꾸는 일, 입력과 처리 순서가 고정된 업무라면 지속 기억이나 장기 계획의 이점이 작을 수 있다. 현재 방식으로 요구사항을 만족한다면 새 구독이나 실행 환경을 추가할 이유도 약하다. 모델 교체를 검토하더라도 처음에는 워크숍 사례처럼 바뀐 조건 하나와 장애 하나를 넣어 어떤 실패가 줄어드는지 확인하면 된다.

세 제품의 작업 공간과 결과 인계부터 비교하려면 Muse·Dots·Grok Bot 비교로, 사람의 수정 시간을 포함해 도입 비용을 따져 보려면 에이전트 완료 비용 분석으로 이어 읽을 수 있다. 이 글을 저장해 두었다면 다음 확인 때는 모델 이름보다 제공 경로·변경된 이용 조건·내 과제의 실패 기록부터 대조하자.