Windows 8 개발 Tip과 강좌 게시판

마이크로소프트 서피스 프로 동영상

코난(김대우) — Fri, 25 Jan 2013 09:44:42 +0900

서피스 프로 동영상이에요.

음... 링크 추가 합니다. http://news.cnet.com/8301-10805_3-57565435-75/microsoft-surface-pro-the-movie/

[다운로드] Windows 8 UX 디자인 가이드 공식 문서 (영문)

코난(김대우) — Tue, 04 Sep 2012 18:01:06 +0900

Windows 8 UX 디자인 가이드 문서 PDF 입니다. (영문)

분량이 상당하네요. 디자인 가이드 문서인 만큼, Windows 8 앱을 개발하는 분들이 참고하시면 좋을 자료가 많습니다.

아울러, 이 문서는 공식 사이트에 등록된 내용입니다. 많은 도움 되시길 바랍니다.

Windows 8 UX 디자인 가이드 문서 PDF 다운로드 : Win8_UXG_RTM.pdf

원문 : Index of UX guidelines for Metro style apps

http://msdn.microsoft.com/en-us/library/windows/apps/hh465424

Windows 8 앱 개발 이야기 - MS 본사 직원과 함께한 Windows 8 QnA

ivoryguard — Sat, 14 Jul 2012 15:17:25 +0900

이번에 Microsoft 본사에서 Windows 8 개발자가 한국에 오면서 한국 개발자와의 미팅 이벤트가 있었는데 Windows 8 멘토 그룹 멤버 자격으로 이 미팅에 참가한 후기를 올려봅니다.

미팅 전에는 실제 Windows 8 개발자와 개발자 대 개발자로 하는 미팅인 줄 알았는데 알고 보니 그런 것은 아니었고 Windows8 개발에 좀더 깊이 관여했던 MS 본사 관계자와의 미팅이었습니다.

하지만 다른 공식적인 홍보 행사나 세미나와는 여러 가지 면에서 큰 차이점이 있었는데, 기술에 대해서 좀더 깊이 알고 영향력 있는 MS 본사 직원이 자세를 낮추고 개발자 및 사용자의 눈높이에 맞춰서 접근하는 시도를 했다는 것입니다.

왜 이렇게 말할 수 있냐면 다음과 같은 이유 때문입니다.

- 참석한 MS 본사 직원은 Christopher Flores (Director of Communications, Windows Client Division)과 Chaitanya Sareen (Principal Program Manager Lead, User Experience PM)이었는데 직함에 Principal이 들어간 직함은 MS 본사에만 있으며 정말로 매우 높고 중요한 직책에 있는 사람들입니다. 그런데 이런 사람들이 아시아 각 나라를 돌면서 사용자와 개발자를 직접 대면하고 있다는 점입니다. 적어도 제가 아는 범위 내에서는 Windows 7의 런칭 때와는 비교할 수 없을 만큼 MS에서 다양한 방식으로 사용자와 의사소통을 시도하려는 노력이 느껴집니다.

- 일방적으로 정보를 전달하는 보통의 행사와는 달리 서로 의견을 주고받고 정확하게 의견을 전달하기 위해서 소수의 사람들만 참가하는 미팅이었습니다. 사실, 한국 개발자와의 미팅 시간에는 저만 참가했으며 마치 커피 한 잔 마시면서 같이 얘기하는 느낌으로 3명이 아주 가까이 모여서 얼굴을 맞대고 이야기를 했습니다. 미팅 전에 왜 소수의 인원만으로 미팅을 진행하냐고 문의했었는데, 너무 많은 사람과 이야기하면 자신들의 의견이 제대로 전달되지 않거나 잘못 전달될 수 있기 때문이라고 하더군요. 개인적으로 이런 스타일의 미팅은 이전에도 몇 번 해본 적이 있는데 정말로 재미있어서 시간 가는 줄을 몰랐습니다.

여하튼, MS 본사 직원 2분과 저 그리고, 통역을 담당하신 교수님 이렇게 4명이 옹기종기 모여 앉아서 1시간 동안 아주 재미있게 다양한 이야기를 나눴습니다. 원래 아젠다에는 Windows 8 기능 소개나 데모와 같은 내용들이 있었는데 Windows 8과 관련된 웬만한 내용은 이미 알고 있는지라 대부분의 시간을 질문 답변과 의견 교환에 할애했습니다.

그러면, 1시간 동안 주고 받은 이야기들에 대해서 쭉 적어보도록 하겠습니다. 주로 제가 질문하고 MS 본사 분들이 이에 대해서 답변하는 형식이었는데 워낙 아무 생각없이 미팅에 참가하기도 했고 정신도 좀 없었던 지라 끝나고 나니 빼먹은 질문도 있고 여러 가지로 아쉬움이 남더군요.

주의사항: 각 질문에 대한 Note에는 매우 주관적인 개인의견이 포함되어 있으므로 적절히 필터링해서 보시기 바랍니다^^

질문: 현재 Windows Store에 올라와 있는 일반적인 Metro Style App 이외에 좀더 멋진 데모들을 보여줄 수 있는지요?

답변:

MS 분들이 사용하고 계신 슬레이트7에도 Windows Releae Preview가 설치되어 있어서 우리가 Windows Store에서 볼 수 있는 것 이상으로 보여줄 것이 없다고 말하다가… 아주 재미있는 데모 하나를 보여줬습니다.

아쉽게도 비공개이기 때문에 이 글에서 상세히 적을 수는 없지만 아주 유명한 게임 엔진이 Windows 8 Metro Style App용으로 포팅되고 있으며 이 엔진을 사용하는 어떤 게임의 데모를 보여줬습니다. 플레이 가능한 상태는 아니고 자동으로 진행되는 데모였는데 그래픽이 대단히 훌륭하고 전혀 끊어짐 없이 매끄러웠습니다. 제가 게임을 꽤 좋아하는지라 워낙 인상 깊은 데모였는데 상세히 적을 수 없는 점이 참으로 안타깝네요.

Note:

Windows 8에서는 이미 DirectX를 이용하여 게임을 개발할 수 있는 환경이 잘 구축되어 있고 OpenXNA를 통해 XNA까지도 사용할 수 있습니다. 여기에 유명 게임 엔진들까지 포팅이 된다면 그야말로 Windows 8은 아이패드를 능가하는 게임 플랫폼으로 자리잡을 확률이 매우 큽니다. Microsoft는 이미 Microsoft Studio라는 매우 훌륭한 게임 개발팀을 가지고 있는데다가 기존 XBOX360 게임 개발사들이 적극적으로 참여하고 다른 플랫폼에서 유명한 게임들까지 포팅이 된다면 우리가 생각하는 것 이상으로 Windows 8 태블릿이 초고속으로 아이패드를 따라잡을 지도 모르겠습니다. 뭐니뭐니해도 게임이 가장 중요한 컨텐츠이니까요^^

Windows 8은 태블릿 뿐만 아니라 일반 데스크탑이나 노트북에서도 사용이 되기 때문에 Windows 8 게임 시장 은 모바일뿐만 아니라 기존 PC게임 시장까지 확장될 수 있습니다. 앞으로 나오는 대부분의 노트북이나 윈도우 태블릿에 Windows8이 기본적으로 설치되어 나온다는 점을 생각한다면 Windows 8 게임 시장은 아마도 이 세상에서 가장 접근성이 높은 게임 통로가 될 것입니다.

질문: Windows 8은 ARM CPU를 지원하는데 그러면 Windows CE의 미래는 어떻게 되는 건가요?

답변:

Windows 8이 ARM CPU를 지원하기는 하지만 Windows CE는 로보틱스나 홈 오토메이션과 같이 매우 작은 기기들에서 계속 사용이 될 것입니다.

Note:

이 질문은 제가 생각하고 있는 것이 맞는지 확인하기 위해서 해본 것입니다. 전통적으로 데스크탑용 Windows OS는 x86만을 지원해왔는데 Windows 8에서부터는 데스크탑 OS에서 아예 ARM CPU까지 지원해버림으로써 Windows 8을 모바일이나 임베디드 영역까지 사용할 수 있을지도 모른다고 생각할 수도 있습니다. 하지만 스마트 폰이나 태블릿은 모바일 기기 치고는 매우 성능이 좋은 기기들이고 거의 몇 년 전 PC 수준의 성능을 보여줍니다. 그러나 스마트 폰보다도 한참 뒤떨어지는 성능의 초소형 임베디드 기기에 사용하기에는 Windows 8은 너무 무겁습니다. 따라서 개인적으로는 당분간 Windows CE(보다 정확히는 Windows Embedded Compact) 계열도 유지가 되지 않을 듯 싶습니다.

여기에서 빼먹은 질문이 하나 있습니다. Windows Embedded에는 ARM CPU 계열의 Windows Embedded Compact가 있고 x86계열의 Windows Embedded Standard 이상이 있습니다. 우리가 자주 접하는 POS나 KIOSK(무인 우편 접수, 승차권 발권기 등)의 상당수는 데스크탑 OS기반의 Windows Embedded Standard를 사용하고 있습니다.(물론 어떤 곳은 그냥 데스크탑 용 Windows XP나 Windows7을 그대로 사용하고 있을지도 모르지만요…) 그렇다면 Window 8도 POS나 KIOSK에 사용될 수 도 있을 텐데 그렇다면 어떤 기술과 언어로 프로그램을 개발해야 할까요?

과연 Metro Style App으로 POS나 KIOSK용 앱을 만들 수 있을까요? 만약 그렇게 되려면 무조건 정해진 Metro Style App 하나만 화면에 실행되어 있어야 하고, 시리얼 통신 및 각종 하드웨어 장치와 통신이 가능해야겠죠. 한 가지 확실한 점은 Windows Store를 통해서 배포되는 일반적인 Metro Style App의 작동 방식이나 보안 정책 등으로는 대응이 어렵기 때문에 OS 기능과 보안 정책의 조정이 필요할 것입니다. 문제는 MS가 이런 것을 허용할 지 말지는 MS 마음이기 때문에 나오기 전에는 알 수가 없습니다.^^

질문: Windows 8 RT가 지원하는 ARM CPU 종류에는 어떤 것들이 있습니까?

답변:

사실, 이 질문은 모종의 목적을 가지고 질문한 것인데 다음과 같은 답변을 들었습니다.

Windows 8 RT는 개인이 직접 설치할 수가 없고 하드웨어에 미리 탑재되어서 나오기 때문에 질문 자체가 의미가 없다. 하지만 이론적으로는 Windows 8은 다양한 ARM CPU에 대응될 수 있다.

Note:

제가 이 질문을 한 목적은 크게 2가지 입니다. 첫째로 안드로이드처럼 초저가 Windows 8 태블릿 기기가 나올 가능성이 있는지와 둘째로 Windows 8 RT가 어디까지 활용될 것인지에 대한 것이죠.

ARM CPU에는 Nvidia Tegra나 퀄컴 스냅드래곤 이외에도 다양한 칩셋들이 있습니다. 그 중에서 중국산 초저가 태블릿에는 보통 락칩이라고 하는 저가형 ARM CPU가 들어가는 경우가 많지요. 안드로이드의 경우에는 다양한 ARM CPU를 사용하는 기기들에 탑재가 되고 있는데 과연 Winows 8 RT도 그렇게 될 수 있는지를 우회적으로 물어보려고 한 것입니다. 물론 기술적으로 Windows 8 RT가 어디까지 지원되는지 궁금하기도 했구요.

하지만, 사실 Windows 8 RT는 안드로이드처럼 중국산 초저가 태블릿에 탑재되지는 않을 듯 합니다. 일단, Windows 8 RT는 DirectX를 지원하는 ARM CPU에서만 사용할 수 있는 것으로 알고 있습니다. 뭐 정확히 말하면 GPU이지만 어차피 ARM CPU들은 전부 SOC 칩셋이니 한몸으로 봐야겠죠. 따라서 최신 ARM CPU에서만 작동할 가능성이 있습니다. 그런데 이런 ARM CPU들은 좀 비싸거든요. 그리고 Windows 8 RT가 탑재되는 태블릿의 성능이나 품질이 어느 정도 이상 되어야만 MS에서 Windows 8 RT를 공급해줄 확률이 큽니다. 그래야 MS가 욕을 안먹으니까요. 따라서 Windows 8 RT는 안드로이드처럼 다양한 기기가 우후죽순 등장하지는 못할지도 모르겠네요. 개발자 입장에서는 파편화가 줄어들어서 좋긴 하겠네요^^

참고로, 제가 작년까지 들은 바로는 Windows 8 RT가 ARM CPU에서 충분한 성능이 안나와서 MS에서 고심중이었다는데 높은 수준의 사용자 경험을 제공하려면 아무래도 최신의 쿼드코어 ARM CPU를 사용하는 기기에만 Windows 8 RT를 공급하는 것이 맞겠지요.

여하튼, 이 사항에 대해서는 좀더 기술적인 의견을 주고받지 못해서 아쉬움이 남습니다.

질문: Windows 8 개발 관련하여 HTML/Javascript 비해 .NET 개발자들에게 소홀하다는 느낌을 받고 있는데 어떻게 생각하시나요?

답변:

지속적으로 다양한 샘플, 강좌, 세미나를 제공하여 .NET 개발자들을 지원하겠습니다.

Note:

매우 원론적인 답변을 들었지만 사실 생각해보면 이 시점에서 별다른 수도 없을 듯 합니다.

현 시점은 기존 .NET 개발자들에게는 매우 큰 도전이라고 할 수 있습니다. 전통적인 데스크탑 환경이 무너지고 모바일 환경이 대세가 되면서 어떻게 해야 할 지 갈팡질팡하고 있다고 할까요? 또한 실버라이트를 비롯한 여러 가지 .NET 기반 기술들이 죽었다고 떠들어대고 있는데다가 Metro Style App이라는 새로운 방식의 클라이언트 프로그램 개발 방식에 적응해야 하기도 합니다. 마치 DOS에서 Windows로 넘어갈 때의 혼란과 비슷한 느낌일 지도 모르겠네요.

(실버라이트 1.1 알파 시절부터 실버라이트로 개발해온 개발자 중 한 명으로서 실버라이트가 죽었다는 말에는 별로 동의하지 않습니다. 실버라이트는 버전 5까지 업데이트되면서 충분히 안정화되었으며 적절한 곳에 잘 사용하면 이보다 더 좋은 도구가 없습니다. 다만 처음에 등장했을 때 MS가 내건 다양한 활용범위가 시대가 바뀜에 따라서 조금 축소된 면이 있을 뿐입니다. 실버라이트가 만능이 아니듯이 HTML5도 만능이 아닙니다.)

세상이 바뀌는 것에 따라 개발자도 따라가야 하는 것은 당연한 것인데 그 과정에 있어서 기존 .NET 개발자들에게 전과 같은 안정감이나 신뢰감을 주지 못하고 있는 듯 합니다. Windows 8에 올인하는 바람에 기존 기술에 대해서 소홀해졌다는 느낌을 주고 있으며, Metro Style App 개발 환경에 있어서도 .NET보다는 HTML5/Javascript쪽에 좀더 많은 노력을 기울이고 있는 듯한 느낌도 주고 있지요. 이런 불안감은 급속도로 팽창하고 있는 iOS 생태계가 MS 진영에 위협을 주고 있다는 점도 한 몫하고 있지 않나 싶습니다.

여하튼, Windows 8이 정식으로 출시되고 Windows 8 대응 기기들이 많이 등장하면 좀 나아지겠죠.

질문: Windows 8의 Metro IE10에서 Adobe Flash 및 AIR 의 지원 예정 및 범위는?

답변:

Windows 8 릴리즈 프리뷰부터 제한적으로 Metro IE10에서 Adobe Flash를 지원하고 있는데 현재는 화이트 리스트 방식으로 Adobe Flash를 지원하는 웹 사이트를 허용하고 있습니다. 즉, 허용된 웹 사이트에서만 Adobe Flash를 지원하고 있으며 정식버전 출시 때까지는 더 이상 이 리스트가 늘어날 것 같지 않습니다. Windows 8 정식 버전이 출시되면 자사 웹사이트 내부의 Adobe Flash가 작동되도록 해달라는 요청이 쇄도할 듯 한데 이에 대해서는 아직 정해진 바가 없습니다. Adobe AIR의 지원과 관련해서는 아는 바가 없습니다.

Note:

처음에는 Windows 8 Metro IE10에서도 어도비 플래시를 지원하지 않는다고 했었는데 갑자기 릴리즈 프리뷰에서 제한적으로 플래시를 지원하는 것으로 방침이 바뀌었습니다. 실제로 Windows 8 릴리즈 프리뷰에서 Metro IE10으로 유튜브 들어가면 플래시로 된 동영상 플레이어가 잘 작동합니다. 하지만 대부분의 웹사이트의 플래시는 작동하지 않습니다. 아마도 매우 큰 동영상 서비스 사이트 등과 같은 웹 사이트에서만 플래시가 지원되지 않을까 싶네요. 그나저나 Windows 8 정식 버전이 릴리즈되면 왜 저 사이트는 플래시가 되고 우리 사이트는 안되냐고 MS에 항의하는 사람들이 엄청 많아질 것 같습니다^^

AIR의 지원 여부는 Adobe Flash 기반으로 크로스 플랫폼 앱을 개발할 수 있느냐의 여부를 결정짓는 이슈인데, 개인적으로는 아마 공식적으로는 지원되지 않을 것 같습니다. 안드로이드의 경우 여러 앱에서 공유되는 Abobe AIR 런타임을 설치할 수 있는데 비해 Metro Style App에서는 보안 정책 상 여러 앱에서 공통으로 사용할 수 있는 런타임 형태로의 설치는 안됩니다. 자기가 필요한 건 자기 안에 있어야 하죠. 기술적으로는 .NET Framework 4.5 Metro Profile 버전의 Adobe AIR 런타임을 만들어서 Metro Style App 안에 통채로 넣어버린다면 작동할 가능성은 있겠지요. (마치 MonoTouch처럼 말이죠) 하지만 과연 Adobe가 이렇게까지 해줄런지는 의문입니다. 게다가 iOS와 안드로이드는 UI가 유사한 점이 많은데 비해 Metro Style App은 다른 두 모바일 환경과 UI나 사용자 경험이 완전히 다르기 때문에 Metro UI답게 앱의 UI를 바꾸지 않으면 Windows Store에 등록할 때 거부당할 겁니다. 즉 Adobe AIR 기반의 크로스 플랫폼이 Metro Style App까지 확장되기는 현실적으로 매우 힘들어 보입니다.

사실, 다양한 모바일 플랫폼에서 작동하는 앱을 만들어야 하는 입장에서 Metro UI는 현실을 좀더 복잡하게 만듭니다. 안드로이드와 iOS 모두를 지원하는 앱을 보면 UI를 거의 동일하게 만든 경우가 많더군요. 이에 비해 Metro UI는 나머지 두 모바일 플랫폼과는 UI나 UX의 철학이 매우 다르기 때문에 게임을 제외한 대부분의 앱을 아마도 UI를 새로 기획해야 할 겁니다. 즉, 단순히 코드를 포팅하는 수준을 넘어서서 UI 설계 자체를 새로 해야 한다는 것이지요. Windows Store에 올라와 있는 Windows 8용 에버노트와 다른 플랫폼의 에버노트 앱을 비교해보시면 금새 이해하실 수 있을 겁니다.

이번에 안드로이드 4.1 젤리빈부터는 Adobe Flash가 지원되지 않는다고 합니다. Adobe에서도 안드로이드 4.0.x까지만 Flash를 지원하고 그 이상부터는 지원하지 않겠다고 선언하기도 했구요. 물론 Adobe AIR는 계속 지원하겠다고 하긴 했지만 MS/구글/애플이 만든 플랫폼을 따라가야 하는 Adobe 입장에서 언제까지 Adobe AIR를 끌고 갈지는 미지수입니다.

