WinUI 3 란 무엇일까? (리유니언 프로젝트 / Windows 앱 SDK )

WinUI

 

 

서론

우선 WinUI 3을 말하기 위해선 WinUI 2 를 말해야 할 것 같다.

아마도 WinUI 2 가 뭔지도 모르는 사람이 대다수일 듯 하다.

왜냐면 그만큼 인기가 ㅈ도 없거든.

 

WinUI 2 는 UWP 기반으로 돌아간다.

UWP 는 뭔가? 하면

Windows 10 을 이용하면서 이런 창을 본 적이 있을거다.

좌측의 프로그램 제거와 우측의 프로그램 제거의 차이가 뭘까?

좌측은 WinUI 2 (UWP), 우측은 Win32 기반으로 개발된 프로그램들 이다.
(일부 Win32 프로그램들이 좌측에도 '등록' 되어 있긴 하다.)

 

대표적인 예로 3D 그림판은 UWP 로 개발되었고,

2D 그림판은 Win32 로 개발되었다.
(2024년 현재는 2D 그림판도 WinUI 3 로 재설계 되었다.)

 

MS 에서는 WinUI 2 를 이와 같이 설명한다.

 

WinUI 2 is a library of controls and styles currently available for use in any UWP app

 

즉 모든 UWP 앱에서 사용가능한 일종의 컨트롤, 스타일 집합 라이브러리인 셈이다.

 

 

 

 

 

WinUI 2

 

그런데 현재, 주변을 살펴보면 UWP 을 개발하는 곳이 있나?

우리 회사는 물론, 지인 개발자들에게 물어봐도 UWP 로 개발하는곳은 없었다.

내가 실제로 사용하고 있는 UWP 앱도 전체에서 2-3% 정도가 전부이다.

 

아래 표를 참고해 보자

MFC, WinForms, WPF 는 현업에서 빈번히 되지만 UWP, WinUI 2 는 못 들어봤을 것이다.

그도 그럴것이 치명적인 이유가 있다.

WinUI 2 는 UWP 앱밖에 개발하지 못 하기 때문이다.

 

WinUI 2.x can be used in UWP applications
 and incorporated into new or existing desktop applications using XAML Islands.

 

사용자와 개발자들은 굳이? 라는 생각을 할 수 밖에 없다.

잘 돌아가는 Win32 를 굳이 버릴 필요가 없었던 것이다.

압도적인 장점이 있는것도 아니니 말이다.

 

 

 

 

 

WinUI 3

 

하지만 WinUI 3 에 와서는 상황이 좀 달라졌다.

WinUI 3 is the path forward for all Windows apps
you can use it as the UI layer on your native UWP or Win32 app

 

WinUI 3 를 이용해서 Win32 앱을 빌드할 수 있게 되었으며,

무려 C++ 을 지원한다.

C#은 당연히 지원하고..

 

C++ 에서 MFC를 대체할 디자이너가 Visual Studio 에 탑재될 날이 머지 않았다.

비록 C# WinForm 처럼 쉽고 간편한 형태는 아니겠지만.

WPF(xaml) 정도의 디자인 생산성을 보여줄 수 있을 것으로 생각된다.

 

기존에 존재했던 MFC, Winform, WPF 가 이른 시일 내에 죽지는 않을것이다.

하지만 WinUI 3 의 등장으로 WinUI 2 는 즉사 할 것으로 생각된다.

WinUI 3 의 결함이 심각하지만 않다면 굳이 WinUI 2 를 사용해야될 이유가 없으며,

내 생각엔 성공적으로 release 된다면

WPF의 영역 도 WinUI 3 로 대체되지 않을까 예측한다

 

다시한번 위의 표를 살펴보면

나는 최종적으로

WinUI 3, WinForms

두가지만 살아남게 되지 않을까 생각한다.

 

MFC - 지금도 살아는 있는데, 매우 보수적인 영역에서 사용됨.

WinForms - 디자인이 중요하지 않은 GUI 프로그램 개발에 사용됨.

WPF - 많은부분이 WinUI 3 와 겹치기에, 지원이 차차 줄어들듯

WinUI 2 - WinUI 3 가 버전 2 를 포함하고 있음, 마찬가지로 지원이 줄어들듯.

 

 

 

 

굳이 왜써?

 

디자인 때문이라고 생각하는 사람들도 있을것이다.

WinForm 이나 MFC 로 할 수 있는 디자인은 한정적이기 때문이다.

 

결론부터 말하자면

디자인 때문만은 아니다.

디자인은 부수적인 요소일 뿐이다.

 

이전부터 Microsoft 는 Apple 처럼 독자적인 견고한 생태계를 만들고 싶어했지만.

 

Win32 가 지원하는 압도적인 하위호환성으로 인해 그것이 빈번히 저지되어 왔다.

Windows 1.0 에서 제작된 프로그램이 Windows 10 에서도 실행된다.

 

Win32 는 굉장히 이전에 설계된 구조다.

