2013
마이크로소프트웨어

글: 안진섭 | jinniahn@gmail.com / 2013년 6월호


<COVER STORY 2>

모바일 시대를 위한 개발자의 선택

모바일 개발에 특화된 주요 크로스플랫폼 비교

모든 IT 서비스에서 모바일은 이미 필수가 됐다. 모든 사람들이 휴대폰을 들고 다니며 일을 처리하는 것이 일상이 된 셈이다. 그런데 문제가 있다. 너무 많은 모바일 플랫폼이 사용되고 있는 까닭에 서비스를 제공하는 입장에서 각 플랫폼별로 개발해야 하는 새로운 부담이 생겨난 것이다. 여기서는 이 문제를 해결하기 위한 전략들을 살펴볼 것이다. 즉, 한번 개발된 소스로 다양한 플랫폼에 동작시키는 방법을 소개한다.



시장에는 다양한 플랫폼이 존재한다. 현재의 주력 플랫폼인 안드로이드, iOS뿐 아니라 MS의 윈도우폰(Windows Phone), 그리고 재도약을 꿈꾸는 블랙베리(Blackberry)도 있다. 또 WebOS나 Firefox OS 등에 대한 소식도 끊이지 않고 들리고 있다. 이미 플랫폼 전국시대가 된 지 꽤 오래다. 

이런 시대에 서비스를 만드는 기업이나 개발자는 어떤 플랫폼을 우선 지원하고 어떤 플랫폼은 포기해야 하는 일종의 선택을 해야 한다. 즉, 많은 플랫폼에서 서비스를 제공하고 싶지만 이를 위해서는 각 플랫폼별로 따로 개발해야 한다. 또 서비스의 확장이나 유지보수를 하려고 하면 플랫폼별로 따로 해야 하기 때문에 개발 비용이 증가하기 일쑤다. 이 때문에 보통 많이 사용하는 안드로이드나 iOS만 지원하기가 쉽다. 그럼 꼭 이렇게 해야만 할까?

이미 시장에는 직접 프로젝트에 사용할 수 있을 정도로 성숙된 크로스플랫폼들이 나와 있다. 이들 크로스플랫폼의 도움을 받으면 OSMU(One Source Multi Use)를 실현할 수 있다. 다시 말해 한번 개발된 소스를 이용해서 다양한 플랫폼에서도 동작시킬 수 있는 것이다.


멀티 플랫폼을 위한 전략의 기본적인 방법
간단히 생각해보면 멀티 플랫폼을 위한 방법은 의외로 간단하다. 필요한 로직이 담긴 소스를 다수의 플랫폼에 있는 공통 실행 환경에서 실행시킬 수 있도록 하면 된다. 여기서 중요한 것은 하나의 소스를 이용하는 것이다. 그리고 이 소스를 어떤 언어로 개발하고 어떤 처리를 거쳐서 최종 타겟 플랫폼에서 실행시키느냐에 따라서 여러 가지 전략이 있을 수 있다. 

지금부터 현재까지 나와 있는 멀티 플랫폼의 전략들을 하나하나 살펴볼 것이다. 그리고 그 전략을 사용하고 있는 제품들에 대해서도 간단히 언급할 것이다. 각각의 전략은 그 나름의 장단점을 가지고 있기 때문에 어떤 것이 더 좋다고 볼 수 없다. 그러므로 솔루션의 목적에 부합하는 조건들을 살펴보고 적절하게 선택해서 사용해야 한다.


