팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #1

필자는 얼마 전에 다음과 같은 글을 썼다. TFS를 그다지 좋아하지 않는 분의 글을 검색 중에 우연히 찾게 되었고, 이에 대해 필자의 의견을 남긴 적이 있다.

개인적인 의견에 필자가 반박한 것이기도 했지만, 필자는 기능적인 면에서 반박을 한 것이라 상대방의 마음이 상할지 몰랐으나, 다시 돌이켜보면 미안한 맘이 계속 든다.

과거 필자는 MS Visual Studio ALM MVP 로서 이 제품을 써야할 이유를 말할 수 있었으나, 지금은 중간적인 입장에서 TFS를 쓰지 말아야 하는 진짜 이유도 써보고 싶었다. 최근 필자는 TFS 이외의 다양한 제품을 접하면서 TFS를 쓰지 말아야 하는 이유에 대해 더욱 확신이 들었다.

우리나라에는 전문가가 없다

우리나라에 팀 파운데이션 서버(Team Foundation Server) 전문가가 없다. 그러므로 당신에게 도움이 될 만한 전문가의 손길은 없을 것이다. 팀 파운데이션 서버(Team Foundation Server) 는 모든 것을 통합한 ALM(Application Lifecycle Management) 제품이다. ALM(Application Lifecycle Management)을 이해하려면 가장 먼저 소프트웨어 공학부터 시작하고 이해해야 한다. 그리고 사용자 측면과 관리적 측면 모두를 이해하고 솔루션 환경을 제공해야 한다.

ALM 제품을 쓰기전에 소프트웨어 공학을 설명하지 못하면 왜 팀 파운데이션 서버(Team Foundation Server)를 써야 하는지도 설명할 수 없다. 소프트웨어 공학은 50년도 되지 않는 짧은 역사를 가졌지만 공학적인 분야에서 이만큼 빠르게 변화하고 발전한 공학도 없을 것이다. 그래서 소프트웨어 공학이란 것이 정확한 기준을 섣불리 경계를 짓기도 애매한 학문이다.

그리고 소프트웨어 공학과 최근 빠르게 확산되는 애자일(agile)에도 많은 시간을 쏟아서 경험을 축척해야 한다. 소프트웨어 공학은 정량적인 측정이 가능하지만 애자일은 다르다. 팀원간의 관계와 팀이 축척한 또는 개개인의 경험이 큰 작용을 하고 애자일이란 툴적인 측면에서도 적극적이어야 한다. 필자도 소프트웨어 공학과 애자일을 공부하면서 처음 블로그에 쓴 글로부터 불과 4년 밖에 채 되지 않는다. 학문이라는 것은 알면 알수록, 배우면 배울수록 모르는 것이 점점 더 많아지는 것은 왜그럴까 ^^;

TFS 전문가는 골고루 다 알아야 한다. 이것 저것 모두 통합된 제품이므로 당연한 것이다. Team Foundation Server, Visual Studio Ultimate 외에 알아야 할 것들이 더 많다.

전문가적인 서비스를 제공하는 업체도 없다

한 마디로, 팀 파운데이션 서버(Team Foundation Server) 기술을 서비스하는 업체들은 다 망했다. 그러므로 만약 당신의 회사에서 TFS 컨설팅이나 서비스를 받고자 한다면, TFS 전문가가 올 확률은 거의 없다고 봐도 된다.

실제로 운영하다 장애가 생겨도 우리나라에서는 제대로 된 서비스를 받기 힘들다. 국내 팀 파운데이션 서버(Team Foundation Server) 전문가가 있는 업체가 한 군데도 없다. 한 곳의 전문 업체가 있었지만 TFS 사업을 접었다고 전해들었다.

필자의 과거 전 회사에서는 TFS 컨설팅을 했었고, 그런 업체가 몇 군데 더 있었지만 지금은 TFS의 수요도 없을 뿐더러 한 번 도입하면 다른 솔루션으로 갈아탈 수 없는 폐쇠성을 가지고 있어 도입의 실효성에 대해서도 논란이 있다.

image-1
이미지 링크

마이크로소프트 제품으로 발라야 한다

