Skip to main content
공개 노트

Microsoft MAI models: 핵심은 '자체 모델을 제품 안에 넣는 것'

Views 22약 4분생성형 AI 활용
Summary

Microsoft MAI models: 핵심은 '자체 모델을 제품 안에 넣는 것'

Microsoft의 MAI는 하나의 모델명이 아니라 Microsoft AI가 직접 개발하는 모델군입니다. 이번 발표의 핵심도 “새 LLM이 또 나왔다”가 아니라, Microsoft가 Copilot, Visual Studio Code, Foundry 같은 자사 제품 안에 자체 모델을 더 깊게 넣기 시작했다는 점입니다.1

이 흐름을 이해하려면 MAI를 범용 모델 하나로 보기보다, 작업별로 나뉜 제품형 모델 포트폴리오로 보는 편이 낫습니다.

MAI는 작업별 모델 포트폴리오다

이번 발표에서 주목할 텍스트 LLM은 MAI-Thinking-1과 MAI-Code-1-Flash입니다.

MAI-Thinking-1은 복잡한 문제를 단계적으로 푸는 추론 모델입니다. 1T 파라미터 규모이며, 실제 추론 시 활성화되는 파라미터는 35B입니다. Microsoft는 이 모델을 제3자 모델 증류 없이 처음부터 학습했다고 설명합니다.1 기술 문서에 따르면 학습 데이터에는 독점 웹 크롤과 Common Crawl이 포함됩니다.

MAI-Code-1-Flash는 개발자 워크플로에 맞춘 코딩 모델입니다. 137B 파라미터 규모이며 활성 파라미터는 5B입니다. GitHub Copilot과 Visual Studio Code용으로 설계됐고, Copilot의 모델 선택기와 자동 선택 흐름에 배포되고 있습니다.2

이미지 영역도 같은 방향입니다. MAI 이미지 모델은 Microsoft AI가 개발한 이미지 모델군으로, 텍스트-이미지 생성을 제공합니다. 일부 모델은 기존 이미지를 입력해 편집하는 이미지-이미지 작업도 지원합니다.3

즉 MAI의 방향은 “하나의 거대 모델로 모든 일을 처리한다”가 아니라, 제품과 작업 맥락에 맞춘 모델을 배치하는 데 가깝습니다.

성능보다 먼저 볼 것은 제품 적합성이다

MAI-Code-1-Flash의 의미는 단순히 코딩 벤치마크 경쟁에 있지 않습니다. Microsoft는 이 모델을 실제 GitHub Copilot 환경에 맞춰 학습하고 평가했다고 설명합니다.2

개발자 도구 안에서 쓰이는 모델은 정답률만 높아서는 부족합니다. IDE 안에서는 응답 속도, 토큰 효율, 코드 수정 방식, 도구 호출 흐름, 불필요한 설명을 줄이는 능력이 모두 중요합니다. 좋은 모델이라도 워크플로를 끊으면 생산성 도구로는 부족합니다.

Microsoft는 MAI-Code-1-Flash가 어려운 코딩 문제를 최대 60% 적은 토큰으로 해결할 수 있다고 주장합니다.2 이 수치는 독립 검증이 필요하지만, 방향은 분명합니다. 앞으로 모델 경쟁은 “얼마나 똑똑한가”뿐 아니라 “얼마나 빠르고, 저렴하고, 자연스럽게 업무 흐름에 들어오는가”로 이동합니다.

기업은 세 가지 기준으로 봐야 한다

MAI 모델을 평가할 때는 모델 이름보다 실제 적용 조건을 먼저 봐야 합니다.

첫째, 현재 쓰는 업무 도구에 붙는지 확인해야 합니다. 이미 GitHub Copilot, Visual Studio Code, Microsoft Foundry를 쓰는 조직이라면 MAI 모델은 별도 플랫폼을 새로 도입하는 것보다 실험 비용이 낮을 수 있습니다.

둘째, 공개 벤치마크보다 내부 업무로 다시 평가해야 합니다. 코딩 모델이라면 우리 코드베이스에서의 리팩터링, 테스트 생성, 저장소 질의응답, 문서화 작업을 봐야 합니다. 이미지 모델이라면 브랜드 스타일, 편집 품질, 반복 작업 자동화 가능성을 확인해야 합니다.

셋째, 데이터와 거버넌스를 검토해야 합니다. MAI-Thinking-1 문서에는 학습 데이터에 독점 웹 크롤과 Common Crawl이 포함됐다고 설명돼 있습니다. 규제 산업이나 저작권 리스크에 민감한 조직이라면 모델 성능만이 아니라 데이터 출처, 사용 조건, 배포 환경을 함께 따져야 합니다.

MAI가 보여주는 변화

MAI 모델의 의미는 Microsoft가 OpenAI 의존을 줄였다는 이야기만으로는 충분히 설명되지 않습니다. 더 중요한 변화는 AI 모델이 독립 제품이 아니라, Copilot, VS Code, Foundry 같은 기존 소프트웨어 기능의 일부가 되고 있다는 점입니다.

따라서 앞으로 모델을 고를 때는 “가장 유명한 모델인가”보다 “우리 업무 도구 안에서 잘 작동하는가”를 먼저 봐야 합니다. 배치 위치, 비용, 지연시간, 토큰 효율, 데이터 거버넌스, 실제 업무 적합성이 모델 선택의 핵심 기준이 됩니다.

MAI는 그 전환을 보여주는 사례입니다. 모델 경쟁은 이제 연구실의 성능표를 넘어, 제품 안에서 얼마나 유용하게 작동하는지로 옮겨가고 있습니다.

참고

1Building a hill-climbing machine: Launching seven new MAI models

2Introducing MAI-Code-1-Flash

3Deploy and use MAI image models in Microsoft Foundry (preview)

이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.

틸노트는 사용자가 AI를 활용해 노트를 쉽게 작성하거나 편집할 수 있는 서비스입니다.

AI 스퀘어 단톡방에 함께해요

AI 활용과 틸노트 사용 팁을 나누는 오픈채팅방입니다. 입장 비밀번호는 tilnote입니다.

참여하기