크로스 컴파일 전략
첫 번째로 크로스 컴파일은 가장 전통적인 방법이다. 오래전 유닉스를 만들 때 사용한 C가 인기를 얻었던 이유이기도 하다. C로 로직을 작성하고 컴파일러를 통해서 각 플랫폼에서 동작할 수 있는 실행 파일을 만들었다. 여기서 중요한 것은 같은 언어를 사용하는 것과 플랫폼에 상관없이 공통적인 라이브러리를 사용할 수 있어야 한다는 점이다. 최근에 C++나 델파이 혹은 C#을 이용하는 제품들이 많이 나오고 있는데, 이 가운데 특히 C#을 이용하는 방법이 눈길을 끈다. <그림 1>은 C#의 오픈소스 프로젝트인 Mono를 이용해서 멀티 플랫폼을 사용하는 방법을 보여주고 있다. C#으로 앱을 작성하면 각 타겟 플랫폼별로 다른 컴파일러를 사용해서 네이티브 앱을 만들게 된다. 플랫폼별로 다른 컴파일러를 쓰는 것은 플랫폼별로 사용할 수 있는 방식이 다르기 때문이다. 원래의 .NET 전략은 각 플랫폼별로 CLR(Common Language Runtime)을 포팅해 가상의 환경을 제공해서 앱을 실행시키는 것이지만 플랫폼별로 그렇게 할 수 없는 경우가 있기 때문이다. 한 예로 iOS의 경우는 커널에서 CLR에서 사용하는 JIT(Just In Time) 기능을 허용하지 않기 때문에 컴파일할 때 중간 코드가 아닌 직접 기계 코드까지 변환하는 과정을 거쳐야 한다.



<그림 1> 크로스 컴파일 방식(Mono)


또 다른 방식으로 Applause에서 사용하는 방법처럼 도메인 언어(DSL)를 이용해서 개발하고 코드 제너레이터를 통해서 각 플랫폼에서 사용하는 언어로 작성된 프로젝터를 만드는 방법이 있다. 이렇게 만들어진 코드는 또 한 번의 컴파일을 거쳐서 최종 바이너리가 만들어진다. 이 방식의 장점은 템플릿을 바탕으로 목적한 소스를 빠르게 만들 수 있다는 것이다. 물론 그러기 위해서 DSL과 그것을 해석해서 코드를 만드는 템플릿을 미리 만들어야 하는 점이 문제점으로 지적된다.

 


<그림 2> 코드 생성 방식(applause 방식)


크로스 컴파일 방식을 사용하면 컴파일러에서 미리 컴파일이 이뤄지기 때문에 속도 면에서 원래 네이티브 앱의 그것과 큰 차이가 없고 단말 플랫폼의 HW 센서 정보를 사용할 수도 있다. 또한 이 방식을 사용해서 앱을 만들게 되면 플랫폼별로 제공되는 앱스토어를 이용할 수 있어서 배포나 판매에 있어서 유리한 면도 있다. 하지만 지원하는 플랫폼 수가 많지 않은 점과 Mono처럼 플랫폼별로 UI 부분은 따로 코드를 작성해야 하는 어려움이 있다. 

주요 제품으로는 Mono 프로젝트를 주도하고 있는 Xamarin과 Applause가 있고, 국내 업체의 플랫폼으로 UXPlus사의 Aqua가 있다. Xamarin은 Mono 프로젝트를 이끌고 있는 회사의 제품으로 iOS, 안드로이드뿐 아니라 맥이나 윈도우 같은 데스크톱 개발에도 쓰인다. 또한 IDE를 가지고 있어서 전 개발 과정을 이를 통해 개발할 수 있고, 자체 컴포넌트 장터를 가지고 있어서 필요한 모듈을 구입해 개발 기간을 단축시킬 수 있다. 

Applause는 앞에서 설명할 것처럼 DSL 언어를 사용한다. 개발은 이클립스(Eclipse)를 통해서 이뤄진다. xText 기반의 DSL 언어를 이용해서 모델을 정의하면 필요한 코드가 자동으로 생성된다. iOS, 안드로이드 그리고 윈도우폰을 지원한다. 

마지막으로 UXPlus사의 Aqua 제품이 있다. Aqua는 플랫폼에 공통적으로 사용할 수 있는 C++ 라이브러리를 제공한다. 이 라이브러리를 이용해서 개발하면 안드로이드, iOS, 바다앱을 만들 수 있다. Aqua의 특이한 점은 UI를 자체 그래픽 엔진을 이용해서 만들었기 때문에 플랫폼과 관계없이 동일한 UI를 유지할 수 있는 것이다.

 


<표 1> 크로스 컴파일 방식의 제품 비교