질문: Windows Store에서 데스크탑 앱의 등록 범위 및 지원 내역은 어떻게 되나요?

답변:

Windows Store에 데스크탑 앱을 등록할 수 있으며, 이 경우에는 Windows Store에서 결제가 이루어지지 않고 앱 결제 페이지로 이동시켜주는 링크 역할을 합니다. 상세한 내용은 다음 링크를 참고하십시오.

http://blogs.msdn.com/b/windowsstore_ko/archive/2012/06/14/windows-listing.aspx

Note:

Windows Store에는 Metro Style App뿐만 아니라 일반 데스크탑용 앱도 등록할 수 있습니다. Windows 8이 모바일에 국한된 OS가 아니라 범용 데스크탑 OS까지 아우르기 때문에 Windows Store에 데스크탑용 앱이 등록되는 것은 어찌보면 자연스러운 일이며, ISV에 더 많은 기회를 제공해줄 것입니다. 물론, 아무 데스크탑 앱이나 Windows Store에 등록할 수는 없으며 인증 도구를 통해서 검사도 해야 하고 심사도 받아야 합니다.

단, Windows Store는 데스크탑 앱을 노출시키켜주는 역할만 합니다. 예를 들어서 아래 스크린 샷처럼 데스크탑용 압축 프로그램인 WinZip이 Windows Store에 등록되어 있는데, 가격이 표시되어 있지 않습니다. 데스크탑 앱의 설치 파일 역시 Windows Store에 있지 않고 개발사 홈페이지에 있게 됩니다.

Windows Store에서 실제 결제가 이루어지지 않기 때문에 Metro Style App처럼 MS와 수익을 배분하지 않고 개발자가 다 가져간다고 합니다. 그리고, Windows 8에서는 Metro Style App의 앱 내 결제 시 자체적으로 결제 시스템을 만들어서 사용하면 개발사가 수익을 다 가져갑니다. iOS의 경우에는 앱 내 결제에서도 애플과 수익 배분을 해야 하죠. 후발주자인 만큼 Store에서의 수익 배분은 여러 가지 면에서 애플 앱스토어보다 Windows Store가 훨씬 유리합니다.

기타:

Windows 8에는 터치스크린 밖에서 안으로 손가락을 드래그하는 제스처가 정의되어 있는데, 이러한 제스처를 터치스크린이 아니라 노트북의 터치 패드에서도 사용할 수 있더군요. 터치패드에서도 멀티터치 제스처를 사용할 수 있어서 핀치 줌을 비롯한 다양한 멀티터치 제스처를 마치 터치스크린에서 하듯이 사용할 수 있더군요. 삼성 시리즈9 노트북에서 시연해 보였는데 매우 편리하고 유용해 보였고 Windows 8이 슬레이트 타입의 태블릿 기기에서만 유용한 OS가 아니라 일반 노트북에서도 빛을 발할 수 있겠구나 하는 생각이 들게 하는 데모였습니다.

후기…

통역해주시는 교수님이 계시긴 했지만 그래도 영어로 알아들어야 하니 정신도 없었고, 또 날도 어둡고 해서 제정신(?)으로 잘 진행했는지 모르겠습니다. 이것저것 이야기하다 보니 시간이 금새 가서 정말로 궁금한 것들 중 몇 개는 물어보지도 못했네요. 게다가 한국 개발자로는 저 혼자 참가한 거라서 이거 괜히 한국 개발자 얼굴에 먹칠을 한 건 아닌가 싶기도 합니다^^;

여하튼 간에, 이 글이 Windows 8을 이해하는데 약간이나마 도움이 되었으면 하며 이 이벤트의 목적과도 잘 부합될 수 있었으면 합니다.

Windows 8 앱 개발 이야기 - 컨슈머 프리뷰용 .NET 메트로 스타일 앱을 릴리즈 프리뷰 용으로 마이그레이션하기

ivoryguard — Thu, 07 Jun 2012 14:38:03 +0900

마이크로소프트의 말에 따르면 Windows 8 릴리즈 프리뷰 용 앱 개발 시스템을 만들면서 기존 컨슈머 프리뷰용 앱을 정리하고 개선하는 방향으로 작업했기 때문에 기존 컨슈머 프리뷰용 앱을 어렵지 않게 릴리즈 프리뷰 용으로 포팅할 수 있을 거라고 합니다.

아래 링크에서 컨슈머 프리뷰용 앱을 릴리즈 프리뷰 버전으로 마이그레이션하는 방법에 대한 문서가 제공됩니다.

http://go.microsoft.com/fwlink/?LinkID=251943

그런데… 이 문서대로만 해서 바로 된다면 세상 참 편하겠죠? ^^;

실제 작업해보니 문서화되지 않은 세세한 변경 사항들이 꽤 되더군요.

그래서, 이번 글에서는 Windows 8 컨슈머 프리뷰 용으로 개발된 .NET 메트로 스타일 앱을 Windows 8 릴리즈 프리뷰에서 작동되도록 마이그레이션하는 방법에 대해서 이야기해볼까 합니다.

이 글은 남들보다 먼저 앱을 개발하신 분들에게도 도움이 되겠지만 아직 한 번도 만들어보지 않은 분들에게도 .NET 메트로 스타일 앱의 템플릿의 상세 기능을 살펴보는데에도 도움이 될 수도 있습니다.^^

일단 대상이 될 앱이 있어야 한데…. 컨슈머 프리뷰 시절 그나마 가장 설명이 자세했던 Windows Blog RSS Reader 앱을 릴리즈 프리뷰에 맞게 고쳐보도록 합시다.

http://msdn.microsoft.com/ko-kr/library/windows/apps/br211380.aspx

여기서 잠깐

이 글을 쓰는 시점에서 영문 문서는 릴리즈 프리뷰로 업데이트되었는데 한글 문서는 아직 컨슈머 프리뷰 버전으로 되어 있으니 이점 참고하세요.

자 시작해봅시다.

일단, 마이그레이션하기에 앞서서 테스트 삼아서 Visual Studio 2012 RC로 새 프로젝트를 만들어보면 Visual Studio 11 베타와 기본 골격은 크게 다르지 않음을 확인하실 수 있습니다. 예전처럼 Assets 폴더와 Common 폴더가 있으며 프로젝트 루트에 XAML 페이지와 CS 파일들이 위치합니다. 그리고, 프로젝트 파일과 솔루션 파일도 동일하기 때문에 Visual Studio 11 베타로 만들었던 프로젝트를 Visual Studio 2012 RC로 열어도 잘 열립니다. (물론 잘 열리기만 합니다^^;)

여기서 잠깐

지난 포스팅의 Visual Studio 2012 RC 스크린샷과 뭔가 다른 점을 찾으셨다면 당신은 눈썰미가 매우 좋으신 겁니다^^ 기본적으로 상단 메뉴가 전부 대문자로 나오던 것이 이전처럼 소문자로 바꿔버렸습니다.

혹시 여러분도 이렇게 바꾸고 싶으시면 아래 링크에서 레지스트리 파일을 받아서 병합하시면 됩니다.

http://blog.xyzzer.me/2012/06/01/visual-studio-2012-all-caps-vs-old-style/

보통 이렇게 새 버전이 나온 경우 새 버전으로 프로젝트를 다시 생성한 후 우리가 만든 코드를 집어넣는 편이 수고를 줄여주는데 이 글에서는 여러 가지로 공부할 거리가 있게 하기 위해 기존 프로젝트 파일을 바로 열어서 마이그레이션 하도록 하겠습니다. 사실, 프로젝트 다시 구성하는 것도 좀 귀찮기도 하죠^^;

일단 기존 프로젝트를 열어서 컴파일을 해보면…. 에러가 나서 컴파일이 안되는군요. 당연하게도 말이죠…

사실, Visual Studio 2012 RC로 넘어오면서 템플릿이 꽤 바뀌었습니다. 그런데 이 글의 맨 처음에 있는 마이그레이션 가이드 문서에는 그런 내용이 거의 없지요.

어떻게 바뀌었는지 비교를 해보기 위해서 같은 이름으로 새 프로젝트를 만들어봅시다.

그러면, 다음과 같이 Common 폴더가 달라졌음을 보실 수 있습니다.

Visual Studio 11 Beta Visual Studio 2012 RC

위 그림에서 보시는 대로 SuspensionManager.cs 라는 파일이 추가되었습니다. SuspensionManager는 기기가 절전 모드로 들어갔을 때를 처리해주는 클래스입니다.

Visual Studio 2012 RC에서 바뀐 템플릿으로 업데이트를 해주는 편이 미래를 위해서 좋겠죠?

Diff 도구로 변경 사항을 살펴보면 새로 만든 테스트 프로젝트에서 LayoutAwarePage.cs, StandardStyles.xaml, SuspensionManager.cs 파일만 달라졌음을 확인하실 수 있습니다. 따라서 이 3개의 파일을 기존 프로젝트로 복사해주고 프로젝트에 Include 해주세요. 이때, 각 파일을 열어서 맨 윗부분의 네임스페이스를 기존 프로젝트에 맞게 고쳐주셔야 합니다. 만약, 테스트용 프로젝트를 생성하셨을 때 기존 프로젝트와 같은 이름으로 만드셨다면 이 과정은 필요없겠죠.

그런 후 컴파일을 해보면 다음과 같이 UseFilledStateForNarrowWindow 속성을 찾을 수 없다고 알려줍니다. 과감하게 이 속성을 삭제합니다. 사실, SuspensionManager.cs만 추가된 것이 아니라 LayoutAwarePage.cs도 상당히 바뀌었거든요.

오~ 이 속성만 XAML에서 지워버리니 컴파일이 되네요~

우와~ 다 되었나보다~ 하는 마음에 실행을 해보지만…………. 화면에 피드 목록이 나오지를 않네요-.-;

컨슈머 프리뷰 버전에서 잘 돌아가던건데 왜 그럴까요?

바로 LayoutAwarePage의 DefaultViewModel의 처리 방식이 달라졌기 때문입니다.

ItemsPage.xaml.cs 를 보시면 다음과 같이 DefaultViewMode이라는 속성을 이용하고 있습니다.

this.DefaultViewModel["Items"] = _feedDataSource.Feeds;

Visual Studio 2012 RC에서는 LayoutAwarePage의 DefaultViewModel의 처리 방식이 달라져서 XAML에서 명시적으로 DataContext를 지정해줘야 작동합니다.

각 XAML 파일을 열고 맨 윗 부분에 다음과 같이 두 줄을 넣어줍니다. (두번 째 줄은 생략 가능합니다.)

DataContext="{Binding DefaultViewModel, RelativeSource={RelativeSource Self}}"

IsTabStop="false"

사실, Visual Studio 11 베타에서는 LayoutAwarePage의 DefaultViewModel 사용법이 좀 이상했습니다. XAML에서 데이터바인딩을 사용하려면 어디엔가는 DataContext를 지정해줘야 하는데 그런게 안보였거든요. 그러던 것이 Visual Studio 2012 RC 템플릿에서는 좀더 XAML답게 템플릿이 바뀐 것이죠.

이제 앱을 다시 실행해보면 처리되지 않은 오류가 발생했다고 하면서 앱이 죽어버립니다^^;

상세 오류 내용은 다음과 같습니다.

Message = "Cannot find a Resource with the Name/Key ListViewItemOverlayBackgroundBrush [Line: 66 Position: 36]"

ItemsPage.xaml을 연 다음 Error 목록을

보니 다음과 같이 되어 있네요.

이 에러의 원흉은 StandardStyles.xaml입니다. Visual Studio 2012 RC로 넘어오면서 기본 컨트롤들의 모양과 구성이 상당히 바뀌었습니다. 그래서 기존 컨트롤의 디자인을 바꾸기 위해 ControlTemplate을 재정의한 경우에는 이처럼 리소스를 찾을 수 없다는 오류가 무진장 많이 뜹니다.

StandardStyles.xaml을 열어서 직접 살펴보거나 또는 새로 만든 프로젝트를 Blend로 열어서 기존 컨트롤의 ControlTemplate을 샘플로 하나 만들어보면 ListViewItemOverlayBackgroundBrush가 ListViewItemOverlayBackgroundThemeBrush 로 바뀌었음을 아실 수 있습니다. 이처럼 주로 Brush 이름에 Theme가 추가된 경우가 대부분이니 열심히 노가다하셔서 잘 바꿔주시면 됩니다.^^;

참고로 디자인을 많이 뜯어고치셨을 수록 노가다의 고통이 심해집니다. 제가 만든 앱은 디자인을 상당히 바꿨기 때문에 이 작업에 시간이 좀 걸렸네요.

다시 실행해보면 다음과 같이 잘 뜹니다.

그런데, 이번에는 항목을 클릭하자마자 바로 에러가 나네요.

다음과 같이 LayoutAwarePage.cs에서 에러가 나는군요.

이 에러의 원흉은 LayoutAwarePage에서 페이지 네비게이션 처리 방식이 바뀌었기 때문입니다.

Visual Studio 11 베타에서는 다음과 같이 페이지가 네이게이션 될 때 OnNavigatedTo 메서드에서 처리했었는데

protected override async void OnNavigatedTo(NavigationEventArgs e)

Visual Studio 2012 RC의 템플릿에서는 _pageKey에 “Page-1” 과 같은 형식으로 각 페이지마다 내부적으로 키값을 만들어서 사용합니다. 그리고 템플릿으로 생성된 XAML 페이지를 열어보면 OnNavigatedTo 메서드 대신 LoadState 메서드로 처리하고 있음을 보실 수가 있죠.

protected override async void LoadState(Object navigationParameter, Dictionary<String, Object> pageState)

그리고, SaveState라는 메서드도 생겼습니다.

바로 LoadState와 SaveState 메서드를 통해 페이지 네비게이션도 처리하고 절전 모드를 위한 상태 저장/복원 기능도 구현합니다.

따라서, 이 에러는 OnNavigatedTo 메서드를 LoadState로 바꾸면 해결이 됩니다. 물론 그에 맞게 이벤트 핸들러 파라미터 처리도 바꿔줘야겠죠.

예를 들면… SplitPage.xaml.cs는 다음과 같이 수정하면 됩니다.

//protected override void OnNavigatedTo(NavigationEventArgs e) - 기존 코드

protected override void LoadState(Object navigationParameter, Dictionary<String, Object> pageState)

