유니버설 윈도우 플랫폼 앱을 닷넷 9으로

닷넷 데스크톱 애플리케이션을 구축하기 위한 통합 프레임워크로서 지금의 윈도우 앱 SDK와 Win UI에 이르기까지 마이크로소프트의 여정은 순탄치 않았다. 현재의 플랫폼은 최신 툴과 설계를 익숙한 프레임워크로 가져오지만 윈도우 10의 유니버설 윈도우 플랫폼(Universal Windows Platform: UWP)에서 빌드된 오래된 코드는 업데이트하기가 어렵다.
 

 
윈도우 8에 도입된 WinRT 모델을 계승하는 유니버설 윈도우 플랫폼은 새로운 윈도우 API와 마이크로소프트 스토어를 지원하도록 설계됐는데, 배포를 마이크로소프트 스토어에 묶어 마이크로소프트의 애플리케이션 승인 프로세스와 자체 결제 플랫폼에 종속되는 점이 문제로 지적됐다.
 
시간이 지나면서 플랫폼과 스토어가 발전했고 Win32 애플리케이션과 게임이 먼저 허용됐고 지금은 써드 파티 결제 플랫폼과 배포를 위한 지원이 추가되고 있다. 현재 모델은 유연하며 최신 닷넷 기능과 호환되도록 설계됐다.
 

AOT로 앞서 나가기

대략 한달 후면 닷넷 9이 출시된다. 첫 릴리즈 후보와 닷넷 9을 지원하는 비주얼 스튜디오 베타 버전은 현재 사용할 수 있다. 마이크로소프트는 이번 출시의 일부로 구식 UWP 기반 애플리케이션을 닷넷 9 플랫폼으로 가져오기 위한 부가적인 툴도 공개했으므로 이를 통해 네이티브 사전(AOT) 컴파일과 같은 새로운 기능을 활용할 수 있다.
 
이 옵션은 중요하다. 닷넷은 원래 모든 언어가 중간 바이트 코드로 컴파일되도록 설계됐다. 이렇게 컴파일된 코드는 이후 런타임에서 해석할 수 있다. 이 모델은 여전히 닷넷의 중심이며, 적시(JIT) 컴파일 툴이 X64와 Arm64 디바이스 모두에서 바이너리 코드로의 빠른 변환을 지원한다.
 
닷넷의 네이티브 AOT 툴은 코드가 네이티브 바이너리로 컴파일하고, 그러면 즉시 패키징과 배포가 가능하므로 앱 출시 속도를 높일 수 있다. 물론 X64와 Arm64를 위해 각기 별도의 바이너리를 생성하고 많은 경우 설치 프로그램도 별도로 만들어야 하지만 어드밴스드 인스톨러(Advanced Installer)와 같은 툴을 활용하면 사용자 PC에 맞는 바이너리를 설치하는 멀티 아키텍처 설치를 빌드할 수 있다.
 

UWP를 윈도우 앱 SDK로 가져오기

UWP 애플리케이션을 윈도우 앱 SDK로 업데이트하는 데는 시간이 걸린다. 특히 아직 윈도우 앱 SDK나 Win UI 3으로 업데이트되지 않은 써드 파티 라이브러리와 구성요소에 의존하는 경우라면 더 많은 시간이 소요된다. 마이크로소프트 스토어를 통해 배포할 수는 있지만 이 경우 네이티브 AOT와 같은 기능을 사용할 수 없다.
 
물론 마이크로소프트는 개발자가 닷넷 스택 최신 버전으로 코드를 업데이트하는 것이 좋겠지만 어려움도 잘 알고 있다. 그래서 기존 코드를 가져와 최신 닷넷에서 실행하고, 시간과 리소스 여유가 될 때 가능한 부분을 변경할 수 있게 해주는 방법이 필요하다. 마이크로소프트는 이 같은 이유로 곧 나올 닷넷 9에 UWP 지원을 추가하는 일련의 툴을 출시했다.
 