모바일 웹 전략
거의 모든 플랫폼이 한 가지 공통적인 것이 있는데, 그건 바로 웹브라우저이다. 웹은 그 태생부터 멀티플랫폼을 목표로 하고 태어났다. PC, 폰, 태블릿 그리고 TV까지 거의 모든 플랫폼, 모든 화면 사이즈에서 실행된다. 따라서 완벽한 크로스플랫폼이 있다면 그건 웹일 것이다. 물론 속도의 문제나 보안상의 이유로 단말의 센서 정보 등과 같이 플랫폼의 민감한 데이터는 접근할 수 없는 문제가 있다. 모바일 웹도 주요 로직이 실행되는 위치에 따라서 서버 중심의 모바일 웹과 단말 중심의 모바일 웹으로 나눌 수 있다.

 


<그림 3> 모바일 웹앱 전략


서버 중심의 웹앱은 기존 웹의 연장선상에 있다. 모든 로직이나 화면 구성은 서버에서 처리한다. 단말은 단지 서버에서 보내주는 데이터를 렌더링해주는 역할만 수행한다. 트위터사에서 공개한 bootstrap이나 zurb의 foundation 라이브러리는 모바일 화면과 PC 화면의 사이즈에 따라서 화면 구성요소들이 자동으로 재배치되도록 돕는다. 이와는 다르게 단말에서 UI 이외의 일부 주요 로직을 수행한다면 단말 중심의 웹앱이다. 최근에는 SPA, 즉 한 페이지 애플리케이션이라고 해서 하나의 HTML 페이지로 구성돼 내부 로직을 자바스크립트와 서버와의 Ajax 통신을 통해 만드는 것이 있는데 이것이 대표적인 단말 중심의 웹앱이라고 할 수 있다. 

모바일 웹앱을 사용하게 되면 플랫폼에 설치돼 있는 브라우저를 사용하기 때문에 설치와 같은 과정을 거치지 않고 사용할 수 있고 항상 최신의 데이터를 유지할 수 있다. 이런 까닭에 서비스를 제공하는 입장에서는 업데이트에 따른 버전 문제를 최소화할 수 있다. 그리고 최근의 HTML5 기능과 자바스크립트 라이브러리들을 이용하면 네이티브 앱과 거의 유사한 기능을 갖는 앱을 만들 수 있다. 하지만 자바스크립트를 사용하는 만큼 속도가 네이티브 앱에 비해 느릴 뿐더러 네트워크가 동작하지 않는다면 서비스 자체가 어렵다는 단점이 있다.

 


<그림 4> 브라우저의 크기에 최적화된 웹 화면을 만들어주는 zurb의 foundation 라이브러리


최근 모바일 웹앱을 위한 자바스크립트 라이브러리들이 많이 등장했다. 주요 제품으로 zepto.js, UI.js, jQuery mobile, Sencha 등이 있다.

 


<그림 5> Sencha(출처 : www.sencha.com/products/touch)


이 중 Sencha는 모바일 웹 개발 플랫폼 중에서 가장 잘 갖춰진 개발 플랫폼이다. 제공되는 제품을 보면 단순한 라이브러리 이상을 지원한다. Sencha는 Sencha Architect라는 자체 IDE를 가지고 있다. 이른 이용하면 데스크톱에서 모바일에 이르는 거의 모든 플랫폼의 웹앱을 만들 수 있고 모바일 화면을 쉽게 만들어주는 Sencha Touch, B2B에서 자주 사용되는 차트를 제공해주는 라이브러리 등 거의 모든 제품들을 보유하고 있다. Sencha로 만들어진 앱은 거의 네이티브 앱처럼 동작한다. 하지만 화려한 만큼 라이브러리가 크고 실행이 약간 무거운 감이 있다. 또한 비용도 문제로 지적된다. Sencha를 사용하기 위해서는 라이선스 비용이 따른다. Sencha와 종종 비교되는 라이브러리로 jQuery Mobile이 있는데, 이것은 jQuery의 확장 모듈로 모바일 화면을 구성할 수 있도록 도와준다. jQuery Mobile은 Sencha만큼 많은 기능을 가지고 있진 않지만 작고 가벼우면서 jQuery Mobile을 지원하는 많은 다른 라이브러리들의 지원을 받는다. 그리고 무엇보다 무료로 사용할 수 있어서 최근 많이 사용되고 있다.

 


