모바일 플랫폼은 이미 한치 앞을 예상할 수 없는 전쟁터이다. 이런 상황에서 연초부터 Sun의 JavaFX Mobile OS, Palm의 Palm® webOS™가 새롭게 등장하면서 더욱 복잡한 상황이 연출되고 있다. 연구 개발해야할 것도 많아지고 있으며, 시장의 흐름 또한 더욱 민감하게 주시해야 한다.

Application을 개발하는 입장에서 타인과 자신으로부터 '어떤 플랫폼을 선택해야 하는지' 끊임없는 질문을 받고 있다. 과연 어떤 플랫폼을 선택해야 효과적인 것일까? 이번 포스팅에서는 다소 원론적인 이야기를 해보고자 한다. 원론적인 이야기일 수 밖에 없는 이유는 제품의 성격, 조직 문화에 따라서 전혀 다른 결론이 나올 수 있기 때문이다. 아래 이야기는 Application 개발자 입장에서 보는 일반적인 관점이라는 것을 염두해 주기를 바란다.


실질적인 마켓크기를 고려해야


흔히 플랫폼의 시장 크기(Market Size)를 단말수와 비례해서 생각하는 경우가 많지만 매우 위험한 생각이다. 위 그림은 각 플랫폼별로 개략적인 누적 판매수이다. Nokia의 S60 플랫폼이 가장 많이 시장에 팔려있다. 그렇다면 Application Developer의 입장에서 저 수치 그대로를 시장 크기라고 판단할 것인가?


시장 크기는 단말 판매량, Data 정액 사용자, Application에 대한 인지도, 유통 채널등이 모두 고려되어야 한다. 그리고, Global 시장을 타겟으로 하는지, Local Market만을 고려하는지에 따라서 수치는 전혀 다르다. huikea.com의 한 보고서에서는 단말 판매량, Data 정액제 가입 비율, 어플리케이션 인지율을 통해서 실제 시장 크기를 계산하였는데, 그중 가장 대표적인 iPhone과 S60을 비교한 내용을 재구성하여 소개한다.


Application Developer 입장에서 보면 시장에 100M 팔린 S60 보다 10M 팔린 iPhone의 크기가 더 크다는 것이다. 위 보고서에 언급되지 않은 요소인 유통 채널의 다양함, 그리고 LCD 크기의 일관성(LCD 해상도가 다양하면 개발 비용이 증가한다.) 등을 고려하면 현재로서는 iPhone 시장이 가장 크다고 해도 과언이 아니다.


Cross Platform에도 관심을

Mobile Platform은 위와 같은 Low level Platform만 존재하는 것이 아니다. Low level platform위에서 작동하는 Cross Platform들이 있다. Flash Lite는 현재 S60과 Windows Mobile 일부에 탑재가 되어 있고, Platform에서 지원하지 않아도 일부 풀브라우저에서 지원하여 Flash가 플레이된다. Flash Lite는 PC 환경과 유사하고, 네트워크와 다운로드 등도 지원하여 간단한 Application이라면 Flash Lite로 충분히 개발할 수 있다.

요즘은 관심사에서 멀어지고 있는 J2ME도 아직은 무시하지 말자. S60과 Blackberry는 기본적으로 J2ME를 탑재하고 있고, Sun의 J2ME와는 약간 다르지만 Android도 Java 기반이다. 다른 플랫폼들이 스마트폰 위에서만 작동되는 것과는 달리 J2ME는 일반폰위에서도 작동이 된다는 것도 플랫폼 전쟁터에서 잊고 있던 상식이다. 가장 큰 시장인 iPhone이 성능 이슈로 인해 Virtual Machine을 포팅하지 않은 것이 아쉬울 뿐이다. 대략적으로 J2ME가 포팅된 누적단말은 1B으로 이야기 되고 있다.

가장 확실한 Cross Platform은 Web 이다. Web만큼 발전되고 독립적인 Platform은 없다. 어디에서나 브라우저만 있으면 Web Application이 작동한다. 이미 'Mobile Native App와 Web App 비교'에서 Web App의 특징을 설명한 적이 있으니 개발하려는 제품이 어디에 적합한지 참고하기 바란다.

