
계속 궁금한 점: AI가 이미 새 코드의 22~46%를 작성하고 있다면, MAI-Code-1은 실제로 무엇을 학습하고 있는가?
요약
추론 모델(Reasoning model)과 기존 LLM의 차이점 및 비용 구조를 분석합니다. 추론 모델은 사고 토큰을 통해 복잡한 문제를 해결하지만 지연 시간과 비용이 높으므로, 작업 성격에 맞는 모델 선택이 중요함을 강조합니다.
핵심 포인트
- 추론 모델은 사고 토큰 사용으로 인해 비용과 지연 시간이 증가함
- 복잡한 아키텍처 리뷰에는 추론 모델을, 자동 완성에는 빠른 모델을 권장
- Copilot은 단일 모델이 아닌 다양한 엔진을 사용하는 레이어 구조임
- 추론 모델은 강화학습을 통해 내부적인 사고 체인을 학습함
처음 접할 때 모두를 당황하게 만드는 예산 관련 주의사항이 있습니다. 모든 추론 모델 (Reasoning model)은 응답에 나타나지 않는 '사고 토큰 (Thinking tokens)'에 대해서도 비용을 지불해야 하며 (입력 토큰 비용의 최대 약 6배까지 치솟을 수 있음), 기존의 LLM (Large Language Model)이 즉각적으로 답변하는 작업에서도 40~90초의 지연 시간 (Latency)을 감수해야 합니다.
추론은 의도적인 작업(아키텍처 리뷰, 마이그레이션, 장애 사후 분석)을 위해 남겨두세요. 자동 완성 (Autocomplete)에는 빠른 모델을 사용하십시오. 더 많이 생각한다고 해서 항상 더 나은 것은 아닙니다.
MAI 수치를 기다리는 동안 가격 맥락을 참고하자면: OpenAI o3는 1M 입력/출력 토큰당 $10/$40이며, Gemini 2.5 Pro는 200K의 사고 예산(Thinking budget)과 함께 $1.25/$10입니다.
추론 모델 (Reasoning model) vs 기존 LLM, 30초 요약 버전
두 가지를 모두 사용하여 제품을 출시해 본 적이 있다면 이 부분을 건너뛰어도 좋습니다. 그렇지 않다면: 기존의 LLM은 본능적으로, 즉 한 번에 다음 토큰을 예측하여 답변합니다. 빠르고 저렴하지만, 다단계 문제에서는 비틀거립니다. 추론 모델은 먼저 생각합니다. 내부적인 체인 (사고 토큰)을 생성하고, 경로를 시도하며, 스스로를 점검한 다음 답변합니다. 모델은 체인이 정답에 도달했을 때 보상을 받는 강화학습 (Reinforcement learning)을 통해 이를 학습합니다.
질문이 끝나기도 전에 대답하는 친구를 알고 계시죠? 가끔은 맞지만, 대개는 틀립니다. Kahneman의 "Thinking, Fast and Slow"는 수년 전에 이를 정확히 짚어냈습니다. 시스템 1 (System 1)은 빠르고, 시스템 2 (System 2)는 신중합니다. RLM (Reasoning Language Model)은 토큰 단위로 과금되는 시스템 2입니다.
Copilot은 결코 모델이 아니었다
이 부분은 대부분의 사람들이 잘못 알고 있는 지점이며, 이번 출시를 평가하는 방식을 바꿉니다. Copilot은 모델이 아니라 레이어 (Layer)입니다. Perplexity와 마찬가지로, 선택기에서 선택할 수 있는 서로 다른 엔진들이 밑단에서 실행됩니다. 지금까지 그 엔진은 OpenAI의 GPT였습니다.
우리는 고객들을 위한 브랜드 가시성 감사 (brand-visibility audits)를 수행하며 이 사실을 뼈아프게 배웠습니다. "Copilot"을 감사하는 것은 사실 ChatGPT를 감사하는 것과 같았습니다. 왜냐하면 그 밑단에 있는 모델이 바로 그것이었기 때문입니다. 엔진은 같고 껍데기만 달랐던 것이죠. 하지만 MAI와 함께라면, Copilot은 추론 (reasoning) 능력과 자신만의 목소리를 갖게 되므로 그 동등성이 깨지게 됩니다.
연구실에서 전하는 솔직한 이야기
솔직하게 말씀드리겠습니다. 왜냐하면 그것이 이 포스트에서 읽을 가치가 있는 유일한 부분이기 때문입니다.
"기본 상태 (out of the box)"의 Copilot은 2년 동안 우리를 좌절시켰습니다. Office 통합 기능은 기대에 미치지 못했습니다. Excel에서 Copilot을 열면 데이터에 손을 댈 수 없다고 말하는 반면, Playwright 플러그인을 사용하는 Claude는 전혀 힘들이지 않고 모든 것을 처리하곤 했습니다. 어느 시점에 이르러 우리의 내부적인 판단은 냉혹했습니다. 차라리 Office를 완전히 버리고 모델이 HTML로 슬라이드 (deck)를 생성하게 하는 편이 낫겠다는 것이었습니다.
우리가 실제로 원하는 것은 AI가 워크플로우 (workflow)를 조율하고, 인간이 경험과 판단력을 제공하는 시스템입니다. 협업적인 프로젝트 지식과 완전한 AI 통합을 동시에 수행하는, 그런 깔끔한 시장 솔루션은 아직 존재하지 않습니다. 그래서 많은 팀이 그러하듯, 우리도 독특한 자체 제작 스택 (homemade stack)을 운영하고 있습니다: Obsidian + SharePoint + GitHub를 Codex, 에이전트 (agents), 그리고 Claude Code에 연결한 형태입니다. 작동은 합니다. 하지만 솔직히 말해서, 이것이 장기적인 해답은 아닙니다.
따라서 GitHub 데이터로 학습되고 GitHub을 위해 구축된 모델은 우리가 알고 있는 바로 그 고통스러운 지점에 직면하게 됩니다. 하지만 이는 제가 진심으로 답할 수 없는 질문을 던지기도 하며, 여러분의 의견을 댓글로 듣고 싶습니다.
여기 불편한 계산 결과가 있습니다. GitHub은 2025년까지 Copilot이 활성화된 파일에서 최대 46%의 코드를 생성하고 있으며 (Java의 경우 61%), 수락률 (acceptance rate)은 약 **27-30%**에 달한다고 밝혔습니다. DX의 2025년 4분기 보고서에 따르면, 병합된 코드 (merged code)의 **약 22%**가 AI가 작성한 것으로 나타났습니다. Google은 새로운 코드의 **약 25-30%**가 AI의 도움을 받았다고 밝혔습니다. 아무도 전체 수치를 깔끔하게 측정하지는 못하지만 (사후에 AI가 작성한 코드를 찾아낼 신뢰할 수 있는 탐지기가 없기 때문입니다), 새로운 코드의 흐름은 이미 20-46% 범위 어딘가에 머물고 있으며 계속 상승하고 있습니다.
따라서 Microsoft가 MAI-Code-1이 "GitHub 코드로 학습되었다"라고 말할 때, 그 코드의 의미 있는 부분은 처음부터 Copilot, Codex 또는 Claude에 의해 작성되었을 가능성이 거의 확실합니다. 이는 질문을 더욱 날카롭게 만듭니다. "GitHub에서 학습했다"는 것이 정말 "모델 출력물(model outputs)로 학습했다"는 것과 크게 다를까요? 이것이 바로 실질적인 모델 붕괴 (model collapse)입니다. CMU의 연구와 800개 이상의 인기 GitHub 프로젝트에 대한 분석은 이미 AI 도입 이후 코드 품질이 저하되고 있음을 경고하고 있습니다. 만약 새로운 모델들이 점점 더 AI가 작성한 코드를 통해 학습한다면, 그들은 스스로의 실수를 증폭시킬 위험이 있습니다.
MAI-Code-1에 대한 구체적인 수치는 알 수 없습니다 (Microsoft는 학습 데이터 세트 중 AI가 생성한 비중을 공개하지 않았습니다). 하지만 "깨끗하고 라이선스가 확보된 데이터"와 "AI 오염이 없는 데이터"는 동일한 주장이 아닙니다. 여러분은 어떻게 생각하시나요?
벤치마크 그 이상의 의미
진정한 이야기는 그 전략에 있습니다. Microsoft는 OpenAI에 130억 달러를, Anthropic에는 최대 50억 달러를 투자했으며, 두 곳 모두를 Azure를 통해 판매합니다. 2026년 4월 27일, OpenAI의 독점권이 종료되었습니다 (그 계기는 OpenAI와 Amazon 간의 최대 500억 달러 규모의 계약이었습니다). 따라서 Microsoft는 이제 투자자, 유통업체, 인프라 제공자이자 직접적인 경쟁자 역할을 동시에 수행하고 있으며, 엔진을 빌려 쓰는 것보다 직접 소유하는 쪽을 선호합니다.
우리가 얻을 수 있는 실질적인 시사점은 다음과 같습니다:
- 도입 여부는 리더보드(leaderboards)에 의해 결정되지 않을 것입니다. 대신 정체성 (identity), 로깅 (logging), 데이터 경계 (data boundaries), 보존 (retention), 서비스 수준 계약 (SLAs), 예측 가능한 비용, 그리고 지식재산권 (IP) 면책에 의해 결정될 것입니다. Microsoft는 이러한 관리 평면 (management plane)을 판매하는 데 매우 능숙합니다.
- 깨끗한 IP 계보 (IP lineage)는 마케팅이 아닌 실제 기능입니다. "증류(distillation) 없음"은 규제 대상 팀들에게 조달 과정에서의 필수 체크 항목입니다 (2025년 DeepSeek의 "누구의 출력물로 학습했는가?"라는 혼란이 이를 구체화했습니다).
- 락인 (Lock-in) 효과는 더 교묘해집니다. 귀하의 워크플로우에 맞춰 튜닝되고, 귀하의 정체성에 연결되며, Azure를 통해 비용이 청구되는 모델은 옮기기 어렵다는 점 때문에 강력한 힘을 가집니다. 이를 테스트하고, 측정하며, 이식성 (portability)을 요구하십시오.
회의론자의 주석
냉정함을 유지하십시오. 벤치마크 (benchmarks)는 Microsoft 자체 결과이며, 외부 연구소에서 이를 재현한 사례는 없습니다. 비교 방식 또한 선택적입니다 (Sonnet 4.6을 전반적으로 능가하지만, 단 하나의 코드 지표에서만 Opus 4.6과 동등한 수준을 보입니다). 256K 대 128K 컨텍스트 (context) 논란을 포함하여 공개된 수치들은 요동칩니다. 새롭고 실제적인 사내 모델 (in-house models)인가요? 그렇습니다. 능력의 혁명인가요? 아마도 아닐 것입니다. 그렇다고 제가 크게 신경 쓰는 것도 아닙니다. 가치는 독립성, 비용, 그리고 통제권에 있습니다.
그것과 더불어, 한 가지 더 조용한 결과가 있습니다. Microsoft의 AI 미래가 훨씬 덜 빌려온 것처럼 보이며 훨씬 더 유망해 보이기 시작했다는 점입니다. 우리는 항상 Microsoft가 우리의 워크플로 (workflow)를 과도하게 통제하는 것을 두려워한다는 것을 알고 있습니다. 하지만 Google이 웹을 통제하거나 TikTok이 우리 아이들의 정신을 통제하는 것을 걱정하지 않는다면, 이것이 그렇게 걱정스러운 일일까요? 우리가 Microsoft가 GitHub의 소유권을 갖는 것을 받아들였을 때, 우리는 이와 유사한 일이 일어날 것임을 알고 있었습니다.
Zoopa의 AI R&D 부문인 498A를 위해 Carlos Ortet가 작성함. 용어 사전 및 FAQ와 함께 Zoopa 블로그에 최초 게시됨.
출처: Introducing MAI-Thinking-1 (Microsoft AI) · Introducing MAI-Code-1-Flash (Microsoft AI) · MAI-Code-1-Flash on the GitHub Changelog
AI가 작성한 코드 점유율에 대하여: GitHub Copilot 통계 · "AI가 모든 코드의 46%를 작성하고 있다" · 모델 붕괴(Model collapse) 설명 (IT Pro) · CMU: AI는 여전히 코드를 더 나쁘게 만들고 있다
www.carlosortet.com
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기