<표 2> 모바일 웹 플랫폼 비교표


하이브리드 앱
앞에서 설명한 웹앱은 실행 환경이 웹 브라우저이기 때문에 디바이스 API를 사용할 수 없다. 최근에는 HTML5에서 연락처나 GPS와 같은 자원들을 사용할 수 있게 됐지만 아직 다른 자원들에 대해 접근하지 못하는 한계점이 있다. 그리고 모바일 웹의 경우 아무리 겉모양을 네이티브 앱처럼 보이도록 해도 브라우저에서 동작하기 때문에 큰 어려움이 있다. 더욱이 웹앱이 플랫폼의 장터에서 거래되지 않는 점도 경우에 따라서는 단점일 수 있다. 이런 문제를 해결하기 위한 방법으로 사용되는 것이 하이브리드 앱이다. 

하이브리드 앱은 HTML5로 작성된 웹앱을 네이티브에 포함시키고 WebView UI 컴포넌트를 통해 동작시킨다. 웹앱 소스가 앱에 포함되기 때문에 서버가 없어도 동작시킬 수 있고 패키지가 네이티브 앱으로 감싸지는 구조를 가지고 있으므로 앱스토어와 같은 앱 장터에서 거래될 수 있는 특징을 가지고 있다. 소스를 서버에서 다운로드하지 않아도 되기 때문에 네트워크 속도에 따른 문제를 최소화할 수 있는 장점도 가지고 있다. 또 모바일 웹앱 방식에서 문제점으로 지적되던 Device API를 제공할 수 있어서 단말의 HW 센서 정보와 같은 단말 정보를 사용하는 웹앱을 만드는 것도 가능해졌다. 하이브리드는 그 이름처럼 웹의 장점과 네이티브의 장점을 잘 접목시켰다. 따라서 HTML5로 앱을 작성하면서 단말 정보를 사용해야 한다면 하이브리드 방식을 사용해야 한다.

 


<그림 6> 하이브리드 앱 구조


대표적인 제품으로 폰갭이 있다. 플래시를 가지고 있는 어도비사가 폰갭을 사들이면서 크게 주목을 받았던 제품으로, 현재는 아파치 재단에서 지원하는 오픈소스로 빠르게 버전을 높여가고 있다. 폰갭은 현재 iOS, 안드로이드, 블랙베리, WebOS, 윈도우, 심비안 그리고 바다를 지원한다. 하이브리드 방식은 OS의 WebView UI 컴포넌트를 이용하는 방식이기 때문에 다수의 플랫폼을 지원하는 것이 유리하다. 폰갭은 단말의 자원을 접근할 수 있는 디바이스 API를 제공할 뿐 아니라 필요한 경우 사용자 API를 추가할 수 있는 구조도 가지고 있다. 하지만 폰갭에서는 UI에 대한 API를 가지고 있지 않으므로 모바일 웹 방식에서 설명했던 자바스크립트를 라이브러리들과 함께 쓰는 것이 보통이다. 

폰갭의 서비스에서 주목할 기능 가운데 하나는 클라우드 빌드를 지원하는 것이다. 개발자는 HTML5를 이용할 웹앱을 만들면 클라우드 빌드를 사용해서 웹앱을 iOS, 안드로이드 등 네이티트 앱으로 만들 수 있다. 이 서비스를 사용하면 맥이 없어도 iOS용 하이브리드 앱을 만들 수 있다.

 


<표 3> 하이브리드 앱 비교표


폰갭과 유사 플랫폼으로 KTH의 앱소프레소가 있다. 앱소프레소는 현재 iOS와 안드로이드만을 지원하고 있지만 폰갭과 같이 WebView UI 컴포넌트를 이용하는 방식이므로 지원 플랫폼을 쉽게 늘릴 수 있을 전망이다. 

