윈도우 8, 무서운 드라이버와 궁합

최악의 궁합, 윈도우 8

윈도우를 여지껏 사용하면서 드라이버와 충돌이 나면 이런 참사가 발생하는지 처음 알았다. 아니, 이렇게 발생할 수도 있는 것 자체가 신기하다.

SONY VPCZ115 시리즈를 사용하는데 SONY 노트북은 전통적으로(?) 그래픽 드라이버를 새로운 운영체제에 맞게 업데이트 안해준다. 그렇다고 공식 NVIDIA 사이트에서 받아서 설치하면 좋겠지만, 설치가 안된다. 드라이버 sys 엎어쳐도 보고 별짓을 다 해봤지만…

어느 날, 이 광경을 보자마자 순간 멍~~~

[이미지] 윈도우 잠금 상태가 한 쪽 모니터에서 풀린 사진

위 이미지의 증거 샷은

  • 점심 시간이라 CTRL+ALT+DEL 키를 눌러서 윈도우를 잠궜다.
  • 윈도우 8이 설치된 노트북으로 외부 모니터를 연결하고 쓰고 있는 중이다.
  • 외부 모니터에는 원격 서버 연결해서 서비스 중인 서버를 관리 중이었다.
  • 점심 먹고 오니, 저런 꼴이 되었다.
  • 외부 모니터는 마우스 커서도 움직인다.!

그 이후, 몇 일에 한 번 꼴로 계속 발생해서, 노트북 집 구석에 모셔다 놓았다.

윈도우 8 문제인가? 드라이버 문제인가?

사실, 그래픽 드라이버 문제인지 확실히 증명할 수는 없다. 증명해야 할 이유도 없거니와…

내 SONY 노트북 모델이 공식적으로 윈도우 8 드라이버를 공급해 주지 않기 때문에, 하위 호환성에 의지해서 모든 드라이버를 설치했다. 노트북 사용자는 어느 정도 어쩔 수 없지 않던가.

예전에 쓰던 노트북에 윈도우 XP 드라이버를 악평으로 악명 높은 윈도우 비스타(Windows Vista) 에 설치해서 잘 쓰던 때와 비교하면 윈도우 8은 너무나 관대하다.

드라이버가 안맞아서, 되지 말아야 할 것을, 얼마나 관대한지 잠금 상태에서도 모니터를 활짝 보여주니 말이다.

사용자 입장에서 SONY 노트북에선 드라이버 공식 업데이트가 없고, 윈도우 8에서는 하위 드라이버 호환성을 버리면, 뭐 노트북 갖다 버리라고? (이럴 때 윈도우 8 안쓰면 되겠지만 개발 환경 맞춰야 하는 경우가 대부분이라)

맥킨토시(Macintosh)의 OSX 운영체제와 리눅스 X-Windows 를 쓰면서 이런 적은 없었다. 물론 수 십년을 윈도우를 쓰면서 이런 적은 처음이다.

그나마 다행인 것이 일할 때 빼면(젠장 비주얼 스튜디오) 윈도우를 구동할 일도 없지만, 켤 때마다 윈도우를 써야 하는 내 상황에 그저 쓴 웃음만 나온다.

용도를 알 수 없는 매트로 시작 화면

또 하나, 방금 내가 뭘 설치하긴 했는데, 뭘 설치했지? 하고 매트로 시작 화면에 가서 찾아보려 해도 찾을 수 없다. (설치한 프로그램 이름이랑 개발사를 대충 보고 설치해서 기억이 안났다)

깨알 같은 아이콘과 텍스트로 어찌 찾는단 말인가. 찾다 찾다 못 찾아 다시 웹 사이트 방문해서 다시 다운로드 받고, 다시 설치하는 것이 훨씬 빨랐다.

또, 자주 쓰지 않는, 아주 가끔 돌리는 디스크 청소 프로그램이나 Disk Inventory X 같은 디스크를 스캔하여 비주얼로 보여주는 유틸리티는 반드시 이름을 외워야 한다. 못 외우면 깨알 같은 아이콘과 텍스트로 뒤져야 한다.

이런 경험을 여러 번 하게 되니 정신적인 안정을 위해 Star8 이라는 시작 메뉴 소프트웨어를 $4.99 주고 샀다.

다가오는 윈도우 8.1도 시작 메뉴로 장난질을 한다던데… 시작 메뉴의 부활이라고 하는데, 시작 메뉴 클릭하면 매트로 시작 화면으로 가는 바로 가기 버튼이란다. (ZDNET 및 IT 미디어 매체에 의하면…)

물론 매트로에서 재미를 즐기는 분들도 있겠지만, 그저 필자에게는 데스크탑으로 가기 위해 봐야하는 스팸 화면 정도? 윈도우 키를 잘못 누르기라도 하면 스팸 화면으로…

'O/S > Windows 8' 카테고리의 다른 글

윈도우 8, 무서운 드라이버와 궁합  (0) 2013.06.05
윈도우 8, 반토막짜리 WinRT와 WinRT SDK  (1) 2012.10.30
Posted by 땡초 POWERUMC

댓글을 달아 주세요

윈도우 8, 뜨거운 감자 [1/2]-무엇이 사용자를 화나게 하는가?
윈도우 8, 뜨거운 감자 [2/2]-혁신은 언제나 리스크를 안고 간다


 필자는 마이크로소프트의 윈도우 8 전략을 조금은 이해한다고 생각한다. 물론 다른 사람들이 볼 때 자신의 의견과 다르거나 필자가 어느 한 쪽으로 편향이 되어 보일 수 있겠다. 하지만, 필자는 진정으로 마이크로소프트의 소프트웨어들을 사랑한다. 필자는 리눅스를 초보이기 때문에 리눅스에 대한 어떠한 피드백을 줄 것도 없거니와 큰 불만도 없다. 리눅스 커널을 뿌리깊게 공부해 본적도 없고 리눅스 전용 소프트웨어를 개발해 본적도 없다. 윈도우 8이라는 뜨거운 감자에 대해 이런 글을 쓰는 것은 그 만큼 윈도우 운영체제를 아낀다는 반증이라고 생각해 주기 바란다.

윈도우 8은 새로운 혁신이다. 일단 현재의 불편함은 윈도우 8 RTM 출시 후 냉정한 사용자의 평가에 맡길 수 밖에 없으므로 이야기를 전환해 보자. 윈도우 8은 우리에게 무슨 메시지를 전하고 싶어하는가?

   

윈도우 8 운영체제가 곧 클라우드이며, 운영체제의 상식의 한계점을 넘었다.

운영체제(OS-Operating System)는 알다시피 '하드웨어와 사용자를 연결'하는 가장 추상화된 레벨이다. 그리고 지금까지의 윈도우 운영체제는 운영체제의 본연의 역할에 충실했다. 하지만, 이제는 윈도우 8 운영체제는 SaaS(Software as a Services)와 통합이 되었다. 운영체제가 SaaS와 통합하기 위해 운영체제는 인터넷이라는 거대한 네트워크와 베플(Best Friend)이 되어야 한다. 최종 사용자에게 소프트웨어를 위한 어떤 서비스를 제공하기 위해 인터넷이라는 매개체를 이용해야 한다. 이로써 운영체제는 운영체제의 기본 역할을 넘어 고객의 요구와 눈높이에 맞추는 소프트웨어 서비스를 제공하는 서비스 프로바이더(Services Provider)가 되었다.

 

   

아마 윈도우 8 운영체제 덕분에 언젠가는 운영체제(OS)의 의미가 더 큰 의미로 사전에 추가될 것이다. '운영체제란? 하드웨어와 소프트웨어, 인터넷을 아울러 최종 사용자에게 가치 창조형 서비스를 제공하는 소프트웨어' 라고 말이다.

   

윈도우 8, 하이브리드 N 스크린

하이브리드 N 스크린. 필자가 이렇게 이름을 지어보았다. N 스크린의 의미는 '폐쇄적인 1~2~3 스크린을 확장하여 N개의 디바이스, N개의 스크린, 그리고 개방형 서비스' 라고 정의할 수 있다. N 스크린을 실현하기 위해 플랫폼의 구축이 반드시 필요하였다. 왜냐하면 N 스크린의 개방형 서비스를 실현하기 위해서는 클라우드라는 규모있는 대규모 플랫폼으로 PaaS(Platform as a Services), IaaS(Infra as a Service), SaaS(Software as a Services)가 제공하는 서비스가 N 스크린의 서비스 품질을 결정한다고 해도 과언이 아니다. 

예를 들어, 일부 2세대 휴대폰이나 최신 스마트폰에서 제공하는 DMB로 TV를 시청하는 서비스를 상상해보자. DMB 전파를 위해 별도 채널을 확보해야 하고, 기존의 기지국에서 DMB 전파를 송신할 수 있는 장치 등이 필요할 수 있다. 혹여 위성 DMB 서비스를 이용하려면 서비스 제공자는 위성이 필요하다는 것이다. DMB 시청에 필요한 모든 서비스를 하나의 플랫폼으로 구축되어 있다고 이해해도 될 것 같다.

 

   

다시 이야기의 원점으로 돌아가서, 필자가 지적한 윈도우 8 의 불편한 것 중의 하나가 '시작' 버튼이 없어진 것이다. 이것을 상징적인 의미로 바꾸어 표현하면 윈도우 8은 더 이상 데스크탑 전용 운영체제가 아니며, 데스크탑이 메인이 아니라는 것이다. 그렇다고 윈도우 8이 테블릿이나 모바일을 메인으로 하는 운영체제도 아니다. 필자가 이름지어 본 '하이브리드 N 스크린'을 기억하는가. 상상해 보자. 윈도우 8 운영체제는 N 명의 사람들이 어깨동무를 하고 동그랗게 모여있는 모습을 하늘에서 내려다본 그 모습이 윈도우 8의 모습이다. 

