.NET MAUI

.NET Multi-platform App UI.

원래는 자마린(Xamarin)이라는 이름으로 시작된 프로젝트다.

크로스 플랫폼 애플리케이션 개발용 프레임워크이자 이를 만드는 회사의 이름이기도 하다. 정확하게 말하자면 크로스 플랫폼 앱 개발 도구는 자마린 플랫폼(Xamarin Platform)이다. 원래 이 회사는 .NET 프레임워크를 리눅스에서 돌리는 모노 프로젝트를 개발했는데 자마린도 여기에서 파생된 것이다. 즉 .NET을 리눅스에서 돌릴 수 있으면 .NET 기반 앱을 윈도우 아닌 다른 운영체제에서 돌리는 것도 가능하겠네? 어차피 안드로이드는 커널이 리눅스고, iOS도 XNU 커널은 유닉스 계열이니까 말이지? 하는 생각에서 탄생한 프로젝트다. .NET 기반이니 개발 언어는 당연히 C#이다. 원래는 안드로이드와 iOS, 윈도우 모바일을 지원하므로 모바일 개발도구로 널리 알려져 있지만 윈도우 RT 환경 및 실버라이트, 윈도우 10에서 데스크톱과 모바일을 동시 지원하는 유니버셜 윈도우 플랫폼, 추가로 macOS 앱 환경까지 지원하기 때문에 데스크톱으로까지 확장될 수 있다. 하지만 모바일용, 특히 안드로이드와 iOS 크로스플랫폼 개발을 위해 쓰는 경우가 압도적으로 많으므로 다른 건 무시해도 좋을 정도다.

윈도우 모바일이야 C#을 쓰지만 안드로이드는 자바, 애플은 Objective-C → Swift 언어를 사용하고 있는데, 자마린은 각 운영체제별 API를 몽땅 C#으로 구현해 놓았다. 즉, C# 하나만 쓰면 두 운영체제 및 윈도우 모바일을 한 가지 언어로 개발할 수 있는 것.

과거에는 유료였기 때문에 '비싸기만 하고 허접하다'는 분위기로 큰 인기가 없었지만 2016년 초에 MS가 인수하고 무료로 풀어버리면서 관심히 확 높아졌다. 게다가 MS가 모바일 시장에 나름대로 사활을 건 프로젝트 중 하나라서 적극 밀어주고 있어서 기능이나 안정화가 계속 향상되고 있다. 아예 오픈 소스로 깃허브에 소스를 올렸고 MIT 라이선스가 적용된다. 비주얼 스튜디오 커뮤니티 에디션에 자마린을 사용하면 완전 공짜. 다만 윈도우는 비주얼 스튜디오, 맥은 비주얼 스튜디오 for 맥으로 개발환경이 거의 고정되어 있다. 비주얼 스튜디오가 워낙에 좋은지라 무료로 쓸 수 있는데 딴 걸 굳이 찾을 필요는...

MS는 .NET MAUI(Multi platform App UI) 프로젝트를 진행하면서 자마린을 흡수할 계획을 밝혔으며, 실제로 2024년 5월 1일부로 자마린 지원을 중단하고 .NET MAUI로 옮겨갈 것을 권고하고 있다.

특징

대부분의 크로스 플랫폼 개발 도구들이 자바스크립트를 사용하고 있는 반면, 자마린은 C#을 사용한다.