폰갭과 앱소프레소는 동일한 방식을 사용하고 있지만 지원 API에 있어서 큰 차이를 보인다. 폰갭이 HTML5의 API를 보충하고 지원하는 방식으로 API를 만들고 있다면, 앱소프레소는 WAC 표준으로 따른다. WAC는 세계의 주요 통신사들이 모여서 만든 API 표준으로, WAC 표준을 따르면 세계의 통신사에서 지원하는 서비스를 만들어서 유통시킬 수 있다. 

앱소프레소의 이런 특징은 KTH의 모 기업인 KT가 WAC을 지원하는 주요 통신사이기 때문으로 풀이된다.

 


<그림 7> 인터프리터 방식 구조(타이타늄 방식)


인터프리터 방식
앞서 살펴봤던 컴파일러 방식과 대조되는 방식이다. 컴파일러 방식이 소스를 컴파일해서 각 플랫폼에 맞는 기계어 혹은 중간 언어로 만드는 방식을 취한다면, 인터프리터 방식은 소스를 직접 단말에 포함시키고 이 소스를 실행시킬 인터프리터를 내장시킨다. 따라서 원시 소스를 컴파일하거나 변환시킬 필요가 없다. 

인터프리터 방식은 인터프리터 엔진을 이용하기 때문에 속도 측면에서는 크게 이득을 보지 못하지만 기존의 스크립트 언어(자바스크립트, 루아, 루비 등)를 그대로 사용할 수 있기 때문에 따로 언어를 배우지 않아도 되는 장점이 있다. 또 단말의 HW 자원도 사용할 수 있는 장점을 가지고 있다.

 


<표 4> 인터프리터 방식을 사용하는 제품 비교


타이타늄이 이 방식을 사용하고 있고, 일정관리 프로그램인 Wunderlist가 타이타늄을 이용해서 작성됐다(최근 이 제품은 완전한 네이티브 앱으로 다시 작성됐다). 타이타늄의 경우 자바스크립트 엔진이 내장돼 있어 자바스크립트를 이용해 앱을 개발하게 된다. iOS는 자바스크립트 코어(JavaScript Core), 안드로이드는 V8 엔진을 내장시켰다. OSMU를 위해서는 인터프리터를 각 플랫폼별로 포팅하는 작업을 해주면 된다. 하지만 이렇게 자바스크립트 엔진을 각 플랫폼으로 포팅하는 것은 쉽지 않은 작업이다. 따라서 지원하는 플랫폼이 넓지 못하다는 단점이 있다. 타이타늄은 iOS, 안드로이드 그리고 블랙베리를 지원하고 있다.

이외에 루비언어를 사용하는 Rhomobile이 있는데, 루비 온 레일즈를 모바일 버전으로 옮긴 것에 가깝다. Rhomobile에서는 개발 편의를 위해서 여러 제품들을 제공해주고 있다. 루비 온 레일즈에 익숙하다면 이 플랫폼을 이용해볼 만하다.


어떤 전략을 사용할 것인가?
지금까지 크로스플랫폼을 지원하기 위한 여러 가지 전략들과 지원 제품들을 살펴봤다. 많은 방법 중에 어떤 전략이 가장 적절할지는 상황에 따라서 다를 수 있다. 그러므로 어떤 전략을 선택할지 결정하려면 몇 가지 요소를 고려해야 한다. 첫 번째는 개발할 언어이다. 개발자들이 웹에 익숙한지 아니면 C++, C# 혹은 스크립트 언어에 익숙한지가 중요하다. 사용할 언어를 새롭게 배워야 한다면 학습에 따른 부담을 가져야 하기 때문이다. 그 다음으로 단말의 센서 정보 등 단말의 내부정보를 사용해야 하는지 알아야 한다. 내부 센서 정보 등이 필요 없다면 웹앱 등을 고려할 수 있다. 모바일 웹을 사용하면 최대한 많은 플랫폼에서 서비스할 수 있다. 

