회사 업무 때문에 구질구질한 재래식 Windows API 기반 네이티브 데스크톱 프로그램이 아니라 일련의 신문물들을 접할 일이 있었다. 바로 지금까지 말로만 듣던 Windows Phone 플랫폼 개발 때문이었다.
1. Windows 8.1
Windows 8로 넘어가면서 부팅부터 UEFI라는 기술이 도입되면서 뭐가 좀 바뀌었다. 운영체제를 다시 설치하려고 부팅 디스크 탐색 순서를 바꾸려고 해도 BIOS Setup에서 좀 번거로운 절차를 거쳐야 하게 되었다.
Windows Phone 에뮬레이터를 돌리려면 역시 BIOS Setup을 들어가서 기본적으로 꺼져 있는 CPU 가상화 기능을 켜야 하며, OS도 아무거나 쓰면 되는 게 아니라 8.1 Pro 이상급이 반드시 필요하다. Hyper-V 기능이 home급에서는 지원 안 되고 Pro나 엔터프라이즈 급 이상부터만 지원되기 때문이다.
Pro 이상에서만 지원되는 대표적인 기능이 바로 원격 데스크톱 서버 기능인데.. 그런 비슷한 기능이 하나 더 생긴 것이다.
요즘은 스마트폰 CPU도 PC와 별 차이 없을 정도로 굉장한 고사양이기 때문에 에뮬레이션을 위해서는 CPU 차원에서의 온갖 첨단 기능이 덩달아 필요해진 듯하다. 덕분에 이젠 가상 머신에서도 Windows Aero 효과가 돌아가는 세상이 되기도 했다.
Windows 8 이상의 그 각지고 단순해진 GUI를 보면, 비스타/7에 비해 퇴화한 것 같고 화면을 왜 저렇게 만들었나 싶은 생각이 처음에 들었다. Windows 8부터는 아시다시피 고전 테마가 없어지고 화면 scheme은 오로지 "표준 아니면 고대비"로 극도로 단순화됐다.
하지만 이젠 저것도 그럭저럭 적응이 돼 간다. 외형이 단순해진 대신, 단조로움을 덜기 위해 창틀의 색깔이 시시각각 변하는 기능이 생기기도 했고. ㅎㅎ
운영체제를 설치하는 중에 전체 화면에서 배경색이 서서히 알록달록하게 변하는 건, 마치 도스 시절 VGA mode 13h에서 전체 화면 게임 프로그램이 팔레트 스크롤을 하는 것 같은 느낌이 들었다.
2. Visual C++ 2013
외형이 별로 바뀐 게 없고 시간 간격도 2012에 비해 겨우 1년 차이밖에 안 나는지라 변화량을 만만하게 봤었는데, 실제로 써 보니 그렇게 만만하지는 않다. 아기자기한 기능들이 많이 강화되고 좋아졌다.
색깔 scheme이 하양과 검정 말고 '파랑'이 하나 더 생겼는데 파랑은 옛날의 우중충한 2010 분위기를 내는 스타일이어서 개인적으로는 비호감.
운영체제의 기본 컨트롤을 쓰는 게 아니라 모든 걸 자기가 직접 그린다는 특성상, 스크롤 바가 굉장히 똑똑해졌다. cursor가 속한 줄 위치가 스크롤 바에도 언제나 표시되어 나오고, 스크롤 중에 페이지 썸네일을 표시하는 기능도 있다.
옵션(프로젝트 옵션과 프로그램 옵션 모두) 대화상자가 드디어 크기 조절이 가능해졌으며, C++도 코딩 중의 자동 서식과 자동 완성 기능이 제법 강화되었다.
Visual Studio (C++ 포함)는 지난 2005 버전 때부터 Express라는 무료 버전이 정식으로 배포되고 있다. 그래서 예전에는 플랫폼 SDK(= 무료 배포)도 자체적으로 컴파일러를 포함하고 있었는데 그것까지 express 에디션으로 완전히 대체되었다. 상업용 버전과는 달리 2013 Express 버전은 Windows 8용 Metro/Phone 앱만 만들 수 있는 'for Windows' 에디션과, 예전의 재래식 native 프로그램만 만들 수 있는 'for Windows desktop' 에디션이 따로 나뉘었다.
3. C++/CX
드디어 그 이름도 유명한 '요물'을 만져 보게 됐다. 처음에는 단순히 C++을 닷넷용으로 마개조한 Managed C++와 C++/CLI의 후신인줄로만 알았는데 그렇지 않다. C++/CX와 Windows RT API는.NET 내지 C++/CLI하고 무늬는 비슷하지만 내부 구조는 완전히 다르다.
예를 들어, 옛날의 C++/CLI에서는 일반 C++ 개체(new)와 관리되는 새로운(__gc new) 개체는 서로 has-a 관계조차도 맺을 수 없었다. 취급되는 방식이 서로 다른 개체를 다른 개체의 멤버로 가질 수 없었다는 뜻이다. C++/CX는 그런 제약이 없다.
.NET 그쪽 바닥은 전통적인 바이트코드 기반 런타임이지만 C++/CX는 엄연한 네이티브 코드 기반이다. 가장 큰 차이로 후자에는 garbage collector가 없다. ref new로 할당하는 ^ 라는 이상한 포인터가 있긴 하지만 얘는 내부적으로 그냥 레퍼런스 카운팅으로 관리될 뿐이다. .NET과 비슷한 API를 차용하고, C#에서 partial도 가져오고 델리게이트나 boxing 같은 것도 가져왔지만, 내부는 여전히 native라는 게 참 인상적이다. 게다가 이제 퇴물 신세가 됐나 싶던 COM 인터페이스까지 다시 끄집어냈다니!
Visual C++ 200x 시절에만 해도 이제 MS가 C++을 버렸네(특히 MFC!!), 네이티브 코드 시절이 끝났네, 심지어 Windows 차기 버전은 닷넷 같은 바이트코드 기반으로 완전히 새로 만들어진다네 하는 온갖 낭설이 떠돌았는데.. 201x로 와서는 그런 낭설이 완전히 불식된 듯한 느낌이다. MFC는 2008 feature pack 때부터 잘 알다시피 환골탈태하였으며, C++ 언어 자체도 C++11 같은 온갖 확장 규격에 힘입어 한없이 강력하고 복잡해졌다. 거기에다 Windows RT의 코드 기반도 네이티브 코드에 힘을 실어 줬으니 C++은 예나 지금이나 건재한 언어 인증을 하게 됐다.
이런 요물의 등장으로 인해 도리어 .NET의 위상이 굉장히 어중간해졌다. 비슷한 시기에 등장한 GDI+도 너무 금세 버림받고 낙동강 오리알 신세가 됐고 말이다. 얘는 이제 하드웨어 가속 지원도 못 받는다니, 안티앨리어싱이 되는 그래픽이 필요하다면 얄짤없이 Direct2D라도 새로 공부해야 하게 생겼다.
뭐 내부 메커니즘이야 어떻든, 네이티브 코드 C++에서도 delete 따질 필요 없이 new를 막 남발해도 된다는 게 무척 신기하며, 마치 자동차로 치면 수동을 몰다가 자동을 모는 듯한 느낌이다. 하지만 세상에 다 썼으면 반드시 반납을 해야 하는 리소스가 메모리만 있는 건 아닌데, 파일이나 다른 커널 오브젝트들은 어떻게 관리되며 생명 주기가 어떻게 되는지 궁금해질 때도 있다. 참고로, 레퍼런스 카운팅도 GC에 비해서 마냥 가볍고 편리하기만 한 물건은 아니며 약점이 있다.
Windows RT API들은 정말 복잡한 namespace와 클래스, 추상 계층들이 넘쳐난다. 지저분한 Windows API를 정말 허접하게 감싼 MFC 정도를 생각했다가 요즘 프레임워크들을 보면 입이 떡 벌어질 수밖에 없다.
멤버뿐만 아니라 클래스 자체에다가도 public 같은 접근성을 지정할 수 있으며, 더 상속이 안 되게 하는 sealed 속성을 줄 수 있다. 일반 C++에서는 허용되지만 C++/CX에서는 “무슨 클래스에서는 생성자가 public이어서는 안 된다, 데이터 멤버가 뭐여서는 안 된다”는 식의 까다로운 제약도 굉장히 많아서 처음엔 답답함을 느꼈다. (상속이라는 게 없는 언어에다가도 클래스를 제공할 수 있게 하기 위해 들어간 제약이라 함.)
이 기회에 delegate라는 게 뭔지도 다시 살펴보게 되었다. 선언 자체는 C++로 치면 함수 포인터 내지 멤버 함수 포인터에 대한 typedef를 선언하는 것과 비슷한 개념이며, 이놈의 인스턴스는 따로 new로 선언해야 한다. 그때 생성자에다가 다른 함수 명칭라든가 람다 함수를 집어넣어 주면 된다.
람다의 경우 this를 캡처로 주면 자연스럽게 멤버 함수도 대리자가 될 수 있으니 매우 유연하다. 물론 그 유연성은 성능 대가를 치르고 얻어진 것이겠지만 말이다.
Windows RT API에는 비동기적으로 행해지는 동작이 많으며, Concurrency Runtime 라이브러리와 밀접한 관계가 있다. 표준 C++ 라이브러리의 일부인 모양인데 create_task에다가 할 일들을 넣어 주고, 그 일이 반드시 다 끝난 뒤에 수행할 일은 저 함수의 리턴값에다가 .then 메소드를 호출하고 거기에다가 또 람다 형태로 넣으면 된다. 기본적으로 코딩 패턴이 그러하다.
.wait 메소드를 이용해서 동기화를 시켜도 되지만, 이 경우 Windows Phone은 UI 스레드까지 멈춰 버려서 데드락이 발생하는 듯하다. 참고로 C#의 경우 언어 차원에서 await이라는 전용 키워드가 존재한다고 함.
도대체 저 라이브러리는 어떻게 구현되었나? 소스 내부에 CreateThread, WaitForSingleObject 같은 Windows API라도 썼는지 궁금했지만.. 디버거로 내부 추적이 전혀 되지 않을 뿐더러 온갖 암호 같은 복잡한 템플릿은 도저히 분석 가능하지 않았다. 그래서 분석을 포기했다.
아무튼, C++은 람다 함수가 도입되어서 코드를 값으로 집어넣는 게 가능해지고, 이게 템플릿과도 결합하는 바람에 그야말로 예전의 C++에서는 상상도 할 수 없던 무궁무진한 활용이 가능해지긴 했다.
Windows RT 환경에서는 재래식 Windows API는 쓸 수 있는 것도 있고 그럴 수 없는 것도 있다. 이걸 일일이 다 분류하는 것도 마소의 엔지니어들의 입장에서는 엄청 고된 일이었겠다.
실행을 잠깐 멈추는 Sleep 함수도 누락되고 없기 때문에 Concurrency::wait를 써야 한다고 한다. 난 저걸 알기 전에는 이벤트 오브젝트를 만들어서 WaitForSingleObjectEx 함수를 쓰곤 했다.
끝으로, Windows RT의 C++/CX 환경은 네이티브 코드를 표방하는 관계로 재래식 static library와 DLL을 모두 만들어 쓸 수 있다. 단, 불가능하지는 않지만 static library의 경우 링커가 경고를 띄운다. 그건 오로지 같은 C++ 프로젝트에서만 활용 가능하니 재사용성이 크게 떨어지기 때문이라고.
RT 환경에서는 Windows Runtime Component라는 특수한 형태의 DLL을 만들어서 코드를 재사용하는 것이 권장되는 방법이다. Windows RT계의 COM 같은 물건인데, 그렇다고 COM 정도로 문법이 크게 제약되고 경직된 건 아니다. C#으로 표현 가능한 언어 요소들을 모두 표현할 수 있고, 아무래도 원시적인 인클루드와 라이브러리보다는 더 깔끔한 빌드/재사용 시스템인 듯하다.
이런 것들을 경험하고 나니 뭔가 미래에 갔다 온 듯한 느낌이었다.
XAML은 Win32 개발로 치면 rc 파일 같은 것이고
public ref class는 Win32에서 __declspec(dllexport) 같은 건가?
예나 지금이나 완전한 형태의 Windows 프로그램을 만들기 위해서는 무슨 언어든 문법 확장이 불가피했지만 지금은 더 체계적이고 조직적이고 더 노골적으로 하는 듯하다.
시대를 불문하고 불변인 자기만의 전문 영역이 있어야겠지만, 한편으로 최신 시대 조류도 놓치지 말고 따라갈 줄 알아야겠다는 생각이 새삼 들었다.
'독립 개발자 네트워크'를 운영하고 계신 깁뿔 님께서 오래 전에 Windows 8 개발 공부를 하면서 올려 놓으신 팁들을 이 기회에 뒤늦게나마 유용하게 활용했다.
Posted by 사무엘
