UWP 를 접한 계기는 마이크로소프트 스토어 때문이었다. 앱을 개발하고 소소한 수익이라도 만져볼 생각이었지만 2024년 11월 UWP에 대한 지원 중단에 대한 포스팅을 발견했고, WinUI 를 접하게 되었다. 둘 다 마이크로소프트 윈도우의 UI 프레임워크지만 UWP 지원을 중단하는 큰 이유는 개발자들의 참여도가 상대적으로 적은 것이 원인이었다. UWP의 지원이 중단되면서 대체재는 무엇일까? 했지만, 마이크로소프트는 WinUI를 권장하고 있다. WinUI는 윈도우 계열의 UI 프레임워크로 간단한 앱은 기존의 WPF , UWP와 흡사하기 때문에 이미 WPF나 UWP에 익숙해져 있다면 WinUI로 빠르게 옮기는 것도 방법일 듯 싶다. 마이크로소프트 UWP 지원 중단과 WinUI 3 권장 UI 프레임워크 UWP 앱, 지금 당장 이전해야 할까? 결론부터 말하면, 모든 UWP 앱을 지금 즉시 WinUI 3로 옮길 필요는 없다. 하지만 “어떤 앱이냐”에 따라 판단은 완전히 달라진다. 아래 중 하나라도 해당된다면, UWP 유지보수는 장기적으로 리스크가 된다. 신규 기능 추가 계획이 있는 앱 Windows 최신 UI/기능을 활용해야 하는 앱 1년 이상 운영 예정인 서비스형 앱 기업/업무용으로 장기 지원이 필요한 앱 반대로, 단순 내부 도구이거나 기능 추가 계획이 없는 경우라면, 단기적으로는 UWP 유지도 가능하다. 중요한 건, ‘지금 이전하느냐’보다 ‘이전을 전제로 설계하고 있느냐’다. UWP 극복하지 못한 비운의 UI 프레임워크 UWP를 처음 접했을 때는 마이크로소프트 스토어 때문이었다. 소소한 윈도우 앱으로 소소한 수익을 기대한 것이지만, 상당히 불편했다. `윈폼보다 못한 기능` 이 한가지만 해도 이미 모든 것을 말해준다. 심지어 WPF보다도 못했다. ( 다행인건 개발환경은 비슷했다는 점에 있다.) 윈도우 계열의 모든 기기에서 사용할 수 있는 `원소스-멀티코드`가 목적이었지만, 욕심이 과했던 것인지 내부의 문제였던 것인지, 문제를 제기해도 UWP에 대한 지원은 미미했다. ...
UWP를 접한 계기는 마이크로소프트 스토어 때문이었다.
앱을 개발하고 소소한 수익이라도 만져볼 생각이었지만 2024년 11월 UWP에 대한 지원 중단에 대한 포스팅을 발견했고,WinUI를 접하게 되었다.
둘 다 마이크로소프트 윈도우의 UI 프레임워크지만 UWP 지원을 중단하는 큰 이유는 개발자들의 참여도가 상대적으로 적은 것이 원인이었다.
UWP의 지원이 중단되면서 대체재는 무엇일까? 했지만, 마이크로소프트는 WinUI를 권장하고 있다.
WinUI는 윈도우 계열의 UI 프레임워크로 간단한 앱은 기존의WPF, UWP와 흡사하기 때문에 이미 WPF나 UWP에 익숙해져 있다면 WinUI로 빠르게 옮기는 것도 방법일 듯 싶다.
UWP 앱, 지금 당장 이전해야 할까?
결론부터 말하면, 모든 UWP 앱을 지금 즉시 WinUI 3로 옮길 필요는 없다.
하지만 “어떤 앱이냐”에 따라 판단은 완전히 달라진다.
아래 중 하나라도 해당된다면, UWP 유지보수는 장기적으로 리스크가 된다.
- 신규 기능 추가 계획이 있는 앱
- Windows 최신 UI/기능을 활용해야 하는 앱
- 1년 이상 운영 예정인 서비스형 앱
- 기업/업무용으로 장기 지원이 필요한 앱
반대로, 단순 내부 도구이거나 기능 추가 계획이 없는 경우라면,
단기적으로는 UWP 유지도 가능하다.
중요한 건, ‘지금 이전하느냐’보다 ‘이전을 전제로 설계하고 있느냐’다.
UWP 극복하지 못한 비운의 UI 프레임워크
UWP를 처음 접했을 때는 마이크로소프트 스토어 때문이었다.
소소한 윈도우 앱으로 소소한 수익을 기대한 것이지만, 상당히 불편했다.
`윈폼보다 못한 기능`
이 한가지만 해도 이미 모든 것을 말해준다.
심지어 WPF보다도 못했다.
( 다행인건 개발환경은 비슷했다는 점에 있다.)
윈도우 계열의 모든 기기에서 사용할 수 있는 `원소스-멀티코드`가 목적이었지만, 욕심이 과했던 것인지 내부의 문제였던 것인지, 문제를 제기해도 UWP에 대한 지원은 미미했다.
더욱이 이런 불편함은 개발자들이 외면하기 시작했고, 다른 대체재로 이동했다.
자연스럽게 관심에서 멀어지기 딱 좋은 ~
지금의 윈도우 계열 프로그램들이 퇴색되는 이유가 여기에 있는 것.
사례를 찾아보니 오래 전에 실버라이트( SilverLight )란 웹 UI가 있었고, 지금의 길을 걸었다.
몇 년 지나지 않아 완전히 서비스를 종료했다.
지금의 UWP를 보면 그런 느낌이 있으며, 마이크로소프트의 원대한 `원소스-멀티유즈`가 목적이었던 UWP는 내부적인 문제를 극복하지 못한 것 같다.
하지만, 다행스러운 점이 있다.
UWP의 지원이 중단된다고 해도, 레거리로 전환되어 공식 문서는 공개적으로 보존할 것이고, 대체재로 WinUI3를 권장하고 있다는 점에 있다.
WinUI3는 WPF, UWP와 비슷한 개발환경을 가지고 있으며 마이크로소프트 스토어의 배포가 가능하다.
지금의 마이크로소프트는 WinUI3를 적극적으로 밀고 있는 모양새.
어쨌든, 테스트로 하나 만들어 보니 나름 괜찮은 퀄리티를 보이고 있다.
( 이번에 출시한 비주얼 스튜디오 2026 또한 마음에 든다. )
WinUI 마이크로소프트의 권장 UI 프레임워크
마이크로소프트 스토어 때문에 접했던 UWP였지만, 이별을 해야 된다.
이제는 WinUI를 권장하고 있으며, 기존에 UWP로 만들었던 앱이 있다면 WinUI로 마이그레이션을 권장하고 있다.
그렇다면 이전에 있던 UWP는 어떻게 될까?
단순히 UWP를 위한 개발이라면 지금 그대로 레거시로 보존하고, 유지보수 형태로 지원을 계획하고 있다.
대신 WinUI 프레임워크에 UWP와Win32개발을 위한 통합을 진행했다.
윈도우 10에서 윈도우 11 로 넘어오면서 내부적으로도 많은 일이 생겼던 모양이다.
개인적으로 마은에 드는 점은 C#, C++의 지원과 함께 기존 UWP에 있던XAML을 그대로 사용할 수 있다는 점에 있다.
단순한 UI 프레임워크의 변경이 아닌 윈도우 개발을 위한 SDK를 새롭게 출시한 느낌이 강하다.
역사의 반복
관련 내용 중 비슷한 사례가 있었다.
과거 마이크로소프트는 실버라이트라는 웹 UI 프레임워크를 배포하고 홍보에 열을 올린 적이 있었다.
XML 기반의 UI 와 C# 또는 VB 코드를 사용한 비하인드 코드로 동작을 연결시키면, 꽤나 괜찮은 웹 UI가 생성되었다.
관련 자료 중 튜토리얼을 보면 나름의 신박한 웹 UI 임을 볼 수 있다.
다만, 실버라이트는 몇 년 지나지 않아 소리소문없이 마이크로소프트에서 퇴출되기에 이른다.
웹UI 로써 모양과 마이크로소프트 웹서비스 기반의 호환성은 충분했다.
다만, 문제는 다른데 있었다.
개발의 불편함과 함께 개발자들의 관심이 자연히 멀어진 것.
당시 실버라이트의 대체재는 너무도 강력한 플래시가 있었다.
초보자부터 숙련자까지 플래시가 접근성이 좋았고, 개발 편의성도 나름 괜찮았다.
뭐, 시간이 지나 플래시 또한 개발이란 시장에서 자연히 멀어진 것도 사실.
( 당시 플래시는 초등학생들까지 미니게임을 만들 정도로 핫한 툴이었다. )
현재의 UWP를 보면 마이크로소프트의 역사가 반복되는 느낌이 있다.
하지만, 이런 반복 속에 더 좋은 프레임워크도 나오면서 비주얼 스튜디오까지 업데이트하여 기능을 보강하는 것은 나름 마음에 든다.
현실적으로 모든 기능을 써보지 못하는 것이 아쉬울 따름.
마이크로소프트의 개발 툴의 방대함은 사람을 기겁하게 만든다.
마이크로소프트 스토어
마이크로소프트는 윈도우 생태계에 변화를 주었다.
개발자들의 참여를 높이고 윈도우라는 OS의 편의성을 높이고자 함에 의 목적이 있을 것이다.
구글이 먼저 시작했고, 애플이 따라왔으며, 이를 본 마이크로소프트의 입장에서도 변화는 주고 싶었을 것이다.
그렇게 탄생한 것이 마이크로소프트 스토어이다.
윈도우키를 누르면 시작메뉴가 나타나고 대놓고 클릭해 달라는 영문 아이콘이 하나 있다.
마이크로소프트 스토어 아이콘이다.
윈도우 사용자라면 앱을 다운로드 받지 않고 편하게 스토어에서 설치하고 바로 사용하면 된다.
굳이 제작사 홈페이지를 가지 않아도 된다.
그럼에도 구글 또는 애플이 운영하는 스토어보다 사실 인기는 떨어진다.
지원되는 서비스도 미비하며, 개발자들을 위한 수익 도모라는 말도 있지만, 사실 구글이나 애플처럼 편의성이 떨어지는 것도 사실이다.
마이크로소프트 스토어 아이콘을 클릭하면 구글플레이 또는 앱스토어와 같은 비슷한 앱이 실행된다.
자신에게 필요한 앱을 찾아 설치하고 사용하면 그만이다.
윈도우만큼 사용자 편의성이 높은 OS도 없지만, 뒷받침되는 앱들은 솔직히 ~ 음 ~
풍요 속의 빈곤처럼 보이는 이유는 무엇일까?
그럼에도 윈도우 사용자들을 위한 앱을 제작해 보는 것도 괜찮을 듯 싶다.
일단은 만들어 보자.
UWP로 계산기를 만들려고 하면 그렇게 수고가 들어갔다.
튜토리얼과 예제를 보더라도 윈도우의 기능을 사용 못 하는 경우들도 있었다.
UWP는 윈도우라는 범주에 있더라도 `원코드-멀티유즈`라는 반응형 앱을 구현하는 것 자체가 쉽지 않았다.
일단 만들어 보긴 했지만, 굳이 이렇게까지 할 이유가 없었다.
( 윈폼, WPF 보다 손이 많이 간다. 더 많은 자료를 찾아야 했다. 고작 ~ 계산기 였는데 말이다. )
하지만, 이번에 마이크로소프트 WinUI를 소개하면서 이런 문제는 해결된 듯 싶다.
일단, 경험이라도 쌓는 느낌으로 개발부터 배포까지 시도해 보면 괜찮을 듯 싶다.
가장 좋은 것은 아마도 계산기 정도면 어떨까 싶다.
튜토리얼은 이미 많이 존재하기 때문.
경험해 보자.
개발부터 배포까지
과거 UWP를 사용해 아주 간단하고 하찮은 프로그램을 만든 후,
마이크로소프트 스토어에 배포를 한 적이 있었다.
너무나 하찮고 간단했던지라 인기는 없었지만,
시험 삼아 올린 것이고, 경험이라 생각했다.
배포하는 기간보다 제작 기간이 더 길었다.
WPF에 익숙해졌다고 해도, UWP로 만든다는 것은 쉽지 않은 작업들 이었다.
WPF에서는 되지만, UWP에서 동작하지 않는 것들이 발생했기 때문이다.
그렇다면, 이번에 UWP 대안으로 떠오른 WinUI 3의 경우는 어떨까?
일단 진행해봐야 정확한 것을 알 수 있을 것 같다.
과정은 다음과 같다.
먼저 개발을 하고, 테스트를 한 후에 마이크로소프트 소프트에 앱을 배포한다.
다른 앱들과 배포하는 과정은 동일하다.
개발과정은 다른 포스팅에서 이어지고,
잠깐 동안 경험한 WinUI 3의 경우,
UWP보다는 편하지만, WPF보다는 확장성이 부족한 느낌이 있었다.
댓글
댓글 쓰기