윈도우 네이티브 윈도우, 다시 중심으로 돌아오다.

[김나래]

• 원문 링크: https://blogs.embarcadero.com/native-windows-is-back-to-center-stage/
• 작성자(작성일): Marco Cantu (2021.11)

UWP의 입지가 줄어들면서, 네이티브 개발이 다시 윈도우 개발의 주된 모델이 되었다. 그 사이에 있었던 닷넷까지 포함하면 20년만이다. 네이티브는 델파이가 가장 잘 하는 분야이므로, 델파이 개발자에게 정말 좋은 소식이다. 

------------------------------------------------------------------------------------------------------------------------------------------------

지난 몇 주 동안, 마이크로소프트는 윈도우 개발 면에서 과거의 방향을 일부 역행하는 발표를 했다. 요약하면, 마이크로소프트는 (완전히 버려지지는 않겠지만) UWP(Universal Windows Platform) 모델의 비중을 줄이고 있다. 

이와 관련된 링크들은 다음과 같다:

• 마이크로소프트는UWP에서 Win32로 마이그레이션하는 방법에 대한 세부 사항들을 공개했지만, 아마 당신이 생각하는 것은 아닐 것이다:  https://www.windowscentral.com/microsoft-publishes-uwp-win32-migration-details 
• UWP는 더 이상 대세가 아니다. 마이크로소프트는 UWP 앱을 윈도우 앱으로 마이그레이션하는 가이드를 발표했다: https://www.neowin.net/news/uwp-no-longer-fashionable-as-microsoft-releases-guidance-for-migrating-apps-to-windows-app-sdk/ 
• 마이크로소프트는 공식적으로 UWP를 더 이상 유지하지 않으려고 한다: https://www.thurrott.com/dev/258377/microsoft-officially-deprecates-uwp 

UWP가 당시 윈도우 개발의 중심 플랫폼이었던 닷넷 아키텍처를 대신하면서, 윈도우 8 이후부터 현재까지 UWP는 마이크로소프트 애플리케이션 개발의 중심이었다.

전통적인 네이티브 윈도우 개발 모델에 대한 집중을 유지해 온 개발자 (와 엠바카데로와 같은 도구 제조사)의 입장에서 볼 때 이 UWP의 쇠퇴는 매우 흥미있는 진화이다. 오랜 시간이 지난 뒤 네이티브 개발자가 다시 주류가 되었기 때문이다. 

 

네이티브에서 .NET과 UWP까지 

수년간, 네이티브 개발 모델 즉 클래식 윈도우 API를 사용하고, 윈도우의 3가지 핵심인 커널/유저/GDI 라이브러리와 그와 관련된 확장 모듈을 활용하는 개발 모델은 구식이고 더이상 사용되지 않고 곧 버려질 것으로 여겨졌다. 이 클래식한 방식은 델파이와 C++빌더 (VCL 라이브러리 포함) 뿐만 아니라 Visual C++ (MFC 라이브러리 포함)에서도 사용하는 방식이다. 

처음에는 윈도우 개발자들에게 닷넷으로 옮겨가도록 권장했다 (앞으로는 닷넷이 있어야 플랫폼 API가 작동할 수 있게 되고, 클래식 애플리케이션은 언젠가 윈도우에서 실행되지 않을 것이라는 생각을 갖도록 만들었다). 시간이 지나면서, 그렇게 되지 않는다는 점이 분명해졌다. 

닷넷 중심 방식이 약해지자, 마이크로소프트는 그 다음 아이디어를 밀어붙였다. 그것은  바로 UWP, 즉 유니버설 윈도우 플랫폼이었다. UWP는 두 가지 기본 컨셉을 중심으로 추진되었다. 첫번째는 동일한 애플리케이션이 데스크탑 PC 뿐만 아니라 윈도우 폰, 게임 콘솔, 바이저(역자주: 홀로렌즈와 같은 착용형 장비)에서 작동할 수 있다는 것이고, 두번째는 보다 안전한 플랫폼 즉 기본 운영 체제에 대해 제한된 접근이었다. API 수준에서 볼 때, UWP 지원은 곧 WinRT 플랫폼 API를 사용한다는 의미이다. 그런데 WinRT는 클래식 API와는 완전히 다르고 호환도 되지 않았다.

UWP는 따라잡는 속도가 느렸다. 델파이와 RAD스튜디오에서 선택할 수 있는 것은 없었다. 뿐만 아니라 Visual C++, 닷넷, C#에서 UWP로 마이그레이션하는 작업은 기존에 사용되던 것과는 다른 런타임 라이브러리 그리고 다른 UI 컨트롤들을 사용해야 한다는 의미였다. 즉, 기존 애플리케이션 중에서 많은 부분을 다시 작성해야 했다. 윈도우 8이 처음 출시되었을 때 (기존 API 애플리케이션을 허용했던 시기)에는, 사용할 수 있는 UWP 앱이 마이크로소프트에서 제공하는 것까지 합쳐도 거의 없었다. 하지만, 윈도우의 새 플랫폼 기능 몇가지는 WinRT API를 통해서만 사용할 수 있었다. 바로 이 점 때문에 개발자와 (RAD스튜디오 등) 개발도구가 클래식 애플리케이션 안에서 WinRT API를 호출하는 방안을 고안하게 되었다. RAD스튜디오에서 윈도우 알림 기능을 지원하는 기능이 바로 이 접근 방식으로 구현되었다.

