반응형
다양한 하이브리드 무엇이 최선일까?
월간 마이크로소프트웨어 2012년 1월호
영문 위키피디아(http://en.wikipedia.org/wiki/Hybrid)를 찾아보면 하이브리드와 관련된 항목만 40여개가 넘는다. 다양한 분야에서 하이브리드에 대한 시도에 관심을 가지고 있기 때문에 아마도 이 숫자는 계속해서 늘어날 것이다. 그럼 소프트웨어 개발자라면 어떨까? 물론 자동차나 자전거에도 관심이 많겠지만 모바일 앱 개발에 조금이라도 관심이 있다면 하이브리드앱이라는 개발방법이 떠오를 것이다. 이미 마소에서도 여러 차례 하이브리드와 관련된 글이 올라왔고 국내에서도 자체적인 개발 프레임워크를 적극적으로 홍보하고 있어 한번쯤은 들어보았을 것이다.
국내에서는 하이브리드 앱이라고 언론에서도 이야기하고 개발자들도 하이브리드라는 단어가 익숙하지만 해외에서는 ‘모바일 프레임워크’라고 표현하고 있고 위키피디아에서는 ‘다양한 디바이스를 지원하는 웹 기반 애플리케이션 프레임워크’라고 정의하고 있다. 여기에서는 국내에 잘 알려진 폰갭이나 티타늄외외에도 다양한 프레임워크를 더 찾아볼 수 있다. 국내에는 거의 알려져 있지 않지만 최초의 하이브리드앱 모델이라고 할 수 있는 것은 QuickConnect 프로젝트다. 2008년 4월 시작되어 iOS상에서 자바스크립트와 Objective-C 사이의 호출을 처리하는 개발방식을 공개하고 개발자들의 열광적인 호응을 얻었다. 현재까지도 진행이 되고 있지만 대중적인 인지도는 높지 않은 편이다.
하이브리드앱의 특징은 개발자들이 기존에 가지고 있던 기술을 그대로 활용할 수 있다는 것이다. 모바일앱 개발을 위해 별도의 교육과정을 거칠 필요가 없으며 이미 구축된 웹 개발 자원을 그대로 모바일 개발에 활용할 수 있다는 것이다. 또 하나의 특징은 개발 프레임워크에 따라 접근 방식이 조금 다르긴 하지만 화면에 보이는 콘텐츠는 브라우저에서 동작할 수 있는 형태로 구현되어있다. HTML, CSS, 자바스크립트만 가지고 구현이 되었고 콘텐츠를 그대로 모바일 브라우저에서 확인했을 때 동일한 콘텐츠를 볼 수 있다는 것이다. 그렇다면 콘텐츠를 어렵게 앱 형태로 만들어서 사용자가 설치할 필요 없이 브라우저에서 바로 이용하게끔 하는 것이 맞지 않을까 싶은데 여기에는 약간의 차이가 있다.
PhoneGap이라는 단어에서 gap(공간적인 틈, 간격)이 의미하는 것처럼 브라우저와 디바이스 간에는 그냥 넘어갈 수 없는 협곡과 같은 곳이 있다. 예를 들어 음식점을 검색하는 앱을 만들었다고 할 때 모바일 브라우저에서 전화걸기를 구현하는 데에는 제약이 있다(물론 <a href=“tel:119”>119</a>와 같은 식으로 링크를 만들 수 있으며 iOS에서는 텍스트 중에서 전화번호를 인지해서 링크를 생성해주기도 하지만 개발자의 의도대로 컨트롤할 수는 없다). 이런 경우에는 디바이스에서 제공하는 전화 관련 기능을 이용해야 하는데 브라우저에서는 이런 기능에 직접 접근할 수 없다. 이런 차이를 넘어설 수 있게 해주는 다리 역할을 하이브리드앱에서 담당하고 있는 것이다. 하지만 언젠가는 이런 간격이 좁아질 것이라고 예측하고 있으며 그때가 되면 웹이 하이브리드앱을 대체할 것이라고 이야기하고 있다.
PhoneGap이라는 단어에서 gap(공간적인 틈, 간격)이 의미하는 것처럼 브라우저와 디바이스 간에는 그냥 넘어갈 수 없는 협곡과 같은 곳이 있다. 예를 들어 음식점을 검색하는 앱을 만들었다고 할 때 모바일 브라우저에서 전화걸기를 구현하는 데에는 제약이 있다(물론 <a href=“tel:119”>119</a>와 같은 식으로 링크를 만들 수 있으며 iOS에서는 텍스트 중에서 전화번호를 인지해서 링크를 생성해주기도 하지만 개발자의 의도대로 컨트롤할 수는 없다). 이런 경우에는 디바이스에서 제공하는 전화 관련 기능을 이용해야 하는데 브라우저에서는 이런 기능에 직접 접근할 수 없다. 이런 차이를 넘어설 수 있게 해주는 다리 역할을 하이브리드앱에서 담당하고 있는 것이다. 하지만 언젠가는 이런 간격이 좁아질 것이라고 예측하고 있으며 그때가 되면 웹이 하이브리드앱을 대체할 것이라고 이야기하고 있다.
(그림 1. 협곡 사이에 놓인 다리 Glen Canyon Dam Bridge)
브라우저에서 부족한 모습을 채워주는 것은 어디선가 보았던 모델인 듯싶다. 바로 RIA가 등장한 배경이다. 웹이 제자리에 머물러있는 사이에 사용자들은 단순한 정보 조회 이상의 기능을 브라우저에서 할 수 있기 원했고 그런 요구사항에 따라 화려하게 등장한 것이 우리가 알고 있는 RIA의 모습이다. RIA는 브라우저에 플러그인 형식으로 제공되며 사용자들의 요구사항을 기민하게 받아들여 빠른 속도로 자리를 잡아나갔다. 하지만 HTML5가 전면으로 등장하면서 기존 RIA 플랫폼의 입지가 줄어드는 모양새를 보여주고 있다. 이러한 움직임은 RIA가 웹의 부족한 부분을 채워왔고 사용자들이 다양한 RIA 플랫폼을 사용하면서 요구되어지고 검증된 결과가 HTML5에 반영되었기 때문이다. HTML5라는 것이 갑자기 누군가의 머릿속에 있다가 뚝 떨어진 것이 아니라 지속적인 사용자의 요구와 이를 개선하기 위한 노력의 기반위에서 나타났다는 것이다.
오픈소스 RIA 플랫폼 티타늄
하이브리드앱 프레임워크 중에서 티타늄(titanium)은 처음부터 모바일을 대상으로 한 것은 아니었다. 2008년 12월 첫선을 보였을 때 타이틀은 오픈소스 RIA 플랫폼이었다. 어도비 AIR와 마찬가지로 다양한 운영체제를 대상으로 하나의 코드로 개발하고 배포할 수 있다는 것이 주요 목적이었다. 당시 자료를 살펴보면 어도비 측에서 티타늄을 상당 부분 견제한 흔적을 찾아볼 수 있다.
하지만 2009년 모바일 애플리케이션을 개발할 수 있는 기능이 추가되고 2010년 아이패드를 지원하면서 데스크톱 개발 플랫폼보다는 모바일 개발 플랫폼으로 주목받게 됐다. 2011년 1월에는 웹개발 IDE로 잘 알려진 Aptana를 인수하면서 강력한 개발툴까지 소유하게 됐다. 개발자 행사인 CODESTRONG 2011(http://codestrong.com/)에서 발표된 내용을 보면 2011년 9월 기준으로 25,000개의 앱이 만들어졌으며 200,000명의 등록된 개발자가 활동하고 있다고 한다. 2011년 3분기 기준으로 앱스토어에 등록된 앱이 60만개라고 했을 때 그 수가 많은 것은 아니지만 증가 추이를 보면 독립적인 개발 프레임워크만으로 대단한 숫자라고 할 수 있다.
(그림 2. 티타늄 스튜디오)
엄격하게 말하면 티타늄은 하이브리드 개발 방법을 택한 것이며 하이브리드앱이라고는 할 수 없다. 개발은 기존 웹 개발 기술을 사용하지만 최종적인 결과는 네이티브 코드로 만들어진다. UI 자체가 네이티브 코드로 만들어지기 때문에 아이폰에서 보이는 것과 안드로이드에서 보이는 것이 동일하지 않고 각 시스템에 맞게 최적화된 화면을 구현할 수 있다.
얼마 전 jQuery 모바일 프레임워크(http://jquerymobile.com/)가 공개되었을 때 비판적인 시각중 하나가 스타일을 적용하더라도 만들어진 앱이 다 비슷비슷해 보인다는 것이었다. 프레임워크에서 제공하는 UI 컴포넌트를 기반으로 스타일만 적용할 수 있으며 아직은 다양한 적용사례가 많지 않아서 그런 측면도 있지만 웹으로 보일 수 있는 화면 구성상의 한계 때문일 수도 있다. 하지만 네이티브 코드를 활용할 수 있다는 것은 그런 제약을 어느 정도 벗어날 수 있다는 것을 의미한다. 그래서인지 티타늄은 기존 웹개발자뿐 아니라 빠른 속도로 애플리케이션을 만들어내기 원하는 기존 네이티브앱 개발자들도 많이 흡수하고 있다.
빠른 개발속도만이 장점이었다면 프로토타입이나 간단한 앱 개발 정도에만 사용되겠지만 개발자수가 늘어나면서 NBC나 eBay, zipcar와 같은 대중적인 서비스에도 적용이 되고 있다는 것은 주목할 만한 사실이다. 어렵게 네이티브 개발 방법을 익히지 않아도 동일한 성능을 낼 수 있다는 점에서 티타늄의 개발방법은 상황에 따라 가솔린 엔진과 전기 모터를 병행하는 하이브리드 자동차와 닮아있다고 할 수 있다.
백조가 된 어도비 드림위버
최근 어도비는 여러 가지 발표로 개발자들과 관련 업계를 혼란스럽게 하고 있다. 어도비 AIR는 다양한 운영체제에 대한 지원이 특징이었는데 리눅스에 대한 지원이 중단되었고 모바일 플래시 플레이어의 향상된 성능이 얼마 전까지 개발자 행사의 주요 주제였는데 모바일 플래시 플레이어에 대한 개발을 중단한다고 선언하고 있다. 그리고 모바일 분야는 아니지만 개발자와 디자이너간의 자연스러운 업무 흐름을 지원하게 만들어졌던 어도비 플래시 카탈리스트 역시 추가적인 업데이트를 중단할 것이라는 발표가 있었다.
이러한 소식들만 보면 어도비는 애플리케이션 시장을 포기하는 것이 아닌가 싶다. 하지만 흥미롭게도 이런 가운데 주목받는 제품이 웹 개발 솔루션인 드림위버다. 1997년 처음 공개된 드림위버는 처음부터 맥과 윈도우를 지원했으며 HTML뿐 아니라 Java, PHP, VB, ColdFusion 등 다양한 언어에 대한 코딩 기능을 지원하고 있다. 하지만 웹 개발 시장이 템플릿 중심으로 쉽게 작성할 수 있게 되고 웹 기반의 저작툴이 활성화되면서 드림위버가 차지하고 있던 시장은 상당부분 줄어들었다. 하지만 드림위버에서 jQuery 플러그인을 지원하고 폰갭으로 패키징하는 기능까지 포함하게 되면서 하이브리드앱 개발의 새로운 중심으로 떠오르게 되었고 사용자들은 새로운 버전의 드림위버를 구매할 동기가 생겨버렸다.
(그림 3. 드림위버 폰갭 빌드 시연 - MAX 2011)
얼마 전 진행되었던 어도비 MAX 2011 키노트만 보아도 드림위버 팀의 위상이 얼마나 달라졌는지 알 수 있다. 물론 플래시를 HTML5 기반으로 변환하거나 HTML5 기반의 저작툴인 EDGE에 많은 공을 들이고 있지만 아직 시장에서 적용하기 어려운 상황에서 드림위버는 어도비가 내세울 수 있는 강력한 콘텐츠 저작도구가 될 수 있는 것이다. 드림위버의 사용자는 전문적인 개발자가 아닌 만큼 SDK나 빌드와 같은 개념에 익숙하지 못하다. 드림위버에서 제공하는 ‘Easy Install’과 같은 기능은 실질적인 사용자를 고려한 기능으로 개발을 전혀 몰라도 만들어진 콘텐츠를 모바일앱으로 전환할 수 있는 기능을 제공하고 있다.
어도비가 폰갭을 만들었던 니토비를 인수하면서 어떤 변화가 있을까 하는 것은 많은 이들이 궁금해하고 있는데 폰갭의 브랜드 효과도 있겠지만 관련 기술력을 제품군에 흡수하게 된다는 점을 주목하고 있다. 특히 클라우드 빌드(서버상에서 모바일 디바이스에 배포 가능한 형태로 패키징하는 기술)와 같은 기술이 드림위버 제품군에 적용된다면 콘텐츠를 제작하는 사용자는 콘텐츠에만 집중하게 되고 만들어진 콘텐츠를 원하는 모바일 디바이스에 최적화된 형식을 클릭 한번만으로 만들어서 배포할 수 있는 환경이 만들어지게 된다.
Callback
아직은 폰갭이라는 이름이 익숙하겠지만 지난 9월 폰갭은 아파치 재단 인큐베이터 프로그램에 편입되었고 이제는 Callback이라는 새로운 이름을 가지게 됐다. 인큐베이터 프로그램은 미숙한(기술적인 부분보다는 아파치 재단의 프로세스 측면에서) 부분을 보완해주고 안정적으로 프로젝트가 성장해나갈 수 있도록 지원하는 프로그램이다. 최근 어도비 플렉스 SDK도 아파치 인큐베이터 프로그램에 등록을 하려는 움직임을 보이고 있다. 그래서 모든 자원이 다 옮겨진 것은 아니고 소스코드는 github에서 관리되고 조금씩 안정화 단계를 진행하고 있다.
폰갭은 2008년 iPhoneDevCamp에서 처음 선을 보였으며 웹 브라우저의 기능 확장이라는 측면에서 웹 표준을 벗어나지 않으며 기존 웹 개발자가 자신이 가지고 있는 기술을 그대로 활용한다는 면에서 환영받고 있다. 별도의 개발툴을 제공하지 않기 때문에 처음 입문하기에 어려운 면이 있지만 드림위버와 같은 기존 콘텐츠 저작도구들이 쉽게 접근할 수 있도록 플러그인 형식으로 지원하고 있기 때문에 다양한 가능성을 가지고 있다. 그리고 다른 개발 프레임워크에 비해 기존 웹 개발자들이 쉽게 접근할 수 있다는 장점을 가지고 있다.
하이브리드앱은 디바이스 API를 사용하는데 사용자가 요구하는 모든 기능을 하나의 라이브러리로 담을 수는 없다. 폰갭에서 제공하는 API 역시 기본적인 기능만을 제공하고 있다. 대신 기능을 확장할 수 있는 플러그인 형태를 활용할 수 있다. 폰갭에서는 플러그인을 추가할 수 있는 아키텍처를 제공하고 개발자들은 다양하게 활용할 수 있는 플러그인을 만들어 이를 다시 오픈소스로 공개하고 있다.
검증된 앱 개발 프레임워크 Appspresso
앱스프레소는 KTH에서 지난 11월 30일 정식 출시한 하이브리드 앱 개발 프레임워크이다. 이미 3월 베타 버전이 나오면서 ‘얼굴인식’이라는 앱을 해당 프레임워크로 개발했다. 닮은 연예인 찾기라는 흥미로운 아이템 때문에 여전히 화제가 되고 있는 앱으로 사진을 찍거나 앨범에서 가져와서 내부 프로세스를 거쳐 닮은 연예인을 찾아주는 기능을 제공한다. 겉으로 보아서는 전혀 웹의 요소라고 할 만한 것이 보이지 않아서 당연히 네이티브 앱으로 개발했을 것이라 생각했는데 앱스프레소 초기 버전으로 개발된 것이라고 한다.
앱스프레소는 폰갭과 마찬가지로 웹 표준 기반의 하이브리드 앱 프레임워크이다. 하지만 자체적인 디바이스 API를 사용하고 있는 폰갭과는 달리 세계 최초로 WAC(Wholesale Application Community)의 Waikiki API를 지원하는 표준 프레임워크라는 차이를 가지고 있다. WAC는 AT&T, Verizon, NTT Docomo, Softback Mobile, KT, SK Telecom 등 전 세계 24개 이동통신사와 제조업체가 참여해 2010년 만들어진 애플리케이션 스토어이다. 2010년 Mobile Congress 2010 행사에서 WAC에 대한 소식이 전해졌으나 아직까지는 실질적인 시장에 영향력을 행사하지 못하고 있다. 또한 WAC 자체가 표준 개발 기구가 아니지만 W3C DAP의 표준을 준수하고 있기 때문에 향후 표준과 관련된 논란은 큰 문제가 되지 않을 것으로 보인다.
앱스프레소의 또 하나의 특징은 ‘on the fly building’이라는 기능으로 수정된 소스를 컴파일 과정 없이 실행 중인 앱에 반영할 수 있는 기능이다. 일반적으로 앱을 개발한다는 것은 수정된 내용을 포함해 다시 컴파일 하는 과정을 필요로 하는데 앱스프레소에서는 이런 과정을 생략할 수 있다는 것이다.
KTH의 모회사인 KT에서는 앱스프레소가 공개되기 이전 2010년 12월 올레 SDK라는 개발 프레임워크를 공개했다. 독자적으로 만든 것은 아니고 영국 ideaworks의 AirPlay SDK(지난 6월 Marmalade로 브랜드명이 변경됐다)를 공동 브랜드 형식으로 공개했으며 초기에는 개발자 경진대회를 개최하는 등 다양한 활동을 진행했다. 하지만 지난 10월 올레 SDK는 공식적으로 서비스를 종료했고 현재는 다양한 운영체제에서 활용할 수 있는 모바일 API와 지도 API, 디자인, 사운드 소스를 제공하는 활동을 진행하고 있다. 히스토리를 잘못 이해하면 올레 SDK가 앱스프레소가 된 것이 아닌가 싶은데 전혀 다른 배경을 가지고 있다.
기업용 하이브리드
기업용 시장에서 주목받고 있는 것이 MEAP(Mobile Enterprise Application Platform)인데 다양한 모바일 환경에서 발생하는 문제점을 해결하기 위한 방법론을 제공하는 것을 목적으로 하며 금융, 물류, 제조, 서비스 등 산업 전반에 걸친 영역을 표준 기반에서 대응할 수 있도록 제공하고 있다. MEAP가 갖춰야 할 요건들을 보면 적은 비용으로 다양한 스마트폰 환경에 적용할 수 있어야 하며 IDE를 지원해주어야 하며 관리, 보안 기능을 제공하고 백엔드 통합에 대한 요건들을 충족시켜주어야 한다. 이런 요건을 충족시키기 위해 모든 운영체제를 개별적으로 대응하기는 힘들기 때문에 선택된 방법이 하이브리드 앱 개발방식이다. MEAP 관련 벤더들은 독자적으로 하이브리드 프레임워크를 개발하거나 관련된 기업을 인수하는 형식으로 이러한 부분을 보완하고 있다. 삼성 SDS나 SK C&C가 독자적인 모델을 만들어가고 있고 KT의 경우에는 안테나 소프트웨어의 AMP를 기반으로 KEMP라는 플랫폼으로 다양한 레퍼런스를 만들어내고 있다. 기업용 RIA 솔루션 업체도 모바일 시장에서 하이브리드 전략을 펼치고 있다. 투비소프트의 ‘엑스플랫폼’ 하이브리드 버전의 경우 파트너사와 함께 실제 프로젝트를 진행하고 있으며 최근 일본에서도 세미나를 진행하면서 많은 관심을 불러 모았다. 인스웨이브의 ‘웹스퀘어’ 제품군도 조만간 하이브리드 버전을 공개할 예정이라고 한다. 기업에서 사용하는 하이브리드 앱 개발 프레임워크는 단순한 콘텐츠 활용이나 디바이스 API를 사용할 수 있다는 것 이상의 성능과 안정성을 요구하기 때문에 범용적인 하이브리드앱과는 차별성을 가지게 된다.
트위터의 선택
최근 몇 차례 업데이트를 거쳐 트위터 웹페이지가 어느 정도 쓸만해졌지만 이전까지는 사용자들의 요구사항을 반영할만한 여력이 없었다. 하지만 트위터에서 제공하는 API가 워낙 강력한 기능을 제공하고 있어서 트위터 웹페이지를 거치지 않고 다른 트위터 애플리케이션을 주로 사용하게 됐다. 그 중에서 화면 가득 다양한 트윗을 보여주는 트윗덱(http://www.tweetdeck.com/)이라는 서비스는 편리성과 강력한 확장성 때문에 국내에서도 많이 전파가 되었고 언론에서도 트위터 사용자 인터뷰에 항상 등장하는 화면이 되기도 했다. 트윗덱은 어도비 AIR의 킬러 애플리케이션이기도 했다. 다른 애플리케이션과 달리 맥, 리눅스, 윈도우를 동시에 지원하기 때문에 다양한 환경에서 사용할 수 있었고 알람이나 멀티 계정 운영등의 기능을 포함시키면서 모니터링 툴처럼 사용되기도 했다.
(그림 4. 트윗덱 – 크롬 웹 스토어)
이런 강력함 때문인지 트위터에서 트윗덱을 견제하기 시작한다는 소문이 돌았고 결국에는 지난 5월 5천만 달러(540억원)에 트윗덱을 인수해버렸다. 그리고 12월초 새로운 트윗덱을 공개했는데 가장 큰 이슈가 된 것은 어도비 AIR 플랫폼을 더 이상 사용하지 않는다는 것이다. 웹, 브라우저 앱(크롬 브라우저에 설치되는), 데스크톱 애플리케이션이 모두 HTML5 기반으로 재구성되었고 어느 환경에서든지 동일한 UI를 경험할 수 있는 새로운 시도를 했다. 일부 기능이 빠지면서 사용자들의 불만도 있었지만 HTML5가 다양한 환경에서 어떤 영향을 미치는지 경험해볼 수 있는 하나의 사례가 아닌가 싶다.
하이브리드 자전거는 거친 산을 달리기에는 무리가 있고 로드의 속도를 따라잡지는 못한다. 하지만 다양한 환경을 지원해주어야 한다면 최적의 선택일 수 있다. 하이브리드앱도 마찬가지로 모든 환경에서 최선은 아니지만 다양한 환경을 필요로 하고 사용자의 요구사항에 따라 최적의 선택일 수 있다. 필요하다면 이전 마소에 연재된 다양한 글을 참고해보면 많은 도움이 될 것이다.
참고자료
1. Appcelerator Titanium
2. Adobe PhoneGap
3. Callback Project
4. QuickConnect
728x90
