MiniMax M2.1은 중국 AI 기업 MiniMax가 2025년 12월 23일 공개한 코딩·에이전트용 오픈 웨이트 모델이다. 이전 M2가 비용 효율성과 폭넓은 접근성을 앞세웠다면, M2.1은 실제 소프트웨어 프로젝트와 복잡한 에이전트 업무를 수행하는 데 초점을 맞췄다. 다국어 소프트웨어 엔지니어링, 풀스택 애플리케이션 제작, 네이티브 모바일 개발, 문서 작성과 사무 자동화가 주요 대상이다. 34

다만 성능 수치의 상당 부분은 MiniMax 자체 평가에서 나온 결과다. 따라서 이번 출시는 모델이 어떤 방향을 지향하는지 보여주는 자료로 볼 수 있지만, 독립 기관이 확정한 모든 모델의 순위로 해석해서는 안 된다.

MiniMax M2.1은 어떤 모델인가

M2.1은 총 2,300억 개 파라미터와 토큰당 약 100억 개의 활성 파라미터를 사용하는 혼합 전문가(Mixture-of-Experts·MoE) 모델이다. 필요한 전문가 일부만 활성화하는 희소 구조를 통해, 비슷한 규모의 모든 파라미터를 매번 사용하는 밀집형 모델보다 추론 효율을 높이려는 설계다. 1

MiniMax가 강조하는 지점은 코딩 모델이 단순한 Python 예제나 독립 함수만 처리해서는 실제 개발에 충분하지 않다는 것이다. 현실의 프로젝트에는 여러 언어로 구성된 코드베이스, 기존 저장소, 모바일 플랫폼, 시각적 인터페이스, 프로젝트별 지침, 도구 호출, 서로 연결된 여러 단계의 작업이 함께 들어간다. M2.1은 이런 전체 흐름을 염두에 두고 설계됐다.

M2에서 무엇이 달라졌나

MiniMax는 M2.1을 M2의 ‘저렴하고 쉽게 접근할 수 있는 모델’이라는 방향에서, 복잡하고 실무 지향적인 작업을 더 안정적으로 수행하는 모델로 확장한 버전이라고 설명한다. 특히 여러 프로그래밍 언어를 넘나드는 개발과 일상적인 오피스·에이전트 업무에 초점을 맞췄다. 4

주요 변화는 다음과 같다.

• 프로그래밍 언어 범위 확대: Rust, Java, Go, C++, Kotlin, Objective-C, TypeScript, JavaScript 등을 강화했으며 Python도 함께 다룬다. 37
• 풀스택 애플리케이션 제작: 서로 분리된 코드 조각을 만드는 데 그치지 않고, 완전하고 작동하는 애플리케이션을 구현하는 것을 목표로 한다. 34
• 네이티브 모바일 개발 강화: AI 시스템의 지속적인 약점으로 지적돼 온 Android와 iOS 개발 역량을 특히 강조한다. 4
• 에이전트 실행 능력 개선: 도구, 프로젝트 파일, 지침, 메모리, 여러 작업 단계를 함께 처리하는 워크플로를 겨냥한다. 4
• 문서·오피스 업무 지원: 구조화된 글쓰기, 기술 문서, 데이터 중심 업무, 지속적인 에이전트 워크플로의 개선을 내세운다. 4

즉 MiniMax의 설명대로라면 M2.1은 단순히 더 크거나 저렴한 코딩 모델이 아니다. 요구사항과 인터페이스를 이해하고, 도구를 호출하며, 여러 파일을 수정하고, 최종적으로 전달 가능한 소프트웨어를 만드는 상황을 목표로 한 업데이트다.

지원과 개선이 강조된 프로그래밍 언어

MiniMax는 M2.1에서 Rust, Java, Golang, C++, Kotlin, Objective-C, TypeScript, JavaScript 및 기타 언어의 능력을 체계적으로 강화했다고 밝혔다. 외부 분석 역시 Java, Go, Rust, C++, TypeScript, JavaScript, Kotlin, Python에 특화된 전문가 구성을 언급한다. 37

