Windows 네이티브 앱 개발은 왜 이렇게 엉망이 되었나 — WinUI, UWP, Win32의 혼돈 정리

한때 가장 강력했던 데스크톱 플랫폼의 현재

Windows는 여전히 전 세계 데스크톱 운영체제 시장의 70% 이상을 차지하고 있습니다. 그런데 아이러니하게도, 이 거대한 플랫폼을 위한 네이티브 앱을 만들려는 개발자들은 점점 더 혼란스러운 상황에 놓이고 있습니다. 어떤 UI 프레임워크를 써야 하는지, Microsoft가 실제로 밀고 있는 기술이 무엇인지, 내가 지금 선택한 기술이 3년 뒤에도 지원될 것인지 확신하기 어렵기 때문입니다.

이 문제를 다룬 글에서 핵심적으로 지적하는 것은, Microsoft가 Windows 앱 개발 기술을 너무 자주, 너무 급격하게 바꿔왔고, 그 과정에서 일관된 비전 없이 여러 기술이 병렬로 존재하게 되었다는 점입니다.

프레임워크 난립의 역사

이 혼란을 이해하려면 짧은 역사 여행이 필요합니다. Windows 앱 개발의 기본은 오랫동안 Win32 API였습니다. C/C++로 직접 Windows API를 호출하는 방식으로, 강력하지만 개발 생산성이 낮았죠. 이후 MFC(Microsoft Foundation Classes)가 이를 감싸는 C++ 래퍼로 등장했고, .NET 시대에는 WinForms가 빠른 데스크톱 앱 개발의 표준이 되었습니다.

2006년에는 WPF(Windows Presentation Foundation)가 등장해 XAML 기반의 선언적 UI와 하드웨어 가속 렌더링을 제공했습니다. WPF는 상당히 성숙한 프레임워크였고, 많은 기업용 애플리케이션이 WPF로 만들어졌습니다.

그런데 Windows 8 시대에 Microsoft는 갑자기 방향을 틀어 UWP(Universal Windows Platform)를 밀기 시작합니다. UWP는 샌드박스 환경에서 동작하고, Microsoft Store를 통해 배포하며, PC, 태블릿, Xbox, HoloLens 등 모든 Windows 디바이스에서 동작하는 "유니버설" 앱을 만든다는 비전이었습니다. 하지만 현실은 달랐습니다. 샌드박스 제약 때문에 기존 Win32 앱이 할 수 있는 많은 작업을 UWP에서는 할 수 없었고, Microsoft Store의 생태계도 활성화되지 않았습니다.

결국 Microsoft는 UWP의 실패를 인정하듯 WinUI 3를 발표합니다. WinUI 3는 UWP의 UI 레이어를 Win32 앱에서도 사용할 수 있게 분리한 것인데, 이것 역시 순탄치 않았습니다. 출시 초기에는 기본적인 기능조차 빠져 있었고, 버그가 많았으며, 업데이트 속도도 느렸습니다. 여기에 .NET MAUI까지 크로스플랫폼 옵션으로 추가되면서, 개발자는 WinForms, WPF, UWP, WinUI 3, MAUI 중 무엇을 선택해야 할지 더욱 혼란스러워졌습니다.

기존 방식과 무엇이 다른가 — 문제의 핵심

이 상황이 단순한 "선택지가 많다"는 불편함을 넘어서 심각한 이유가 있습니다. 첫째, 기술 간 호환성이 부족합니다. WPF에서 만든 커스텀 컨트롤을 WinUI 3에서 재사용할 수 없고, UWP 앱을 WinUI 3로 마이그레이션하는 것도 상당한 작업을 요구합니다. 둘째, Microsoft 자체도 일관되게 사용하지 않습니다. Windows의 설정 앱, 파일 탐색기, 그리고 각종 내장 앱들이 서로 다른 UI 프레임워크로 만들어져 있어서, 같은 OS 안에서도 디자인 언어가 제각각입니다.

셋째, 그리고 가장 중요한 것은 투자의 불확실성입니다. 어떤 프레임워크에 팀의 시간과 역량을 투자했는데, Microsoft가 몇 년 뒤에 그 기술의 지원을 사실상 중단해버리면 어떻게 될까요? UWP에 올인했던 팀들이 실제로 이런 경험을 했고, 이런 전례가 있기 때문에 새로운 기술을 선택하는 것 자체가 리스크가 됩니다.

대안은 있는가 — 업계 맥락

이런 혼란 속에서 많은 개발자들이 택하는 현실적인 대안이 있습니다. 바로 Electron이나 Tauri 같은 웹 기반 데스크톱 프레임워크입니다. 웹 기술(HTML, CSS, JavaScript/TypeScript)로 UI를 만들고 이를 데스크톱 앱으로 패키징하는 방식이죠. VS Code, Slack, Discord 같은 대형 앱들이 이미 Electron으로 만들어져 있다는 것은, "네이티브"가 반드시 최선이 아님을 시장이 증명한 셈입니다.

또한 Flutter, Qt, Avalonia 같은 크로스플랫폼 네이티브 프레임워크도 대안으로 떠오르고 있습니다. 특히 Avalonia는 WPF와 유사한 XAML 기반 API를 제공하면서 Windows, macOS, Linux를 모두 지원해서, WPF 경험이 있는 .NET 개발자들에게 주목받고 있습니다.

한국 개발자에게 주는 시사점

한국에서도 기업용 데스크톱 애플리케이션 수요는 여전히 상당합니다. 금융권의 트레이딩 툴, 제조업의 MES 시스템, 관공서의 각종 업무 시스템 등이 Windows 네이티브 앱으로 운영되고 있죠. 이런 환경에서 "다음 프로젝트는 어떤 프레임워크로 할 것인가"는 매우 현실적인 질문입니다.

현시점에서 가장 안전한 선택은 아마도 WPF일 것입니다. 가장 성숙하고, .NET 생태계 안에서 장기 지원이 보장되어 있으며, 레퍼런스와 커뮤니티 자원이 풍부합니다. 새로 시작하는 프로젝트라면 Tauri나 Electron도 충분히 고려할 만하고, 크로스플랫폼이 필요하다면 Avalonia나 Flutter를 살펴볼 가치가 있습니다.

마무리

Windows 네이티브 앱 개발의 혼란은 Microsoft가 모바일 시대의 전략적 실패를 데스크톱 프레임워크로 만회하려다 오히려 기존 생태계마저 파편화시킨 결과라고 볼 수 있습니다. 개발자로서 우리가 할 수 있는 것은, 특정 벤더의 로드맵에 지나치게 의존하지 않는 아키텍처를 설계하는 것일지도 모릅니다.

여러분의 팀에서는 Windows 데스크톱 앱을 어떤 기술로 만들고 있나요? 프레임워크 선택에서 가장 중요하게 보는 기준은 무엇인지 이야기 나눠봅시다.