Mavis 전환과 M3 모델의 기술적 제약 조건

MiniMax는 2026년 5월 27일 기존의 MiniMax Agent를 Mavis(MiniMax as a Jarvis)로 개편하고 차세대 M3 모델을 출시했다. M3 모델은 희소 주의 집중(Sparse Attention) 구조를 채택하여 연산량을 최적화함으로써 최대 100만 토큰의 컨텍스트 윈도우를 지원한다. 개발자는 Mavis API를 통해 Anthropic 메시지 포맷과 호환되는 방식으로 M3 모델을 호출할 수 있으며, 이를 통해 100만 토큰 컨텍스트 내에서 데이터 처리 제약을 확인할 수 있다. M3 모델은 텍스트뿐만 아니라 네이티브 멀티모달 입력을 지원하여 이미지 내 복잡한 도표나 텍스트를 직접 분석하고 추론하는 기능을 제공한다.

MiniMax는 서비스 이용 체계를 단순화하기 위해 기존의 TokenPlan과 Agent Plan을 하나의 통합 플랜으로 합쳤다. 사용자는 단일 키와 공유 크레딧 풀을 통해 명령줄 인터페이스(CLI), API, 에이전트 제품군을 통합 관리하며 자원을 유연하게 배분한다. 이러한 통합은 개발자가 API로 프로토타입을 검증한 뒤 에이전트 제품으로 배포하는 과정에서 발생하는 계정 관리 비용을 제거한다. Mavis는 단순한 모델 업데이트가 아니라 데스크톱 앱에서 여러 에이전트를 병렬로 실행하여 협업하게 만드는 운영 방식의 변화를 핵심으로 한다.

'심판과 선수' 문제를 해결하는 팀 엔진 구조

MiniMax는 단일 에이전트가 결과물을 생성하고 스스로 검토할 때 발생하는 '심판과 선수' 문제, 즉 자기 비판의 일관성 결여 문제를 해결하기 위해 에이전트 팀(Agent Teams) 구조를 도입했다. 이 구조는 리더(Leader), 워커(Worker), 검증자(Verifier)의 세 가지 역할로 과업을 분리하여 생성 주체와 검증 주체가 서로를 견제하도록 설계했다. Mavis의 리더 에이전트는 과업 시작 전 해당 작업이 팀 단위로 분할하여 수행할 가치가 있는지 먼저 판단하며, 오타 수정과 같은 단순 작업은 단일 에이전트나 스크립트로 처리하도록 유도하여 내부 마찰을 최소화한다.

팀 엔진(Team Engine)은 지속적 상태 머신(State Machine)을 기반으로 각 과업을 생성(Producing), 검증(Verifying), 완료(Done) 상태로 추적하고 관리한다. 워커가 생성한 결과물이 검증 단계에서 실패 판정을 받으면, 팀 엔진은 자동으로 생성 단계의 에이전트를 다시 깨워 재작업을 수행하게 만든다. 이는 멀티 에이전트 협업을 단순한 일회성 함수 호출이나 텍스트 블록 반환으로 처리하지 않고, 작업이 완전히 완결될 때까지 상태를 유지하며 비동기적으로 제어하는 방식이다. 이러한 설계는 모델이 자신의 오류를 무비판적으로 수용하는 현상을 억제하고 최종 결과물의 논리적 완결성을 높인다.

OpenAI·Anthropic 에이전트 설계와의 차별점

Mavis의 팀 엔진은 OpenAI Agents SDK가 채택한 핸드오프(Handoff) 기반의 순차적 흐름이나, 랭그래프(LangGraph)의 감독 노드 중심 명시적 워크플로우 그래프와 구별되는 상태 기반 자동 회귀 시스템을 지향한다. OpenAI의 방식이 작업 권한을 순차적으로 넘기는 파이프라인 구조라면, Mavis는 팀 엔진이 전체 상태를 유지하며 검증 실패 시 이전 단계로 회귀하는 루프를 자동으로 관리한다. 이는 개발자가 미리 정의한 경로를 따라가는 것이 아니라, 작업의 실제 진행 상태에 따라 엔진이 유연하게 다음 동작을 결정하는 구조적 차이를 만든다.