모바일 크로스 플랫폼 앱 개발에 많이 쓰이는 아파치 코르도바는 웹 뷰에서 프로그램을 돌린다. 즉, 웹 앱처럼 HTML과 CSS, 자바스크립트를 사용하고 앱 안에서는 웹 브라우저를 하나 안아서 그 안에서 웹 페이지로 보여주는 것이다. 쉽게 말하면 그냥 모바일 웹 사이트가 기계 안에서 하나 돌아가고 있다고 보면 된다. 다만 웹 사이트가 로컬, 즉 앱을 설치한 기기 안에 내장되어 있어서 웹 페이지를 일일이 서버에 접속해서 받아오고 변경되는 내용이 있을 때마다 서버와 데이터가 왔다갔다 해야 하는 웹 앱보다는 빠르게 동작하고 네트워크 트래픽도 덜 먹는다. 반면 자마린은 네이티브, 즉 각 운영체제별 고유 코드와 UI를 활용하는 방식으로 만들어진다. 이와 같이 네이티브 앱을 만드는 크로스 플랫폼 개발 도구로는 페이스북의 리액트 네이티브나 텔레릭의 네이티브스크립트(NativeScript) 같은 것들이 있다. 코르도바의 방식이 하이브리드 앱보다는 빠르지만 역시 네이티브보다는 느리다는 단점이 있는데, 그런 면에서 보면 속도에서는 처음부터 각 운영체제별 개발 도구로 개발한 진짜 네이티브 앱보다는 느리지만 자마린도 상당히 좋은 결과물을 낸다.

꼭 크로스 플랫폼이 아니더라도, 기존 C# 개발자가 안드로이드나 iOS용 앱을 개발하기 위해 자바/코틀린이나 스위프트를 배울 필요가 없다는 것은 분명한 장점이다. 실제로 자마린 개발자 중에는 그런 사람들이 적지 않고.

개발 과정

처음에 프로젝트를 생성할 때에는 몇 가지 선택을 해야 한다. 일단 한번 선택을 하고 나면 바꾸기가 쉽지 않으므로 신중하게 선택해야 한다.

UI 구현

비즈니스 로직은 C#을 사용해서 구현하면 어느 운영체제에서든 쉽게 가져다 쓸 수 있다. 문제는 UI 부분. 각 운영체제별로 UI를 구성하는 요소나 레이아웃, 뷰의 구현 방법이 제각각이다. 아파치 코르도바는 네이티브 UI를 거의 무시하고 웹 페이지처럼 구현해서 사용하지만 자마린은 네이티브 UI를 최대한 활용한다. 따라서,

• UI는 각 운영체제별로 따로 구현을 한다. 이 때에도 C#을 사용해서 구현할 수 있다. 아니면 공유 라이브러리를 만들고 각 운영체제의 네이티브 개발 환경에서 불러다 쓰는 방법도 있긴 하지만 상당히 까다롭다. 그래도 자마린 측에서는 80% 이상의 코드는 공유할 수 있다고 주장한다.
• Xamarin.Forms를 사용해서 UI도 같은 코드로 구현하고 운영체제별로 만져줘야 하는 부분만 따로 만질 수 있다. 멀티 플랫폼 개발을 신속하게 할 수 있는 장점이 있지만 운영체제별로 따로 구현하는 것보다 UI에 제약이 많고 실제 결과물이 운영체제별로 미묘한 차이가 있는 건 어쩔 수 없어서 이걸 조정하는 과정도 꽤나 손이 간다. 업계의 설명에 따르면 약 90~95% 정도의 코드를 공유할 수 있다고 한다.

코드 공유 방법

운영체제에 관계 없이 공통으로 쓸 수 있는 코드를 어떻게 공유할지는 두 가지 옵션 중 하나를 선택해야 한다.

• 포터블 클래스 라이브러리 (Portable Class Library, PCL) : 공통되는 코드들이 DLL 형태로 만들어지고 이 라이브러리를 각 운영체제별 코드가 불러다 쓰는 구조다.
• 공유 자산 프로젝트 (Shared Asset Project, SAP) : DLL을 따로 만들지 않고 각 운영체제별 실행파일 안에 같이 들어간다.

