이제 코딩 AI를 볼 때 질문은 많이 달라졌습니다. "이 모델이 그럴듯한 코드를 만들 수 있나"보다 더 중요한 건, 실제로 팀의 총 일을 줄이느냐는 점입니다. AI가 더 큰 기능을 끝까지 구현할수록, 숨은 비용은 오히려 리뷰·검증·재작업 쪽에서 커지기 쉽기 때문입니다.
그 기준으로 보면 Xiaomi의 MiMo-V2.5-Pro는 흥미로운 신호입니다. 이 모델은 1.02조 파라미터 규모의 MoE 구조에 42B 활성 파라미터, 최대 100만 토큰 컨텍스트를 내세우며, 수백~수천 번의 도구 호출이 필요한 장기 코딩 작업을 겨냥합니다.1 Xiaomi는 Rust 기반 SysY 컴파일러를 4.3시간, 672회 툴 호출로 완성했고, 11.5시간 동안 자율적으로 비디오 편집기 앱을 만들었다고 공개했습니다.23 중요한 건 "오래 돌았다"가 아니라, 이런 유형의 모델이 실제 개발 흐름 일부를 대체할 수 있는지입니다.
핵심은 성능이 아니라 총 사이클 타임이다
확인 가능한 사실부터 보죠. MiMo-V2.5-Pro는 Xiaomi 발표 기준으로 장기 작업과 에이전트형 코딩에 초점을 둔 모델입니다. 1M 컨텍스트, 하이브리드 어텐션, 멀티 토큰 예측(MTP), 그리고 대규모 에이전틱 RL을 결합해 긴 작업 궤적을 유지하도록 설계됐습니다.1
이 사실이 중요한 이유는, 이제 코딩 모델의 경쟁 단위가 "한 번의 답변"이 아니라 "작업 세션 전체"로 바뀌고 있기 때문입니다. 예를 들어 기능 하나를 끝까지 구현하려면 계획, 파일 탐색, 수정, 테스트, 회귀 수정, 환경 적응이 이어집니다. MiMo-V2.5-Pro가 겨냥하는 건 바로 이 긴 루프입니다.
다만 여기서 바로 "Claude Opus급 대체재"라고 단정하면 곤란합니다. Xiaomi와 외부 기사들은 SWE-Bench Pro, Terminal-Bench, ClawEval 같은 지표에서 Claude Opus 4.6에 근접하거나 일부 항목에서 앞선다고 전하지만, 상당수 수치는 Xiaomi 측 평가와 내부 벤치에 기대고 있습니다.23 즉, 실력은 분명 올라왔지만, 팀 도입 판단은 벤치마크보다 "머지까지 걸린 시간"으로 내려야 합니다.
먼저 바뀔 가능성이 큰 워크플로는 따로 있다
이런 모델이 처음부터 모든 개발 업무를 바꾸지는 않을 겁니다. 대신 긴 호흡과 반복적 도구 사용이 이득인 영역에서 먼저 효용이 날 가능성이 큽니다.
첫째는 프로토타입을 실제 동작물까지 밀어붙이는 작업입니다. Xiaomi가 공개한 8,192줄 규모 비디오 편집기 사례는, 단순 코드 생성보다 기능 조립과 상태 유지가 강한 모델임을 보여주려는 데모에 가깝습니다.2
둘째는 리포지토리 단위 리팩터링입니다. 큰 컨텍스트와 장기 일관성은 여러 파일에 걸친 규칙 변경, API 마이그레이션, 테스트 보수 같은 유지보수성 높은 작업과 맞닿아 있습니다.
셋째는 다단계 디버깅입니다. 초기 수정이 다른 곳을 깨뜨리고, 다시 로그와 테스트를 읽어 되돌아가는 유형의 버그는 짧은 채팅형 모델보다 에이전트형 모델에 더 적합합니다.
넷째는 외부 툴을 많이 쓰는 구현 작업입니다. Xiaomi는 ngspice 시뮬레이션 루프 같은 사례도 제시했는데, 여기서 핵심은 특정 도메인 지식보다도 "도구를 호출하고 결과를 읽어 다음 행동을 정하는 루프"를 오래 유지하는 능력입니다.2
써보려면 데모 말고 '리뷰 부채'까지 측정해야 한다
실무에서 가장 흔한 착시는, AI가 혼자 오래 일한 시간을 생산성으로 오해하는 것입니다. 11시간 자율 실행은 인상적이지만, 사람이 마지막에 2시간 동안 구조를 뜯어고쳤다면 절감된 시간은 생각보다 작을 수 있습니다.
그래서 테스트는 간단해야 하지만 측정값은 냉정해야 합니다. 기능 1개, 지저분한 버그 1개, 유지보수 작업 1개를 고르세요. 그리고 네 가지만 보시면 됩니다. 툴 호출 수, 사람 개입 시점, 최종 정합성, 머지까지 걸린 시간입니다.
특히 사람이 어디서 개입했는지가 중요합니다. 요구 재설명 때문인지, 잘못된 파일 편집 때문인지, 테스트 회귀 때문인지 구분해야 합니다. 그래야 이 모델이 일을 줄였는지, 아니면 검토 부담을 뒤로 미뤘는지 보입니다.
MiMo-V2.5-Pro의 또 다른 장점 후보는 토큰 효율입니다. Xiaomi는 ClawEval에서 비슷한 수준의 성능을 내면서 Claude Opus 4.6, Gemini 3.1 Pro, GPT-5.4보다 약 40~60% 적은 토큰을 썼다고 주장합니다.23 이 수치가 재현된다면 비용보다 더 중요한 효과는 세션 길이당 밀도입니다. 같은 예산으로 더 많은 실험을 돌릴 수 있기 때문입니다. 다만 이것도 자체 평가 성격이 강하므로, 실제 팀 환경에서 다시 확인해야 합니다.
마지막으로 가장 큰 트레이드오프가 남습니다. 자율성이 강한 모델은 프로세스가 약한 팀에서 "생산성 엔진"이 아니라 "리뷰 부채 생성기"가 될 수 있습니다. 테스트가 빈약하고, 샌드박스가 없고, 코드 리뷰 기준이 느슨하면, 더 오래 달리는 모델일수록 더 큰 덩어리의 불확실한 변경을 가져옵니다.
그래서 MiMo-V2.5-Pro는 모든 팀의 기본 선택지라기보다, 이미 테스트·리뷰·실행 하네스를 갖춘 팀에게 먼저 맞는 모델입니다. 그런 팀이라면 프로토타이핑, 대규모 유지보수, 복합 디버깅에서 꽤 현실적인 시간 절감을 볼 수 있습니다. 반대로 검증 체계가 약한 팀이라면, 이 모델이 줄여주는 건 타이핑 시간뿐이고 늘어나는 건 사후 점검 시간일 가능성이 큽니다.
참고
1XiaomiMiMo/MiMo-V2.5-Pro · Hugging Face
3Xiaomi's open-weight MiMo-V2.5-Pro takes aim at Claude Opus with hours-long autonomous coding
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.