Microsoft가 Build에서 자체 AI 모델을 추가로 공개할 것으로 알려졌습니다. 코딩 특화 모델, 추론 특화 모델, 에이전트용 모델이 거론되고, GitHub Copilot에 쓰일 더 저렴한 코딩 모델도 주목받고 있습니다.
겉으로 보면 “Microsoft가 OpenAI 의존도를 줄이려는가?”라는 질문이 먼저 떠오릅니다. 하지만 더 실용적인 관점은 따로 있습니다.
Microsoft는 어떤 작업에 어떤 모델을 배정할지 직접 통제하려는가?
이 질문이 중요한 이유는 AI 제품의 경쟁력이 이제 단일 모델의 성능만으로 결정되지 않기 때문입니다. 비용, 지연시간, 품질을 함께 관리하면서 작업별로 모델을 고르는 능력이 점점 더 중요해지고 있습니다.
자체 모델의 의미: 더 싸게, 더 자주, 더 적절하게 쓰기
AI 서비스에서 큰 비용은 추론에서 발생합니다. 사용자가 요청할 때마다 모델을 실행해야 하고, Copilot처럼 하루 종일 쓰는 개발자 도구에서는 그 비용이 빠르게 누적됩니다.
따라서 Microsoft의 자체 코딩 모델은 단순한 기술 과시라기보다 운영 전략에 가깝습니다. 모든 요청에 최고급 범용 모델을 쓰는 대신, 코드 자동완성, 간단한 수정, 테스트 생성처럼 반복적이고 빈번한 작업에는 더 저렴한 특화 모델을 배치할 수 있습니다.
이미 Microsoft Foundry에는 이미지, 음성, 전사 작업용 Microsoft 1st-party MAI 모델이 추가됐습니다.1 MAI-Voice-1과 MAI-1-preview처럼 특정 사용처를 겨냥한 자체 모델도 공개된 바 있습니다.2 이는 Microsoft가 “하나의 거대 모델”보다 “용도별 모델 포트폴리오”를 강화하고 있음을 보여줍니다.
핵심은 모델 자체보다 라우팅이다
앞으로 AI 플랫폼의 차별점은 “가장 똑똑한 모델 하나”가 아니라 “요청에 맞는 모델을 얼마나 잘 고르는가”에서 나올 가능성이 큽니다.
Microsoft Foundry는 모델 라우터의 품질, 비용, 지연시간을 평가하는 절차를 제공합니다.3 모델 라우터는 사용자의 요청을 보고 가장 적절한 모델을 선택하는 장치입니다. Foundry의 라우터 평가는 라우터 인식 평가 파이프라인용 오픈소스 GitHub 저장소를 사용합니다.3
이 관점에서 Microsoft 자체 모델은 전체 전략의 일부입니다. OpenAI, Anthropic, Google, 오픈소스 모델과 함께 Microsoft 모델을 조합하고, 작업별로 자동 선택하는 구조가 더 중요합니다.
즉 Build에서 새 모델 이름이 무엇인지보다 중요한 질문은 이것입니다.
어떤 작업을 Microsoft 자체 모델이 맡는가?
어떤 작업은 외부 고성능 모델로 보내는가?
비용과 지연시간이 중요한 요청은 어떻게 처리하는가?
Copilot 같은 제품에서 모델 선택이 사용자 경험에 어떤 영향을 주는가?
Copilot은 AI 기능 경쟁에서 AI 원가 관리로 이동한다
GitHub Copilot에 더 저렴한 코딩 모델이 필요해진 배경도 이 흐름과 연결됩니다. 개발자 도구는 사용 빈도가 높고, 에이전트형 코딩은 한 번의 작업에도 많은 토큰을 사용할 수 있습니다.
예를 들어 코드베이스를 읽고, 수정 계획을 세우고, 파일을 바꾸고, 테스트까지 실행하는 에이전트형 작업은 단순한 자동완성보다 훨씬 많은 모델 호출을 요구합니다. 이런 구조에서는 성능만큼이나 비용 관리가 중요해집니다.
Microsoft Foundry에는 GPT-5.5, GPT-image-2, Gemma 4, Claude Opus 4.7 같은 외부 모델도 계속 추가되고 있습니다.1 동시에 Foundry Local은 2026년 4월 GA 단계에 도달했고, Microsoft Agent Framework 1.0도 같은 시기 GA로 공개됐습니다.1
이는 Microsoft가 클라우드 모델, 로컬 실행, 에이전트 프레임워크, 자체 모델을 하나의 운영 체계로 묶으려 한다는 신호로 볼 수 있습니다. Copilot 역시 단순한 “AI 구독 상품”을 넘어, 작업별 모델 배정과 원가 관리를 정교하게 해야 하는 제품이 되고 있습니다.
기업이 배울 점: 모델 선택보다 작업 분해가 먼저다
Microsoft의 자체 AI 모델 전략에서 기업과 개발자가 얻을 수 있는 교훈은 분명합니다.
이제 “어떤 모델이 제일 좋은가?”만 묻는 것으로는 부족합니다. 먼저 해야 할 일은 업무를 나누는 것입니다.
복잡한 설계, 장기 추론, 고난도 문제 해결은 고성능 모델에 맡긴다.
반복 코딩, 간단한 수정, 요약, 전사처럼 빈번한 작업은 저렴한 특화 모델로 처리한다.
지연시간이 중요한 기능은 빠른 모델이나 로컬 실행 가능성을 검토한다.
여러 모델을 쓴다면 품질, 비용, 지연시간을 함께 평가하는 기준을 만든다.
Microsoft의 자체 AI 모델은 OpenAI를 대체하느냐의 문제가 아닙니다. 더 정확히는 AI 제품을 운영하는 방식이 바뀌고 있다는 신호입니다.
앞으로 중요한 것은 하나의 최고 모델을 고르는 일이 아니라, 작업에 맞는 모델을 조합하고 라우팅하는 능력입니다. Build에서 공개될 Microsoft의 자체 모델도 이 흐름 속에서 봐야 합니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.