다시 한번 선배님들의 의견을 듣고 싶네요^^

여기서 취준생의 고민에 글을 올렸는데…

많은 선배님들이 댓글을 달아주셔서 감사 했습니다.^^

덕분에 마음을 좀 가다듬기도 했었습니다.
얼마 뒤에는
어찌어찌 취업도 했습니다.

WPF 관련 개발도 몇건 했고,
중간 중간 아직은 많이 서툴지만 닷넷 기반 웹 개발도 하고 있습니다.

위에 언급한 대로 웹관련 개발이 아직은 부족해서 공부를 병행하고 있기는 한데…
크로스 플랫폼에 큰 매력을 느껴서요…

시간을 쪼개서 파보고 싶은데… 고민이 되네요.

처음엔 생각도 안하고 .net maui 쪽을 살펴봤는데…
어느순간에 Avalonia(아발로니아)도 보이더군요…

WPF를 좋아하는 저에겐
데스크탑 중심의 아발로니아가 매력적으로 느껴지는데…
아무래도 마소 공식 프레임워크가 아니다 보니…
불안감이랄까?

결국은 사라지는 프레임워크에 시간을 투자하는 결과가 나올까 조바심도 생기구요.
또한 과연 실무에도 적용할만 안전성이 있을까?
하는 걱정도 생기더군요,…

머 두루두루 다 살펴보면 좋겠지만…
제 현재 여건상 시간을 쪼개가며 양쪽 모두를 집중하는건 이도저도 아닐것 같아서요.

아발로니아 / 마우이 2개의 프레임워크 한정해서 보면
어느쪽이 전망이 더 밝다고 보시는지요?

해외 커뮤니티도 자주 살펴보기는 하는데… 저에게는 혼란스럽기만 해서요…
선배님들의 고견을 듣고 싶습니다.^^

2개의 좋아요

현재
저는 WPF가 주 업이고
스터디 형식으로 avalonia와 maui를 다루고 있습니다.

현재까지 제가 스터디 형식으로 알아본 기준으로는

Maui의 단점

Avalonia의 단점

  • Android, IOS의 API(카메라, 센서 등)의 라이브러리 부재
  • 개발할 수 있는 지원 툴이 Rider, vscode가 있지만 Visualstuido는 넘사벽
  • 변형된 xaml이기 때문에 약간의 스터디가 필요함

모바일 앱 당장 출시해!

  • Maui 한표, 각 모바일의 API(카메라, 인증 등)가 있기 때문에 향후 앱 출시 이후에도 API를 이용한 기능 업데이트 대응이 가능하기 때문에

데이터조회 및 관리의 서비스

  • 아발로니아 한표, 우선 픽셀 퍼펙트(스키아 기반의 UI) + 빠른 AOT가 매력적

결론

어느 프레임워크를 하시던가에 그 상황에 맞게 고치고 수정하고 오픈소스 기여하고 해야되는게 맞다고 생각합니다.
기본적으로 WPF를 하시고, 시간의 여유가 있으시면 2가지 모두 하시고
욕심버리고 하나만 할 것이다 하시면
간발에 차이로 마우이에 한표 드리겠습니다!

8개의 좋아요

저라면 아발로니아…
마우이는… 플러터 와 코틀린 같은 넘어야 할 벽이 너무 거대함
반면 아발로니아는 매력적이게도 거의 모든 플랫폼에 모두 사용가능 합니다.
근디
Avalonia는 데스크톱 애플리케이션 개발에 이상적입니다.
Windows, Linux, macOS에서 모두 실행 가능한 애플리케이션을 개발할 수 있습니다.

네 데탑 개발에 특화 되있다네요… 모바일은 플러터나 코틀린이 대세 아닌가여 ?

6개의 좋아요

너무 친절하시네요^^
감사합니다. 선배님!

댓글 달아주신 내용을 몇번이나 정독 했습니다.

양쪽을 살펴보며 어렴풋이 느꼈던 생각들이 정리가 되는 기분입니다.
음…
마우이라…
심정적으로 아발로니아가 데스크탑 중심이라서 애정(?)이 가서 심난했는데
선배님의 글을 읽고 스스로 정리가 되가는것 같습니다.
감사합니다. 선배님^^

3개의 좋아요

댓글 달아주셔서 감사합니다. 선배님!

WPF를 많이 좋아하는 저로썬 아발로니아에 관심이 많이 갔습니다.
다만 마소 공식 프레임워크가 아니다 보니 일말의 불안감이랄까?

어떠한 이유로 인해 장기적으로 유지가 안되는 프레임워크에 시간을 낭비하는
결과가 오지 않을까 하는 불안감이 있어서요…