이 변화는 기술 스택이 한 가지 언어로 통일되지 않은 조직에 특히 중요하다. Python 작업에서는 뛰어난 모델이라도, 실제 저장소에 Java·Go 기반 백엔드와 Rust·C++ 시스템 코드, TypeScript·JavaScript 웹 인터페이스, Kotlin·Objective-C 모바일 코드가 함께 있다면 성능이 달라질 수 있기 때문이다.

Claude 모델과 비교하면 어떤가

MiniMax는 다국어 소프트웨어 엔지니어링 시나리오에서 M2.1이 Claude Sonnet 4.5를 앞서고 Claude Opus 4.5에 근접한다고 주장한다. 회사가 공개한 SWE-bench Multilingual 점수는 **72.5%**다. 316

그러나 이 수치를 독립적인 최종 결론으로 받아들이기는 어렵다. 인용된 자료만으로는 중립적인 기관이 동일한 조건에서 재현한 순위가 확인되지 않으며, 프롬프트와 에이전트 구성, 모델 버전, 평가 절차에 따라 결과가 달라질 수 있다. 이후 공개된 외부 분석에서는 M2.1이 SWE-bench Verified에서 M2보다 개선됐지만, 여러 강력한 독점 모델에는 여전히 뒤처진 것으로 나타났다. 7

따라서 가장 신중한 결론은 다음과 같다. MiniMax는 다국어 저장소 단위 코딩을 M2.1의 핵심 강점으로 삼고 있으며, 공개 결과는 이전 모델보다 상당한 개선이 있었음을 시사한다. 하지만 이 결과만으로 모든 소프트웨어 프로젝트나 워크플로에서 Claude보다 우수하다고 단정할 수는 없다.

VIBE 벤치마크란

VIBE는 Visual & Interactive Benchmark for Execution의 약자로, ‘시각적·상호작용 기반 실행 벤치마크’로 풀이할 수 있다. MiniMax가 만든 이 평가 체계는 모델이 그럴듯한 코드를 생성하는지를 넘어, 처음부터 완전하고 실제로 사용할 수 있는 애플리케이션을 구축하는지를 측정한다. 34

VIBE는 다음 다섯 영역으로 구성된다.

• 웹(Web)
• 시뮬레이션(Simulation)
• Android
• iOS
• 백엔드(Backend)

평가는 배포된 애플리케이션과 실제 상호작용·시각적 검증을 중심으로 진행된다. 따라서 전통적인 코딩 벤치마크가 충분히 포착하지 못할 수 있는 요소, 예를 들어 앱이 실제 사용 환경에서 작동하는지, 상호작용이 올바르게 동작하는지, 인터페이스가 시각적 기대를 충족하는지를 확인하려는 평가다. 4

M2.1의 VIBE 공개 점수

MiniMax는 VIBE 종합 점수로 88.6점을 제시했다. 세부적으로는 VIBE-Web 91.5점, VIBE-Android 89.7점이다. 48

이 수치가 주목받는 이유는 단순한 코드 완성이나 버그 수정이 아니라, 애플리케이션을 실제로 만들어 전달하는 능력을 평가하기 때문이다. 다만 VIBE 자체가 MiniMax가 만든 벤치마크이고, 모델 간 비교 역시 MiniMax의 평가 환경에서 산출됐다. 따라서 이 점수는 모델이 어떤 능력을 목표로 하는지 보여주는 회사 발표 자료로 보는 것이 적절하며, 독립적으로 확정된 업계 순위로 보기는 어렵다. 48

모바일·웹·앱 개발에서의 활용

MiniMax는 M2.1이 브라우저 기반 애플리케이션뿐 아니라 네이티브 Android와 iOS 개발에서도 더 강해졌다고 설명한다. 시각적 디자인과 미적 요소, 복잡한 상호작용, 3D 과학 시뮬레이션, 고품질 시각화에 대한 이해도 개선했다고 밝혔다. 4

이는 자연어로 애플리케이션을 설명하면 에이전트가 작동하는 제품을 조립하는 이른바 ‘바이브 코딩(vibe coding)’을 한 단계 확장하려는 접근이다. MiniMax가 내세우는 목표는 보기 좋은 데모를 만드는 데서 끝나는 것이 아니라, 유지보수할 수 있고 실제 업무에 전달 가능한 애플리케이션을 생성하는 것이다. 4