윈도우 8을 현재의 모습보다 미래지향적으로 바라본다면 매우 파괴력 있는 운영체제임은 틀림이 없다. 대신, 그 리스크(Risks)도 안고 가야 하는 것도 윈도우 8의 운명이다. 미래를 향한 파괴력인지, 스스로 자멸하는 파괴력인지 마이크로소프트의 몫이라고 할 수 있겠다. 그렇기 때문에 마이크로소프트의 윈도우 8은 전세계의 윈도우 사용자와 함께 어깨동무를 하고 나아가야 할 소셜틱한 운영체제임이 틀림이 없다.

   

   

윈도우 8, 그리고 …

필자가 윈도우 8에 대해 볼멘 소리를 하다 말고 윈도우 8의 미래지향적인 메시지를 얘기하는 것도 매우 재미있다고 느껴진다. 필자는 윈도우 8의 양날의 검이라고 생각한다. 마이크로소프트가 수 많은 사용자의 피드백을 무시하고 내놓은 윈도우 8 운영체제에 대해 냉혹한 평가를 받아야 한다.

그리고 윈도우 8이라는 뜨거운 감자는 쉽게 식지 않을 것 같다. 이제는 마이크로소프트의 몫이다. 맛있게 속이 알차게 익은 감자가 될지, 다 타버리고 재만 남는 감자가 될지는 아직 아무도 섣불리 판단하기 이르다. 다만, 우리 사용자 입장에서는 윈도우 8 이 발전하고 좋아져야 하는 것은 당연한 것이다. 사용자가 싫어하는 것을 하지 않거나 보완하는 것이 진정으로 위하는 것이라는 모 기업의 TV 기업 이미지 광고의 의미도 곱씹어 보아야 할 것이다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 개발자 2012.08.20 14:18 Address Modify/Delete Reply

    잘 봤습니다. MS 를 사랑하는 개발자로서 공감이 가네요. 빌 돌아와줘요~~~

  2. 지나가는이 2012.08.21 22:09 Address Modify/Delete Reply

    마우스 오른쪽 클릭하면 시작버튼 누를때 나오는 것과 비슷한 것이 뜹니다.
    이전보다 기본적으로 필요한 것들이 들어가 있고 더 좋은데요..
    사용해 보면 windows8 굉장히 유용합니다.
    과거에는 안티였지만 windows8로 그나마 변하느낙 부다 좋은징조로 받아들이는데.
    mvc분들은 과거에는 이해할수 없이 찬양하더니 windows8 나오니 비판적이신듯..ㅋㅋ

    • NikooRn 2012.11.27 10:51 Address Modify/Delete

      문제는 오른쪽 클릭을 해도 윈도우7에서 하던 많은 것들이 안되는게 문제죠.. 특히 시작화면의 앱에서는 오른쪽 클릭을 해도 앱에서 다양하게 이루어지던 기능들이 많이 빠져있고 계정도 일반계정이라 힘드네요...

  3. çatı 2012.08.31 02:46 Address Modify/Delete Reply

    아주 좋아요. 감사

윈도우 8, 뜨거운 감자 [1/2]-무엇이 사용자를 화나게 하는가?
윈도우 8, 뜨거운 감자 [2/2]-혁신은 언제나 리스크를 안고 간다


윈도우 8, 마이크로소프트의 가장 최신 버전의 운영체제이다. 2009년 10월 23일, 윈도우 비스타의 부진을 딛고 윈도우 7을 출시하였고, 이는 현재까지도 마이크로소프트의 성공한 운영체제로 평가 받고 있다. 특히 윈도우 7은 윈도우 비스타에 비해 월등히 빠른 성능과 글래스 스타일(Glass Style) 효과인 반투명한 윈도우 창이 윈도우 운영체제에 매우 조화롭게 녹아 들었다. 필자 또한 윈도우 XP 이후 가장 오랫동안 사용한 운영체제가 바로 윈도우 7이기도 하다.

 

   

(본 아티클에서는 어휘의 자연스러움을 위해 용어는 영문 또는 한글을 혼합하여 사용하였음을 양해 바란다. 그리고 '메트로 스타일' 용어에 대해 마이크로소프트의 공식적인 지침이 없으므로 '메트로 스타일'과 '윈도우 8 스타일' 등의 용어를 혼용하여 사용한다.)

   

윈도우 8을 논하기 전, 윈도우 비스타와 윈도우 7부터...

윈도우 비스타와 윈도우 7, 무엇 때문에 운영체제의 성패를 좌우하였는가? 사용자에게 보여지는 글래스 스타일의 UI 효과도 똑같았고, 사용자 계정 컨트롤(UAC, User Account Control)의 강력한 사용자 측면의 보안 강화와 같은 기능들은 대부분이 유사하였다. 특히 외관상 전문가가 아니면 구분하지 못할 정도로 두 운영체제 모두 아름다운 사용자 인터페이스를 가졌다.

 

   

그렇다면 무엇이 윈도우 비스타를 추락시켰나? 큰 맥락만 짚고 넘어가보자. (단, 개발 입장에서는 더 큰 어려움이 많았지만, 이 아티클에서는 주요한 사용자 측면만 요약한다)

  • 첫 번째로 운영체제의 하위 호환성이다. 게임 유저들이 게임을 하기 위해, 그리고 윈도우 응용 프로그램 또한 기업용 응용 프로그램들이 윈도우 XP 사용을 유지하였거나 윈도우 XP로 다운그레이드를 하였다. 그 이유는 하위 호환성이 완벽하게 보장이 되지 않았으며 보안 프로그램(특히 기업용)이나 시스템 레벨에서 동작하는 소프트웨어(드라이버 등)의 마이크로소프트 파트너에서도 이에 발 빠르게 대응하지 않은 문제도 있었다.
  • 두 번째, 운영체제 성능이다. 사용자가 운영체제를 사용하기 위해 다양한 동작을 하게 되는데, 그 중에서 응용 프로그램을 실행하고, 인터넷을 즐기기 위해 브라우저를 실행하고, 사용자가 체감적으로 느끼는 반응 속도가 윈도우 XP에 비해 성능이 현저하게 떨어졌다. (응용 프로그램 버전, 브라우저 버전에 대한 성능 문제는 이 아티클에서는 논외로 한다)
  • 세 번째, 사용자를 괴롭히는 사용자 계정 컨트롤(UAC). 윈도우 XP에서는 대부분 사용자 계정을 최고 관리자 계정(Administrators) 범주에 포함이 되었으나, 윈도우 7에서는 사용자 계정은 관리자 계정이 아닌 일반 계정이다. 그래서 응용 프로그램 등이 사용자 시스템의 리소스에 접근하기 위해 사용자에게 허가를 받아 임시로 계정 권한을 관리자로 승격시키는 것이 주요 컨셉트이다. 이로써 악성코드나 바이러스는 자기은폐나 자기복제를 하기 위해 사용자 시스템의 리소스에 접근할 수 있는 권한이 근본적으로 차단이 되었다. 하지만, 이런 권한 승격을 위해 사용자에게 묻는 횟수가 너무하다 싶을 정도로 많았기 때문에 사용자에게 분노를 느끼게 할 정도였다.

   

그렇다면, 왜 윈도우 7이 성공했는지에 대한 대답은 간단하다. 위의 세 가지의 문제들이 모두 깔끔하게 해결되었기 때문에, 더 이상 사용자는 윈도우 XP에 머물 이유가 없었다. 윈도우 7의 보안 향상이라는 점 때문에 기업에서도 적극적으로 관심을 보이며, 국내 굴지의 대기업에서 전사적으로, 일부는 점진적으로 직원들이 사용하는 컴퓨터의 운영체제를 윈도우 XP에서 윈도우 7으로 업그레이드를 하였다. (즉, 윈도우 비스타는 건너 뛰었다) 필자가 다니던 전 회사인 N모 게임사도 2011년 3000여명의 전사적 차원에서 윈도우 7으로 교체하였고, 운영체제의 표준으로 자리잡았다.

   

   

윈도우 8, 윈도우 비스타를 방불케 하는 뜨거운 감자!

이 아티클을 쓰는 시점, 윈도우 8은 이미 제조사에게 제공되는 RTM 버전이 공급이 되었다. 윈도우 8이 공식적으로 출시가 되면 많은 제조사에서 생산되는 데스크탑 컴퓨터, 노트북, 울트라북, 테블릿 기기에 윈도우 8이 기본 탑재가 되어 출시될 것이다.

   



무엇이 윈도우 8을 뜨거운 감자로 만들었는가?

