MiMoCode 소개
MiMoCode는 터미널에서 동작하는 AI 코딩 어시스턴트로, Xiaomi의 MiMo 팀이 공개한 오픈소스 프로젝트입니다. 코드를 읽고 쓰며 명령을 실행하고 Git을 관리하는 일반적인 코딩 에이전트 기능에 더해, 세션이 바뀌어도 프로젝트에 대한 이해를 유지하는 영속 메모리 시스템을 갖춘 것이 가장 큰 특징입니다. 한 번의 대화가 끝나면 맥락을 잊어버리는 기존 도구와 달리, MiMoCode는 프로젝트의 지식과 작업 진행 상태를 세션 너머로 이어갑니다.
MiMoCode는 OpenCode를 기반(fork)으로 만들어졌으며 MIT 라이선스로 공개되어 있습니다. OpenCode의 핵심 기능(여러 제공자 지원, TUI, LSP, MCP, 플러그인)을 그대로 유지하면서 영속 메모리, 지능형 컨텍스트 관리, 서브에이전트 오케스트레이션, 목표 기반 자율 루프, compose 워크플로, dream/distill 기반 자기 개선을 더했습니다. 프로젝트가 내세우는 핵심 화두는 긴 호흡의 작업(long-horizon task) 으로, 수십에서 수백 단계에 이르는 실행 과정에서 의사결정 품질과 상태 연속성을 어떻게 유지할 것인가에 초점을 맞춥니다. MiMo 팀은 이 문제를 계산(computation), 메모리(memory), 진화(evolution) 라는 세 가지 축으로 나누어 설계했습니다.
설치 후 첫 실행 시 별도 설정 없이 바로 쓸 수 있도록 MiMo Auto 라는 한시적 무료 채널이 내장되어 있습니다. MiMo Auto는 MiMo-V2.5 모델을 기반으로 하며 100만(1M) 토큰 컨텍스트를 지원합니다. 동시에 OpenAI 호환 API를 비롯한 주요 LLM 제공자 API에 연결할 수도 있어, 익명 채널로 가볍게 시작하거나 자신이 쓰던 모델 제공자를 그대로 붙이는 두 방식을 모두 지원합니다. Claude Code의 기존 인증을 한 단계로 가져오는 가져오기 옵션도 제공합니다.
MiMoCode는 단순히 명령을 수행하는 데 그치지 않고, 작업 과정에서 얻은 지식을 메모리로 정리하고 반복되는 작업을 재사용 가능한 형태로 추출하는 자기 개선 흐름을 갖추고 있습니다. 이런 설계 덕분에 긴 호흡의 작업에서 맥락 손실 없이 작업을 이어가는 데 초점을 맞춥니다.
MiMoCode의 세 가지 에이전트 모드
MiMoCode는 작업 성격에 따라 전환할 수 있는 세 가지 기본 에이전트를 제공하며, Tab 키로 전환합니다.
| 에이전트 | 설명 |
|---|---|
| build | 기본 모드. 개발을 위한 전체 도구 권한을 가집니다. |
| plan | 코드 탐색과 해법 설계를 위한 읽기 전용 분석 모드입니다. |
| compose | 명세 기반 개발과 스킬 기반 워크플로를 위한 오케스트레이션 모드입니다. |
특히 compose 모드는 명세에서 시작해 배포까지 이어지는 구조화된 워크플로를 제공합니다. 계획 수립, 실행, 코드 리뷰, TDD, 디버깅, 검증, 병합을 위한 내장 스킬을 갖춰 명세 기반 개발의 전체 수명 주기를 조율합니다. 기본 에이전트 외의 서브에이전트는 시스템이 필요에 따라 생성합니다.
계산: 단일 턴 추론에 연산을 더하기
작업이 수십에서 수백 단계로 길어지면 각 단계의 오류가 시간이 지날수록 누적되는데, 정작 긴 호흡의 실행 도중에는 외부에서 잘못을 바로잡아 줄 신호가 부족합니다. MiMoCode는 이 문제에 여러 단위로 추가 연산을 투입해 대응합니다. 단일 스텝의 의사결정 오류 확률을 낮추고, 작업 수준에서 너무 일찍 멈추거나 방향이 어긋나는 것을 막으며, 실행 수준에서 불필요한 왕복을 줄입니다.
Max Mode: 병렬 샘플링과 선택
Max Mode는 매 턴마다 N개의 후보 해법을 병렬로 생성합니다(기본값 N=5). 각 후보는 추론과 도구 호출 계획을 독립적으로 완성하되 실제로 실행하지는 않으며, 이후 같은 모델을 심판(judge)으로 삼아 모든 후보의 추론 과정과 행동 계획을 비교해 가장 나은 하나를 골라 실행합니다. 기본 temperature가 1이라 다섯 개의 표본이 동일하게 나오는 경우는 거의 없는데, 여러 후보가 수렴하면 그 방향에 대한 확신이 높다는 뜻이고, 후보들이 크게 갈리면 낮은 temperature의 심판이 가장 견고한 계획을 고르는 편이 단일 표본에 의존하는 것보다 안정적입니다. SWE-bench Pro 기준으로 Max Mode는 단일 샘플링 대비 성능을 10~20% 끌어올리지만, 그 대가로 토큰 소비가 약 4~5배 늘어납니다. Max Mode는 아직 실험적 기능이라 설정에서 수동으로 켜야 합니다.
Goal: 독립적인 완료 검증
Max Mode가 "제대로 하는 것" 을 다룬다면, Goal은 "끝까지 해내는 것" 을 다룹니다. 긴 작업에서 흔한 실패 양상은, 에이전트가 뒤쪽 턴에서 이전 진행 상황을 보고 "다 됐다" 고 성급히 선언하거나 질문을 던지며 멈춰 버리는 것입니다. 사람이 곁에서 교정해 줄 수 없는 자동 실행 환경에서는 특히 위험합니다.
Goal은 다음과 같이 동작합니다. 사용자가 "모든 테스트를 통과하고 코드가 커밋된 상태" 같은 자연어 종료 조건을 정의하면, 에이전트가 작업을 멈추려 할 때마다 시스템이 독립적인 모델 호출을 띄워 전체 대화 기록을 검토하고 조건이 실제로 충족되었는지 판단합니다. 충족되지 않았다면 구체적으로 부족한 부분을 에이전트에게 되돌려 작업을 이어가게 하고, 달성이 불가능하다고 확인되면 불가능으로 표시합니다. 이 검증자는 실제 작업에 참여하지 않으므로 에이전트가 이미 완료한 부분에 편향이 생기지 않고, 매번 에이전트와 똑같은 컨텍스트(실제 도구 출력 포함)를 받습니다. 실제로는 조건이 이미 충족됐는데 검증자가 아니라고 판단하는 "거짓 차단" 이 그 반대보다 흔하며(주로 환경 문제로 테스트가 실패할 때 발생), 무한 루프에 빠질 확률은 0.5% 미만이고 한계에 도달하면 자동으로 종료합니다.
Max Mode와 Goal은 테스트 타임 연산(test-time compute)의 서로 직교하는 두 방향입니다. Max Mode는 같은 스텝에 N배의 연산을 들여 최선을 고르는 병렬 방식이고, Goal은 같은 작업 안에서 자기 점검과 실행 지속에 더 많은 시간을 들이는 직렬 방식이며, 둘은 동시에 켤 수 있습니다.
Dynamic Workflow: 대규모 병렬 오케스트레이션
프로젝트 전체를 다른 프로그래밍 언어로 이전하는 작업처럼 규모가 커져 수십에서 수백 개의 병렬 작업 단위를 동시에 조율해야 하면, 라운드 단위의 도구 호출만으로는 부족해집니다. 전통적으로는 절차를 SKILL.md 에 자연어로 적어 모델에게 시키지만, 자연어는 모호하고 잊히기 쉬우며 검증할 수 없어 복잡한 워크플로에서는 단계가 누락되거나 분기 처리가 모델 판단에 좌우되는 등 체계적으로 실패합니다.
Dynamic Workflow는 오케스트레이션 로직을 프롬프트에서 코드로 옮깁니다. 메인 에이전트가 JavaScript 스크립트를 생성하면 격리된 샌드박스 안에서 결정론적으로 실행되며, 스크립트는 agent() 로 서브에이전트를 분배하고 parallel() / pipeline() 으로 동시성을 제어합니다. if 문은 분기를 잊지 않고 for 루프는 일찍 빠져나가지 않으므로, 모델의 판단은 코드 생성처럼 정말 필요한 곳에만 쓰입니다. MiMoCode의 구현은 Anthropic의 Dynamic Workflow 핵심 의미론과 호환되며, 스크립트가 다른 스크립트를 호출하는 workflow() 프리미티브, 각 agent() 결과를 디스크에 동기 기록해 중단 후 로그에서 복구하는 기능 등을 더했습니다.
MiMoCode의 영속 메모리와 컨텍스트 재구성
MiMoCode의 영속 메모리는 SQLite FTS5 전문 검색을 기반으로 하며, 역할이 다른 네 종류의 저장소로 구성됩니다. 프로젝트의 지식과 규칙, 아키텍처 결정을 담는 프로젝트 메모리 (MEMORY.md), checkpoint-writer 서브에이전트가 자동으로 유지하는 구조화된 상태 스냅샷인 세션 체크포인트(checkpoint.md), 에이전트의 임시 메모 공간인 스크래치 노트(notes.md), 그리고 작업별 로그를 남기는 작업 진행 기록(tasks/<id>/progress.md)입니다. 세션을 다시 시작하면 이 메모리가 자동으로 주입되어, 에이전트가 프로젝트 맥락을 처음부터 다시 배우지 않아도 됩니다.
사이클: 무한 세션의 기본 단위
단일 턴 연산을 키우면 각 스텝의 오류율은 낮출 수 있지만, 다중 턴 작업의 핵심 문제인 "컨텍스트는 결국 바닥난다" 는 점은 풀리지 않습니다. MiMoCode는 물리적 컨텍스트 창은 유한하게 유지하면서 논리적 세션은 무한히 늘어나게 하는 방식으로 이를 해결합니다. 한계에 닿기 전, 런타임은 정해진 위치(체크포인트)마다 독립적인 writer 서브에이전트를 띄워 지금까지의 대화를 읽고 구조화된 상태 파일을 디스크에 기록합니다. 메인 에이전트는 그동안 작업을 계속하고, writer는 별도로 동시에 돕니다. 창이 실제 한계에 가까워지면 런타임은 재구성(rebuild)을 수행해 현재 창을 끊고 새 창을 연 뒤, 디스크에 보존된 파일을 씨앗 삼아 컨텍스트를 다시 세웁니다. 모델 입장에서는 대화가 한 번도 끊긴 적 없는 것처럼 보입니다. 체크포인트를 거쳐 재구성으로 마무리되는 이 한 묶음을 사이클(cycle) 이라 부르며, 사이클 수에는 상한이 없습니다.
흥미롭게도 체크포인트는 창이 거의 찰 때까지 미루지 않고, 설정된 예산의 약 20%, 45%, 70% 지점처럼 한계보다 훨씬 일찍 발동합니다. 컨텍스트 사용률이 높아지면 모델 능력이 떨어지는 "lost in the middle" 현상 때문에 구조화된 추출의 신뢰도가 급격히 낮아지고, 추출 작업 자체도 같은 창 안에서 공간을 필요로 하기 때문입니다. 사용률 95%에서는 생각할 여유가 없지만 30%에서는 충분합니다. 각 발동은 이전 체크포인트에 대한 증분 업데이트이며, 마지막 재구성은 그렇게 쌓아 둔 구조화된 기록을 작업 컨텍스트로 되살리는 순간일 뿐 급한 압축이 아닙니다.
Writer 서브에이전트와 계층형 메모리
가장 자연스러운 발상은 메인 에이전트가 스스로 메모를 유지하게 하는 것이지만, 까다로운 문제를 디버깅 중인 모델에게 구조화된 로그까지 맡기면 두 가지를 모두 더 못하게 됩니다. 그래서 MiMoCode는 메인 에이전트가 자신의 메모리를 직접 유지하지 않는다 는 원칙을 둡니다. 추출은 메인 루프 밖으로 완전히 빼내, 런타임이 발동하고 메인 에이전트의 주의나 토큰 예산을 공유하지 않는 독립적인 writer 서브에이전트가 수행합니다. writer는 11개 필드(현재 의도, 다음 행동, 작업 제약, 작업 트리, 현재 작업, 관련 파일, 작업 간 발견, 오류와 수정, 런타임 상태, 설계 결정, 기타 메모)로 구성된 체크포인트 파일을 고정된 구조로 기록합니다. 각 구조화 파일은 단 하나의 주체만 쓸 수 있는데(single-writer), 이는 동시 쓰기로 인한 상태 불일치를 막는 가장 단순한 불변식입니다. 메인 에이전트는 구조화 파일에 읽기 전용으로 접근하고, 유일한 예외인 notes.md(자유 형식 스크래치패드)에만 자신의 발견을 덧붙일 수 있습니다. 이 노트는 각 체크포인트에서 writer가 읽어 적절한 구조화 필드로 분류한 뒤 비웁니다.
메모리는 수명이 다른 계층으로 나뉩니다.
- 세션 메모리(
checkpoint.md)는 현재 논리적 세션 안에서만 살아 있습니다. - 프로젝트 메모리(
MEMORY.md)는 아키텍처 결정과 사용자 규칙, 반복 검증된 기술 사실 등 세션을 넘어 지속됩니다. 여러 세션 체크포인트에서 어떤 관찰이 안정적으로 반복되면 writer가 이를 세션 계층에서 프로젝트 계층으로 승격시킵니다. - 전역 메모리는 프로젝트를 가로질러 적용되는 사용자 선호를 담습니다.
- 히스토리(History)는 모든 메시지와 도구 호출의 원문을 색인 없이 보존하는 SQLite 트레이스로, 구조화 메모리에서 찾지 못한 세부는 에이전트가 history 도구로 원본까지 거슬러 추적합니다.
위 계층일수록 더 정제되고 지속적이며 작고, 아래 계층일수록 더 완전하고 크며 느립니다. writer가 위로 정제하고, 히스토리는 아래에서 최후의 조회처가 됩니다.
재구성 시점에는 보존된 파일들을 계층화된 프롬프트로 조립해 새 창에 주입합니다. 대략 작업 목록, 세션 체크포인트, 최근 사용자 메시지의 원문 일부, 프로젝트 메모리, 전역 메모리, 노트, 필요 시 읽을 메모리 파일 경로 색인 순서이며, 각 구획에 독립적인 토큰 한도를 둡니다. 모든 구획이 한도를 채워도 주입되는 총량은 대략 65K 토큰 이내로 유지되어, 에이전트는 목표를 다시 확인하거나 이미 처리한 파일을 다시 읽을 필요 없이 곧바로 작업을 이어갑니다. 작업은 T1, T1.1, T1.2 같은 트리 형태의 작업 체계로 추적되며, 체크포인트 시스템과 연동되어 세션이 재개되어도 진행 상태가 보존됩니다.
MiMoCode의 진화: 경험에서 배우는 자기 개선
같은 프로젝트를 수십, 수백 번 다루다 보면 세션이 끝날 때마다 경험이 사라져 매번 같은 제약을 다시 발견하고 같은 실수를 반복하게 됩니다. MiMoCode는 두 가지 자동 정리 루틴으로 경험을 축적합니다.
/dream 은 7일마다 자동으로 발동해, 독립적인 에이전트가 과거 세션 대화와 기존 메모리 파일을 읽고 병합, 중복 제거, 경로 유효성 검증, 압축을 수행해 흩어진 기억을 현재 상태의 간결한 표현으로 수렴시키고 전역 메모리를 갱신합니다. /distill 은 30일마다 자동으로 발동하며, 마찬가지로 독립 에이전트가 과거 세션을 읽되 초점은 지식이 아니라 과정 입니다. 반복되는 작업 패턴을 찾아 재사용 가능한 스킬, CLI 명령, 사용자 정의 에이전트, SOP 문서 같은 산출물로 굳힙니다. 프로젝트 메모리를 순수 벡터 DB가 아닌 파일로 둔 핵심 이유는 검토 가능성(reviewability)입니다. 메모리가 에이전트 행동에 영향을 주기 시작하면 사용자가 무엇을 기억했는지 보고, 틀린 항목을 지우고, 오래된 지식을 고칠 수 있어야 하기 때문입니다.
이 밖에도 기본 에이전트는 필요에 따라 서브에이전트를 만들어 현재 세션 컨텍스트를 공유하며 병렬로 작업하게 하고(수명 추적, 취소, 백그라운드 실행 지원), TenVAD와 MiMo ASR 기반의 실시간 스트리밍 음성 입력(/voice)도 지원합니다.
MiMoCode의 성능 평가
오프라인 벤치마크에서 MiMo Code와 MiMo-V2.5-Pro 조합은 SWE-bench Verified(82%), SWE-bench Pro(62%), Terminal Bench 2(73%) 세 평가 모두에서 Claude Code와 Claude Sonnet 4.6 조합(각각 79%, 55%, 69%)을 앞섭니다. 주목할 점은 같은 MiMo-V2.5-Pro 모델을 쓰더라도 MiMo Code 하네스가 Claude Code 하네스(76%, 57%, 68%)보다 높은 점수를 낸다는 것으로, 모델뿐 아니라 하네스 설계 자체가 결과에 기여함을 보여줍니다. 다만 이들 벤치마크는 여전히 개별 저장소 단위 이슈를 한 번에 푸는 능력을 측정할 뿐이고, 다중 턴 메모리나 백그라운드 상태 유지, 완료 검증, 세션 간 진화 같은 MiMoCode의 설계 목표는 수십 턴 이어지는 실제 개발에서야 그 가치가 드러납니다.
이 한계를 보완하기 위해 MiMo 팀은 사람이 참여하는 이중 맹검 A/B 평가를 진행했습니다. 개발자 본인의 실제 프로젝트에서 익명의 두 코딩 에이전트를 같은 작업에 병렬로 띄우고, 독립적으로 작업을 마친 뒤 개발자가 점수를 매기는 방식입니다. 사내 베타 기간 동안 576명의 개발자와 474개의 실제 비공개 저장소를 대상으로 승패가 명확한 1,213건의 A/B 쌍을 수집했고, 같은 목표 모델 아래에서 MiMo Code와 Claude Code의 종단 간 개발 경험을 비교했습니다. 그 결과 작업이 복잡해질수록 MiMo Code의 우위가 커졌습니다. 실행 스텝이 200 이내일 때는 두 시스템의 승률이 50% 안팎으로 비슷했지만, 스텝이 200을 넘으면(다중 턴 사용자 상호작용 포함) MiMo Code의 승률이 65% 이상으로 올라갔습니다.
MiMoCode 설치 및 사용법
설치는 한 줄 스크립트 또는 npm으로 진행합니다.
# 한 줄 설치
curl -fsSL https://mimo.xiaomi.com/install | bash
# 또는 npm으로 설치
npm install -g @mimo-ai/cli
첫 실행 시 설정이 자동으로 안내되며, MiMo Auto(한시적 무료, MiMo-V2.5 기반 100만 토큰 컨텍스트), Xiaomi MiMo 플랫폼(OAuth 로그인), Claude Code에서 가져오기, 사용자 정의 제공자(OpenAI 호환 API 추가) 중에서 고를 수 있습니다. 설정은 프로젝트 디렉토리의 .mimocode/mimocode.json(또는 전역 ~/.config/mimocode/mimocode.json)으로 관리하며, 제공자와 모델 선택, 에이전트 권한, 체크포인트와 메모리 동작, MCP 서버 연결, 키바인딩과 테마 등을 설정합니다. 판정 모델을 활용한 병렬 best-of-N 추론인 Max Mode는 설정의 experimental.maxMode 로 켤 수 있습니다.
소스에서 실행하려면 Bun을 사용합니다.
bun install # 의존성 설치
bun run dev # 개발 모드 실행
bun turbo typecheck # 타입 검사
MiMoCode의 라이선스
MiMoCode의 소스 코드는 MIT 라이선스로 공개되어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다. 다만 사용에는 별도의 사용 제한(Use Restrictions)이 함께 적용되며, Xiaomi MiMo 호스팅 서비스 이용은 MiMo 서비스 약관을 따릅니다.
MiMoCode 공식 홈페이지
https://mimo.xiaomi.com/mimocode
MiMoCode 소개 블로그
https://mimo.xiaomi.com/blog/mimo-code-long-horizon
MiMoCode 프로젝트 GitHub 저장소
더 읽어보기
이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다. 
파이토치 한국 사용자 모임
이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일
로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다. 
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 