Web App의 가장 큰 단점은 Local Resource에 대한 접근을 못한다는 것인데 일부 풀브라우저들은 Ajax나 Dynamic Menu와 같은 기술을 이용해서 Local Resource 접근을 지원하고 있다. 위와 같이 Native App과의 차이가 점점 없어지는 추세이다. Native App과 Web App의 중간이 되는 Web Runtimes App(위젯이 가장 대표적인 예이다.)도 있으니 개발하고자 하는 Application의 특징에 맞추어 선택을 해야 한다.



플랫폼 독립적인 아키텍쳐의 설계가 중요

지금은 플랫폼을 선택할 때가 아니다. 국내만 보아도 Windows Mobile 외의 플랫폼이 이제야 도입되는 시기인 만큼 추이를 지켜보아야 할 필요가 있다. 현재 필요한 것은 다양한 플랫폼에 이식이 가능한 개발 설계를 해야 하는 것이다. 개발의 측면에서 몇가지 주요한 내용을 정리하자면 아래와 같다.



플랫폼보다 중요한 것은 Business를 만드는 것

제품을 개발하기 전에 Platform을 선택하는 것은 어리석은 짓이다. Platform 선택보다 중요한 것은 '어떤 제품(Business)을 개발하는 것이냐'이다. 시장이 어떤 제품을 원하느냐, 그리고 새롭게 적용할 수 있는 기술이 무엇인지를 먼저 고민하고 결정하라. 그 외에 이통사와 제휴를 하거나 Platform별로 이루어지는 Challenge와 같은 기회요인이 있는지 검토를 해보아야 한다.

이런 기본적인 결정이 끝난 후에 제반 사항이 가장 맞는 단말과 플랫폼을 선정해야 한다. 어떤 플랫폼이 다양한 API와 매쉬업 서비스, 그리고 오픈 마켓을 제공한다고 무턱대고 해당 플랫폼을 선택하는 우를 범하지 않기를 바란다.

어느 기업이던 장기적으로 계획을 가지고 개발해야 하는 제품이 있는 반면, 단기적으로 집중 개발하여 타이밍을 맞추어야 하는 제품이 있다. 국내 모바일 브라우저 개발사의 장기 제품이 '위젯'과 같은 플랫폼이라면 단기제품으로는 'Transcoder'가 있다.

PC Web에 맞춰서 개발된 웹페이지를 Proxy Server를 거쳐서 모바일 화면에 맞게끔 DIV나 이미지, 표 등을 재배치하여 html 이나 WAP으로 변환하여 보여주는 기술을 'Transcoder'라고 한다. 주로 동영상의 용어로 사용되었던 'Transcoder'가 일반인들에게 알려진 것은 google 덕분이다. 국내에서도 'google transcoder'기술과 제휴한 SKT나 아이허브 등에서는 WAP 브라우저를 통해서 일반 Web 페이지에 들어가서 검색을 하거나 브라우징을 할 수가 있게 되었다.

현재 위와 같은 솔루션은 구글뿐만이 아니라 WAP 브라우저에서 출발한 대부분의 모바일 브라우저 개발사는 보유하고 있다. 다만 제품의 완성도면에서 구글을 것을 아직은 따라오지 못하고 있으며 구글이 검색과 함께 패키지로  제공함으로 제휴면에서 유리하게 작용하여 맥을 못추고 있다.

생각해보면 이 제품이 일반 html 구문을 분석하는 기술과 그 분석된 내용을 작은 화면으로 재배치 하는 기술 또는 WAP 브라우저에서 사용하는 tag로 재생산하는 기술이 필요한 것을 알 수 있다. 그렇다면 지금껏 WAP 브라우저에서 많은 작업을 했던 WAP 브라우저 개발사에게 꽤나 유리한 제품이라는 것이다. 하지만 '구글'이란 공룡에 밀려서인지 국내 개발사들이 이 제품 개발에 소홀히 하고 있다는 느낌이다. 구글 제품 외에 국내 솔루션이 실려서 국내 WAP 브라우저 내에서 Web 서핑을 하게끔 한단 소리를 들어본 적이 없다. 그나마도 일부 서비스 사업자만이 이를 제공한다. 단순히 시장성이 없다고 이야기 하기에는 조금 아쉬운 감이 있다. 아이허브에서도 소개를 했듯이 사용자들은 별의별 방법을 동원하여 WAP 브라우저에 Web 서핑을 하려고 하고 있다. 국내 사업자에게 상당히 유리한 솔루션이다. 2-3년 후에는 쓸모가 없어질 기술일 수도 있다. 잘 고민해보기를 바란다.