말씀하신 대로 모바일 개발에는 여러 옵션이 있지만
마우이 / 아발로니아 를 한정해서 선택하려니 선택장애가 생기네요 ㅎ

선배님께서는 아발로이나에 좀더 점수를 주시는듯 한데…
아발로니아가 미래에도 꾸준히 존속할수 있을까? 란 불안감에는
어떤 의견이 있으신지도 궁금합니다.^^

3개의 좋아요

아발로니아는 오픈소스이긴 하지만 아발로니아를 전문적으로 유지보수하는 회사가 존재합니다.

Avalonia UI - About

Avalonia UI: 한눈에 보기 | LinkedIn

역시 MAUI, AvaloniaUI 말고도 .NET의 크로스플랫폼 후보인 UnoPlatform 또한 회사가 존재합니다.

Uno Platform: Create Beautiful‎ - .NET apps faster

MS가 사실 자마린도 버린 마당에 MS 공식 프레임워크라고해서 꾸준히 유지보수해주리라는 법은 없습니다. Windows Phone 과 SilverLight도 버렸지요.

내가 기술이 좋고 애정이 가신다면, 단순 사용자에 그치는 것이 아니라 커뮤니티에 기여해주시는 것이 훌륭한 유저가 아닌가 생각해봅니다.

UnoPlatform은 오픈소스는 아니지만 AvaloniaUI는 오픈소스라서 Github 기여가 가능합니다.

꼭 소스코드 커밋만이 기여는 아니고, Issue Up 또한 기여입니다.

7개의 좋아요

시간 내서 댓글 달아주셔서 감사합니다.
두 프레임워크의 배경과 그동안 마소의 역사(?)에 대해 대강은 알고 있습니다.^^

단지 저의 상황이 2개의 프레임워크를 살펴보는건 무리인것 같아서요…
여러 선배님들의 생각을 듣고 싶었습니다.

댓글은 달아주신점은 감사합니다만…

본격적으로 아직 사용해 본 것도 아닌데 온픈소스 기여 이야기를 하셔서
좀 어리둥절 한데 제 글이 이상한가 싶네요?

취지는 알겠습니다만 단순 의견을 묻는 글에 훌륭한 유저가 되어야 한다는
말까지 듣게 될줄은 몰랐습니다. ㅎ

제 글에 실례된점이 있었다면 사과 드리겠습니다.

4개의 좋아요

여기에 대한 저의 대답이었습니다.

이 글에 대한 내용은 아니지만 왜 저렇게 적었는지 경위에 대해 말씀드리면,

사실 초보자/정보가 적은 사람들은 커뮤니티에 기술의 비교에 대해서 많이 물어봅니다.

그리고 커뮤니티에는 기술의 비교에 대한 내용이 많이 오고 갑니다. 여기뿐만 아니라 다른 곳도 마찬가지이고, 특히 .NET의 크로스플랫폼 기술은 React Native 또는 Flutter, Electron 과 비교되며 기술적 부족함이 많이 지적되고 있는 것이 사실이고 현주소입니다. 머리수가 다르다보니 기여자 수가 다르기 때문이라고 생각합니다.

질문자님처럼 .NET 안에서도 크로스플랫폼의 선택을 고민하시는 분도 계십니다. .NET의 크로스플랫폼에 대해 고민하시는 분들 중에는 'MS 진영’이라고 표현하시면서 .NET의 크로스플랫폼이라도 하나로 통합되어 유저들의 기여라도 하나로 모으는 것이 좋지 않나, 그야말로 .NET의 크로스플랫폼 팀킬이니, 춘추전국시대이니 이렇게 표현하는 것도 본적 있습니다.

크로스플랫폼에 막 입문하시는 NET 개발자들은 .NET을 좋아하기에 .NET으로 크로스플랫폼을 하고 싶지만, 자마린처럼 버려지거나 Flutter보다 레퍼런스도 적고 이직자리도 적은 것이 늘 걸림돌이라 실제로 ‘직접 실행해보기 전에’ 커뮤니티 같은 곳에 글로 의견을 묻곤 합니다.

하지만 앞서 말씀드린대로 .NET 크로스플랫폼 기술은 다른 크로스플랫폼 기술보다 ‘일반적인’ 이슈는 없으나 유저 기여수가 다른만큼 디테일에서 떨어지는 것이 사실이므로 비즈니스라는 회사 일의 관점에서는 비교가 무의미할 정도로…생산성 측면에서도, 대체 인력면에서도 .NET 크로스플랫폼은 국내에서난 힘든 것이 너무나 자명합니다.