마이크로소프트는 UWP를 밀어붙이는 동안, 클래식 앱은 더이상 사용되지 않을 것이라는 암시를 해왔지만, 개발자들은 실제로 그 말을 듣지 않았다. 그 다음 단계로 마이크로소프트가 추진한 것은 일명 “데스크탑 브릿지(Desktop Bridge)”이다. 이것은 네이티브 애플리케이션이 WinRT API를 더 많이 활용할 수 있도록 하고, 가벼운 컨테이너 안에 “패키징”하여 추가 보안을 할 수 있는 기술이다.  패키징은 APPX로, 그 이후에는 MSIX로 구현되었다. 다시 말하지만, RAD스튜디오에서는 데스크탑 브릿지를 꽤 오래 전부터 IDE 안에서 직접 지원해왔다. 

마이크로소프트는 데스크탑 브릿지에 대해 처음에는 애플리케이션을 UWP로 마이그레이션 하는 것을 도와주는 길이라고 설명했다. 당시에는 UWP가 여전히 마이크로소프트의 목표였다. 개발자는 기존의 애플리케이션 폼을 한번에 하나씩 변경할 수 있었는데, 얼마 지나지 않아 개발자는 방대한 코드 베이스를 이런 식으로 전환하는 작업에 실제로 전혀 관심이 없고, 오히려 플랫폼 기능을 사용하는 것에 관심을 가진다는 점이 명백해졌다. 이와 더불어 APPX와 MSIX는 클래식 애플리케이션이 마이크로소프트 스토어에 들어갈 수 있도록 하는 문도 열었다. 

작년을 잠깐 떠올려보면, 마이크로소프트는 프로젝트 리유니언(Project Reunion, 지금은 Windows App SDK로 불린다)을 발표하면서 UWP 애플리케이션에서 모든 네이티브 API를 호출할 수 있고, 네이티브 애플리케이션 역시 모든 UWP API를 호출할 수 있도록하는 상호 운용성을 완벽하게 제공하겠다는 목표를 내세웠다. 하지만 결국 네이티브 애플리케이션 지원을 훨씬 더 우선하고 UWP는 뒤로 밀렸다.

 

다시, 네이티브 

자, 다시 말해서, 지난 15년 즉 마이크로소프트에서 네이티브 윈도우 애플리케이션을 곧 사라질 이등 계급으로 취급하던 시대가 끝남에 따라, 이제는 그 위치가 완전히 뒤바뀌었다. 네이티브 앱 즉 클래식 API앱은 지금 이자리에 있고, 현대화, 새 API 지원, 윈도우11 지원 등의 맥락에서 우선 순위에 있다. 마이크로소프트는 네이티브 세계에 UWP 동의와 API를 제공할 계획이다.  

이 현상은 점점 증가하고 있다. 예를 들어, WebView 2 컨트롤(내장된 Chromium Edge로써 델파이, C++빌더에서도 이것을 래핑하여 지원하고 있다)은  COM 컴포넌트이다. 다른 새 API들 역시 COM을 사용한다. 물론 일부는 네이티브에 또 다른 일부는 WinRT에 기반을 두고 있지만 모두 네이티브 애플리케이션에서 액세스 할 수 있다. 

네이티브 API 모델이 여전히 지금 이자리에 있다는 사실은 델파이와 C++빌더에게 정말 멋진 소식이다. 이 모델은 엠바카데로가 항상 가장 우선 순위에 놓고 지켜오고 있었기 때문이다(글쎄, 델파이 닷넷 시절이 잠시 있긴 했지만), 뿐만 아니라 오랫동안 우리는 경쟁자들의 라이브러리보다 훨씬 많이 이 모델을 확장시켜왔다.

클래식 API를 사용하는 대체 UI 프레임워크, 예를 들어 MFC 라이브러리나 마이크로소프트 WinForms 라이브러리 등을 보면, VCL 라이브러리가 해왔던 것들에 비해, 이 모델에 대해 마이크로소프트의 관심과 향상이 훨씬 부족했다는 생각을 하게된다. 새 UI 컨트롤 추가부터 WinRT와 Reunion 컨트롤 내장까지, High DPI 지원부터 UI 스타일에 이르기까지, VCL 라이브러리는 지속적으로 확장되었고 경쟁 네이티브 라이브러리보다 훨씬 더 빠르게 향상되어왔다.

이런 이유로 RAD스튜디오는 오늘날 최고의 네이티브 윈도우 클라이언트 애플리케이션 개발 솔루션의 자리에 있다. 그뿐 아니라, RAD 스튜디오는 10년, 20년된 코드베이스를 놀랄만큼 쉽게 마이그레이션 한다. 다른 제품들과는 비교도 안된다. 

델파이, C++빌더 개발자가 되고, 최고 대우를 받는 윈도우 애플리케이션을 개발하는 것은 멋진 일이다. 이제는, 마이크로소프트가 혹시라도 차기 윈도우 버전에서 네이티브 애플리케이션 모델을 버릴지도 모른다는 염려 조차 할 필요가 없다.