김명신의 즐거운 하루

새로운 플랫폼이 시장에 성공적으로 진입하기 위한 가장 첫번째 선결과제는 플랫폼의 완성도라기 보다는 플랫폼의 저변을 확대하는 것에 있다지만 완성도가 담보되지 않은 플랫폼이 저변을 확대하기란 아주 운이 좋은 경우를 제외하고는 불가능해 보인다.
플랫폼의 완성도와 플랫폼의 저변 확대 사이의 관계는 충분조건이라기 보다는 필요 조건으로 보는 것이 일면 타당해 보이고, 그런 이유로 플랫폼의 저변 확대를 위해서는 반드시 플랫폼의 완성도가 미리 충족되어야 한다.

플랫폼의 완성도가 어느정도 수준에 이른다면 그 다음으로 어떠한 조건들이 충족되어야만 플랫폼의 저변 확대를 꽤할 수 있을까?

1.플랫폼에 대해서 많은 사람들이 이해할 수 있도록 해야 한다.

플랫폼이 가져다 주는 가치 체계를 이해해야 하고, 플랫폼의 용도를 이해하고, 플랫폼의 기술적 내용을 이해하고 또 플랫폼의 실질적인 가치 소득 관계가 명확히 잡혀야 한다. 실질적인 가치 소득이 보장되어야 한다.

2. 플랫폼에서 개발자들이 마음껏 뛰어 놀 수 있도록 해야한다.

구조적 명쾌함, 시류를 약간 늦춰 따라가는 영리함, 강력한 개발 도구를 제공하여 개발자들이 마음껏 플랫폼을 즐기고 이해할 수 있도록 해주어야 한다.

3. 플랫폼이 건전한 생태계 속에서 지속 발전되어야 한다.

고정된 플랫폼이 아니라 사용자들이 지속적인 feedback을 근간으로 성숙해 가야 한다. 타 제품과의 변별력이 없는 과성숙 단계에 이를때 까지 지속적으로 발전하고 성숙해가야 한다.

플랫폼이 시작 진입 단계로 부터 성공으로 옮겨가는 과정이 계획적으로 개발된 완성도 높은 겨우 몇 개의 어플리케이션에 의해서 좌지우지 될 수 있다는 생각은 내 기준에서는 "우둔함" 그 이상도 이하도 아니다.

Windows 8이 과연 하위 호환성을 그대로 유지할 것인가에 대하여 고민하지 않을 수 없다.
Windows 8은 기존의 Intel CPU 외에도 ARM 계열의 CPU을 지원하기로 알려져 있다.
그렇다면 Intel CPU를 이용하도록 개발된 어플리케이션을 ARM 계열의 CPU에서 수행할 수 있을까? 이는 당연히 NO이다.
Intel CPU에서 수행되도록 개발된 어플리케이션을 ARM 계열의 CPU에서 수행하는 방법은 크게 3가지로 나누어 볼 수 있다.

1. CPU 독립적인 Framework/Runtime을 사용하여 개발한다.

예를 들면 .NET Framework나 Winidows8의 WinRT 등과 같은 Runtime 만을 사용하여 어플리케이션을 개발하는 것이다.
기존의 .NET Framework으로 개발된 코드들이 32bits OS에서는 32bit로, 64bits OS에서는 64bit로 수행될 수 있었던 것은, 바로 이와 같은 runtime을 기반으로 하기 때문이다. 따라서 Windows 8에서도 .NET Framework와 WinRT 등 만을 이용하여 어플리케이션을 개발하면, 이러한 Runtime이 ARM 계열의 CPU에서 정상적으로 포팅(porting)되었다는 가정하에 수행이 가능하다.

2. Emulation 환경을 제공하는 방식이다.

3. Cross Compile을 수행한다.

이는 Source Code가 이미 있다고 가정하고, Source Code를 Intel용 혹은 ARM용 으로 구분하여 컴파일하는 방식이다. 이렇게 되면 CPU별로 서로 다른 실행파일이 독립적으로 생성된다. 소스코드가 없는 경우 ARM 지원이 불가능하다.