(단, 이 아티클에서는 윈도우 8을 데스크탑 운영체제 관점에서 바라볼 것이며, 테블렛은 특별히 언급하지 않는 한 논외로 한다.)

   

  • 시작 버튼
    윈도우 8에는 '시작' 버튼이 사라졌다. 별것도 아닌 '시작' 버튼이 무엇이 문제가 되는지 잠시 되짚어보자. 마이크로소프트는 윈도우 운영체제가 부팅되면 '바탕화면'이 사용자에게 가장 먼저 보이는 UI이다. 최초 이 텅 빈 UI에 사용자는 윈도우라는 운영체제를 배우지도 않아도 사용할 수 있는 방법이 필요했고, 그 획기적인 방법이 '시작' 버튼이다. 10년이 훨씬 넘는 긴 세월 동안 윈도우는 '시작' 버튼으로 사용자가 사용하기 쉬운 운영체제가 되었다.
    10년도 더 이전에는 '시작' 버튼이라는 용어 자체가 획기적이었다. 당시의 대부분의 소프트웨어는 각 기능의 접근을 위해 '메뉴'라는 것을 구현하였다. 기술적으로 이 메뉴 구현을 '풀다운 메뉴(Pull-Down Menu)' 라는 기법을 사용하였고 이 기법은 2진-트리와 비슷한 자료구조의 형태이다. '풀다운 메뉴' 단어에서 알 수 있듯이 최상위 메뉴가 하위 서브 셋 메뉴를 갖는 획기적인 방법이었다. 모든 소프트웨어들은 GUI(Graphics User Interface)의 유무에 상관없이 함께 필수적으로 구현하는 것이 '풀다운 메뉴'였다. 윈도우에서 '시작' 버튼은 단순히 메뉴라는 기능적인 관점을 넘어 사용자의 경험(UX)에 즉각적으로 향상된 사용자 경험을 제공해 주었다. '시작' 버튼의 기능은 단순히 메뉴가 펼쳐지는 UI에서 점차적으로 많은 개선이 이루어졌고, 현재의 윈도우 7의 모습으로 발전한 획기적인 바로 그것이 '시작' 버튼이다.



    윈도우 8의 '시작' 버튼이 사라지는 것에 대해 많은 찬반 토론이 있지만, '시작' 버튼의 그 기원 자체를 인정하고 시작해야 한다. 그깟 '시작' 버튼이 윈도우를 대표하고 윈도우라는 운영체제를 연상케 하는 핵심적인 요소임이 분명하다는 것을 인정해야 한다. 그렇지 않으면 '시작' 버튼의 유무에 대한 논의 자체가 불필요하다. 최근 '시작' 기능 자체가 매우 많은 기능을 담당하고 사용 방법도 복잡해짐에 따라 '시작' 버튼에 대한 혁신이 필요하다는 관점에서 '시작' 버튼이 없어지는 것을 환영하는 사람도 있다. 반면, 필자와 같이 '시작' 버튼이 반드시 필요하다는 사람들은 '시작' 버튼이 사라지는 것을 상당히 우려하고 있고, 가장 큰 불만 중 하나이다. '시작' 버튼이야말로 윈도우의 기능과 소프트웨어 자원의 집합체를 바로 '시작' 버튼에 모든 것을 담아낸 최고의 사용자 경험이었다.
    초기 버전의 윈도우 8 CTP(Consumer Preview와 상응 또는 그 전후) 버전에는 레지스트리를 통해 '시작' 버튼을 활성/비활성 할 수 있는 방법이라도 제공이 되었지만, 윈도우 8 RTM 버전에는 이 방법마저도 제공해주지 않는다.

    즉, '시작' 버튼이 사라진 것을 받아들여야 한다. 이로써 사용자 관점에서 기존 통합된 UX가 분산되어 버렸다. 과연 '시작' 버튼을 제거한 것이 향상된 사용자 경험인지에 대해서는 추후에 냉철한 평가가 필요할 것이다.
    • 시작 버튼의 모든 프로그램 항목들은 메트로 시작화면으로...
    • 시작 버튼의 제어판과 컴퓨터 관리는 바탕화면에서 제스처를 통해 슬라이드 메뉴를 활성화시키는 것으로...
    • 시작 버튼의 시스템 종료도 제스처를 통한 슬라이드 메뉴를 활성화시키는 것으로 ...
    • 시작 버튼의 윈도우 내의 자원의 검색은 매트로 시작 화면의 검색 기능으로...
    • 키보드의 Windows 키는 '시작' 버튼의 시작 메뉴 활성화 기능에서 매트로 시작화면<->데스크탑 바탕화면 전환으로…

    결국 '시작' 버튼을 제거하여 '시작' 버튼이 제공하는 기능을 분산시켜 버렸기 때문에, 클릭 1~2번으로 해결할 수 있는 것들을 클릭+제스처를 이용하여 좀 더 어려운 동선을 그려야 한다. 그리고 사용자들이 '시작'만 보고도 윈도우를 쉽게 사용할 수 있었지만, 윈도우 8 사용자는 무엇을 보고 '시작'해야 할까?

       


   

메트로 스타일 (윈도우8 스타일 사용자 인터페이스 및 사용자 경험)

마이크로소프트가 정식으로 '메트로(Metro)'라는 단어를 사용한 것이 윈도우 폰 7에서 시작되었다. 필자는 이 메트로 스타일의 UI를 보았을 때 감탄을 하였다. 전혀 마이크로소프트의 발상이라고 할 수 없을 정도로 퀄리티가 높은 사용자 인터페이스였다. 마이크로소프트가 출시하는 대부분의 소프트웨어들은 전형적인 마이크로소프트 스타일의 '콘솔(Console)' 형태의 사용자 인터페이스이다. 수십년 동안 '콘솔' 화면에 익숙해진 것인지 메트로 스타일의 사용자 인터페이스는 그야말로 획기적일 보일 수 밖에 없었다.
윈도우 폰 7이 다른 국가에 비해 국내 출시가 매우 늦어진 탓인지 메트로 UI에 대해 이런저런 불만의 목소리는 거의 없었다. 하지만, 윈도우 폰 7은 국내 출시되고 얼마 되지 않아 상당한 불만들이 쏟아져 나오기 시작했다. 폴더 기능의 부재는 윈도우 폰 7의 불만 중에 하나이다. 그 흔한 모바일 운영체제에서 지원하는 폴더 기능을 제공하지 않는다. 수 많은 앱들 중에 비슷한 앱을 묶어 폴더에 담기도 하고, 자주 사용하는 기능을 폴더링하여 접근성이 좋은 첫 페이지에 놓기도 한다. 하지만, 당연하다고 생각하는 폴더 기능조차 윈도우 폰 7에서는 제공되지 않는다.

   

폴더 기능의 부재 때문에, 윈도우 폰 7에서는 앱이 많아질수록 앱 관리가 힘들어졌다. 앱을 찾기 위해 무한 스크롤을 해야 하고, 어느 앱이 어느 앱인지 분간하기도 쉽지 않다. 아이콘으로 앱을 구분할 수 없고, 수 많은 네모 칸의 이 색깔 ,아니면 저 색깔의 앱들을 무슨 수로 빠르게 찾을 수 있었겠는가. (필자는 검색 기능을 말하는 것이 아닌, 육안으로 인식하는 것에 대한 것임을 유의하기 바란다)

 

   

이미 윈도우 폰 7의 메트로 스타일의 폴더 기능의 부재로 겪게 되는 불편함은 여전히 윈도우 8에서 개선되지 않았다. 정말 필자가 느끼는 것 중의 가장 불편한 것이라면 첫 째도 폴더 기능이고, 둘 째도 폴더 기능이다. 윈도우 8의 메트로 바탕 화면에서 단색의 네모 칸의 앱 아이콘은 도저히 앱들을 분간할 수 없을 지경이다. 그나마 검색 모드로 전환해야 같은 분류의 앱들이 어느 카테고리인지 표시는 해주지만 사실 눈에 잘 띄지도 않는다. 그리고 원하는 곳으로 이동할 수도 없기 때문에 사실상 더 불편해 졌다고 느껴진다.

   

데스크탑 응용 프로그램을 찾으려면 메트로 바탕화면으로 가야 한다.

필자의 입장에서 가장 이해가 되지 않는 부분이다. 왜 데스크탑 응용 프로그램을 실행하기 위해 메트로 바탕화면으로 이동해야 하는가. 윈도우 8에서는 데스크탑 응용 프로그램을 찾기 위해서 메트로 바탕화면으로 이동해야 한다. 그리고 데스크탑 응용 프로그램 아이콘을 클릭하면 다시 데스크탑 바탕화면으로 이동하고 응용 프로그램이 실행된다. 예를 들자면, 필자가 게임을 실행하기 위해서 '메트로 바탕화면 이동 -> 게임 응용 프로그램을 스크롤하며 찾기 -> 게임 응용 프로그램 클릭 -> 데스크탑 바탕화면으로 강제 전환됨 -> 게임 실행됨'. 몇 달 동안 윈도우 8을 사용해왔지만 여전히 비효율적인 방법이라고 느끼며 불편하다.

   

 

