김명신의 즐거운 하루

Windows 8의 Metro style app은 설치 과정과 실행 과정이 기존의 전통적인 desktop application과 사뭇 다릅니다. 하지만 Disk 어딘가에 저장되어 있는 것은 분명할 것이고, 이미 설치된 Metro style App들을 참고할 수 있다면 개발과정에 많은 도움이 될 것 같아서 조금 살펴보았습니다.

Metro Style App은 어떤 언어를 사용하여 개발되었는지에 따라 수행 모델이 조금 상이한데, 개발 언어에 따라 다음과 같이 분류해 볼 수 있겠습니다.

1. C++, XAML : native binary 생성

2. C#, XAML : managed binary 생성

3. Javascript, HTML : 추가로 코드를 생성하지 않고 javascript와 HTML을 그대로 packaging

1과 2의 경우는 실행파일(executable)이 생성되기 때문에, 이를 수행하면 상관이 없지만, 3번의 경우 적절한 surrogate process가 반드시 필요하겠지요. 이 경우 WWAHost.exe 가 그 역할을 담당하게 됩니다.

다음과 같이 한번 확인해 보시죠.

1. 기본으로 설치된 Metro style app 중 Finance를 수행합니다.

2. Desktop 으로 돌아와서 작업관리자(Task Manager)를 띄웁니다.

3. 오른쪽 마우스 버튼을 클릭하여 Go to Details를 누릅니다.

4. Details 탭으로 이동하게 되는데 다음과 같이 WWAHost.exe 가 선택됨을 알 수 있습니다.

