AesCode 32B vs Muse Code: 포스터 엔진과 터미널 에이전트는 라이벌이 아니다

AesCode 32B와 Muse Code는 두 이름 모두 "code"라는 단어를 포함한다는 이유로 비교되는데, 그것이 이 둘의 거의 유일한 공통점이다. AesCode 32B는 편집 가능한 HTML과 CSS — 슬라이드, 포스터, 대시보드, 보고서 — 를 생성하기 위한 마이크로소프트의 연구 체크포인트로, Apache 2.0 라이선스로 Hugging Face에 공개되었으며, 저장소는 2026년 9월 29일에 생성되었고 "Release AesCode-32B"라는 이름의 커밋은 2026년 10월 7일자로 기록되어 있다. 마이크로소프트는 이에 대해 아무것도 발표하지 않았다. 런치 포스트도, 보도자료도 없으며, 모델 카드 자체에도 출시 날짜가 명시되어 있지 않다. Muse Code는 모델이 아니다. 그것은 2026년 8월 초부터 베타로 운영되는 메타의 터미널 코딩 에이전트로, 저장소를 상대로 셸 명령을 실행하며 시간을 보낸다. 이 중 하나는 브라우저에서 열어 볼 수 있는 파일을 만들어내고, 다른 하나는 테스트가 통과할 때까지 명령을 실행한다. 이 둘 중에서 무엇을 고를지는 모델을 고르는 결정이 아니며, 이 페이지가 할 수 있는 유용한 일은 바로 당신이 마치 그런 결정인 것처럼 선택하는 것을 막아주는 것이다.

각각이 실제로 무엇을 위한 것인지

AesCode 32B는 Qwen3-VL-32B-Instruct에서 출발하며, 모델 카드에 따르면 3,000개의 시연에 대한 콜드 스타트 지도 미세 조정(cold-start supervised fine-tuning)을 거친 뒤 실행, 텍스트, 경계, 표/차트, 레이아웃, 공백, 디자인이라는 일곱 가지 보상 채널에 걸친 GDPO 강화 학습으로 훈련된다. 이 중 여섯 채널은 결정론적 검증기이고, 일곱 번째는 대상 페이지의 "디자인 그래프"에 연결된 샘플별 루브릭을 바탕으로 작동하는 비전-언어 판정자다. 모든 후보 출력은 외부 요청이 차단된 샌드박스형 Playwright 브라우저에서 렌더링된 다음, DOM과 계산된 스타일, 경계 상자, 스크린샷을 통해 채점된다. 의도된 출력은 카드에 명시되어 있는데, 편집 가능한 슬라이드, 포스터, 대시보드, 보고서, 그리고 멀티모달 코드 생성에 관한 연구다. 이 모델은 완전한 HTML 문서를 생성하며, 출력이 검사 가능한 상태로 유지되도록 실제 HTML 표 구조와 ECharts 사양을 사용하도록 훈련된다.

Muse Code는 구조적으로 다른 일을 합니다. macOS와 Linux용 네이티브 바이너리로, 메인 에이전트 루프, 세션 전반에 걸쳐 계속 맥락을 수집하는 비동기 백그라운드 에이전트, 하위 에이전트들이 서로 충돌하지 않도록 격리된 Git 워크트리, 그리고 크래시된 세션을 재생하거나 재개할 수 있게 해주는 로컬 이벤트 로그를 갖추고 있습니다. Meta 자체 보고에 따르면 이는 몇 시간 단위로 측정되는 기간 동안 수천 건의 도구 호출을 기록합니다. 판매되는 것은 결과물이 아니라 루프입니다.

두 가지를 나란히 놓으면 동사가 맞지 않습니다. AesCode 32B는 렌더링합니다. Muse Code는 실행합니다. 문제가 "우리 분기별 발표 자료를 만드는 데 디자이너가 사흘이 걸린다"라면, Muse Code는 상관없고 AesCode 32B가 바로 그 문제를 겨냥합니다. 문제가 "아무도 이 의존성 트리를 업그레이드하는 데 주말을 쓰고 싶어 하지 않는다"라면, AesCode 32B는 할 말이 없고 Muse Code가 바로 그 도구입니다.

각 측의 증거는 같은 종류의 증거가 아니다.

이 부분은 모든 비교 페이지가 틀리는 지점이라, 천천히 살펴볼 가치가 있습니다.

AesCode 32B의 수치는 300개 샘플 인포그래픽 평가에서 나온 것으로, 프롬프트당 세 번 생성하고 선택 없이 측정한 결과이며, 그 자체로 인상적입니다: Overall 점수 85.89로 GPT-5.5의 81.28, Claude Opus 4.8의 80.39를 앞섰는데, 두 모델 모두 Microsoft 자체 하네스로 동일한 참조 이미지 설정에서 측정되었습니다. 이 카드는 또한 심각한 캔버스 경계 실패가 샘플의 4.3%에서 반복되는 반면 GPT-5.5는 34.7%라는 점, 그리고 AesCode 32B가 자체 Qwen3-VL-32B 백본을 Visual 차원에서 22.4점, Overall에서 24.8점 능가한다고 보고합니다.

