블로그 | 자마린 폼 지원 종료 이후 해야 할 일 '업데이트가 전부다'

마이크로소프트 닷넷의 첫 주요 크로스 플랫폼 UI 툴인 자마린 폼(Xamarin Forms)의 지원 중단까지 한 달이 채 남지 않았다. 자마린 폼은 개발자가 윈도우, iOS, 안드로이드를 위해 각기 별개의 UI를 구축할 필요 없이 하나의 코드 베이스를 구축해서 디바이스별 코드를 사용하지 않고도 모든 타겟 플랫폼으로 컴파일할 수 있는 일련의 크로스 플랫폼 UI 컨트롤을 제공했다. 큰 인기를 끌었지만, 이제 곧 사라진다.
 
마이크로소프트는 자마린 폼의 뒤를 이을 마우이(MAUI), 즉 멀티 플랫폼 앱 UI(Multi-platform App UI)를 개발해왔다. 마우이는 윈도우, 맥OS, iOS, 안드로이드를 지원하며, 개발자는 자마린과 동일한 툴과 기법을 사용해서 최신 닷넷 릴리스로 계속해서 코드를 개발할 수 있다. 마우이는 많은 부분이 아직 개발 중인 단계인데, 몇 가지 차이점으로 인해 컨트롤 집합을 단순히 교체하기는 어렵다.
 

깃허브에서 두 플랫폼의 현재 상태에 대한 비교 자료를 볼 수 있다. 가장 중요한 차이점은 최신 닷넷 플랫폼으로 코드를 이전해야 한다는 점과(닷넷 6 이상에서 지원), MVU와 블레이저(Blazor) 두 가지 모두 지원하도록 확장되는 다양한 애플리케이션 모델일 것이다. 목표는 마우이와 윈도우 앱 SDK 간에 공통적인 기능 집합을 제공해서 윈도우 전용 코드를 다중 플랫폼으로 신속하게 이전할 수 있도록 하는 것이다.
 
한 가지 유의해야 할 부분은 자마린 폼이 지원되지 않는다 해도 구형 iOS와 안드로이드 디바이스를 위한 앱을 구축하기 위해서는 여전히 필요하다는 점이다. 구형 디바이스가 타겟이 아닌 경우 코드를 마우이 또는 현재 사용 가능한 대체 크로스 플랫폼 닷넷 UI 프레임워크 중 하나로 이전하는 방안을 고려해야 한다. 우노 플랫폼(Uno Platform)과 아발로이나(Avalonia) 모두 WinUI 3 호환 컨트롤을 제공하고 다양한 운영체제를 지원하는 성숙한 툴이다.
 

마우이 외의 옵션

선택할 수 있다는 것은 좋다. 닷넷은 오픈소스라는 특성에 힙임어 우노, 아발로니아와 같은 확장 기능을 위한 매력적인 플랫폼이 됐다. 우노와 아발로이나는 모두 크로스 플랫폼 UI를 위한 다양한 접근 방법을 제공하며 다양한 애플리케이션 모델을 지원하고 폭넓은 컨트롤을 제공한다. 팀에 맞는 툴을 선택할 수 있는데, 새로운 툴을 시도해 보고 싶다면 리포지토리에서 새 분기를 설정하고 실행하기만 하면 된다.
 
마이크로소프트는 자마린에서 마우이로 업데이트하기 위한 가이드를 제공한다. 대부분의 일반적인 시나리오는 지원되지만 워치OS와 같이 그 외의 경우에는 새로운 네이티브 스위프트 애플리케이션을 구축해야 한다. 실제로는 그렇게 할 필요가 없을 수도 있다. 완전히 새로운 애플리케이션 프레임워크를 관리하는 것보다 워치OS의 풍부한 알림이 더 나은 대안일 수 있기 때문이다.
 
프로젝트를 마우이 SDK 프로젝트 형식으로 수동으로 옮길 수 있지만 마이크로소프트 자체의 닷넷 업그레이드 어시스턴트(.NET Upgrade Assistant)를 사용해서 이전 과정을 시작하는 방법도 있다. 다만 대부분의 경우 바로 빌드 가능한 애플리케이션을 얻을 수 있는 것은 아니다. 직접 레이아웃을 최종 정리하고 적절한 라이브러리가 있는지 확인해야 한다.
 
마우이 최근 릴리스에서는 이전의 많은 문제가 해결됐다. 마이크로소프트는 마우이 깃허브 리포지토리를 통해 공개 로드맵을 운영하고 수정 목록을 제공한다. 확실히 매우 활동적인 프로젝트이며 빠른 속도로 성숙 단계로 발전하고 있다.
 
대안 UI 플랫폼을 사용할 계획이라면 우노와 아발로니아 모두 자체 마이그레이션 가이드와 함께 대형 고객사가 플랫폼을 전환한 방법을 보여주는 사례 연구를 제공하므로 참고할 수 있다.
 

UI 플랫폼 선택