다만 이 목표가 실제로 달성되는지는 실사용 저장소에서 확인해야 한다. 모바일 빌드 시스템, 의존성 충돌, 플랫폼별 관례, 접근성, 보안 검토, 장기 유지보수는 어떤 벤치마크 점수로도 대체할 수 없는 실무 검증 항목이다.

복잡한 업무를 위한 ‘Interleaved Thinking’

MiniMax는 Interleaved Thinking을 작업을 수행하는 동안 체계적으로 문제를 해결하는 접근법으로 소개한다. 시스템 지침, 사용자 요구사항, 메모리, 도구 스키마, 프로젝트 지침 파일처럼 서로 다른 제약을 한 번에 유지하도록 돕는 것이 목적이다. 4

이는 에이전트 업무에서 중요하다. 성공적인 결과는 코드가 실행되는지 여부만으로 결정되지 않기 때문이다. 에이전트는 다음과 같은 과정을 함께 수행해야 할 수 있다.

1. 기존 프로젝트를 점검한다.
2. 저장소별 지침을 따른다.
3. 알맞은 도구를 선택해 사용한다.
4. 여러 파일을 서로 맞물리게 수정한다.
5. 문서나 구조화된 결과물을 작성한다.
6. 최종 결과가 처음 요구사항을 충족하는지 확인한다.

MiniMax는 이 기능을 기술 문서, 구조화된 글쓰기, 데이터 처리, 지속적인 오피스 자동화와 연결한다. 모든 다단계 업무를 안정적으로 끝낸다는 증거라기보다는, M2.1을 단순 코드 생성기가 아니라 코딩·에이전트 모델로 포지셔닝하는 이유를 보여주는 설명에 가깝다. 4

M2.1에 접근하고 배포하는 방법

개발자가 선택할 수 있는 경로는 크게 두 가지다.

• API 이용: MiniMax가 제공하는 호스팅 API를 통해 M2.1을 사용할 수 있다. 46
• 직접 배포: 모델 가중치가 Hugging Face에 공개돼 있어 자체 서빙 환경을 구성할 수 있다. 46

MiniMax의 배포 안내는 SGLang 사용을 권장하며, 관련 배포 생태계에서는 vLLM도 지원된다. 141 직접 운영하면 API만 사용하는 방식보다 인프라, 데이터 처리, 모델 서빙, 연동, 확장 정책을 조직이 더 직접 통제할 수 있다.

다만 오픈 웨이트와 자체 배포가 곧바로 총비용 절감을 의미하는 것은 아니다. 자체 운영에는 충분한 GPU 자원, 엔지니어링 시간, 모니터링, 유지보수, 운영 지원이 필요하다. 실제 경제성은 활성 파라미터 수만이 아니라 사용량과 인프라 선택에 따라 달라진다. 12

결론: M2.1은 누구에게 적합한가

M2.1과 M2의 가장 큰 차이는 초점의 이동이다. M2.1은 접근성과 추론 효율을 중심으로 설명된 모델에서 벗어나, 다국어·풀스택·에이전트 기반 업무를 겨냥한 모델로 포지셔닝됐다. MiniMax가 공개한 SWE-bench Multilingual 72.5%와 VIBE 88.6점, VIBE-Web 91.5점·VIBE-Android 89.7점은 이러한 방향성을 뒷받침한다. 348

개발자에게 매력적인 요소는 넓은 언어 지원, 오픈 웨이트, API 접근성, SGLang·vLLM을 통한 배포 선택권이다. 기업 입장에서는 서빙 환경과 데이터 처리에 대한 통제권을 확보하면서 더 복잡한 코딩·자동화 업무를 운영할 가능성이 핵심이다.

반대로 가장 중요한 주의점도 분명하다. 주요 모델 비교와 새 VIBE 결과는 대부분 MiniMax가 직접 보고한 수치다. M2.1을 도입하려는 팀이라면 벤치마크를 그대로 받아들이기보다 자체 코드 저장소, 모바일 빌드, 문서화 요구사항, 보안 통제, 자동화 업무를 기준으로 먼저 검증해야 한다.