그리고 커뮤니티는 '책임 없는 조언’이 가능한 곳이니만큼 '내가 경험한 것이 아닌 주변의 사실만 보고 판단한 팩트라고 여겨지는 것’들 위주로 사실처럼 알려주는 문화도 있습니다. 그런 분들도 역시 선의로 도와주시는 것이겠지만, 그런 비교 이슈 자체가 생기면서 기존에 .NET 크로스플랫폼 기술을 다른 시선 아랑곳하지 않고 잘 써오시던 소신있는 분들을 상처줄 수도 있습니다. 나는 MAUI가 좋아서, AvaloniaUI가 좋아서 할 뿐인데 자꾸 주변에서 다른 기술이 우월하다며 신규 유저의 유입을 끊어주는 것이죠. 그러면 순수하게 커뮤니티에 기술적인 선택에 도움을 받고자 온 분들은 그것이 어느정도 일리있는 것이라 생각하고 비교 된 기술 중에서 어떤 한 가지 기술을 선택하게 됩니다. 이것은 아까 'MS 진영’이라고 표현했던 .NET 크로스플랫폼 기술끼리도 마찬가지입니다.

선택받지 못한 기술의 얼굴 모르는 유저는 또 낙심하거나 어떤 형태로든 영향을 받을 것입니다. 오프라인이라면야 신경을 덜 쓸 수 있지만 커뮤니티이기에 불특정다수가 볼 수 있는 것이 신경쓸 점이라고 생각합니다.

마지막으로 비교하며 간만보는 분들은 유저이기에 솔직하고 건실한 피드백을 줄 수 있다고는 하셔도, 내가 좋아하는 기술, 사라지지 않았으면 좋겠다는 막연한 바램만 있고 실질적으로 기술적으로 존속이 되는데 도움이 되는 오픈소스 기여에는 수동적입니다.

그래서 죄송하게도 제가 질문자님도 같은 맥락일거라 지레짐작을 하고…

  1. 기술적 완성도나 선택을 이론으로만 비교하며 고려하지만 말고 직접 조금이라도 프로토타이핑을 해본 뒤에 결정을 내리는 것이 좋지 않을까했습니다. 누군가의 조언보다는 직접 경험하고 판단하면 문제도 확실해지고 이런 비교글도 필요없는 것 아닌가 했습니다.

  2. 추가적으로 기술이 사라지는 것을 원치 않는다면 마음뿐이 아닌 기술의 생존에 직접적으로 도움이되는 실질적 기여 (코드 기여, 이슈업, 유료 후원 등)와 걱정이 함께 동반되면 그게 건강한 문화 아니겠나요.

하는 생각으로 많이 앞서 나가서 글을 단 것 같습니다…

저도 정말 죄송합니다.

7개의 좋아요

너무나 좋은 말씀해주셔서 감사합니다.
선배님 글을 읽어보며 저도 다시 한번 저 스스로를 돌아보게 되네요…

혹여나 제 글로 인해 부정적인 영향을 받는 분들이 없기를 진심으로 바랍니다.

제가 언급한 ‘본격적으로 사용으로 안했다’ 란 표현은
본격적인 개발을 해본적이 없다 라는 표현이였습니다.

아발로니아와 마우이 2개를 가지고 짧지 앉은 시간 동안 간단한 앱을 만들며
저 스스로 생각을 정리하고 싶었지만
각자 장단점이 있어서 쉽게 결정을 내리기가 힘들더군요.,…

평소 이곳에 올라오는 글들을 자주 접하면서
저보다는 깊이 알고 계신 분들에게 의견을 여쭤보고 싶었습니다.

분명 양쪽 프레임워크의 장단점에 대해 제가 파악한것 보다는 좀더 양질의 의견을
듣고

또한 본문에도 언급했지만 데스크탑 및 WPF에 평소 애정이 깊은 저로써는
한쪽으로 편향되는 마음이 커서
현실적인 부분도 듣고 싶었었나 봅니다.

제 글이 어떤 의도를 가지고 작성한 건 단연코 아니며
2개의 프레임워크를 비교하며 기술적 우월함을 비교하려는 의도는 더더욱
아니였습니다.

하지만 읽는 분들에 따라 이렇게 저렇게 해석될수 있다는 점을 간과한것도
사실이기에 선배님의 말씀을 듣고 저도 글 작성에 좀더 신중하지 못한것 같아
죄송한 마음이 드네요…

귀한 시간 내주셔서 좋은 말씀 많이 해주셔서 감사합니다.^^

7개의 좋아요