Windows 네이티브 앱 개발은 혼란스러운 상태

4 days ago 6

Windows용 유틸리티 앱 개발 경험을 통해 네이티브 앱 개발 환경의 복잡성과 비효율성이 드러남
Win32에서 WinUI 3까지 이어지는 UI 프레임워크의 잦은 세대 교체로 인해 일관된 기술 기반 유지가 어려움
최신 Windows App SDK는 필수 기능 미지원, P/Invoke 의존, 불완전한 C# 상호운용성 등으로 실용성이 낮음
배포 과정에서도 MSIX 서명 비용, Store 등록 거절, .NET 런타임 의존성 등 현실적 제약이 큼
결과적으로 많은 개발자가 Electron·Tauri 같은 웹 기반 프레임워크로 이동하며, Microsoft가 네이티브 개발을 우선하지 않는 상황임

Windows 네이티브 앱 개발의 혼란

초기에는 C 기반 Win32 API가 중심이었으며, 이후 MFC가 객체지향적 추상화를 제공
2002년 .NET 1.0과 함께 C# 및 Windows Forms가 등장해 메모리 관리와 현대적 언어 기반을 제공
2006년 WPF가 도입되어 XAML 기반 UI와 GPU 렌더링을 지원
2012년 WinRT, 2015년 UWP로 이어지며 샌드박스형 앱 모델과 Microsoft Store 배포를 목표로 함
2021년 Windows App SDK와 WinUI 3이 등장해 WinRT/UWP 기능을 통합했으나 또 다른 API 계층을 추가
UI 프레임워크의 진화 경로는 다음과 같음 Win32 → MFC → WinForms → WPF → WinRT XAML → UWP XAML → WinUI 3

WinUI 3 앱 개발에는 C++, C#/XAML (Framework-dependent), C#/XAML (.NET AOT) 세 가지 선택지가 존재
- C++은 성능이 좋지만 메모리 안전성 부족
- Framework-dependent 방식은 Windows에 최신 .NET(10)이 기본 포함되지 않아 사용자 설치가 필요
- .NET AOT는 런타임 전체를 바이너리에 포함, 단순 앱도 9MiB 이상으로 커짐
Rust 바인딩 프로젝트는 중단된 상태
배포는 MSIX 패키징이 권장되지만,
- 코드 서명 인증서 비용(연 $200~300) 이 높고
- 서명 없는 사이드로딩은 PowerShell 명령 필요 등 사용자 경험이 나쁨
- Microsoft Store 등록도 “지속적 가치 부족” 사유로 거절됨
.NET을 Windows Update로 배포하거나, MSIX 종속 패키지로 제공하는 개선책이 제시됨
현재의 Windows 개발 체계는 “절반만 완성된 상태”로 평가됨

현재 Microsoft는 네이티브 앱 개발을 우선하지 않음
- 관련 이슈 트래커는 버그와 미응답 보고로 가득
- Windows App SDK의 변경 로그는 머신러닝 API 추가 중심
- Visual Studio Code, Outlook, Start 메뉴 등 주요 앱조차 웹 기술 기반으로 작성
커뮤니티는 Avalonia, Uno Platform 같은 서드파티 UI 프레임워크로 이동 중
- 이들은 WPF 철학을 계승하고 크로스플랫폼 지원을 강화
그러나 현재로서는 Electron이나 Tauri 같은 웹 기반 프레임워크가 더 현실적 선택
- TypeScript/React/CSS 조합이 C#/XAML보다 생산적이며
- Win32 API 접근도 가능
- Tauri는시스템 WebView를 활용해Chromium 번들 불필요
  - WebView2 런타임은 4주마다 업데이트, 반면 시스템 .NET은 4.8.1에 고정
  - Microsoft가 Windows App SDK 개선과 배포 체계 단순화를 추진한다면 회복 가능성이 있으나
  - 현재로서는 대부분의 개발자가 기대하지 않음
  - 결론적으로 “웹 스택을 선택하겠다”는 판단으로 마무리됨