Xiaomi의 「MiMo Code」 OSS 공개로 알게 된, AI 코딩의 주전장이 “모델”에서 “하네스”로 옮겨간 이야기

Xiaomi가 2026년 6월, 터미널 네이티브 AI 코딩 에이전트인 MiMo Code를 MIT 라이선스로 OSS(Open Source Software) 공개했다. 실체는 **OpenCode의 포크(Fork)**이며, 「모델」이 아니라 **하네스(Harness, 에이전트 기반)**라는 점이 중요하다. - 주목할 점은 성능 수치 그 자체보다, 같은 모델을 사용하더라도 하네스의 차이만으로 벤치마크가 약 5포인트 움직였다는 사실이다. 에이전트 개발의 경쟁 축이 「모델」에서 「하네스 설계」로 옮겨가고 있음을 보여준다. - MiMo Code의 설계 사상(영속 메모리 / 자기 유지보수 / 서브 에이전트 / 골 드라이븐 루프(Goal-driven loop))은, 일본 기업이 코드를 해외 API로 보내지 않고 셀프 호스팅(Self-hosting)으로 AI 코딩을 돌리기 위한 구체적인 설계도로 읽힐 수 있다. - 다만 벤치마크는 자기 신고(Self-reported) 방식이며 공식 리더보드에는 게재되지 않았다. 액면 그대로 믿기보다는 「아키텍처로부터 무엇을 배울 것인가」라는 관점에서 읽을 것을 권한다.

2026년에 들어서며 일본 엔지니어의 상당수가 Claude Code나 Gemini CLI, 각종 코딩 에이전트를 업무에 도입하기 시작했다. 반면 실무 현장에서는 여전히 다음의 세 가지 벽에 부딪히고 있다.

컨텍스트(Context)의 상실— 세션을 넘기면 「지난주에 결정한 설계 판단」을 잊어버림

데이터 주권— 자사의 기밀 코드를 해외 SaaS의 API로 보내도 되는지에 대한 법무·보안상의 우려

벤더 락인(Vendor Lock-in)— 폐쇄적인 에이전트에 업무 플로우를 장악당하는 불안함

그러던 중, Xiaomi가 2026년 6월에 OSS 공개한 MiMo Code는 이러한 세 가지 벽에 정면으로 대응하는 아키텍처를 가지고 있다. 게다가 「Claude Code를 200스텝 이상의 장시간 태스크에서 앞질렀다」라는 도발적인 주장까지 포함되어 있다.

여기서 많은 일본어 기사들은 「Xiaomi의 신모델 대단하다」로 끝을 맺는다. 하지만 본질은 그곳에 있지 않다. 본 기사는 **「하네스의 아키텍처」**에 초점을 맞추어, 일본 엔지니어가 자사의 AI 코딩 기반을 설계할 때 무엇을 가져올 수 있는지를 깊이 있게 파헤친다.

여러 1차 소스를 대조해 보면, 사실관계는 다음과 같다.

• MiMo Code(v0.1.0)는 OpenCode의 포크로서 구축되어 있다. OpenCode의 코어 기능(멀티 프로바이더 대응, TUI, LSP, MCP, 플러그인)을 그대로 계승하고, 그 위에 독자적인 레이어를 추가했다. - 라이선스는 MIT(단, USE_RESTRICTIONS.md에 이용 제한 있음). 가중치(Weights)를 포함한 모델 MiMo-V2.5-Pro도 별도로 Hugging Face에서 공개되어 있다. - 모델 MiMo-V2.5-Pro는 총 파라미터 1.02조 / 액티브(Active) 42억의 MoE(Mixture of Experts), 컨텍스트 길이 100만 토큰, FP8(E4M3) 혼합 정밀도를 지원한다. - 설치는 원라이너(One-liner)로 가능하다.

# macOS / Linux
curl -fsSL https://mimo.xiaomi.com/install | bash
# Windows / npm 경유
...

벤치마크에 대해서는 벤더(Xiaomi) 측이 다음 수치를 주장하고 있다.

벤치마크	MiMo Code	Claude Code
SWE-bench Verified	82%	79%
...

그리고 「200스텝 미만에서는 거의 대등하지만, 200스텝을 넘어가면 승률이 65% 이상으로 올라간다」라며 장시간 태스크에서의 우위를 주장하고 있다.

⚠️

중요한 주의 사항: 이것들은 자기 신고 값이며, 집필 시점에서 MiMo Code는 공식 리더보드에 게재되지 않았다. HackerNews의 댓글에서는 「무료 모델을 써봤지만 Sonnet 4.6에는 한참 못 미친다」, 「스레드의 댓글이 봇 같다(스텔스 마케팅 의혹)」라는 목소리도 있다. 수치는 액면 그대로 믿지 말고, 검증용 화제로 다루어야 한다.