MiniMax M2.1은 중국 AI 기업 MiniMax가 2025년 12월 23일 공개한 코딩·에이전트용 오픈 웨이트 모델이다. 이전 M2가 비용 효율성과 폭넓은 접근성을 앞세웠다면, M2.1은 실제 소프트웨어 프로젝트와 복잡한 에이전트 업무를 수행하는 데 초점을 맞췄다. 다국어 소프트웨어 엔지니어링, 풀스택 애플리케이션 제작, 네이티브 모바일 개발, 문서 작성과 사무 자동화가 주요 대상이다. 34

다만 성능 수치의 상당 부분은 MiniMax 자체 평가에서 나온 결과다. 따라서 이번 출시는 모델이 어떤 방향을 지향하는지 보여주는 자료로 볼 수 있지만, 독립 기관이 확정한 모든 모델의 순위로 해석해서는 안 된다.

MiniMax M2.1은 어떤 모델인가

M2.1은 총 2,300억 개 파라미터와 토큰당 약 100억 개의 활성 파라미터를 사용하는 혼합 전문가(Mixture-of-Experts·MoE) 모델이다. 필요한 전문가 일부만 활성화하는 희소 구조를 통해, 비슷한 규모의 모든 파라미터를 매번 사용하는 밀집형 모델보다 추론 효율을 높이려는 설계다. 1

MiniMax가 강조하는 지점은 코딩 모델이 단순한 Python 예제나 독립 함수만 처리해서는 실제 개발에 충분하지 않다는 것이다. 현실의 프로젝트에는 여러 언어로 구성된 코드베이스, 기존 저장소, 모바일 플랫폼, 시각적 인터페이스, 프로젝트별 지침, 도구 호출, 서로 연결된 여러 단계의 작업이 함께 들어간다. M2.1은 이런 전체 흐름을 염두에 두고 설계됐다.

M2에서 무엇이 달라졌나

MiniMax는 M2.1을 M2의 ‘저렴하고 쉽게 접근할 수 있는 모델’이라는 방향에서, 복잡하고 실무 지향적인 작업을 더 안정적으로 수행하는 모델로 확장한 버전이라고 설명한다. 특히 여러 프로그래밍 언어를 넘나드는 개발과 일상적인 오피스·에이전트 업무에 초점을 맞췄다. 4

주요 변화는 다음과 같다.

• 프로그래밍 언어 범위 확대: Rust, Java, Go, C++, Kotlin, Objective-C, TypeScript, JavaScript 등을 강화했으며 Python도 함께 다룬다. 37
• 풀스택 애플리케이션 제작: 서로 분리된 코드 조각을 만드는 데 그치지 않고, 완전하고 작동하는 애플리케이션을 구현하는 것을 목표로 한다. 34
• 네이티브 모바일 개발 강화: AI 시스템의 지속적인 약점으로 지적돼 온 Android와 iOS 개발 역량을 특히 강조한다. 4
• 에이전트 실행 능력 개선: 도구, 프로젝트 파일, 지침, 메모리, 여러 작업 단계를 함께 처리하는 워크플로를 겨냥한다. 4
• 문서·오피스 업무 지원: 구조화된 글쓰기, 기술 문서, 데이터 중심 업무, 지속적인 에이전트 워크플로의 개선을 내세운다. 4

즉 MiniMax의 설명대로라면 M2.1은 단순히 더 크거나 저렴한 코딩 모델이 아니다. 요구사항과 인터페이스를 이해하고, 도구를 호출하며, 여러 파일을 수정하고, 최종적으로 전달 가능한 소프트웨어를 만드는 상황을 목표로 한 업데이트다.

지원과 개선이 강조된 프로그래밍 언어

MiniMax는 M2.1에서 Rust, Java, Golang, C++, Kotlin, Objective-C, TypeScript, JavaScript 및 기타 언어의 능력을 체계적으로 강화했다고 밝혔다. 외부 분석 역시 Java, Go, Rust, C++, TypeScript, JavaScript, Kotlin, Python에 특화된 전문가 구성을 언급한다. 37