{

//FeedData feedData = e.Parameter as FeedData; - 기존 코드

FeedData feedData = navigationParameter as FeedData;

…

모든 XAML 페이지를 다 수정해주고 실행해보면…

짜잔! 잘 돌아갑니다~

스냅뷰 상태는 수정하지 않아도 잘 돌아가는군요.

생각보다 몇 군데 수정하지 않았는데 Windows 8 릴리즈 프리뷰에서 작동하도록 잘 마이그레이션되었네요.

마지막으로, 스토어에 올리거나 다른 사람에게 배포하기 위해 App Package를 만들어봅니다.

그러면, 다음과 같이 또 에러 메시지가 뜰 겁니다.

이 에러는 현재 프로젝트 파일에 있는 인증용 임시 pfx 파일 (WindowsBlogReader_TemporaryKey.pfx)이 컨슈머 프리뷰에서 만들어져서 그런 겁니다. 같은 이름으로 프로젝트 파일을 만든 후 pfx 파일을 기존 프로젝트에 덮어쓰면 App Package가 잘 생성이 됩니다.

이렇게 해서 간단한 Windows 8 컨슈머 프리뷰용 RSS 리더 앱을 Windows 8 릴리즈 프리뷰로 마이그레이션 해봤습니다.

위 내용만 봐서는 몇 군데 수정안하고 금새 된 것 같죠? 하지만 그건 이 앱이 간단하기 때문입니다. 현실적인 앱에서는 아마 이보다 훨씬 복잡할 겁니다. 하지만 이 글에서 적은 것들과 마이크로소프트의 마이그레이션 가이드를 참고하시면 적어도 새로 만드는 것보다는 훨씬 빨리 마이그레이션 하실 수 있을 겁니다^^

사실, 이 외에도 몇 가지 더 발견한 이슈들이 있긴 합니다.

다음은 제가 발견한 마이그레션 이슈들 중 몇 가지 입니다.

세컨더리 타일을 사용하실 때 컨슈머 프리뷰에서는 다음과 같이 로고 URL을 지정하는데 이 소스를 그대로 돌리면 Argument가 잘못되었다고 에러 메시지가 뜹니다.

var logo = new Uri("ms-resource:Assets/2ndlogo.png");

이 경우 다음과 같이 URL의 형식을 바꿔주면 문제가 해결됩니다. 이런 내용은 마이그레이션 문서에 안나오더군요^^;

Uri logo = new Uri("ms-appx:///Assets/2ndlogo.png");

Frame.GetNavigationState() 메서드를 이용하면 네이게이션 히스토리를 가져올 수 있는데, Visual Studio 2012 RC에서 Frame.Navigte 메서드를 호출할 때 기본 타입이 아닌 객체 타입을 인수로 넘겨주면 Frame.GetNavigationState() 메서드에서 Serializaion 에러가 납니다. 이 문제는 Visual Studio 2012 RC에서 네이게이션 처리 방식이 달라져서 생긴 문제인데 개발자 입장에서 본다면 버그라고 볼 수도 있죠. 무엇보다도 우리가 직접 네비게이션 히스토리 기능을 만들지 않는 이상 Frame.GetNavigationState()가 유일하게 히스토리를 가져올 수 있는 메서드라는 점에서 더욱 문제가 됩니다.

마지막으로, 이 글이 이전에 개발하셨던 앱을 Windows 8 릴리즈 프리뷰 용으로 마이그레이션하는데 도움이 되었으면 하며 컨슈머 프리뷰 버전과 릴리즈 프리뷰 버전의 소스 코드를 첨부합니다.

Windows 8 앱 개발 이야기 - 개발자 입장에서 Windows 8 릴리즈 프리뷰 살펴보기

ivoryguard — Wed, 06 Jun 2012 21:52:53 +0900

Windows 팀의 수장인 시놉스키 부사장이 5월이 일본에 방문했을 때 Windows 8의 새로운 버전이 6월 첫째 주에 릴리즈될 것이라고 말을 했는데… 설마 MS에서 말한 6월 첫째 주가 6월 1일이 될 줄은 생각지도 못했습니다.^^; 보통 6월 첫째 주라고 말하면 6월 첫째 주 금요일 정도로 생각되시지 않나요?^^

여하튼 미국 시간으로 6월 1일에 Windows 8 릴리즈 프리뷰와 Visual Studio 2012 RC도 같이 공개되었습니다. 그래서 이번 글에서는 Windows 8 릴리즈 프리뷰에서 변경된 사항들을 개발자 관점에서 살펴보도록 하겠습니다.

이번에도 프리뷰?

이번에도 역시나 마이크로소프트는 RC라는 이름 대신에 릴리즈 프리뷰라는 명칭을 붙여서 Windows 8의 새로운 버전을 공개했습니다. 이로써 지금까지 개발자 프리뷰 –> 컨슈머 프리뷰 –> 릴리즈 프리뷰 순서로 공개되었네요. 사실 Windows 8 릴리즈 프리뷰는 RC버전이라고 봐도 무방한데 마이크로소프트에서 계속해서 프리뷰라는 단어를 사용하는 이유는 여기에서 더 변할 여지가 있다는 것을 강조하고 싶은 듯 합니다.

개발자에게는 새 Windows 버전보다는 오히려 Visual Studio 새 버전이 더 반갑고 기대가 될 수 있습니다.

이번에 릴리즈 된 Visual Stduio는 Visual Studio 2012 RC로 이름이 변경되었습니다.

따라서, 작년부터 지금까지 Visual Studio의 이름은 다음과 같이 바뀌어왔네요.

- Visual Studio 2011 Developer Preview

- Visual Studio 11 Beta

- Visual Studio 2012 RC

중간에 컨슈머 프리뷰 때만 버전 넘버로 잠깐 갔다가 이번에 다시 연도로 돌아왔습니다. 아마도 Visual Studio 이전 버전들과 이름을 맞추라는 압박이 많이 들어왔나 봅니다.^^

이번 Windows 8 릴리즈 프리뷰는 Windows 8 정식 버전 출시 이전의 마지막 릴리즈이며 아마도 올해 하반기에 Windows 8 정식 버전을 만날 수 있지 않을까 예상해봅니다.

새로운 마음으로 포맷할 준비 되셨나요?

Windows 8 릴리즈 프리뷰에 맞게 메트로 스타일 앱을 개발하기 위해서는 기존 Windows 8 컨슈머 프리뷰를 Windows 8 릴리즈 프리뷰로 업그레이드해야 합니다. 다행히도 포맷하지 않고 Windows 8 컨슈머 프리뷰에서 Windows 8 릴리즈 프리뷰로 업그레이드가 가능합니다.

하지만…. Visual Studio 11 Beta는 어떡하실 건가요? 덩치 큰 Visual Studio 11 Beta 및 각종 개발도구들을 다 언인스톨하고 Visual Studio 2012 RC를 설치하느니 그냥 기존 Windows 8 컨슈머 프리뷰 파티션을 포맷하시고 새로운 마음으로 새 OS와 새 개발도구를 설치하신 편이 정신 건강에 좋으실 겁니다.^^ 물론 그 전에 사용자 데이터 백업은 필수겠죠.

Windows 8 릴리즈 프리뷰 OS와 새 개발도구는 아래 링크에서 다운로드하실 수 있습니다.

http://msdn.microsoft.com/ko-kr/windows/apps/br229516/

Windows 8 릴리즈 프리뷰 공개된 날 바로 3대의 PC에 설치해봤는데 삼성 슬레이트7에서 특성을 좀 타서 약간 고생했던 기억이 있네요. 그래서 제 경험담 몇 가지를 적어봅니다.

- Windows 8 컨슈머 프리뷰에 로그인 된 상태에서 설치할 경우 잘 업그레이드됩니다. 그런데 Windows.old는 수동으로 지우면 잘 안지워지고 디스크 정리로 지우셔야 합니다.

- 삼성 Slate 7의 바이오스 진입 방법은 윈도우 키를 누른 상태에서 전원 키를 누르시면 됩니다.

- 부팅 USB로 설치할 때 검은 화면에 커서만 깜빡이는 경우에는 USB를 FAT32로 포맷한 후 USB를 다시 만들어보세요.

- MSDN 구독자는 OS 언어팩을 다운로드할 수 있는데, Windows 7과 같이 제어판에서 바로 언어팩을 설치할 수 없습니다. Windows 8 릴리즈 프리뷰에서 언어팩을 설치하시려면 콘솔창에서 dism 명령으로 설치하셔야 합니다.

Windows 8 릴리즈 프리뷰 뭐가 달라졌나?

이 글은 일반인 또는 IT 전문가 대상이 아니니 간단하게만 살펴보도록 하겠습니다.

우리가 Windows 8 릴리즈 프리뷰에서 피부로 느낄 수 있는 가장 큰 변화는 한글 지원과 Windows Store가 아닌가 싶습니다. Windows 8 릴리즈 프리뷰에는 한글판 및 한글 언어팩이 제공되어서 한글 윈도우 8을 사용할 수 있게 되었습니다.

새로운 메트로 스타일 앱도 추가가 되었습니다. 위 스크린 샷을 보시면 뉴스, 스포츠, 여행 앱이 보이시죠? 기본 앱인데 매우 쓸만하게 잘 만들었습니다. 특히 스포츠 좋아하시는 분들은 스포츠 앱을 사랑하실지도 모르겠네요. 게다가 우리나라 스포츠 소식도 지원이 됩니다.

여행 앱은 Bing 여행 서비스와 연동되어 전 세계의 다양한 여행지를 소개해줍니다. 특히 파노라마 기능을 통해 유명 여행지의 사진을 360도 회전하면서 볼 수 있는 것이 매력적입니다.

Windows Store에도 국내에서 개발된 앱들도 여러 개가 등록이 되어서 국내 사용자들에게 더욱 친숙하게 다가설 수 있게 되었습니다. 아래 스크린샷에는 없지만 네이버 라인 메신저와 벅스 뮤직 등도 스토어에 등록되어 있습니다.

이 외에도 세부적인 안정성 향상은 기본이며 세세하게 다듬어진 부분이 많습니다.

하지만… 솔직히 말씀드리면 대충 봐서는 영어가 한글로 바뀌었을 뿐 Windows 8 컨슈머 프리뷰에 비해서 눈에 띄게 확 달라진 점은 보이지 않을지도 모릅니다.

하지만… IE10에는 굉장히 중요한 변화가 하나 있습니다. 바로 메트로 IE10의 플래시 지원입니다~!

원래 메트로 IE10에서는 플래시와 같은 브라우저 플러그인은 지원하지 않겠다고 했었는데 워낙 플래시에 대한 요구가 높아서인지 마이크로소프트에서 한발짝 물러난 듯 싶습니다.

그래서 다음과 같이 메트로 IE10에서도 유튜브 동영상이 아주 잘 돌아갑니다. 더군다나 x86에서만 되는 것이 아니라 ARM CPU에서도 그대로 지원된답니다. 정말로 고무적인 일이 아닐 수 없습니다~!

하지만… 아쉽게도 메트로 IE10에서의 플래시 지원은 제한적으로 유튜브와 같이 주요 사이트에서만 된다고 하는군요.

그래서 아래 스크린샷과 같이 우리나라 홈페이지에 들어가있는 플래시는 여전히 x로 나옵니다.

(네이버와 같은 포탈은 자동으로 플래시를 안쓰도록 전환되기 때문에 플래시 안나오는 사이트 찾느라 잠시 고민 좀 했습니다^^;

사실, 메트로 IE10에서 플래시가 지원된다는 사실은 Windows 8 릴리즈 프리뷰가 공개되기 며칠 전에 새어나오긴 했습니다. 원래 Windows 7까지도 어도비 플래시가 OS에 내장되어 있지 않아서 보통 OS 새로 설치하고 IE 열면 플래시 설치하라고 떴었는데 Windows 8 릴리즈 프리뷰에서는 어도비 플래시를 기본으로 내장하고 있다고 하는군요.

그런데.. 왜… 마이크로소프트는 위와 같이 유튜브 같이 유명한 몇몇 사이트를 제외하고는 여전히 우리들의 홈페이지를 구멍뚫린 채로 그냥 놔뒀을까요? 혹시 보안 이슈 때문일까요 아니면 Windows Store 때문일까요? 들리는 소문에 따르면 허가된 웹사이트에서만 플래시를 지원해준다고 하니 혹시 마이크로소프트 본사에 이메일을 보내서 우리 사이트도 넣어달라고 하면 넣어줄 지도 모르겠습니다^^; 어쨌든 원래 되는걸 막아놓은 거니까요^^

이 쯤에서 “음… 플래시가 지원된다면 당연히 실버라이트도 되어야 하는 거 아냐? 게다가 자기네 거자나…”라고 생각하신 분들이 계실 것 같네요. 그런데 아쉽게도 메트로 IE10에서는 실버라이트는 지원되지 않습니다. 실버라이트 개발자 중 한 명으로서 참 아쉬운 일이긴 한데 한 편으로는 MS가 이해가 되기도 하고 한 편으로는 섭섭한 마음이 없을 수가 없네요. 그런데 현재 실버라이트가 다양한 ARM CPU에서 작동하는 버전이 없는데다가 XAML 기반 기술은 메트로 스타일 앱으로 통합해가는 추세이기 때문에 이런 결정을 한 듯 싶습니다. 어쨌든 .NET 개발자 중에서는 실버라이트 개발자가 메트로 스타일 앱에 가장 빨리 적응할 수 있으니 불행 중 다행이라고 해야 하나요?^^

Visual Studio 2012 RC를 살펴봅시다.

이번에는 개발자에게 가장 중요한 Visual Studio 2012 RC에 대해서 살펴보도록 하죠.

Visual Studio 2012 RC부터는 Blend가 하나의 구성 요소로 통합되어서 별도로 설치할 필요 없이 Visual Studio 2012 RC 설치 시 자동으로 설치됩니다. 그러니 Visual Studio 11 베타 때처럼 “블렌드 어디있어?” 하실 필요가 없습니다.

사실, 이제는 Blend와 Visual Studio를 떼놓고 말할 수 없기 때문에 진작에 이렇게 되었어야 했습니다. 이제 개발자에게 Blend는 선택이 아니라 필수입니다~ 필수~

본격적으로 Visual Studio 2012 RC에 대해서 살펴보도록 하지요.

일단, Visual Studio 11 Beta때는 이랬습니다.

이 화면이 Visual Studio 2012 RC에서는 다음과 같이 바뀌었습니다.

전반적인 느낌이 확 바뀌었는데 디자인 적으로는 크게 다음 2가지가 눈에 뜨입니다.

1) 메뉴가 모두 대문자로 바뀌었음

2) 툴바 아이콘이 단색에서 컬러 아이콘으로 바뀌었음

개인적으로 1번은 좀 적응이 안됩니다. Visual Studio 화면 보고 있으면 왠지 어색한 느낌이 계속 들었는데 바로 1번 때문에 그런 거더라구요. 그리고 2번은 대환영입니다. 사실 이전 버전에서는 아이콘이 전부 회색이라서 도대체가 구분이 안되었거든요. 특히 2번은 MVP들의 거센 항의(?)가 주 요인이 되었다고 합니다^^

사실, 개인적으로는 Visual Studio 11 베타나 Visual Studio 2012 RC나 다들 너무 회색조라서 코딩하는 내내 눈이 아른거려서 별로네요. 디자인만 따지면 Visual Studio 2008이나 Visual Studio 2010이 더 익숙하고 좋은데 말이죠….

그럼 기능적으로는 뭐가 바뀌었을까요?

다음 두 링크에서 어느 정도 확인이 가능합니다.

http://blogs.msdn.com/b/windowsappdev/archive/2012/05/31/what-s-changed-for-app-developers-since-the-consumer-preview.aspx

주요 사항 몇 가지를 정리해보겠습니다.

High priority roaming app settings

- 메트로 스타일 앱에서는 앱 설정을 Roaming 방식을 통해서 여러 기기에서 공유하고 동기화할 수 있는데, 이 앱 설정 Roaming이 매우 빨리 되도록 해서 사용자가 다른 기기로 바꿔서 사용하더라도 딜레이 없이 바로 이전 설정을 이어서 사용할 수 있도록 해준답니다.

향상된 Visual Studio 템플릿

- 기존에 제공되었던 템플릿들이 향상되었습니다. 예를 들면 Blank Template은 사용자가 마음대로 커스터마이징할 수 있도록 불필요한 것들을 모두 제거했습니다.

- GridView와 ListView는 기본적으로 Virtualization을 지원하도록 하여 메모리를 적게 사용하면서도 더 빠르게 작동하도록 변경되었습니다.

- 실제로 11 베타 때의 템플릿 소스와 2012 RC의 템플릿 소스를 비교해보면 여러 가지 면에서 개선이 되었는데, 이 점 때문에 컨슈머 프리뷰 버전의 앱을 릴리즈 프리뷰 버전의 앱으로 마이그레이션할 때 여러 가지 문제가 발생합니다. 이 부분은 다음 강좌에서 다루도록 하죠.

- C#/VB에 WinRT 컴포넌트 템플릿이 추가되었습니다.

XAML 앱에서 향상된 View State 디자인 기능

- 실제 메트로 스타일 앱을 개발하다 보면 스냅 상태를 디자인하고 테스트하는 것이 쉽지 않았습니다. 왜냐면 실제 앱을 실행한 후 스냅 상태로 바꿔야 하기 때문이죠. 그래서 스냅 상태를 테스트하려면 사실상 슬레이트7과 같은 실제 기기를 이용하여 리모트 디버깅을 사용해야 그나마 좀 나았는데, 이제는 Visual Studio와 Blend 내에서 바로 미리보기 할 수 있게 되었습니다.

그리고, Enable state recording을 선택하면 현재 선택된 상태에서 변경된 속성값들이 현재 상태 쪽으로 적용이 된다고 하니 각 상태별로 눈으로 직접 확인하면서 보다 쉽게 디자인할 수 있게 되었네요.

Blend에서 HTML 편집 기능 강화

- 이 부분은 직접 써보지 않아서 잘 모르겠지만 다음과 같은 것들이 가능해졌다고 합니다.

CSS 속성과 Style Rule의 잘라내기/복사/붙여넣기가 지원됩니다.
한 번에 여러 개의 엘리먼트에 대한 CSS 속성과 HTML 속성을 편집할 수 있습니다.
어떤 엘리먼트에서라도 컨텍스트 메뉴를 통해 “Create a style rule from element class/id” 와 “Add/Remove class” 를 선택할 수 있습니다.

Javascript App에서 제스쳐 이벤트 모델 개선

- 다중 동시 제스쳐가 지원됩니다. 예를 들면 오디오 이퀼라이저 같은 것을 여러 손가락으로 한 번에 제어할 수 있습니다.

- 어떤 엘리먼트 위에서 제스쳐가 일어났는지 좀더 상세히 알아낼 수 있습니다.

사실 이외에도 우리가 알지 못하는 변경 사항들이 꽤 많겠죠?

Windows 8 릴리즈 프리뷰에서의 변화의 방향

MS 블로그 포스팅 등에 따르면 Windows 8 릴리즈 프리뷰에서는 Breaking Changes를 최대한 줄이는 방향으로 작업했다고 합니다. 즉, API를 완전히 뜯어고치는 것이 아니라 기존 API를 좀더 다듬고 개선하는 방향으로 했다는 것이죠. 실제로 Windows 8 컨슈머 프리뷰 버전에서 개발했던 앱을 릴리즈 프리뷰로 포팅을 해보니 컨슈머 프리뷰를 좀더 정리하는 방향으로 개선되었다는 느낌을 받았습니다.

하지만…. 한 가지 아쉬운 점은 뭐가 어떻게 변경되었는지 상세하게 알려주는 문서가 매우 부족하더군요.

일단, .NET 메트로 스타일 앱에 대해서는 다음 링크에서 어떤 API가 바뀌었고 추가되거나 빠졌는지 한 눈에 보실 수 있습니다.

http://firstfloorsoftware.com/files/DiffLists/WinRT%20Consumer%20Preview-vs-WinRT%20Release%20Preview.html

위 링크에 따르면 추가된 것이 84개, 변경된 된 것이 131개, 없어진 것이 122개라는군요.

이 수치만 보더라도 어떤 방향성을 가지고 Windows 8 컨슈머 프리뷰에서 릴리즈 프리뷰로 바뀌었는지 짐작할 수 있습니다.

그리고, 아마도 부족한 API들은 추후 정식 버전이 릴리즈되고 난 후 실버라이트에서 그랬던 것 처럼 툴킷 형태로 제공되지 않을까 짐작해봅니다.

이제 메트로 스타일 앱 개발에 뛰어들 때가 왔습니다.

컨슈머 프리뷰 시절 간단한 RSS 리더 앱을 하나 만들었었는데, 이 앱을 릴리즈 프리뷰로 마이그레이션 해보니 역시 MS 제품은 베타나 프리뷰 단계에서 개발하면 고생한다는 것을 다시 한 번 체험했습니다^^; 실버라이트 때도 그랬고 Kinect For Windows 에서도 새 버전이 릴리즈될 때마다 API가 바뀌어서 마이그레이션하느라 고생했었는데 이번에 메트로 스타일 앱을 마이그레이션할 때도 문서화되어 있지 않은 세세한 변경 사항들 때문에 생각보다 이것저것 고칠 부분들이 좀 되더군요. 물론 새로 만드는 것보다는 빠릅니다만…..^^;

하지만 어떤 제품이든지 RC 단계에 들어서면 API는 거의 바뀌지 않고 주로 버그 픽스나 성능 개선이 이루어진다는 점을 생각한다면 이제는 실제 윈도우 스토어에 올려서 판매할 앱을 개발해도 되지 않나 싶습니다. 그러니 지금까지 관망하고 계셨던 분들이라면 실제 메트로 스타일 앱 개발에 뛰어드셔도 별 문제가 없을 듯 싶습니다. 게다가 현재 대만에서 진행중인 컴퓨텍스라는 큰 규모의 IT 행사에서 각 업체들이 앞다퉈서 윈도우 8 태블릿 기기를 내놓고 있는 것을 보면 적어도 윈도우 8의 미래가 어둡지 않은 것만은 확실한 듯 합니다.^^

다음 글에서는 제 경험을 바탕으로 컨슈머 프리뷰 버전의 메트로 스타일 앱을 릴리즈 프리뷰 버전으로 마이그레이션하는 방법에 대해서 적어보도록 하겠습니다.

Windows 8 앱 개발 이야기- Hello JavaScript #1: 작동 방식 이해하기

ivoryguard — Sat, 19 May 2012 14:59:48 +0900

지금까지 강좌는 .NET 개발자들을 기준으로 진행해왔는데 (뭐 대부분의 강좌가 사실 언어와는 별 상관없었지만요….^^) Windows 8 앱 개발 이야기를 하면서 자바스크립트에 대해서 이야기하지 않고 넘어갈 수가 없습니다. 그래서 이번 강좌부터는 몇 회에 걸쳐서 자바스크립트로 메트로 스타일 앱을 개발하는 것에 대해서 이야기해볼까 합니다. 참고로 전 자바스크립트는 잘 모르니 이 점 감안해주세요^^;

애초부터 거기에 있었다.

개인적으로는 자바스크립트를 그다지 좋아하지 않습니다. VB/C#과 같은 최신 언어에 비해서 생산성도 많이 떨어지고, 속도도 느리고, IDE 지원도 떨어지고, 무엇보다도 디버깅하기가 쉽지 않은 언어이기 때문입니다. (사실은 실력이 없어서 그렇습니다.)

하지만, 그럼에도 불구하고 자바스크립트에 대해서 개인적으로 한 가지 인정하는 점 하나가 있다면 그 어떤 언어보다도 널리 사용이 되며 개발자의 스펙트럼도 굉장히 넓다는 점입니다. 마치 개발자라면 누구나 기본적인 내용은 알고 있는 교양과목과 같다고 할까요? (그렇다고 자바스크립트가 쉽다는 뜻은 아닙니다.) 사실 프로그램 개발하다 보면 누구나 한 번 쯤은 자바스크립트를 다뤄야 할 일이 생기는 듯 합니다.^^

이와 같은 느낌이 드는 가장 큰 이유는 자바스크립트가 웹 브라우저 안에서 작동하기 때문이 아닌가 싶습니다. 인터넷에 연결되는 거의 모든 기기에는 웹 브라우저가 있으며 웹 만큼 세상에서 널리 퍼진 플랫폼도 없지요. 자바스크립트로 개발한 웹 프로그램은 웹 브라우저만 있다면 플랫폼과 장치를 가리지 않고 작동합니다.(물론 이론적인 이야기입니다.)

