[Slog] MAUI 선택, 괜찮은 판단이었을까 🤔

슬로그 작성 중 슬로그
,
1

:hammer_and_wrench: 모니터링 앱 프로젝트: 왜 MAUI인가?

안녕하세요! 이광석입니다. :blush:

이번 회사 프로젝트로 Windows와 Android 환경에서 동작하는 설비 모니터링 앱을 개발하게 되었습니다.

회사 내부 프로젝트인 만큼 자세한 기술 사양은 공유하지 못하지만,
진행 중 느낀 문제점들과 고민들, 그리고 해결 방향에 대한 내용을 Slog로 남겨두고자 합니다.
(왠지… 문제가 생길 것 같은 싸~한 느낌이 들기도 하네요 :sweat_smile:)

처음에는 React Native가 자연스러워 보였다

처음 이 프로젝트를 시작할 때, 가장 먼저 떠오른 선택지는 React Native였습니다.

  • 회사 전체 프론트엔드는 점차 React 기반으로 통합되고 있고,
  • 메인 프로그램도 ASP.NET Core API(백엔드) + React(프론트엔드)로 리뉴얼 중이며,
  • 모바일 앱도 JavaScript 기반으로 통일하면 유지보수 측면에서 유리해 보였습니다.

하지만 실제로 적용을 고민해보면서, 몇 가지 현실적인 벽을 마주했습니다:

  • React Native 경험자가 팀 내에 전무했고,
  • 웹 React와는 전혀 다른 개발 환경과 네이티브 연동 방식에 대한 러닝 커브가 컸습니다.
  • 특히, 디바이스 연동 및 커스터마이징이 많은 UI를 빠르게 구현하려면,
    React Native보다는 .NET 기반에서의 개발 경험을 살리는 방식이 더 적절하다고 판단했습니다.

Avalonia, Uno도 후보였다 — 그러나 제외한 이유는?

React Native 외에도 Avalonia와 Uno Platform도 진지하게 검토했습니다.

1. Avalonia :cross_mark:

  • Avalonia는 XAML 계열의 AXAML을 사용하는 프레임워크입니다.
  • 하지만 저희 팀은 앞으로 대부분의 UI를 React 기반 웹으로 전환하려는 방향이라,
  • 새로운 XAML 문법까지 학습하는 것은 부담이 컸습니다.
  • 게다가, Android 지원은 여전히 실험적 수준이어서 안정성 면에서도 우려가 있었습니다.

2. Uno Platform :cross_mark:

  • Uno는 MAUI와 마지막까지 경쟁했던 강력한 후보였습니다.
  • 다만 Uno는 WinUI 3 기반이라, 저희 팀이 WPF에서 자주 사용했던
    Trigger, 특히 DataTrigger를 기본적으로 지원하지 않습니다.
  • VisualStateManager 방식에 익숙하지 않은 팀원들에게는 이 부분이 큰 제약으로 작용했습니다.

결국 MAUI로 결정한 이유

이 모든 후보들을 검토한 끝에, 최종적으로 MAUI를 선택하게 된 이유는 다음과 같습니다:

  • 기존 WPF 경험을 그대로 살릴 수 있는 XAML + MVVM 구조
  • .NET 기반 생태계에서 Android/Windows를 동시에 지원
  • 네이티브 API 접근, 커스터마이징, 배포 등에서 WPF 개발자들에게 진입장벽이 낮은 점
  • 무엇보다도, 현재 팀은 WPF 개발자 4명으로 구성되어 있어
    학습 비용 없이 바로 실전 투입이 가능하다는 점이 결정적이었습니다.

“메인 프로그램은 유지보수를 거치면서 개선하면 되지만,
모니터링 앱은 기업 고객에게 직접적인 만족감을 주는 앱이기 때문에,
디자인과 기술 모두 완성도 있게 구현되어야 한다는 판단을 내렸습니다.”

앞으로의 계획

현재는 백엔드 안정화에 집중하고 있으며,
모니터링 앱 프론트는 기본 기능만 구현된 상태입니다.
이후에는 MAUI를 사용하면서 겪는 다양한 이슈들과 해결 과정을
계속해서 Slog에 남겨볼 예정입니다.

궁금한 점이 있으시면 언제든지 댓글이나 DM 주세요 :sparkles:
감사합니다!

1개의 좋아요