그럼에도 불구하고 내가 흥미롭다고 생각하는 지점은 다음 한 가지다. 같은 MiMo-V2.5-Pro를 MiMo Code와 Claude Code 양쪽 하네스에서 구동했을 때도, SWE-bench Pro에서 62% vs 57%, Terminal-Bench 2에서 73% vs 68%와 같이 약 5포인트의 차이가 발생했다는 점이다. 이는 모델이 아니라 하네스(주변 장치/기반)에서 기인한 차이다.

이곳이 본 기사의 핵심이다. MiMo Code가 OpenCode에 추가한 독자적인 레이어는 크게 4가지로 분류할 수 있다. 이들은 모두 '컨텍스트 윈도우 (Context Window)에 대한 과도한 의존'이라는 현대 에이전트의 구조적 약점에 대한 처방전이 된다.

많은 코딩 에이전트들은 기억을 모델의 컨텍스트 윈도우에 통째로 맡기고 있다. 그래서 윈도우가 가득 차면 과거의 결정을 잊어버린다. MiMo Code는 기억을 컨텍스트 외부에 둔다.

SQLite FTS5를 통한 전문 검색(Full-text search) 기능이 포함된 크로스 세션 메모리 - 프로젝트 메모리 (MEMORY.md), 세션 체크포인트, 스크래치 노트, 태스크 진행 상황 - 컨텍스트 윈도우의 잔여량을 확인하여 자동으로 체크포인트를 저장

.mimocode/
├── mimocode.json # 설정 (프로바이더, MCP, LSP 등)
├── MEMORY.md # 프로젝트 장기 기억
...

설계의 핵심은 '기억 = 검색 가능한 외부 스토어'라는 사고방식이다. 이는 RAG (Retrieval-Augmented Generation)의 발상을 에이전트 자신의 작업 기억에 적용한 것으로, 직접 에이전트를 구축할 때도 모방할 수 있다.

/dream은 7일마다 자동으로 실행되어, 별도의 유지보수용 에이전트가 과거 세션과 메모리 파일을 리뷰한다. 중복을 제거하고, 파일 경로의 유효성을 검증하며, 장기 기억으로서 다시 압축한다. /distill은 워크플로우를 추출 및 자동화한다.

즉, 에이전트가 자신의 기억을 정기적으로 '청소'하는 것이다. 장기 운용 시 메모리가 오염되어 정밀도가 떨어지는 문제에 대한 운영 설계 측면의 해답이다.

primary 에이전트가 필요에 따라 서브 에이전트를 생성할 수 있으며, 라이프사이클 관리 · 취소 · 백그라운드 실행 기능을 갖추고 있다. 에이전트는 역할별로 나뉘어 있다.

build: 기본값. 풀 권한(Full permission)으로 구현한다. -
plan: 읽기 전용으로 분석한다 (파괴적인 조작을 하지 못하게 함). -
compose: 사양 주도 개발 (Specification-driven development) (Tab 키로 실행. 요구사항 → 설계 → 구현 → 테스트 → 리뷰를 일관되게 수행).

plan을 읽기 전용으로 고정하고 있는 점은, 후술할 일본 현장에서의 안전한 운용과 직결된다.

/goal로 세션의 정지 조건을 설정하면, 독립된 **저지 모델 (Judge Model)**이 대화를 평가하여 '목표 달성 여부'를 판정한다. 나아가 experimental.maxMode (병렬 best-of-N 추론 + 저지 선택)도 준비되어 있다.

'언제 멈출 것인가'를 별도의 모델이 판정하게 하는 구조는, 지난 기사에서 다루었던 '폭주하는 에이전트' 문제(자율 실행이 비용이나 사고를 유발하는 문제)에 대한 하네스(Harness) 측면에서의 제동 장치라고도 할 수 있다.

MiMo Code는 MIT 라이선스 + OpenAI 호환 API + 셀프 호스팅 가능이라는 조합을 갖추고 있다. 설정에서 프로바이더를 교체할 수 있다.