TFS 도입을 결정하는 순간 마이크로소프트(Microsoft)의 제품으로 완전히 발라버려야 한다.

가장 먼저 발라야 하는 것은 윈도우 서버(Windows Server) 이다. 가장 최신의 버전인 Team Foundation Server 2012는 윈도우 서버 2008 R2 부터 설치할 수 있다. 항상 최신 버전에 잘 적응을 하는 것이 이로울 것이다.

두 번째로 발라야 하는 것은 엑티브 디렉토리(Active Directory; AD)이다. 다른 LDAP(Lightweight Directory Access Protocol; 경량 디렉터리 액세스 프로토콜)의 OpenLDAP 은 전혀 지원하지 않는다. 예를 들어, 사내에서 리눅스(Linux) 서버에 OpenLDAP을 쓴다면 당장 OpenLDAP 데이터를 Active Directory로 마이그레이션을 해야할 지도 모른다. 좀 더 똑똑한 방법으로는 Active Directory와 OpenLDAP을 동기화 하는 방법도 있지만, 결국 유지 관리의 피로도는 급격하게 늘어날 것이다. (물론, AD 없이 쓸 수도 있지만, 없이 쓸 생각을 하면 앞이 캄캄하다)

세 번째로 발라야 하는 것은 Microsoft SQL Server 데이터베이스 제품이다. 왜 MySQL을 지원하지 않는지 기술적으로 이해하기가 힘들다. 물론 이 제품에서 분석 서비스(Analysis Services)와 리포팅 서비스(Reporting Services)를 제공하는데, 이거 안쓰고 싶어도 써야 한다. 이거 안쓰면 TFS가 매우 초라해 지기 때문이다.

네 번째로 발라야 하는 것은 IIS(Internet Information Services; 인터넷 정보 서비스)이다. 너무도 당연한 이야기지만…

다섯 번째로, 옵션으로 쉐어포인트(SharePoint)를 바를 수 있다. 이것을 바르려고 하는 순간 전용 서버를 고려해야 할 것이다.

예측할 수 없는 잦은 장애, MS 제품에 잔지식이 많아야 한다

모든 것이 통합된 TFS 구동하는 환경은 또 매우 복잡하고 오류의 원인을 찾는 것이 매우 힘들 수도 있다. 그러므로 MS 제품 이것 저것을 알아야 하고 계속…….. 배워야 하는 악순환이 계속된다.

필자는 6년이 넘게 거의 논스톱으로 직접 운영하는 TFS 서버가 있다. 서버도 직접 구매했었고, 소음 때문에 코로케이션으로 쓰다가 서버는 팔고, 결국 규모를 데스크탑 두 대로 줄여서 집에서 돌린다. 자동 업데이트가 설정이 되었는지 원인은 모르겠으나 서버 재부팅 후에 TFS 서비스들이 먹통이 되는 경우가 많았다.

실무에서도 많이 겪는 문제 중 하나가 윈도우 업데이트(Windows Update) 서비스이다. 필자가 몸담았던 회사 중에 운영 조직에서 윈도우 서버 전문가들이 직접 관리했지만, 가끔은 윈도우 업데이트 후에 정상적인 서버 작동이 되지 않아 윈도우 업데이트를 롤백(rollback) 하는 경우가 다반사였다.

대충이라도 모르면 어디서 튀어나온 트러블인지도 예측할 수 없다. 권한 구성만 해도 엑티브 디렉토리, IIS, MSSQL, 쉐어포인트 다 따로 해줘야 하는데 이 제품들이 서로 자기 오류가 아니라는 듯한 메시지만 보여준다.

제대로 된 기능이 하나도 없다

얼마 전에 필자가 쓴 글이다. 글의 요지는 ‘모든 것을 만족할 수 있지만, 어느 것도 만족할 수 없다.’ 이다.

[ALM] 13. 불완전한 통합, 팀 파운데이션 서버(Team Foundation Server)