데스크탑 응용 프로그램은 데스크탑에서 찾고... 메트로 앱은 메트로 바탕화면에서 찾아야 한다. 하지만 윈도우 8은 모든 응용 프로그램과 앱들을 메트로 바탕화면에 몰아 넣었다. 필자는 노트북 또는 데스크탑을 사용할 때 메트로 앱을 사용할 일이 없고, 메트로 바탕화면으로 가야 할 일도 없다. (물론 사용자마다 틀리겠지만...). 필자는 메트로 앱 중 뉴스 앱보다 데스크탑에서 브라우저로 뉴스를 보는 것이 빠르고 편하다. 더불어 체감적으로 브라우저 랜더링에 비해 메트로 앱의 랜더링은 너무 느리다. 필자가 사용하는 데스크탑 경험은 바로 이것이다. 즉, 데스크탑 경험에서는 메트로 시작 화면이 필요 없다. 물론, 재미있는 메트로 게임 앱이 나온다면 기분 전환 삼에 사용할 의향도 있다. 하지만 필자의 데스크탑 경험에서는 메트로 시작 화면과 앱들은 어떠한 사용자 경험의 향상도 없고, 데스크탑과 메트로 바탕화면을 왔다 갔다 하는 것이 오히려 불편하다.
물론, 데스크탑 응용 프로그램을 데스크탑 바탕화면에 바로가기 아이콘을 생성하거나 테스크바(Task Bar)의 핀(Pin)으로 고정할 수 있는 편리한 방법도 제공해 준다. 하지만 이것은 필자가 언급하는 근본적인 해결책이 아니므로 논외로 하겠다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 아크몬드 2012.08.10 09:07 Address Modify/Delete Reply

    우와.. 재밌는데요..ㅋㅋ

    저도 그동안 생각하고 있었던 점을 정리해서 올려보렵니다.
    간만에 열혈 윈도우 포스팅 본 것 같아 아련하네요. 이런 글 본지가 언젠지...

    잘 보고 갑니다.

  2. TY LEE 2012.09.08 03:45 Address Modify/Delete Reply

    필자는 개발자 출신인가.. 엠에스가 전략을 바꾼건 시대의 트랜드를 읽어냈다는 것이고 그건 잘한것이라 본다. 트랜드란게 곧 대중의 요구다. 몇몇 엔지니어 비유맞추기보다는 대중을 선택한것이지. 전문지식이 없어 메트로니 콘솔이니.. 정확한 의미는 모르겠다만 필자의 글의 문맥상 대략은 그 뜻이 그려지는데, MS가 이런 인터페이스를 시도한건 논리적인 UI에서 직관적인 UI로 넘어가려는것이다. 미래에 모든 디바이스들의 유저인터페이스는 이런 환경으로 바뀔것이다. 스마트폰을 사용하는데 사용설명서를 읽고 쓰는 사람이 있던가 (어르신들은 좀 논외로하자-필자식 꼬리자르기) 그 스마트폰에 시작버튼이 있던가. 직관적으로 찾아가는 것이다. 그것이 훨씬 재미와 감동을 준다. 오히려 그런 손동작과 눈동자의 움직임으로 좌뇌보다 우뇌를 사용하게 된다. 폴더타령하고 체계적인 분류를 원하는 분들은 좀 이해가 안갈수도 있다. 우리의 직관을 믿으시라. 아직 더 많이 바뀌어야하지만, 시작버튼이 없어진것은 기계가 좀더 인간과 가까워지고 생명력을 얻었다는 신호탄이다. 이방법으로 해당 앱이나 기타목표물을 찾아가는 그 과정에서 불편함을 느낀다면 그것은 디자인이 잘못된것이지, 근본적인 이 접근방법이 잘못된것이 아니다. 그런부분은 애플이 한수위인듯하다.

  3. 현천이 2012.10.05 23:02 Address Modify/Delete Reply

    와 진짜 잘 짚었음. 설치한지 5분만에 시작을 대체할 방법을 찾기 시작하고, 10분만에 바탕화면에 가는 방법을 찾아야 함. 정말 망작 필이 솔솔 남.

    윈도우 7의 성공요소와 비스타의 실패 요인도 정확하게 짚었음.
    개인적으로, 이번 8과 비스타의 최대 망작요소는 항상 마소의 고질적인 문제 - 개발한 프로그램을 사용하도록 강요된 환경 - 에서 출발함. 메트로 기능은 잘 쓰면 매우 좋지만, 사용하라고 강요하는 환경에서는 너무나 부담스러움.

  4. 하두호 2012.11.07 15:07 Address Modify/Delete Reply

    와 진짜 제가 하고 싶은 말들만 쏙쏙 적어 두셨네요 윈8 나쁘진 않은데 본문같은 단점들은 정말 이해하기 힘든 부분입니다

본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다. 그리고 현재 필자는 NCSOFT에 재직하지 않음을 참고하기 바랍니다.


