Microsoft, Windows 11의 UI 프레임워크인 WinUI를 오픈소스로 전환 작업중
(neowin.net)- Microsoft가 Windows 11의 사용자 인터페이스 프레임워크인 WinUI의 오픈소스화를 위해 단계적 계획을 발표함
- WinUI는 복잡한 구조와 많은 독점 코드로 인해 즉각적인 공개가 불가능함( 공유 가능한 부분과 그렇지 않은 부분을 구분하는 작업이 필요함)
- 오픈소스화는 네 단계로 진행될 예정
- 1단계: 미러 빈도 증가 : WASDK 1.8 배포(8월말) 이후 내부 커밋을 더 자주 GitHub와 동기화하여 투명성 및 개발 진행 상황을 공유함
- 2단계: 외부 개발자 로컬 빌드 : 외부 개발자가 직접 코드를 클론받아 로컬에서 빌드할 수 있게 되며, 설정 및 의존성 관련 문서도 제공됨
- 3단계: 외부 기여 및 테스트: 커뮤니티 기여자들이 Pull Request 제출 및 로컬 테스트가 가능해지고, 내부 의존성 정리와 테스트 인프라 공개도 이뤄질 예정임
- 4단계: GitHub 중심의 개발 체계 전환 : 최종적으로 GitHub이 주요 개발, 이슈 관리, 커뮤니티 소통의 중심이 되며 내부 미러 시스템이 단계적으로 폐지됨
- WinUI의 오픈소스 로드맵은 GitHub 프로젝트 보드에서 공개적으로 관리되고 있음
- 개발자 및 사용자들은 피드백, 명확한 이슈 작성, 기존 의견에 대한 투표 등을 통해 WinUI 발전에 기여할 수 있음
COM도 Webview도 싫어요... 좀 쓸만한 GUI가 있으면 좋겠어요.
지금까지 Windows용 UI로 써봤던것 중에 가장 마음에 드는건 Qt4였습니다. Qt5부터는 뭔가 좀 느낌이 많이 달라졌더군요.
Hacker News 의견
-
Windows의 네이티브 UI 기술의 미래에 대해 걱정임
운영체제 개발자들은 보통 스스로 사용하는 제품을 통해 잘 작동하고 일관된 네이티브 앱을 만들어왔음
하지만 Windows 11에서는 이와 정반대가 일어남
Windows 10부터 최소한 잘 동작하는 기본 메일·캘린더 앱이 있었지만, Windows 11 최신 업데이트에서는 이런 앱이 빠지고, 느린 WebView 래퍼로 대체되어 실행하는 데 몇 초나 걸림-
WinUI 커뮤니티 콜을 보면, 신입 직원 대부분이 Windows 경험이 전혀 없고, 경영진도 이에 대해 신경을 쓰지 않아 기본기를 제대로 익히지 못하는 상황임
Windows 개발자라면 당연히 알만한 질문에 대해 답변도 못하고, 왜 질문이 나왔는지 이해 못하는 표정임
이런 요인 때문에 Windows 11 여기저기에 Webview2 인스턴스가 넘쳐나게 됨 -
Windows 11의 UI 문제는 신규 앱·기능에 너무 집중하고, 예전 도구들은 최신화하지 않는다고 느껴짐
예를 들어, 제어판은 Windows 7 때부터 거의 같은 스킨만 입혀져 남아있음
더 깊이 파고들면 마치 호머 심슨 등에 클립을 붙인 밈처럼 구석구석 구식 툴이 숨어있음
겉보기만 새로울 뿐, 사용하다 보면 한계가 빨리 드러남 -
언젠가 MSO(Office)를 Dart와 WASM 같은 기술로 완전히 새로 짤 수도 있을 것 같음
네이티브 툴킷과 완전히 독립된 형태로, Excel의 모든 기능을 재현하고 O365 프리미엄 플랜 형태로 어디서나 접근 가능하게 할 수도 있을 거라 생각함
결국, ChromeOS처럼 변모해 잠금/로그인 화면 같은 곳만 간단한 네이티브 UI가 필요하고, 나머지는 가볍게 처리할지도 모름 -
Microsoft 내부의 권력투쟁과 가혹한 사내정치를 이해하면 이런 변화가 왜 발생하는지 알 수 있음
부서들끼리 서로 우위를 차지하려고 경쟁 중인 상태임 -
Windows에는 최소 10개의 각기 다른 UI 프레임워크가 뒤섞여 있는 느낌임
Windows 11은 마치 자연사박물관 구경하는 느낌
MSC처럼 완전히 Windows 2000 시절 디자인에 머문 앱도 있고, 메트로 스타일 영향으로 투박하고 원색적인 UI도 보임
최신 Win11 스타일은 그럴듯해 보이지만, 실제로는 '돼지에게 립스틱 바르기'처럼 보여짐
오른쪽 클릭 메뉴가 대표적 예시로, 예뻐 보이지만 실제로는 기능이 부족해서 '더 보기' 버튼을 눌러야 예전 스타일과 더 많은 기능을 볼 수 있음
전체적으로 뒤죽박죽임
-
-
Microsoft의 "Microsoft 목표와의 정렬", "리소스 배분을 신중히 한다" 같은 발표에서 진정성을 느낄 수 없음
결국 프레임워크를 외부에 맡기고, 열정만 가득한 외부 개발자들이 유지관리에 힘써주길 바라며 리소스를 빼는 정책으로 보임-
"열정 있는 패배자"라는 표현은 너무 부정적임
내가 Win11 UI에 관심이 없거나, 이번 오픈소스화가 단순히 비용절감용이라는 냉소적 시각에 공감한다 해도
이 일을 이어가려 하는 사람들에게는 나름의 존중을 표하고 싶음 -
명확히 말하면, 이건 "보장된 지원 없음, 보안 버그 외에는 추가 업데이트 계획 없음, 알아서 쓰시오"라는 대기업 화법임
-
농담처럼 "Apache Windows 언제 나옴" 말하고 싶어짐
진지하게 말하면, 이제 데스크탑 UI 툴킷은 더 이상 경쟁력이나 진입장벽이 아님
Windows에만 3~4가지 다른 스타일이 공식 유통되고 있기 때문임
하지만 보안·안정성은 여전히 Windows가 기업, 금융, 관공서에서 살아남기 위해 반드시 필요한 요소임 -
다른 회사의 UI 프레임워크를 오픈할 경우 이해가 가는 부분이 있음
예를 들어 Atlassian이나 AWS의 프레임워크는 Jira/AWS에서 쓰니 B2B SaaS에도 써볼 만하다고 느낌
그런데 이 프레임워크는 왜 써야 할지 모르겠음
정말 Windows 네이티브 앱만 만드려는 게 아니라면 이미 더 나은 선택지가 있다고 생각함 -
WinUI는 실패했다고 생각함
-
-
Windows 개발 커뮤니티에서 WinUI에 신경 쓰는 이들은 거의 없고, WinRT/UWP에 이미 투자한 뒤 빠져나올 수 없는 개발자들만 얽매여 있음
Windows 8 이후로 너무 많은 다리가 끊겨서, 커뮤니티 신뢰를 잃음
사실상 Microsoft가 문제를 고치는 대신 커뮤니티에 넘겨버리려 한다는 뜻으로 보임-
DevExpress, Progress Telerik 같은 업체들도 자체적으로 WinUI 컨트롤 개발에 투자를 안 하고 있으니
이들도 WinUI의 미래를 믿지 않는다는 신호임
현시점에서 기업용 앱은 WinForms, WPF 정도만이 현실적인 대안임
실제로 WinUI3로 만들어져서 현업에서 쓰는 앱은 본 적이 없음 -
솔직히 말하면, 누가 이제 Microsoft의 어떤 UI 프레임워크든 진지하게 쓸까 싶음
예전에도 써오던 프레임워크는 언제나 마무리도 안 되고, 반쯤 만든 상태로 버려둔 채
새롭게 번쩍거리는 프레임워크에 눈을 돌리기 때문에 결국 다 잊히게 됨
오히려 오픈소스 크로스 플랫폼 프레임워크가 기본기와 기능면에서 훨씬 완성도가 높고, 유지보수도 잘 됨
이번 WinUI도 결국 잊혀지고 외면받은 또 하나의 UWP 신세일 뿐임
-
-
Windows에 몇 개의 UI 프레임워크가 있는지 이제 세기도 힘든데, 너무 혼란스럽다고 느낌
오픈소스화해서 뭘 기대하는 건지 의문임
단순히 열려있다는 이미지 연출용인지, 아니면 Windows 타겟팅 개발자들에게 실질적인 이점이 있는 건지 궁금함-
WinUI는 UWP에서 발전한 버전이고, UWP 자체는 WinRT의 진화임
WinUI의 의도는 명확하고, 오랜 시간 발전해 온 기술임(지금은 WinUI 3 버전)
MAUI는 경쟁 제품이라기보다는 크로스 플랫폼용
그래도 OS 전체, 특히 관리 도구까지 WinUI로 재구성하지 않으면 장기적 신뢰는 쉽지 않음 -
위에 나온 수많은 약어와 설명을 보고 처음에는 풍자라고 생각함
WinUI, UWP, WinRT, XAML, Avalon, WPF, Project Reunion, Win2D, MFC, wxWidgets, Qt 등
워낙 많은 버전과 프레임워크 이름이 뒤섞여 설명만 들어도 길고 헷갈림 -
아마 Microsoft는 또 언제나처럼 새로운 트렌드(이젠 AI!)에 집중하면서
예전 기술은 큰 반발 없이 정리할 방법을 찾는 중 아닐지
실제로 반발하는 사람도 소수에 불과할 것 같음 -
실제로 Windows에는 UI 프레임워크가 세 가지고, 이 중 두 개만 실질적으로 살아있음
나머지는 Win32/네이티브, WPF/Managed 이 두 가지 라인의 반복된 진화에 지나지 않음
WinUI3는 둘의 간극을 메우려고 나온 것임 -
장기적으로 보면 MFC가 여전히 가장 오래 살아남을 수 있는 선택임
지금은 업데이트가 멈췄지만 앞으로 20년은 거뜬히 살아있을 거임
-
-
Microsoft가 차라리 WPF를 계속 발전시켜줬으면 함
다양한 프로젝트에 오랫동안 써왔고, 러닝커브는 있지만 Data Binding, ViewModel, XAML 모두 지금도 만족스럽게 씀
다만 WPF가 완벽해지려면 몇 가지 개선이 필요함
최근 Microsoft 새 프레임워크나 오픈소스(Avalonia, Uno 등)도 써봤지만, 샘플이 돌아가지도 않거나 개발 방식이 잘 맞지 않아
결국 다시 익숙한 WPF로 돌아가게 됨
WPF의 가장 큰 개선 아이디어는 Data Binding 시스템을 런타임 Reflection이 아니라 .NET 컴파일 타임 코드 생성으로 만드는 것임
이 방식이면 진짜 AOT 빌드가 가능하고, 성능도 비약적으로 좋아질 것이며, XAML 타입 안정성, 크로스 플랫폼 지원 등 장점도 많음
직접 오픈소스로 해보려 했지만, 시간이 부족하고 할 일이 너무 많음-
이야기한 두 번째 단락이 Avalonia에 딱 맞음
Avalonia는 이미 AOT, 컴파일 타임 바인딩 오류, 크로스 플랫폼 기능을 지원함
최근 업데이트를 한동안 안 보셨다면 Avalonia compile-time data binding docs와 XamlX 프로젝트 참고 바람 -
이 방식이면 어셈블리 트리밍도 가능해짐
독립 배포를 하려면 지금은 .NET 라이브러리가 200MB이상 붙지만, 이 방법이면 훨씬 줄일 수 있음
-
-
예전에 WinUI3를 평가해봤을 때, 개발자 경험이 너무 나빴음
배포하고자 하는 앱을 디버깅하려면 시스템에 실제로 설치해야 했고
그러다 보니 시작 메뉴에 쓸데없는 항목들이 많이 들어가고, 레지스트리도 지저분해짐
심지어 예제 코드에서 버튼을 클릭하자마자 앱이 바로 크래시났음
난 Windows 앱 개발할 때는 여전히 Win32+WTL로 만듦- 앱을 직접 설치해야만 디버깅이 가능했던 건 "패키지형" 앱을 선택했기 때문임
기능 및 권한 처리가 필요해서 그렇게 되어 있음
macOS도 비슷하게 패키지 앱이면 설치해야하고, Launchpad에 안 보여도 Spotlight로 검색 가능함
- 앱을 직접 설치해야만 디버깅이 가능했던 건 "패키지형" 앱을 선택했기 때문임
-
많은 사람들이 지적하듯, Windows용 UI 프레임워크는 오랜 기간 동안 제대로 정리되지 않고 혼란만 가중됨
안타깝지만 크로스 플랫폼 오픈소스 쪽도 마찬가지임
GTK도 한동안 엉망이었고, Qt는 기능은 많지만 프로페셔널 용도에서 라이선스 체계가 너무 부담스러움
(Nokia 시절 희망도 MS의 엘롭, 이후 Qt 소유주 교체 등 때문에 사라짐)
특정 분야엔 Dear Imgui 같은 괜찮은 솔루션도 있지만,
전체적으로 네이티브, 크로스플랫폼 UI/위젯 프레임워크 중에 퍼미시브 라이선스·네이티브 컴파일·좋은 위젯 구성·Vulkan 3D 렌더링까지 지원하는 대안이 거의 없음- Electron이나 React Native가 비판 받는 이유는 "웹이 별로니까" 라는 정서 때문인데,
정작 플랫폼 유연성을 원한다면 사실상 대체제가 거의 없다는 현실을 간과함
Microsoft가 이 영역에서 진짜 의미 있는 제품을 만들 수 있었을 텐데, 시도 자체가 너무 미지근했고 그래서 제대로 된 결과가 나온 적이 없음
- Electron이나 React Native가 비판 받는 이유는 "웹이 별로니까" 라는 정서 때문인데,
-
Windows 11에서 네이티브 수직 작업표시줄이 다시 추가됐으면 좋겠음
이 기능은 Windows 98부터 있었던 건데 11에서 사라짐
Windhawk(수평 taskbar 강제)나 StartAllBack(Windows 10 코드 복원형) 같은 서드파티 툴이 있지만 완벽하지 않음-
UI 프레임워크를 오픈소스한다고 해서 작업표시줄 기능이 확장되지는 않을 것임
이런 영역에서의 외부 기여는 UI 프레임워크가 아니라 작업표시줄 자체(즉 explorer.exe)가 오픈돼야만 가능함 -
참고로 최초는 Windows 95 시절부터 수직 작업표시줄이 옵션에 있었음
-
작업표시줄 기능은 explorer.exe 소속 기능임
지금 논의되는 오픈소스 발표는 explorer와는 무관함 -
Windows 팀이 WinUI로 네이티브 데스크톱 UI를 진짜 만들고 있는지 의문임
-
-
Windows용 UI 작업은 요즘 Win32, GDI, DirectDraw 등을 활용해서 진행함
CsWin32, 최신 C# (ref returns) 덕분에 예전보다 접근성이 많이 좋아짐
예전엔 보통 C++로 따로 프로젝트를 구성해야 했지만, 이제 네이티브메서드.txt에 필요한 함수만 적어주면 코드젠이 알아서 처리함
Win32는 확실히 다른 UI 프레임워크보다 더 로우레벨이긴 하지만, 반대로 Microsoft가 손대거나 폐기하기도 어려움
장기적으로 보면 이런 API만큼 안정적으로 살아남은 것은 없음
웹 플랫폼도 장기적 관점에서는 비교조차 안 됨-
그래도 많은 부분에서 여전히 C++가 필요함
Windows 팀의 COM에 대한 고집 때문임
Windows Runtime Components가 .NET 생태계 수준을 올릴 수 있는 기회였지만 놓쳐버림
셸 확장·컨텍스트 메뉴 확장 등은 C++로 해야 하고, 이걸 .NET에서 하려면 결국 C++ 스텁을 두고 .NET 프로세스 호출하는 식이 됨 -
이런 고수준 프레임워크 논의보다는 저수준 API 이야기가 더 흥미로움
Windows 렌더링 스택 전체가 GDI/DirectX 위에 올라가 있는 걸로 아는데, Win32 자체도 결국 GDI 위에 있음
진짜 메탈에 가까운 Windows UI 스택을 논의한다면 DirectX로부터 시작하는 게 더 의미 있을 것 같음 -
유저 입장에서 보면 Win32도 충분히 고수준임
현재까지 버튼, 스크롤바 등을 제대로 그릴 수 있는 툴킷은 Win32 뿐임 -
Windows 네이티브 개발을 위한 진짜 좋은 프레임워크를 커뮤니티가 만들어줬으면 함
하지만 그렇게 할 만한 커뮤니티 규모가 충분치 않은 게 현실임
-
-
예전 Windows UI 개발에서 가장 그리웠던 점은
Microsoft에서 직접 만든 것처럼 자연스럽게 어울리는 앱을 쉽게 만들 수 있도록 도와줬던 점임
웹 기술 도입 이후 Windows UI 경험의 일관성이 크게 깨졌음
Microsoft가 예전 앱을 최신화하지 않은 것도 문제지만, 새 툴도 스타일 가이드에 맞는 라이브러리를 제공 안 해줌
비스타 시절부터 이런 현상이 보이기 시작했고, MSDN에서도 '이 기능 이렇게 써보세요' 같은 풍부한 예제 자료가 점점 줄어들었음