크로스 플랫폼(Cross Platform)을 지원하는 Atlassian 의 제품 몇 개와 비교해 보자.

  • TFS 이슈관리 vs JIRA (atlassian)  
    음.. 이건 알만한 사람이면 다 안다. TFS를 JIRA와 비교하는 것이 실례이다. redmine과 같은 오픈된 제품에 비해서도 TFS는 장점보다는 단점이 더 많다. TFS 이슈관리가 MS OFFICE 플러그인을 제공하긴 하지만, MS OFFICE에서 플러그인으로 다루는 것이 더 불편하다. 플러그인을 너무 대충 만들어놓고 OFFICE 통합이라고 하는 것은 좀 무리수다.

  • TFS 코드뷰어 vs STASH (atlassian)
    이것도 TFS는 STASH에 비교하는 것이 실례이다. STASH의 특성이 조금 다르긴 하지만, github 의 인트라넷 버전이라고 봐도 무방할 것이다. 그만큼 TFS 코드뷰어에 비해 잘 만들어 졌다.

  • TFS 팀 빌드 vs BAMBOO (atlassian)
    TFS 팀 빌드는 할 수 있는 것이 거의 없다. BAMBOOJenkins에 비교 자체가 실례이므로 넘어간다. 이미 BAMBOO는 Amazon EC2 같은 클라우드와 통합이 되었다. 이에 비해 TFS는 이제 베타 버전으로 인터넷을 통해 서비스를 테스트 중이다. 특히 BAMBOO는 다양한 소스 제어를 지원하는 것도 장점이다.

Atlassian의 통합성은 TFS의 복잡한 구성보다 더 간단하다. Atlassian 제품은 각 제품간에 긴밀하게 통합이 되어있으며, 다른 3rd party 제품까지 다양하게 통합할 수 있다. Atlassian 은 제품마다 REST 형태의 API 를 제공하는데, 제품간에 응용 프로그램 수준의 인증이나 Oauth 인증 등 다양하게 각 제품을 연결할 수 있다.

필자는 Atlassian 제품은 모든 제품을 라이센스를 직접 구매하여 집에서 호스팅을 하면서 공부하는데, 서로 간에 긴밀하게 잘 통합되어 있으며, 상당히 많은 Addon이 제공되어 매우 쉽게 기능을 확장할 수 있다.

#1의 결론

이번 #1에서 이야기한 ‘팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #1’은 주로 TFS의 외적인 부분에서 언급하였다. 앞으로 TFS 제품을 Atlassian과 다른 오픈된 ALM 솔루션과 기능적인 면으로도 비교해 볼 예정이다.

이슈 관리/ 소스제어/ 빌드/ 테스팅/ 릴리즈, 그 외에 다양한 면에서 비교해 보면서 진짜 이유를 조금씩 파헤쳐 볼 것이다.

image-2
이미지 링크, 이런 것도 통합인가?

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 지나가는사람 2019.08.28 15:25 Address Modify/Delete Reply

    이미 오래전 글이긴 하지만 본 김에 첨언하자면...

    TFS는 Windows VS를 사용하는 환경이라면 엄청나게 강력한 툴이며, 기능또한 강력하다 생각합니다.

    물론 언급한 것 처럼 마소의 제품군을 사용해야 그 위력이 재대로 발휘되는 만큼 어느정도의 마소 제품군의 강제성은 있습니다만 이 이유로 사용하지 말아야 한다는 것은 논리적 비약이라 볼 수 있겠네요.

    차나리 제목이 TFS 구축 시 유념해야 할 사항 혹은 TFS 기능을 100%로 끌어올릴 수 있는 방법 이정도가 제목이였으면 더 좋지 않았을까 싶네요..

  2. 지나가는사람 2019.08.28 15:31 Address Modify/Delete Reply

    덧붙여 MS제품에 잔지식이 많아야한다 즉, 어렵다는 것이 TFS가 좋지 않다라고 말하는 것도 논리적 비약이라 보여지네요.

    SQL Lite가 Oracle 혹은 Sql Server에 비해 가볍고 사용하기 편하다는 이유로 Oralce DB는 SQL Lite보다 좋지 않다. 라고 말하는 것이 억지라고 생각되거든요.

    물론 좋은 제품이라하면 기능의 접근성이 좋고 직관적으로 이해하기 편해야 하는 것은 맞지만 역으로 기능이 많고(복잡하고) 익히기에 어렵다는 이유로 그것이 좋지 않다라고 말하는 것은 아니라는 것이죠.