그런데, 이런 자바스크립트가 최근 들어서 스마트폰이나 태블릿과 같은 모바일 기기의 등장과 함께 급속도로 인기를 끌고 있습니다. 사실 자바스크립트의 활용 분야는 매우 다양해졌습니다. AJAX의 등장으로 좀더 인터렉티브한 웹 애플리케이션을 만드는데도 사용이 되고 있으며, jQuery Mobile 등을 이용하여 손쉽게 모바일 웹사이트를 만들 수도 있게 해주며, PhoneGap이나 Titanuim과 같은 크로스 플랫폼 개발 도구의 기본 프로그래밍 언어로도 사용이 됩니다.

하지만, 자바스크립트는 넷스케이스 사에서 1995년에 처음 만든 이후부터 이미 우리 곁에 오랫동안 있어온 기술이며 기술로만 따지자면 전혀 새로울 것이 없는 기술입니다. 단지 우리가 새로운 활용처를 발견한 것 뿐이죠. 그리고 좀더 쉽게 사용할 수 있도록 프레임워크화 되어 가고 있는 것입니다.

Objective C나 C#를 배울 필요 없이 우리가 이미 잘 알고 있는 자바스크립트를 이용하여 모바일용 앱을 만들 수 있다는 사실이 멋지지 않나요?^^ 게다가 한 번 만들면 다른 플랫폼에서도 작동하기까지 합니다!

여하튼, 가장 진입장벽이 낮으면서 다양한 모바일 기기를 동시에 지원하는 개발 언어로서 별다른 대안이 없을 만큼 자바스크립트 + HTML5 조합이 대세인 것은 확실합니다.

Microsoft, 자바스크립트에 꽂히다.

데스크탑 OS의 최강자 Microsoft가 모바일 OS 분야에서 전혀 힘을 쓰지 못한지 몇 년이 지난 지금, Microsoft가 모바일 OS 시장 탈환을 위해 들고 나온 무기는 다름 아닌 자바스크립트입니다. 현재 모바일 OS시장에서 제일 중요한 이슈는 누가 얼마나 견고한 생태계를 만드냐는 것입니다. 애플은 선두업체로 iOS 생태계를 이미 견고히 만들어놔서 앞으로도 무너지지 않을 것처럼 보이고, 스마트폰에서 안드로이드의 생태계는 하드웨어 제조사를 기반으로 생각보다 잘 구축되었죠.

그런데, Windows Phone 7은 어떤가요? 솔직히 말씀드려서 VB/C#으로만 개발이 가능하기 때문에 기존 C++ 개발자는 수용을 못하고, 하드웨어 제약이 있어서 안드로이드만큼 하드웨어 제조사에게 환영받지 못하고 있는 것이 사실이죠. 물론 늦게 출발한 것이 제일 큰 이유입니다만…

이런 와중에 Microsoft에게 있어서 데스크탑 OS와 겹치는 부분이 있는 태블릿 시장에서만큼은 절대로 밀려서는 안되는 상황에 이르렀습니다. 그래서, Microsoft는 단 시간 내로 Windows 8의 생태계를 구축하기 위해 기존의 .NET 뿐만 아니라 C++과 자바스크립트까지 모두 끌어안았습니다.

사실, 자바스크립트로 Windows 8용 앱 개발을 할 수 있을 거라는 정보는 이미 2010년 말에 알려졌습니다. 이 소식 때문에 전세계 실버라이트 커뮤니티와 포럼에서 난리가 났죠. 주로 실버라이트의 미래에 대한 걱정이었습니다만…. 제 느낌으로는 이 시점을 기준으로 Microsoft에서 공개하는 정보나 소식들이 HTML5쪽으로 좀더 기울고 있다는 느낌을 주더군요.

실제로, 최근 Windows 8과 관련된 Microsoft의 행보를 보면 오히려 .NET을 역차별하는 듯한 느낌이 들 정도로 HTML5 + 자바스크립트에 집중하는 듯한 모습을 보이고 있습니다. 작년에 마이크로소프트의 국제 컨퍼런스인 //Build//에 참가했을 때도 C# 보다는 자바스크립트 쪽 내용이 훨씬 많았으며, 심지어는 같이 공개된 Blend 5 프리뷰는 XAML은 지원하지 않고 HTML5만 지원하는 .NET 개발자 입장에서 본다면 좀 황당한 상황까지 발생하기도 했습니다. 또한 Windows 8 개발자 프리뷰에 기본 탑재된 앱의 2/3 가까이가 C#/VB가 아닌 자바스크립트로 개발되어 있었습니다. 솔직히, 올해 공개된 블렌드 5 베타에서서도 XAML 디자이너는 허구한날 뻗는데 비해 HTML5쪽은 그럭저럭 쓸만하게 돌아가는 것을 보고 아 MS가 정말로 자바스크립트+HTML5에 올인했구나 하는 느낌을 받았답니다^^;

이처럼, Microsoft는 자바스크립트에 꽂혔다고 말할 수 있을 정도로 Windows 8에서 자바스크립트+HTML5에 대한 지원을 강화하고 있으며, 이는 메트로 스타일 앱과 IE10 모두에서 공통으로 발견할 수 있는 현상입니다. 어쨌든, 메트로 스타일 앱을 자바스크립트로 만들 수 있다는 것은 개발자 입장에서는 매우 환영할 일이며, Windows 8의 생태계를 확장하는데 가장 중요한 역할을 할 것입니다.

자바스크립트와 메트로 스타일 앱에 대해서는 말을 풀자면 한참을 할 수 있지만 이 쯤에서 줄이기로 하고 본격적인 이야기로 들어가기로 하지요.

메트로 스타일 앱에서 자바스크립트가 작동하는 방식

아래 그림은 메트로 스타일 앱 개발과 관련해서 아주 익숙하고 유명한 그림입니다.

이 그림을 잘 보시면 WinRT위에 자바스크립트와 HTML/CSS가 올라가 있군요.

.NET Framework 쪽과 비교하면 다음과 같이 대응이 되겠죠.

XAML <----> HTML/CSS

C#/VB <----> JavaScript

즉 UI의 구조와 모양은 HTML/CSS로 정의하고 로직은 JavaScript로 개발하는 형태를 취하고 있습니다.

그런데, 데스크탑쪽에도 자바스크립트과 HTML이 있네요? 당연하게도 IE상에서도 자바스크립트를 사용할 수 있습니다.

마이크로소프트에서는 메트로 스타일 앱 개발에 사용되는 자바스크립트는 ECMAScript 5 표준을 지킨다고 되어 있습니다.

즉, 표준 자바스크립트 문법을 준수하기 때문에 IE상의 자바스크립트나 메트로 스타일 앱에서 사용하는 자바스크립트나 똑같습니다.

음… 그렇다면 기존 웹 페이지에서 사용하던 자바스크립트 소스를 메트로 스타일 앱 개발 시 그대로 사용할 수 있다는 걸까요?

네 이론적으로는 자바스크립트 표준을 준수하는 소스라면 메트로 스타일 앱에서도 그대로 작동합니다. 단, 보안상 일부 소스는 수정이 필요하긴 합니다만…

와우~ 이것 참 멋진 일이 아닐 수 없네요~!

하지만 세상은 그렇게 호락호락하지 않습니다^^; 이에 대해서는 아마도 여러 강좌에 걸쳐서 차근차근 이야기가 될 것 같네요.

자 그럼 구체적으로 자바스크립트로 만든 메트로 스타일 앱이 어떻게 작동하는지 살펴보도록 하겠습니다.

다음 그림은 IE와 메트로 스타일 앱에서의 자바스크립트 작동 구조를 비교한 것입니다.

IE에서는 우리가 이미 해왔던 것과 똑같이 IE가 HTML 소스와 자바스크립트를 처리하여 화면에 표시합니다.

이에 비해, 메트로 스타일 앱에서는 IE 대신 HTML Host Process라는 녀석이 HTML과 자바스크립트를 처리합니다. 그래서 iexplore.exe 대신 WWAHost.exe라는 프로세스가 실행이 됩니다. 실제로 자바스크립트로 만든 앱을 실행한 다음 프로세스 목록을 보면 다음과 같이 WWAHost.exe를 발견할 수 있습니다. 혹시, 데스크탑에서 HTML Application에 대해서 들어보셨던 분이라면 쉽게 이해하실 수 있을 겁니다.

다음은 자바스크립트 메트로 스타일 앱을 실행될 때 일어나는 일에 대해 설명하는 그림입니다.

자바스크립트 메트로 스타일 앱도 C#/VB로 만든 앱과 동일하게 .Appx 라는 압축 파일에 필요한 파일들이 들어가 있습니다. 단지 C#/VB의 경우에는 .exe 파일이 들어가있는데 비해 자바스크립트 메트로 스타일 앱에는 .html, .css, .js 등이 들어가 있습니다. 마치 웹 페이지 소스를 하나의 압축 파일로 묶은듯한 느낌이네요. 앱이 실행되면 위에서 얘기했던 HTML Host Process가 실행되면서 앱 실행에 필요한 코드들이 App Container로 올라와서 작동합니다.

뭐 대충은 감을 잡을 수 있을 듯 하군요. 웹 페이지 소스를 .Appx에 다 밀어넣어 놓고 IE 대신 HTML Host Process가 이를 처리하는 거라고 봐도 될 듯 싶습니다^^

WinJS란?

위쪽에 있는 IE와 메트로 스타일 앱의 비교 그림을 다시 보시면 매트로 스타일 앱 쪽에는 WinRT가 위치하고 있습니다. 자바스크립트 메트로 스타일 앱에서는 WinRT API를 사용할 수가 있습니다. 이점이 IE 안에서의 자바스크립트와 가장 큰 차이점으로, 자바스크립트 메트로 스타일 앱에서는 WinRT를 통해 로컬 리소스까지 마음대로 활용할 수 있어서 메트로 스타일 앱의 기능 구현에 제약 사항이 없다는 겁니다. 즉, C#/VB로 만드는 것과 완전히 동일하게 메트로 스타일 앱을 만들 수 있다는 거지요. 이 말을 반대로 하면 IE에서는 WinRT API를 사용할 수 없다는 말도 됩니다.

그런데, 자바스크립트 메트로 스타일 앱에서 로컬 리소스를 사용하려면 자바스크립트에서 WinRT API에 접근할 수 있어야 하는데, 어떻게 이것이 가능하게 되는 걸까요?

Microsoft에서는 자바스크립트 메트로 스타일 앱에서 WinRT API를 사용할 수 있도록 하기 위해서 WinJS – Windows Library for JavaScript라는 것을 새롭게 만들었습니다. WinJS는 Metro Style App을 위한 전용 JavaScript 라이브러리로 WinRT와 자바스크립트 사이의 브릿지 역할을 해줍니다. 사실상 자바스크립트로 메트로 스타일 앱을 개발하는 것은 WinJS 라이브러리를 사용하는 것과 같다고 말할 수 있을 만큼 WinJS는 자바스크립트 메트로 스타일 앱 개발과 뗄 수 없는 관계에 있습니다.

PhoneGap이나 티타늄과 같은 크로스 플랫폼 도구를 보면 표준 자바스크립트로는 할 수 없는 기능들 – 예를 들면 센서 사용, 로컬 파일 시스템 접근 등 –을 가능하게 하기 위해 자체적인 자바스크립트 라이브러리를 제공하는데 WinJS는 이런 수준을 훨씬 뛰어 넘어서서 C#/VB + XAML 만큼이나 편리하고 쉽게 자바스크립트로 메트로 스타일 앱을 개발할 수 있도록 통합적인 기능을 제공합니다.

그래서, WinJS에서는 다음과 같이 메트로 스타일 앱 개발 전반에 걸친 다양한 기능을 제공합니다.

위에서 눈여겨봐야 할 몇 가지 사항을 간단하게 설명해보겠습니다.

Promise – 자바스크립트에서 비동기 호출을 쉽게 사용할 수 있게 해주며 C#/VB의 Async Framework에 대응됩니다.

Navigation – 기존 웹 페이지와 달리 Single-page Navigation을 가능하게 해주며 C#/VB의 Navigation Famework과 유사한 기능을 제공합니다.

Data binding – HTML과 CSS를 이용하여 XAML처럼 데이터바인딩을 할 수 있게 하여 코드와 디자인을 분리해줍니다.

Animations – XAML에 있는 키 프레임 애니메이션까지도 가능하게 해줄만큼 강력하고 편리한 애니메이션 기능을 제공합니다.

Controls – 손쉽게 UI를 만들 수 있도록 다양한 컨트롤을 제공하며 GridView나 FlipView와 같은 컬렉션 컨트롤까지 제공해줍니다.

WinJS 기능 중 극히 일부만 설명했는데, 잘 보시면 .NET에서 지원되는 편리한 기능들을 자바스크립트 쪽으로 가져온 듯한 인상을 주는군요. 실제로 자바스크립트 메트로 스타일 앱 샘플을 몇 개 만들어보니 전반적인 개념이나 구조 측면에서 .NET으로 만든 메트로 스타일 앱과 유사한 점을 많이 찾을 수 있었습니다.

몇 가지 이슈들

자바스크립트 메트로 스타일 앱과 관련하여 몇 가지 생각나는 이슈들을 대해서 한 번 살펴보도록 하겠습니다. 참고로 저는 자바스크립트 전문가가 아니며 제가 아는 범위 내에서 매우 주관적으로 적은 내용이니 잘못된 게 있으면 바로 알려주세요^^

자바스크립트 메트로 스타일 앱은 .NET 매트로 스타일 앱이 할 수 있는 모든 것을 할 수 있나요?

이 문제에 대한 대답은 거의 그렇다입니다.

기본적으로 메트로 스타일 앱의 핵심은 WinRT인데 자바스크립트에서도 WinJS를 통해서 WinRT API를 호출할 수 있으므로 사실상 앱을 만드는데 기능제약은 없다고 봐도 무방합니다. 하지만… 제가 아는 범위 내에서 딱 한가지 안되는 점을 찾았습니다. 바로, 자바스크립트로는 WinRT 컴포넌트를 만들 수 없습니다.

다음 그림을 보시죠.

위 그림은 각 프로그래밍 언어 사이의 호출 관계도입니다. 위 그림에 따르면 C++, C#, VB는 WinRT 컴포넌트를 만들 수 있지만 자바스크립트로는 만들 수 없는 걸로 되어있습니다. 즉, 자바스크립트로 WinRT 컴포넌트를 만들어서 C#쪽에서 참조하는 것은 불가능합니다. 물론 그 반대는 가능하죠. 사실 자바스크립트 쪽에서는 바이너리 수준의 컴포넌트라는 개념 자체가 아예 없지요. 자바스크립트에서는 다른 자바스크립트를 소스 레벨에서 Include해서 사용하기 때문입니다. 런데, 이건 딱히 큰 문제라고도 볼 수 없을 수도 없는 것이, 큰 규모의 앱을 만든다거나 또는 여러 언어를 섞어서 앱을 만들면서 컴포넌트를 공유할 때나 발생할 수 있는 문제이기 때문에 현실에서 자바스크립트로 WinRT 컴포넌트를 만들 수 없다는 점이 큰 문제가 될 것 같지는 않으니 걱정하실 필요는 없을 듯 하네요. 만약 여러 언어에 걸쳐서 공통 요소가 필요하면 C++이나 C#/VB로 WinRT 컴포넌트를 만들어서 공유해야겠죠.

기존 자바스크립트 소스를 어디까지 사용할 수 있나요?

이 문제는 아마 현실적으로 가장 중요한 이슈일 듯 합니다. 저도 다 테스트를 해본 것이 아니기 때문에 장담하지는 못하지만 메트로 스타일 앱의 자바스크립트가 ECMAScript 5 표준을 제대로 지키고 있다면 이론적으로는 기존 자바스크립트 소스가 안돌아갈 이유는 없습니다. 예를 들면 이론적으로는 메트로 스타일 앱 개발 시 jQuery도 사용할 수 있을 겁니다. 다만, 현재까지 공개된 Windows 8 컨슈머 프리뷰에서는 IE 엔진에 버그가 약간 있어서 안되는 것들도 가끔 있을 수 있다고도 하네요.

메트로 스타일 앱과 다른 플랫폼 간의 자바스크립트 소스 공유가 얼마나 가능할까요?

이 문제 대한 답은 생각에 따라서 달라질 수 있는데 개인적으로는 UI단 코드는 거의 힘들지 않을까 싶습니다.

만약, 여러분이 만든 프로그램이 페이지가 1개이고 아주 간단한 프로그램이라면 거의 모든 소스를 재활용하여 웹 브라우저에서도 그대로 사용하거나 또는 다른 플랫폼용 앱으로도 만들 수 있을 겁니다. 하지만 Windows Store에 올릴 수 있는 정도의 현실적인 앱에서 자바스크립트 메트로 스타일 앱의 자바스크립트 소스를 다른 플랫폼으로 얼마나 이식할 수 있을지는 장담할 수가 없습니다. 바로 WinJS 때문이죠.

WinJS를 사용하는 순간 다른 플랫폼으로 이식이 매우 힘들어집니다. 왜냐면 다른 플랫폼에는 WinJS가 없기 때문이죠. 심지어는 데스크탑 IE로 옯기는 것도 쉽지 않게 됩니다.

그럼 WinJS를 사용하지 않은 앱이라면 가능한가요? 네 아마도 대부분의 코드를 옮길 수 있으실 겁니다. 예를 들어서 페이지 1개 짜리의 스도쿠 앱을 만들었는데 이 앱을 만들면서 WinJS의 편리한 기능을 하나도 사용하지 않고 오직 일반적인 HTML5의 태그와 자바스크립트만으로 만든다면 가능할 겁니다(물론 하드웨어에 전혀 접근하지 않는 앱에 한해서입니다). 하지만 각 플랫폼마다 사용자 경험이 다르기 때문에 어떤 플랫폼의 앱을 그대로 다른 플랫폼으로 옮기게 되면 어색해질 확률이 높습니다. (단, 보통 게임들은 자체적인 사용자 경험을 가지고 있기 때문에 이 문제에서 좀더 자유롭습니다.)

예를 들면, iOS에서는 커버플로우 UI가 흔하지만 메트로 UI에서는 보통 커버플로우 UI를 사용하지 않습니다. Microsoft의 메트로 UI 디자인 가이드에서도 다른 플랫폼의 앱을 포팅할 때 커버플로우나 책장 넘어가는 효과를 그대로 포팅하는 우를 범하지 말라고 써있더군요.

이처럼, 각 플랫폼마다 사용자 경험이 다르기 때문에 UI도 달라져야 합니다. 특히 iOS와 안드로이드는 좀 유사한 면이 있지만 메트로 UI는 다른 플랫폼과 사용자 경험이 많이 다르기 때문에 대부분의 경우 UI를 그대로 사용할 수가 없습니다.

즉, 메트로 스타일 앱은 매트로 UI답게 만들어야 한다는 것입니다. 그러기 위해서는 WinJS를 사용하는 것이 가장 효과적이겠죠. 그런데 WinJS를 사용하면 다른 플랫폼으로의 이식이 힘들어집니다. 그리고 매트로 스타일 앱에서 하드웨어 리소스에 접근하는 것은 WinJS를 이용해서만 가능합니다.(HTML5 표준 태그에서 지원되는 GeoLocation등은 제외)

그럼 우리가 해야 할 일은 뭘까요? 최대한 UI와 로직을 분리하여 재사용할 수 있는 블럭의 양을 늘리는 것이겠죠. 다행히 WinJS는 디자인과 코드를 쉽게 분리할 수 있도록 여러가지 기능을 제공하기 때문에 이를 잘 사용하시면 자바스크립트에서도 디자인과 코드를 최대한 분리할 수가 있습니다.