[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012
[월간 마이크로소프트 5월호 특집기사] C++ 매트로 앱 개발을 위한 C++/CX 언어
[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012를 마치며


엄준일 – 현재 NCSOFT에 재직 중이며, Microsoft ALM MVP와 한국 Visual Studio 팀과 블로그를 운영하고 있다.. 주로 .NET 기술을 전파하고 있고, 마이크로소프트가 지향하는 소프트웨어 개발 프로세스와 통합 및 테스팅 분야를 4년 동안 공부해왔다. 그 외에 CodePlex 오픈 소스 사이트를 통해 프레임워크, 툴 그리고 라이브러리 등을 공개하여 운영 중이다.

 

 


C++ 매트로 앱 개발 준비 사항

C++ 매트로 앱을 개발하기 위해 C++ 개발자는 당장 개발하기 앞서 몇 가지 숙지해야 할 지식과 개념들이 있다. 그리 어려운 것들은 아니지만, 이것을 모르고 접근하려고 하면 어디서부터 시작해야 할지 매우 혼란스러울 것이다. 필자는 과거에 C와 PASCAL을 주로 사용하였고, PC통신이라는 커뮤니케이션을 통해 여러 가지 액션 게임과 대전 게임, 어드벤처 게임을 개발하여 공개해 본 적은 있으나, 최근에 사용되는 C++과 DirectX로 개발해 본 경험은 전무하다. 대신 C라는 언어와 윈도우8이라는 공통 분모를 바탕으로 최대한 C++ 개발자에게 매트로 앱을 쉽게 개발하기 위해 설명할 것이다.

 

C++/CX 란?

첫 번째 준비사항은, C++ 매트로 앱 개발의 위해 C++/CX를 이해해야 한다. C++/CX는 C++ Components Extension(C++ 컴포넌트 확장)이라는 의미로 그 문법은 C++/CLI와 매우 흡사하다. C++/CLI의 대부분은 .NET의 MSIL 형태의 목적 파일로 컴파일 되기 때문에, C++/CLI 응용 프로그램이 동작하기 위해서는 .NET Framework가 설치가 되어야 했었다. 이는 곧, C++/CLI의 gcnew 객체는 .NET 가비지컬렉션의 대상이 되기 때문에 .NET에 매우 가까운 구조였다. 반면, C++/CX은 간단하게 정의하자면 간결한 COM 프로그래밍 언어이다. 그 문법이 C++/CLI와 같지만, 완벽하게 네이티브 형태로 컴파일 된다. 이 말은 즉, .NET Framework이 필요가 없고, .NET 가비지컬렉션의 대상이 되지도 않는다.

앱 개발에 필수 런타임인 WinRT(Windows Runtime)를 이용하여 구현을 하기 위해선 IInspectable 인터페이스를 구현해야 한다. COM 프로그래밍에 직간접적으로 IUnknown 인터페이스를 구현하는 것과 같다. 왜냐하면 IInspectable 인터페이스는 IUnknwon 인터페이스를 상속하기 때문이다.

IInspectable 인터페이스는 곧 COM 개념과 같다. 컴포넌트를 다양한 언어와 공유하고 통합할 수 있는데 WinRT 프로그래밍에서 C#, VB.NET, 그리고 JavaScript에서 IInspectable을 구현하는 객체를 사용할 수 있게 된다. (단, IInspectable 인터페이스는 컴파일러에 의해 구현될 수 있다)

MIDL_INTERFACE("AF86E2E0-B12D-4c6a-9C5A-D7AA65101E90")

IInspectable : public IUnknown    

{

public:

virtual HRESULT STDMETHODCALLTYPE GetIids(

/* [out] */ __RPC__out ULONG *iidCount,

/* [size_is][size_is][out] */ __RPC__deref_out_ecount_full_opt(*iidCount) IID **iids) = 0;

 

virtual HRESULT STDMETHODCALLTYPE GetRuntimeClassName(

/* [out] */ __RPC__deref_out_opt HSTRING *className) = 0;

 

virtual HRESULT STDMETHODCALLTYPE GetTrustLevel(

/* [out] */ __RPC__out TrustLevel *trustLevel) = 0;

 

};

Code 1 IInspectable 인터페이스 정의

COM 프로그래밍 중 가장 빈번하게 사용되는 것 중 하나가 참조 카운팅인데, ^ 기호로 참조 카운팅을 관리하는 개체를 ref new로 인스턴스를 생성하면 더 이상 귀찮은 AddRef와 Release메서드를 호출해 줄 필요가 없다. 예를 들어, Platform::WeakReference 등을 이용하여 생성된 객체에 대해 수명 관리를 위임할 수 있는 방법들이 제공된다.

정리해보면, WRL(Windows Runtime Library)가 C#, VB.NET, JavaScript로 개발할 수 있는 환경을 제공하는 것이 바로 COM이며, 이를 쉽게 개발할 수 있는 언어가 C++/CX인 것이다.

 

프로퍼티(Property) 사용

C++/CX는 프로퍼티를 사용할 수 있는 키워드를 제공한다. C++/CX 프로퍼티는 .NET 프로퍼티와 내부적으로 똑같이 동작한다. 이 프로퍼티는 컴파일 시에 get/set 메서드를 자동으로 생성해 준다. 프로퍼티는 읽기 전용/쓰기 전용, 그리고 이 두 가지 모두를 지원하도록 구현할 수 있다.

이 프로퍼티는 매트로 앱을 개발하면서 상당히 자주 만나게 될 것이다. 왜냐하면 XAML과 함께 앱을 구현하면서 바인딩(Binding) 개념에 프로퍼티 구현이 필수적이기 때문이다. 그래서 XAML 바인딩에서 INotifyPropertyChanged 인터페이스를 구현하여 데이터 모델과 바인딩된 데이터간에 데이터 변경에 대해 알려줌으로써 1-way 또는 2-ways 바인딩을 사용한다.

#include "pch.h"

 

public ref class Person sealed

{

private:

    Platform::String^ name;

    int age;

 

public:

    Person(Platform::String^ name)

    {

        this->name = name;

    }

 

    // 읽기 전용 프로퍼티

    property Platform::String^ Name

    {

        Platform::String^ get() { return this->name; }

    }

 

    // 읽기 쓰기 프로퍼티

    property int Age

    {

        int get() { return this->age; }

        void set(int age)

        {

            if( age <=0 ) throw ref new Platform::InvalidArgumentException();

 

            this->age = age;

        }

    }

};

Code 2 C++/CX 프로퍼티

이 프로퍼티는 내부적으로 생성되는 get/set 매서드를 사용하는 것이 아니라 선언된 프로퍼티를 마치 맴버 변수처럼 사용이 가능하다. 일반적인 C++ 에서는 get/set 메서드를 구현하는 방식으로 person->setName(L"Junil Um"); 이런 코드를 이상 사용하지 않는다.

아래의 코드와 같이 프로퍼티로 선언한 이름으로 직접 엑세스할 수 있다.

Person^ person = ref new Person("Junil Um");

person->Age = 20;

 

필자는 매크로를 사용하여 좀 더 빠르고 쉽게 프로퍼티를 선언하여 사용하는 방식을 권하고 싶다. 아래의 코드는 프로퍼티의 get 또는 set, get/set 을 매크로로 대체한 것이다.

#define __PROPERTY_GET_FUNC(TYPE, NAME) TYPE get() { return m_##NAME; }

#define __PROPERTY_SET_FUNC(TYPE, NAME) void set(TYPE value) { m_##NAME = value; }

#define DEFINE_PROPERTY(TYPE, TYPENAME) property TYPE TYPENAME

#define __PROPERTY(TYPE, NAME, IMPL) \

private: \

    TYPE m_##NAME; \

public: \

    DEFINE_PROPERTY(TYPE, NAME) \

    { \

    IMPL \

    } \

 

#define PROPERTY_GET(TYPE, NAME) __PROPERTY(TYPE, NAME, __PROPERTY_GET_FUNC(TYPE, NAME))

#define PROPERTY_SET(TYPE, NAME) __PROPERTY(TYPE, NAME, __PROPERTY_SET_FUNC(TYPE, NAME))

#define PROPERTY(TYPE, NAME) __PROPERTY(TYPE, NAME, __PROPERTY_GET_FUNC(TYPE, NAME) __PROPERTY_SET_FUNC(TYPE, NAME))

 

 

안전한 포인터 사용, 대리자(Delegate)

포인터 함수는 C++에서 흔히 사용되지만, WinRT 프로그래밍에서는 직접적인 포인터 연산이 그리 좋은 코드는 아닐 수 있다. 이유는 간단하다. WinRT APIs (내장 라이브러리)들이 인자 값으로 포인터가 아닌 대리자(Delegate)를 즐겨 전달 받는다. 그리고 이벤트(Events) 프로그래밍에서 대리자를 공통적으로 사용한다.

void ShowMessageBox(Platform::String^ str)

{

    auto dialog = ref new Windows::UI::Popups::MessageDialog(str);

    dialog->ShowAsync();

}

 

 

void App::OnLaunched(LaunchActivatedEventArgs^ pArgs)

{

    auto ptr = &ShowMessageBox;

 

    ptr("Hello Metro App with C++");

}

Code 3 함수 포인터

.NET 에서는 대리자(Delegate)를 안전한 포인터 함수라고 정의한다. 포인터 함수를 사용하든, 대리자를 사용하든 결과는 똑같지만 이왕이면 안전하게 제어할 수 있는 대리자를 사용하라는 것이다. 사실, .NET 에서 대리자는 일반적인 클래스(Class)와 똑같이 취급한다. 대리자는 컴파일이 되면 일반적인 클래스로 정의되기 때문이다.

어쨌든 위의 포인터 함수를 대리자로 바꾸어보면 다음과 같다.

delegate void ShowMessageBoxHandler(Platform::String^ str);

void ShowMessageBox(Platform::String^ str)

{

    auto dialog = ref new Windows::UI::Popups::MessageDialog(str);

    dialog->ShowAsync();

}

 

void BlankPage::OnNavigatedTo(NavigationEventArgs^ e)

{

    auto msghandler = ref new ShowMessageBoxHandler(&ShowMessageBox);

    msghandler("Hello Metro App with C++");

}

Code 4 C++/CX 대리자

C++/CX 매트로 만들기 첫 걸음

이제 매트로 앱 코드를 작성하고 이해하기 위한 어느 정도의 준비는 된 것 같다. 매트로 앱은 처음 앱의 처음 진입점이 App클래스의 OnLaunched 메서드이다.

void App::OnLaunched(LaunchActivatedEventArgs^ pArgs)

{

    auto sampleData = ref new SampleDataSource();

 

    auto rootFrame = ref new Frame();

    TypeName pageType = { GroupedItemsPage::typeid->FullName, TypeKind::Metadata };

    rootFrame->Navigate(pageType, sampleData->ItemGroups);

 

    Window::Current->Content = rootFrame;

    Window::Current->Activate();

}

Code 5 앱 진입점인 App 클래스

 

위의 코드의 LaunchActivatedEventArgs 인자는 main 함수의 인자 값이라고 생각해도 좋다. 단지 다른 점을 찾는다면 LaunchActivatedEventArgs 객체는 COM Proxy 개체로써, 앱 실행시 인자 값 등을 전달 받을 수 있다. .

이곳에서 앱의 초기화를 수행한 후에 Frame->Navigate 메서드로 사용자 인터페이스를 가지고 있는 화면으로 이동한다. C#,VB.NET 그리고 C++ 매트로 앱은 XAML(Extensible Application Markup Language)을 이용한다. 처음 .NET Framework 3.0에서 WPF 응용 프로그램에서 XAML을 주로 사용하였으나, .NET Framework 4.0에 와서는 별도의 구성요소로 분리가 되었고, 현 버전에서는 완전히 독립된 컴포넌트로 구성되었다. XML은 언어의 분류상 객체지향언어로 구분하게 되는데 XAML은 객체지향언어와 상호작용이 가능하여 그 확장의 가능성이 무한대로 볼 수 있다.

매트로 앱과 친해지기 위해서는 C++/CX도 이해해야겠지만, XAML도 항상 벗처럼 삼아야 한다. XML 프로그래밍에 익숙한 독자라면 XAML이 어렵지 않을 것이다. XML 프로그래밍은 책 몇 권의 분량으로도 모두 담지 못할 것이다. 그리고 XAML 또한 책 한 권 분량 이상으로 그 내용이 방대하므로 더 자세한 내용은 MSDN을 통해 천천히 익히길 바란다.

Figure 1 Blend for Visual Studio 2012

 

XAML을 처음부터 거부감을 느낄 필요는 없다. 당장은 앱을 만들기 위해 디자인을 해야 하는데, Blend for Visual Studio 2012 (과거 Expression Blend) 라는 디자인 도구가 있다. XAML은 이 도구를 이용하여 디자인을 하면 개발자도 쉽게 사용자 인터페이스를 완성할 수 있다.

지면으로 모든 것을 설명하지 못하니, 다음의 링크를 반드시 확인하기 바란다.

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

이 링크에서 매트로 앱을 만들기 위한 개발 도구 및 SDK와 샘플 앱을 C#, C++, JavaScript로 구현해 놓았고, 마이크로소프트가 제공하는 품질 좋은 디자인 파일도 있다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다. 그리고 현재 필자는 NCSOFT에 재직하지 않음을 참고하기 바랍니다.


[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012
[월간 마이크로소프트 5월호 특집기사] C++ 매트로 앱 개발을 위한 C++/CX 언어
[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012를 마치며

 

엄준일 – 현재 NCSOFT에 재직 중이며, Microsoft ALM MVP와 한국 Visual Studio 팀과 블로그를 운영하고 있다.. 주로 .NET 기술을 전파하고 있고, 마이크로소프트가 지향하는 소프트웨어 개발 프로세스와 통합 및 테스팅 분야를 4년 동안 공부해왔다. 그 외에 CodePlex 오픈 소스 사이트를 통해 프레임워크, 툴 그리고 라이브러리 등을 공개하여 운영 중이다.



 

성큼 다가온 Visual Studio 2012

Microsoft의 대표적인 통합 개발 도구인 Visual Studio 2012의 성장세가 무척 빠르다. 지난 10년전 .NET 플랫폼과 함께 대표적인 개발 도구인 Visual Studio.NET (2003버전)를 내놓았다. 그 때의 시간이 바로 엊그제 같은데 그 이후 Visual Studio 2005, 2008, 2010을 지나 Visual Studio 2012베타 버전을 필자가 사용하고 있으니, 짧은 10년동안 Microsoft를 비롯하여 개발 언어, 개발 툴, 이 모든 것이 굉장히 많이 변해 왔음을 새삼 다시 느껴진다. 이제 Windows 8라는 새로운 운영체제가 기다리고 있다. 그리고 이를 빛내줄 Visual Studio 2012.

 

성큼 다가온 Visual Studio 2012과 그 발자취

Visual Studio 2012를 먼저 논하기 전에 Visual Studio가 어떤 발자취를 남기며 발전해 왔는지 간단하게 살펴보는 것도 독자들이 Visual Studio 2012를 이해할 수 있는 좋은 방법이라고 생각한다. 물론 짧고 간단하게 모든 것을 설명할 수는 없지만, 전반적인 특징만으로 그 동안 개발 트랜드가 어떻게 바뀌었고, 시장의 요구 사항이 어떻게 변화하여 왔는지 한 눈에 알 수 있는 가장 좋은 방법이라고 생각한다.

 

Microsoft의 첫 번째 진정한 통합 제품으로 평가 받는 제품이 Visual Studio.NET (2003버전)이다. Microsoft의 전략적인 언어인 C# 1.0과 VB.NET(v7.0)이 .NET 개발의 대표적인 언어가 되었다. 기존의 VB를 세련된 객체지향 언어로 탈바꿈하면서 이전의 VB개발자들에게 .NET 개발의 문턱을 낮출 수 있는 매우 좋은 사례이기도 하다. (단, Visual Studio 2002는 논외로 하겠다)

이 이전의 개발도구는 하나의 도구에서는 하나의 언어로만 개발을 할 수 있었고, 개발 툴 역시 그 언어에 매우 종속적이고, 다른 언어로 전환하려면 이전의 개발 도구와 개발 경험 역시 많은 부분을 새로 습득해야 했다. 특히 J# 이라고 하는 Java 언어와 라이브러리를 제공하였는데, Java 개발자들을 .NET 플랫폼 안으로 끌어안기 위한 매우 독특한 사례이기도 하다. 실제로 J#은 웬만한 Java 소스 코드를 변경 없이 .NET 목적 파일로 컴파일 할 수 있었다.

Visual Studio는 하나의 개발 도구를 통해 여러 가지 언어를 선택하여 웹 응용 프로그램, 윈도우 응용 프로그램, 모바일 개발, XML, XML 웹 서비스를 개발을 통합하고, 여기에 포함되는 .NET Framework 1.0은 응용 프로그램을 빌드하고 실행하는 구성요소로서, ADO.NET, ASP.NET, Windows Forms 등을 포함하는 .NET Framework 클래스 라이브러리와 CLR(Common Language Runtime-공용 언어 런타임)을 제공, 이 CLR 을 통해 공통된 API 집합을 만들어 다양한 언어간의 상속, 오류 처리, 디버깅이 가능하며 개발자들은 사용하려는 언어를 자유롭게 선택할 수 있게 되었다.

이 후, Windows Server 2003 제품에 표준으로 탑재하여 .NET Framework의 확산에 큰 공을 이루게 되었고, 실제로 엔터프라이즈 시장에서 이 버전을 기준으로 많은 기업용 시스템에 도입이 되었다. 현재까지도 이 버전을 기준으로 운영이 되는 기업용 시스템이 상당수 존재하고 있을 정도이다.

 

때는 2005년. Visual Studio 2005버전은 파격 그 자체다. 여기에 포함된 런타임인 ..NET Framework 2.0은 이전 .NET Framework 1.x에 사용된 코드를 대부분 갈아 엎었을 정도이다. .NET Framework의 뼛속까지 변신한 것이다. ASP.NET 2.0, ADO.NET 2.0, Windows Forms 2.0, C# 2.0 과 같이 '~2.0' 이라는 버전 번호를 붙였고, 많은 기능이 보완되고 확장되었다. .NET Framework 2.0 의 주요 컴포넌트들은 더 이상 .NET Framework 1.1 에 의존하지 않게 되었으며, .NET Framework 2.0 은 .NET Framework 3.5 SP1 까지 .NET Framework의 모태가 된다.

모든 것이 생소할 정도로 많은 변신이 있었는데, 그 중에서 C#과 VB.NET 언어가 대표적이다. Boxing(박싱), Unboxing(언박싱)의 반복적인 캐스팅(Casting) 의 비효율을 개선하고, 보다 객체지향적인 코드 품질을 생산할 수 있는 제네릭(Generic)이 등장하였다. 이와 함께 .NET Framework 클래스 라이브러리에 다수의 제네릭(Generic) 클래스가 추가되었다. 개발 툴도 많은 변화가 있었는데, IDE 자체의 외관도 많이 변했고, 개발 툴의 내부적인 코드에서 변화가 왔고 다양한 내부 인터페이스가 추가되었다. Visual Studio의 솔루션 탐색기에서 흔히 사용하는 '솔루션 폴더'도 이때 등장하였다.

그리고, 이 제품의 버전부터 Visual Studio Team Suite + Team Foundation Server 의 제품을 조합하여 Visual Studio Team System(VSTS) 라는 새로운 개발 패러다임을 .NET 에서도 지원하게 되었다. VSTS 를 통해 ALM(Application Lifecycle Management-애플케이션 수명 주기 관리) 을 수행할 수 있게 되었으며, IT 조직의 비지니스 전반의 생산성을 향상 시키고, 사람과 개발 조직의 변화를 가져다 주는 시초가 되었다.

 

.NET Framework 3.0은 새로운 개발 도구와 출시되지 않았다. 2005년 중순 Windows Vista 운영체제가 출시되면서 이에 대응하는 라이브러리가 포함이 되었다. 함께 새로운 기술도 대거 포함이 되었는데, 그 중에서 대표적으로 꼽으라고 하면 WPF와 WCF이다. XAML(Extensible Application Markup Language) 과 함께 WPF 의 출연으로 UX(User Experience) 의 시대 흐름에 진입하게 되었다. 또한, WCF는 여러 가지의 분산 통신 기술이 통합되었다. 이전의 Remoting, XML Web Services, MSMQ 등이 하나의 WCF 컴포넌트에서 제공하게 됨으로써 Messaging Model 기반으로 통합할 수 있게 되었다.

 


 

 

때는 2007년, 또 한번의 메이저 급 업데이트였다 언어적으로 LINQ라는 새로운 녀석 때문이다. LINQ(Language Integrated Query) 라는 이름에서 알 수 있듯이 익숙한 SQL Query 문법과 유사하여 객체 탐색에 있어 효율성이 매우 높아졌고, 그 성능도 일일이 손으로 짠 코드보다 더 빠른 경우가 있다. 이 LINQ의 기반이 되는 람다식(Lambda Expression), 익명 타입(Anonymous Type), 확장 메서드(Extension Methods)의 언어적인 새로운 스팩이 한데 아우러져 LINQ를 구성한다. XML객체, DataSet, 파일 시스템, 컬렉션 등 모든 대상이 LINQ 쿼리식의 대상이 된다. 이에 영향을 받아 JavaScript와 Java 언어에 영향을 주어 LINQ와 유사한 프레임워크가 등장하였지만, .NET 과 같이 언어적으로 통합이 되지 않았다. 마치 Method Chaining 패턴을 이용한 라이브러리로 분류된다.

이 밖에 정말 헤아릴 수 없을 정도의 많은 진보가 있었다. 개발 도구와 개발 언어, 그리고 .NET 플랫폼의 기술이 발전한다는 것은 분명 매우 좋은 일이겠지만 아마 이 시기부터 많은 .NET 개발자들이 Microsoft의 기술 발전을 따라가기 벅차했었다.

 


2010년에 이르러, Visual Studio 2010버전이 출시되었다. 너무 빠른 .NET 기술의 발전의 탓일까, 이 때는 언어와 .NET Framework보다는 Visual Studio라는 개발 툴에 가장 초점이 맞추어졌다. 그 중 핵심 키워드라고 할 수 있는 것 3가지는 "시각화", "디버깅", "프로세스" 일 것이다. (필자의 의견이므로 Microsoft가 추구했던 것과는 다를 수 있다.) 이 세 가지의 핵심 키워드는 시각화, 협업에 있어 코드의 이해를 좀 더 쉽게, 그리고 복잡한 데이터를 한 눈에 알 기 쉽게… 디버깅-디버깅 시 데이터의 수집이 혁신적으로 발전하였고, 물리적으로 분리된 티어(Tier)간에 데이터 수집… 프로세스, 애자일을 강조하고 애자일한 통합 프로세스를 개발 툴에 제공.

.NET Framework 4.0은 .NET Framework 2.0기반이 아닌 새로운 프레임워크로 구성되었고, 멀티코어 처리를 위해 강력한 병렬 처리 라이브러리(Parallel Libraries)가 있다. 또, 동적 언어 런타임(Dynamic Language Runtime)으로 정적 형식과 동적 형식의 경계를 허물었으며, 루비(Ruby), Lisp, JavaScript, 파이썬(Phython), PHP와 같은 동적 언어와 상호 운용이 가능하다. 예를 들자면, C# 언어로 파이썬 개체와 상호 연동이 가능하다는 것이다.

 

  

제품의 버전 / 특징

2002년

  • Visual Studio .NET 2002 / .NET Framework 1.0 
    첫 통합 개발 환경 
    발매 당초의 제품명은 ' Visual Studio .NET 
  • C# 1.0 / Visual Basic .NET (7.0) 
    C# 은 마이크로소프트의 새로운 객체 지향 언어 
    Visual Basic 도 객체지향 언어

2003년

  • Visual Studio .NET 2003 / .NET Framework 1.1 (5월) 
  • C# 1.1 / Visual Basic .NET (7.1) 
    모두 버전 업 
  • Windows Server 2003 
    .NET Framework 1.1 표준 탑재

2005년

  • Visual Studio 2005 / .NET Framework 2.0 (12월) 
    ClickOnce 배포 
    제네릭 클래스 도입 
    ASP.NET 2.0, ADO.NET 2.0, Windows Form 2.0 
    리팩토링 기능 / 코드 스니펫 
    무료 Express Edition (C#, VB, C++) 
  • C# 2.0 / Visual Basic 2005 (8.0) 
    제네릭 대응 
  • Visual Studio 2005 Team System 
  • SQL Server 2005 지원

2006년

  • .NET Framework 3.0 (11월) 
    코어 부분은 .NET Framework 2.0 그대로 
    WPF(Windows Presentation Foundation) 
    WCF(Windows Communication Foundation) 
    WF(Windows Workflow Foundation) 
    CardSpace 
  • Windows Vista 
    .NET Framework 3.0 기본 탑재

2007년

  • Visual Studio 2005 Service Pack 1 (6월) 
  • ASP.NET AJAX 1.0 (추가 모듈) 
    AJAX Web Application 개발이 용이 
  • Expression Blend 
    Expression Studio 첫 제품 
    WPF 어플케이션의 GUI 구축
  • Visual Studio 2008 / .NET Framework 3.5 (11월 경) 
    개발 코드명 'Orcas' 
    WPF 의 GUI 설계 가능 
    Javascript 디버그 기능 및 IntelliSense 
    ASP.NET AJAX 표준 탑재 
    .NET Framework 2.0, 3.0, 3.5 선택 가능 
  • C# 3.0 / Visual Basic 2008 (9.0) 
    LINQ 기능 
  • SQL Server 2008 
  • Windows Server 2008 
  • Visual Studio Team System 2008

2008년

  • Visual Studio 2008 SP1 / .NET Framework SP1 
    ASP.NET Dynamic Data 
    ADO.NET Entity Framework / Data Services (Astoria) 
    WCF Atom Pub Services 
    클라이언트 프로파일(Client Profile) 
  • VSTS 
    Windows Server 2008 지원 
    SQL Server 2008 지원 
    성능 향상 및 개선 
  • Visual Studio SDK 1.1 (SP1) 
    Visual Studio Shell 재배포 패키지 경량화 
    DSL 출력 미리보기 등… 
  • Visual C++ 2008 
    오피스 리본 스타일 Interface 
    고급 GUI 컨트롤 등…

2010년

  • 사용자 친화적인 Visual Studio IDE
  • 코드 탐색 강화
  • 개발 툴에서 다양한 .NET Framework 개발 환경 제공
  • JavaScript 언어 개발 환경 강화
  • 다양한 플랫폼 지원
    • 64 Bit Mixed-Mode 디버깅
    • Managed 와 Mixed-Mode 의 Minidump 디버깅
  • Historical Debugger
    • 디버그 내용을 기록, 재생
  • 프로젝트 관리 및 프로세스 통합

 

 

Visual Studio 2012와 함께 매트로 앱 개발

Visual Studio 2012의 가장 큰 핵심은 바로 Windows 8 운영체제이다. Windows 8은 매트로 응용프로그램이라는 새로운 환경과 WinRT(Windows Runtime)인 새로운 런타임을 제공한다 그리고 Visual Studio 2012는 Windows 8 운영체제에 가장 최적화된 개발 툴이다. 독자들은 또 새로운 것을 배워야 하나라고 한숨을 쉴 수도 있을 것이다. 하지만 섣부른 독자들의 판단은 잠시 후에 하기 바란다. 왜냐하면 Windows 8 개발은 새로운 환경이면서도 새로운 환경이 아닐 수도 있다. Windows 8 운영체제를 사용하고 WinRT APIs 집합을 사용하는 것 이외에는 아무것도 변한 것이 없기 때문이다. 단지 바뀐 것은 여기에서 개발된 응용 프로그램은 데스크탑 컴퓨터, 테블릿, 모바일 환경 모두 실행되고 배포할 수 있다는 것이다.

최근 개발 환경을 엿보자면 C++을 사용하는 네이티브 개발과, NET에서 지원하는 C#과 같은 관리 언어, 그리고 웹 개발에 필요한 HTML과 JavaScript, 이 중에 단 한가지 기술 영역만 있으면 Windows 8 매트로 응용 프로그램 개발 준비는 끝이라는 것이다. 우리가 흔히 사용하는 스마트 폰을 보면 알 수 있듯이, 개발자는 단지 '위치 정보', '화면의 표현 방법', '데이터 연동', 그리고 스마트 폰을 가로로 볼 때와 세로로 볼 때와 같은 일상적인 기능을 제공하는 APIs를 익히기만 하면 된다. 기존에 Visual Studio를 사용하여 개발해 본 독자라면 그 만큼 진입 장벽이 낮다.

윈도우 폰7 개발처럼 테블릿 시뮬레이터가 제공이 된다. Windows 8 테블릿이 지원하는 대부분의 모든 기능을 이 시뮬레이터에서 테스트를 해 볼 수 있다. 윈도우 폰7 개발처럼 반드시 시뮬레이터가 필요한 것은 아니다. 실제 시뮬레이션이 필요 없다면 곧바로 로컬 데스크 탑에서 매트로 앱을 실행해 볼 수 있다.

Figure 1 Visual Studio 2012 매트로 앱 실행 및 디버깅

 

Figure 2 시뮬레이터 실행 환경

 

더불어 Visual Studio에서 제공하던 성능 측정 도구와 코드 정적 검사를 매트로 앱 개발 환경에서도 그대로 이용할 수 있다. 이는 곧 Visual Studio 2012이 Windows 8 개발에 가장 최적화가 되었다는 의미가 된다.

 

Figure 3 매트로 앱 성능 측정 및 진단

 

간략하게 나마 Visual Studio 2012과 Windows 8 개발에 대해 살펴보았다. 필자가 얘기한 것처럼 개발자에게 있어 새로운 환경이지만, 반대로 전혀 새롭지 않기도 하다. Visual Studio로 간단한 앱을 만들 수 있는 실력이라면 곧바로 Windows 8 매트로 앱을 개발할 수 있을 정도로 진입 장벽이 낮다. 물론, 좀 더 기술적이거나 독창적이고 예쁜 앱을 만드는 것은 더 많은 노력이 필요하다. 단지, 앱 개발자는 자신만의 앱 개발에만 집중하면 된다.

 

Figure 4 Windows 8 개발에서 배포까지

 

Visual Studio 2012과 함께 매트로 환경의 게임 개발

데스크 탑과 테블릿, 그리고 모바일 앱 중에서 단연 게임이 빠질 수 없다. 매트로 환경에서 게임 개발은 아직 시장이 포화되지 않은 장르이다. 그 만큼 게임 개발자에게 있어 매트로 환경에서 게임 개발은 매우 유혹적이기도 하다. 더 반가운 소식은 매트로 게임 개발에 필요한 지식은 게임 개발자에게 익숙한 C++언어와 DirectX다. DirectX를 이용하여 2D, 3D 게임을 개발할 수 있다.

얼마 전까지만 해도 Microsoft가 전략적으로 게임 개발을 지원하던 프레임워크인 XNA를 매트로 게임 개발에 지원하지 않는다. 대신 기존 게임 개발자에게 기존 개발 환경을 그대로 이어갈 수 있는 DirectX를 선택한 것이다.

Figure 5 DirectX 3D 샘플

Figure 6 DirectX 2D 샘플

 

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

협정 세계시(UTC) 시간으로 2012/06/01, Windows 8 Release Preview와 Visual Studio 2012 Release Candidate 버전이 MSDN Subscription을 통해 공개가 되었다. 이번 버전에는 Windows 8 Consumer Preview(CP) 버전과 Visual Studio 11 Beta 버전에 비해 잔존하는 버그가 상당히 줄어들었다. Windows 8 CP 버전을 쓰면서 가장 사용하기 불편했던 점은 데스크톱 응용 프로그램들이 이유 없이 멈추고, Visual Studio 11 Beta 의 IDE가 자주 뻗어 버리는 현상이 눈에 띄게 사라졌다. 더불어 이 두 가지 Release의 성능도 눈에 띄게 향상되었다. 마이크로소프트의 많은 노고에 박수를 보내고 싶다.

   

Windows 8 Release Preview와 Visual Studio 2012 Release Candidate 피드백

Windows 8 Release Preview에서 조금 변화를 원한다면, Metro 시작화면에는 Metro 응용 프로그램만 나열되었으면 한다. 그리고 폴더 기능이나 같은 카테고리 앱끼리 정렬할 수 있으면 더 좋겠다. 데스크톱 응용 프로그램과 Metro 앱이 마구 섞여 있으니 검색 기능 없이 찾기가 힘들다.

   

Visual Studio 2012 Release Candidate 버전에서는 아이콘의 컬러를 흑백에서 컬러로 바꾸었다고는 하지만, 필자 개인적으로는 솔루션 탐색기부터 산만해진 것은 변함이 없다. 컬러를 넣으려면 넣고 빼려면 빼지 말이다. 아이콘 컬러를 넣어달라는 수많은 사용자 피드백에도 불구하고 또 이렇게 산만해진 컬러링은 정말 최악이다.

결론은 둘 중 하나인 것 같다 사용자 피드백을 씹는다거나, 사용자 피드백이 좀 약했다던가...

   

   

Windows 8 SDK, 이빨 빠진 호랑이 격!

자! 이제 본론으로 들어가서 Windows 8 SDK(Software Development Kit)과 Visual Studio 2012에 매우 중요한 것이 변경되었다. 이미 pcworld.com 에서 Release 제품이 나오기 이전에 예고를 했다. Windows 8 SDK 에는 Command-Line 과 관련된 대부분의 실행 파일들이 포함되지 않는다. Windows 8 SDK는 이 링크에서 다운로드 받을 수 있다.

   

위의 Windows 8 SDK 링크를 참고하면 다음과 같은 문구를 찾을 수 있다. 이번 SDK가 DirectX SDK와 통합된 것은 그다지 관심이 없다. 다만, 빌드와 관련된 모든 Command-Line(명령줄)을 제거했다는 것이 중요하다.

   

Windows 8 SDK를 이용하여 단독으로 아무것도 할 수 없다. 일반적으로 마이크로소프트에서 제공하는 Software Development Kit(SDK)에는 개발에 필요한 대부분의 기능들이 포함되어 있다. 가장 중요한 것이 SDK 에 포함되어 있는 Compiler(컴파일러)이다. Visual C++, Visual C#, Visual Basic.NET 으로 작성된 소스 코드를 컴파일하기 위해서는 Compiler가 필요한데, Windows 8 SDK 에서는 제공해 주지 않는다. 그리고, 복잡한 워크플로우로 빌드되는 최근의 개발 환경에서 MSBuild.exe가 필요하다. MSBuild.exe는 인증 작업, 링크 작업, 리소스 병합 등 복잡한 작업을 순차적으로 처리해주는 매우 훌륭한 도구이다. Windows 8 SDK 에서는 이것도 빠져있다.

   

이제 좀 현실감이 올 것이다. 가장 먼저 타격을 받는 것이 바로 통합 빌드 시스템이다. 빌드 서버에 Visual Studio 2012를 설치하지 않으면 Windows 8 Metro App이나 .NET Framework 4.5, 그리고 최신 버전의 Visual C++ 소스 코드를 컴파일하거나 배포할 수 없다. 이는 좀 더 복잡해지는 라이선스 정책과도 교묘해진다. 일반적으로 Visual Studio의 라이선스는 개발자당 1 Copy의 Per User 라이선스이다. 그렇다면 빌드 서버에서 빌드를 하기 위해 Visual Studio를 설치했다면, 이는 Per User 라이선스를 적용 받는 것일까?

   

물론, 무료로 사용할 수 있는 Visual Studio 2012 Express 버전이 있다. 무료이고 상용으로 사용해도 제약이 없는 버전이지만, 제품 자체가 매우 최소한의 기능만 제공한다. Visual Studio Gallery 웹 사이트와 Visual Studio Extension Manager(확장 관리자)에서 제공하는 확장 기능을 사용할 수 없다. (단, Templates(템플릿), ToolBox(툴박스)와 관련된 것들만 수동으로 설치가 가능하다). 협업이나 형상 관리를 위해 SVN Source Control Provider(SVN 소스 제어 기능)나 Team Explorer(팀 탐색기)도 설치되지 않는다. 교육용으로는 적합할 지 모르겠으나, 실제로 기업 현장의 필드에서 사용하기엔 있으나 마나...

   

다시 원점으로 돌아가서 Visual Studio 2012과 .NET Framework 4.5의 새로운 기능을 살펴보자.

   

필자가 어림 잡아 새롭다거나 눈에 띄는 Features를 아래와 같이 아주 간단하게 정리해보았고, 나름대로 간략한 소감을 적어본다.

  • Visual Studio 2012
    • 매트로 앱 개발 - Visual Studio 2012는 매트로 앱 개발을 위한 툴 그 이상 이하도 아니다.
    • C++ Editor 개선 - 개선이 되었더라도 3rd-party 제품인 Visual Assist 를 $99 에 사서 쓰는 것이 더 좋다.
    • Graphics Tools - AutoDesk, Pixel Shader를 만들고 수정하기 편리해졌다. 그런데 이런 기능은 사용하기 늘 부족하기 때문에 NVIDIA Parallel Nsight 2.1 같은걸 쓰는 것이 이로울 것이다. 항상 느끼는 것이지만, 만들다가 만 Features가 Visual Studio에는 너무 많다.
  • .NET Framework 4.5
    • Portable Class Libraries - 마이크로소프트 BCL Team이 Visual Studio 2010 버전으로 공개했다. 그다지 새롭지 않다.
    • Parallel Computing - 가려웠던 부분을 상당부분 긁어줄 것 같다. Parallel 라이브러리에는 찬사를 보내고 싶다.

   

이 외에는 대부분이 성능적인 개선과 기능적으로 보강한 것들이 대부분이다.

   

   

이제 대략적인 결론이 나온다. 매트로 앱만 개발하기 위해서 굳이 Visual Studio 2012를 사용하는 것은 비용적으로 비효율적일지도 모른다. 매트로 앱은 Visual Studio 2012 Express for Windows 8 을 쓰고, 그 외의 시스템적으로 변경사항을 최소화하기 위해 Visual Studio 2010이나 Visual Studio 2008을 사용하고, 더불어 Windows 7 SDK and .NET Framework 4 또는 Windows 7 SDK and .NET Framework 3.5 SP1 을 사용하는 것이 좋겠다. 그리고 필자는 이번 SDK 에 Compiler 배포를 모두 제거한 것을 이해하기 힘들다. 사실상 .NET 환경의 개발자 또는 기업을 대상으로 돈 내놓으라는 것과 다를 바 없다. 그리고 마이크로소프트의 기술은 점점 발전하는데, 기술 이외의 것들은 퇴보적인 경향을 보인다.

   

참고로 다시 한번 상기하자면, 아래는 Windows 7 SDK for .NET Framework 4의 설치 화면이다. 이번 Windows 8 SDK 에는 아래의 대부분이 빠진다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 네모 2012.06.07 00:19 Address Modify/Delete Reply

    컬러부분은. 계속 수정중이라 하니 좀더 지켜봐야 할 듯 합니다.
    기본테마는 더 밝아졌으면 좋겠고 다크는 괜찮더군요. 하지만 사용하는 시간이 줄어드니 무료로 버텨보고 그 돈으로 맥이나 알아봐야 겠네요.

  2. 네모 2012.06.07 00:20 Address Modify/Delete Reply

    컬러부분은. 계속 수정중이라 하니 좀더 지켜봐야 할 듯 합니다.
    기본테마는 더 밝아졌으면 좋겠고 다크는 괜찮더군요. 하지만 사용하는 시간이 줄어드니 무료로 버텨보고 그 돈으로 맥이나 알아봐야 겠네요.

지난 2012년 02월 29일, Windows 8 Consumer Preview 와 Visual Studio 11 Beta 버전이 공개가 되었습니다. 그 중 Windows 8 의 가장 큰 특징이라고 하면 WinRT(Windows Runtime)을 이용하여 Metro 응용 프로그램을 만들 수 있는 것이죠. 이전 Windows 7까지 Win32 API 를 이용하여 데스크탑 응용 프로그램을 만들었습니다만, Windows 8 에 와서는 이전 Win32 환경과 새로운 WinRT 환경에서 개발을 할 수 있습니다.

   

더 자세한 정보를 원하시면 다음의 MSDN 링크를 통해 확인하시기 바랍니다.

http://msdn.microsoft.com/en-us/library/bb386063(v=vs.110).aspx

   

쉽게 WinRT는 Metro Style App를 구동하기 위한 API 집합들이며, Win32의 Function APIs 가 아닌, 좀 더 세련되고 객체지향적으로 다듬은 차세대 윈도우 런타임이라고 생각하셔도 됩니다.

   

   

Visual Studio 11 은 Windows 8 의 Metro Style App 을 개발하기 위해 개발 템플릿을 지원해 줍니다. (프로젝트 템플릿 같은 그런 것들이죠). 그럼 Visual Studio 11 에서 제공하는 Metro Style App 의 템플릿은 어떤 것을 지원하는지 한번 볼까요?

   

분할 응용 프로그램

분할 응용 프로그램 템플릿은 사용자 지정하여 2열 보기에서 항목과 항목 세부 정보로 된 목록을 보기 위한 앱을 만들 수 있는 Metro 스타일 앱의 주요 기반이 됩니다. 이 보기에서 사용자는 항목 간에 빠르게 전환할 수 있으며 목록을 동적으로 업데이트할 수도 있습니다. 예를 들어 뉴스 읽기 프로그램, 스포츠 득점 앱, 전자 메일 앱 등이 있습니다. 이 프로젝트 템플릿은 Metro 스타일 앱에 권장되는 탐색 모델을 사용합니다.

표 형태 응용 프로그램

표 형태 응용 프로그램 템플릿을 사용하여 Metro 스타일 앱을 만드는 것이 좋습니다. 이 템플릿을 사용자 지정하여 사용자가 범주 검색을 통해 완전히 빠져드는 콘텐츠를 찾는 앱을 만들 수 있습니다. 예를 들면 쇼핑 앱, 뉴스 앱, 사진 또는 동영상 앱이 있습니다. 이 프로젝트 템플릿은 Metro 스타일 앱에 권장되는 탐색 모델을 사용합니다.

탐색 응용 프로그램

이 JavaScript 템플릿에는 기본 탐색, 앱 바탕 화면 도구 모음(앱 바) 및 표 형태 응용 프로그램과 분할 응용 프로그램 템플릿에서 사용되는 미디어 모드 기반 레이아웃이 제공됩니다. 탐색 템플릿에는 최소 페이지 조각 하나만 포함되어 있으며, 페이지 조각을 손쉽게 추가할 수 있습니다. 그런 다음 콘텐츠를 추가할 수 있습니다. 이 프로젝트 템플릿은 Metro 스타일 앱에 권장되는 탐색 모델을 사용합니다.

고정 레이아웃 응용 프로그램

이 JavaScript 템플릿은 콘텐츠가 고정 뷰포트에 맞게 되어 있다는 점을 제외하고 빈 응용 프로그램 템플릿과 동일한 최소한의 Metro 스타일 앱을 제공합니다. JavaScript에서 개발하는 대부분의 게임 앱에 이 프로젝트 템플릿을 권장합니다

DirectX 응용 프로그램

이 C++ 템플릿은 Metro 스타일 게임 개발에 사용할 수 있습니다.

   

Visual Studio 11 C# 언어에서 제공하는 Metro Style App 템플릿

   

Visual Studio 11 JavaScript 언어로 제공되는 Metro Style App 템플릿

특이하게도 JavaScript 언어로 제공되는 템플릿에만 고정 레이아웃(Fixed Layout) 템플릿을 지원하는군요.

   

Visual Studio 11 C++ 언어에서 제공하는 Metro Style App 템플릿

   

   

템플릿 샘플

각각 템플릿이 어떻게 구성되었는지 보기로 한 참에, 각 언어별로 제공되는 템플릿을 생성하여 Windows 8 에서 실행해 보았습니다.

   

JavaScript 템플릿으로 만든 Metro Style App Sample

   

   

C# 템플릿으로 만든 Metro Style App Sample

   

   

C++ 템플릿으로 만든 Metro Style App Sample

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요