그 모든 것을 벤더가 보고했고 재현되지 않은 것으로 읽어라. 벤치마크, 모델을 훈련시킨 보상 채널, 그리고 그 점수를 매기는 지표는 모두 같은 연구소의 작업이며, 300개의 샘플은 Microsoft의 것이다. 그렇다고 그 결과를 일축할 이유는 아니다 — 평가는 이례적으로 투명하고, 검증기 스택은 공개되어 있으며, 카드가 어떤 모델도 60을 넘지 못하는 차원("style", 아무것도 55.99를 넘는 점수를 받지 못하는)을 공개한다는 사실은 대부분의 벤더 표가 담고 있는 것보다 더 큰 정직성이다. 그것은 85.89를 다른 연구소가 다른 과제에서 산출한 숫자 옆에 놓고 비교가 일어난 척하지 않을 이유다.

Muse Code의 수치는 또다시 다른 의미에서 Meta가 보고한 수치다. 이는 모델과 하네스를 함께 측정한다. Meta는 Muse Code가 Terminal-Bench 2.1에서 82.9%를 기록했다고 보고하는데, 이는 Claude Code와 짝을 이룬 Claude Opus 5의 86.7%에 이어 2위이며, DeepSWE 1.1에서 59.3%, 내부 코딩 벤치에서 70.6%를 기록했다. 그 표 전반에 걸쳐 서로 다른 하네스가 서로 다른 모델과 짝지어졌기 때문에, 시스템 점수에서 모델의 기여도를 읽어낼 수 없다. 그리고 Muse Code가 측정되는 대상과 AesCode 32B가 측정되는 대상 사이에는 전혀 겹치는 부분이 없다 — 하나는 터미널 작업과 소프트웨어 엔지니어링으로 평가되고, 다른 하나는 인포그래픽의 텍스트가 읽을 수 있는지와 레이아웃이 넘치지 않는지로 평가된다.

"32B 체크포인트 하나"가 숨기는 것

배포는 두 제품이 가장 극명하게 갈리는 지점이며, 짧은 버전은 글머리 기호 목록 하나에 담긴다.

• 무엇인가 — AesCode 32B: 다운로드하는 33B 파라미터 모델 체크포인트. Muse Code: 설치 가능한 터미널 에이전트 제품.

• 라이선스 — AesCode 32B: Apache 2.0, 가중치 포함. Muse Code: 독점; 그 기반이 되는 모델은 비공개.

• 공급하는 것 — AesCode 32B: GPU와 서빙 스택. Muse Code: API 키 또는 구독.

• 하드웨어 최소 요구 사항 — AesCode 32B: 이 카드는 bf16 파라미터만으로도 대략 65GB의 가속기 메모리를 계획하라고 권고하며, 자체 서빙 예시에서는 4방향 텐서 병렬 처리를 사용합니다. Muse Code: 노트북 한 대.

• 컨텍스트 — AesCode 32B: 보고된 구성에서 24,576토큰이며, RL 훈련 중에는 프롬프트와 응답이 8,192토큰으로 제한됩니다. Muse Code: 그 아래에 있는 Muse Spark 모델을 통한 1M 토큰 창.

• 가격 — AesCode 32B: 가중치는 무료이며, 비용은 하드웨어입니다. Muse Code: 토큰당 청구되거나 월간 요금제를 통해 청구됩니다.

• 근거 — AesCode 32B: 자체 300개 샘플에 대해 벤더가 직접 수행한 평가이며, 평가 하네스가 공개되어 있음. Muse Code: 에이전트와 모델이 결합된 스택에 대해 Meta가 보고한 시스템 수준 벤치마크.

그 "하드웨어 최소 사양" 행은 사람들이 건너뛰는 부분이다. bf16의 32B 체크포인트는 노트북용 모델이 아니고, 게다가 AesCode 32B는 비전-언어 모델이라서 서빙 경로가 이미지 입력도 함께 처리한다. Muse Code는 오후 한나절이면 설치할 수 있는 바이너리다.

그들이 진정으로 겹치는 부분

실질적인 중복은 정확히 하나뿐이고, 그것도 좁습니다. 둘 다 디자인에 인접한 산출물을 가리키며 사람이 다듬을 무언가를 생성하도록 요청할 수 있습니다. 팀에서 내부 대시보드를 코드로 생성하고 있고, 대시보드 저장소에 풀 리퀘스트를 열 수 있는 에이전트도 원한다면, 두 제품 모두 그 워크플로에 접점이 있습니다.