하지만, 뭐 꼭 안될 것도 없는 것이 모든 플랫폼에서 공통으로 사용할 수 있는 자바스크립트 프레임웍이 나오지 않을거라는 보장은 없으니까요^^ 실제로 jQuery쪽에서는 Metro UI용 테마도 만들고 있다는 소식도 들리고 있네요.

어쨌든, 그럼에도 불구하고 다른 언어들에 비해서 자바스크립트가 제일 이식성이 높다는 점은 부인할 수 없을 듯 합니다. 기존 자바스크립트 소스를 C#이나 Objective C로 포팅하는 것보다 해당 플랫폼에 맞게 자바스크립트 소스를 수정하는 것이 더 빠를테니까요^^

오늘은 자바스크립트로 메트로 스타일 앱을 개발하는데 있어 필요한 사전 지식들에 대해서 설명했습니다. 다음 강좌에서는 실제 자바스크립트로 메트로 스타일 앱을 개발하는 것에 대한 이야기를 해보도록 하겠습니다.

Windows 8 컨슈머 프리뷰 소개 영상입니다.

코난(김대우) — Sat, 28 Apr 2012 10:52:37 +0900

Windows 8 컨슈머 프리뷰 소개 영상입니다.

기본적인 Windows 8 의 기능과 동작에 대해서 살펴 보실 수 있으니 많은 도움 되시길 바랍니다.

감사합니다.

Windows 8 메트로 UI를 마우스와 키보드로 제어하는 소개 영상

코난(김대우) — Wed, 04 Apr 2012 15:18:03 +0900

Windows 8은 태블릿 뿐만 아니라, 키보드와 마우스를 사용하는 데스크톱 환경에서도 충분히 제어 가능합니다.

기억할 것은 "화면의 코너"

특히, 앱을 개발하기 원하는 개발자 분들에게도 많은 도움 되시면 좋겠습니다.

Windows 8 메트로 스타일 UI에 대하여 소개하는 영상

코난(김대우) — Wed, 04 Apr 2012 15:04:08 +0900

Silverlight 플레이어가 설치되지 않았거나, 최신 버전의 Silverlight이 필요합니다.

메트로 스타일 UI란 무엇인가.

메트로 스타일에 대해 소개하는 동영상입니다. - 영어로 되어 있지만, 쭉 보시면서 참고하시면 좋을 듯.

링크 : http://msdn.microsoft.com/en-us/library/windows/apps/hh464920

Windows 8 앱 개발 이야기 - 메트로 스타일 앱의 패키징과 배포

ivoryguard — Mon, 26 Mar 2012 08:11:12 +0900

이번 글에서는 우리가 개발한 메트로 스타일 앱을 어떻게 패키징하고 배포하는지 살펴보도록 합니다.

메트로 스타일 앱의 배포 방식의 이해

윈도우 응용 프로그램의 경우 보통 .exe나 .msi와 같은 설치 파일로 패키징해서 배포합니다. 사실 윈도우 응용 프로그램의 배포는 단순히 파일만 복사해주면 되는 것이 아니라 ActiveX 컴포넌트를 레지스트리 등록하고, 시작 메뉴 등록하고 각종 세팅 등을 해주고, 거기에 설치 가능 여부 확인 및 조건부 설치 등 매우 복잡합니다. 그래서 Install Shield와 같은 전문 설치 파일 생성 프로그램에서는 다양한 배포 옵션을 제어하기 위해서 전용 스크립팅 기능까지 제공하는 것이 일반적이죠. 뭐 간단한 .NET Framework 윈도우 응용 프로그램은 XCOPY 배포도 가능합니다만…

이에 비해 모바일 기기용 앱들은 보통 배포에 필요한 파일들을 하나의 파일로 압축해서 배포하는 경우가 많습니다.

예를 들면, 안드로이드는 *.apk, Windows Phone 7은 *.xap 파일 형식으로 모든 파일을 압축해서 배포하게 되지요.

여기서 잠깐

*.apk와 *.xap 파일 모두 ZIP 형식으로 압축되어 있기 때문에 기존 압축 유틸리티로 압축을 풀어서 안의 내용을 볼 수 있습니다.

메트로 스타일 앱도 이와 비슷하게 배포에 필요한 모든 파일을 *.appx라는 파일로 묶어서 배포하게 됩니다. 물론 *.appx 파일 역시 ZIP 압축 형식입니다.^^

예를 들면 HelloWorld 앱의 .appx 파일을 압축 프로그램으로 열어보면 다음과 같이 표시됩니다.

메트로 스타일 앱에는 .appx 이외에 .appxupload 라는 파일 형식도 있습니다. *.appxupload은 Windows Store에 등록하는데 사용되는 파일로 프로그램 파일인 *.appx와 다른 필요한 파일들을 다시 압축한 파일입니다.

따라서, 메트로 스타일 앱의 배포 과정을 그림으로 표현하면 다음과 같이 됩니다.

실질적으로는 앱을 등록하는 방법에는 크게 2가지가 있습니다.

Visual Studio 11에는 현재 열린 프로젝트를 바로 Windows Store에 업로드해주는 기능이 있습니다.
Microsoft 의 메트로 스타일 앱 등록 사이트에 로그인해서 별도로 만들어놓은 .appxupload 파일을 등록합니다.

Package Manifest 설정하기

모바일용 앱을 설치할 때 보면 이 앱이 어떤 권한들을 사용하는지 표시해준 다음 설치하게 합니다. 일반적으로 모바일 기기에서는 각 앱이 사용할 수 있는 권한을 제한하고 어떠한 권한들을 사용하는지 사용자에게 확인을 받게 함으로써 보안성을 높이고 있습니다. 예를 들어서, 어떤 앱이 사용자 몰래 GPS를 켜서 사용자의 이동 경로를 몰래 수집할 수도 있겠죠. 그래서 GPS를 사용하는 앱은 설치 시 또는 실행 시 이 프로그램이 위치 정보를 사용한다는 것을 사용자에게 알려주도록 되어 있습니다.

메트로 스타일 앱에도 마찬가지로 각 기능의 사용 여부를 지정하는 옵션이 있는데, 바로 Package Manifest에서 이러한 옵션을 설정하게 됩니다. 참고로, 배포를 위한 패키지 생성에 앞서서 반드시 Package Manifest를 먼저 설정해야 합니다.

Visual Studio의 Solution Explore에서 Package.appxmanifest를 더블클릭하면 다음과 같은 창이 뜹니다.

Application UI에서는 프로그램의 표시 이름, 설명, 초기 레이아웃, 로고, 스플래시 이미지 등 프로그램의 정보와 모양을 지정할 수 있습니다.

Capabilities 탭을 보시면 각 기능의 허용 여부를 지정할 수 있습니다. 예를 들어서 이 프로그램 인터넷에서 정보를 가져오는 RSS 리더라면 반드시 “Internet (Client)” 를 체크해야만 서버에서 RSS 피드를 읽어올 수 있습니다. 이 외에도 위치 정보, 웹 캠, 외장 저장소 등이 접근 권한도 지정할 수 있지요.

이처럼, 개발하는 앱이 사용하는 기능에 따라서 Capabilities를 설정해줘야 앱이 해당 기능을 사용할 수 있습니다. 한 가지 재미있는 것은 “Enterprise Authentication”인데, Active Directory를 사용하는 엔터프라이즈 인트라넷 환경에서 도메인 크레덴셜을 사용하여 인트라넷 리소스에 접근할 수 있는 권한도 설정이 가능합니다. 이러한 옵션은 다른 모바일 앱에는 없는 옵션으로 기존 윈도우 환경을 배려하고 있네요.

Declarations 탭에서는 현재 앱의 추가적인 속성을 정의합니다.

예를 들면, 다음과 같이 파일을 여러 때 이 앱이 지원하는 파일 형식을 지정할 수가 있습니다.

마지막으로 Packaging 탭에서는 패키지 생성과 관련된 속성을 지정합니다. 여기에 설정되는 값들은 대부분이 Windows Store를 위한 것들이죠.

Visual Studio로 배포 패키지 생성하기

이제 배포를 위한 Package Manifest 설정이 끝났으면 실제 패키지를 만들어봅시다.

Visual Studio의 Project 메뉴 –> Store 메뉴를 보시면 패키징 및 배포와 관련된 메뉴들을 찾을 수 있습니다.

하나씩 살펴보도록 하죠.

Open Developer Account
개발자 계정 페이지를 엽니다. 아쉽게도 현재는 아래 나라의 개발자만 접근이 가능합니다.
근데, 제가 알기로는 Windows 8 컨슈머 프리뷰에서는 이 나라들의 개발자라고 하더라도 허가된 일부 개발자들만 앱을 올릴 수 있는 것으로 알고 있습니다.(확인 필요) 애플의 앱스토어에 앱을 올리려면 개발자 등록을 해야 하는데, 이와 비슷하다고 생각하시면 됩니다.

Reserve App Name
자기가 스토어에 올릴 프로그램 이름을 예약하는 기능입니다. 이 기능 역시 한국에서는 아직 안됩니다.
예를 들어서 어떤 개발자가 “My Hello World”라는 앱을 개발할 계획을 가지고 있을 때 남들이 이 이름을 먼저 사용하지 못하게 미리 확보할 수 있다는 것이죠. 참고로, 앱 이름 예약의 유효기간은 12개월이며 이 기간 내에 앱을 등록하지 않으면 만료됩니다.

Edit App Manifest
현재 프로젝트의 Package Manifest를 편집합니다. 위에서 이미 설명했죠.

Associate App With the Store
이 기능 역시 우리는 아직 사용할 수가 없습니다. 설명에 따르면 Developer Windows Live ID로 로그인 한 다음 Store쪽의 정보와 현재 프로젝트의 앱을 연결하여 결제 및 알림 시나리오를 테스트할 수 있도록 해준다고 하는군요.

Capture Screenshots

앱의 화면을 캡쳐해주는 기능인데 사실은 그냥 시뮬레이터를 실행해줄 뿐입니다. 시뮬레이터에 있는 Capture Screen 버튼을 누르는 것은 우리 몫이죠^^

Create App Package
현재 프로젝트를 실제로 패키징 해주는 메뉴입니다.

Create App Package 메뉴를 클릭하면 다음과 같은 창이 뜹니다.

첫번 째 옵션은 Developer Windows Live ID가 필요하므로 아직 사용할 수가 없습니다.

두번 째 옵션을 선택하면 Windows Store를 거치지 않고 로컬에서 테스트할 수 있는 패키지를 생성해줍니다. 현재로서는 이 기능만 사용이 가능합니다.

“Create a package to use locally only”를 선택한 후 Next를 누르면 다음과 같은 화면이 나옵니다. 이 화면에서는 로컬 테스트용 패키지를 생성할 때의 옵션을 지정할 수 있습니다.

각 플랫폼 별로 Configuration을 선택할 수 있으며, 맨 아래에 있는 옵션을 선택하면 앱이 다운되었을 때 분석하는데 도움을 주는 Public Symbol 파일(*.appxsym)을 생성해줍니다. 대부분의 경우 기본값을 사용하면 되겠지요.

Create 버튼을 클릭하면 다음과 같이 패키지가 잘 생성되었다고 알려줍니다.

화면에 있는 생성 경로를 마우스로 클릭하면 생성된 패키지 폴더가 열립니다.

생성된 폴더를 열어보니 다음과 같이 파일과 폴더가 생성되어 있군요.

생성된 파일들을 하나씩 살펴보도록 합시다.

Create App Package 메뉴에서 자동으로 버전 증가 옵션을 체크하면 위 스크린샷과 같이 패키지를 만들 때마다 버전이 올라가면서 각 버전별로 파일과 폴더가 생성이 됩니다. 그리고, 잘 보시면 각 버전마다 “앱이름.appxupload”와 “앱 이름” 폴더가 생성되어 있습니다.

첫 부분에서 말씀 드렸듯이 .appxupload는 Windows Store용 등록 파일입니다. 이 파일을 “Uplaod App Package” 메뉴를 통해 Windows Store에 올리는 것이죠.

.appxupload 파일을 압축 프로그램으로 열어보면 다음과 같이 실제 앱이 들어있는 .appx 파일과 디버깅용 심볼 테이블 정보를 담고 있는 .appxsym이 들어있음을 보실 수 있습니다.

이번에는 생성된 폴더 쪽을 보도록 하죠.

각 파일에 대한 설명은 다음과 같습니다.

Add-AppxDevPackage.bat – 개발용 머신에 설치하기 위한 배치 파일, 해당 머신에 Developer License 필요
HelloWorld_1.0.0.9_AnyCPU_Debug.appx – 실행에 필요한 파일이 ZIP 형식으로 압축된 파일
HelloWorld_1.0.0.9_AnyCPU_Debug.appxsym – 디버깅용 심볼 파일
HelloWorld_1.0.0.9_AnyCPU_Debug.cer – 보안 인증 파일

Add-AppxDevPackage.bat 는 개발용 로컬 머신에 설치하기 위한 배치 파일로 Windows Store를 거치지 않고 로컬에서 바로 앱을 설치할 수 있게 해줍니다. 그냥 더블클릭하면 다음과 같이 관리자 권한으로 실행하라고 친절히 알려줍니다.^^;

그렇다고 자기 PC에서 바로 관리자 권한으로 실행하면 오류가 나는데, 이미 자기 PC에서는 Visual Studio에서 빌드하면서 앱이 등록이 되어 있기 때문입니다. 따라서 테스트할 다른 머신에 생성된 폴더를 통째로 복사한 다음 Add-AppxDevPackage.bat 를 관리자 권한으로 실행해야 합니다.

앞 부분에서 .appx에 실제 앱 파일들이 포함되어 있다고 했는데, HelloWorld_1.0.0.9_AnyCPU_Debug.appx 를 압축 프로그램으로 열어보면 다음과 같이 exe 파일을 비롯한 여러 개의 파일이 안에 들어있습니다.

여기서 잠깐

앱을 개발하다 보면 이미지와 같은 외부 리소스를 사용하는 경우가 많습니다.

예를 들면, 아래와 같이 accept.png를 프로젝트에 등록하면 기본적으로 Build Action이 Content로 됩니다.

이렇게 Content로 등록된 파일들은 빌드시 debug/release 폴더에 복사가 되며 .appx로 패키징할 때도 같이 포함이 됩니다. 다음 스크린 샷을 보시면 .appx에 포함되어 있음을 확인하실 수가 있습니다.

좀 장황하게 설명했는데, 정리하면 다음과 같습니다.

1) Visual Studio의 Sotre->Create App Package 메뉴 클릭

2) “Create a package to use locally only”를 선택하여 로컬 테스트용 패키지 생성

3) 생성된 폴더를 테스트할 머신으로 복사 후 Add-AppxDevPackage.bat를 관리자 권한으로 실행

생각보다 간단하죠?

그런데, 이렇게 보니 마치 안드로이드에서 APK 파일만 복사해서 설치하는 되는 것처럼 Windows Store를 거치지 않고 마구마구 배포되는 거 아닌가 싶은 생각이 드는군요. MS가 바보가 아닌 이상 이렇게 둘 리가 없겠죠? 그래서 Developer License라는 기능이 있습니다.

Developer License에 대하여…

로컬 테스트용 패키지는 Windows Store를 거치지 않고 배포할 수 있는 대신 배포하는 머신에는 반드시 Delveoper License가 있어야 합니다.

Developer License라고 하니 좀 거창해 보이면서 추가 비용이 들 것 같은 느낌을 주는데, 공짜이며 우리가 원하는 만큼 마음대로 발급할 수 있습니다. 심지어는 Windows Store 등록을 위한 계정도 없어도 됩니다.

Developer License 발급받기

관리자 권한으로 커맨드 창을 실행한 다음 “powershell”을 입력하여 PowerShell을 실행합니다.

Show-WindowsDeveloperLicenseRegistration 를 입력하면 다음과 같이 “동의” 창이 뜹니다.

“I Agree”를 클릭하면 로그인 계정의 비밀 번호를 물어본 다음 잠시 기다리면 다음과 같이 라이센스가 발급되었다고 나옵니다.

간단하죠?

Developer License 관련하여 다음과 같은 명령도 사용할 수 있습니다.

Get-WindowsDeveloperLicense : 현재 머신의 Developer License 정보를 표시합니다.
Unregister-WindowsDeveloperLicense : 현재 머신의 Developer License를 제거합니다.

그런데 위 스크린샷의 내용을 보니 발급한지 31일 후에 만료되는 것으로 나오네요?

네 맞습니다. Developer License는 머신 단위로 생성이 되며 발급 후 31일이 지나면 만료됩니다….. 엥?

그럼 딸랑 한 달밖에 못쓴다는 건가요?

걱정마세요! Developer License는 계속해서 갱신할 수 있습니다.^^

한 달이 지난 후에 위에서 설명한 것처럼 다시 발급받으면 됩니다.

참고로, Visual Studio 11을 실행할 때 Developer License가 없거나 만료되었으면 자동으로 안내 창이 뜨면서 갱신이 되니 Developer License의 유효기간이 31일이라고 해서 개발에 문제가 되지는 않습니다.

여기서 잠깐

리모트 디버깅을 위해 다른 머신에 리모트 디버거를 설치하면 기본적으로 Developer License가 생성이 됩니다. 이 역시 유효기간은 31일이므로 Developer License가 만료되면 PowerShell을 이용하여 갱신해야 합니다.

Developer License와 보안

Developer License는 머신 단위로 발급이 되며 발급 될 때 Microsoft 의 서버와 통신하게 됩니다. 또한 Microsoft에서 발급된 Developer License를 모니터링할 수 있다고 합니다. 만약 계약 사항을 위반하여 사용하는 사례가 발견되면 해당 Developer License가 취소될 수 있다고 하는군요.

또한, Developer License가 설치되어 있는 머신에는 우리가 만든 앱 뿐만 아니라 다른 사람이 만든 앱도 Windows Store를 거치지 않고 설치될 수 있기 때문에 아무래도 보안의 위협이 생길 수가 있습니다.

이러한 이유들로 인해 Developer License는 꼭 테스트가 필요한 머신에서만 발급하실 것을 권장합니다.

Windows App Cert Kit 사용하기

개발한 앱을 Windwos Store에 올리게 되면 심사를 받게 되는데, Windowns App Cert Kit을 이용하면 우리가 만든 앱의 기본적인 기능을 미리 테스트하여 심사 전에 문제점을 미리 발견할 수 있도록 도와줍니다.

Windowns App Cert Kit은 다음과 같은 사항들을 자동으로 테스트하고 결과를 알려줍니다.

Package Manifest가 다음 요구 조건을 만족하는지 테스트함
- Number of tiles
- Number of apps per package
- App type
- ResourceID not listed
- OSVersionHighestTested
메트로 스타일 앱에서 지원하지 않는 API를 사용하는지 테스트함
앱이 얼마나 빨리 실행되고 대기 상태로 들어가는지 테스트함
Manifest에 정의된 언어에 대한 언어 리소스가 잘 포함되어 있는지 테스트함
보안에 문제가 있는지 테스트함
앱이 다운되거나 멈춰버리는 지 모니터링함

Windowns App Cert Kit를 실행하면 다음과 같은 창이 뜹니다.

잠시 기다리면 현재 머신에 설치되어 있는 앱의 목록이 표시됩니다.

목록에서 우리가 만든 앱을 선택한 후 Next를 클릭합니다.

그러면, 다음과 같이 검사를 진행합니다. 이 때 테스트를 하는 동안 앱을 사용하지 말라고 하는군요.

