.NET MAUI: 두 판 사이의 차이

내위키
편집 요약 없음
 
(같은 사용자의 중간 판 21개는 보이지 않습니다)
1번째 줄: 1번째 줄:
Xamarin.
.NET Multi-platform App UI.


크로스플랫폼 애플리케이션 개발 도구이자 이를 만드는 회사의 이름이기도 하다. 정확하게 말하자면 크로스플랫폼 앱 개발 도구는 자마린 플랫폼(Xamarin Platform)이다. 원래 이 회사는 [[.NET]] 프레임워크를 [[리눅스]]에서 돌리는 모노 프로젝트를 개발했는데 자마린도 여기에서 파생된 것으로, 개발 언어는 당연히 [[C샵|C#]]이다. 원래는 [[안드로이드]]와 [[iOS]], [[윈도우 모바일]]을 지원하므로 모바일 개발도구로 널리 알려져 있지만 윈도우 RT 환경 및 실버라이트<ref>하지만 실버라이트는 [[MS]] 쪽에서도 점점 손을 놓는 분위기라, <del>플래시도 망하가는 판에 뭐...</del> [[비주얼 스튜디오]]의 프로젝트 생성 때 실버라이트 템플릿은 제거된 상태이고,  장래에는 지원을 중단할 것(deprecated)이라고 밝히고 있다.</ref>, [[윈도우10]]에서 데스크톱과 모바일을 동시 지원하는 유니버셜 윈도우 플랫폼 앱 환경까지 지원하기 때문에 데스크톱으로까지 확장될 수 있다. 하지만 모바일용, 특히 [[안드로이드]]와 [[iOS]] 크로스플랫폼 개발을 위해 쓰는 경우가 압도적으로 많으므로 다른 건 무시해도 좋을 정도다.
원래는 자마린(Xamarin)이라는 이름으로 시작된 프로젝트다.


[[윈도우 모바일]]이야 [[C샵|C#]]을 쓰지만 [[안드로이드]]는 [[자바]], [[애플]]은 Objective-C → [[Swift]] 언어를 사용하고 있는데, 자마린은 각 운영체제별 API를 몽땅 [[C샵|C#]]으로 구현해 놓았다. 즉, [[C샵|C#]] 하나만 쓰면 두 운영체제 및 [[윈도우 모바일]]을 한 가지 언어로 개발할 수 있는 것. <ref>그런데 2016년부터 [[오라클]][[자바]] 관련 소송에 지친 [[구글]][[자바]] 대신 [[Swift]]로 갈 지도 모른다는 얘기가 돌고 있다. 그러면 [[Swift]] 하나로 [[안드로이드]]와 [[iOS]]를 다 개발할 있게 되는 셈. 실제 개발 과정은 많이 다르겠지만 비즈니스 로직만 공유할 수 있어도 그게 어딘데. 하지만 [[안드로이드 스튜디오]] 3.0을 내놓으면서 Swift가 아니라 자바와 VM 기반 언어인 [[코틀린]]을 공식 지원하고 있고, 아예 주 개발 언어를 [[코틀린]]으로 옮길 가능성이 높다.</ref>
[[크로스 플랫폼]] 애플리케이션 개발용 [[프레임워크]]이자 이를 만드는 회사의 이름이기도 하다. 정확하게 말하자면 [[크로스 플랫폼]] 앱 개발 도구는 자마린 플랫폼(Xamarin Platform)이다. 원래 이 회사는 [[.NET 프레임워크]]를 [[리눅스]]에서 돌리는 모노 프로젝트를 개발했는데 자마린도 여기에서 파생된 것이다. 즉 [[.NET]]을 [[리눅스]]에서 돌릴 수 있으면 [[.NET]] 기반 앱을 [[윈도우]] 아닌 다른 운영체제에서 돌리는 것도 가능하겠네? 어차피 [[안드로이드]]는 [[커널]]이 [[리눅스]], iOS도 XNU [[커널]]은 [[유닉스]] 계열이니까 말이지? 하는 생각에서 탄생한 프로젝트다. [[.NET]] 기반이니 개발 언어는 당연히 [[C샵|C#]]이다. 원래는 [[안드로이드]][[iOS]], [[윈도우 모바일]]을 지원하므로 모바일 개발도구로 널리 알려져 있지만 [[윈도우]] RT 환경 및 실버라이트<ref>하지만 실버라이트는 [[MS]] 쪽에서도 점점 손을 놓는 분위기라, <del>플래시도 망하가는 판에 뭐...</del> [[비주얼 스튜디오]]의 프로젝트 생성 때 실버라이트 템플릿은 제거된 상태이고, 장래에는 지원을 중단할 것(deprecated)이라고 밝히고 있다.</ref>, [[윈도우 10]]에서 데스크톱과 모바일을 동시 지원하는 유니버셜 윈도우 플랫폼, 추가로 [[macOS]] 앱 환경까지 지원하기 때문에 데스크톱으로까지 확장될 있다. 하지만 모바일용, 특히 [[안드로이드]][[iOS]] [[크로스플랫폼]] 개발을 위해 쓰는 경우가 압도적으로 많으므로 다른 건 무시해도 좋을 정도다.


과거에는 유료였기 때문에 '비싸기만 하고 허접하다'는 분위기로 큰 인기가 없었지만 2016년 초에 [[MS]]가 인수하고 무료로 풀어버리면서 관심히 확 높아졌다. 게다가 [[MS]]가 모바일 시장에 나름대로 사활을 건 프로젝트 중 하나라서 적극 밀어주고 있어서 기능이나 안정화가 계속 향상되고 있다. 아예 [[오픈 소스]]로 [[깃허브]]에 소스를 올렸고  [[MIT 라이선스]]가 적용된다. [[비주얼 스튜디오]] 커뮤니티 에디션에 자마린을 사용하면 완전 공짜. 다만 [[윈도우]]는 [[비주얼 스튜디오]], [[맥]]은 [[자마린 스튜디오]]개발환경이 거의 고정되어 있다. 하지만 [[비주얼 스튜디오]]가 워낙에 좋은지라 무료로 쓸 수 있는데 딴 걸 굳이 찾을 필요는...
[[윈도우 모바일]]이야 [[C샵|C#]]을 쓰지만 [[안드로이드]]는 [[자바]], [[애플]]은 Objective-C → [[Swift]] 언어를 사용하고 있는데, 자마린은 각 운영체제별 API를 몽땅 [[C샵|C#]]으로 구현해 놓았다. 즉, [[C샵|C#]] 하나만 쓰면 두 운영체제 및 [[윈도우 모바일]]을 한 가지 언어로 개발할 수 있는 것. <ref>그런데 2016년부터 [[오라클]]과 [[자바]] 관련 소송에 지친 [[구글]]이 [[자바]] 대신 [[Swift]]로 갈 지도 모른다는 얘기가 돌고 있다. 그러면 [[Swift]] 하나로 [[안드로이드]]와 [[iOS]]를 다 개발할 수 있게 되는 셈. 실제 개발 과정은 많이 다르겠지만 비즈니스 로직만 공유할 수 있어도 그게 어딘데. 하지만 [[안드로이드 스튜디오]] 3.0을 내놓으면서 Swift가 아니라 [[자바]]와 VM 기반 언어인 [[코틀린]]을 공식 지원하고 있고, 아예 주 개발 언어를 [[코틀린]]으로 옮길 가능성이 높다. 실제로 구글은 2019년 들어서 중심축을 [[코틀린]]으로 옮긴 상태다.</ref>
 
과거에는 유료였기 때문에 '비싸기만 하고 허접하다'는 분위기로 큰 인기가 없었지만 2016년 초에 [[MS]]가 인수하고 무료로 풀어버리면서 관심히 확 높아졌다. 게다가 [[MS]]가 모바일 시장에 나름대로 사활을 건 프로젝트 중 하나라서 적극 밀어주고 있어서 기능이나 안정화가 계속 향상되고 있다. 아예 [[오픈 소스]]로 [[깃허브]]에 소스를 올렸고  [[MIT 라이선스]]가 적용된다. [[비주얼 스튜디오]] 커뮤니티 에디션에 자마린을 사용하면 완전 공짜. 다만 [[윈도우]]는 [[비주얼 스튜디오]], [[맥]]은 [[비주얼 스튜디오]] for 맥<ref>원래는 이름이 '자마린 스튜디오'였다가 [[비주얼 스튜디오]] for 맥으로 바뀌었다.</ref>으로 개발환경이 거의 고정되어 있다. [[비주얼 스튜디오]]가 워낙에 좋은지라 무료로 쓸 수 있는데 딴 걸 굳이 찾을 필요는...
 
[[MS]]는 .NET MAUI(Multi platform App UI) 프로젝트를 진행하면서 자마린을 흡수할 계획을 밝혔으며, 실제로 2024년 5월 1일부로 자마린 지원을 중단하고 .NET MAUI로 옮겨갈 것을 권고하고 있다.<ref>[https://learn.microsoft.com/en-gb/dotnet/maui/migration/?view=net-maui-8.0&WT.mc_id=dotnet-35129-website "Upgrade from Xamarin to .NET"], Microsoft Learn, 26 January 2024.</ref>


==특징==
==특징==


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


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


==개발 과정==
==개발 과정==
22번째 줄: 28번째 줄:


* UI는 각 운영체제별로 따로 구현을 한다. 이 때에도 [[C샵|C#]]을 사용해서 구현할 수 있다. 아니면 공유 라이브러리를 만들고 각 운영체제의 네이티브 개발 환경에서 불러다 쓰는 방법도 있긴 하지만 상당히 까다롭다. 그래도 자마린 측에서는 80% 이상의 코드는 공유할 수 있다고 주장한다.
* UI는 각 운영체제별로 따로 구현을 한다. 이 때에도 [[C샵|C#]]을 사용해서 구현할 수 있다. 아니면 공유 라이브러리를 만들고 각 운영체제의 네이티브 개발 환경에서 불러다 쓰는 방법도 있긴 하지만 상당히 까다롭다. 그래도 자마린 측에서는 80% 이상의 코드는 공유할 수 있다고 주장한다.
* Xamarin.Forms를 사용해서 UI도 같은 코드로 구현하고 운영체제별로 만져줘야 하는 부분만 따로 만질 수 있다. 멀티 플랫폼 개발을 신속하게 할 수 있는 장점이 있지만 운영체제별로 따로 구현하는 것보다 UI에 제약이 많고 실제 결과물이 운영체제별로 미묘한 차이가 있는 건 어쩔 수 없어서<ref>미묘한 차이는 그냥 무시해도 될 것 같지만 은근히 눈에 걸리기도 하고, UI는 이런 미묘한 부분이 사용자 편의성에 큰 영향을 때도 종종 있다.</ref> 이걸 조정하는 과정도 꽤나 손이 간다. 업계의 설명에 따르면 약 90~95% 정도의 코드를 공유할 수 있다고 한다.<ref>Xamarin.Forms로 개발했다고 해도 운영체제별로 따로 코드를 첨가해 줄 수 있다. 이는 운영체제별 프로젝트에 넣을 수도 있고, 간단한 거라면 공통 코드에 전처리기를 사용하는 방법도 있다. 하지만 운영체제별 메인 언어를 사용할 수는 없고 [[C샵|C#]]으로 해야 한다.</ref><ref>네이티브 UI를 거의 무시하고 웹 페이지로 돌리는 코르도바라고 해도 운영체제별로 만져줘야 하는 부분이 아주 없는 건 아니다. 네이티브 API를 불러와야 할 때에는 [[자바스크립트]]보다 [[C샤프|C#]]이 확실히 편하다.</ref>
* Xamarin.Forms를 사용해서 UI도 같은 코드로 구현하고 운영체제별로 만져줘야 하는 부분만 따로 만질 수 있다. 멀티 플랫폼 개발을 신속하게 할 수 있는 장점이 있지만 운영체제별로 따로 구현하는 것보다 UI에 제약이 많고 실제 결과물이 운영체제별로 미묘한 차이가 있는 건 어쩔 수 없어서<ref>미묘한 차이는 그냥 무시해도 될 것 같지만 은근히 눈에 걸리기도 하고, UI는 이런 미묘한 부분이 사용자 편의성에 큰 영향을 때도 종종 있다.</ref> 이걸 조정하는 과정도 꽤나 손이 간다. 업계의 설명에 따르면 약 90~95% 정도의 코드를 공유할 수 있다고 한다.<ref>Xamarin.Forms로 개발했다고 해도 운영체제별로 따로 코드를 첨가해 줄 수 있다. 이는 운영체제별 프로젝트에 넣을 수도 있고, 간단한 거라면 공통 코드에 전처리기를 사용하는 방법도 있다. 하지만 운영체제별 메인 언어를 사용할 수는 없고 [[C샵|C#]]으로 해야 한다.</ref><ref>네이티브 UI를 거의 무시하고 웹 페이지로 돌리는 코르도바라고 해도 운영체제별로 만져줘야 하는 부분이 아주 없는 건 아니다. 네이티브 API를 불러와야 할 때에는 [[자바스크립트]]보다 [[C샵|C#]]이 확실히 편하다.</ref>


===코드 공유 방법===
===코드 공유 방법===
37번째 줄: 43번째 줄:
==평가==
==평가==


아무래도 [[C샵|C#]] 개발자들은 쓰던 언어로 모바일 앱을, 그것도 [[안드로이드]]와 [[아이폰]], <del>개발해 봐야 별 볼일 없는</del> [[윈도우 모바일]]까지 개발할 수 있으므로 열광할 수밖에 없다. 그리고 완전한 네이티브 앱으로도 개발이 가능하다. 물론 각 운영체제별로 새로운 버전의 [[SDK]]가 나오면 자마린이 이를 지원하기까지는 시차가 좀 있긴 하지만 호환성을 생각한다면 보통은 구 버전과 호환되도록 개발하는 게 보통이므로<ref>예를 들어 [[안드로이드]] 앱은 버전 7에 해당하는 [[누가]]가 나왔는데도 아직도 4.4 수준인 킷캣을 최소 구동환경으로 개발하는 앱이 대다수다. 물론 이는 [[구글]]에서 새 버전의 UI를 구 버전에서 소프트웨어 방식으로 지원하는 키트를 내놓고 있다는 이유가 크지만.</ref> 큰 문제는 아니다.
아무래도 [[C샵|C#]] 개발자들은 쓰던 언어로 모바일 앱을, 그것도 [[안드로이드]]와 [[아이폰]], <del>개발해 봐야 별 볼일 없는</del> [[윈도우 모바일]]까지 개발할 수 있으므로 열광할 수밖에 없다. 그리고 완전한 네이티브 앱으로도 개발이 가능하다. 물론 각 운영체제별로 새로운 버전의 [[SDK]]가 나오면 자마린이 이를 지원하기까지는 시차가 좀 있긴 하지만 호환성을 생각한다면 보통은 구 버전과 호환되도록 개발하는 게 보통이므로<ref>예를 들어 [[안드로이드]] 앱은 버전 7에 해당하는 [[누가]]가 나왔는데도 아직도 4.4 수준인 킷캣을 최소 구동환경으로 개발하는 앱이 대다수다. 물론 이는 [[구글]]에서 새 버전의 UI를 구 버전에서 소프트웨어 방식으로 지원하는 키트를 내놓고 있다는 이유가 크지만.</ref> 큰 문제는 아니다. 특히 유니티를 엔진으로 쓰는 게임 개발이라면 [[C샵|C#]] 하나로 다 되므로 더더욱 환영받을 만하다.


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


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


==전망==
==전망==


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


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


그런데 [[구글]]에서 [[플러터]](Flutter)라는 상당히 강력한 [[크로스 플랫폼]] 개발도구를 내놓아서 강력한 라이벌로 대두되고 있다. [[플러터]]는 이전의 [[크로스 플랫폼]] 개발도구와는 달리 각 OS별 인터페이스를 싹 무시하는 방식을 사용하고 있다. 예를 들어, 자마린에서 화면에 버튼을 놓는다면 자마린 프레임워크가 [[안드로이드]]라면 [[안드로이드]]의 버튼 인터페이스를, [[iOS]]라면 [[iOS]]의 버튼 인터페이스를 사용해서 버튼을 그리는 것과는 달리 [[플러터]]는 운영체제가 제공하는 인터페이스를 싹 무시하고 자기가 버튼을 그리고 관리해 버리는 것. OS별 인터페이스를 이용하게 되면 아무래도 모양도 차이가 있고 OS가 인터페이스를 관리하는만큼 동작 방식도 약간씩 차이가 나지만 [[플러터]] 방식은 외관과 동작방식을 전부 [[플러터]]가 관리해 버리므로 운영체제에 관계 없이 똑같은 동작을 보장한다.
자마린의 미덕은 크게 두 가지다. 첫째는 [[C샵|C#]] 개발자가 다른 언어를 배울 필요 없이 [[안드로이드]]나 [[iOS]]용 앱을 개발할 수 있다는 것이고, Xamarin.Forms를 사용하면 같은 코드로 양쪽 운영체제의 앱을 동시에 개발할 수 이다는 것이다. 그런데 최근의 추세는 한 명의 개발자가 필요에 따라 몇 가지 언어를 배우고 사용하는 건 거의 기본이 되어 가고 있다. 과거의 [[C]]나 [[C++]] 같은 언어에 비하면 요즘 개발에 쓰이는 언어는 배우기도 쉽고 툴의 지원도 좋다. 만약 [[C샵|C#]]를 할 줄 안다면 안드로이드라면 [[자바]], 더 나아가서 요즘 구글에서 밀어주고 있는 [[코틀린]]을 배우는 건 쉽다. [[iOS]]라면 오브젝티브 C는 물론 애플이 새로 만든 Swift 역시 [[C샵|C#]] 개발자들이 적응하기 쉽다. 자마린이 아무리 좋다고 해도 네이티브로 밀어주는 개발 환경보다는 아무래도 부족한 점이 여러 가지가 있다. Xamarin.Forms의 경우에는 정말로 그 특징을 살려서 개발할 수 있는 앱의 범위가 좁다는 게 문제고, 각 운영체제의 네이티브 UI를 사용하다 보니 양쪽 운영체제에서 같은 앱의 동작이 미묘하게 다른 점이 많다는 것도 문제다.
 
그런데 [[구글]]에서 [[플러터]](Flutter)라는 상당히 강력한 [[크로스 플랫폼]] 개발도구를 내놓아서 기존 크로스 플랫폼 개발 도구들의 강력한 라이벌로 대두되고 있다. [[플러터]]는 이전의 [[크로스 플랫폼]] 개발도구와는 달리 각 OS별 인터페이스를 싹 무시하는 방식을 사용하고 있다. 예를 들어, 자마린이나 리액트 네이티브가 화면에 버튼을 표시한다면 운영체제가 [[안드로이드]]라면 [[안드로이드]]의 버튼 인터페이스를, [[iOS]]라면 [[iOS]]의 버튼 인터페이스를 사용해서 버튼을 그리는 것과는 달리 [[플러터]]는 운영체제가 제공하는 인터페이스를 싹 무시하고 자기가 버튼을 그리고 관리해 버리는 것.<ref>모바일 게임이 주로 이런 방법을 사용해 왔다.</ref> OS별 인터페이스를 이용하게 되면 아무래도 모양도 차이가 있고 OS가 인터페이스를 관리하는만큼 동작 방식도 약간씩 차이가 나지만 [[플러터]] 방식은 외관과 동작방식을 전부 [[플러터]]가 관리해 버리므로 운영체제에 관계 없이 똑같은 동작을 보장한다. 네이티브 인터페이스를 무시하고 자기가 바닥부터 인터페이스를 다 그리는 만큼 속도가 느리지 않나? 하고 생각할 수 있지만 실제로는 네이티브에 필적할 성능을 보여주고 있다. [[구글]]에서는 안드로이드와 iOS는 물론 웹 개발까지도 플러터로 할 수 있도록 밀어붙이고 있어서 자마린에게는 가장 강력한 경쟁자로 대두되고 있다. 다만 [[플러터]]는 사용층이 얇은 [[다트]]([[Dart]]) 언어인 게 문제지만 이건 언어 자체가 나빠서가 아니리서 플러터 사용층이 넓어짐에 따라 [[Dart]] 사용자도 빠르게 늘어나고 있는 추세다.


==다른 제품/서비스==
==다른 제품/서비스==


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


===자마린 테스트 클라우드===
===자마린 테스트 클라우드===

2024년 5월 14일 (화) 20:16 기준 최신판

.NET Multi-platform App UI.

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

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

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

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

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

특징

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

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

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

개발 과정

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

UI 구현

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

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

코드 공유 방법

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

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

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

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

평가

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

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

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

전망

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

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

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

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

다른 제품/서비스

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

자마린 테스트 클라우드

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

자마린 유니버시티

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

각주

  1. 하지만 실버라이트는 MS 쪽에서도 점점 손을 놓는 분위기라, 플래시도 망하가는 판에 뭐... 비주얼 스튜디오의 프로젝트 생성 때 실버라이트 템플릿은 제거된 상태이고, 장래에는 지원을 중단할 것(deprecated)이라고 밝히고 있다.
  2. 그런데 2016년부터 오라클자바 관련 소송에 지친 구글자바 대신 Swift로 갈 지도 모른다는 얘기가 돌고 있다. 그러면 Swift 하나로 안드로이드iOS를 다 개발할 수 있게 되는 셈. 실제 개발 과정은 많이 다르겠지만 비즈니스 로직만 공유할 수 있어도 그게 어딘데. 하지만 안드로이드 스튜디오 3.0을 내놓으면서 Swift가 아니라 자바와 VM 기반 언어인 코틀린을 공식 지원하고 있고, 아예 주 개발 언어를 코틀린으로 옮길 가능성이 높다. 실제로 구글은 2019년 들어서 중심축을 코틀린으로 옮긴 상태다.
  3. 원래는 이름이 '자마린 스튜디오'였다가 비주얼 스튜디오 for 맥으로 바뀌었다.
  4. "Upgrade from Xamarin to .NET", Microsoft Learn, 26 January 2024.
  5. 요즘은 타입스크립트도 많이 사용한다. Angular 2가 이걸 채용한 게 컸다. 어차피 타입스크립트를 컴파일하면 자바스크립트가 나오므로 자바스크립트로 개발할 수 있는 건 무엇이든 타입스크립트로도 개발할 수 있다. 그런데 타입스크립트MS가 만든 거다.
  6. 미묘한 차이는 그냥 무시해도 될 것 같지만 은근히 눈에 걸리기도 하고, UI는 이런 미묘한 부분이 사용자 편의성에 큰 영향을 줄 때도 종종 있다.
  7. Xamarin.Forms로 개발했다고 해도 운영체제별로 따로 코드를 첨가해 줄 수 있다. 이는 운영체제별 프로젝트에 넣을 수도 있고, 간단한 거라면 공통 코드에 전처리기를 사용하는 방법도 있다. 하지만 운영체제별 메인 언어를 사용할 수는 없고 C#으로 해야 한다.
  8. 네이티브 UI를 거의 무시하고 웹 페이지로 돌리는 코르도바라고 해도 운영체제별로 만져줘야 하는 부분이 아주 없는 건 아니다. 네이티브 API를 불러와야 할 때에는 자바스크립트보다 C#이 확실히 편하다.
  9. 안드로이드 SDK와 함께 제공되는 에뮬레이터를 쓸 수도 있지만 비주얼 스튜디오에서 제공되는 에뮬레이터가 하이퍼-V 가상화 기술을 사용하기 때문에 되려 속도가 더 빠르다. 심지어 이 에뮬레이터를 안드로이드 스튜디오에서 사용하는 것도 가능하다! 이렇게 쓰면 USB 연결 기기처럼 인식된다. 자세한 설정 방법은 여기를 참조하자.
  10. 예를 들어 안드로이드 앱은 버전 7에 해당하는 누가가 나왔는데도 아직도 4.4 수준인 킷캣을 최소 구동환경으로 개발하는 앱이 대다수다. 물론 이는 구글에서 새 버전의 UI를 구 버전에서 소프트웨어 방식으로 지원하는 키트를 내놓고 있다는 이유가 크지만.
  11. 하지만 비주얼 스튜디오는 아파치 코르도바 환경도 꽤 열심히 지원해 주고 있다.
  12. 모바일 게임이 주로 이런 방법을 사용해 왔다.