Microsoft는 많은 양의 코드를 수동으로 작성해야 하는 기존 개발 및 마이그레이션 프로세스에 의존하는 대신, AI 에이전트를 통해 WinUI를 중심으로 Windows 앱 생태계를 재구축하려 하고 있습니다. 회사는 새로운 빠른 가이드를 통해 빈 폴더에서 WinUI 3 앱을 만든 뒤, 약 30분 안에 이를 테스트하고 MSIX 형식으로 패키징해 Microsoft Store에 제출할 수 있다고 말합니다.
제안된 과정에서는 Visual Studio를 설치할 필요가 없으며, VS Code, .NET 10, Windows App Development CLI, WinUI 프로젝트 템플릿, GitHub Copilot 무료 버전과 WinUI Agent 확장을 사용합니다. 기사에 따르면 사용되는 도구는 무료이며, 앱 생성, 기능 추가, 테스트 및 패키징 단계에서 수동 개입을 크게 제한할 수 있습니다.
WinUI Agent는 무엇을 추가하는가?
WinUI Agent를 일반적인 대화형 도우미인 Copilot과 혼동해서는 안 됩니다. 이 도구는 인터페이스 설계, 코드 검토, 사용자 인터페이스 테스트, 앱 패키징, 이전 프레임워크 기반 프로젝트 마이그레이션 등 WinUI 앱 개발과 관련된 작업을 위해 설계되었습니다. Microsoft는 또한 에이전트를 Microsoft Learn MCP 서버에 연결할 것을 권장하며, 이를 통해 에이전트가 쿼리와 작업을 수행하는 동안 최신 WinUI API 문서를 참조할 수 있습니다.
이 점은 중요합니다. 기사에 따르면 WinUI 3에는 WPF 및 UWP와 비교해 AI 모델이 학습할 수 있는 예제의 규모가 동일하지 않기 때문입니다. 따라서 필요한 최신 대안을 명시적으로 지시하지 않으면 에이전트가 오래된 패턴을 자동으로 생성할 수 있습니다.
마이그레이션은 단순한 검색 및 바꾸기가 아니다
Microsoft는 WPF 및 UWP 앱을 WinUI로 마이그레이션하기 위한 별도의 지침도 제공합니다. WPF의 경우 이 과정은 네임스페이스 이름을 바꾸는 것만으로 끝나지 않습니다. 예를 들어 System.Windows.*에서 Microsoft.UI.Xaml.*로 전환하려면 컨트롤, 스레드 처리, 창 관리, DPI 디스플레이 지원, 데이터 바인딩 등의 차이를 처리해야 합니다. 회사는 에이전트가 이러한 측면을 점검하는 데 도움이 되는 대응표와 초기 지침을 제공합니다.
UWP 지침에서는 해당 플랫폼이 더 이상 활발히 개발되지 않으며 WinUI 3와 Windows App SDK가 그 이후의 경로라고 설명합니다. Microsoft는 AI 모델이 수년에 걸쳐 축적된 다수의 UWP 예제로 학습했기 때문에, 마이그레이션 기술에서 사용해야 할 대안을 지정하지 않으면 기존 UWP 패턴을 계속 생성할 수 있다고 경고합니다.
이 소식이 중요한 이유
더 큰 목표는 Windows에 새로운 네이티브 앱을 도입하는 비용을 낮추고, 대규모 WPF 및 UWP 앱 기반을 마이그레이션하는 데 따르는 부담을 줄이는 것입니다. 이를 통해 Microsoft는 개발자들이 웹 앱과 다중 플랫폼 프레임워크를 선택하는 이유 중 하나를 해결하려 합니다. 즉, 여러 운영 체제에서 코드를 재사용할 수 있고 향후 근본적으로 바뀔 수 있는 Windows 프레임워크에 대한 의존을 피할 수 있다는 점입니다.
Microsoft는 Build 2026에서 WinUI를 “Windows 앱을 위한 생산 플랫폼”이라고 표현했으며, 향후 플랫폼이 전면적인 재구축을 겪지 않을 것이라는 메시지를 전달하기 위해 이름에서 “3”을 삭제했습니다. 그 밖의 약속으로는 메모리 사용량 감소, DataGrid 및 차트 지원 추가, WPF 호환성 개선, 오픈 소스 참여 확대가 있으며, WinUI가 완전히 오픈 소스가 되었다는 점도 언급했습니다.
기사에 따르면 Microsoft는 Windows 11의 일부 기존 Windows UI 구성 요소를 대체하는 데에도 WinUI 3를 사용하고 있으며, 여기에는 자동 실행 기능과 인쇄 관리가 포함됩니다. 이러한 내부 사용은 개발자들에게 기술 도입을 요구할 때 회사에 실질적인 근거를 제공하지만, 동시에 Microsoft 스스로 지켜야 할 기준을 드러냅니다.
코드 생성으로 해결되지 않는 한계
개발자가 작성하는 코드 줄 수를 줄인다고 해서 앱의 품질이 반드시 향상되는 것은 아닙니다. 기사에 따르면 Microsoft가 WinUI Agent에 검토 및 테스트 기능을 마련한 이유도 생성된 코드에 점검이 필요하기 때문입니다. 또한 네이티브 앱으로 개발자들을 유도하더라도 그 결과 메모리를 많이 사용하거나 느리게 동작하는 앱이 만들어진다면 충분하지 않습니다.
여기서 Microsoft 전략의 역설이 나타납니다. Microsoft는 개발자들에게 더 가벼운 네이티브 앱을 만들도록 권장하지만, 일부 앱과 Windows 자체의 인터페이스에서는 WebView2를 사용합니다. 기사에 따르면 WebView2로 구축된 Windows 11의 날씨 앱은 유휴 상태에서 약 1.2GB의 메모리를 사용하며, 이는 macOS의 네이티브 날씨 앱보다 약 5배 많은 수준이고 Chromium 하위 프로세스 9개를 실행합니다. 또한 소스에 제시된 사례에 따르면 WhatsApp, Discord, Teams와 같은 앱도 성능 또는 리소스 사용량과 관련한 비판을 받고 있습니다.
certi.news의 분석: 실제 변화는 단순히 프로그래밍 도우미를 추가하는 것이 아니라, 앱 생성, 마이그레이션, 테스트 및 패키징이 가능한 에이전트와 Windows의 전체 개발 주기를 연결하려는 시도입니다. 이 계획의 성공 여부는 도구가 아직 입증하지 못한 두 가지에 달려 있습니다. 실제 프로젝트에서 마이그레이션이 얼마나 정확한지, 그리고 AI가 생성한 WinUI 앱이 Microsoft가 경쟁하려는 웹 앱보다 실제로 성능과 리소스 사용량에서 우수할지 여부입니다. 따라서 이 이니셔티브는 Windows 개발자들에게 유망해 보이지만, 엔지니어링 검토와 실제 테스트의 필요성을 없애지는 않습니다.