실제로, 테스트 도중에 앱이 자동으로 실행되는 것을 보실 수가 있습니다.

주의사항!: 절대로 가만 놔두셔야 합니다. 안 그러면 제대로 테스트가 수행되지 못해서 무진장 오래 걸리거나 실패합니다.

한참을 기다리면 XML된 리포트을 어디에 저장하겠느냐고 물어봅니다.

저장한 XML 리포트를 열어보면 다음과 같이 테스트 결과를 보여줍니다.

왜 실패했나 봤더니 다음과 같이 디버그 모드로 컴파일되어 있다고 알려주는군요.

사실, 이 외에도 실패한 테스트가 몇 개 더 있는데, 그 부분은 아직 구현을 안해서 그런 겁니다.

여기서 잠깐

Windowns App Cert Kit은 다음과 같이 커맨드라인으로도 실행할 수 있습니다.

appcert.exe reset
appcert.exe test -apptype metrostyle -packagefullname [package full name] -reportoutputpath [report file name]

여기서, appcert.exe는 기본적으로 C:\Program Files\Windows Kits\8.0\App Certification Kit 폴더에 위치합니다.

Windows 8 정식 버전을 기다리며…

이 글에서는 메트로 스타일 앱의 패키징 방법과 다른 머신에 로컬로 배포하는 방법에 대해서 살펴봤습니다. 그리고 패키징과 배포 시 생성되는 파일들의 내부도 들여다봤습니다.

아직 한국에서 Windows Store에 앱을 등록할 수 없어서 실제로 Windows Store에 등록하는 과정은 보여드리지 못한 점이 아쉽습니다. 나중에 Windows 8 정식 버전이 나오면 실제로 Windows Store에 앱을 등록하는 과정에 대한 내용도 올리도록 하겠습니다.

Windows 8 앱 개발 이야기 - Hello World로 살펴보는 앱 개발 개요 #2: 리모트 디버깅과 터치 기반 개발 환경 구축

ivoryguard — Sat, 17 Mar 2012 13:20:18 +0900

지난 글에서는 간단한 Hello World 메트로 스타일 앱을 만들어보면서 대략적인 느낌을 살펴봤습니다.

이번 글에서는 실제 개발환경 구축과 관련된 몇 가지 이야기를 해보도록 하죠.

리모트 디버깅이 필요한 이유

사실, 리모트 디버깅이라는 것은 예전부터 있었던 기술입니다. 윈도우 응용 프로그램을 개발할 때, 개발자 PC에서는 잘 돌아가던 프로그램이 사용자 PC에서는 잘 돌아가지 않는 경우가 허다했었죠. 그래서 “윈도우 응용 프로그램은 배포가 반이다”라는 말도 있었으니까요^^

여하튼, 리모트 디버깅이라는 것은 다른 기계에서 작동하는 프로그램을 개발자 쪽 PC에서 디버깅할 수 있게 해주는 기능입니다. 개발자 PC의 환경과 사용자 PC쪽의 환경이 서로 다르기 때문에 실제 사용자 PC쪽에서 프로그램을 돌리면서 디버깅함으로써 버그의 원인을 찾기 쉽게 해줍니다.

그런데, 스마트폰이나 태블릿과 같은 모바일 기기에서의 리모트 디버깅은 또다른 중요한 목적이 있습니다. 바로 폼 팩터의 차이로 인해 발생하는 사용자 경험의 차이입니다. 보통 모바일 기기는 PC에 비해서 화면이 작고 손으로 들고 사용하며 터치로 입력을 하게 됩니다. 따라서 개발자의 로컬 머신에서 실행하는 것과 실제 기계에서 사용하는 것은 화면 크기/입력 방식/사용 패턴 등 많은 부분이 차이가 납니다. 예를 들면, 24인치 모니터에 키보드/마우스가 연결되어 있는 개발자 PC에서 앱을 실행하는 것과 10.1인치 태블릿에서 앱을 실행하는 경우를 비교해본다면 같은 프로그램이지만 느낌은 완전 다릅니다.

따라서, Windows 8 메트로 스타일 앱을 개발할 때는 개발자 PC가 아닌 실제 기계에서 테스트를 하는 것이 매우 중요합니다. 그래서 기존 윈도우 응용 프로그램을 개발할 때는 리모트 디버깅이 옵션사항이었다면 메트로 스타일 앱을 개발할 때는 필수 사항이 됩니다. 참고로, 시뮬레이터를 이용하면 실제 기기에서 작동하는 것과 비슷하게 돌려볼 수 있지만 절대로 실제 기계의 느낌을 그대로 전달받을 수 없습니다. 그래서 터치 기반의 앱을 개발할 때는 터치가 되는 기기가 필수입니다. (Windows 8 뿐만 아니라 Windows 7에서도 마찬가지입니다.) 그 덕분에 제 주위에는 도대체 터치 장비가 몇 개나 되는지 모르겠습니다^^;

여기서 잠깐

iOS나 안드로이드 개발의 경우에는 타겟 기기 자체가 모바일 기기이므로 보통 에뮬레이터를 사용하거나 아니면 실제 기계를 개발 PC에 연결해놓고 디버깅합니다. 물론, 네트워크를 통해서 디버깅해주는 기능을 제공하기도 합니다. 이에 비해 Windows 8에서는 개발자 PC의 로컬에서도 앱이 작동하기 때문에 로컬 머신/시뮬레이터/실제 기계에서 디버깅 할 수 있고, 이 중에서 실제 기계에서 실행해볼 수 있도록 해주는 기능이 바로 리모트 디버깅입니다. 개발 환경만 본다면 다른 모바일 앱 개발 환경에 비해서 많이 좋은 편이죠^^)

리모트 디버깅 설정 방법

리모트 디버깅을 하려면 디버깅을 할 다른 기기에 Windows 8을 설치한 다음 리모트 디버거를 설치해야 합니다.

아래 주소에서 리모트 디버거를 다운로드하여 디버깅할 기기에 설치합니다.

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28973

여기서 잠깐

Visual Studio 2011을 설치하면 리모트 디버거가 같이 설치가 됩니다. 어떤 분들은 아예 Visual Studio 2011을 설치해버려서 리모트 디버깅도 하고 직접 컴파일도 하는걸 좋아하실 지도 모르겠네요^^

Visual Studio 2011에서의 리모트 디버깅은 네트워크 상으로 데이터를 주고받습니다. 따라서 디버깅할 기기를 개발자 PC와 같은 네트워크에 연결시킵니다.

디버깅할 기기에서 리모트 디버거를 실행합니다.

개발자 PC의 Visual Studio에서 Remote Machine으로 변경합니다.

그러면 다음과 같은 창이 뜹니다. 만약 리모트 디버깅을 처음 사용하거나 다른 기기를 등록하고 싶으면 Address에 해당 기기의 주소를 입력하여 등록합니다. 참고로 기존에 등록되어 있는 리모트 머신이 있으면 이 창이 안뜹니다. 그리고, 전 이미 연결을 해버려서 확실히 기억이 나지 않지만 아마 기기 쪽에서도 수락을 해줘야 할 겁니다^^;

이제, 프로젝트를 실행하면 다음과 같이 로컬 머신이 아니라 다른 기기에서 프로그램이 실행이 되는 것을 확인할 수 있습니다.

스마트폰을 한 손에 들고 찍느라 사진이 좀 흔들렸습니다^^;

리모트 기기 쪽의 메트로 화면을 보면 HelloWorld가 등록되어 있네요. 터치와 관련된 부분은 글로 전달하기가 쉽지 않은데, 실제 기계에서 앱을 실행해보면 로컬 머신이나 시뮬레이터와는 느낌이 매우 다르다는 것을 아시게 될 겁니다.^^

이렇게 기기 쪽에서 실행된 앱은 마치 개발자 PC의 로컬 머신에서 돌린 것처럼 디버깅을 할 수 있습니다. 예를 들면 다음과 같이 브레이크 포인트를 찍어놓고 기기 쪽에서 버튼을 터치하면 디버깅 기능이 아주 잘 작동함을 확인할 수 있습니다. 게다가, 리모트 디버깅 기능의 속도는 꽤 빨라서 로컬과 거의 차이를 느낄 수가 없습니다.

참고로, 리모트 기기 쪽의 리모트 디버거 창을 보시면 다음과 같이 연결 로그가 표시됩니다.

그런데, 개발하다 보면 크기와 해상도가 다른 다양한 기기에서 테스트를 해야 할 수도 있습니다. 이런 경우 리모트 머신을 바꿔줘야 하는데 이 경우 프로젝트의 속성창의 Debug 탭을 보시면 다음과 같이 리모트 머신 관련 설정을 변경하실 수 있습니다.

이처럼, Visual Studio 2011에서는 실제 메트로 앱 개발에 필요한 편리한 기능들을 제공하여 개발 생산성을 높여줍니다.

터치 기반의 개발 환경 구축

Windows 8은 모바일 전용 OS가 아니라 모바일과 데스크탑까지 아우르는 OS입니다. 그래서 이전처럼 키보드와 마우스로도 아주 훌륭하게 잘 작동하죠. 하지만 Windows8을 접하는 대부분의 사람들은 “터치로 해야 제 맛이겠네”라고 말합니다^^

사실, 틀린 말이 아닌 것이 대부분의 메트로 스타일 앱은 터치 스크린에 최적화되어 개발이 됩니다. 따라서 개발자들도 이에 맞는 개발 환경을 구축하지 않을 수가 없습니다.

갑자기 왜 개발 환경 구축애기를 하냐구요? 바로 위에서 설명한 리모트 디버깅과 관련된 내용이기 때문입니다.

Windows 8 메트로 스타일 앱 개발을 위한 터치 환경 구축에는 다음과 같은 방법들이 있습니다.

1) 기존 데스크탑/노트북을 사용하는 경우

Windows 8은 Windows 7보다도 더 가볍고 빠르기 때문에 기존 PC/노트북에 Windows8 과 Visual Studio 2011을 설치해서 개발하실 수 있습니다.

이 경우, 실제 기계 대신 시뮬레이터를 이용하여 테스트를 해야 합니다.

그런데, 터치도 안되고 GPS도 없는 기존 PC에서 어떻게 테스트를 할 수 있을까요? 마우스를 여러 개 꼽아서 사용하면 될까요?^^

시뮬레이터에서는 터치가 안되는 기기에서 터치 입력을 테스트할 수 있는 방법을 제공합니다.

시뮬레이터 툴바의 우측 상단에 있는 아이콘을 이용하면 싱글 터치, 핀치/줌, 로테이션을 테스트해볼 수 있습니다.

예를 들어서, Pinch/Zoom 아이콘을 클릭하면 다음과 같이 2개의 터치 커서가 나타납니다. 마우스 왼쪽 버튼을 클릭한 상태에서 마우스 스크롤 휠을 굴리면 확대/축소가 됩니다. 아이디어 괜찮네요^^

다음 스크린 샷과 같이 현재 위치 값을 수동으로 넣음으로써 GPS도 테스트해 볼 수 있습니다. 예를 들어서 위치 기반 앱을 만들 경우 현재 위치의 위도/경로를 수동으로 입력하여 가상으로 GPS가 작동하는 것처럼 만들 수 있다는 것이죠.

이처럼, 터치가 되는 장비를 구입하지 않고도 얼마든지 메트로 스타일 앱을 만들 수 있습니다. 시뮬레이터로 터치 입력해보시면 터치가 없어도 테스트할 수 있다는 것은 좋지만 아무래도 불편한 것이 사실입니다. 여러분이 돈을 받고 앱을 판매하실 생각이시라면 되도록이면 실제 기기를 구입하는 편이 좋겠죠.

여기서 잠깐
멀티터치가 되는 스크린에서 시뮬레이터를 실행하면 시뮬레이터에서도 멀티터치를 사용할 수 있습니다.

2) 터치가 되는 모니터를 구입하는 경우

인터넷 쇼핑몰을 검색해보시면 터치가 되는 모니터를 판매하고 있습니다. 이 경우 모니터만 바꾸면 개발자가 손만 모니터로 뻗어서 바로 터치 입력을 테스트할 수 있습니다.

아래 제품은 HP의 L2105tm라는 모델로 2터치 지원입니다. 이 글은 제품 홍보나 리뷰 글이 아니므로 더 이상의 상세한 내용은 적기가 좀 그렇군요.

출처: http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c01914769&lang=en&cc=us&taskId=101&prodSeriesId=4031739&prodTypeId=382087

여하튼, 터치가 되는 모니터를 구입하면 넓은 화면 덕분에 개발하기도 좋고 바로 터치가 되어서 편리하긴 합니다.

3) 터치가 되는 노트북을 구입하는 경우

바꾸는 김에 아예 터치가 되는 노트북으로 바꿀 수도 있습니다. 터치 스크린이 장착된 노트북은 크게 2가지 타입이 있습니다.

화면이 돌아가고 스타일러스 펜이 있는 노트북

– 전통적인 윈도우 태블릿 노트북으로 대부분 멀티터치와 정밀한 스타일러스 펜 입력이 동시에 지원되기 때문에 Windows8에서 지원하는 모든 타입의 입력을 테스트할 수 있습니다. 단점은 화면이 작고 (13.3인치 이하) 비쌉니다.

아래 모델은 레노보 x220t라는 모델인데 성능 좋고 될 것 다 되지만 가격이 엄청 비쌉니다^^;

사진 출처: http://laptops.techfresh.net/more-details-on-lenovo-thinkpad-x220-and-x220t-tablet-pcs/

터치만 되는 노트북

- 아직까지는 이런 타입의 노트북은 거의 없지만(지금 까지 나온 종류가 몇 개 안됩니다.) 얼마 전 인텔의 발표로 봤을 때 Windows 8 출시 이후에 이런 노트북이 꽤 많이 나올 듯 싶습니다. 기존 윈도우 태블릿보다는 가격이 저렴할 겁니다.

아래 사진은 인텔에서 차기 울트라북 전략을 발표하면서 공개한 터치 스크린 장착 울트라북 샘플입니다.

앞으로 울트라북이 이런 식으로 발전할 거라고 말하는군요. 노트북에 터치스크린이 장착되면 교통 수단으로 이동 시 입력의 편리성이 매우 향상됩니다.

출처: http://www.gizmowatch.com/intel-touchscreen-ultrabook-emerge-ivy-bridge-windows-8.html

이런 노트북을 구입하면 개발과 실기에서 테스트를 모두 할 수 있는 장점이 있죠. 단점은 노트북을 새로 구입해야 한다는 것입니다^^;

4) 슬레이트 타입의 태블릿을 사용하는 경우

실제 사용자들이 사용할 기기들은 대부분 아이패드와 비슷한 모양의 터치스크린만 있는 윈도우 태블릿이 될 겁니다.

다음은 //Build/ 컨퍼런스에서 개발자에게 살포(?)한 Developer PC로 삼성 Slate7의 베타버전 정도 되는 기기입니다. 키보드 독이 있고 USB 포트가 있으며 CPU가 Core i5라서 개발 머신으로도 충분히 사용할 수 있을 정도입니다.

아래 사진과 같이 저사양의 윈도우 태블릿도 나와 있어서 가격의 부담을 덜 수 있습니다. 물론 성능은 좀 느립니다.

출처: http://us.acer.com/ac/en/US/content/model/LE.RK602.047

리모트 디버깅 이야기 하다가 여기까지 왔는데… 사실 제가 말하고 싶었던 것은 리모트 디버깅은 바로 위와 같은 타입의 기기와 함께 사용할 때 주로 사용된다는 겁니다. 이 경우, 개발자 PC는 꼭 터치가 될 필요는 없겠죠. 그리고 개발자가 여러 명인 경우 평상시는 로컬 머신이나 시뮬레이터로 개발하다가 필요할 때만 이런 기기를 연결해서 리모트 디버깅으로 테스트할 수도 있습니다.

위와 같이 여러 가지 방법으로 Windows 8 앱 개발을 위한 터치 개발 환경을 구축할 수 있습니다. 각 방식마다 장단점이 있고, 또 Windows 8이 다른 모바일 OS처럼 모바일 기기에서만 사용되는 것이 아니기 때문에 개발하는 앱의 특성과 타겟 기기에 따라서 적절한 방식을 선택할 필요가 있습니다.

한 가지 확실한 점은 Windows 8이 정식으로 출시되면 다양한 타입의 터치 기기가 시장에 등장할 것이고, 앞으로 개발자들도 노트북을 구입할 때 터치 지원 여부를 따지게 될 것입니다.

2회에 걸쳐서 Visual Studio 2011을 이용한 메트로 스타일 앱의 대략적인 개발 개요(또는 느낌)에 대하여 설명드렸습니다.

하지만, 한가지가 빠졌습니다. 바로 개발한 앱을 어떻게 배포하느냐는 겁니다. 만들어서 남에게 안주면 소용이 없자나요^^;

그래서, 다음 글에서는 메트로 스타일 앱의 배포에 대해서 이야기해보도록 하겠습니다.

P.S. 사실, 터치 스크린과 터치 입력의 특성에 대해서 제대로 설명하면 한참을 해야 하는데 이 글에서는 상세히 기술하지 않았습니다.

Windows 8 앱 개발 이야기 - Hello World로 살펴보는 앱 개발 개요 #1

ivoryguard — Sun, 11 Mar 2012 16:08:10 +0900

이번 강좌에서는 C#으로 아주 간단한 메트로 스타일 앱을 만들어봄으로써 메트로 스타일 앱 개발의 대략적인 개요에 대해서 살펴볼까 합니다.

메트로 스타일 앱을 개발하기 위해서는 Windows 8 컨슈머 프리뷰와 함께 Visual Studio 2011 Beta가 필요합니다.

MSDN 구독자는 MSDN 사이트에서 다운로드하실 수 있고, 일반 개발자들은 다음 링크에서 무료 개발도구인 Visual Studio 2011 Express Beta for Windows 8을 다운로드하여 설치합니다.

http://msdn.microsoft.com/en-us/windows/apps/br229516/

저는 Visual Studio 2011 Ultimate Beta를 사용하기 때문에 Visual Studio 2011 Express Beta for Windows 8의 사용자의 경우에는 UI나 기능이 약간 다를 수 있습니다.

개발 준비가 되었으면, Visual Studio 2011 Beta를 실행합니다.

Visual Studio 2011부터는 개발도구도 메트로 스타일로 확 바뀌었습니다. 만약, 이전부터 .NET 개발을 해오신 분이라면 좀 어색할 수 있습니다. 제 경우에는 느낌도 좀 다르고 아이콘도 바뀌어서 좀 낯설어보입니다. 뭐 시간이 지나면 익숙해지겠지요.

New Project 메뉴를 클릭하고 왼쪽 템플릿 목록 중에서 Windows Metro Style을 선택하면 다음과 같이 여러 개의 템플릿이 표시됩니다.

이 중에서 Blank Application을 선택한 후 솔루션 이름과 프로젝트 이름을 Hello World라고 지정한 후 OK를 클릭합니다.

그러면 다음과 같이 프로젝트가 생성이 됩니다.

오른쪽 Solution Explorer에서 BlankPage.xaml을 더블클릭하여 XAML 뷰를 엽니다.

여기서 잠깐!
Visual Studio 2011 Beta를 설치하실 때 기본 경로가 아닌 다른 경로에 설치하면 XAML 디자인 뷰가 작동하지 않습니다.
이런 문제가 발생할 경우 다음 링크에 있는대로 하시면 해결하실 수 있습니다. (제가 그랬습니다 ^^)
http://blendinsider.com/xaml/known-issue-xaml-designer-in-visual-studio-11-beta-crashes-on-launch-2012-03-07/