내가 MS 개발자라면 이 압도적인 하위 호환성을 매번 유지하느라 골머리가 썩어날 것이다.

(특히 보안부분에서)

썩은 가지는 쳐 버릴 필요가 있다, 언제까지고 Win32 를 천년만년 사용할 순 없다.

 

MS도 같은 의견이였을 것이다.

Xbox, HoloLens, Surface Hub, IoT 등에서 Win32 를 그대로 사용할 순 없었기에

새로운 구조를 만든것이 UWP 이다.

 

거기에 생각을 넓혀

C# .Net 생태계를 기반으로 모든 영역에서 크로스 플랫폼까지 꿈꾸는듯 하다. (해당 프로젝트를 .NET MAUI 라고 한다)

※ 이전에도 크로스 플랫폼은 지원되긴 했으나. GUI 프로그래밍은 매우 불편했었다.

중요한건 GUI 프로그래밍을 xaml 기반으로 지원할 거라는것이 WinUI 3 / MAUI 의 핵심이다.

 

IOS, MAC, android, Windows, Linux 를 지원하면 사실상 현존하는 모든 OS 를 지원하는 것이다.

더이상 운영체제로는 '큰 돈' 을 벌지 못한다.

다른 운영체제에 종속되어 있는 사용자를 Windows '플랫폼' 으로 끌고 들어와야 돈을 벌 수 있다.

MS가 사용자에게 친숙한 기업이 되면

'AWS' 쓸거 'Azure' 한번 살펴보게 되고

'Samsung' 노트북 살거 'Surface' 한번 살펴보게 된다.

거기다 다른 운영체제 프로그램을 Visual Studio 로 개발할 수 있게 한다면 추가 수익이 따라올 것이다.

 

MS 의 본래 계획은 WinUI 2 를 토대로 차차 UWP 로 바꿔 나가는 것이였겠지만,

개발자들은 Win32 프로그램만 개발하였다.

사용자들도 굳이 잘되는 Win32 냅두고 생소한 UWP 를 찾지 않았다.

 

이러다간 WinUI 2.0 프로젝트 자체가 엎어질 염려가 있었기에 Microsoft 는 WinUI 3.0 을 개발하여

Win32 를 포괄하는 방향으로 선회 한 것이다.

그래도 여전히 MS의 최종 목표는 Win32 를 없애는 것일 거라고 추측된다.

단지 좀더 '친근하게' UWP 를 어필하는 전략이 WinUI 3 라고 생각한다.

 

 

 

MS의 부가적인 목표

현재의 Windows 라이브러리 체계는 좀 지저분하다.

동적 라이브러리 (*.dll, *.lib)

정적 라이브러리 (*.lib)

COM 라이브러리 (1234-12-1234...)

등등 모두 장단점이 있는데 아마도 MS는 앞으로 이런 라이브러리 지원 형태를 모두 없애고

 

패키지 형태로 이를 배포할 생각인것 같다. (마치 Nuget 과 같이)

아마 WinUI 3.0 C++ 레벨에서는 동적, 정적 라이브러리 사용을 막는건 힘들어 보이지만

최소한 WinUI 3.0 .Net Core 에서는 위 라이브러리 사용의 일반화를 줄이려고 노력하는듯 하다.

 

 

 

지금 개발해 볼수 있나?

 

이렇게 WinUI 3 를 제작하는 프로젝트를 = 리유니온 프로젝트라고 지칭한다.

리유니온 프로젝트를 Visual Studio 2019 에 설치하면 관련 프로그램을 개발해 볼 수 있다.

WinUI 3 Project Reunion 0.8 Preview (April 2021) - Windows apps

하지만, 개인적으로 추천하지 않는다.

아직 불안한점이 많다.

아무것도 손대지 않은 기본 템플릿 에서부터 경고 메세지를 뿜고,

군대군대 #pragma warning restore 로 경고 복구구문이 덧데어져 있고

C++ 로 프로젝트 생성시 intellisense 가 적용되지 않아

자동완성 기능이나, 선언부 참조 등이 아예 먹통이 되기도 한다.

 

아직은 많이 부족하다.

 

해외 기사, 리뷰들을 몇개 뒤적여 본 결과

21H2 에서 정식 출시될 것 같다고 추측하는 글들이 많았다.

 

21H2 == Windows 11 이다.

가능하면 Windows 11 정식 출시 이후 / 1.0 버전이 정식적으로 출시되면 개발해 보는것을 추천한다.

 

 

추가사항

2021 - 11 - 29 

 

Stable channel release notes for the Windows App SDK - Windows apps

 

얼마전에 AppSDK 1.0 버전이 추가 되었다.

아직은 조금 불안정한 모습이나, Windows 11 버전에서 Visual Studio 2022 기반으로 출시된

공식 안정 버전이므로 참고하길 바란다.

 

위에서 언급한대로 C++, C# 을 지원한다.

 

 

 

2022 - 01 - 08

 