본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다. 


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


본 글 이외에 Visual Studio 팀 블로그를 함께 운영하는 강보람 MVP님의 "Welcome to Metro User Interface" 컬럼과 남정현 MVP님의 "Windows Server 8 미리 보기" 컬럼은 필자의 블로그에 기재하지 않은 점 또한 참고하기 바라며, 저작자의 동의하에 추후에 공개가 될 수 있습니다.



시대가 바뀌면서 Windows도 전통적인 모습에서 벗어나서 새로운 흐름을 만들고자 하는 노력이 시작된 것 같다. 물론 기존의 데스크 탑은 여전히 널리 사용될 것이다. 일상적인 업무에서 사용하는 응용 프로그램이 굳이 메트로 사용자 인터페이스 형태를 띌 필요는 전혀 없을 테니 말이다. 그리고 앞으로도 계속해서 기존의 데스크 탑을 타겟으로 하는 윈폼이나, WPF의 개발도 지속될 것이다. 하지만, 새로운 기회는 작은 틈에서 나오는 것이니 이 틈새를 잘 이해하기 위해서는 Windows 8의 메트로 환경을 잘 이해할 필요가 있다.

 

Windows 8과 Visual Studio 2012은 그야말로 N스크린에 감히 필수적인 환경이라고 말하고 싶다. 그 어떤 플랫폼도 데스크 탑과 테블릿, 모바일 등의 모든 기기와 환경 모두를 지원하는 것은 매우 어려운 일이다. 일반 사용자가 기기마다 사용하는 용도와 스타일이 다르고, 모바일 기기마다 해상도와 특징이 다르기 때문이기도 하지만, 하나의 개발 도구로 모든 상황을 대응할 수 있는 통합 개발 도구가 없는 것도 한 몫을 한다. 아니라고 말하는 독자도 있겠지만, 필자는 데스크 탑 환경까지 확장하는 N스크린을 말하는 것이고, 모든 N개의 스크린에서 똑같은 사용자 경험을 제공하는 것을 말한다. 이런 관점에서 Windows 8과 Visual Studio 2012은 그 해답을 제시하고 있으며, 충분히 가치 있고, 도전해 볼만하다. 이런 이유로 벌써부터 필자는 매우 흥분이 된다.

 

그리고 이 글에서 모두 소개하기는 어려웠지만, Windows Server 8은 그 동안의 Windows 운영 체제가 보여주었던 정적인 모습을 탈피하여 대규모 데이터 센터가 아닌 비용 문제 때문에 고민이 많은 수 많은 중소 규모의 IT 인프라에서도 효율적으로 시스템을 운영하고 애플리케이션 개발자들이 핵심에만 접근할 수 있도록 도와줄 방법을 제공하고 있다. 또한 메트로 스타일의 앱은 단순히 사용자 인터페이스에 관한 새로운 접근일 뿐만 아니라 데스크톱 가상화나 서버 관리자를 위한 새로운 종류의 서비스로 자리잡을 수 있다. 여전히 Charm Bar의 기능은 유용하게 사용할 수 있으며, Application Contract를 정확하게 지원하는 서버용 메트로 앱을 만들어 서버 관리자의 일을 덜어내거나 전혀 새로운 경험의 터치 기반 KIOSK를 손쉽게 만들 수도 있을 것이다. 이것은 전적으로 여러분의 선택에 달려있는 일이 될 것이다. 더 나아가서, Windows Server 8의 여러 기술들이 각종 호스팅 환경은 물론 Windows Azure나 Amazon과 같은 Public Cloud Computing 환경에도 전면적으로 도입이 된다면 더 멋지고 유용한 서비스들이 대거 등장하지 않겠는가 하는 것이 개인적인 생각이다.

 

참고 자료


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 아크몬드 2012.08.02 10:05 Address Modify/Delete Reply

    재밌게 읽고 갑니다.

본 글을 월간 마이크로소프트 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

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