왼쪽 ToolBox에서 Button 하나와 TextBox 하나를 화면에 끌어놓기 한 후 Name을 각각 btnTest, txtMsg로 변경합니다.

BlankPage.xaml.cs 를 열어서 다음과 같이 코드를 삽입합니다.

프로젝트를 실행하면 다음과 같이 전체 화면으로 프로그램이 실행됩니다. 메트로 스타일 앱은 기본적으로 전체 화면으로 실행된다는 점을 기억하세요.

윈도우 키를 눌러서 메트로 화면으로 가보면 다음과 같이 우리가 만든 프로그램이 화면에 등록되어 있음을 보실 수 있습니다.

간단하게 Hello World 앱을 만들어봤습니다.

느낌이 어떠신가요? 만약 실버라이트나 WPF를 개발해보신 분이라면 아마도 익숙함을 느끼실 겁니다.

Windows 8 메트로 스타일 앱의 UI는 XAML로 정의하고, 코드 비하인드 쪽에서는 C#/VB로 개발합니다.

메트로 스타일 앱은 C#.VB 이외에도 HTML5/Javacript, C++ 로도 개발할 수 있는데, 이 강좌에서는 .NET 기반 개발에 대해서만 설명했습니다. 사실 메트로 스타일 앱을 HTML5/Javascript로 개발할 수 있다는 점은 매우 중요한 의미를 갖는데, 이에 대해서는 다음에 얘기해보도록 하지요.

실버라이트, WPF, Windows 8 메트로 스타일 앱, Windows Phone 7 앱에는 한 가지 공통점이 있습니다.

모두 XAML을 기반으로 한다는 것이죠. 따라서, 기존 실버라이트나 WPF 개발자는 이미 메트로 스타일 앱 개발의 상당수의 내용을 알고 있는 셈입니다. 위 기술들이 모두 XAML을 기반으로 하고 있고, 또 개발 방식도 거의 비슷하고 .NET 프레임웍의 API를 기반으로 하기 때문에 상당수의 코드를 공유하거나 재활용할 수 있다는 장점이 있습니다. 그래서 XAML을 알고 있으면 데스크탑, 웹(실버라이트), 스마트폰, 태블릿 앱 개발을 모두 할 수 있습니다. 물론, 각 기술마다 XAML 문법이 완전히 똑같지는 않아서 약간의 수정이 필요하지만, 그래도 상당수의 코드를 재활용할 수 있다는 점은 매우 큰 장점이라고 할 수 있겠죠.

사실, Windows 8 이 출시되면 가장 혜택을 보는 개발자가 바로 실버라이트/WPF 개발자 분들이실 겁니다. 이 중에서도 메트로 스타일 앱은 실버라이트, 특히 Windows Phone 7용 실버라이트와 가장 유사하기 때문에 기존 실버라이트 개발자분들은 정말로 빠르게 적응하실 수 있습니다.

하지만 실버라이트/WPF 개발자가 아니더라도 메트로 스타일 앱 개발에 어렵지 않게 적응할 수 있습니다. 메트로 스타일 앱 역시 기본적으로는 .NET이기 때문에 UI단 이외의 다른 부분은 데스크탑용 .NET Framework에서 배웠던 기능들 중 상당수를 그대로 사용할 수 있기 때문에 기존 .NET 개발자가 안드로이드나 iOS용 앱을 개발하는 것에 비해서는 훨씬 빨리 적응할 수 있습니다.

즉, Windows 8의 메트로 스타일 앱은 이미 수많은 잠재 앱 개발자를 보유하고 있는 것입니다. 게다가 Visual Studio라는 강력한 도구까지 있구요.^^

여기서 잠깐!

이번 Windows 8 강좌에서는 XAML의 기초적인 문법까지는 다루지 않고 그때 그때 필요한 부분만 설명할 예정입니다.
혹시, XAML이 처음이신 분은 실버라이트 게시판에서 제 실버라이트 강좌를 보시면 조금이나마 도움이 되지 않을까 싶네요.

http://www.sqler.com/bSilverlight

말이 실버라이트 강좌지 80%의 내용은 XAML에 대한 이야기입니다.

그런데…. Windows 8 메트로 스타일 앱은 기존 윈도우 응용 프로그램과는 작동 방식이 좀 다릅니다.

윈도우 탐색기로 프로젝트 폴더를 열어서 HelloWorld.exe를 더블클릭하면 다음과 같이 오류 창이 뜨면서 실행이 안됩니다.

즉, 메트로 스타일 앱은 반드시 메트로 UI 안에서만 작동한다는 것이죠.

그리고, 기존 윈도우/웹 개발과 다른 점이 또 하나 있습니다.

빌드를 할 때 Local Machine, Simulator, Remote Machine을 고를 수 있다는 겁니다.

Windows 8은 다른 모바일용 OS와는 달리 데스크탑 OS이기도 합니다. iOS나 안드로이드 앱을 개발할 때는 데스크탑 PC(또는 Mac)에 개발툴을 설치하고 기계를 연결하여 개발하는데, Windows 8은 그 자체가 데스크탑 OS이기 때문에 로컬 머신에 Visual Studio를 설치하여 바로 개발할 수 있습니다. 그래서 개발 환경은 다른 모바일 OS에 비해서 아주 많이 좋고 편리합니다.

그럼, Simulator는 뭘까요?

Simulator로 바꾼 후 실행하면 현재 데스크탑 화면에서 실행되지 않고 다음과 같이 가상의 태블릿 화면 안에서 실행됩니다.

아하! Simulator로 실행하면 다른 모바일 앱 개발처럼 가상의 기계에서 테스트를 할 수 있군요!

Simulator에서는 현재 데스크탑 메트로 화면이 그대로 재현이 됩니다. 데스크탑에 어떤 메트로 앱이 설치되어 있으면 그것도 그대로 나옵니다. 그래서 에뮬레이터가 아니라 시뮬레이터입니다.

메트로 스타일 앱 개발에서 Simulator는 매우 중요한 역할을 합니다.

실제 기계는 다양한 해상도와 크기를 가지고 있고, 중력 센서에 의해 화면이 회전이 되기도 합니다.

이러한 것들을 실제 기기 없이 개발 환경에서 가상으로 테스트해볼 수 있는 것이죠.

예를 들면 다음과 같이 화면이 회전된 상태를 만들 수도 있구요…

또 다음과 같이 화면의 크기도 바꿔가면서 테스트할 수도 있습니다.

마지막으로, Remote Machine이 있는데, 이건 뭐냐면 실제 태블릿 기기를 연결하여 그쪽에서 실행되게 하는 것입니다.

예를 들면…아래 사진은 //BUILD/ 컨퍼런스 참가자에게 배포한 삼성에서 만든 윈도우 태블릿인데, Remote Machine을 선택하고 빌드하면 Visual Studio로 개발하는 프로그램이 내 컴퓨터가 아니라 실제 기기에서 실행이 됩니다. 이렇게 하면, 프로젝트를 실행한 후 실제 기기에서 직접 터치하면서 테스트를 할 수 있으니 사용자들이 실제로 사용하는 방식대로 테스트해볼 수 있습니다.

참고로.... 아래 사진은 제 겁니다^^

이처럼, Visual Studio 2011에서는 메트로 스타일 앱 개발을 편리하게 하는 많은 기능들을 제공하고 있습니다.

그럼, 다음 강좌에서는 Remote Machine 디버깅과 메트로 앱을 배포하는 방법에 대해서 살펴보도록 하겠습니다.

Windows 8 앱 개발 이야기 - WinRT에 대하여

ivoryguard — Sun, 11 Mar 2012 15:57:35 +0900

Windows 8 개발 이야기를 하면서 빼놓을 수 없는 것이 바로 WinRT에 대한 것입니다. 사실, WinRT는 Windows 8 Metro Style App 개발의 전부라고 해도 과언이 아닙니다.

그래서, 이번 글에서는 WinRT에 대해서 간략히 살펴보도록 하겠습니다.

다음 그림은 Microsoft의 Windows 8 개발 관련 PPTX에 자주 등장하는 거의 공식적인(?) Windows 8 플랫폼의 구조도입니다.

위 그림에 따르면 메트로 스타일 앱을 만드는 방법에는 XAML을 이용하는 것과 HTML/CSS를 이용하는 방법이 있군요.

XAML을 이용하는 경우에는 C++/C#/VB를 사용할 수 있으며, HTML/CSS를 이용하는 경우에는 JavaScript로 개발하게 됩니다.

그리고 바로 아래에 WinRT가 있어서 어떤 언어를 사용하더라도 WinRT의 API를 사용하도록 되어 있군요.

위 그림에서 Metro Style APP 영역과 Desktop Apps 영역의 색깔이 다르죠? 이 두 영역 사이에는 너무나 큰 간격이 있어서 양쪽을 오갈 수 없습니다. 즉, 두 영역이 서로 상관없이 완전히 따로 논다는 것이죠.

WinRT는 Windows Runtime의 약자입니다. WinRT는 메트로 스타일 앱 개발을 위한 새로운 Windows API입니다. 메트로 스타일 앱을 만드는데 있어서 WinRT는 마치 데스크탑 어플리케이션 개발에서의 Win32와 같은 역할을 수행한다고 볼 수 있지요.

자 그럼 여기서 질문 하나, WinRT는 새로운 .NET Framework일까요?

현재까지 조사해본 바에 따르면 WinRT는 COM 기반의 Native API입니다. WinRT는 C언어 기반의 오래된 Win32 API는 달리 객체지향을 기반으로 하여 현대적으로 설계되었으며 C++로 만들어졌다고 하는군요. 그리고 COM 기반으로 하는 Native API라고 합니다.

즉, WinRT가 .NET Framework의 영향을 많이 받긴 했지만 .NET Framework 그 자체는 아니라는 것이지요.

그럼, Windows 8에서 .NET Framework은 어디로 갔을까요?

다음 그림을 봅시다. (출처: http://dougseven.com/2011/09/15/a-bad-picture-is-worth-a-thousand-long-discussions/)

위 그림은 Windows 8 개발과 관련하여 좀더 상세하고 정확하게 보여주는 그림입니다.

위 그림에 따르면 C#/VB로 메트로 스타일 앱을 개발할 때는 .NET Framework 4.5를 이용한다고 되어 있네요. 그런데, 오른쪽 데스크탑 쪽에도 .NET 4.5가 보입니다. 어떻게 된 일일까요?

.NET Framework 4.5에는 .NET Metro Profile이라는 것이 추가되었습니다. C#/VB로 메트로 스타일 앱을 개발할 때는 데스크탑용 Full .NET Framework 4.5 대신 .NET Metro Profile이라는 서브셋만을 사용하게 됩니다. 참고로 데스크탑용 .NET 프로그램을 개발할 때는 .NET Client Profile을 사용하게 됩니다. 즉, WinRT는 메트로 스타일 앱 개발 시 기존의 Win32와 유사한 역할을 수행하며 그 위에서 .NET Framework 4.5 Metro Profile이 작동하고 있는 것이 됩니다.

그럼, 여기서 질문 하나 더 해보죠. WinRT는 Win32를 대체하는 걸까요?

이 질문에 대한 답은 적어도 x86에서는 아니라는 겁니다. 여러 사람들이 이 문제에 대해서 조사를 해봤는데 x86 CPU에서 Windows 8 Metro Style App을 실행해보면 기존 데스크탑 응용 프로그램과 같이 Win32용 DLL들을 로딩한다고 합니다. 즉, x86 CPU 상에서는 WinRT는 Win32 API 상에서 작동한다고 볼 수 있겠네요.

그런데, Windows 8은 x86 뿐만 아니라 ARM Core CPU도 지원한다고 하고 있죠. 아직 ARM Core CPU용 Windows 8이 공개가 되지 않았기 때문에 단정할 수는 없겠지만, 개인적으로 ARM Core CPU에서는 WinRT가 Win32를 대체하는 그런 느낌으로 사용될 것으로 예상하고 있습니다. ARM Core CPU애서는 Win32 API가 작동하지 않으니까요.

정리하면, WinRT는 메트로 스타일 앱을 위한 새로운 Windows API라고 보시면 되겠습니다.
마치 “새 술은 새 부대에” 같은 느낌이군요^^

WinRT는 .NET Framework만 지원하는 것이 아니라 다른 언어에서도 사용이 됩니다.

매트로 스타일 앱은 크게 다음 3가지 방법으로 개발될 수 있습니다.

당연하게도 C#/VB + XAML 개발이 가능합니다. 이 경우 .NET Framework 4.5 Metro Profile을 이용하며 WPF/Silverlight 개발과 매우 유사합니다. (사실 WPF보다는 Silverlight와 더 유사합니다.) 이 경우 컴파일한 결과는 *.exe로 생성이 되는데, 이렇게 생성된 exe 파일은 데스크탑 모드에서는 실행되지 않습니다. 윈도우 탐색기에서 exe를 더블클릭해보면 다음과 같이 경고 메시지만 뜹니다. 즉 메트로 스타일 앱의 exe는 반드시 Metro UI를 통해서만 실행이 됩니다.

사실, Window 8로 넘어오면서 가장 덕을 보는 사람들이 바로 WPF/Silverlight 개발자가 아닌가 싶습니다. 물론, WPF와 Silverlight의 XAML이 차이가 있는 것처럼 메트로 스타일 앱의 XAML도 WPF/Silverlight와 차이가 있습니다. 하지만 기본적인 내용은 거의 같기 때문에 WPF나 Silverlight를 해본 사람이면 단시간 내에 메트로 스타일 앱 개발자가 될 수 있습니다. 그 중에서도 Silverlight 개발자가 가장 빨리 익숙해질 수 있습니다.

Windows Phone7과 달리 C++도 지원합니다. C++로 개발 시 XAML도 사용할 수 있지만 아마도 C++은 주로 DirectX를 이용할 때 주로 사용되지 않을까 싶네요. 모바일 개발자 중 C++ 개발자 비중이 많은 현실이다 보니 C++ 지원은 꽤나 중요할 듯 싶습니다.

마지막으로, WinRT에서는 HTML5/JavaScript 개발도 지원합니다. 이 경우 개발되는 Metro Style App은 *.appx라는 압축 파일 안에 패키징 되며 Metro 버전의 IE 상에서 작동하게 됩니다. HTML5로 메트로 스타일 앱을 만들 수 있다는 것은 매우 중요한 의미를 가집니다. HTML5로 메트로 스타일 앱을 개발할 때는 WinJS라는 메트로 스타일 앱 전용 자바스크립트 라이브러리를 사용해야 하기 때문에 기존 Javascript코드를 100% 재활용할 수는 없지만 분명 기존 소스를 어느 정도는 재활용할 수 있고, 무엇보다도 이미 익숙한 HTML과 JavaScript로 앱을 개발할 수 있다는 점에 수많은 잠재 개발자를 확보하게 되는 것이죠. 즉, Windows 8의 생태계를 단시간 내로 확장하고 견고하게 만들 수 있는 것입니다.

그런데, 위 3가지 개발 모두 밑단에서는 결국 WinRT의 API를 사용합니다. 그리고 컴포넌트도 공유할 수 있습니다. 즉, 어떤 WinRT용 컴포넌트를 개발했다면 C#/VB/C++/JavaScript에서 모두 사용할 수 있다는 겁니다. 단, 이처럼 다양한 언어에서 호출이 가능하려면 WinRT 컴포넌트에 맞게 개발을 해야 합니다. 이 부분은 아직 상세히 공부하지 못했는데, 예를 들면 C#으로 개발할 경우 C#의 모든 데이터 타입을 컴포넌트 API로 노출할 수 없고, WinRT에서 공용으로 사용할 수 있는 데이터 타입만을 사용해야 하는 걸로 알고 있습니다. 데스크탑 개발에서 COM 컴포넌트 만들면 여기저기에서 사용할 수 있었는데, 이 때 COM 인터페이스에 맞게 컴포넌트를 개발해야 하는 것과 비슷한 느낌이네요.

아직까지는 Windows 8이 정식 출시되지 않아서 서드파티 컨트롤이 전혀 없지만 Windows 8 정식이 출시되면 매우 다양한 컴포넌트들이 출시가 되어 어떤 언어로 개발하더라도 쉽고 빠르게 개발할 수 있게 되지 않을까 싶습니다. 마치 데스크탑 응용 프로그램을 위한 수많은 ActiveX 컴포넌트나 .NET 컴포넌트들이 있었던 것처럼 말입니다.

사실 Metro Style App을 개발할 때 WinRT에 대해서 직접적으로 몰라도 만들 수는 있을 겁니다. 하지만 데스크탑 응용 프로그램을 만들다 보면 Win32 API에 대해서 알 필요가 있는 경우가 많은 것처럼, Metro Style App 개발을 하다 보면 WinRT에 대해서 어느 정도 알아야 할 필요가 있지 않을까 싶네요. 아직은 초기 단계라서 WinRT에 대한 정보가 매우 부족하지만 시간이 지남에 따라 “Windows API 정복”과 같은 책처럼 “WinRT API 정복”과 같은 책이 나올지도 모르겠네요.

한 가지 좋은 소식이 있는데, “Programming Windows’로 유명한 찰스 펫졸드 아저씨가 “Programming Windows” 6th 에디션을 준비중이라고 합니다. 이번 책에서는 C#과 XAML로 Windows 8 메트로 스타일 앱 개발에 대한 내용이 된다고 하는군요. 무척이나 기대가 됩니다.

http://www.charlespetzold.com/blog/2012/02/Programming-Windows-6th-Edition.html

Windows 8 앱 개발 이야기 - Windows 8 살펴보기

ivoryguard — Sun, 11 Mar 2012 15:50:48 +0900

2월 29일 스페인 바르셀로나 모바일 월드 콩그레스(MWC) 2012 행사장에서 Windows 8 컨슈머 프리뷰 버전이 공개되었습니다. 작년 9월에 공개되었던 개발자 프리뷰는 사실 개발자들을 대상으로 하는 맛보기용 버전이었고, 이번에 공개된 Windows 8 컨슈머 프리뷰는 이름 그대로 실제 사용자들을 대상으로 하는 프리뷰 버전으로 사실상 Windows 8 베타 버전이라고 할 수 있죠. 이와 함께 Windows Store 베타 및 Visual Studio 2011 Beta도 같이 공개되었습니다.

즉, 드디어 Windows 8용 앱 개발을 위한 실질적인 장이 마련된 것입니다.

이 글에서는 Windows 8용 앱 개발에 들어가기 앞서 Windows 8에 대해서 간략히 살펴보고 개발 환경 준비에 대한 이야기를 할 까 합니다.

태블릿 OS와 데스크탑 OS가 융합하고 있다.

애플에서 아이패드를 처음 내놓을 당시 아이폰을 키운 것 뿐이라는 비평이 꽤 있었습니다. 그런데, 출시 이후에 어떻게 되었나요? 단지 화면이 커진 것 뿐인데 그것 하나만으로도 새로운 사용처와 시장을 만들어냈으며 태블릿 시장의 대부분을 독식하고 있습니다. (작년 아마존 킨들의 저가 공세로 좀 줄어들긴 했습니다만…)

아이패드로 시작된 태블릿 시장은 앞으로 매우 큰 성장 가능성을 가지고 있는 블루오션인데, 현재 Microsoft Windows의 상황은 어떤가요?

사실, 태블릿 PC는 윈텔 진영에서 먼저 시작했습니다. 그러나 비싸고, 무겁고, 사용하기가 불편해서 많이 팔리지는 못했죠. 현재도 Windows 7 기반의 태블릿 PC들이 있긴 하지만 아이패드에 비해서는 판매량이 매우 적습니다. (개인적으로는 Windows 7 기반의 태블릿 PC와 아이패드는 서로 비교할 수 없는 다른 기기라고 생각합니다만 시장에서는 비교를 많이 하죠. 어떤 곳에서는 아이패드와 같은 컨텐츠 소비 지향성 태블릿PC를 스마트패드라고 부르기도 하더군요.)

여하튼, MS에서 있어서 태블릿 시장은 기존 PC 영역에 더욱 가깝기 때문에 MS로서는 절대로 밀려서는 안 되는 시장입니다. 그래서, 좀 늦은 감이 있긴 하지만 MS에서도 Windows 8을 출시함으로써 태블릿 시장에 대응하려고 하고 있습니다.

그런데, 좀 더 일이 재미있게 되었습니다. 왜냐면 Windows 8은 태블릿 전용 OS가 아니라 태블릿부터 데스크탑까지 아우르는 범용 OS로 만들어졌기 때문입니다. 개인적으로는 MS가 애플이 했던 것처럼 WP7을 기반으로 태블릿 전용 OS를 내놓을 거라고 생각했었는데 완전히 틀린 셈입니다^^;

Windows 8이 범용 OS라는 것은 매우 중요한 의미를 가지고 있습니다. MS 관계자분의 말씀에 따르면 MS는 애초부터 태블릿 OS와 데스크탑 OS를 따로 가져갈 생각이 없었다는군요. 사실, 태블릿과 스마트폰 사이에는 생각보다 사용 패턴이 다르며, 오히려 태블릿과 노트북 사이에 더욱 많은 유사성이 있습니다. 따라서 MS의 이러한 전략은 범용 OS 제조사로서 충분히 납득이 갈만한 일이며, 다양한 기기에서 같은 OS를 사용함으로써 얻을 수 있는 장점도 상당히 많습니다.

즉, 태블릿 OS와 데스크탑 OS가 융합하고 있다는 겁니다. 이 말 한 마디 하려고 서론이 길었네요^^;

아래 그림은 현재 애플과 MS의 OS 배합(?)에 대한 그림입니다.

애플의 경우 스마트폰과 태블릿이 같은 OS를 사용하고, 데스크탑 OS에서 모바일 OS의 기능을 수용하고 있는 모양새입니다.

이에 비해 MS는 스마트폰만 OS가 다르고 태블릿 이상은 같은 OS로 가고 있습니다. 그리고 데스크탑 OS가 태블릿 OS를 수용하고 있는 모양새를 취하고 있죠.

* 위 그림은 현재 상황에 한정된 것입니다. 지금까진 나온 루머에 따르면 “아폴로”라는 프로젝트 명을 가진 Windows Phone 8은 WinRT기반, 즉 Windows 8과 커널을 공유한다고 합니다. 그렇게 된다면 Windows Phone 8부터는 데스크탑, 태블릿, 스마트 폰이 같은 커널의 OS를 사용하게 될 것입니다.

Windows 8의 주요 특징

개인적으로, Windows 8는 MS의 장기적인 전략에 대한 고민이 녹아있는 OS라는 느낌을 받았습니다. 예전에 어떤 기사를 보니 Windows 8은 MS의 가장 큰 모험중의 하나라고 말했다던데 실제로 그렇게 말할 만큼 큰 변화가 많습니다.

이 글은 IT 강좌가 아니므로 개발과 관련된 부분을 위주로 Windows 8의 특징 몇 가지만 간단히 살펴보겠습니다.

1) 터치에 특화된 Metro UI