또 동작시켜야 하는 타겟 플랫폼이 고려돼야 한다. 가장 많은 플랫폼을 지원하는 것은 모바일 웹 방식 혹은 폰갭과 같은 하이브리드 방식이다. 

마지막으로 속도가 중요하다면 컴파일 방식을 우선 고려한다. 컴파일 방식은 지원 플랫폼은 많지 않지만 속도에 관해서는 여러 방법 중에 최대의 이점을 누릴 수 있다.


모바일 크로스플랫폼의 한계와 미래 그리고 전략
최근 링크드인(LinkedIn)이 자사의 앱을 기존의 하이브리드 앱에서 네이티브 앱으로 전환했다. 이에 앞서 페이스북도 자사의 모바일 전략을 수정하면서 앱을 네이티브 앱으로 변경했다. 이렇게 모바일 크로스플랫폼을 사용하던 기존 전략을 수정한 것은 크로스플랫폼에서 오는 문제점 때문이다. 우선 속도의 문제이다. 웹이 호환성 면에서 좋긴 하지만 속도에 있어서는 네이티브 앱에 비할 바가 아니다. 그리고 UI의 구현의 문제점도 있다. 요즘 인기 있는 모바일 앱의 경우, 화려한 UI로 시선을 끈다. UI는 비단 예쁜 화면만이 아니라 앱의 사용성에도 영향을 주는 부분이다. 

이런 문제는 하이브리드 앱만의 문제가 아니라 크로스플랫폼이 가지고 있는 한계를 보여준다. 모든 플랫폼에 공통으로 사용되기 위해 가상의 레이어를 중간에 둘 수밖에 없기 때문에 속도 면에서 불리하고 플랫폼별 강점들을 사용할 수 없기 때문이다. 

하지만 크로스플랫폼은 시장에 빠르게 진입해야 하는 경우나 화려한 UI나 속도보다 유지보수 비용이 더 중요한 B2B 시장에 들어갈 때는 꼭 고려해야 한다. 일정 관리 솔루션인 Wunderlist의 경우 초기 앱들은 타이타늄을 이용해서 서비스를 시작했다. 시작 당시 iOS, 안드로이드, 맥, 윈도우 앱을 동시에 출시하면서 많은 사람들을 놀라게 했는데, 이는 크로스플랫폼을 이용했기에 가능했다.

또한 모바일 크로스플랫폼도 여러 가지 전략에 따라서 문제 요인들을 피해 갈 수 있다는 점도 고려하길 바란다. 많은 플랫폼에서 지원하고자 한다면 모바일 웹이나 하이브리드 앱 방식을 사용하고, 속도가 중요하다면 크로스 컴파일 방식이나 인터프리터 방식을 사용하는 것이다. 앞서도 언급했지만 어떤 경우에나 맞는 그런 솔루션은 없다. 언제나 상황을 고려해서 최고가 아닌 최선의 솔루션을 선택하는 것이 옮은 선택이다. 이 글을 통해 각자가 원하는 솔루션을 찾을 수 있길 바란다.

 

[참고자료]
1. xamarin - http://xamarin.com/
2. applause - https://github.com/applause/applause
3. aqua - http://uxplus.com/
4. phonegap - http://phonegap.com/
5. appsopresso - http://appspresso.com/
6. titanium - http://www.appcelerator.com/platform/titanium-sdk/
7. rhomobile - http://rhomobile.com
8. sencha - http://www.sencha.com/
9. jQuery mobile - http://jquerymobile.com/



/필/자/소/개/

안진섭jinniahn@gmail.com

임베디드 소프트웨어 및 모바일 분야에서 경력을 쌓았고 현재 삼성SDS에서 B2B를 위한 크로스플랫폼과 관련해 선임 개발자로서 일하고 있다. 저서로 <iPhone 실전 프로젝트 따라하기>가 있다.



※ 본 내용은 (주)마소인터렉티브(http://www.imaso.co.kr/)의 저작권 동의에 의해 공유되고 있습니다.
    Copyright ⓒ Maso Interactive Corp. 무단전재 및 재배포 금지

맨 위로
맨 위로