# MAI-Code-1-Flash

> Clean Markdown view of GeekNews topic #30137. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30137](https://news.hada.io/topic?id=30137)
- GeekNews Markdown: [https://news.hada.io/topic/30137.md](https://news.hada.io/topic/30137.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-03T11:35:26+09:00
- Updated: 2026-06-03T11:35:26+09:00
- Original source: [microsoft.ai](https://microsoft.ai/news/introducingmai-code-1-flash/)
- Points: 2
- Comments: 1

## Topic Body

- **MAI-Code-1-Flash**는 일상 개발자 워크플로우에서 빠르고 효율적인 코딩 지원을 목표로 한 Microsoft의 새 코딩 모델이며, VS Code의 GitHub Copilot 개인 사용자에게 배포 중임
- Microsoft는 이 모델을 **GitHub Copilot 하네스**에서 직접 학습시켜 실제 개발 환경의 도구·시스템과 더 잘 상호작용하도록 설계함
- **적응형 응답 길이 제어**로 단순 요청에는 간결하게 답하고 복잡한 작업에는 더 많은 추론 예산을 쓰며, 최대 60% 적은 토큰으로 더 어려운 문제를 해결함 {p:60}
- Microsoft의 생산 하네스 평가에서 **Claude Haiku 4.5**보다 4개 핵심 코딩 벤치마크 모두에서 높은 통과율을 보였고, SWE-Bench Pro에서는 51.2% 대 35.2%로 16포인트 앞섬
- 별도 적대적 추론 벤치마크에서는 186문항·34개 범주에서 **85.8% 조정 정확도**를 기록했지만, Einstellung trap 같은 핵심 적대 범주는 50% 미만 정확도에 머물러 개선 여지가 있음

---

### 출시와 배포
- MAI-Code-1-Flash는 빠르고 효율적인 일상 개발자 지원을 위해 만든 Microsoft의 새 코딩 모델임
- Microsoft가 처음부터 끝까지 구축했으며, 깨끗하고 적절히 라이선스된 데이터를 사용함
- GitHub Copilot 개인 사용자의 [VS Code](https://code.visualstudio.com/download)에 배포 중이며, 모델 선택기와 기본 Auto picker 아래에서 사용할 수 있음
- 추가 설정은 필요 없고, 배포가 진행되면 GitHub Copilot이 Auto picker를 통해 작업을 MAI-Code-1-Flash로 라우팅하거나 모델 선택기에 직접 표시함
- 피드백은 [GitHub Community](https://github.com/orgs/community/discussions/197306)에서 받을 예정임

### 개발자 워크플로우 중심 설계
- MAI-Code-1-Flash는 벤치마크 최적화만이 아니라 개발자가 매일 쓰는 생산 워크플로우를 중심에 두고 만들었음
- 생산 환경에서 쓰이는 GitHub Copilot 하네스(harness)로 직접 학습해 에이전트형 코딩 작업에서 주변 도구와 시스템을 다루는 방식을 익히도록 설계함
- 학습 중에는 핵심 소프트웨어 엔지니어링 작업, 저장소 질의응답, 리팩터링, 실제 GitHub Copilot 사용에서 각색한 텔레메트리 기반 작업으로 체크포인트를 평가함
- 학습·평가·생산 환경을 맞추면 오프라인 개선이 실제 개발자 품질로 이어지도록 돕는다는 설계 목표를 가짐

### 토큰 효율과 응답 방식
- 적응형 솔루션 길이 제어를 학습해 작업 난도에 따라 응답 깊이를 조절함
- 단순 요청에는 간결하게 답하고, 더 깊은 분석이나 더 넓은 코드 변경이 필요한 문제에는 더 많은 추론 예산을 사용함
- 개발자는 유용한 출력을 더 빨리 보기 시작할 수 있음
- MAI-Code-1-Flash는 최대 60% 적은 토큰으로 더 어려운 문제를 해결하며, 지연 시간 감소, 비용 절감, 토큰 대비 수익 개선, 더 부드러운 대화형 워크플로우를 목표로 함

### 코딩 벤치마크 결과
- Microsoft는 SWE-Bench Verified, SWE-Bench Pro, SWE-Bench Multilingual, Terminal Bench 2에서 MAI-Code-1-Flash와 Claude Haiku 4.5를 같은 생산 하네스로 평가함
- 평가는 작업 성공률과 각 작업 완료에 필요한 평균 솔루션 토큰 수를 측정함
- MAI-Code-1-Flash는 테스트한 4개 핵심 코딩 벤치마크 모두에서 Claude Haiku 4.5보다 높은 통과율을 기록함
- SWE-Bench Pro의 다양한 실제 작업에서는 51.2% 대 35.2%로 16포인트 앞섬
- SWE-Bench Verified에서는 최대 60% 적은 토큰으로 더 어려운 문제를 해결해 정확도와 효율이 동시에 개선될 수 있음을 보임

### 지시 따르기·추론·한계
- MAI-Code-1-Flash는 표에 나온 모든 벤치마크에서 Claude Haiku 4.5보다 앞섰으며, IF Bench의 정밀 지시 따르기에서는 +28.9로 가장 큰 격차를 보임
- Advanced IF의 루브릭 기반 평가에서는 +14.5로 가장 좁은 격차를 보임
- 강한 지시 따르기 성능은 에이전트형 도구 사용으로도 이어짐
- 수학, 과학, 시각 생성 코딩의 핵심 추론 능력에서도 Claude Haiku 4.5를 앞섬
- 표준 벤치마크는 추론만큼 암기도 보상할 수 있어, Monty Hall 문제를 본 모델은 정답을 맞히지만 상품을 뒤집으면 실패할 수 있음
- Microsoft는 inverted classics, impossible tasks, underdetermined scenarios 같은 적대적 함정을 중심으로 186문항·34개 범주의 벤치마크를 만들었음
- MAI-Code-1-Flash는 이 적대적 벤치마크에서 Claude Haiku 4.5를 전체적으로 넘었고 85.8% 조정 정확도에 도달함
- 추론, 지시 따르기, 불가능한 문제 인식에서 특히 강한 성능을 보였지만, Einstellung trap 같은 핵심 적대 범주는 50% 미만 정확도에 머물러 개선 여지가 남아 있음

## Comments



### Comment 58862

- Author: neo
- Created: 2026-06-03T11:35:27+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48374466) 
- 모델 카드에 따르면 이건 총 **137B 파라미터** 모델임  
  성능은 그렇게 좋아 보이지 않음: MAI-Code-1-Flash (137B-A5B)는 SWE-bench pro 51%, Qwen3.6-35B-A3B는 SWE-bench pro 49.5%([https://huggingface.co/Qwen/Qwen3.6-35B-A3B](<https://huggingface.co/Qwen/Qwen3.6-35B-A3B>))  
  Claude Haiku와 비교하지만 Haiku는 좋은 모델이 아니고, 로컬이나 API로 비용 10% 수준에 돌릴 수 있는 작은 오픈 모델보다도 못함
  - 핵심은 이 모델이 **Haiku와 경쟁하는 작은 모델**이라는 것 같고, 다음에는 "Sonnet"급, 그다음에는 Opus급 경쟁 모델이 나오길 기대함  
    Microsoft가 왜 Copilot에서 자기들이 만든 모델 제공을 이렇게 미루는지 궁금했는데, OpenAI와의 계약 일부였을 수도 있겠다는 생각이 듦
  - **137B-A5B**라면, 앞선 제목이 암시하던 5B 파라미터 모델은 아님

- 시작으로는 좋고 경쟁은 환영하지만, Haiku 4.5 같은 **작은 클라우드 모델**을 코딩에 써본 적은 거의 없음  
  귀엽긴 해도 진지한 코딩에서는 비싼 내 시간을 낭비하는 경우가 많고, 어제 해지한 GitHub Copilot로 돌아가게 만들 정도도 아님  
  GitHub Copilot은 어제까지는 가격 경쟁력이 있었지만, 요청당 과금에서 가장 비싼 축의 토큰당 할당량 방식으로 바뀌었음. 웃고 싶으면 불타는 서브레딧을 보면 됨: [https://www.reddit.com/r/GithubCopilot](<https://www.reddit.com/r/GithubCopilot>)  
  이후 거의 무료에 Sonnet+급인 DeepSeek Flash high로 바꿨고, 더 똑똑한 모델이 필요하면 월 $20 Codex에 가입해 지금 접근 가능한 최고라고 보는 GPT 5.5를 쓸 듯함
  - 큰 모델로 작업을 **위상 정렬된 작업 그래프**로 조직하고, 복잡도에 따라 작은 모델을 각 작업에 붙인 뒤, 큰 모델이 평가하고 필요한 곳을 패치하게 함  
    이 방식에서는 일상적인 작업에 Haiku를 꽤 자주 쓰며, 여러 시간 걸리는 고복잡도 작업도 더 좋은 결과와 훨씬 낮은 비용으로 처리 가능함. 부모 오케스트레이터가 작업을 효과적으로 정리하고 품질을 검토하며 필요한 곳에서 통합해, 단일 컨텍스트 창 안에서 거대한 노동을 수행함  
    Haiku를 직접 쓰지는 않지만 큰 작업의 토큰 사용량 중 30~40%를 차지하는 경우가 많음. 완료 시간과 비용 모두 개선되고, Haiku는 문자 그대로의 지시와 계획을 “재해석”하지 않고 따르는 데 더 나은 반면 Opus급 모델은 사고 과정에서 계속 의심하고 되묻는 편임  
    그래서 Haiku는 시간 낭비가 아니라 엄청난 시간을 아껴줌. 다만 여기까지 오기 위해 오케스트레이션 시스템을 먼저 만들고 계속 반복 개선하는 데 많은 시간을 썼음. 흥미롭게도 디렉터와 이후 distinguished engineer로 일한 경험이 이걸 끝까지 안정적으로 굴릴 도구를 줬고, 다양한 능력의 다중 에이전트 흐름은 1000명 엔지니어 조직의 역학과 크게 다르지 않음
  - 어려운 보안 버그를 찾는 용도로 여러 모델을 벤치마크해 보니, 그 과정에서 **Haiku와 Sonnet에 대한 신뢰**가 급격히 떨어졌음  
    자체 호스팅한 Qwen 3.6 27B가 보안 버그 탐지에서 둘을 일관되게 앞섰고, 이는 꽤 충격적인 결과였음. Qwen은 Haiku 수준이거나 조금 못할 줄 알았고, Sonnet보다는 확실히 못할 거라고 봤음  
    DeepSeek와 MiMo는 Haiku와 Sonnet보다 훨씬 잘하고, 비용은 일부에 불과한데 Opus/GPT 5.5 수준에 가까움  
    무료로 받거나 보통 다 쓰지도 못하는 구독에 포함된 게 아니라면, Haiku나 Sonnet을 쓸 이유가 거의 없어 보임
  - 거의 같은 상황임. DeepSeek는 거절도 거의 없었고, 중국식 가치관 덕분에 **리버스 엔지니어링**, 저작권 파일 찾기, 출처가 의심스러운 소스 코드 작업 같은 것에서 마찰이 훨씬 적었음  
    Copilot 가격을 90% 낮춰도 돌아가지 않을 것 같음
  - 이건 Qwen 3.6, Gemma 4, Nemotron 3 Super 같은 범위로 보임  
    Haiku와 비슷하게 경쟁력 있는 모델은 많고, Qwen 3.6 35B-A3B처럼 훨씬 작고 싼 것도 있음. 이런 건 노트북에서 돌릴 수 있으니 Microsoft에서 빌릴 필요가 없음  
    새 Copilot 청구서에 당황했지만 생태계에 남고 싶은 사람에게는 쓸 선택지가 되겠지만, 대부분에게는 더 나은 선택지가 넘침
  - 월 $20짜리 **ChatGPT 플랜**에 Codex가 포함되는 건 가성비가 좋음  
    프리미엄 ChatGPT만 있어도 괜찮고, 정기적으로 사용량 제한에 걸리긴 해도 대부분의 일은 할 수 있음

- 실제로 이런 **작은 모델을 코딩**에 쓰는 사람이 있나? 있다면 어떻게 쓰는지 궁금함  
  보통은 전부 Opus로 처리함. 더 무거운 모델로 계획/설계/아키텍처를 잡고 구조화된 작업을 이런 작은 모델에 위임하는 방식인지, 양쪽을 다 해보고 테스트한 사람의 생각을 듣고 싶음
  - 직장에서는 Opus 4.x를 쓰고, 집에서는 이런 “작은” 모델들(20~80B, 활성 3~4B)을 씀  
    아쉽지만 아직은 비교가 안 됨  
    Opus로는 복잡한 코드베이스에서도 설계, 아키텍처 제안, 코드 변경을 믿고 작업할 수 있음  
    작은 모델들은 “시도”는 하는 느낌임. 작은 작업에는 되지만, 복잡한 작업에서는 직접 하는 것보다 일이 더 많아지는 경우가 흔함  
    달랐으면 좋겠고, 1~2년 뒤에는 달라질 수도 있음
  - 더 무거운 모델로 계획/설계/아키텍처를 하고 구조화된 작업을 작은 모델에 맡기는 건 **항상 그런 방식**이었음  
    claude code에는 opusplan이 있고, 계획 모드에서는 Opus를 쓰다가 실행은 Sonnet으로 전환함  
    [https://code.claude.com/docs/en/model-config#opusplan-model-...](<https://code.claude.com/docs/en/model-config#opusplan-model-setting>)  
    수정: 계획은 Sonnet, 실행은 Haiku로 하거나 원하는 다른 조합으로도 구성 가능함  
    [https://code.claude.com/docs/en/model-config#control-the-mod...](<https://code.claude.com/docs/en/model-config#control-the-model-users-run-on>)
  - Haiku는 꽤 싸면서도 크게 망치지 않아서, 예전 Copilot 플랜에서 기존 프로젝트의 **대화형 코딩**에 썼음  
    간단한 기능은 완전한 계획을 세우지 않음. 코드를 조금 쓰고 짧은 프롬프트 한 줄로 모델에게 해야 할 일을 말함. 가끔 임시 주석을 코드에 넣어 방향을 줌  
    보통 코드 변경이 파일이나 패키지 안에 머무르면 Haiku도 요청을 따라가고 너무 망치지 않을 만큼은 충분함. 시간이 지나며 방향을 주는 스킬도 만들어뒀음. GitHub Copilot을 쓰던 몇 달 동안 월말에 남은 크레딧을 허겁지겁 쓰려고 한 적도 있음  
    AI 코드 완성만으로도 꽤 괜찮을 때가 있음. 코드가 해야 할 일을 임시 주석으로 적고 Tab-Tab-Tab만 누르면 함수 전체가 완성되기도 함  
    고급 모델이 덜 망칠 거라 생각해 사람들이 그쪽으로 가는 경향이 있지만, 코드를 정말 이해하고 있다면 낮은 모델로 대화형으로 작업하는 편이 더 쉬움
  - 변경 작업의 실행을 별도 책임으로 나눔  
    메인 채팅을 “오케스트레이터”인 Opus로 지정하고, 목표를 정한 뒤 다음 하위 에이전트를 순서대로 써서 도달할 때까지 밀어붙이게 함  
    1. 단계 실행(Sonnet): 오케스트레이터 지시에 따라 30분/100k 토큰 동안 작업  
    2. 검토(Opus): 이전 단계의 작업에서 오류와 지시 충실도를 면밀히 확인하고, 고친 뒤 오류와 토큰 사용을 줄이기 위한 에이전트 설정+도구 개선 기회를 파일에 기록  
    3. 자기 개선(Opus): 사용자 개입이 필요 없는 것 중 영향이 큰 자기 개선 항목을 구현  
    반복: 오케스트레이터 세션 토큰 예산이 소진될 때까지 진행함. 1M 같은 값으로 설정하면 됨  
    기본 논리는 각 단계를 관리 가능한 크기로 유지해 지시 준수율을 높이고 비용을 낮추는 것임. 캐시된 토큰도 비용이 들기 때문임. 프롬프트 토큰은 생성 토큰보다 훨씬 싸므로, Opus가 주도하기보다 주로 검토하게 만들수록 비용도 많이 절약됨  
    자기 개선 단계는 매우 비싸지만 개선이 누적됨. 며칠이나 몇 주짜리 작업을 돌릴 거라면 안 하는 쪽이 훨씬 비쌈  
    수정: Claude Code에서 Anthropic 모델로도 하고, 오프라인 사용에는 Qwen 계열 모델로도 함
  - Claude Code 자체도 많은 하위 에이전트를 Haiku로 띄움  
    이 모델은 **환각률이 낮아서** 탐색 작업에 좋고, 여기서 나온 모델도 가장 좋은 용도는 비슷할 것 같음. 많은 작업이 계획이나 수정 전에 여러 탐색 에이전트를 띄우고, 이후에는 도구 호출 몇 번으로 끝나기 때문에 토큰 사용량도 큼

- 이 모델을 **Haiku 4.5**와 비교하고 있음  
  Opus도 Sonnet도 아니고, Anthropic의 가장 작은 모델인 Haiku, 그것도 3버전 전 모델과 비교하는 셈임
  - 4.5가 아직 최신 Haiku 모델임

- 왜 다들 창 스크롤을 이렇게 엉망으로 재구현하는 걸까?
  - 아마 바이브 코딩으로 만든 듯함. 나는 StopTheMadness로 막아둠
  - 바로 눈에 띄어서 곧장 닫아버렸음

- 벤치마크는 여전히 이렇게 낮은데 모델은 혁명적인 것처럼 마케팅되는 게 너무 이상함  
  코딩 능력이 낮아도 문제가 아니라고 한다면, 토큰 가격 인상과 “범용” 모델 설정을 같이 봐야 함  
  왜 수학 에이전트로 팔지 않는 걸까? 왜 서로의 작업을 확인할 **에이전트 4개**를 내가 설정해야 하나?
  - 이해하기로는, 다른 모델들과 달리 **MAI 모델**은 벤치마크 점수를 끌어올리도록 특별히 설계된 합성 데이터셋으로 아직 미세조정하지 않았기 때문임
  - 핵심은 **가격 대비 성능**임  
    5B 파라미터로 그 정도 점수라면 꽤 좋고, 얼마 전까지만 해도 거의 믿기 어려운 수준이었음  
    작은 모델은 점점 더 좋아질 것이고, 클라우드 최첨단 모델도 작아질 거라고 봄  
    지금의 인프라 대규모 증설이 철도 같은 느낌이 될 또 하나의 이유임

- 소개 블로그 글에 정보가 훨씬 많음  
  [https://microsoft.ai/news/introducingmai-code-1-flash/](<https://microsoft.ai/news/introducingmai-code-1-flash/>)  
  그리고 모델 카드도 있음  
  [https://microsoft.ai/pdf/MAI-Code-1-Flash-Model-Card.PDF](<https://microsoft.ai/pdf/MAI-Code-1-Flash-Model-Card.PDF>)  
  제목의 활성 5B는 7개 MAI 모델에 대한 더 넓은 발표에서 나온 듯함  
  [https://microsoft.ai/news/building-a-hillclimbing-machine-la...](<https://microsoft.ai/news/building-a-hillclimbing-machine-launching-seven-new-mai-models/>)

- Haiku가 애초에 무엇을 위한 모델인지 다시 떠올려야 했음  
  Anthropic이 최근 Haiku 마케팅에 큰 힘을 쓰지는 않았음  
  가벼운 모델이 필요하면 Sonnet을 씀. Max 플랜에서는 거의 공짜에 가깝고 꽤 빠름. 일반적인 코딩에서 Haiku가 들어갈 자리는 잘 안 보임  
  Haiku는 대규모 **요약/분류**가 필요할 때 쓰는 모델인 듯함  
  Microsoft가 Haiku를 기준점으로 삼은 건 낮은 기준임
  - “Max 플랜에서는 거의 공짜”라는 말은 웃긴 모순임

- 웹사이트는 **Safari에서 테스트**해 줬으면 함  
  iOS 사용자는 거의 전부 기본으로 Safari를 쓰고, 데스크톱 경험도 모바일과 꽤 비슷하니 테스트가 쉬움  
  저 스크롤 효과는 내 환경에서 완전히 버벅임. Chrome/Edge에서는 잘 된다는 건 알겠음
  - Firefox+macOS에서도 확실히 **스크롤 가로채기** 같은 게 있고 느낌이 끔찍함

- 어제만 출시됐어도 Copilot 자동 모델 선택이 **9배짜리 모델**을 써서 한 오후 만에 월 할당량을 조용히 태워버리는 일은 피했을지도 모름