크로스 플랫폼으로 개발할 때에는 PCL 쪽이 더 나은데, SAP으로 개발할 경우 리소스를 운영체제별 프로젝트에 따로 포함하고 공통 코드에는 전처리기를 써서 운영체제별로 리소스의 위치를 별도로 지정하는 번거로움이 있기 때문이다. PCL로 개발할 때에는 리소스를 라이브러리에 두고 공통 코드에서 사용하면 되기 때문에 편리하다. 외부 모듈을 쓸 때에도 비슷한 차이점이 있다. 물론 운영체제별 네이티브 코드가 많을 때에는 SAP 개발 쪽이 더 유리할 때도 많다. SAP에서는 전처리기를 못 쓰기 때문에 코드 안에서 운영체제 종류를 알아낸 다음에 그 종류에 따라 분기하는 식으로 구현해야 하지만 SAP이라면 전처리기를 사용해서 다른 운영체제의 코드는 건너뛰어버리면 되기 때문. 운영체제별 코드가 꽤 양이 많다면 최종 결과물의 양이나 속도 면에서 아무래도 차이가 있다. 또한 PCL로 개발하면 결국 실행파일과 DLL 파일 두 개를 만들고 DLL의 API를 부르는 식이 되므로 속도는 조금 차이가 나지만 고성능 게임이라면 모를까, 그 차이는 미미한 수준이다.

안드로이드용 앱은 윈도우 환경에서 에뮬레이터도 돌릴 수 있고 개발이 원활하지만 iOS용 앱은 윈도우 환경에서는 실행 파일을 만들 수 없어서 맥이 필요하고 Xcode도 설치해야 한다. 만약 주 개발 환경이 윈도우라면 윈도우와 맥을 네트워크로 연결하고 맥에서 빌드를 진행한다. 비주얼 스튜디오 엔터프라이즈 에디션을 쓰면 윈도우 환경에서도 iOS 에뮬레이터를 돌릴 수 있다. 문제는 엔터프라이즈 에디션 가격이 맥북보다 비싸다는 것. 그냥 맥북 사자.

평가

아무래도 C# 개발자들은 쓰던 언어로 모바일 앱을, 그것도 안드로이드와 아이폰, 개발해 봐야 별 볼일 없는 윈도우 모바일까지 개발할 수 있으므로 열광할 수밖에 없다. 그리고 완전한 네이티브 앱으로도 개발이 가능하다. 물론 각 운영체제별로 새로운 버전의 SDK가 나오면 자마린이 이를 지원하기까지는 시차가 좀 있긴 하지만 호환성을 생각한다면 보통은 구 버전과 호환되도록 개발하는 게 보통이므로 큰 문제는 아니다. 특히 유니티를 엔진으로 쓰는 게임 개발이라면 C# 하나로 다 되므로 더더욱 환영받을 만하다.

Xamarin.Forms에 대한 평가는 엇갈리는 편이다. 인터넷 후기를 보면 강추하는 사람들도 상당수 있지만 처음에는 기대에 부풀어서 손을 댔다가 결국은 갖가지 버그나 한계에 부딪쳐서 네이티브로 돌아왔다는 사람들도 많다. 아무래도 두 운영체제를 UI까지 같은 코드로 지원을 하다 보면 각자의 고유 기능 중 사용하지 못하는 게 은근히 꽤 있을 수밖에 없는지라... 개발 환경을 제대로 설치하기가 은근히 까다로워서 하라는대로 제대로 했는데도 컴파일이 제대로 안 되고 자꾸 이상한 에러가 터지기도 한다. 그래도 MS로서는 열심히 밀어주고 있는지라 빠르게 기능 개선이나 안정화가 꾸준하게 이루어지고 있다. MS 측에서도 각 운영체제 고유의 인터페이스를 활용해야 하는 앱이라면 네이티브 방식으로 자마린을 활용하고, 기본적인 UI를 가지고 빠르게 멀티 플랫폼을 개발해야 하는 앱이라면 Xamarin.Forms을 사용하라고 권고하고 있다.