이 변화는 기술 스택이 한 가지 언어로 통일되지 않은 조직에 특히 중요하다. Python 작업에서는 뛰어난 모델이라도, 실제 저장소에 Java·Go 기반 백엔드와 Rust·C++ 시스템 코드, TypeScript·JavaScript 웹 인터페이스, Kotlin·Objective-C 모바일 코드가 함께 있다면 성능이 달라질 수 있기 때문이다.

Claude 모델과 비교하면 어떤가

MiniMax는 다국어 소프트웨어 엔지니어링 시나리오에서 M2.1이 Claude Sonnet 4.5를 앞서고 Claude Opus 4.5에 근접한다고 주장한다. 회사가 공개한 SWE-bench Multilingual 점수는 **72.5%**다. 316

그러나 이 수치를 독립적인 최종 결론으로 받아들이기는 어렵다. 인용된 자료만으로는 중립적인 기관이 동일한 조건에서 재현한 순위가 확인되지 않으며, 프롬프트와 에이전트 구성, 모델 버전, 평가 절차에 따라 결과가 달라질 수 있다. 이후 공개된 외부 분석에서는 M2.1이 SWE-bench Verified에서 M2보다 개선됐지만, 여러 강력한 독점 모델에는 여전히 뒤처진 것으로 나타났다. 7

따라서 가장 신중한 결론은 다음과 같다. MiniMax는 다국어 저장소 단위 코딩을 M2.1의 핵심 강점으로 삼고 있으며, 공개 결과는 이전 모델보다 상당한 개선이 있었음을 시사한다. 하지만 이 결과만으로 모든 소프트웨어 프로젝트나 워크플로에서 Claude보다 우수하다고 단정할 수는 없다.

VIBE 벤치마크란

VIBE는 Visual & Interactive Benchmark for Execution의 약자로, ‘시각적·상호작용 기반 실행 벤치마크’로 풀이할 수 있다. MiniMax가 만든 이 평가 체계는 모델이 그럴듯한 코드를 생성하는지를 넘어, 처음부터 완전하고 실제로 사용할 수 있는 애플리케이션을 구축하는지를 측정한다. 34

VIBE는 다음 다섯 영역으로 구성된다.

• 웹(Web)
• 시뮬레이션(Simulation)
• Android
• iOS
• 백엔드(Backend)

평가는 배포된 애플리케이션과 실제 상호작용·시각적 검증을 중심으로 진행된다. 따라서 전통적인 코딩 벤치마크가 충분히 포착하지 못할 수 있는 요소, 예를 들어 앱이 실제 사용 환경에서 작동하는지, 상호작용이 올바르게 동작하는지, 인터페이스가 시각적 기대를 충족하는지를 확인하려는 평가다. 4

M2.1의 VIBE 공개 점수

MiniMax는 VIBE 종합 점수로 88.6점을 제시했다. 세부적으로는 VIBE-Web 91.5점, VIBE-Android 89.7점이다. 48

이 수치가 주목받는 이유는 단순한 코드 완성이나 버그 수정이 아니라, 애플리케이션을 실제로 만들어 전달하는 능력을 평가하기 때문이다. 다만 VIBE 자체가 MiniMax가 만든 벤치마크이고, 모델 간 비교 역시 MiniMax의 평가 환경에서 산출됐다. 따라서 이 점수는 모델이 어떤 능력을 목표로 하는지 보여주는 회사 발표 자료로 보는 것이 적절하며, 독립적으로 확정된 업계 순위로 보기는 어렵다. 48

모바일·웹·앱 개발에서의 활용

MiniMax는 M2.1이 브라우저 기반 애플리케이션뿐 아니라 네이티브 Android와 iOS 개발에서도 더 강해졌다고 설명한다. 시각적 디자인과 미적 요소, 복잡한 상호작용, 3D 과학 시뮬레이션, 고품질 시각화에 대한 이해도 개선했다고 밝혔다. 4

이는 자연어로 애플리케이션을 설명하면 에이전트가 작동하는 제품을 조립하는 이른바 ‘바이브 코딩(vibe coding)’을 한 단계 확장하려는 접근이다. MiniMax가 내세우는 목표는 보기 좋은 데모를 만드는 데서 끝나는 것이 아니라, 유지보수할 수 있고 실제 업무에 전달 가능한 애플리케이션을 생성하는 것이다. 4

