마이크로소프트는 지난 2024년 5월 윈도우 코파일럿 런타임을 발표했다. 당시 새로 출시된 코파일럿+ PC를 대상으로 한 이 런타임은 온디바이스 소규모 언어 모델부터 윈도우의 NPU(신경망 처리 장치) 하드웨어 지원 개선, 윈도우 애플리케이션을 위한 새로운 인공지능 API, 그리고 인기 있는 AI 개발 및 튜닝 툴의 ARM 이식에 이르기까지 다양한 측면에서 혁신적이었다. 지난 1년 동안 이 혁신을 구현해온 마이크로소프트가 마지막 핵심 기능인 AI API를 마침내 안정화된 버전으로 출시했다.
윈도우 코파일럿 런타임은 마이크로소프트의 파이 실리카(Phi Silica) 소규모 언어 모델, 그리고 컴퓨터 비전과 오디오 서비스를 제공하기 위한 기타 여러 모델을 활용해서 PC에서 실행되는 윈도우 AI 기반 애플리케이션을 구축하기 위한 툴 모음이다. 고가의 클라우드 기반 모델을 사용할 필요가 없다. 다만 윈도우 코파일럿 런타임 애플리케이션은 로컬 리소스만 사용하므로 연산 성능이 초당 40조 회 이상인 전용 AI 가속 칩이 필요하다.
첫 릴리즈 당시에는 이러한 기능을 이용할 수 있는 PC는 제한적이었지만 이제는 거의 표준이다. 인텔과 AMD의 최신 반도체 칩은 첫 코파일럿+ 하드웨어에 사용된 ARM 하드웨어와 동일한 NPU 기능을 제공하며 가격도 전보다 훨씬 더 저렴해졌다. 최근 출시된 서피스 디바이스는 이보다 더 저렴한 NPU 기반 퀄컴 칩셋을 사용하며 가격은 799달러부터 시작한다.
지난 몇 년 동안 AI 전환을 거치며 모두가 알게 됐듯이, AI에서 1년은 매우 긴 시간이다. AI를 더 쉽게 실제 데이터에 그라운딩하도록 돕는 새로운 기술이 등장했고 엔드포인트에 바로 사용할 수 있는 오픈소스 모델의 수도 대폭 증가했다. 마이크로소프트는 새 윈도우 릴리즈에 새로운 소규모 언어 모델을 번들로 제공한다(개발자 릴리즈는 제공되지 않을 수 있음).
이제 저렴한 PC로 복잡한 AI 모델을 개발, 튜닝, 실행할 수 있게 된 만큼 마이크로소프트는 윈도우 AI 개발의 다양한 구성요소를 애저(Azure)의 통합 AI 파운드리(AI Foundry)와 동일한 유형의 플랫폼으로 가져오고, 개발자가 자체적인 윈도우 개발 툴체인에 이를 손쉽게 통합할 수 있도록 해야 한다.
윈도우 AI 파운드리 소개
1년이 지난 지금 마이크로소프트는 윈도우 코파일럿 런타임을 AI 개발 플랫폼을 제공하는 새로운 툴 모음으로 발전시켜 윈도우 AI 파운드리라는 이름으로 리브랜딩하고 있다. 동시에 마이크로소프트는 더 다양한 PC에서 더 쉽게 모델을 실행할 수 있도록 다이렉트ML(DirectML)에 새로운 추상화를 추가하고 있다(이 부분은 윈도우 ML로 리브랜딩 중). 핵심 구성요소는 사용자 하드웨어에 따라 적합한 AI 모델을 다운로드하고 실행하는 AI 런타임인 파운드리 로컬(Foundry Local)이다. 파운드리 로컬은 현재 윈도우와 맥OS에서 프리뷰 단계에 있다.
윈도우 코파일럿 런타임과 달리 윈도우 AI 파운드리는 더 이상 코파일럿+ PC에만 초점을 맞추지 않고, 새로운 윈도우 ML 플랫폼을 기반으로 CPU, GPU, NPU에서 AI 추론을 지원한다. 마이크로소프트는 당분간은 윈도우 앱 SDK를 통해 코파일럿+ PC용 API도 계속 제공할 예정이다. 윈도우 AI 파운드리는 사용 가능한 모델을 관리하는 CLI 툴로서 새로운 파운드리 로컬 애플리케이션을 기반으로 하며, 마이크로소프트 이외의 다른 모델 카탈로그도 지원한다.
목표는 개발자가 윈도우에서 AI 애플리케이션을 더 쉽게 구축하고, 사용자가 최대한 다양한 PC에 설치해 사용할 수 있도록 하는 것이다. 마이크로소프트는 자체 AI 내장 모델과 함께 제공되는 NPU가 장착된 디바이스를 위해 윈도우 앱 SDK에 부가적인 윈도우 AI API를 제공할 예정이다. 윈도우 플랫폼 및 AI 런타임 제품 담당 파트너 디렉터인 자틴터 만은 “AI 클라우드의 모든 기능을 클라이언트로 가져오고 있다. 대규모 AI 모델을 윈도우에서 바로 실행하고 맞춤 설정하고 구축하기 위한 시스템이라고 보면 된다”고 말했다.
윈도우 AI 파운드리의 중요한 새로운 기능 중 하나는 내장된 파이 실리카 모델을 위한 LoRA(저순위 적응) 튜닝 알고리즘 지원이다. 비주얼 스튜디오 코드의 AI 툴킷을 사용해서 튜닝이 가능해진다. 또한 윈도우 스토어의 AI 데브 갤러리(AI Dev Gallery) 애플리케이션 최신 버전에는 기존 LoRA 어댑터를 파이 실리카에 신속하게 추가하고 평가하는 기능이 있다. 이와 같은 툴은 개발자에게 AI 모델을 튜닝하고 애플리케이션이 적절한 결과물을 내놓도록 보장하기 위한 기술을 제공하는 데 있어 중요한 부분이다. 튜닝은 애플리케이션에 그라운딩을 추가하고 자체 데이터를 사용해 결과를 유도함으로써 환각 위험을 줄이는 유용한 방법이다.
애저의 모델 제어 프로토콜(MCP) 도입에 발맞춰 윈도우도 AI 작업을 애플리케이션과 통합하기 위해 MCP를 도입한다. 이를 통해 AI 애플리케이션은 PC에 위치하는 애플리케이션을 신속하게 에이전트로 사용해 이를 지능형 워크플로우에 구축해 넣을 수 있다. 애플리케이션은 특정 기능을 앱 작업(App Action)으로 노출할 수 있으며 이는 신속하게 MCP 서버가 되어 맞춤형 워크플로우를 위한 새로운 빌딩 블록을 제공한다.
파운드리 로컬 사용하기
엔비디아 GPU가 장착된 x64 PC와 퀄컴 NPU가 장착된 ARM PC에서 각각 파운드리 로컬을 테스트했다. 먼저 두 디바이스에 파이 4 미니(Phi 4 Mini)를 다운로드했다. 파이 4 미니는 엔비디아 디바이스에서는 GPU, ARM 컴퓨터에서는 CPU를 사용해 실행됐다. 참고로 파운드리 로컬은 PC 하드웨어를 프로파일링하고 최적의 모델 버전을 자동으로 다운로드한다. 현재 모델 라이브러리를 보려면 foundry model list 명령을 사용하면 된다. 이 명령은 어느 ONNX 런타임이 어느 모델에서 지원되는지 보여준다. 첫 테스트에서는 모델이 NPU 추론을 지원하지 않는 것으로 나타났다.
모델 목록은 사용 중인 디바이스에서 무엇이 지원되는지를 보여준다. 따라서 퀄컴 NPU를 지원하는 모델을 보려면 ARM 디바이스에서 list를 실행해야 한다. 이를 통해 Phi4-mini-reasoning이 NPU를 지원한다는 사실을 볼 수 있다. 또한 파운드리 로컬을 사용해 프롬프트를 제공할 때 가속기를 사용하고 있음을 작업 관리자의 NPU 성능 모니터에서 확인할 수 있었다. 모든 모델이 모든 NPU에 최적화된 것은 아니며, 아키텍처에 따라서도 사용 가능한 모델이 달라질 수 있다. 곧 NPU 추론에 더 많은 모델을 사용할 수 있게 되기를 바란다.
로컬 프롬프트는 첫 시작으로 괜찮은 방법이지만 자체 SDK와 오픈AI SDK를 지원하는 파운드리 로컬을 사용하는 편이 더 유용하다. 파운드리 로컬은 모델을 위한 REST 엔드포인트를 노출하므로 이를 대상으로 코드를 작성할 수 있다. 로컬 엔드포인트에서도 클라우드 엔드포인트와 동일한 REST 호출을 사용할 수 있다.
로컬 AI 애플리케이션을 구축하는 데 필요한 마이크로소프트 툴이 마침내 나온 것이다. 파운드리 로컬은 PC에서(개발용 PC와 사용자용 PC 모두) 모델을 관리하면서 클라우드에서 PC로 코드를 옮기는 데 필요한 API를 제공하며, 이 과정에서 전용 추론 가속기를 활용해 클라우드 데이터 센터의 부하를 없앤다.
윈도우 ML의 기반
추론을 위한 공통 프레임워크로 윈도우 ML을 사용하는 것은 새로운 윈도우 AI 개발 플랫폼의 또 다른 핵심 요소로, 현재 추론을 처리하는 PC에 가장 적합한 런타임 환경을 사용해 ONNX 모델을 호스팅하고 호출하는 표준적인 방법을 제공한다. 코드에서 파운드리 로컬 SDK와 CLI를 사용해서 애플리케이션에 사용할 수 있는 모델 유형을 확인해 다운로드하고 최신 상태로 유지할 수 있으며, 윈도우 ML이 모델의 실행을 보장한다. 이것이 윈도우 AI 파운드리의 기반이라고 보면 된다. 즉, 모든 것이 이 위에 있으며, 이게 없으면 아무것도 작동하지 않는다.
윈도우 AI 파운드리에서 지원하는 모델 라이브러리에 파운드리 로컬만 있는 것은 아니다. 올라마, 허깅 페이스와 같은 공개 카탈로그와도 호환된다. 마이크로소프트 자체 파운드리 로컬 모델 라이브러리를 최적화하기 위한 작업은 마이크로소프트가 했지만 다른 모델의 적절한 ONNX 구현을 적용하기 위해서는 추가 작업이 필요할 수 있다는 점에 유의해야 한다.
파운드리 로컬의 현재 프리뷰는 독립적인 애플리케이션으로 설치되지만, 계획은 윈도우의 일부로 집어넣어 사용자가 WinGet 사용법을 배울 필요 없이 파운드리 로컬의 SDK와 API를 사용하도록 만들어진 AI 애플리케이션을 실행할 수 있도록 하는 것이다. 이렇게 되면 윈도우 ML이 플랫폼의 일부가 되고 파운드리 로컬 캐시에서의 모델 실행이 간소화될 것이다. 파운드리 로컬은 윈도우 기본 애플리케이션이므로 실행 공급자를 관리할 필요가 없다. 최신 버전의 모델과 함께 실행 공급자가 알아서 선택되고 다운로드된다.
윈도우 ML을 타겟팅하면 코드의 미래 유용성을 확보하는 데 도움이 된다. 새로운 CPU, GPU, NPU가 출시되더라도 이것이 엔드포인트 AI 코드를 위한 하드웨어 독립적인 공통 환경을 제공하기 때문이다. 그 결과는 코파일럿 런타임의 크로스 플랫폼 후속 버전으로, GPU 또는 NPU가 탑재된 PC뿐만 아니라 모든 윈도우 PC를 지원하게 된다.
모델 컨텍스트 프로토콜로 연결하기
빌드 2025 사전 행사에서 마이크로소프트 CTO 케빈 스콧은 이른바 “에이전틱 웹(agentic web)”의 발전에 대해 이야기했고, 이후 빌드 기조연설에서 CEO 사티아 나델라도 이 개념을 다시 언급했다. 에이전틱 웹 개념의 핵심은 모델 컨텍스트 프로토콜(Model Context Protocol) 기반의 새로운 툴을 만들어 애플리케이션과 데이터 소스를 AI 애플리케이션에 쉽게 연결할 수 있도록 하는 것이다. 스콧은 MCP를 ‘분산 AI 플랫폼의 HTTP’라고 설명했다.
필자는 이 의견에 전적으로 동의하지는 않지만(개인적으로는 CORBA와 같은 기술에 더 가깝다고 생각함), 스콧의 말은 중요한 점을 짚는다. 즉, 복잡하고 값비싼 임베딩 기반 벡터 인덱스를 구축하지 않고도 AI 애플리케이션을 실제 데이터에 그라운딩할 수 있는 방법이 필요하다는 것, 그리고 AI 기반 워크플로우에 속하는 애플리케이션이 에이전트 쿼리와 어느 데이터를 공유할지 제어하기 위해 필요한 도구를 제공해야 하며, 이 모든 것을 AI 워크플로우에 연결할 수 있는 표준 서비스 모음으로 묶어야 한다는 것이다.
윈도우 AI 플랫폼이 윈도우 애플리케이션에 에이전트를 연결해서 에이전틱 윈도우(Agentic Windows)를 형성하는 자체 MCP 프레임워크를 제공하는 것이 놀라운 일은 아니다. 이를 통해 코드에서 특정 기능을 애플리케이션에 노출할 수 있으므로 UI 액세스가 필요한 일반 연산자 모델을 두는 데서 오는 복잡성을 피할 수 있다. 윈도우 디벨로퍼(Windows Developer)의 제품 마케팅 디렉터인 디비야 벤카타라무는 이것이 “에이전트가 MCP 서버를 통해 윈도우 네이티브 앱과 상호작용할 수 있는 표준화된 프레임워크”를 제공한다고 설명했다.
OS에 MCP를 통합해 넣기 위해서는 API에 서버를 추가하는 툴만으로는 부족하다. 에이전트가 에이전트 워크플로에 포함할 수 있는 사용 가능한 에이전트를 찾을 수 있도록 하는 방법이 필요하다. 이는 MCP 레지스트리의 형태로 제공되며, 최소 권한 제어 및 감사 가능한 운영으로 서버를 래핑하는 강화된 보안 모델과 연결된다. 이제 윈도우는 특정 기능을 위한 자체 MCP 서버를 노출한다. 초기에는 API 표면의 일부만 제공되겠지만 시간이 지나면서 더 많은 기능이 MCP를 통해 노출될 예정이다.
벤카타라무와의 대화에서 필자의 흥미를 끈 시나리오 중 하나는 에이전트를 사용해 PC에 바로 코딩을 시작할 수 있는 개발 환경을 구축하는 것이다. 벤카타라무와는 “먼저 VS 코드에서 깃허브 코파일럿을 열어 환경 설정을 요청한다. 이렇게 하면 WSL의 MCP 서버에 안전하게 연결된다. 에이전트는 적절한 리눅스 배포판을 설치할 수 있다. 개발자가 직접 WSL 환경을 설치하려면 원하는 배포판의 최신 버전을 파악한 다음 해당 배포판을 찾고 모든 패키지를 설치하는 데만 해도 상당한 시간이 걸릴 것이다. 이제 에이전트가 이러한 작업을 수행하도록 하면 개발자는 환경 자체가 자동으로 설정된 상태에서 코딩 준비에 집중할 수 있다”고 말했다.
앱 작업으로 애플리케이션에 MCP 서버 추가
가용한 MCP SDK를 사용해서 기존 API와 함께 작동하는 특정 애플리케이션 기능을 에이전트에 노출할 수 있다. 또는 애플리케이션 개발자를 위해 마이크로소프트가 제공하는 새로운 기능인 앱 작업(App Action)도 있다. 앱 작업은 특정 애플리케이션 기능을 MCP 서버로 래핑한다. 서비스에 웹훅을 추가하고 에이전트에서 사용할 동작을 노출하는 것과 비슷한 방식이다. 웹훅과 달리 앱 작업 정의에는 AI 기반 에이전트를 구축하기 위한 의미체계 설명이 포함된다.
앱 작업의 핵심은 엔티티 개념이다. 엔티티는 작업에 전달되고 작업에서 반환되는 객체로, 간단한 변수, 그보다 더 복잡한 결과 집합, 문서, 사진 또는 텍스트 등이 있다. 엔티티는 JSON 객체이므로 개발자가 이미 익숙한 기법을 사용해 앱 작업을 구축하고 제공할 수 있으며, 윈도우는 WinRT에 새로운 API를 포함해서 코드에 빠르게 엔티티 지원을 추가할 수 있도록 한다. 앱 작업은 현재 윈도우 SDK 프리뷰 릴리즈에서 지원되며 프로젝트의 일부로 선언해야 한다.
앱 작업 빌드의 시작은 엔티티 JSON이다. 엔티티 JSON은 에이전트 빌더에서 작업이 설명되는 방식, 입출력, 그리고 예를 들어 COM GUID를 통한 호출 방식을 정의한다. 코드에서 비동기 인터페이스를 구현하는 앱 공급자(Action Provider) 클래스를 사용해 작업을 처리할 적절한 핸들러를 작성해야 한다. 공급자는 앱 작업 JSON에 정의된 이름을 사용해서 적절한 코드로 입력을 라우팅하고 작업이 완료되면 응답을 반환한다.
마이크로소프트는 작업을 테스트하기 위한 앱 작업 플레이그라운드를 제공한다. 윈도우에 작업을 등록하면 플레이그라운드에서 볼 수 있다. 그런 다음 입력 엔티티를 전송하고 플레이그라운드를 사용해 애플리케이션 응답을 확인할 수 있다. 이후 애플리케이션은 작업의 가용성을 설정할 수 있다. 예를 들어 코드를 실행하고 종료할 때 작업을 켜고 끌 수 있다. 이렇게 하면 애플리케이션과 에이전트는 사용자 제어 하에서만 실행된다.
비주얼 스튜디오 코드와 같은 툴에서 깃허브 코파일럿을 통해 MCP가 지원되면 코드 툴과 디자인 툴, 또는 코드 툴과 클라우드 서비스를 기능 수준에서 연결하는 AI 기반 툴체인을 갖출 수 있게 된다. 필요한 것은 우리가 지능형 워크플로우를 구축할 수 있도록 툴이 자체 서버를 추가하는 것이다.
윈도우의 AI 플랫폼
윈도우를 성공으로 이끈 핵심은 윈도우가 플랫폼이라는 사실이다. 마이크로소프트가 이것을 잊지 않은 것은 분명해 보인다. 이 새로운 플랫폼의 중심에 위치하는 윈도우 AI 파운드리 및 관련 툴은 모든 종류의 모델(특히 오픈소스 모델)을 사용해 윈도우 애플리케이션에 AI를 구축하도록 설계됐으며, 더 광범위한 에이전트 웹의 로컬 인스턴스에 PC의 코드를 연결하는 방법을 제공한다. 즉, 마이크로소프트는 MCP 서버를 관리하고 보호하는 데 필요한 툴을 제공함으로써 사용자를 보호하고 있다.
빌드 2025에서 발표된 기능 대부분이 지금 바로 다운로드 및 실행이 가능한 상태라는 것은 반갑지만, 툴이 더 개선되고 윈도우에 통합되는 과정에서 앞으로 더 많은 것들이 나오게 된다. 개발자가 지금 해야 할 일은 CPU, GPU 또는 NPU에 관계없이 모든 PC에 번들로 제공되기 전에 윈도우의 에이전트 AI 미래를 구축하고 테스트하는 데 필요한 요소를 미리 찾는 것이다. 시작하기 위한 툴은 이미 나와 있으므로 향후 윈도우 업데이트의 일부로 사용자에게 이러한 툴이 제공되면 그 즉시 코드를 실행할 수 있도록 준비해 두자.
dl-itworldkorea@foundryco.com
Simon Bisson editor@itworld.co.kr
저작권자 Foundry & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.