# Muse Spark 1.1 공개 > Clean Markdown view of GeekNews topic #31279. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31279](https://news.hada.io/topic?id=31279) - GeekNews Markdown: [https://news.hada.io/topic/31279.md](https://news.hada.io/topic/31279.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-07-10T09:06:55+09:00 - Updated: 2026-07-10T09:06:55+09:00 - Original source: [ai.meta.com](https://ai.meta.com/blog/introducing-muse-spark-meta-model-api/) - Points: 1 - Comments: 1 ## Topic Body - Meta Superintelligence Labs가 공개한 **Muse Spark 1.1**은 에이전트 작업을 겨냥한 멀티모달 추론 모델로, 도구·컴퓨터 사용, 코딩, 멀티모달 이해를 전작보다 강화함 - 외부 앱과 서비스 전반의 **계획·오케스트레이션**을 맡고, native tools, MCP servers, custom skills에 zero-shot으로 일반화하는 점이 핵심임 - **100만 토큰 컨텍스트 창**을 능동적으로 관리해 과거 작업 정보를 검색하고, 이후 단계에 필요한 핵심 맥락을 압축해 유지함 - 개발자는 공개 프리뷰로 나온 **Meta Model API**에서 모델에 접근할 수 있고, Meta AI 앱과 meta.ai에서는 “Thinking” 모드로 사용할 수 있음 - Meta는 Advanced AI Scaling Framework에 따라 배포 전 안전성 평가를 진행했으며, Chemical & Biological, Cybersecurity, Loss of Control 범주에서 안전 여유 범위 안에 있다고 평가함 --- ### Muse Spark 1.1의 위치와 제공 방식 - **Muse Spark 1.1**은 Meta Superintelligence Labs의 최신 모델로, 기존 Muse Spark 대비 주요 업그레이드로 소개됨 - 에이전트 작업용 **멀티모달 추론 모델**이며 다음 영역의 향상을 강조함 - 도구 사용 - 컴퓨터 사용 - 코딩 - 멀티모달 이해 - 이번 출시는 [Muse Image](https://ai.meta.com/blog/introducing-muse-image-muse-video-msl/) 공개와 함께 Meta가 말하는 “personal superintelligence” 비전에 가까워지는 단계로 연결됨 - 개발자는 공개 프리뷰로 나온 [Meta Model API](https://developer.meta.com/ai/resources/blog/build-with-muse-spark)를 통해 Muse Spark 1.1에 접근할 수 있음 - Meta AI 앱과 [meta.ai](http://meta.ai/)에서는 “**Thinking**” 모드로 제공됨 ### 에이전트 작업과 긴 컨텍스트 처리 - 여러 외부 앱과 서비스에 걸친 **개인 에이전트 작업**에서 계획을 세우고 실행 흐름을 오케스트레이션함 - native tools, **MCP servers**, custom skills에 zero-shot으로 일반화함 - 복잡한 프로젝트를 Muse Spark보다 훨씬 빠르게 처리하도록 학습됨 - 메인 에이전트는 컨텍스트를 수집하고 계획을 세운 뒤 병렬 subagent에 실행을 위임함 - subagent는 맡은 작업을 따르고 사용 가능한 도구를 이해하며, 필요할 때 메인 에이전트로 에스컬레이션함 - **100만 토큰 컨텍스트 창**을 능동적으로 관리함 - 수행한 행동을 기억함 - 훨씬 이전 작업의 정보를 검색함 - 이후 작업에 필요한 핵심 단계를 남기도록 압축함 ### 컴퓨터 사용 자동화 - Muse Spark 1.1은 여러 애플리케이션을 오가고 정보가 실시간으로 바뀌는 **컴퓨터 사용 워크플로**에 강점을 보임 - 긴 세션에서도 컨텍스트를 유지하고, 변하는 요구사항에 적응하며, 익숙하지 않은 인터페이스를 최소한의 사람 개입으로 탐색함 - 데스크톱 작업을 항상 클릭 단위로만 처리하지 않고 상황에 따라 자동화와 직접 조작을 고름 - 자동화가 빠를 때는 스크립트를 작성함 - 직접 상호작용이 단순할 때는 클릭을 사용함 - 각 단계에서 여러 동작을 묶어 생성함 - 저녁 파티 준비 예시에서는 주문 과정에서 새 컨텍스트가 생기자 이를 인식하고, 사용자 개입 없이 필요한 업데이트를 수행함 ### 코딩 성능과 개발 워크플로 - 크고 복잡한 코드베이스를 다루는 **실전 코딩 작업**에서 Muse Spark 1.1의 성능이 크게 향상됨 - 복잡한 버그 진단과 수정, 엔터프라이즈급 시스템의 새 기능 구현, 대규모 코드 마이그레이션을 수행할 수 있음 - 웹 애플리케이션 생성과 end-to-end 질의응답 같은 사용 사례에서 첫 모델 대비 큰 향상을 보임 - 다양한 하네스(harness)에 부드럽게 적응하고 복잡한 **멀티턴 동작**을 안정적으로 처리하도록 학습됨 - planning mode - goal conditioning - subagent delegation - context compaction 같은 일반적인 에이전트 코딩 기능을 지원함 - OpenCode 디버깅 데모에서는 채팅 웹 앱을 만들고, 자동 스크린샷으로 사용자에게 보이는 실패를 찾고, 관련 코드까지 추적해 수정한 뒤 변경 사항을 검증함 - Meta 내부 개발자와 연구자는 Muse Spark 1.1을 매일 사용 중이며, Meta Internal Coding Bench에서 Muse Spark보다 크게 개선되고 주요 대안들과 경쟁력 있는 결과를 보임 - 연구자들은 Muse Spark 1.1을 워크플로에 활용해 **모델 개발·평가 작업**도 자동화하고 있음 - DeepSWE 평가 예시에서는 OpenCode 안에서 여러 추론 강도별 DeepSWE 일부 작업을 자체 평가하고, 결과 기반 분석 대시보드를 생성함 ### 멀티모달 이해와 실행 - Muse Spark 1.1은 지각, **멀티모달 추론**, 도구 사용을 결합하는 작업에서도 강점을 보임 - 실제 환경과 상호작용하면서 근거 있는 산출물을 만들 수 있음 - 시각 자료에서 코드 산출물 생성 - 이미지·비디오의 매우 상세한 캡션 생성 - 멀티모달 사용 사례를 위한 에이전트 워크플로 실행 - 지각과 행동이 함께 필요한 상황에서 멀티모달 역량이 특히 유용함 - 시각과 오디오를 검사함 - 긴 워크플로 동안 세부 정보를 보존함 - 사용자를 대신해 컴퓨터를 조작할 때 해당 세부 정보를 활용함 - Facebook Marketplace 에이전트 예시에서는 스마트폰으로 촬영한 비디오에서 유용한 사진을 추출하고, 상품을 추론한 뒤 사용자의 브라우저를 조작해 Marketplace 등록을 생성함 ### 안전성 평가 - Meta는 배포 전 [Advanced AI Scaling Framework](https://ai.meta.com/static-resource/Meta_Advanced-AI-Scaling-Framework-v2)에 따라 광범위한 **안전성 평가**를 수행함 - 이 프레임워크는 Meta의 가장 고도화된 모델을 위한 평가, 위협 모델, 배포 기준을 정의함 - 평가 범주는 다음 frontier risk를 포함함 - Chemical & Biological - Cybersecurity - Loss of Control - Meta의 평가에서 Muse Spark 1.1은 모든 frontier risk 범주에서 **안전 여유 범위** 안에서 작동함 - 직접 jailbreak, 신뢰할 수 없는 데이터에서 오는 간접 공격, prompt injection, developer-prompt 공격에 강한 저항성을 보임 - 그 결과 adversarial robustness가 개선되고 hallucination 비율과 sycophancy가 줄어듦 - 전체 안전성 관련 내용은 [Muse Spark 1.1 Evaluation Report](https://ai.meta.com/static-resource/muse-spark-1-1-evaluation-report)에 문서화됨 ### 초기 파트너 반응과 향후 계획 - Meta Model API 공개 프리뷰를 통해 개발자가 처음으로 **Muse Spark 1.1** 기반 빌드를 시작할 수 있음 - 초기 파트너들은 긴 컨텍스트 처리, 코딩, 추론 역량을 결합해 대규모 에이전트 워크로드를 처리할 수 있는 기반 모델로 평가함 - Replit CEO Amjad Masad는 100만 토큰 컨텍스트, 이미지·비디오·PDF 멀티모달 지원, 인용 포함 내장 검색, 구조화 출력, 병렬 도구 호출, OpenAI 호환 패키지를 한 모델에 담았다는 점을 강조함 - Cline CEO Saoud Rizwan은 강한 도구 사용과 실제 코딩 워크로드를 규모 있게 실행할 수 있는 가격대를 함께 갖춘 점 때문에 Cline 개발자에게 조기 접근을 제공하고 싶었다고 밝힘 - Box의 Yashodha Bhavnani는 Box의 엔터프라이즈 업무 평가 세트에서 Muse Spark가 현재 주요 frontier 모델과 경쟁력 있는 엔터프라이즈 역량을 보였다고 평가함 - OpenClaw Foundation의 Dave Morin은 Muse Spark 1.1을 에이전트 실행에 빠르고 강력한 모델로 평가함 - Meta는 더 성능이 높은 모델을 학습 중이며 향후 공유할 계획임 ## Comments ### Comment 61508 - Author: neo - Created: 2026-07-10T09:06:56+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48846184) - 링크된 보고서에 훨씬 자세한 내용이 있음: [https://ai.meta.com/static-resource/muse-spark-1-1-evaluatio...]() Terminal-Bench-2.1 세부사항을 보면 “공식 저장소의 Terminal-Bench 2.1 작업 89개를 bash 도구 전용 에이전트 하네스로 평가했고, 리소스는 CPU 6코어와 RAM 8GB로 제한했다”고 되어 있는데, 이러면 결과는 **실격**임 각 터미널 벤치 작업에는 CPU 상한과 RAM 상한이 따로 있고, 둘 중 하나라도 넘기면 실격임. tbench-2.1 기준으로 89개 중 CPU 6코어를 허용하는 작업은 0개이고, RAM 8GB를 허용하는 작업은 8개뿐임 이런 식의 수상한 벤치마킹은, 모델의 벤치마크 성능을 높이려고 하네스를 만드는 재미를 완전히 빼앗아 감. 무엇을 해도 헤드라인의 부정확한 숫자를 이길 수 없기 때문임. 아마 그래서 이 모델이 공식 리더보드 [https://www.tbench.ai/leaderboard/terminal-bench/2.1]()에 없는 것 같음 전 Meta 직원으로서 조금 씁쓸하지만 크게 놀랍지는 않음. PSC가 끝나고 다음으로 넘어가기 전까지는 **숫자 올리기**가 핵심 성과 평가 지표였음 - 모델이 실수로 포크 폭탄을 일으키는 경우를 빼면 왜 **리소스 제한**을 고려해야 하는지 모르겠음. 이 벤치마크는 터미널 사용, 특히 많은 bash 도구 호출을 이어 붙이는 능력을 보는 것이라고 생각했는데, 어떤 테스트 케이스에서 이게 중요해짐? - 폐쇄형 모델의 문제가 바로 이거임. 우리가 돈 내는 대상이 **더 뛰어난 기반 모델**인지, 벤치마크 점수를 극대화하도록 잘 설계된 하네스인지 정확히 알 수 없음 - 순수하게 궁금한데, 리소스 제한이 병목이 되는 빈도는 얼마나 됨? 하네스는 여기서 무엇을 도와주나? 병렬성을 제한하거나 더 효율적인 도구를 쓰는 식인가? - 요지는 이해하지만 그렇게까지 중요할지는 잘 모르겠음 harbor / tb2.1이 Docker 실행에서 사용할 수 있는 **스왑**을 제한했나? 예전에는 Docker 인스턴스 실행이 명세보다 더 많은 메모리를 쓸 수 있는 버그가 있었음. 원래 작업 중 일부는 스왑을 활용하지 않으면 사실상 완료가 불가능했고, Docker가 스왑에 접근하지 못하게 막으면 오라클 풀이도 통과하지 못했음 기억으로는 crack-7z-hash와 filter-js-from-html이 그 문제가 있었는데, 몇 달 동안 안 봐서 확실하진 않음 - 그렇게 큰 문제로는 안 보임. 어떤 제품을 평가할 때도 제품 만든 쪽의 말을 그대로 믿지는 않음. 당연히 편향이 있을 테니까. 그래서 [https://artificialanalysis.ai]() 같은 **독립 테스트**가 존재하는 것임 - 며칠간 미리 써볼 수 있었고, 그동안 LLM용 플러그인을 만들 수 있었음. 터미널에서 이렇게 모델을 시험해볼 수 있음 `uv tool install llm` `llm install llm-meta-ai` `llm keys set meta-ai` `# paste API key here` `llm -m meta-ai/muse-spark-1.1 "Generate an SVG of a pelican riding a bicycle"` 결과는 여기 있음: [https://tools.simonwillison.net/markdown-svg-renderer#url=ht...]() 비교용으로 Muse Spark 1에서 나온 펠리컨은 여기 있음: [https://simonwillison.net/2026/Apr/8/muse-spark/]() - 이렇게 많은 모델을 **미리보기**할 시간을 어떻게 내는지 궁금함. 최근 모델 출시가 정말 정신없었는데, 가끔은 일처럼 느껴지지 않나? - Zuck은 정면 경쟁보다 모델 시장의 **스포일러 역할**에 더 집중하는 편이 나을지도 모름 Anthropic이나 OpenAI의 모델 매출을 따라잡을 필요 없이, 그 매출을 99% 깎아내릴 수만 있으면 됨. 프런티어 모델 개발에 몇십억 달러를 계속 쓰고, **오픈 가중치**로 공개해서 코딩 모델을 범용 상품으로 만들면 됨. 여기에 잘 만든 오픈소스 기준 하네스도 필요함 이걸 할 수 있고 사업적으로도 말이 되는 위치에 있는 사람은 거의 없음. 어차피 흐름은 그쪽으로 갈 가능성이 크고, 그는 그 속도를 크게 높일 수 있음. 컴파일러가 그랬듯 모델도 독점 제품에서 범용 상품으로 옮겨가길 바라야 함 Zuck이 세상에 할 수 있는 가장 좋은 일 중 하나일 수 있음 - 그들이 매출을 잃으면, Meta의 연산 자원은 누가 빌려 쓰게 됨? - 진짜 **스포일러 왕**이 되려면 학습 데이터셋을 오픈소스로 공개하면 됨. 거기까지 갈지는 의심스러움 - 코딩 모델은 목적지가 아님. 코딩 모델은 **범용 지능**으로 가는 부트스트래핑 과정의 일부일 뿐임 - llama로 이미 그걸 시도하지 않았나? - 그가 해야 할 일은 이런 모델을 만드는 게 더 이상 그렇게 어렵지 않다는 걸 증명하는 것뿐임. 이 회사들의 해자는 프런티어 모델 구축이 정말 어렵다는 **인식**이기 때문임 - 가격이 말이 안 되게 좋음. 100만 토큰당 입력 $1.25, 출력 $4.5이고, **캐시된 입력**은 $0.15임 [https://dev.meta.ai/docs/getting-started/pricing-rate-limits]() - 이건 xAI Grok 4.5와 가장 직접적으로 비교할 수 있음. 둘 다 방향성은 “Haiku 가격의 Opus급 지능”에 가깝고, 이런 모델을 앱에 넣고 싶은 애플리케이션 개발자에게는 아주 큰 일임 Haiku와 Sonnet을 Grok 4.5로 바꾸는 테스트를 하고 있었는데, 이것도 한번 써볼 생각임. 특히 캐시 가격은 훨씬 쌈 - 캐시된 입력 가격 비율이 좋음 Grok 4.5는 $2/$6로 나왔지만, 조용히 캐시된 입력 100만 토큰당 $0.50을 받음. 이건 **Opus 4.8**만큼 비싼 수준임 - Meta는 지금 모델을 고르는 대부분의 사람들 레이더에 없음. 정말 좋은 모델이 있다면, 경쟁사 가격에 맞추기 전에 보조금을 줘서 사용자를 확보하는 게 말이 됨 - Qwen 3.7 Max보다 쌈. Grok 4.5의 $2 입력 / $6 출력에 이어, 대형 연구소들이 **GLM 5.2의 압박**을 느끼고 있다는 두 번째 신호임 - 그래도 여전히 터무니없이 비쌈. Google 검색 결과 100개에 $10을 내야 한다고 생각해보면 사실상 이게 그런 것임 출력 100만 토큰당 $1.50 넘게 쓰려는 사람이 왜 있는지 정말 모르겠음. 하물며 $15~50은 말할 것도 없음. 소비자가 실제로 사용량 기반 과금을 내는 경우가 있나? - 어제까지만 해도 OpenAI와 Anthropic이 되돌릴 수 없을 정도로 앞서 있다는 분위기가 강했던 것 같은데, 이제 xAI와 Meta가 적어도 실용 모델과 경쟁 가능한 물건을 내놨고 가격도 쌈 물론 Fable, 그리고 아마 곧 나올 GPT-6까지 보면 두 선두 연구소가 앞서 있다는 이야기는 아직 유지되지만, 여론 주도층이 말하던 것처럼 완전히 끝난 게임은 아님 - 이제 모델은 대체로 충분히 좋아졌음. 큰 돌파구가 없다면 지금부터 중요한 건 **비용**뿐임 - 사람들이 Google이 뒤처진 것을 Anthropic과 OpenAI가 엄청 앞선 것으로 잘못 해석했음. 실제로는 Google이 Tensorflow, Angular, GCP 때처럼 뒤처진 것에 가까움 - 그 뉘앙스는 좀 다름 **GLM 5.2**에 대한 기대감은 이 전부터 이미 컸음. xAI나 Meta가 다른 방식으로 큰 차이를 만든 건 아니고, GLM 5.2와 비슷한 결과와 비슷한 가격에 가까움 - 개인적으로 Meta를 좋아하진 않지만, 이건 인정함. 경쟁이 많을수록 일반 소비자에게 좋고, 기업에도 좋음 중국 모델, Grok, Meta, Google, OpenAI, Anthropic이 모두 경쟁하는 건 승리라고 봄. 이런 보조금 붙은 토큰을 쓸 수 있을 때 최대한 활용하려고 미친 듯이 만들고 있음 - Meta의 로컬 llama 모델은 한때 **오픈소스 AI**의 얼굴이었음. 판이 정말 많이 바뀌었음 - 확실히 좋은 일이라고 봄. 다만 이런 발전 때문에 AI 시대에 필요한 소프트웨어 엔지니어 수가 늘어날지 줄어들지는 아직 마음속에서 논쟁 중임 한편으로는 제품 만들기가 쉬워져서 더 많은 사람이 만들고, 더 많은 제품과 기능이 생길 것임. 비기술자들도 많이 만들려 하겠지만 막히게 되고, 결국 엔지니어가 필요해짐. 숙련된 기술 회사와 비기술 창업자, 예비 창업자들이 만들어낼 제품의 총량은 엄청날 것임. 가까운 미래에 더 많은 소프트웨어 엔지니어가 필요하다는 **상승 시나리오**는 여기 있음 반면 1년쯤 지나면 사람들이 이런 제품을 잔뜩 만들겠지만, 대부분은 마케팅하거나 팔거나 돈을 벌지 못할 것임. 결국 그렇게 많은 소프트웨어 엔지니어가 필요하지 않게 될 수도 있음. 그래도 전체적으로는 상승 시나리오가 순효과로 이길 가능성이 크다고 봄 - 중국 모델을 더 풀어 쓰면 DeepSeek, GLM(Z.ai), Minimax, Kimi(Moonshot), Hy3(Tencent), Qwen(Alibaba)이 있음 각각은 가중치를 내려받아 **로컬 실행**할 수 있음 - 그는 이 소식을 자기 Meta Threads가 아니라 X에 올렸음. 이걸 크게 키우려는 관심이 어느 정도인지 보여줌. 물론 이 회사들이 계속 현금을 태우는 동안 우리 입장에서는 비용이 감당 가능한 수준에 머물 수 있음 - 지금까지 본 것 중 가장 큰 **기술 경쟁**임. 가장 부유한 회사들, 가장 똑똑한 사람들, 가장 부유한 나라들이 뛰어들었음 경쟁이 좋은지는 모르겠고, 몇 년 뒤에 보게 될 것임. 오랜만에 육체노동 직업을 갖게 될 날을 기대 중임 - 어떻게 모든 회사가 모든 벤치마크에서 자기들이 1등처럼 보이게 만들 수 있는 거지? - 먼저 직접 고른 벤치마크 묶음에서 어떤 모델들이 더 나쁜지 봄 다음으로 경쟁사 모델의 **이전 버전**과 비교함. 그래도 좋아 보이지 않으면 자기 이전 모델과 비교함 - 해자가 크지 않고, 개선은 점진적이며, 비교할 모델을 골라 담기 때문임 공정하게 말하면 주된 강점이 가격이라면 비슷한 성능대 모델과 비교하는 게 더 맞아 보임 - 이제 Gemini와 비교하는 건 **공짜 빙고 칸** 같은 느낌임 - AI 쪽을 깊이 아는 사람 기준으로, 코딩에서 **표준 벤치마크**는 뭐라고 봐야 하나? - 자기 모델이 최소 N개 벤치마크에서 앞서는 정확한 순간을 기다렸다가 발표하면 됨 - Meta가 **폐쇄형 가중치 모델**을 개발하고 출시하고 있었다는 걸 놓쳤음. 아쉽다. 미국산 오픈 가중치 모델에서 더 많은 진전이 있으면 좋겠음 - 컨테이너 안에서 codex와 함께 동작하게 만들었음. 참고로 Codex:Muse 인터페이스에서 대부분 마주칠 버그가 있는 것 같음 내가 보기엔 codex가 서버 측 도구 호출을 예상하지 못했고, Meta가 그 ID들을 다루는 방식 때문에 생기는 일종의 파싱 또는 통합 오류임. codex를 muse와 처음 몇 번 실행했을 때 첫 번째 비웹검색 호출에서 실패했음 수정은 했고, 개인적으로는 맞춤형 **서버 측 도구 호출**과 무기한 파일 저장에 아직 완전히 설득되진 않았지만, 지금까지는 꽤 멋진 모델이고 즐겁게 쓰고 있음 [https://github.com/accretional/awesome-muse-spark/blob/main/...]() - 공개된 벤치마크를 보면 코딩과 멀티모달도 꽤 좋지만, **도구 호출 성공률**이 매우 좋은 것 같음 이런 성능 형태에 가장 잘 맞는 사용 사례는 뭘까? - 디버깅과 진단은 도구 호출이 매우 많음. 로그를 grep하거나 변환하고, 프로파일러나 추적기를 호출하고, 사고 보고서를 작성하는 일까지 포함됨 버그 진단은 코딩을 어느 정도 하면서도 **도구 활용**을 더 잘해야 하는 영역임. 좋은 진단 보고서가 있으면 수정은 Opus에 넘기면 됨 Opus도 보고서를 어느 정도 쓰지만, typst 문서에서 여전히 표 너비를 자주 틀려서 마지막 열에 텍스트가 가득 차는데 폭은 몇 글자밖에 안 되는 일이 생김 - Gemini 3.5 Flash는 도구 호출에서 Fable보다 나음. 도구 호출은 아마 **사후 학습**으로 비교적 쉽게 개선할 수 있는 영역 중 하나일 것임 - 앞으로 새 릴리스마다 이런 패턴을 보게 될지 궁금함. 도구 사용은 빠르게 바뀔 가능성이 커서, 가장 지능적인 모델보다 **가장 최신 모델**이 항상 우위를 가질 수도 있음 - 이건 좀 쓸모없게 들림. JSON 같은 제약된 디코더 성능이 뛰어난 건 흥미롭지만, 일반 디코더에서 도구 검증기를 거치고 좋은 오류 메시지를 받은 뒤 다시 시도하는 루프는 거의 항상 두 번째 시도에서 도구를 작동시킬 수 있음. 입력은 캐시되니 비용도 비싸지 않음