크로스플랫폼 자체의 한계를 제외하고 가장 문제가 되는 것은 만들어진 앱의 크기인데, 보통 크로스플랫폼 앱이 네이티브 앱보다 용량이 크지만 자마린으로 개발한 앱은 .NET 프레임워크 런타임의 안드로이드 버전인 모노 런타임을 포함하고 있다 보니 실로 크고 아름답다는 게 문제. 별 기능도 없이 뼈대만 있는, 즉 IDE가 자동으로 생성한 것을 그대로 컴파일해도 16MB에 육박하는 앱이 나온다. 이중 10MB 가까이가 모노 프레임워크다. 최대한 쥐어짜서 최적화를 해도 한 자리 수로 떨어뜨리기 힘들다. 안드로이드 스튜디오가 생성한 비슷한 뼈대의 앱은 1MB 정도밖에 안 먹는 것과 비교하면 커도 너무 크다. 자마린 쪽에서도 이 문제는 고민하고 있고, 선택적인 클래스 라이브러리 링크로 .NET 런타임의 크기를 최소화하기 위한 최적화가 이루어지고 있다. 자기들 말로는 이렇게 최적화 옵션으로 컴파일을 하면 2.9MB 정도로 줄어든다고는 하지만 실제로는 그 정도까지는 잘 안 되는지라... 아무튼 크로스플랫폼 개발 환경은 쏟아지고 있지만 각자 장단점이 너무나 뚜렷하고 결국 각각이 안고 있는 단점이 무시할 수 없는 것들이 많은지라 개발자는 아파치 코르도바로 해야 할지, 리액트 네이티브로 해야 할지, 자마린으로 해야 할지 갈팡질팡할 수밖에 없다. 이걸 써 보니 이게 문제고, 저걸 써보니 이 문제는 괜찮은데 또 다른 문제가 골치아프고...

전망

모바일 앱 개발 시장의 점유율 면에서야 아직은 작다. 네이티브 개발이 제일 많고, 웹 앱이나 하이브리드 앱이 그 다음이고, 리액트 네이티브나 자마린은 성장 단계. 하지만 구글의 플러터가 인기를 끌면서 앞날이 좀 불투명해졌다. 아무래도 진입 장벽이라는 면에서는 자바스크립트가 낮기도 하고 이미 자바스크립트를 사용하는 웹 개발자가 많기 때문에 C# 기반의 자마린이 좀 불리할 수는 있다. 하지만 C# 자체가 좋은 언어이기 때문에 개발의 규모가 커지면 유지보수나 디버깅 측면에서는 유리하기도 하고, 윈도우 모바일이 대차게 망한 상태에서 MS로서는 모바일 앱 개발 시장의 주도권이라도 노려보자는 생각으로 자마린을 열심히 밀고 있다. 초기에는 굉장히 제한도 많고 버그도 많아서 덤볐다가 피본 사람들이 많지만 계속해서 기능이 향상되고 버그도 줄고 있어서 쓸만하다는 개발자, 더 나아가서는 강추하는 개발자들도 늘어나고 있다. 같은 자바스크립트를 이용하는 리액트 네이티브도 있다. 자바스크립트 계열 크로스플랫폼 개발환경이 워낙에 춘추전국시대다 보니 잘못 선택했다가 그 플랫폼이 망하면 나도 같이 망하지만 자마린은 그래도 망할 위험은 상대적으로 적다. MS로서는 어차피 윈도우 모바일이 지금도 빌빌거리고 있고 앞으로도 별 가망이 없으니 별 수 없다.

온라인 도움말도 꽤 잘 되어 있고, 윈도우 계열 개발에 관한 명저를 여럿 쓴 바 있는 찰스 페촐드가 쓴 <Creating Mobile Apps with Xamarin.Forms> eBook을 공짜로 풀기까지 했다. PDF 기준으로 무려 1187나 된다. 영어가 되는 초보자라면 이걸 보고 공부하면 무척 좋다. 상대적으로 한글 자료는 아직은 좀 부족한 편.