UWP의 닷넷 9 지원은 “원 버튼” 솔루션이 아니라 닷넷 개발 스택의 다양한 계층과 비주얼 스튜디오, 윈도우 SDK, 그리고 닷넷 자체에서 동작하는 여러 툴의 혼합체다. 이 툴들이 함께 작동하면서 기존 C# 코드를 가져와 윈도우 앱 SDK로의 마이그레이션 프로세스를 시작하기 위해 필요한 기반 요소를 제공하면서 사용자에게 최신 플랫폼의 이점을 볼 수 있도록 한다. 더 새로운 기술로의 업데이트는 점진적으로 진행할 수 있다. 예를 들어 일부 기능을 XAML 아일랜드에 유지하면서 Win UI 사용자 환경을 개발할 수 있다. 결과적으로 마이크로소프트가 자체 앱 업데이트에 사용하는 툴의 공개 출시 버전을 활용하게 되며, 마이크로소프트 스토어는 이러한 툴과 함께 작동해서 조만간(아마 닷넷 9이 정식 출시되고 지원을 받게 되는 11월 중으로) 네이티브 AOT 버전을 제공할 것이다.
 
이 툴을 사용할 다른 좋은 이유는 이전 닷넷 네이티브 툴에 대한 종속성을 없애준다는 점이다. 닷넷 네이티브는 닷넷 코어 2.0과 닷넷 스탠다드 2.0 이상으로는 업데이트가 되지 않았기 때문에 새로운 닷넷 기능을 제대로 사용할 수 없다. 이 변경으로 코드에 새로운 라이브러리를 추가할 수 있으므로 닷넷과 윈도우 기능을 더 폭넓게 이용할 수 있다.
 

닷넷 9에서 UWP 시작하기

프리뷰 코드가 늘 그렇듯이 설정은 다소 복잡하다. 먼저 비주얼 스튜디오 17.12 최신 프리뷰 빌드부터 시작한다. 설치하고 나면 독립형 비주얼 스튜디오 설치 프로그램을 사용해 윈도우 애플리케이션 개발 워크로드를 활성화한다. 또한 설치 프로그램의 기타(Others) 섹션에서 UWP 툴과 최신 윈도우 11 SDK 릴리즈를 추가한다.
 
다음은 한시적으로만 적용되는 요건으로, 새로운 XAML 컴파일러를 다운로드해 설치해야 한다. 이 컴파일러는 향후 윈도우 11 SDK 릴리즈에 포함되지만 지금은 따로 업데이트해야 한다. 또 다른 중요한 요구사항은 닷넷 9 최신 나이틀리 빌드다. 필요한 툴이 RC2의 표준 프리뷰 빌드부터 패키징되기 때문이다. 마이크로소프트가 제공하는 nuget.config 파일을 애플리케이션 프로젝트에 추가해서 닷넷을 현재 나이틀리 빌드 최신 상태로 유지할 수 있다.
 
또다른 개별 설치에서는 닷넷 9에 호스팅되는 UWP 애플리케이션을 지원하기 위해 새 프로젝트 템플릿을 추가한다. 이 부분 역시 출시가 가까워지면 비주얼 스튜디오에 포함될 것이다. 이 같은 상황은 출시 몇 개월 전의 마이크로소프트 개발 툴에서는 흔한 일이다. 닷넷, 비주얼 스튜디오와 같은 컴포넌트 기반 툴에는 가동부가 많은 만큼 업데이트 일정이 다를 수 있기 때문이다.
 
이제 새 프로젝트 템플릿을 사용해서 닷넷 9에서 UWP를 다룰 수 있다. 빈 템플릿으로 시작해서 기존 코드와 XAML을 가져오는 편이 아마 가장 쉬울 것이다. 원래의 UWP 템플릿과 거의 동일하게 작동하면서 Win UI 마이그레이션을 준비할 수 있게 해준다. 다른 템플릿은 다이렉트 X를 사용하거나 새 라이브러리를 빌드하는 애플리케이션을 포함한 다른 시나리오에 도움이 될 것이다.
 

여전히 할 일은 많다

닷넷 9에서 UWP 프로젝트를 사용하는 과정은 이전 버전의 닷넷과 많은 부분에서 비슷하다. 익숙한 애플리케이션 구조를 사용하며 최신 MSIX 애플리케이션 패키지가 지원된다. 참고로, 생성된 프로젝트 파일에서 몇 가지를 변경해야 한다. 기본적으로 불필요한 몇몇 파일을 참조하고 그에 따른 빌드 오류가 발생하기 때문이다.
 