그렇다면 Windows 8의 경우에는 Intel/ARM 계열의 CPU를 어떻게 둘다 지원하겠다는 것일까? 위에서 알아본 3가지 방법 중, 1과 3번을 적용할 것으로 보인다.
즉 .NET Framework을 이용하여 개발된 어플리케이션들은 Intel/ARM 계열에서 정상적으로 동작될 것을 보장하려고 최대한 노력할 것이다. 이렇게 말한 이유는 이미 마이크로소프트에서 기술 지원 연한이 종료된 .NET Framework 1.0/1.1나 현재까지는 기술지원을 하고 있으나 곧 기술지원이 종료될 것으로 예상되는 .NET Framework 2.0이 Intel/ARM에서 모두 수행될 가능성은 낮아 보이기 때문이다.
또한 Visual Studio와 같은 개발 도구에서 ARM 계열의 CPU에 맞도록 컴파일 Type을 지원하여 기존 source에 대한 Cross Compile을 제공할 것이다.

그런데,
그렇다면 기존에 윈도우에서 수행되던 어플리케이션들은, 제조사가 어떤 CPU를 사용함에 따라 수행이 가능할 수도 있고(Intel), 수행할 수 없을 수(ARM)도 있다는 것인가? 지금까지 공개된 내용만을 보면 그렇다.
Intel CPU를 이용하여 양산된 Windows 8 기반의 제품들은 기존의 어플리케이션들을 모두 수행할 수 있을 것이고, ARM 계열의 CPU를 이용하여 양산된 Windows 8 기반의 제품들은 기존의 어플리케이션들 중, 아주 소수의 어플리케이션들만을 겨우 수행할 수 있는 수준에 머물게 될 것이다.

Windows 계열에서 제공해 오던 하위 호환성이라는 최고의 장점이 "선택적 호환성"이라는 이름으로 탈바꿈 할지도 모를 일이다.
게다가 Windows 8이 후발 주자로서 IPad와 같이 시장에서 확고한 자리를 선점한 Form Factor 제품과 싸우는데 있어서 가장 큰 무기는 새로운 UI도 강력한 성능도 오래가는 배터리도 아니라, 바로 기존의 어플리케이션을 그냥 수행할 수 있는 점 일 것이다.

이와같은 "선택적 호환성"이 시장에서 성공할지의 여부는 두고 볼 일이다.
두 자식 중 하나만 시장과 사용자의 선택을 받을지, 혹은 두 자식 모두 건강하게 시장에서 자리 잡을지 지켜볼 일이다.

Windows Phone에서는 Launchers와 Choosers라는 기능을 이용하여 윈도우 폰에서 수행되는 앱이 자주 사용하게 되는 기능들을 편리하게 재사용할 수 있도록 하고 있습니다.
Launchers에 포함되어 있는 기능들이라면, email 작성 프로그램이나, 빙맵, 전화걸기, 링크 공유, SMS(문자) 작성, Web Navitation  등이 있고요, Choosers에 포함되어 있는 기능들이라면, 주소 선택, 전화번호 찾기, 사진 선택 등의 기능들이 포함됩니다.
사실 이렇게 Launchers/Choosers라고 구분할 이유는 별로 없을 것 같으나, Launcher의 경우 반환 되는 정보가 없고, Chooser로는 반환 되는 정보가 있다 정도로 구분지어진 것이라고 보면 됩니다.
Launchers던 Choosers던 상관없이 윈도우 폰에서 공통적으로 자주 사용하는 기능들을 모아둔 것이라고 보면 되겠지요.

그런데 스마트폰이나 패드류의 하드웨어와 같은 consuming device들이 공통적으로 하는 큰 작업 중의 하나가 구매(Purchase)임에도 불구하고, 이번 윈도우 폰에는 구매를 위한 어떠한 Launchers나 Choosers도 포함되어 있지 않아 매우 실망스럽습니다.

또한 윈도우 폰에서 제공해주는 API 군들을 잘 살펴보면, Launchers Choosers 뿐만 아니라 대부분의 기능이 쉽게 사용하도록 구성은 되어 있지만 확장성이 상당히 미약함을 알 수 있는데, People Hub에는 Custom Application을 추가할 수 없고, Launchers Choosers에도 새로운 Launchers나 Choosers를 만들어서 포함시킬 수 있는 방법이 없습니다.

새로운 Lanchers/Choosers 등을 사용자가 추가할 수 있도록 API가 디자인 되고, 이를 이용하여 자국의 실정에 맞는 결재 방식을 제공함으로서, in-app purchase 등에서 효과적으로 사용할 수 있을텐데 말이죠. 유감 천만입니다.(이러한 기능은 이미 안드로이드에서는 제공되고 있습니다.)

Windows Phone의 Launchers
http://msdn.microsoft.com/en-us/library/ff769550(v=VS.92).aspx