Discussion: WinUI 3.0 XAML Designer · Issue #5917 · microsoft/microsoft-ui-xaml

WinUI 3.0 에서 현재 디자이너가 동작하지 않는다.

토론 내용으로 볼 때, 이는 MS의 의도인듯 하다.

 

C# 10.0 에서 새로이 추가된 Hot-reload 기능을 이용하여 미세 조정하는걸 지원한다는 이유로 퉁치려는 듯 한데

굉장히 멍청한 방법이라고 생각한다.

Blend 에서도 지원하지 않는건 매한가지이기에,

 

차라리 UWP 에서 디자인 -> WinUI 이식과 같은 방법을 사용하는것이

XAML 에 익숙하지 않은 사람들에게 훨신 도움이 될 것이다.

 

결론적으로 아직까지는 WinUI 3.0 을 통해 신규 프로젝트를 진행하는것을 극구 말리고 싶다.

 

 

2023 - 04 - 28

현재로서도 WinUI 3 의 Designer 는 지원되지 않다.

Where is the designer view in WinUI 3? - Microsoft Q&A

재미있는 점은 여전히 xaml 형태이기에 다른 형태(UWP, WPF)로 해당 파일을 열면

Designer 를 이용할 수 있다는 점이다.

솔직히 Microsoft 가 왜 이런 정책 고수하는지 모르겠습니다.

 

MAUI 의 경우 멀티플랫폼 지원 문제로 인해 아예 Designer 를 지원하지 않는다고 발표 하였다.

XAML - .NET MAUI

 

There is no visual designer for producing XAML in .NET MAUI apps. 
All XAML must be hand-written, 
but you can use XAML hot reload to view your UI as you edit it.

 

여전히 백엔드 개발자 혼자서 WinUI 3 프로젝트를 진행하는것은 그다지 추천하지 않는다.

 

 

2023 - 05 - 05

WinUI 3 을 통해 개발해 보려고 한번 이것저것 시도 해 봤다.

경험해 본 봐론 확실히 WPF나 차라리 UWP(이미 죽긴했다)를 쓰는게 아직까진 더 좋다고 느낀다.

Properties 까지는 잘 보이는 모습을 보이지만 기존 WPF, Winform 기반에서 존재했던

Event UI가 보이지 않는다.

물론 해당 기능이 없다고  개발이 불가능한것은 아니지만 상당히 불편한것이 사실이다.

 

추가로 개선점도 보이는데, Hot-Reload 를 일일히 누르지 않아도 UI 변경이 앱에 즉각적으로 적용된다.

이정도면 사실 디자이너와 차이가 없을정도의 생산성이다.

추가로 안정성도 초창기에 비하면 크게 향상되었다.

 

 

2024 - 09 - 22

어느정도 안정되었겠지~ 생각하고 WPF로 작성한 프로젝트를 WinUI 3로 이전하려 시도하였다.

안정성은 이제 꽤 뛰어난 편이고(물론 Winform, WPF 보다는 떨어진다.)

 

이전에는 Hot-Reload 버튼을 계속 눌러줘서 UI를 갱신해야 했다면,

Designer가 없는것도 Hot-Reload의 즉각적인 반응으로 인해 납득할만한 수준이 되었다.
(한번 써 보시면 왜 제가 '납득할만' 하다는지 이해하실겁니다.)

App.xaml에 전역적인 Style을 지정하는게 아닌이상(이러면 오류 발생)

개별 Page 별로 수정하는것은 안정성 높게 잘 적용된다.

 

하지만 놀라운 사실을 발견하였다.

From the dotnet community on Reddit

Proposal: Window Width/Height in Desktop · Issue #2731 · microsoft/microsoft-ui-xaml

바로 WinUI 3 단에서는 Window Size를 Xaml 단에서 변경할 수 없다는 사실이다.

그럼 코드 단에서는 구현할 수 있나? 하고 Github 에서 문제를 해결하신 분들의 코드를 찾아보니

m_window = new MainWindowPage();

IntPtr hWnd = WinRT.Interop.WindowNative.GetWindowHandle(m_window);
WindowId windowId = Win32Interop.GetWindowIdFromWindow(hWnd);
AppWindow appWindow = AppWindow.GetFromWindowId(windowId);

appWindow.Resize(new Windows.Graphics.SizeInt32(800, 600));

m_window.Activate();

C# 이나 C++을 좀 다뤄본 사람들은 이 코드가 뭘 의미하는지 알것이다.

LowLevel 단에서 Window Handle을 가져와서 사이즈를 강제로 변경시키는 행위이다.

 

물론 Keyboard Global Hook을 구현할 때와 같이,

개발시 OS의 핸들을 얻을 상황은 많이 발생한다.

그런데 고작 Application 단의 프로그램 '창 크기' 하나 바꾸기 위해

Github 커뮤니티 내부에서 이런 방식을 사용할 정도라면

이건 창의 사이즈를 바꾸는 추상화된 API 자체가 존재하지 않는다는 의미이다.