5. WWAHost.exe 프로세스 내부를 살펴보기 위해서는 여러가지 도구를 활용할 수 있지만, 그 중 가장 간편한 Process Explorer(http://technet.microsoft.com/en-us/sysinternals/bb896653 ) 와 같은 도구를 이용해서 WWAHost(8140) Process를 살펴보면 다음과 같습니다.

예상하실 수 있는 바와 같이 jscript9.dll 파일이 load되어 있고, mshtml 등도 로드되어 있음을 알 수 있습니다.

사실 오늘 말씀드리고 싶었던 내용은 이미 설치된 파일의 내용을 한번 들여다 보고자 하는 것이기에 이 정도에서 Process Model은 각설하고, 좀더 아랫쪽으로 내려가 보도록 하죠.

Process Monitor(http://technet.microsoft.com/en-us/sysinternals/bb896645 )와 같은 도구를 이용하면 특정 프로세스가 접근하는 레지스트리나 파일 등등에 대해서 조목조목 그 내용을 살펴볼 수 있는데요, 이 도구를 이용하여 Metro style app들의 구동시에 동작 메커니즘을 쭉 따라가다 보면 Startup시에는 Registry에 집중적인 접근이 나타나고, 이후에 Program Files\WindowsApps 라는 폴더로 부터 Binary들에 접근함을 알 수 있습니다.

따라서 Metro App의 설치 과정이 이 폴더와 연관성이 있음을 단번에 알 수 있습니다. 이 폴더에 접근하기 위해서는 조금 까다로운 절차를 거쳐야 합니다. (권한설정 등의 정보를 변경하면 조금 쉽게 접근할 수 있지만 다시 rollback을 하는 것이 귀찮으므로 다른 방법으로 접근해 보죠.)

1. 명령창을 관리자 권한으로 엽니다.

2. Explorer.exe를 수행합니다.

3. 탐색기 탭의 View 에서 Hidden items를 check 하여 숨겨진 폴더를 살펴봅니다.

오호라, 일단 숨겨진 “WindowsApps” 폴더가 있음을 발견하셨지요?

4. 더블클릭 해도 폴더 내용이 보이지 않고 약간의 경고 창이 뜨면서 security tab을 이용해서 access 권한을 설정하라는 내용이 나타날 겁니다. 이 폴더의 소유권은 TruestedInstaller가 가지고 있는데, 소유권을 뺏어와서 내 맘대로 그 내용을 살펴 볼 수도 있겠지만 추후 작업이 귀찮아지므로 참기로 하고 대신 관리자 권한으로 띄웠던 명령창을 이용해 봅시다.

5. C:\Program Files\WindowsApps 폴더로 이동하여, dir을 해보면 여러 폴더가 보일텐데요, 이 중 Finance라는 Keyword를 가진 folder를 찾아보면 다음과 같은 결과가 나옵니다.

6. 이 중 version 정보가 1.0.1030.0 인 폴더로 이동한 다음 dir을 해보면

7. Finance App이 구성하고 있는 모든 파일들의 List를 살펴볼 수 있습니다.

8. 폴더 각각을 드려다 보면 html 파일과 javascript 들이 어떻게 작성되어 있는지 source level로 그대로 확인해 보실 수 있습니다.

Javascript/HTML은 source 자체가 packaging 되므로 위와 같이 쉽게 내용을 살펴보실 수 있지만, C#/XAML은 조금 다를 수 있습니다. 이번에는 C#/XAML 형태로 작성된 녀석들을 살펴보겠습니다.

Solitaire 같은 App이 대표적으로 C#을 이용하여 작성된 코드인데요(참고적으로 C#으로 DX를 사용하는 방법도 아시게 될겁니다.)

1. 절차는 위의 예와 거의 같습니다.

2. XAML 파일과 DLL 파일이 List에 보이는데 XAML 파일은 txt 파일이므로 그대로 내용을 살펴보실 수 있습니다.

3. dll 파일의 경우 managed dll 이므로 reflector(http://www.reflector.net/ )와 같은 도구를 이용해서 그 내용을 살펴보실 수 있습니다.

살펴보신 내용은 제발~~~~ 지구의 평화를 위해서 사용하여 주세요!!!

감사합니다.

몇몇분이 고맙게도 제 글을 읽어주시고 feedback을 보내주셨습니다. 대부분 소스코드의 공개에 대한 불안함을 피력해 주신 부분이었는데요.. 다음과 같이 정리하면 될 것 같습니다.

1. html/js는 소스코드를 볼 수 없었던 적이 단 한번도 없습니다.
   브라우져에서 오른쪽 마우스를 막는 등의 유치한 방법 정도가 있었지만 마음먹으면 몇초 이내로 내용을 다 볼 수 있습니다.
2. Managed Code(C#/VB) 등의 reflection 기술은 이미 오래되고 성숙된 기술입니다.
   기존에 Managed Code로 개발된 모든 binary는 소개해 드린 것과 같은 reflection tool을 이용해서 얼마 던지 볼 수 있었습니다.
3. C/C++ native : 이쪽은 그나마 내용을 쉽게 확인 할 수 없지만, 머리속에서 assembly-->C++로의 reversing을 하는 사람들이 얼마던지 있습니다.

상기 1,2번의 문제점을 보완하기 위해서 스크램블링(난독처리)하는 도구들이 일부 나와 있고, 이 경우 코드를 상당히 어렵게 변경하기 때문에 코드를 읽기가 매우 매우 어려워집니다.

결과적으로, Metro Style App이라고 해서 이전보다 보안이 더욱 취약해서져서 내용이 모두 공개되는 것은 아니며, 기존과 동일 수준이 그대로 유지되고 있다고 보시는 편이 적절합니다. 제 글이 약간 충격적이셨다면 그것은 기존에 이러한 방법을 몰랐기 때문이지 더 나빠진 것은 절대로! 아닙니다.

감사합니다.

Native쪽의 MFC나 ATL들은 약간 접어두고, Managed 세상의 Winform, WPF, Silverlight, WinRT 각각에서 응용 프로그램의 Entry Point이면서 Exit Point인 Application Type을 모두 찾아서 정리해 보았습니다. Type의 이름은 모두 Application이지만 DLL 이름도 서로 다르고, 위치도 다르고 생김새도 다릅니다.

대박 힘들어요.

사람이 엄청나게 많은 출근길의 지하철 2호선. 차량 중간에 대롱대롱 메달려 있는 화면에 애처로운 crash 화면이 애처롭다.
만원 지하철 내에서, 사람들 사이를 비집고 상당히 먼거리에서 줌을 끝까지 당겨서 억지로 한컷 찍어 보았다.
저 메시지 창에서 어떤 의미있는 내용을 파악할 수 있을지 고민해 보자.

글자가 잘 보이지는 않지만 대략적으로 살펴보자.

"Access Violation at address 0040???? in module "TopPlayer.exe". Read of address 0000000C

1. 일단 발생한 Exception은 Access Violation 이다.

Access Violation은 접근하지 말아야할 메모리 공간에 접근하였거나, 접근을 시도했던 메모리가 허용하지 않는 접근을 시도했을 경우 발생한다. 접근하려고 시도 했던 memory address는 0000000C 이다.
0000000C 는 Windows에서 의도적으로 접근 불가 영역으로 설정해둔 파티션에 속한다. 일반적으로 0x00000000~0x0000FFFF의 64K영역은 잘못된 포인터 운영을 알려주기 위해서 접근시 항상 오류를 발생하게 설정해 둔 영역이다. 정확히는 이 Partition은 PAGE_NOACCESS flag로 설정되어 있다.

2. 0x0000000c ??

0040???? 영역에는 application의 code가 있을 것이다. 여기서 수행되는 명령어는 0000000C 주소로 부터 값을 읽어오는 명령어가 포함되어 있을 것인데, 대략 다음과 같은 내용일 것으로 추정된다.

ecx = 0x0000000c
mov eax, [ecx]

혹은

ebp + ? 의 값은 0x0000000c
move ecx, [ebp + ?]

등등...

물론 레지스터는 다른 것일 수 있으나, 동일하게 0x0000000c 주소로부터 값을 읽어 오는 명령어일 것이다. 그렇다면 왜 하필 0x0000000c 일까? 이 값은 0xc 즉, 10진수로 12에 해당하는데, 사실 코드에서 직접적으로 0x0c 주소를 access 하려고 시도했다기 보다는 특정 register 값에 0xc 만큼을 더한 위치를 access하려다가 문제가 생겼다고 보는 편이 더 적절하다.
어떤 경우 이러한 operation이 일어날까? 대표적인 코드들은 다음과 같다.

C++로 개발된 경우 ecx에는 this가 들어간다. 따라서 다음과 같은 코드일 가능성이 높다.

ecx = this가 있고,
mov eax, [ecx + 0xc]

만일 이 경우 ecx가 null이면 0xc address를 access 하게 된다. 혹은 반드시 ecx가 아니라 다른 register를 기준으로 했을 수도 있다. 위의 경우라면 this가 가리키는 위치로 부터 0xc만큼 떨어진 member variable이 되고, 만일 virtual function을 포함하였다면, 0x8 만큼 떨어진 공간일 가능성이 많다. 또한 여기에 포인터 변수가 위치한 경우가 된다.

코드로 보면

class CustomType
{
    int x; int y; int z;
    void *p;
}

혹은

class CustomType
{
// 하나이상의 virtual function
    int x; int y;
    void *p;
}

p에 접근하는 코드가 ecx + 0xc 이다.
그리고 포인터에 접근하는 기준 register인 ecx의 값이 null이다. 이 값이 null인 이유는 너무 다양하지만 프로그램이 정상 수행되다가 갑자기 죽는 경우라면 heap crash일 가능성이 크다.

3. 0040???? 주소에서 오류가 발생했다.

이 주소에 load 되어 있는 코드는 무엇일까?
사실 알 수 없다. 모든 DLL들은 Preferred based address를 가지고 있어서, 자신이 로드되기를 바라는 base address가 있지만, 이 영역이 이미 다른 용도로 사용할 경우, Loader가 rebasing을 한다. 따라서 수행되고 있는 프로세스를 들여다 보기 전에는 여기에 어떤 DLL이 load되어 있는지 알 수 없다. 게다가 VISTA 이상의 OS라면 ASLR(Address space layout randomization) 때문에 로드되는 위치가 중구난방이 된다. (Vista는 아니었던듯)
따라서 저 위치에 어떤 코드가 있었고 어떤 모듈이 로드되었는지를 알고 싶다면 Windbg나 Process Monitor와 같은 Tool을 이용해 보면 된다.

Node.js의 소개글 들에 대한 유감

최근 javascript를 이용한 web application 개발의 새로운 방법으로 유행처럼 번지고 있는 node.js를 다루고 있는 많은 글들을 보게 된다.

대부분의 글과 문서, 책 등을 살펴보면 node.js의 우수성을 알리기 위해서 아파치 웹 서버에 비해 더욱더 높은 성능을 가지고 있으며 메모리 사용량도 적을 뿐만 아니라, 사용자가 아무리 늘어도 메모리 사용량이 거의 일정하다고 그래프를 그려가면서 힘 주어 이야기 한다.

이러한 장점을 가져오는 node.js만의 특징으로 다음과 같이 3가지를 이야기 하고 있다.

 

1.     Event loop

2.     단일 Thread

3.     Async. I/O

 

더 나아가서는 이러한 방식의 도입이 획기적 일뿐만 아니라 혁신적이기까지 하다고 한다.

약간 심하게 말하면 형편없고 터무니 없다. 개인적인 경험으로는 20년 전의 Windows 3 Programming을 처음 시작했을 때, Message Loop, 단일 Thread에 의한 비선전형 Multitasking을 이야기하였고, 단일 메시지를 처리할 때 너무 많은 시간을 소비하면 안되기 때문에 비동기 I/O는 계속적인 관심 대상일 수 밖에 없었다. 그런데 갑자기 이러한 기능이 획기적이고 혁신의 반열에 까지 들어서게 된 것은 웬일이란 말인가?

이러한 황당함은 모 개그 프로그램처럼 70년대 생 이상만 공감할 수 있는 개그인가?

 

Event Loop은 수십년간 이미 잘 알려진 기법이고 GUI를 이용하는 OS의 경우 대부분 내부적으로 이 방법을 사용하고 있으므로 별다를 것이 없다.

 

Network Application에서 단일 Thread를 이용해서 Client의 Request를 순차적으로 처리하는 방법과 Request별로 Thread를 생성해서 처리하는 방법, 일정 수의 Thread를 생성하여 Thread Pooling을 수행하는 방법 등은 이미 수십 년 전부터 그 각각의 특징이 분석되고 그 장단점이 충분히 논의 되어 왔다. 게다가 지금과 같이 Multi Processor, Multi Core의 CPU를 사용하는 경우, 단일 Thread만일 이용하면 충분히 Processor, Core의 능력을 사용하지 못한다.(Node.js의 Cluster따위는 말할 필요도 없다.)

 

비 동기 I/O는 작업을 시키는 입장에서는 그 작업에 대해서 더 이상 신경 쓰지 않고, 요청한 작업이 완료되거나 혹은 여타의 이유로 작업이 중단되는 경우 그 결과만을 통보해 주는 기법이지만, CPU 입장에서는 그것이 User Mode이건 Kernel Mode이건 상관없이 특정 Thread가 작업을 처리해 주어야만 한다. User Mode혹은 자신의 Framework에서 단일 Thread만을 쓰기 때문에 시스템 전반에 걸쳐서도 효율적으로 운용될 것이라는 것은 망상에 가깝다.

 

효율적인 알고리즘을 사용한다면 처리속도와 메모리와 같은 저장소의 효율 상에는 항시 반비례 관계를 가지게 된다. 처리속도를 높이려면 더 많은 메모리를 사용하면 되고, 메모리를 적게 쓰려면 처리 속도를 희생하면 된다.

 

그렇다면 node.js가 가진 진짜 장점은 무엇일까?

개인적으로 가장 좋아 보이는 부분은 javascript를 이용한 전방위 개발이며, 독립적인 수행 환경이다. Client side, server side를 고려하지 않고, javascript language를 이용하여, 타 system 이나 runtime의 도움 없이 독립적으로 수행 가능한 것은 상당히 큰 장점이다. 기존에 javascript가 다른 그 무엇을 수행하기 위한 보조적인 용도로만 사용되었다는 것을 생각해보면 상당한 장점이라 할 수 있겠다.

추가적으로 node.js가 나온지 그리 오래되지 않았음에도 불구하고 상당히 폭발적인 반응을 끌어 모으고 있다는 점이다. 패키지의 수와 안정성과 더불어, 주요 기업들이 node.js에 대해서 전방위적인 지원을 아끼지 않고 있다. Microsoft, Ebay, LinkedIn, Yahoo 등이 대표적이다.

 

옛말에 “모로가도 서울만 가면 된다.”라는 말이 있기는 하지만, Node.js가 가지는 장점의 본질을 정확히 이야기하지 못하고 “깜도 안되는 내용”을 특징이면 장점이라고 말하면 Node.js 자체가 우스워 보일지도 모를 일이다.

 

비판으로 일관하였으나 그것은 절대 Node.js 자체에 대한 것은 아니며, 오히려 Node.js의 미래에 대해서는 비관적이기 보다는 희망적으로 보인다. 그렇기에 node.js에 대한 잘못된 시각에 대하여 강한 비판을 하게 되는 것 같다.

Hadoop또한 기존의 linux와 유사하게도 다양한 재단(foundation), 회사별 배포판이 존재하며 앞으로 더욱 더 다양한 회사에서 그들만의 배포판을 만들어 내지 않을까 생각된다.
Hadoop이 아파치 소프트웨어 재단에 의해서 만들어진 것이기 때문이기도 하지만, 가장 간단한 배포 version은 아파치 소프트웨어 재단으로 부터 얻을 수 있다. http://hadoop.apache.org/

Hadoop은 크게
1. Hadoop Common
2. HDFS,
3. Hadoop MapReduce

로 구분되어 있으며, 그외 Hadoop과 생태계를 같이 하는 Avro, Cassandra, Chukwa, HBase, Hive, Mahout, Pig, ZooKeeper 들도 개별 download 받아서 설치해 볼 수 있다.

사실 아파치 소프트웨어 재단에서 제공되는 version은  딱히 "배포판"이라고 부르기 보다는 그냥 download 위치 정도라고 보는 편이 맞을듯 하다. 리눅스와 윈도우를 지원한다고는 하지만 리눅스만 production platform으로 인정하고 있고, 윈도우는 cygwin을 추가로 설치해야할 뿐더러 개발용으로만 사용하도록 권고한다.

이에 비해 제대로된 배포판은 클라우데라(cloudera)로 부터 찾을 수 있다. CDH(Cloudera Distribution Hadoop)이라고 하며 https://ccp.cloudera.com/display/SUPPORT/Downloads 로 부터 내용을 확인할 수 있는데, 오늘 확인해본 바로는 CDH 3 update 3까지 나와 있으며, CDH 4 beta가 나와 있는 상태이다.

CDH3 update 3의 installation guide를 확인해 보면 CDH3에 포함되어 있는 component의 내용을 확인할 수 있는 오만 잡다한 걸 다 넣어 두었다.(물론 보는 관점에 따라서 full stack이라는 좋은 말을 사용할 수도 있다.)
무엇이 포함되어 있는지 살펴보면

1. Apach Hadoop Common
2. HDFS
3. MapReduce

4.HBase
5. Oozie
6. ZooKeeper
7. Mahout
8. Flume
9. Sqoop
10 Hue
11. Pig
12. Hive
13. Whirr
14. Snappy

이 포함되어 있다.
installation guide에 문서화 되어 있는 Linux 배포판은, RedHat과 SUSE 정도만 다루어지고 있다.
클라우데라는 이 같은 Linux용 패키지 외에도 KVM, VMWare, VirtualBox 등의 VM용 패키지, 그리고 EC2 등의 Cloud에서의 사용을 위해서 Whirr을 사용할 수도 있다.

비교적 최근에 마이크로소프트 또한 이 대열에 합류하여 MDH(Microsoft Distribution Haddop)이라는 배포판을 만들고 있는데, 곧 정식 배포 Version이 출시될 것으로 보인다. 마이크로소프트가 이처럼 오픈소스 Project에 대한 배포판을 만들었던 적이 있었던가?
마이크로소프트의 document plan들을 살펴보면 이들이 어떠한 작업들을 준비하고 있는지 대략적으로 살펴볼 수가 있는데
(http://social.technet.microsoft.com/wiki/contents/articles/6205.microsoft-hadoop-distribution-documentation-plan.aspx)

상기 문서에 따르면 배포본은 총 3가지의 Target Platform을 위해서 준비되고 있다.

Hadoop Clusters on the Windows Azure platform.

Apache Hadoop cluster provisioned through the Elastic Map Reduce (EMR) Portal, HadoopOnAzure.com .

Hadoop clusters deployed to on-premise hardware.

즉,
1. Azure subscriber를 위해 요청한 만큼의 Computing Resource를 쓸 수 있는 배포판
2. Azure 상에서 구동되기는 하지만 간단한 방법으로 Hadoop을 쓸 수 있도록 해주는 EMR(Elastic MapReduce)
    (http://www.youtube.com/watch?v=uoNupeET8ZE&feature=player_detailpage 동영상 참조)
3. 마지막 Windows 설치 패키지

과연 마이크로소프트의 MDH는 더그커팅이 이끄는 클라우데라의 CDH 만큼의 경쟁력을 가질 수 있을까?

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

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

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 윈도우 폰" 정도로는 절대로 시장에서 성공할 수 없다.