모바일 왕국을 꿈꾸며!!! mobizen@mobizen.pe.kr

Posted
Filed under 모바일 일반
이 포스팅은 mobizen도 잘 알고 있는 퓨처워커님의 'SKT App Store의 히든 리스크, Complexity'에 대한 다른 접근을 말하고자 함이다. Tumbler에 간략하게 정리를 했다가 좀 정형화할 필요도 있고, 업계의 중요한 역할을 하고 계시는 퓨처워커님의 포스트이기 때문에 그냥 넘어가기는 아쉬움이 남아 포스팅 한다.


대전제에는 공감

SKT 앱스토어가 복잡한게 사실이다. 개발자는 다양한 Device를 고려해야하고, 사용자 입장에서는 기존 Contents Mall과 다른 점을 알 수가 없다. 그리고 사실 SKT의 현재까지의 앱스토어 전략 발표는 허술하기 짝이 없어 많은 이들에게 실망을 준 것도 사실이며, 비판 받아 마땅하다. 하지만 논리가 날카롭지 않으면 그 또한 문제이다. 퓨처워커님의 글이 틀리고 무조건 mobizen말이 맞다는 것이 아니고, 조금 생각이 다르기 때문에 다양한 의견의 소통이 필요하다는 취지에서 생각을 정리하며 공유해본다.


모든 S/W 개발툴은 복잡해

모든 S/W 개발툴은 사실 비엔지니어 입장에서 복잡한게 사실이다. OS가 있고, 그 위에 미들웨어 플랫폼이 있다. 그 미들웨어 플랫폼 위에 Native Application과 Widget으로 구분되는 Application이 실행된다. 각각의 제품을 개발하기 위해서 Language를 익혀야하고, 그 위에 돌아가는 Framework 또한 이해가 필요하다. 그것만으로 되는 것은 아니고 각종 라이브러리를 사용해야 하며, UI 개발툴도 있다. 사람에 따라 Widget의 Define과 Platform의 범주가 다르지만 개발에 이러한 복잡한 요소가 필요한건 대동소이하다. 모든 사람들이 간편하다고 하는 iPhone의 경우를 예로 들어 구분을 해보자.

사용자 삽입 이미지

위와 같이 Native Application의 경우 다양한 개발툴을 통해야만 완성도 있는 제품을 만들어 낼 수가 있다. 그렇다면, 복잡하다는 SKT 앱스토어의 경우는 어떨까? Widget을 제외한 Native Application(정확하게는 VM)만 고려해서 구성해보자.

사용자 삽입 이미지

WIPI C와 GNEX가 Middle ware 통합 플랫폼이므로 OS에 독립적이며, Language, IDE, Compiler를 모두 지원한다. 아이폰과 비교할 때 COGP라는 Tool이 하나 있지만 COGP는 말그대로 Tool이다. 개발된 어플을 스마트폰위에서 돌리고 싶을 때 사용할 뿐, 필수 요소는 아니다.

어느 쪽이 더 복잡해 보이는가? 더욱 중요한 것은 개발자들이 어느쪽이 친숙하냐일텐데, 국내 모바일 개발자들에게 WIPI C, GNEX와 XCode 중에 어느 쪽일까? 솔직한 심정은 '복잡한 개발툴' 보다는 '이제껏 준비해 놓고 바뀐건 없네' 쪽인데..


해외 이통사는 앱스토어를 잘 준비?

퓨처워커님이 예로 든 해외 업체들을 한번 살펴보면
T-Mobile, Verizon, Softbank, China Mobile, Vodafone, AT&T 이다. T-Mobile가 집중하는 안드로이드는 스마트폰 플랫폼이며, 이제껏 단 하나의 모델만 나와있다. 현실상 Feature 폰의 플랫폼이 안드로이드가 될 수 없으므로 단일 플랫폼이라는 것은 조금 과장이다. T-Mobile의 모든 폰들이 스마트폰이 될수는 없을 것이다. 게다가 SKT의 앱스토어는 Feature 폰 Target이다. 앱스토어의 타겟 Segment가 잘못되었다는 지적은 가능하지만, 단말 하나 나온 스마트폰 플랫폼과 수평 비교는 조금 무리수가 있다.

Verizon, Softbank, China Mobile, Vodafone이 단일화 한다는 위젯 플랫폼이 사실 이번 SKT 앱스토어의 핵심이다. 성능이야 아직 알 수 없으나 Nate MoA, 1mm, Doozle, T interactive를 거쳐왔던 대기화면과 위젯 플랫폼을 i-topping으로 단일화 한다는 것 아닌가? 언급된 JIL은 하나의 기업일 뿐, 그 규모와 참여 이통사수가 복잡성의 이슈는 아니다.