자마린의 미덕은 크게 두 가지다. 첫째는 C# 개발자가 다른 언어를 배울 필요 없이 안드로이드나 iOS용 앱을 개발할 수 있다는 것이고, Xamarin.Forms를 사용하면 같은 코드로 양쪽 운영체제의 앱을 동시에 개발할 수 이다는 것이다. 그런데 최근의 추세는 한 명의 개발자가 필요에 따라 몇 가지 언어를 배우고 사용하는 건 거의 기본이 되어 가고 있다. 과거의 C나 C++ 같은 언어에 비하면 요즘 개발에 쓰이는 언어는 배우기도 쉽고 툴의 지원도 좋다. 만약 C#를 할 줄 안다면 안드로이드라면 자바, 더 나아가서 요즘 구글에서 밀어주고 있는 코틀린을 배우는 건 쉽다. iOS라면 오브젝티브 C는 물론 애플이 새로 만든 Swift 역시 C# 개발자들이 적응하기 쉽다. 자마린이 아무리 좋다고 해도 네이티브로 밀어주는 개발 환경보다는 아무래도 부족한 점이 여러 가지가 있다. Xamarin.Forms의 경우에는 정말로 그 특징을 살려서 개발할 수 있는 앱의 범위가 좁다는 게 문제고, 각 운영체제의 네이티브 UI를 사용하다 보니 양쪽 운영체제에서 같은 앱의 동작이 미묘하게 다른 점이 많다는 것도 문제다.

그런데 구글에서 플러터(Flutter)라는 상당히 강력한 크로스 플랫폼 개발도구를 내놓아서 기존 크로스 플랫폼 개발 도구들의 강력한 라이벌로 대두되고 있다. 플러터는 이전의 크로스 플랫폼 개발도구와는 달리 각 OS별 인터페이스를 싹 무시하는 방식을 사용하고 있다. 예를 들어, 자마린이나 리액트 네이티브가 화면에 버튼을 표시한다면 운영체제가 안드로이드라면 안드로이드의 버튼 인터페이스를, iOS라면 iOS의 버튼 인터페이스를 사용해서 버튼을 그리는 것과는 달리 플러터는 운영체제가 제공하는 인터페이스를 싹 무시하고 자기가 버튼을 그리고 관리해 버리는 것. OS별 인터페이스를 이용하게 되면 아무래도 모양도 차이가 있고 OS가 인터페이스를 관리하는만큼 동작 방식도 약간씩 차이가 나지만 플러터 방식은 외관과 동작방식을 전부 플러터가 관리해 버리므로 운영체제에 관계 없이 똑같은 동작을 보장한다. 네이티브 인터페이스를 무시하고 자기가 바닥부터 인터페이스를 다 그리는 만큼 속도가 느리지 않나? 하고 생각할 수 있지만 실제로는 네이티브에 필적할 성능을 보여주고 있다. 구글에서는 안드로이드와 iOS는 물론 웹 개발까지도 플러터로 할 수 있도록 밀어붙이고 있어서 자마린에게는 가장 강력한 경쟁자로 대두되고 있다. 다만 플러터는 사용층이 얇은 다트(Dart) 언어인 게 문제지만 이건 언어 자체가 나빠서가 아니리서 플러터 사용층이 넓어짐에 따라 Dart 사용자도 빠르게 늘어나고 있는 추세다.

다른 제품/서비스

자마린 사에서는 크로스 플랫폼 앱 개발 도구인 자마린 플랫폼 말고도 다음과 같은 제품 및 서비스를 내놓고 있다.

자마린 테스트 클라우드

테스트 시나리오를 만들어 놓고 2,000개 이상의 모바일 기기에서 앱을 테스트해 볼 수 있는 서비스로, 동시에 테스트할 수 있는 기기의 수와 하루에 테스트 작업을 해 볼 수 있는 시간 제한에 따라서 월 단위 유료 과금된다. 테스트 시나리오의 작동 결과, 스크린샷, 성능 수치와 같은 자료들을 제공 받을 수 있다. 아무래도 대부분은 안드로이드 기기이고, iOS 및 윈도우 모바일 기기도 테스트할 수 있다.

자마린 유니버시티

자마린 관련 온라인 교육 프로그램을 제공한다. 무료로 들을 수 있는 강의도 있지만 상당 부분은 유료다. 비용은 2017년 기준으로 1년에 999 달러. 유료 가입을 하면 유료 강의를 들을 수 있는 것은 물론 강사에게 온라인으로 1:1 지도도 받을 수 있고, 학사 관리도 해 준다. 이쪽 개발자로 제대로 나가 볼 생각이라면 그리 비싼 수업료도 아니므로 투자 가치 있다.