클로드 코드 팀즈(Claude Code Teams)가 리드 에이전트를 통해 격리된 팀원들에게 작업을 할당하고 취합하는 중앙 집중식 구조를 사용하는 것과 달리, Mavis는 비동기 처리 방식을 통해 작업 완결성을 확보한다. 리더 에이전트가 계획을 확정하면 세부 작업은 배경에서 독립적으로 진행되며, 사용자는 중간 사고 과정을 실시간으로 대기할 필요 없이 최종 결과물만을 전달받는다. 이러한 방식은 단일 에이전트가 긴 작업을 수행할 때 종료 시점을 판단하지 못하고 사용자에게 계속 확인을 요청하는 '컨텍스트 불안(Context Anxiety)' 현상을 구조적으로 방지한다.

합의 비용(Cost of Consensus)과 토큰 리스크

MiniMax는 구조 없는 동질적 모델 간의 멀티 에이전트 토론이 단일 에이전트의 자가 수정 방식보다 토큰 비용을 2.1배에서 3.4배까지 증가시키지만, 정확도는 향상되지 않는다는 '합의 비용(Cost of Consensus)' 수치를 제시했다. 이는 명확한 역할 분담과 상태 제어 없이 단순히 여러 에이전트를 투입하는 방식이 실질적인 성능 개선 없이 비용만 높이는 비효율적인 연산임을 의미한다. 따라서 Mavis는 리더, 워커, 검증자의 엄격한 분리를 통해 이러한 무분별한 토큰 소모를 제어하고 구조적 협업을 강제한다.

멀티 에이전트 시스템 운영 시에는 세 가지 구체적인 비용 오버헤드가 발생한다. 첫째, 연구-작성-포맷팅 에이전트 간에 정보를 재구성하며 발생하는 핸드오프 비용(Handoff cost)이 토큰과 시간을 소모한다. 둘째, 모든 워커가 공유 컨텍스트를 참조할 때마다 중복 토큰이 발생하는 공유 비용(Sharing cost)이 누적된다. 셋째, 병렬로 생성된 여러 초안의 사실 관계를 교차 검증하고 문체를 통일하여 하나의 문서로 합치는 집계 비용(Aggregation cost)이 발생하며, 이는 고도의 추론 능력을 요구하는 가장 어려운 단계다.

실무 도입 판단 기준과 법적 제약 사항

기업이 Mavis를 도입할 때의 핵심 판단 기준은 '단일 에이전트의 표류(Drifting) 비용'이 '팀 운영 오버헤드'보다 큰지 여부다. 표류란 에이전트가 복잡한 다단계 작업을 수행하며 초기 목적을 잊고 논리적 일관성을 상실하는 현상을 말하며, 단위 테스트나 린팅처럼 결과 검증이 명확하고 작업 단계가 긴 과업일수록 Mavis의 팀 구조가 유리하다. 반면 단순한 상수 변경이나 짧은 작업은 단일 에이전트나 스크립트를 사용하는 것이 비용과 속도 면에서 효율적이다.

모델 라이선스와 법적 리스크는 도입 전 반드시 확인해야 할 제약 조건이다. MiniMax는 M2.7 모델의 가중치를 Hugging Face에 공개했으나, M2 및 M2.5와 달리 상업적 이용 시에는 반드시 서면 승인을 받도록 라이선스 조건을 변경했다. 또한 MiniMax는 Anthropic 모델을 증류(Distillation)했다는 의혹을 받고 있으며, 디즈니, 유니버설, 워너브라더스 등 글로벌 영상 제작사로부터 비디오 제품의 저작권 침해 소송을 당한 상태다. 이러한 컴플라이언스 리스크는 모델의 벤치마크 성능과 별개로 서비스 중단 가능성을 내포하므로 법무 검토가 선행되어야 한다.

결론적으로 작업이 충분히 길고 결과 검증이 가능하여 단일 에이전트의 표류 비용이 팀 운영 오버헤드보다 클 때만 Mavis 도입이 유리하다.