그런 경우에도 구분은 깔끔하다. AesCode 32B는 아티팩트를 생성한다. Muse Code는 변경을 만들어낸다. 두 가지를 모두 수행하는 파이프라인은 AesCode 32B를 호출해 렌더링한 뒤, 그 결과 파일을 에이전트에게 넘겨 배치하고 연결하고 테스트하게 할 것이다. 그리고 두 제품 중 어느 것도 그것을 막지 않는다. 왜냐하면 둘은 애초에 같은 슬롯을 두고 경쟁한 적이 없기 때문이다.

오늘 예측할 수 있는 이 맞대결의 절반

여기에는 분명히 말할 가치가 있는 실질적인 비대칭이 있다. AesCode 32B는 어떤 추론 제공업체도 배포하지 않는다. Hugging Face 카드에는 호스팅된 엔드포인트도, 파트너도, API도 없다. 사용하려면 65GB의 가중치를 내려받고 서빙 경로를 직접 구축해야 한다. 이는 연구용 릴리스로서 정상적인 상태이며, 동시에 GPU 8개를 보유하지 않은 사람과 이 모델 사이에 가로놓인 가장 큰 단일 장애물이기도 하다.

Muse Code의 기반 모델에는 그런 문제가 없습니다. Muse Spark 제품군은 일반 API 모델로 제공되며, Muse Spark 1.2는 OrcaRouter 카탈로그에 있고 여기서는 Meta의 정가인 입력 토큰 백만 개당 $1.25, 출력 토큰 백만 개당 $4.25로 청구됩니다 — 제공업체의 정가를 그대로 전달하며 저희 쪽에서는 마진을 붙이지 않으므로, Meta의 가격 변경은 그쪽에 적용되는 당일 바로 여기에도 적용됩니다. 키 하나로 200개가 넘는 다른 모델들과 함께 이용할 수 있고, 제공업체에 문제가 생기면 자동 장애 조치가 이루어지는데, 이는 "한번 시도해 볼 수 있다"와 "이걸 프로덕션 경로에 올릴 수 있다"의 차이입니다. 이 페이지에서 실제로 원하셨던 것이 Muse Code 제품을 도입하지 않고 Muse Code 내부의 지능을 사용하는 방법이었다면, 그것이 바로 그 경로이며, 실제로 존재합니다. 원하셨던 것이 AesCode 32B였다면, 그 경로는 다운로드입니다.

어느 것을 고를까?

만약 결과물이 핵심이라면 AesCode 32B를 선택하세요. 당신은 대량으로 덱, 보고서, 포스터 또는 대시보드를 제작하고 있고, 하드웨어를 보유하고 있거나 임대할 의향이 있으며, 구조화되고 편집 가능한 HTML을 생성하는 모델의 매력 — 표는 표로, 차트는 ECharts 스펙으로, 모든 것이 Git에서 diff 가능 — 은 연구급 서빙 설정을 할 가치가 있습니다. 당신이 다운로드 수가 적은 미발표 모델의 얼리 어답터라는 점, 어떤 독립 연구소도 그 점수를 재현하지 못했다는 점, 그리고 24K 컨텍스트가 긴 문서에 실질적인 제약이라는 점을 받아들이세요.

과정이 핵심이라면 Muse Code를 선택하세요. 터미널에서 실행되고, 세션 중간에 충돌이 나도 살아남고, 격리된 워크트리에서 여러 워크스트림을 동시에 유지할 수 있는 에이전트를 원하고, 토큰당 또는 월 단위로 지불해도 괜찮다면.

필요한 게 API 키 뒤에 있는 유능한 추론 모델이었고 터미널 하네스는 애초에 원하던 부분이 아니었다면, 둘 중 어느 것도 고르지 말고 Muse Spark 1.2로 바로 라우팅하세요.

이 페이지를 바꾸려면 무엇이 필요할까요

세 가지입니다. 추론 제공업체가 AesCode 32B를 채택하거나 Microsoft가 호스팅 엔드포인트를 공개하면, 배포 항목이 무너지고 그 모델은 반나절이면 평가할 수 있는 대상이 됩니다. 그러면 디자인 비중이 큰 팀에게 이 질문은 훨씬 더 팽팽한 문제가 될 겁니다. 독립 평가가 85.89 Overall과 4.3% 경계 실패율을 재현한다면, 증거 비대칭은 상당히 줄어듭니다. 그리고 Meta가 Muse Spark 가중치를 공개하면, "하나는 다운로드할 수 있고 다른 하나는 그럴 수 없다"는 프레이밍은 완전히 사라집니다. 그중 하나가 실현되기 전까지 솔직한 요약은 이 두 제품이 단어만 공유할 뿐, 하는 일은 공유하지 않는다는 것입니다.