Windows Phone의 Choosers
http://msdn.microsoft.com/en-us/library/ff769543(v=VS.92).aspx

올해 초여름에 한국 마이크로소프트에서 Microsoft TechFair 2011 이라는 행사를 기획하고 진행한 바가 있었습니다. "The Cloud on the road"라는 주제를 가지고 마이크로소프트의 Cloud 기술에 대해서 발표를 하였는데요, 그 중에 제가 직접 진행하였던 Windows Azure Programming 세션을 동영상으로 제작하여 올려두었습니다.

Windows Azure Programming을 어떻게 하는 건지 궁금하신 분께는 도움이 되실 듯합니다.
http://youtu.be/iVVmGbh23II

스마트폰의 앱 개발이 iphone의 시작으로 폭발적으로 성장하게된 이유는 여러가지로 해석이 가능하겠지만, 누구나 동의할 수 있는 하나는 개발사(자)들이 이를 통해서 새로운 수익창출의 기회를 폭넓게 가지게 된 것이라는데 있다고 하겠다.
애플의 앱스토어는 개발자:애플=7:3의 수익 분배 구조를 가지고 있기 때문에 인디개발자(사)로부터 꽤 규모를 갖춘 개발사에게 새로운 수익창출 모델이 되었다.
이러한 장터모델과 뛰어난 환금성으로 인해 XCode라는 낯선 개발 Tool, Object C라는 낯선 언어, 매킨토시를 사용해야만 하는 낯선 운용환경에도 불구하고 수많은 개발자(사)들이 이에 뛰어들어 앱 개발 시장을 계속해서 확장해 가고 있다.

윈도우폰의 기본전략도 이와 같은 방법을 취해야할 필요가 있다. 마이크로소프트의 강력한 세계 최고의 개발자(사)들은 마이크로소프트를 떠받들고 있는 최고의 전략이자 도구가 된다.
하지만 그들에게도 현실적인 수익와 때돈 벌이의 장을 마련해 주지 못하면 윈도우 폰이 아무리 플랫폼의 완성도가 높다한들 시장에서의  성공 가능성은 0으로 수렴할 것이다.
앱개발의 저변 확대를 위해서 가장 중요한 요소로 보는 것이 바로 이점이다.

1. 마이크로소프트 또한 개발자:마이크로소프트=7:3의 수익 분배 구조를 가지고 있음을 충분히 강조해야한다.
이는 부연 설명이 필요하지 않을 것 같다.

2. 앱 내부에 광고를 손쉽게 포함시켜서, 무료 앱이라 하더라도 수익을 가져갈 수 있도록 해야하고, 사용량이 많은 훌륭한 앱을 개발한 개발사(자)가 지속적으로 수익을 가져갈 수 있도록 해야한다.
생각보다 약간 복잡할 수 있다. 모바일 광고를 위한 플랫폼이 확보 되어 있어야 한다.
광고주가 있어야 하고 광고를 만들고 광고를 전달하고, 광고를 수신하는 방법을 고려해야 한다. 마이크로소프트가 이미 Mobile Advertising에 대해서 폭넓게 작업을 진행하고 있지만 한국내에 이것이 언제 도입될지는 알 수 없으므로, 국내에 이미 어느 정도 활성화 되어 있다고 생각되는 모바일 광고 플랫폼을 사용할 수 있도록 해야한다. 구글의 애드몹이나 애플의 아이애드는 모르겠고, 다음의 Ad@m이나 시장참여를 준비중인 NHN의 모바일 광고 플랫폼 등을 핵심으로 두고, Visual Studio와 같은 강력한 개발 Tool 내부로 광고를 Consuming할 수 있는 손쉬운 기능을 끌고 들어와야 한다.

3. 앱 내부에서 결재가 가능하도록 해야한다.
앱 내부에서 결재가 가능한 플랫폼과 손쉽게 적용 가능한 개발 Framework이 필요하다. In App Purchase라고 알려진 이 기능은 장터를 제공하는 회사의 플랫폼을 이용하도록 제한되어 있으나 다양한 결제 방식(카드, 이체, 휴대폰 소액결제)과 더불어 다양한 플랫폼 개발사를 이용할 수 있다면 더 좋을 것이다.

앱의 다양성을 확보하고 장기적으로 시장을 주도하는 스마트 폰이 되기 위해서는 결국 "자본이 이끄는" 형태로의 방향설정이 시급하다고 하겠다.

"카카오톡 for 윈도우 폰" 정도로는 절대로 시장에서 성공할 수 없다.