저는 XAML을 이용하지 않고, 온코드로 화면을 초기화하는 것이 더 자유롭다고 느끼는 편이라, 위지위그의 필요성에 대해서 별로 느끼지 않게 되었으며, WPF의 경우엔 개발 편의를 위해 절대 레이아웃을 전제하는데, 레이아웃은 굳이 멀티플랫폼 환경이 아니라도, 반드시 존재해야되는 UI 계층이라고 생각합니다. 그리고 많은 분들이 데스크탑 환경이면 WPF가 낫다고 말하시는데, WPF는 닷넷5까지만 지원하고, C#에 추가된 최신 기능도 사용하지 못하죠. 개인적으로는 아무리 생각해도 저는 MAUI가 아닌 WPF를 선택해야할 메리트가 느껴지지 않네요. WPF가 안정화된 라이브러리를 가졌고, 고성능 UI 구현에 장점이 있다는데, 저는 이것도 잘 와닿지 않습니다. 대체 WPF를 써야하는 궁극적인 이유가 무엇인가요?
일단 WPF는 현재 출시된 가장 마지막 .NET 버전인 .NET 9 기준으로도 여전히 지원되고 있고 계속 업데이트되는 기술입니다. 특별한 이변이 없다면, 곧 출시될 새 장기지원 버전인 .NET 10에서도 업데이트가 계속 진행될 것으로 보입니다.
그리고 많은 경우 아직까지도 .NET으로 Windows 데스크톱 애플리케이션을 디자인하려는 경우가 많은 점 + 러닝 커브가 낮은 점을 메리트로 여겨서 WPF를 선택하시는 경우가 많다고 생각합니다.
반면 MAUI의 경우 Flutter처럼 Write-Once Run-Everywhere를 지향하는 기술이기 때문에 여기에 맞는 요구 사항이 따로 있다고 생각합니다. 즉, 요구 사항이 무엇인지에 따라 WPF인지 MAUI인지가 갈린다고 봐야 하지 않을까 생각합니다.
아, 제가 지원이 중단된 UWP와 헷갈린 것같습니다.
UWP가 WPF보다 최신모델이니 WPF도 당연히 지원이 중단된 것으로 알고 있었네요. 알려주셔서 감사합니다.
잘몰라서 그렇는데 MAUI가 ?? WPF 를 대체할 성격인가요??
WPF 매인이고 MAUI 는 모바일 특화 아니었나요??/
UWP가 더 이후에 나온 기술은 맞지만 WPF와는 성격이 좀 다릅니다.
많은 사람들이 Windows는 Desktop OS다 라고 알고 있고 사실 요즘은 그렇긴합니다만, UWP가 만들어지던 시기엔 Windows로 별의 별짓을 다하려던 시기라서 Windows OS가 Desktop에 국한 되어있지 않았습니다. 그래서 MS에서 Windows 생태계를 구축하기 위한 Windows Cross Platform 기술이라고 알고 있습니다.
말씀하신대로 UWP가 아무래도 Desktop Windows OS에서 만드는 예제가 많아서 그렇게 느끼신 걸 수도 있습니다. 그리고 UWP의 기술을 WPF에서 가져다 사용할 수도 있기에 WPF가 Windows Desktop 한정이라면 더 유연한 기술은 맞습니다.
특화…라기보다는 크로스 플랫폼 기술은 맞기 때문에 MAUI로 Windows Desktop App을 만들 경우 비즈니스가 확장되어 모바일까지 '필요해지는 시기’가 왔을 때 확장이 용이하다는 점 같습니다.
Flutter랑 비슷하죠.
데스크탑 앱도 만들 수 있지만…
추천하지는 않는 그런 경우요.
아무래도 관성이 첫 번째 이유일 것 같습니다.
흥행에 성공적이지 못했던 자마린(의 윈도우 구현은 UWP입니다)을 계승한 MAUI 보다, WPF 는 꽤 장기적으로 안정적으로 사용되어 왔으니까요.
그리고, 소프트웨어 구조도 한 몫 한 것 같습니다.
우선, WPF는 윈도우를 전제하기 때문에, 단순한 구조라 접근성이 좋다고 할 수 있습니다. 그러나, MAUI 는 복수의 플랫폼을 전제하기에, 같은 코드를 작성하더라도 고려 사항이 많게 됩니다.
사실 이 점은 MAUI 를 윈도우 앱을 개발하는데 사용하는 개발자에게도 시사하는 바가 있는데, 현재 작성하는 코드가 윈도우(또는 단일 플랫폼)만 전제하는 코드는 아닌 지 검토해봐야 합니다.
그런 고려가 여의치 않은 경우, 윈도우 앱은 WPF를 사용하는 편이 더 효율적이라 할 수있습니다.
마지막으로 언급하고 싶은 차이점으로는 WPF 는 서비스 컨테이너를 전제하지 않고 개발된 반면 (WPF 창시자가 가장 후회하는 부분이라고 하더군요), MAUI는 전제하여 개발되었다는 점입니다.
간단히 얘기하면, MAUI의 콘트롤은 서비스 컨테이너가 생성하기에, 아래와 같은 의존성 주입 코드가 가능합니다.
public MainPage(MainPageViewModel viewModel)
{
InitializeComponent();
BindingContext = viewModel;
}
그러나, WPF에서는 위와 같은 의존성 주입코드가 아니라, static 한 서비스 컨테이너를 직접 접근하는 방식입니다.
public MainPage()
{
InitializeComponent();
var viewModel = ServiceProvider.GetRequiredService<MainPageViewModel>();
DataContext = viewModel;
}
이런 태생적 차이점으로 인한 상이한 코드 구조는 개발자의 과거 경험에 따라 익숙함이 다를 수 있습니다.
Asp Net Core 등을 사용하던 사람에게는 MAUI 쪽이 익숙한 반면, WPF/윈폼 사용자에게는 아래 쪽, 혹은 서비스 컨테이너를 사용하지 않는 방식이 더 익숙할 수도 있습니다.
그래도 무엇이 더 근본이냐고 묻는다면, 저는 MAUI의 손을 들어주고 싶네요. 윈도우즈 점유율이 아직까진 높지만, 미래엔 어떻게 될지 모르니. 제가 생각하는 가장 이상적인 미래는 여러 OS들이 서로 균형있는 점유율을 유지하는 것인데, 그런 시대가 만약 온다면 MAUI가 빛을 낼거라고 생각합니다.
말씀하신 취지에 맞는 답글인지는 모르겠지만, 저는 오히려 근본은 기술이 아니라 비즈니스라고 생각합니다. MAUI가 아니라 크로스플랫폼 기술을 지향하고 싶으신 의도라고 파악이 되는데…비즈니스의 흥망성쇄에 따라서 기술이 함께 망하기도 하고 흥하기도 합니다.
모든 사람은 개발자가 아니고 모든 개발자가 같은 경험을 가지고 있지는 않습니다만…한 가지 분명한 것은 기술기반으로 이해하고 비즈니스를 접근 해야하기 때문에 기술이 필요하다고 생각합니다. 비 개발자두요. 기술적인 한계를 이해하고, 시간 또한 비용이라는 제약사항을 이해한 그때 당시에 따른 비즈니스적인 판단을 해야만 하기 때문입니다.
장기적으로 어떻게 될지 몰라서라는 것은 가능성이며 그 비즈니스는 망할수도 있기때문에 요즘 기술에서는 MVP모델로 패턴그런거 없이 이 상품이 시장에서 먹힐것인가를 빠르게 만들고 버리는 것입니다.
기술이 뛰어난 개발자가, 처음부터 여러 미래에 발생할 기술적 이슈를 상상해서 처음부터 이거저거 다되게 만들면… 유연할 수 있지만 비즈니스가 충분히 발전하지 않은 상태로 뇌피셜만가진 고급 기술덩어리라서 일단은 개발공수가 많이 들 것이며 큰돈 들여 실패할 우려도 있습니다.
그래서 기술이란 하나의 기술로 다 되는 건 없고 적합한 기술만이 있는 것이며 크로스플랫폼이 발전적인 이 상황에서도 Native 환경의 기술이 같이 발전하고 있는 거라 생각합니다.
아직은 이런 글이 많이 찾아지지 않습니다. 하지만 추세라는 것은 분명하며, 사람의 경험을 편하게 해주는 UI UX가 진짜로 AI한테 그냥 말만 잘하면 알아서 해줄 경우 사람이 보기 편하고 알아보기 편한 UI UX는 진짜로 없어질 가능성도 있습니다.
그러면 추세가 있고 모든 가능성을 생각해야해서 UI UX는 필요없다고 주장하면 수많은 Toss UI 컨퍼런스에 참여하는 개발자들에게 맞을수도 있겠지요.
그렇기 때문에 우리는 기술을 가지고 있고 기술로 밥벌어먹고 살더라도 비즈니스가 저는 우선이라고 생각합니다.
MAUI는 프로덕션 레벨에 도달하지 못한거 같습니다.
반년전 github issues 확인했을때 안된다 투성이었어요.
현재 모바일은 크로스 플랫폼이 한때 많이 올라왔다가 떨어지는 추세입니다.
이유는 웹으로 가능한것들 제외하면 디바이스 전용 기능을 쓰게 되는데.
이게 IOS, Android마다 별도 코딩이 필요합니다.
심지어 Android는 제조사 별로도 갈라지는 경우가 생깁니다.
덕분에 크로스 플랫폼으로 갔다가 다시 전용으로 돌아온 회사들이 많습니다.
하나로 다한다는게 참 좋긴 한데… 이게 아직 완벽한 경우를 보지는 못했네요.
하다못해 내/외장 카메라를 좀 로레벨로 제어를 하고 싶다? 안됩니다.
크로스플랫폼의 강점은 "통합 UI"가 아니라 "공통 서비스"에 있다고 생각합니다. WPF는 윈도우 환경에 최적화되어 성능과 커스터마이징에서 강점을 가지며, 복잡한 UI를 처리하기에 적합합니다. 반면, MAUI는 여러 플랫폼에서 동일한 UI를 제공하지만, 각 플랫폼의 UI 특성을 고려하기 어려워 부족한 경험을 제공할 수 있습니다.
결국, 핵심 로직과 서비스를 공통화하고, 각 플랫폼에 맞는 최적화된 UI를 구축하는 것이 더 효율적이라 생각합니다.