Windows Phone 7과 유사하게 시작 화면이 메트로 스타일로 바뀌었습니다. 물론 기존의 데스크탑 화면도 사용할 수 있지만 아주 큰 변화죠. 모든 UI가 터치에 특화되어 있습니다. 물론 키보드와 마우스로도 사용할 수 있습니다. 하지만 앞으로 Windows 8용 프로그램을 만들 때는 터치 입력을 고려해서 만들지 않을 수가 없겠죠?

참고로, 메트로 UI는 기존 Windows에 Shell 형태로 올린 런처가 아니라 OS와 완전히 통합되어 있습니다. 또한 GPU 가속을 통해 매우 빠르고 부드럽게 작동하지요.

Windows 8에서 도입한 메트로 UI는 다음과 같은 특징을 가집니다.

- 터치에 최적화된 사용자 경험을 제공합니다.

- 기존 시작 메뉴에 비해 프로그램 실행 아이콘(또는 이미지)를 보다 시각적으로 표시해줍니다.
(기존 데스크탑 사용자에게 이 부분이 어떻게 받아들여질지는 좀더 연구해볼 필요는 있습니다.)

- 해상도에 유연합니다.

위에서 말한 “해상도에 유연”하다는 특징은 다음 스크린샷을 보시면 쉽게 알 수 있습니다.

아래 스크린샷은 1366*768 해상도에서 캡쳐한 것입니다.

아래 스크린샷은 1920*1200 해상도에서 캡쳐한 것입니다.

Windows 8은 소형 태블릿부터 대형 모니터까지 전부 아우를 수 있어야 하는데, 메트로 UI는 현재 화면의 해상도에 따라서 적절하게 배치가 바뀌기 때문에 화면 크기와 상관없이 일관되고 편리한 사용성을 유지할 수 있습니다. 따라서 다양한 제조사에서 만들어지는 다양한 형태의 기기에 유연하게 대응할 수 있게 됩니다.

2) ARM CPU 지원

세상에나…. 드디어 Windows 8이 ARM CPU에서도 돌아간답니다. 이 말은, 아이패드나 안드로이드 태블릿처럼 ARM Core CPU를 사용하는 기기에서도 Windows 8이 작동한다는 뜻입니다. 앞으로 ARM Core CPU에 Windows 8를 탑재한 태블릿들이 나오면 아이패드와의 정면 승부를 하게 될 겁니다.

개발자 입장에서는 한 번 만든 프로그램이 x86과 ARM 모두에서 돌아가게 되니 감사할 따름이지요^^

단, 모든 프로그램이 그대로 작동하는 것은 아니고 Metro UI상에서만 작동하는 메트로 스타일 앱만 지원됩니다.

실제로, Visual Studio 2011 베타를 실행해보면 다음과 같이 타겟 플랫폼에 ARM이 들어가 있습니다.

아직 ARM용 Windows 8은 공개되어있지 않은데 다음과 같은 내용들이 알려져 있습니다.

(MS에서는 ARM용 Windows 8을 WOA – Windows On ARM – 이라고 부르더군요.)

- ARM용 MS Office가 제공됩니다.

- ARM용 Windows 8은 개인이 직접 설치할 수 없으며 하드웨어에 기본 설치되어 제공됩니다.

- 일부 ARM 호환 CPU 제조사가 비공개적으로 ARM 기반 디바이스를 개발자에게 제공할 계획이라고 합니다.

- ARM용 Windows 8에도 x86/x64버전과 같이 데스크탑 모드가 존재합니다.

ARM CPU는 x86 계열 CPU들에 비해서 전력 소모량 대비 성능이 뛰어나다고 하죠. Windows 8의 ARM 지원은 보다 가볍고 오래가는 태블릿 기기를 만들 수 있게 해줄 것입니다.

3) 데스크탑 모드 지원

데스크탑 모드라는게 뭐냐면 예전 Windows의 바탕화면을 말합니다. 즉, 메트로 UI가 아닌 기존 방식의 바탕화면을 지원한다는 것이죠. 데스크탑 모드에서는 단축아이콘과 작업 표시줄이 있으며 여러 개의 창을 띄워놓고 사용할 수 있죠. 기존 윈도우 응용 프로그램이 데스크탑 모드에서 작동을 합니다.

즉, Windows 8 태블릿에서는 아이패드나 안드로이드 패드와 달리 여러 개의 창을 띄워놓고 작업하는 것도 가능하다는 것입니다. 사실, 어떤 작업들은 메트로 스타일 앱으로 하는 것이 불편할 수 있습니다. Windows 8의 데스크탑 모드 지원은 다른 태블릿과 차별화된 요소이며 비즈니스 환경에 어필할 수 있는 부분이기도 합니다.

한 가지 재미있는 것은, ARM 버전 Windows 8에도 데스크탑 모드가 존재한다는 것입니다. 사실, x86/x64 버전이야 데스크탑 모드가 있는 것은 당연한 것인데, ARM 버전에도 있다고 하네요. 다음과 같은 상상을 해본다면 한 편으로는 이해가 되는 부분입니다.

“ 사무실에서는 키보드와 마우스를 연결하여 MS Office로 업무를 처리하다가 외근 나갈 때는 본체만 들고 나가서 아이패드처럼 사용하고 싶습니다.”

ARM CPU를 사용함으로 인해서 배터리는 오래 가면서 얇고 가볍게 만들 수 있게 되므로 기존 윈도우 응용 프로그램이나 ActiveX를 사용하는 웹사이트에 들어가지 않는 사람이라면 보다 편리한 모바일 라이프를 즐길 수도 있지 않을까 싶네요. 아마도, ARM CPU를 사용하는 윈도우 태블릿 제품에는 독이나 키보드가 같이 제공될 확률이 높을 듯 합니다.

4) 새로운 개발 모델

Windows 8에서는 두 가지 형태의 프로그램이 지원이 됩니다.

- Desktop App: 우리가 기존에 만들어왔던 윈도우 응용 프로그램으로 x86/x64 계열 CPU에서만 작동합니다.

- Metro Style App: Metro UI 상에서 작동하며 x86과 ARM Core 모두에서 작동합니다

Windows 8의 개발 모델은 다음 그림 한 장으로 설명할 수 있습니다.

위 그림을 보시면 Metro Style App과 Desktop App이 분리가 되어 있음을 보실 수 있습니다. 이처럼 Windows 8에서는 두 가지 개발 모델이 완전히 분리되어 있어서 서로 오갈 수가 없습니다.

Metro Style App 쪽을 보시면 WinRT라는 것이 있는데, Windows 8에서 새롭게 만든 Windows API입니다. Metro Style App을 만든다는 것은 WinRT가 제공하는 API를 사용한다는 것과 같다고 보시면 됩니다.

다음 그림은 두 가지 개발 모델을 비교해본 것입니다.

Desktop App는 기존과 다를 것이 하나도 없으며 우리가 해오던 그대로 하면 됩니다. Windows 8은 Windows 7에서 작동하는 모든 응용 프로그램도 그대로 작동할 거라고 합니다. 단, 이 말은 x86 계열 CPU를 사용하는 기기에만 해당됩니다. 삼성 Slate 7과 같이 인텔 CPU를 사용하는 태블릿 PC같은 기기에서는 기존 응용 프로그램도 그대로 다 돌아갑니다. 인터넷 뱅킹, 회사 업무, MS Office 등 기존에 우리가 Windows XP또는 Windows 7에서 했던 것들을 그대로 다 할 수 있다는 거죠. 이 점이 Windows 태블릿의 장점이기도 합니다.^^

이에 비해, Metro Style App은 x86과 ARM Core CPU 모두에서 작동합니다. 그 대신, 스마트폰 용 앱과 같은 형태로 작동하며 여러 가지 보안 제약사항도 많습니다. 또한 새로운 방식으로 개발해야 합니다. 보다 정확히 말씀드리면 Windows 8에는 Windows Runtime이라는 새로운 Windows API가 생겼고, Metro Style App은 Windows Runtime 상에서 작동하는 프로그램입니다.

Metro Style App은 기존 데스크탑 프로그램보다는 스마트폰이나 태블릿용 앱과 유사하다고 보시면 됩니다.

Metro Style App은 다음과 같은 특징을 가집니다.

- 전체 화면 실행

- 모바일에 최적화된 응용 프로그램 주기

- 여러 가지 보안 제약 사항

Windows Phone7에서는 C#/VB로만 앱 개발이 가능했는데, Windows 8에서는 C++과 HTML5/JavaScript로도 개발이 가능합니다. 특히 HTML5/JavaScript로 메트로 스타일 앱을 개발할 수 있게 됨으로써 Windows 8의 앱 생태계가 매우 빠르게 만들어질 수 있는 발판이 마련되었다고 볼 수 있겠네요.

다음 그림은 Metro Style App의 응용 프로그램 주기입니다. 기존 스마트폰이나 태블릿용 앱처럼 백그라운드로 들어가면 모든 작동이 멈추고 다시 포그라운드로 오면 재개가 되죠. 또한 바로 종료되는 것이 아니라 메모리상에 남아있다고 필요에 따라서 자동으로 종료됩니다.

메트로 스타일 앱 사용 시 한 가지 주의 사항이 있습니다. 해상도가 1024*768보다 낮은 기기에서는 메트로 스타일 앱이 실행되지 않습니다.

예를 들어서 해상도가 1024*600인 HP Slate나 상당수의 넷북에서는 메트로 스타일 앱을 실행할 수 없습니다. 따라서 메트로 스타일 앱을 개발할 때는 1024*768이 최소 해상도가 됩니다. 그리고, 1366*768보다 낮은 해상도에서는 스냅 기능(한 화면에서 2개의 메트로 스타일 앱을 보여주는 기능)이 작동하지 않습니다. 따라서 해상도가 1280*800인 태블릿이나 노트북에서는 스냅 기능을 사용할 수 없습니다.

개인적으로는 아직 한 가지 파악이 안된 부분이 있습니다. ARM 버전에도 데스크탑 모드가 존재하는데, ARM 버전의 데스크탑에서 작동하는 프로그램은 어떻게 만들 수 있는지 알려진 바가 없습니다. 현재까지 알려진 바에 의하면 ARM 버전의 MS Office는 메트로 UI가 아닌 데스크탑 모드에서 작동할 것이라고 합니다. 이 부분은 좀더 시간이 지나야 알 수 있을 듯 하네요.

4) Windows Store

드디어 Windows에도 마켓이 등장했습니다. Windows Store 역시 Metro UI 형태를 취하고 있으며 다음과 같이 생겼습니다. 참고로, Windows 8 개발자 프리뷰에서는 Windows Store에 들어갈 수 없었는데, Windows 8 컨슈머 프리뷰에서는 Windows Store에 들어갈 수 있습니다.

Windows Store에 들어가기 위해서는 MS의 Live.com 계정이 필요한데, Windows 8 설치 시 계정을 생성하거나 기존 계정을 연결할 수 있습니다. 이 부분은 iOS나 안드로이드와 비슷하다고 볼 수 있겠네요.

Windows Store 역시 메트로 UI를 사용하는데 각 항목이 일목요연하게 정리가 되어 있어서 사용성이 꽤 괜찮습니다.

다음은 실제 앱에 대한 화면입니다. Windows Store가 아직 베타라서 모두 무료 앱이거나 체험판만 등록되어 있습니다.

Windows Store는 기존 윈도우 개발자에게 새로운 가능성을 열어주는 기회의 땅이죠^^ Ojective C나 Java를 배우지 않고도 자기가 이미 알고 있는 기술가지고 돈을 벌 수 있게 된 겁니다. 게다가 Windows Store는 태블릿 뿐만 아니라 데스크탑에서도 사용할 수 있기 때문에 매우 큰 시장을 단기간에 구축할 수 있을 겁니다.

참고로, Metro Style App만이 Windows Store에 등록될 수 있습니다. 기존 데스크탑 프로그램을 그냥 등록할 수는 없어요^^;

Windows Store에는 앱스토어나 안드로이드 마켓과는 달리 트라이얼 시스템이 기본 지원됩니다. 기존 Shareware처럼 설치 후 며칠 동안만 사용할 수 있고, 그 이후에는 구입을 해야만 계속 사용할 수 있게 할 수 있습니다. 이런 트라이얼 시스템은 Windows 8에서 기본으로 제공되기 때문에 개발자가 따로 만들 필요가 없으니 참 편리하죠. 참고로, 다른 앱스토어에서는 트라이얼 시스템이 없으며 보통 앱 개발 업체들이 아무개 Lite 또는 아무개 Free 와 같은 이름으로 맛보기 전용 앱을 따로 만들어서 올립니다.

개발한 Metro Style App을 Windows Store에 등록하려면 Windows App Certification Kit을 이용하여 개발한 App을 서명한 후 Microsoft에 제출하면 심사 후 Store에 등록이 됩니다.

5) Live.com 기반의 클라우드 서비스

Windows 8 컨슈머 프리뷰부터는 설치 단계에서부터 Live.com 계정과 연동 설정을 할 수 있으며, iCloud처럼 클라우드 서비스를 사용할 수 있습니다. 사실, Windows 7에서도 Windows Live 필수 패키지를 설치하면 각 컴퓨터간의 데이터 동기화 기능을 사용할 수 있었는데, Windows 8에는 OS 차원에서 지원됩니다. 또한 SkyDrive도 연동되어 있어서 데스크탑과 태블릿 사이, 또는 데스크탑과 노트북 사이의 데이터 공유가 한결 쉬워졌습니다.

개발자 관점에서 좀더 말씀드리면, 이러한 클라우드 기능을 개발하는 메트로 스타일 앱에 쉽게 넣을 수 있도록 정교한 API가 같이 제공됩니다.

Windows 8 컨슈머 프리뷰 다운로드하기

Windows 8 컨슈머 프리뷰는 아래 링크에서 설치하실 수 있습니다.

http://windows.microsoft.com/ko-KR/windows-8/download

메트로 스타일 앱 개발을 위한 Visual Studio 2011 Express Beta는 아래 링크에서 다운로드하실 수 있습니다.

http://msdn.microsoft.com/ko-kr/windows/apps/br229516

물론, MSDN 구독자는 MSDN 사이트에서 다운로드하실 수도 있습니다.

참고로, Windows 8 컨슈머 프리뷰는 5개국어로 릴리즈되었는데, 이 중에 한국어는 포함되어 있지 않습니다. 하지만 한글 키보드를 선택할 수 있어서 기능 체험이나 개발에는 전혀 문제가 없습니다. 사실, 작년에 공개된 개발자 프리뷰에 비해서 훨씬 안정적으로 바뀌어서 실사용도 충분히 가능합니다^^

개발자에게 새로운 문이 열리다…

개인적으로 Windows 8은 데스크탑 OS와 태블릿 OS의 절묘한 조합이라고 말씀드리고 싶습니다. 우리가 기존에 해왔던 일들도 그대로 할 수 있으면서 여기에 태블릿 OS의 편리함과 사용자 경험이 더해짐으로써 보다 다양한 기기에서 보다 쉽고, 그리고 동일한 사용자 경험을 누릴 수 있게 된 것입니다. 특히 사용자 입력에 대한 반응이 매우 신속해서 기본적인 사용성도 대폭 향상되었습니다.

그리고… 개발자에게도 새로운 문이 열렸습니다. 단순히 Windows 8 용 프로그램을 개발하는 것뿐만 아니라 Windows Store를 통해 판매도 할 수 있게 된 것입니다. 아마도 올해 하반기 쯤에는 Windows 8 정식 버전이 발매될 것입니다. 그 동안 차근차근 Windows 8에 대해서 준비를 해놓는다면 남들보다 앞서가는 개발자가 될 수 있지 않을까 생각해봅니다^^

마지막으로, 개인적인 Windows 8 소감 한마디 한다면… OS만 바꿨을 뿐인데 컴퓨터 업그레이드를 한 느낌입니다.^^ 그만큼 윈도우 7보다 빠르며, 특히 부팅 속도는 예술이라고 할 수 있습니다. 그리고 윈도우에서 터치로 하는 Cut the Lope 참 재미있군요^^

다음 글에서는 Windows 8 앱 개발의 기초가 되는 WinRT에 대한 이야기와 함께 Windows 8 앱 개발 환경 구축과 관련된 이야기를 해보도록 하겠습니다.