다만 이 목표가 실제로 달성되는지는 실사용 저장소에서 확인해야 한다. 모바일 빌드 시스템, 의존성 충돌, 플랫폼별 관례, 접근성, 보안 검토, 장기 유지보수는 어떤 벤치마크 점수로도 대체할 수 없는 실무 검증 항목이다.

복잡한 업무를 위한 ‘Interleaved Thinking’

MiniMax는 Interleaved Thinking을 작업을 수행하는 동안 체계적으로 문제를 해결하는 접근법으로 소개한다. 시스템 지침, 사용자 요구사항, 메모리, 도구 스키마, 프로젝트 지침 파일처럼 서로 다른 제약을 한 번에 유지하도록 돕는 것이 목적이다. 4

이는 에이전트 업무에서 중요하다. 성공적인 결과는 코드가 실행되는지 여부만으로 결정되지 않기 때문이다. 에이전트는 다음과 같은 과정을 함께 수행해야 할 수 있다.

1. 기존 프로젝트를 점검한다.
2. 저장소별 지침을 따른다.
3. 알맞은 도구를 선택해 사용한다.
4. 여러 파일을 서로 맞물리게 수정한다.
5. 문서나 구조화된 결과물을 작성한다.
6. 최종 결과가 처음 요구사항을 충족하는지 확인한다.

MiniMax는 이 기능을 기술 문서, 구조화된 글쓰기, 데이터 처리, 지속적인 오피스 자동화와 연결한다. 모든 다단계 업무를 안정적으로 끝낸다는 증거라기보다는, M2.1을 단순 코드 생성기가 아니라 코딩·에이전트 모델로 포지셔닝하는 이유를 보여주는 설명에 가깝다. 4

M2.1에 접근하고 배포하는 방법

개발자가 선택할 수 있는 경로는 크게 두 가지다.

• API 이용: MiniMax가 제공하는 호스팅 API를 통해 M2.1을 사용할 수 있다. 46
• 직접 배포: 모델 가중치가 Hugging Face에 공개돼 있어 자체 서빙 환경을 구성할 수 있다. 46

MiniMax의 배포 안내는 SGLang 사용을 권장하며, 관련 배포 생태계에서는 vLLM도 지원된다. 141 직접 운영하면 API만 사용하는 방식보다 인프라, 데이터 처리, 모델 서빙, 연동, 확장 정책을 조직이 더 직접 통제할 수 있다.

다만 오픈 웨이트와 자체 배포가 곧바로 총비용 절감을 의미하는 것은 아니다. 자체 운영에는 충분한 GPU 자원, 엔지니어링 시간, 모니터링, 유지보수, 운영 지원이 필요하다. 실제 경제성은 활성 파라미터 수만이 아니라 사용량과 인프라 선택에 따라 달라진다. 12

결론: M2.1은 누구에게 적합한가

M2.1과 M2의 가장 큰 차이는 초점의 이동이다. M2.1은 접근성과 추론 효율을 중심으로 설명된 모델에서 벗어나, 다국어·풀스택·에이전트 기반 업무를 겨냥한 모델로 포지셔닝됐다. MiniMax가 공개한 SWE-bench Multilingual 72.5%와 VIBE 88.6점, VIBE-Web 91.5점·VIBE-Android 89.7점은 이러한 방향성을 뒷받침한다. 348

개발자에게 매력적인 요소는 넓은 언어 지원, 오픈 웨이트, API 접근성, SGLang·vLLM을 통한 배포 선택권이다. 기업 입장에서는 서빙 환경과 데이터 처리에 대한 통제권을 확보하면서 더 복잡한 코딩·자동화 업무를 운영할 가능성이 핵심이다.

반대로 가장 중요한 주의점도 분명하다. 주요 모델 비교와 새 VIBE 결과는 대부분 MiniMax가 직접 보고한 수치다. M2.1을 도입하려는 팀이라면 벤치마크를 그대로 받아들이기보다 자체 코드 저장소, 모바일 빌드, 문서화 요구사항, 보안 통제, 자동화 업무를 기준으로 먼저 검증해야 한다.