// .mimocode/mimocode.json (이미지)
{
"provider": {
...

금융, 공공, 제조 등 '소스 코드를 해외 SaaS로 보낼 수 없는' 업종에게 이는 매우 큰 장점이다. 하네스는 OSS로 자사 관리하고, 추론은 온프레미스(On-premise) / 국내 리전의 사내 모델로 향하게 하는 구성을 추가 개발 없이 취할 수 있다. 해외 프런티어 모델의 API에 의존하지 않는 선택지를 업무 흐름을 바꾸지 않고 가질 수 있는 것이다.

이번 5포인트 차이가 보여주는 교훈은 명확하다. 같은 모델이라도 하네스에 따라 성과가 달라진다. 일본 기업의 AI 도입은 '어떤 모델이 똑똑한가'에 치우치기 쉽지만, 실제 생산성은

• 메모리 관리 (세션을 넘나들며 설계 판단을 유지할 수 있는가)
• 컨텍스트 압축의 영리함
• 서브 에이전트의 권한 분리

와 같은 **주변 장치(Footwork)**에서 결정된다. MiMo Code의 아키텍처는 자사에서 하네스를 평가하고 내재화할 때의 체크리스트로 사용할 수 있다.

plan(읽기 전용)과 build(풀 권한)의 분리는 그대로 리뷰 운용에 전용할 수 있다. 예를 들어 '운영 환경에 가까운 리포지토리에서는 먼저 plan으로 조사 → 인간이 리뷰 → build로 구현'이라는 게이트를 설정하면, 자율 에이전트의 사고를 구조적으로 줄일 수 있다.

벤치마크는 자기 신고 사항이다. PoC(Proof of Concept)에서 자사 태스크의 실측치를 얻기 전까지는 성능을 믿지 않는다. -
MIT 라이선스이지만, 상용 이용 전에 반드시 제한 조항을 확인한다. USE_RESTRICTIONS.md가 존재한다. -
시용은 좋지만, 기밀 코드를 통과시킨다면 앞서 언급한 셀프 호스팅 구성으로 전환한다. MiMo Auto

（무료 프레임워크）는 중국 Xiaomi의 추론 기반을 경유 - 설치는
curl | bash

원라이너(One-liner)이므로, 사내 도입 시에는 스크립트 내용을 반드시 감사해야 한다.

MiMo Code 뉴스의 본질은 "Xiaomi가 빠른 모델을 내놓았다"가 아니라, AI 코딩의 경쟁 축이 모델에서 하네스(Harness, 에이전트 기반)로 옮겨갔다는 점의 가시화다. 내일부터 할 수 있는 일들을 나열한다.

하네스를 평가 축에 추가하기: 모델 비교표뿐만 아니라 「메모리 관리 · 컨텍스트 압축 · 권한 분리」를 평가 항목으로 삼는다. -
영속 메모리(Persistent Memory) 개념을 자체 에이전트에 이식: 컨텍스트 창(Context Window)에 의존하지 않고, 검색 가능한 외부 메모리(SQLite FTS5 또는 벡터 DB)로 작업 기억을 넘긴다. -
권한 분리를 워크플로우화: plan 단계에서 반드시 읽기 전용(Read-only) 페이즈를 거치게 하고, build 단계는 인간의 승인(Human Gate) 후에 진행한다. -
데이터 주권 구성 시도: OpenAI 호환 사내 추론 기반에 하네스를 연결하여, 코드를 외부로 유출하지 않는 PoC(Proof of Concept)를 하나 실행해 본다. -
벤치마크는 직접 측정하기: 공개된 수치가 아니라, 자사의 전형적인 태스크로 장시간(200 스텝급) 실측치를 측정한다.

"똑똑한 모델을 선택하는" 시대에서, "똑똑한 하부 구조(Chassis)를 설계하는" 시대로. MiMo Code는 그 OSS의 모범 사례로서, 설령 자사에서 채택하지 않더라도 **읽어볼 가치가 있는 레퍼런스 구현(Reference Implementation)**이다.

• MiMo Code 공식 GitHub (XiaomiMiMo/MiMo-Code)
• MiMo-V2.5-Pro 모델 페이지 (Hugging Face)
• VentureBeat 「Xiaomi's new open source, agentic AI coding harness MiMo Code beats Claude Code at ultra-long, 200+ step tasks」
• HackerNews 디스커션 (MiMo Code Is Now Released and Open-Source)
• The Decoder 「Xiaomi's open-weight MiMo-V2.5-Pro takes aim at Claude Opus with hours-long autonomous coding」
• Gizmochina 「Xiaomi announces new AI coding agent that actually remembers what it was doing」

본 기사는 벤더 공표치를 포함합니다. 벤치마크는 집필 시점 기준으로 자기 신고(Self-reported) 상태이며 공식 리더보드에 게재되지 않았으므로, 도입 판단은 반드시 자사 환경에서의 실측에 기반하여 결정하시기 바랍니다.