사용자 삽입 이미지


COGP는 Tool일뿐

앞서 이야기 했지만 COGP는 개발 플랫폼이 아니라 Tool이다. 그것도 Game 컨텐츠만을 위한 Tool이다. COGP와 WIPI는 서로 선택의 수평선에 놓일 수 없다. 그러한 선택을 굳이 예로 들어야 했다면, WIPI C와 GNEX를 비교해야 옳다. 그리고 SKT는 사업설명회에서 'RTOS위의 WIPI는 당분간 포기하지 않겠다'라는 의사를 분명히 밝혔었다.

이통사 입장에서 다양한 플랫폼과 단말이 존재하는 것은 장점이자 단점이다. 단점이라함은 주로 사업자 위주의 시각이고, 장점이라함은 사용자의 시각이다. 스마트폰의 플랫폼이 너무 난립하는 것은 결론적으로 소비자에게도 피해가 가지만, 그렇다고 Feature 폰을 버린다는 것 또한 극단적이다. 개인적으로 스마트폰 앱스토어는 플랫폼이나 단말사 위주로 구성되고, 이통사 앱스토어는 Feature Phone 위주가 되는 것이 맞은 Positioning이라는 생각이다.

사용자 삽입 이미지


이슈는 다른 곳에

다시 한번 말하지만 퓨처워커님의 'SKT App Store의 히든 리스크, Complexity'라는 대명제에는 동의한다. 다만, 접근이 조금 잘못되지 않았냐는 것이다. SKT의 앱스토어의 복잡성에 대한 문제는 오히려 다른데에 있다는 의견이다.

첫번째로 i-Topping의 위젯 표준화 문제이다. i-Topping을 개발했던 벨록스가 워낙에 일찍부터 위젯 플랫폼을 준비하는 바람에 i-Topping은 전혀 위젯 표준화에 대한 고려가 되어 있지않다. 다양한 사업자들이 쉽게 위젯을 만들고, 만들어낸 위젯이 재사용되기 위해서는 JIL의 참여보다는 표준화에 대한 노력이 필요하다. WIPI도 그러더니 SKT의 플랫폼은 항상 이러한 국제 표준에 대한 노력과 배려가 부족하다.

두번째는 COGP의 한계이다. COGP는 Game 컨텐츠를 위한 변환툴이다. 사실, COGP와 같은 Cross Platform 변환툴은 게임 이외의 요소에 적용하기에 문제가 많다. 스마트폰 어플을 개발할 때 중요한 요소 중에 하나가 각 플랫폼에 있는 embeded Component이다. 아이폰에 있는 Safari 객체, Windows Mobile에 있는 IE 객체등이 대표적인 예이다. 하지만, 이러한 Cross Platform Converting 툴은 embeded Component를 지원할 수가 없다. 아직까지 국내 스마트폰 사용 비중에서 업무용을 무시할 수 없다는 것을 고려해보면 이번 앱스토어의 크나큰 결점이며, SKT가 보는 스마트폰의 중요도를 알 수 있다.

세번째는 역시 정책적인 복잡성이다. 아직 발표는 나지 않았지만 기존 컨텐츠몰과의 차별성과 사용자의 인지 혼란, 이번에 발표된 개발플랫폼으로 기존 Walled Garden용 컨텐츠를 개발하면 안되는건지 등 수많은 정책의 모호함이 남아 있다. 6월까지는 기다려 봐야 할 듯 하며, 가장 핵심이 되는 이슈라고 생각한다.

사용자 삽입 이미지

시장에 대한 애정어린 비판은 필요하다. 하지만 정확한 비판만이 좋은 Feedback을 만들어 낼 수 있을 것이다. 조금은 aggressive한 포스팅이지만 퓨처워커님의 공력을 알기에 생각을 공유를 해본다. 혹시 mobizen이 잘못 생각하고 있는 부분이나 다른의견이 있다면 리플이나 트랙백으로 알려주기 바란다.
2009/04/29 02:31 2009/04/29 02:31
제이펍

이의제기 잘 보았습니다. RSS로 구독하고 있는데, 객관적인 자료를 바탕으로 정확한 분석을 하고 계셔서 많은 도움을 받고 있습니다.
저의 짧은 안목으로도 이번 SKT의 앱스토어 전략에 말못할 문제가 있는 것 같습니다.
히든 리스크가 복잡성이 아니라, 핵심 전략이 모호함으로 비쳐지고 개발자들은 그 안개가 언제 걷히는지 기다리고만 있으니 많이 아쉽네요.

