앱개발, 이젠 다시 크로스개발이다
Xamarin.Forms 로 올비 앱 출시하기까지
2018-08-17 수정: 지금은 시간이 또 흘러 상황이 많이 바뀌었음을 알려드리고자 합니다. Xamarin.Forms 는 React Native 와 경쟁에 있어 그 격차가 상당히 많이 밀려났습니다. 깃허브 스타 숫자의 차이가 20배 이상 나고있고, MS에서도 Xamarin 인수이후 여전히 자사 제품에 자마린을 사용하지 않고있고 Xamarin 팀원 충원에도 미온적인 태도를 보인지 꽤 지났습니다. Xamarin.Forms 생태계도 생각만큼 성장하지 않았습니다.
Xamarin에 대해 이렇게까지 긍정적으로 글을 적은 후에 말을 돌리는것이 곤혹스럽습니다만 지금은 저는 꽤 오랫동안 개인앱/회사에서 사용하는 React Native를 사용하고 있고 또 추천합니다. 매우 안정적이고, 생산성/퍼포먼스도 좋고 커뮤니티/생태계가 정말 큽니다. 또 Google의 Flutter는 한세대 진화한 툴로서 앞으로 유망할것 같고요 무엇보다 OS개발사에서 크로스플랫폼 툴을 만들었다는 점이 가장 주요한 강점입니다. 단점으로는 아직 나온지가 얼마 안되어 충분히 성장하지 못한 생태계가 있겠구요.
자마린(Xamarin)은 마이크로소프트(MS) 진영에서 오래 일한 개발자들에게 대단한 희소식이다. 자신의 경험과 기술을 그대로 이용해 모바일 앱을 만들 수 있다. 개발자라면 누구나 자신의 앱 하나쯤 핫한 모바일 앱 시장에 내놓고 싶을 것이다. 그러나 iOS와 안드로이드 개발은 부담없이 도전할 영역은 아니다.
필자는 인디 게임 개발자로 업계에 첫 발을 들였다. 첫 개발작을 앱스토어에서 판매했고 비교적 쉽게 게임회사에 취직해 5년간 모바일 게임을 만들었다. 크로스 플랫폼 개발은 게임 개발자에게 너무나 당연했다. iOS와 안드로이드에서 각각 개발하는 것은 초기 모바일 진입시기에나 있던 일이었다. 요즘은 ‘cocos2d-x’나 ‘Unity3D’ 게임엔진을 이용하면 작업 한번으로 양쪽 게임을 모두 완성할 수 있다. ‘Unity3D’는 PC용까지 만들어낸다.
이 글은 게임개발자이자 iOS 앱 개발자가 적는 ‘자마린’ 도입기다. 그래서 자마린을 구성하는 .NET 프레임워크나 C# 내용에 대해 전문적으로 다루기에는 부족하다. 이번 프로젝트를 시작하며 C#을 처음 배웠다. 이런 점 때문에 자마린을 고민하는 분들에게 더 좋은 가이드로 다가서기를 바란다. 또, 다양한 IT 업계 종사자들에게도 자마린 이해에 도움이 되었으면 한다.
The smart ones don’t tell you
크로스 플랫폼 개발이라는 말을 듣자마자 '에이 그래도 제대로 된 앱을 만들려면 따로따로 만들어야지..' 혹은 '그런건 금융권 앱이나 하는거야' 라고 생각하시는 분들께 아래의 링크를 추천한다.
- 당신이 하이브리드 앱인지 모른채 사용한 8가지 웰메이드 앱
두번째 링크글에서는 심지어 "The smart ones don’t tell you." 라는 말까지! 이쯤되면 생각을 조금은 열어봐야 하지 않을까. 아무튼 서두는 이렇게 시작하지만, 앞으로 설명할 'Xamarin'도 네이티브다!
코더가 아닌 ‘개발자'이고 싶다. 꿈꿔오던 크로스 플랫폼 앱
작업 한번에 모든 플랫폼의 앱이 만들어진다면 얼마나 좋을까, 사실 이 문제는 모바일 시대가 열린 5~6년 전부터 수많은 개발자들이 한번쯤은 바래왔던 것이다. 현재의 방식은 아무래도 개발팀을 효율적으로 운용하기 위해서 연구개발팀과 포팅(한 플랫폼 혹은 OS용으로 완성된 프로그램을 다른 플랫폼 용으로 다시 제작하는 것)팀 으로 나누게 되는데 포팅을 담당하는 인력은 아무래도 제품의 기획과정까지 참여할 여유는 없어 포팅을 위한 코딩을 하게된다. 게다가 까다롭고 반복된 포팅은 원작과 싱크를 맞추는 과정에서 버그유발자로 변해버린다. 여러모로 스트레스가 많은 작업이다. 크로스 플랫폼 개발을 한다면 이러한 과정을 생략할 수 있어 모든 개발자가 함께 고민하고 기획하며 제품만을 만들어가는것이 가능해 지는 것이다.
모바일 개발역사에 있어 크로스 플랫폼은 꽤나 뜨거운 감자같은 존재다. 하이브리드 앱에 대한 관심은 수많은 회사들의 연구로 시작해 PhoneGap, React Native에 이어 지금의 자마린까지 왔다. 이러한 시도들은 여러 한계 때문에 끝내 좌절돼었다. 페이스북이 하이브리드 앱으로 출시했다가 발생하는 역경들을 극복하지 못하고 끝내 각기 네이티브 앱으로 회기한것은 많이 알려진 이야기이다. 그러니 파편화되어있는 일반 앱 개발환경을 보는 게임개발자는 "차라리 게임엔진으로 일반 앱 한방에 만드는게 낫겠다"라는 우스겟 소리까지 나오기도 한다. 그런 상황들이 계속됐지만 자마린은 달랐다. 그것에 대해서 뒤에서 계속 이야기 하겠다.
창업과 킥스타터
2015년에 지금의 김명진 대표를 만나 나는 게임개발자로서의 생활을 끝내고 ‘내 아이를 위한 웨어러블 디바이스'를 만드는 스타트업 회사 ‘올비’를 공동창업하게 되었다.
올비는 영유아가 착용하는 웨어러블 기기이다. 아기의 피부온도, 무호흡 감지, 수면패턴 등을 수집하고 부모에게 수집한 데이터를 육아상식과 함께 알려준다. 직장에서도 사랑스러운 내 아기의 상태를 확인할 수 있다. 우리 팀 올비의 첫번째 과제는 제품 프로토타입을 만들고 킥스타터에 런칭해서 실제 고객들의 반응을 보는 것이였다.
iOS앱 개발자기도 했던 나는 킥스타터에 선보이기 위해 iOS앱을 먼저 만들었다. 킥스타터로 좋은 결과를 얻게된다면 안드로이드 개발자를 새로 영입하여 포팅을 맡기거나 상황이 여의치 않으면 내가 어떻게든 독학해서 제품출시일에 맞춰 안드로이드 앱까지 만들겠다는 계획이였다. iOS앱 개발은 순조로와서 부가기능인 채팅기능 까지도 구현이 완료되었다.
어느정도 완성도를 갖췄던 올비 iOS 앱올비 앱 제작과정의 고민
2015년 10월에 올비를 공동창업한 후 다음 해인 2016년 3월에 킥스타터에 순조롭게 런칭해 선판매를 진행했고 올비는 킥스타터에서 3만1052달러, 카카오 스토리펀딩에서 선판매로 약 1300만원의 성과를 거두었다.
그러나 하드웨어 펌웨어도 개발해야 하는 상황에서 iOS, 안드로이드 플랫폼의 앱을 만드는 것은 쉬운 일이 아니였다. 보통 스타트업은 한 플랫폼의 앱을 먼저 만들어서 시장의 반응을 본 후에 그에 따라 다른쪽 플랫폼을 출시하는것이 일반적이며, 리스크를 많이 줄일 수 있는 방법이다. 그러나 하드웨어 제품은 시장반응을 살펴보며 차근차근 진행하는 것이 허락되지 않는다. 고객은 고가의 제품을 구매했는데 사고봤더니 내 스마트폰은 안된다고? 이해를 해줄 만한 것이 아니다.
올비, 킥스타터 소개 페이지아이폰앱, 안드로이드앱 모두 동시에 출시해야만 한다. “그래 안드로이드 앱까지 만들자.” 그러나 여기서 발생한 가장 큰 문제는 기준이 되는 iOS 올비 앱에 변경사항들이 끊임없이 생겼다는 사실이다. 제품출시전 사람들에게 테스팅하는 과정에서 예상과 달리 방향을 틀어야 할 일이 많이 생겼기 때문이다. 기존에 없던 제품을 만들어 내는 과정에서 이는 당연한 일이였지만 우리는 이정도 일줄은 예상하지 못했다. 약속한 제품완성, 배송일은 다가오는데 iOS앱은 당장 다음 테스트 후에 또 바뀌게될 판이고, 안드로이드 앱은 첫 삽조차 뜨지 못했다. 정말이지 사면초가였다. 일정중 3~4개월을 안드로이드 포팅 작업으로 잡아놨었는데 이미 그 기간은 한참 써버렸고 안드로이드 개발경험도 없는 내가 만들기에는 애초 말이 안되는 기간이였다. 킥스타터에서 엄청난 돈이라도 벌었으면 전문 안드로이드 개발자를 영입할 수 있었겠지만 그것도 아니였고 반복해 말하지만 본체인 iOS앱 자체가 아직도 미정이였다! 무엇을 포팅하겠는가...
그리고 이대로는 어찌저찌 포팅에 성공한다고 쳐도 출시 후에 분명 또 바뀔 것이다. 그때마다 양 플랫폼에 동일한 수정을 한다는게 굉장히 까다롭기도 하고 중요한것은 그 과정에서 버그가 발생할 소지가 많다는 것이 큰 문제이다.
MS의 자마린 인수와 무료화
2016년 4월 MS는 자마린을 인수하고 꽤 고가였던 이용료를 무료로 사용할 수 있게 했다. 2016년 5월 사면초가 상황의 올비는 그동안 꽤나 진행되었던 iOS 올비 앱을 뒤도 돌아보지 않고 버린 후에 자마린을 이용해 새로 만드는 계획으로 급선회 한다.
부끄럽게도 자마린이 뭔지도 잘 모르던 상황에서 지푸라기를 잡는 심정으로 ‘Hello World’를 찍고 몇번의 테스트 후에 급하게 도입을 결정했다. 다급한 심정이였기도 했지만 처음접한 자마린은 다행히도 쿨했고 MS의 인수와 무료화 시기는 우리를 위한 것이 아닌가 하는 마음까지 들었다. 결론부터 말하면 5월에 첫삽을 뜬 올비 자마린 버전 앱은 6개월만인 같은 해 11월1일 iOS와 안드로이드 플랫폼에 성공적으로 출시를 했다. 기적과도 같았다.
거의 대부분의 기능이 작동하던 iOS 올비 앱MS는 왜 자마린을 큰돈에 인수해서 무료로 풀었을까? MS의 입장과 업계의 이야기를 종합하면 모바일 시대 이후에 모바일 생태계를 구축하지 못한 MS의 히든카드라는 것이 중론이다. 윈도우폰은 아직까지도 이렇다할 점유율을 가져가지 못했다. MS가 마음만 먹으면 언제든 모바일 시장을 잡을 줄 알았지만 쉽사리 되지 않았다. 여러가지 이유가 있겠지만 윈도우폰용 앱이 적다는 문제가 있다. 닭이 먼저인지 달걀이 먼저인지 모르겠지만 윈도우폰 사용자가 많지 않으니까 앱 개발사들이 큰 인력을 들여서까지 윈도우폰용 앱을 만들 이유가 없고, 쓸 수 있는 앱이 많지 않으니 윈도우폰 사용자가 늘지 않는 악순환이 수년간 반복해온 것이다. MS가 카카오톡에게 윈도우폰용 카톡을 만들어달라고 오래도록 요청했던 것은 재미있는 사례다. 그런데 카톡은 그렇게 만든 앱조차도 작년 12월 블랙베리에 이어서 윈도우폰 서비스를 종료한다고 발표했다. 지원해야 할 플랫폼이 유지,보수,개선을 해야하는 앱 개발사와 이해관계가 맞질 않는 것이다.
윈도우폰 서비스를 종료하는 카카오톡그렇기 때문에 MS는 자마린을 인수해 앱개발사들이 널리 쓰이게 함으로서 윈도우앱 플랫폼인 ‘UWP(Universal Windows Platform)’용도 덩달아 쉽게 출시해 나가는 그림을 그리고 있는 것이다. MS의 희망처럼 자마린이 주류로 될 가능성은 높지 않아보인다. 그러나 자마린을 써본 사람이라면, 적어도 나만 해도 ‘이 방법이 앱개발의 대세가 되면 얼마나 좋을까' 하는 생각을 하게된다. 이점이 바로 자마린의 기대해볼 만한 무기가 아닐까?
앱스토어와 구글플레이에 동시출시한 Xamarin.Forms로 제작된 올비 앱Xamarin.Forms 의 등장
자마린은 먼저 ‘Xamarin.iOS’ 와 ‘Xamarin.Android’로 시작했다. 이것은 기존의 iOS, 안드로이드 플랫폼 개발방식을 그대로 사용하지만 개발 언어와 프레임워크만 딱 C#과 .NET 프레임워크 를 사용하는 것이다. 조금 단순히 말하자면 기존에 만든 iOS앱에 C#으로 똑같이 바꿔서 작성할 수 있도록 Mono를 이용해 iOS 와 Android SDK의 API들을 C#으로 매칭(Bind)시켜 놓은 것이다. 이것만으로도 C# 진영의 개발자들에겐 엄청난 소식이였다.
하지만 개발언어를 C#으로 사용할 수 있다는 것이 전부다. 현실적으로는 남은 숙제는 자마린으로 앱을 만들기 위해서 해당 모바일 OS의 API사용법을 숙지해야한다.
설명을 돕기 위해서 이 문제를 ‘우리가 쓰는 언어의 번역’으로 바꿔서 말을 해보자면 자마린이라는 자동번역기가 있다. 이 번역기는 한글을 쓰면 단어를 영어로 바꿔주는 번역기이다. 한국어(C#)가 영어(iOS)로 자동변환되긴 하지만 ‘나는 사과를 좋아해’ 가 ‘I like an apple’로 자동으로 변환되는 것이 아니라 ‘I apple like’ 라고 번역이 된다. 이러면 제대로 된 문장이 되지 않는다. 그러니 이 번역기를 사용해서 ‘I like an apple’ 이라는 결과를 얻으려면 ‘나는 사과를 좋아해'가 아니라 (조금 이상하지만) ‘나는 좋아해 (an) 사과’ 라고 사용해야 한다는 말이다. 즉 영어문법을 알지 못하면 결국 사용할 수 없다. 위의 예가 설명에 도움이 됐는지 모르겠다. 결론은 기존의 앱개발을 잘 알지 못하면 자마린만으론 제대로된 앱을 만들 수 없었다.
이런 와중에 ‘Xamarin.Forms’라는 것이 발표되었다. 이녀석은 한글로(C#) ‘나는 사과를 좋아해'라고 적으면 영어로는 ‘I like an apple’ 중국어로는 ‘我喜歡一個蘋果’ 라고 해당 언어의 용법까지 포함해서 완벽하게 만들어 주는 것이다. 개발 자체는 기존 ‘C#’, ‘WPF(Windows Presentation Foundation)’에 방식과 똑같이 만들었는데 결과물로는 iOS, 안드로이드 앱이 떡하니 나오는 것이다. ‘Xamarin.Forms’의 핵심은 UI를 통합하였다는 점과 그 개발방식으로 WPF 방식을 채택했다는 것이다. 기존에 WPF 으로 윈도우 프로그램을 만들듯이 ‘AbsoluteLayout’, ‘StackLayout’들을 ‘xaml’에 마음껏 작성한 코드가 앱이 되어 나온다. 그 과정에서 ‘Forms’가 수많은 작업들을 내부적으로 처리하는데 이때 문제는 이런 류의 개발툴은 여러 OS의 각 버전들을 다 커버하면서 안드로이드의 파편화까지 피할 정도로 완벽하게 만드는 것이 불가능에 가깝다는 데에 있다. 이런 이유로 그동안 크로스 플랫폼 개발이 많은 관심이 있었지만 제대로 성공할 수가 없었다.
‘Xamarin.Forms’도 2014년에 발표했지만 2016년 하반기에 발표한 2.3.3 버전 정도 되서야 안정적으로 사용할 수 있게 됐다. 이전까지는 너무나 불안정하고 크래쉬(비정상 종료)가 많이 일어났다. 쓸만해진 2.3.3 버전 조차도 현재 2.3.4-pre 릴리즈를 업데이트 하는 과정에서 수개월동안 100개가 넘는 버그를 수정하고 있을 정도이다. 이중 내가 제보해 패치중인 것만 벌써 5개이다.
최근 수개월만에 발견하고 고쳐진 버그만 해도 100개가 넘는 Xamarin.Forms이런 상황이긴 하지만 많은 회사들이 결국 해내지 못했던 것을 자마린 팀은 어떻게든 해나가고 있다. 하루가 다르게 점점 안정화 되고 있다. 그것도 꽤나 쓸만한 수준으로! 벅찬 응원을 보낸다.
진정한 네이티브 앱
여러차례 말했듯 크로스 플랫폼은 수많은 개발자들이 바랬던 것이다. 그러나 희망에 비해 현실은 냉혹했다. 하이브리드 앱부터 시작해서 QT, PhoneGap에 이어 최근에 React Native 등 의미있는 방법들이 발표했고 이를 적용해서 앱을 출시한 개발사들도 많았지만 각각의 한계들이 있었다. 자마린은 희망과 현실의 거리를 굉장히 많이 줄였다고 생각한다. 기존의 방식들이 가졌던 단점들을 커버하면서 ‘C#’과 ‘.NET’ 프레임워크라는 강력한 무기까지 가졌기 때문이다. 그리고 완벽한 네이티브 앱을 만들어 낸다는 점에서 큰 우위를 차지한다. 완벽한 네이티브 앱이란 쉽게 말해 자마린으로 만든 앱은 코드를 열어보지 않고서는 눈치 채지 못한다는 것이다. 또한 단순히 외형만 네이티브가 아니라 각 플랫폼이 갖는 고유한 UX를 그대로 살릴 수 있다는 점이 큰 매력이다.
앱을 구성하는 데 있어 최근의 가장 보편적이고 스탠다드한 UI는 상단 네비게이션바 + 탭바의 구성인데 iOS와 안드로이드의 가장 눈에 띄는 차이점은 탭바의 위치이다. 안드로이드의 탭바는 상단에 위치하는데 그럴 수 밖에 없는것이 안드로이드는 기본적으로 화면 하단에는 뒤로가기, 홈버튼 등의 가상버튼이 존재해 iOS처럼 하단에 탭바가 붙게되면 가상버튼과 같은 위치라 터치 오작동이 많이 발생해 탭바를 상단에 위치시킬 수 밖에 없다. 이런 사정과는 관계없이 기존의 크로스 플랫폼 개발은 iOS, 안드로이드에 상관없이 고정된 한쪽에 위치한 탭바가 나온다. 하지만 ‘Xamarin.Forms’에서는 동일한 코드인데도 네이티브 탭이 iOS는 하단에 안드로이드, UWP 는 상단에 위치하게 된다.
각 플랫폼이 갖는 고유한 UX는 복잡한 역사와 목적들을 담고있다. 몇가지 더 예를 들어보자면 아이폰의 경우 스티브잡스가 ‘스마트폰은 한손으로 조작 가능해야한다'라고 했던 초기시대에는 3.5인치의 작은 아이폰밖에 없었다. 그러나 팀쿡 체제의 애플이 4인치의 아이폰을 출시하면서 한가지 문제가 생겼다. 아이폰은 항상 화면 왼쪽상단에 ‘뒤로가기' 버튼이 위치하는데 화면이 큰 아이폰이 출시하면서 손가락이 닿지 않는다는 것이다. 애플은 ‘iOS7’에서 손가락으로 화면 왼쪽 끝에서 끌어당겨 ‘뒤로가는' 기능을 추가해 이를 해결했다.
또 iOS와 안드로이드의 큰 특징 중 하나는 iOS는 탭을 계층상 가장 상위에 놓고 각 탭에 각각의 네비게이션 페이지를 넣는 것이 표준이다. 안드로이드는 네비게이션을 가장 상위에 놓고 그 안에 탭을 넣고 각각 탭안에 페이지를 넣는 것이 표준이다. 물론 이것을 지키지 않고 마음대로 만들 수는 있지만 기본적인 방식이고 사용자의 경험을 해치지 않기 위해 지향해야한다. 이런 차이가 어떤 결과를 낳는가 하면, 아이폰의 경우 한 탭을 선택해 새로운 페이지로 계속 이동해도 여전히 탭이 더 상위에 있기 때문에 현재위치에서 탭 이동이 가능하다. 안드로이드는 다른 탭으로 이동하려면 다시 처음으로 돌아와야 한다.
첫번째 페이지에서 아기를 선택하면 iOS와 Android에서 각각 그림과 같이 아기페이지로 이동한다. iOS는 하단에 탭이 여전히 살아있어(상위에 있기 때문) 탭이동이 가능하다위 그림의 첫번째 페이지에서 아기를 선택하면 iOS와 Android에서 각각 두번째 세번째 그림과 같이 아기페이지로 이동한다. iOS는 하단에 탭이 여전히 살아있어(상위에 있기 때문) 탭이동이 가능한 반면 Android에선 현재 페이지에서 나와야만 다른 탭으로 이동할 수 있다.
아이폰 탭구성이 안드로이드 보다 좋다는 이야기가 아니다. 다만 양사가 이 이슈에 대한 접근방식에 차이가 있어 각기 다른 동작 규칙을 결정했다는 것이 중요한 점이다. 안드로이드 경우 새 페이지로 이동했을때 다른 탭으로 이동이 가능하다면 유저에게 혼란을 줄 수 있다는 생각에서 결정한 것이였다고 생각된다. 게다가 안드로이드는 스크롤로 탭간 이동이 가능하다. <위 그림>의 3번째 그림 상태에서 오른쪽으로 스크롤을 한다고해서 다음 탭으로 이동해 버린다면 어딘가 모르게 위화감이 들것이다. 또 아이폰은 스크롤로 탭간 이동이 되지 않는다. iOS의 UX 개발진들은 ‘탭’은 명확히 서로가 다르다는 것을 구분짓고 싶다는 의지가 있지 않았을까? 게다가 아이폰은 스와이프(Swipe) 액션을 주로 사용하기 때문에 사용에 혼동을 주는 것도 원치 않았을 것이다. 반대로 안드로이드의 스와이프 액션은 거의 사용하지 않기 때문에 스크롤 형식의 탭간 이동이 문제없다.
iOS에서 여러곳에 사용되는 스와이프(Swipe) 액션.놀랍게도 위에 언급했던 UX의 고유속성이 ‘Xamarin.Forms’로 앱을 만들면 매우 손쉽게 모두 구현이 가능하다. 이것을 PhoneGap 방식으로 만들면 iOS, 안드로이드 앱이 마땅히 가져야 할 고유한 특징을 무시한 똑같은 앱이 만들어 지기 때문에 각 플랫폼별 UX를 만들 수 없다. 고객들은 매번 앱마다 새로운 사용설명서를 원하지 않기 때문에 플랫폼의 고유한 UX는 매우 중요하다. 이 점이 바로 그동안 개발자들이 하이브리드, 크로스플랫폼 앱 개발 도입을 망설였던 이유다. 안타깝게도 한국의 앱 개발사들은 이와같은 표준이나 디자인 가이드라인에 대하여 무지하거나 무시하는 경향이 있다. 이런 점들이 중요하다는 것을 알지만 ‘그럼에도 불구하고' 우리는 독창적인 방식으로 만들겠어! 라면 다행이고 박수 한번 쳐주겠지만, 그게 아닌 그저 내마음대로 만든 개똥철학 앱이 너무나도 많다.
당장 서울시에서 자전거 대여서비스를 하고있는 ‘따릉이' 앱만 봐도 햄버거메뉴 버튼이 오른쪽 상단에 있는데 누르면 왼쪽에서 마스터페이지가 튀어나오는 기형적인 형태를 하고있다. 다른것이 아닌 잘못된 것이다! ‘Xamarin.Forms’는 이러한 점을 결코 경시하지 않도록 해준다.
사실은 기존 앱개발자가 사용해야 더욱 강력하다
앞서 이야기했지만 ‘Xamarin.Forms’는 기존의 ‘C#’, ‘WPF’개발방법을 그대로 계승한다.
‘윈도우 진영에서 해오던 개발방식에 비해 거의 변화가 없기 때문에 그대로 앱을 만들 수 있다’ 라고 이야기 했지만, 각 앱의 특징들을 살리는 것이 중요하기 때문에 막상 실전에 들어가면 ‘앱'과 각각의 모바일 OS에 대해서 편법이나 관습적인 것들까지 매우 깊이 알고 있어야 질좋은 앱이 만들어진다.
또 ‘Forms’를 통해 대부분의 코드가 통합되지만 여전히 iOS와 안드로이드는 각각 손봐줘야 할 점들이 있다. 자마린의 장점이라고 볼 수 있는 부분인데 ‘Forms’로 뭔가 통합적인 처리가 안될때는 주저없이 각각 네이티브 코드를 작성할 수 있다. 즉 자마린으로 불가능한 것은 없다. 예를 들어 C# 개발자가 ‘Xamarin.iOS’와 ‘Xamarin.Android’ 방식으로 세부적으로 코딩할때는 본래 개발 방식 그대로 ‘C#’을 작성해 적용시킬 수 있다. 반면 윈도우 진영의 개발자는 쉽지 않을 것이라 생각된다.
그 결과 소위 ‘팬시'하지 않은 앱이 만들어 지는 것이다. 모든 기능들이 적당히 잘 작동되는 앱이긴 하지만 왠지모르게 동작이 어수룩하고 올드한 느낌이 나게된다. 앱이라면 당연히 갖춰야할 것을 놓치는 경우도 있다. 바꿔말해 각 모바일OS의 디자인 가이드라인과도 거리가 있다. 물론 사람마다 견해 차이가 있을 수 있겠지만 내 생각에는 기존의 앱 개발자가 자마린으로 앱을 만드는 것은, ‘C#’, ‘WPF’ 개발자가 자마린으로 앱을 만드는 것보다 더 질 좋은 즉, 고객 중심에 맞는 결과물을 만들수 있다고 생각한다.
c# 이렇게 좋은 언어였니?
기존의 앱개발자가 더 유리하다고 느낀 이유중 하나는 역설적이게도 ‘C#’이 너무나 좋아서이다. 굉장히 난해하고 학습곡선이 긴 언어였으면 쉽지 않았겠지만 ‘C#’을 처음 접해본 내가 6개월만에 양 플랫폼에 어느 정도 규모가 있는 앱을 런칭했으니 개인적으로 우수하고 편리한 언어라는 것이 증명이 됐다고 본다. 이 언어는 너무나도 잘 만들어졌고 쉽게 배울 수 있는 언어였다. (숙련되고 강력하게 사용하기 위해서는 물론 오랜 수행이 필요하겠다.)
특히 ‘WPF’진영에서는 당연하게 사용하는 ‘MvvM’패턴과 변수의 바인딩을 통해 UI와 유기적으로 연결되는 부분은 정말 이렇게 편하고 안정적인 방법이 있을까 싶어 감탄했다. ‘Objective C’에서도 ‘KVO’ 패턴으로 비슷한 기능이 가능하긴 하지만 따로 구현을 해야하고 대중적이지 않다. 윈도우 진영에 있어보지 못한 사람으로서 우물 안 개구리식으로 살았구나 하는 한숨까지 나올 정도였다. 가령 그동안엔 힘겹게 블록(block)을 쓰며 ‘이것이라도 있어서 감사합니다’ 하며 작성했던 코드가 ‘C#’에서 ‘await’ 키워드 하나로 해결되는 것을 보고 놀랐다. 지금은 스위프트(Swift)가 새로 출시돼 매우 우수한 언어로 인정을 받고 있지만 나온지 한참 되었던 C#이 이정도로 진화된 모습이였던 것을 몰랐던 것에 대한 아쉬움에 개발자로서 많은 반성을 하게되었다.
nuget Package를 활용한 우수한 생산력
자마린은 .NET 프레임워크의 우수한 기능들을 그대로 사용할 수 있는데다가, 생산성을 향상시켜주는 ‘nuget Package’를 사용할 수 있다. ‘Unity3D’에는 ‘Asset Store’가 있고 iOS에는 ‘CocoaPods’가 있듯이 최근 몇년 사이에는 이러한 공개 라이브러리들을 최대한 활용해 생산성을 높이는 것이 트렌드이다. ‘nuget Gallery’의 라이브러리들은 거의 오픈소스 프로젝트여서 소스코드를 볼 수 있고 직접 개선에 참여할 수 있다. 심지어 ‘Xamarin.Forms’조차 오픈소스 프로젝트로 운영하고 있다.‘Forms’에서 지원하지 않는 기능중 대표적으로 카메라 제어나 블루투스 제어가 있다. 물론 이 부분은 ‘Xamarin.iOS’ 나 ‘Xamarin.Android’를 이용해서 따로 구현해 낼 수 있지만 이를 미리 작성해놓은 라이브러리가 ‘nuget Library’다. 카메라나 갤러리를 이용하기 위해서 ‘James Montemagno’의 ‘Media plugin’을 이용하고 블루투스를 이용하기 위해선 ‘Adrian’ 의 ‘xabre Ble Plugin’을 이용하면 코드 몇줄로 필요한 기능을 구현할 수 있다. 웨어러블 기기를 연동하는 올비 앱에서는 카메라와 블루투스를 위해 ‘nuget Package’를 적극적으로 활용하고 있는데 각각의 OS앱을 따로따로 만들었다면 얼마나 끔찍했을까 한다. 특히 안드로이드의 경우 스마트폰 제조사마다 카메라나 블루투스가 조금씩 다른 동작들을 하는 경우가 많아서 이에 대응하기가 정말 힘들었을 것이다. 한가지 단점이 있다면 안정화가 되지 않은 플러그인들이 꽤 있다. 위에 언급한 두 라이브러리도 계속 업데이트 중이고 올비 앱에서 지속적으로 사용해야하는 핵심기능이기 때문에 나도 적극적으로 개선에 동참하고 있다. 라이브러리의 문제가 있을 때엔 화가 날때도 많지만 한편으로 수많은 사람들이 사용하는 라이브러리를 개선하는 작업은 자마린을 하면서 경험하는 또다른 즐거움 이랄까.
한편 이미 안정적으로 동작하는 ‘nuget Package’도 상당히 많으며 기존 .NET 진영의 안정화된 라이브러리들을 마음껏 사용할 수 있으니 좋다. ‘JSON’같은 경우도 ‘Newtonsoft’의 ‘JSON.NET’ 라이브러리를 사용하면 강력한 기능들을 손쉽게 사용할 수 있다. 또, 자마린으로 앱을 제작하면서 한가지 걱정했던 것은 2D 그래픽을 다루는것이 걱정이였는데 iOS와 안드로이드 ‘View’의 ‘OnDraw’ 함수 에서 각각 처리하기에는 번거로웠다. 다행이 때에 맞춰 ‘SkiaSharp.Forms’ 라이브러리가 나와서 ‘View’에 대한 2D 그래픽(Graphic)처리가 ‘Forms’단에서 원코드로 손쉽게 가능하게 되었다.
SkiaSharp.Forms를 이용하여 난해한 실시간 2d그래프를 그려주었다.자마린에 대한 세간의 우려
자마린에 대한 공통적인 우려는 크게 두가지 정도로 추려진다. 첫번째는 사용자가 많지 않아 원하는 정보를 얻기가 쉽지 않다는 우려다. 결론부터 말하자면 그렇지 않다. 철저히 국내에 한정된 이야기이지(한글 서적이 거의 없다), 해외에서는 이미 많은 사용자가 있다. 스택오버플로우(StackOverFlow) 에서도 하루안에 얻지 못한 답이 없을 정도이며 공식 포럼에서도 많은 개발자들이 적극적으로 참여하고 있다. 그리고 대부분 개발자들이 윈도우 진영의 개발자들이기 때문에 상당히 숙련되고 진중한 개발자들이 많아 기술적으로 큰 도움을 받을 수 있다는 장점이 있다. 게다가 재밌는 것은 자마린에서 ‘Forms’의 존재만 빼면 iOS API에 99%를 C#일뿐인 ‘Xamarin.iOS’로 코딩할 수 있다. 이말인 즉슨 자마린으로 앱을 만들다가 문제가 생기면 iOS나 안드로이드 진영의 해결방법을 이용해 ‘C#’식으로 해결할 수 있다. 또한 자마린을 사용하지 않더라도 세계에서 가장 많고 숙련된 .NET 개발자 진영의 개발자들에게 도움을 받을 수 있다는 것도 매력적이다.
두번째는 최신 OS에 대한 지원이 늦지 않을까 하는 우려이다. 이것은 그동안의 많은 다른 크로스 플랫폼들이 그래왔기 때문에 자마린도 그렇지 않을까 하는 걱정인데 역시 결론부터 말하자면 사실이 아니다. iOS의 경우 애플에서 새로운 업데이트 버전의 베타(Beta) 테스팅이 시작될 때 해당 버전에 대한 ‘Xamarin.iOS’ 베타테스팅이 같이 운용된다. 결국 iOS가 새로 릴리즈될 때 몇일 되지않아 ‘Xamarin.iOS’가 대응될 정도로 빠른 적용이 가능하게 된다. 나온지 얼마 되지 않은 ‘iOS10’의 기능도 올비 앱에서는 이미 사용하고 있다. 현재까지의 행보만 봐서는 태생 자체가 ‘Mono’를 이용해 타 플랫폼의 API를 연결하는 형태이다 보니 그동안의 다른 크로스 플랫폼과는 비교적 수월하게 대응하는 것이라고 예상해 본다. 물론 쉽지 않은 작업일 것이다. (2017년 3월 말에 릴리즈된 iOS 10.3은 몇일만에 Xamarin 지원이 완료되었다)
함께 만들어가는 자마린
자마린을 도입하면서 느낀 장점은 해외의 개발자들과 소통할 수 있다는 것이다. 한글로 된 자료 자체가 없다보니 생존을 위해서 그랬던 것인지 몰라도 해외에서 수많은 자마린 개발자들과 함께 활동하는 경험은 그동안 해본 다른 어떤 경험보다 즐거운 경험이다. 처음에는 아무것도 모르니 무식한 질문부터, 이젠 때때로 기존 개발자들에게 도움을 주기도 하는데 아주 짜릿하다.
5만명 정도가 사용하고 있는 카메라, 갤러리 사진관리 nuget Plugin ‘Media Plugin’의 경우 많은 개발자들이 사용하는데도 불구하고 LG 스마트폰에서 사진이 90도 돌아가 저장되는 문제가 있었다. 깃허브(Github)에 이슈를 만들어 코드 수정내역을 올렸는데 빠르게 적용해주어 업데이트 되었다.
‘Forms’의 최신 업데이트 2.3.4 버전은 현재 Pre Release 상태에 있는데 열심히 버그를 발견해서 재연되는 샘플 프로젝트를 만들어 올리고 있다. 최근에 자마린 ‘Bugzilla’에 내가 제보한 51536, 53351번은 굉장히 치명적인 버그였는데 제보후에 금방 수정이 이뤄졌다. 세계적으로 핫한 자마린에 직간접적으로 참여해서 목소리를 낼 수 있다는 것은 기분좋은 일이다.
최신 Forms 테스팅에 참여해서 적극적으로 버그를 제보하고 반영여부를 주시하고 있다자마린은 최신버전의 베타테스팅을 사용자들과 같이 할 뿐 아니라 깃허브에 ‘Open Pull Request’도 받고 있다. 기존 참여자가 아니면 승인되기가 쉽지는 않지만 ‘Request’ 가이드라인을 잘 지켜 테스트케이스를 함께 잘 첨부하면 승인이 꽤 된다.
또 포럼에서는 ‘Xamarin.Forms Evolution’ 이라는 코너를 만들어 ‘Forms’에 추가되어야 한다고 생각하거나 미래의 방향성을 잡는데 결정할 사항들을 사용자들과 함께 토의하고 결정하고 있다. 여러 플랫폼과 엔진을 사용해 보았지만 이정도로 사용자들의 의견을 들으려하고 함께 하려고 하는 곳은 쉽게 보지 못했다. 물론 그것이 그만큼 아직 충분히 성숙하지 못하고 문제도 많다는 점을 반증하는 것이라고 볼 수도 있겠지만 일단은 종합적으로 볼 때 긍정적이라고 평가하고 싶다.
앞으로 대세는 자마린이다
나는 개인적으로 수많은 개발자들과 개발사들이 자마린으로 앱을 개발하는 시대가 열렸으면 하는 마음이 있다. 전세계가 한 언어로 소통하면 편할거라는 생각은 누구나 하지 않겠는가? 하지만 여러가지 한계가 있고 또 문화적으로 포기할 수 없는 것들이 있을 것이다.
앞서 언급했듯이 자마린은 각 플랫폼들의 특색들을 살리면서 편리하게 크로스 플랫폼 앱을 만들어낼 수 있는 좋은 도구이다. 게다가 불가능이 없는 방식이다. 자마린을 사용함으로서 개발사 안의 단순 포팅 노고를 덜어내줄 수 있고 버그유발을 줄일 수 있다. 또한 OS나 기기별로 파편화 되는 문제들은 자마린에 맡김으로서 앱 그 자체에 대한 노력에 더욱 집중할 수 있다는 굉장한 장점이 있다.
물론 자마린도 아직 많은 발전이 필요하다. 특히 국내에는 자마린 개발자가 희소하기 때문에, 한국형 라이브러리나 SDK가 준비되어 있지 않다. 페이스북이나 구글 플레이 서비스(Google Play Service), 파이어베이스(Firebase)와 같은 유명 SDK는 자마린 측에서 이미 바인딩하여 라이브러리를 제공하지만 카카오톡 SDK라던지 네이버 지도SDK 는 자마린 용이 준비되지 않아 웹 방식을 적용하거나 직접 네이티브 라이브러리를 바인딩해서 사용해야 한다. 또 한가지, 최근에 ‘Bugzilla’에 제보한 51825번 (Private 처리 중) 같은 경우 ‘iOS SearchBar’에 한글을 입력할 경우 자음과 모음이 분리되는 치명적인 버그가 있다. 이런 버그는 한국 개발자가 제보하지 않는 이상 끝내 고쳐지지 않는 버그로 남을 것이다.
자마린은 이미 지원하고 있는 윈도우 ‘UWP’뿐 아니라 최근 맥 앱(Mac App)도 지원을 시작했다. 루머인지 모르겠지만 갤럭시 S8의 윈도우 버전이 준비중이라는 소식도 나왔다가 사라졌다 한다. 만약 그런 일이 일어나면 나로서는 오히려 환영할 일이다! 다른 회사면 적어도 포팅하는데 몇달에서 1년은 걸릴 것이 Xamarin.Forms로 만들었으면 1,2주 정도만 손보면 윈도우용도 출시할 수 있을것이다. 전보다 편한 세상이 오고 있다. 한국의 많은 개발자들이 자마린을 이용해 서비스를 출시하게 되었으면 좋겠다. 자마린의 초기 학습자료는 자마린 공식 홈페이지에 친절하게 나와있으니 다른곳에서 따로 찾을 필요가 없다. 그리고 검색해보면 주제별로 주옥같은 묶음 샘플들이 깃허브에 통채로 올라가있다. 공식 홈페이지의 학습자료들과 많은 샘플들만 돌려보아도 쉽게 학습이 가능할 것이다. 수고하는 자마린 팀을 응원하며 모두에게 적극 추천한다.
본 글은 테크매거진 #마이크로소프트웨어 2017년 4월호(388호, IT조선 발행)에 실린 칼럼입니다. 부족한 글을 본지에 실어주시고 편집에 수고해주신 관계자 분들에게 감사드립니다. 양질의 내용들이 채워진 마이크로소프웨어, 응원하며 적극 추천합니다.