우노 및 아발로니아 UI 플랫폼과 마우이의 가장 큰 차이점은 마우이는 네이티브 컨트롤을 위한 래퍼라는 점이다. 마우이에서는 동일한 코드를 그대로 사용해서 네이티브 모양과 느낌의 앱을 빌드할 수 있고, 아발로니아와 우노에는 자체 렌더링이 있다. 이 방식은 다양한 타겟 디바이스에서 앱 간에 어느 정도의 일관성을 보장하며 다른 디바이스와 플랫폼으로 컨트롤을 더 쉽게 이식할 수 있게 해준다. 아발로니아와 우노 플랫폼은 윈도우의 WinUI 모델을 기반으로 사용함으로써 컨트롤의 스타일에 대해 더 많은 옵션을 제공한다.
 
우노의 마이그레이션 문서를 보면 애니메이션부터 컨트롤, 탐색 등에 이르기까지 고려해야 할 사항이 많다. 그러나 우노와 자마리안 폼의 XAML 구현 방법은 상당히 비슷해서, 무난하게 마이그레이션을 수행할 수 있다. 다만 쉽게 자동화할 수 있는 프로세스라고 기대하면 안 된다.
 
예를 들어 컨트롤 또는 객체를 애니메이션화하는 경우 자마린 폼의 애니매이션 클래스에서 WinUI 3의 스토리보드로 전환해야 한다. 스토리보드는 닷넷 초기 WPF에 도입된 애니메이션 접근 방식을 기반으로 하며, 대부분의 윈도우 UI 개발 툴에서 10년 이상 사용된 만큼 아마 익숙해 보일 것이다. 자마린 폼 애니메이션 작업에 해당하는 스토리보드 기능을 이해하고, 스토리보드 타임라인 내에서 작업하면서 이를 마이그레이션의 일부로 사용하는 것이 좋다.
 
한 가지 중요한 차이점은 WinUI 3의 탐색 지원 방식이다. 자마린 폼에는 페이지 모델과 페이지 사이의 탐색을 관리하는 스택이 있다. 이 페이지 모델은 페이지 스택의 앞방향 또는 뒷방향 탐색을 관리하는 프레임 컨트롤로 대체된다. 이 방식이 더 유연하긴 하지만 WinUI 3의 윈도우 유산에는 몇 가지 문제가 따라온다. 우선 하드웨어 탐색 버튼을 직접 지원하지 않으므로 필요한 부분에 직접 코드를 추가해야 한다. 또한 자체적인 탐색 표시줄 컨트롤도 추가해야 한다. 다만 자마린 폼과 달리 WinUI 탐색은 새 페이지로 매개변수를 전달할 수 있다.
 
이러한 자잘한 문제가 꽤 많기 때문에 마이그레이션을 시도하기 전에 충분히 시간을 들여 문서와 자습서를 살펴봐야 한다. 그래도 큰 문제라고 할 만한 것은 없고 대부분은 해결 방법이 있다. 물론 마이그레이션하면 일부 작업이 간소화되고 코드 복잡성을 낮추고 디버깅이 쉬워지는 등 다른 측면도 있다.
 

업데이트가 전부다

어떤 접근 방식을 선택해 자마린 폼을 대체하든 상당한 작업이 필요하다. 다만 이 작업의 대부분은 자마린을 뛰어넘는 닷넷 플랫폼의 발전으로 인한 것이다. 마이크로소프트는 닷넷이 모든 타겟 플랫폼에서 원활하게 실행되도록 하기 위해 많은 노력을 기울였으므로 사용자와 접하는 애플리케이션을 구축한다면 이러한 변화를 활용하는 것이 좋다. 자마린 폼은 이제 레거시 기술이다. 즉, 개발자와 사용자가 앞으로 나가지 못하게 하는 걸림돌이 될 수밖에 없다.
 
현대적 UI 프레임워크로 전환하면 애플리케이션의 미래를 한 단계 더 확실히 보장할 수 있다. 사용자를 위해 더 새로운 디바이스를 지원하고, Wasm을 통해 네이티브 데스크톱 및 모바일 앱과 많은 기능이 동일한 리치 웹 애플리케이션을 지원할 수 있다. 아발로니아와 우노에는 모두 자마린 폼에서 가능한 기능을 뛰어넘는 방대한 컨트롤 라이브러리가 있으므로 코드로 더 많은 작업을 더 빠르게 할 수 있다.
 
이 방식을 택한다면 자마린 폼의 수명 종료를 코드 업데이트와 재설계의 기회로 보고 애플리케이션에 더 적합한 더 새로운 닷넷 기능과 새로운 디자인 패턴을 활용할 수 있을 것이다. 피그마(Figma)와 같은 현대적 디자인 툴을 툴체인에 추가해서 디자인과 개발 사의 간극을 잇고 마찰을 줄이고 더 협업적 환경을 구축할 수도 있다.
 
자마린 폼의 지원 종료는 모바일 및 크로스 플랫폼 닷넷에 나쁜 소식이 아니다. 오히려 현대적 닷넷이 많은 옵션을 제공한다는 것을 보여준다. 또한 닷넷은 오픈소스 기반이므로 빈 틈이 있다면 자기만의 코드로 채워 넣을 수 있다.
editor@itworld.co.kr