닷넷 9에서 UWP를 사용하기 위한 핵심은 .csproj 파일에 설정되는 몇 가지 속성이다. 이러한 속성은 Win UI와의 충돌 없이 UWP를 활성화하고 비주얼 스튜디오 빌드 툴이 올바른 XAML 컴파일러를 사용하도록 보장한다. 또 다른 필요한 속성은 코드가 마이크로소프트 스토어에 게시될 수 있도록 네이티브 AOT로 컴파일되도록 보장한다. 이는 스토어 제한을 피하기 위한 유일한 방법이다.
 
여기서 코드 업데이트와 관련한 문제가 발생한다. 모든 코드(사용 중인 라이브러리까지)가 네이티브 AOT와 호환되는지 확인해야 하는데, 필요한 일이긴 하지만 그 과정이 복잡하고 시간도 많이 걸릴 수 있다. 이걸 제대로 하지 않으면 닷넷 9에서 UWP 애플리케이션이 제대로 작동하지 않는 경우가 많다. 필요한 작업의 대부분은 닷넷에서 네이티브 AOT로의 마이그레이션을 위해 필수적이다. 두 기술의 유효성 검사 처리 방법이 다르기 때문이다. 네이티브 AOT는 훨씬 더 엄격하며 정적 유효성 검사와 코드 주석을 사용한다. 버그를 방지하는 데 도움이 되지만 마이크로소프트의 마이그레이션 설명서에 따른다 해도 약간의 노력이 필요하다.
 
이러한 툴의 상당수는 UWP에서 현대적 윈도우 앱 SDK 애플리케이션으로의 전환을 통해 코드를 지원하는 데 중점을 두지만 다른 시나리오도 지원된다. 흥미로운 시나리오 중 하나는 XAML 아일랜드의 작동 방식을 개선해서 기존 UWP 컨트롤을 현대적인 Win32 애플리케이션에 호스팅하는 것이다. 닷넷 9에서 UWP가 지원되므로 Win32 코드와 컨트롤을 같은 프로젝트에 두고 동일한 빌드 툴을 사용할 수 있다. XAML 아일랜드 컨트롤을 코드의 나머지 부분과 따로 관리할 필요가 더 이상 없다.
 
이 툴에는 놀라울 정도로 많은 기능이 있으므로 살펴보는 과정에서 더 많은 기능을 찾게 될 것이다. 다른 두 가지 애플리케이션 개발 모델 사이의 간극을 잇는 것은 코드를 최신 상태로 유지하는 것 이상의 역할을 한다. 개발자에게는 최신 기술에 몰두하느라 개발자를 뒷전에 두고 있지 않다는 점을 보여주는 데 도움이 된다. 또한 마이크로소프트 스스로가 이 코드를 사용하고 있음을 아는 것도 유용하다. 마이크로소프트 스토어도 같은 방식으로 UWP에서 윈도우 앱 SDK와 Win UI 3로 이전하고 있다.
 
지금 바로 모든 부분이 작동할 것으로 기대하면 안 된다. XAML 디자이너와 같은 핵심 툴 일부가 빠져 있으므로 지금은 애플리케이션 레이아웃 작업을 할 수 없다. 새 디자이너는 아직 개발 중이며 정식 출시 시점에는 포함될 것이다. 프리뷰 코드에서 실행되는 프리뷰 릴리즈인 만큼 기능의 부족함은 지금 단계에서는 감수할 수밖에 없다.
 
마이크로소프트가 강조하듯이 이러한 툴은 새 UWP 애플리케이션을 구축하기 위한 용도로 만들어지지 않았다. 무엇보다 UWP는 더 이상 개발되지 않으므로 새로운 윈도우 기능을 코드에서 사용할 수 없게 된다. 어쨌든 이러한 툴은 기존 코드도 그대로 버려지지 않으며 이전 코드에서 새로운 코드로 업그레이드하기 위한 효과적인 경로가 필요하다는 사실을 인정한 결과다.
editor@itworld.co.kr