mobizen

핵심전략의 부재야 사실 말해야 입만 아플 정도입니다. SKT 내부에서 지속적인 세미나와 컨설팅을 진행하고 있으나, 별게 나오진 않을거라고 예상합니다. 제자리 걸음이겠죠...

goodidea

지금까지 이통사의 발빠르지만 일관성없는 모바일 전략이 오늘의 복잡성을 만들어낸게 아닐까요.

mobizen

넵. 맞는 말씀입니다. ^^

퓨처워커

역시 모비즌님. 급조한 포스트에 논리정연하게 의견을 주셨네요. 감사합니다. 최소한 "복잡성"이라는 키워드 하나에 대해서만이라도 좀 적어보려고 했습니다만, 시간 관계상이란 그리 다듬지 못한 내용인데 역시 선수의 눈은 벗어나지 못하는군요. 아마 다음달쯤에 다른 경로(?)로 차분하게 정리해볼 생각합니다. 시각이 다른 것이 바로 블로그의 재미인 것 같습니다.

mobizen

ㅎㅎ 이해해 주실 줄 알았습니다. 서로 다른 시각과 의견을 공유하고 발전시켜 나가는게 블로그의 참 재미죠. 참고로 K 모바일 제목이 참 가관입니다. 논쟁 가열은 무슨..요즘 K 모바일도 너무 선정적이라 KIN 이예요.

그나저나 요즘 얼굴 뵙기 힘드네요. 많이 바쁘신가 봐요. 혹시 오늘 MS 행사에 오시나요?

Aspirant

그런데 한가지 궁금한 것은 컴파일 도구는 모두 제공해주는 건가요? 예를 들어 WIPI-C를 컴파일하려면 CPU나 OS에 따라서 컴파일러가 다 달라집니다. 그런데 그중에서 핸드폰에 많이 사용되는 ARM을 위한 컴파일러는 ADS(ARM Development Suite)와 RVDS가 있는데 가격이 사용자당 1천만원을 넘습니다.
이 것에 대한 부담을 일반 개발자가 져야한다고 한다면 개인 개발자 참여는 불가능 합니다. 기존의 솔루션 업체들이 지금과 변화없이 그대로 가겠지요. 다시 말해서 말만 앱스토어지 그냥 과거랑 똑같은걸 아닐런지요...??

mobizen

WIPI는 미들웨어 플랫폼인데 다른 놈과는 조금 다르죠. Native Application이 있고, VM의 영역이 있습니다. 보통 단말사 내장 어플리케이션을 개발할 때는 Native Application로 만드는데 이때는 말씀하시는 것 처럼 ADS가 필요하죠. 맞죠. 천만원이 넘습니다. 이쪽 영역은 거의(!!) 단말사의 영역입니다.

이통사의 앱스토어는 컨텐츠(Application)를 만들어 판매하는 Market Place 입니다. 다운로드가 되어야 하고 삭제, 추가, 업그레이드가 되어야 합니다. VM 형태로 제공되죠.

이통사 상황에 따라 다르긴 하지만 이때는 ADS가 필요없어 질 것 같습니다. COD를 통한 컴파일을 하거나 현재 이통사에서 개발 중인 Local Compiler(거의 완성된 것으로 알고 있습니다.)를 사용하면 될 듯 합니다. 뭐. 나와 봐야 나왔나보다 하는거긴 합니다..

그리고 SKT의 경우 GNEX는 컴파일러까지 같이 제공하니깐요. ^^

namomo

비싼 ADS가 아닌 GCC를 이용할 수도 있습니다. SKT에선 툴 체인 패키지로 묶어 배포하기도 하고요. 현재는 일반인에겐 배포하지 않고 있지만 mobizen님 말씀처럼 일반 개발자들에게도 공개하지 않을까 싶네요

mobizen

namomo님 리플과 정보 감사합니다.

사실 플랫폼 제공업체에게 컴파일러까지 책임져주라는 것은 다소 무리한 요구라고 생각하고 있습니다. 해주면 고맙지만, 개방의 이슈는 아닌 것 같아서요.

안용규

좋은 글 잘 읽었습니다. 제가 지금 하는 일이 앱스토어 전략을 짜는 일인데 참 어려움이 많습니다. 어떻게 해야 개발자 분들의 가려움을 긁어 줄 수 있을지 고민이 많습니다.