2018.05.17

레거시 윈도우 앱을 윈도우 10 앱으로 변환하는 방법

Simon Bisson | InfoWorld
칩이나 운영체계 등의 플랫폼 변환은 쉽지 않은 작업이다. 그런데 이보다 더 어려운 작업이 하나 있다면, 그것은 한 SDK를 다른 SDK로 변환하는 작업이다. 마이크로소프트는 10년이 넘은 Win32 코드와 이의 다양한 사용자 경험층을 새로운 WinRT와 유니버설 윈도우 플랫폼(UWP)으로 변환하는 작업을 진행 중이다.

Image Credit : GettyImagesBank

이는 수십억 대에 이르는 PC와 온갖 버전의 윈도우 설치물, 그리고 세련되지 않은 Win32로 제작된 코드, 윈폼(WinForms), WPF가 관련된 거대한 프로젝트이다. 이들 모두를 UWP로 하룻밤 사이에 이식하는 것은 점증적 업그레이드로만 기존 LOB(line-of-business) 소프트웨어를 지원하는 데 집중해온 업종에서 불가능한 요구이다. 그리고 마이크로소프트 데스크톱 브리지가 윈도우 10 기능과의 통합을 부분적으로 허용하긴 하지만, 윈도우 7용으로 제작된 소프트웨어로 이들을 소환하거나, 구형 윈도우 SDK에는 등가물이 없는 새로운 사용자 인터페이스 컴포넌트는 이용할 수 없다.

UWP 데스크톱 UI의 개선
핵심 UWP 플랫폼을 전달하는 작업이 대부분 마무리되면서, 현재 마이크로소프트는 관련 기능을 구형 SDK로 역이식하는 방법을 개발하고 있다. 목표는 스스로 ‘현대적 애플리케이션’이라고 칭하는 것과 데스크톱 애플리케이션을 더욱 근접시키는 것이다. 데스크톱에 치중하는 최신 UWP 컨트롤 세트는 이런 과정의 일부이고, 이들 컨트롤을 구형 소프트웨어 코드에 이식하는 방법, 구형 애플리케이션의 신규 버전 제작을 용이하게 하는 신규 배치 모델들이 이에 동반된다.

UWP의 윈도우 레이아웃은 컨트롤과 공간 설계의 많은 부분을 태블릿에서 처음 쓰인 윈도우 8 WinRT로부터 물려받았다. 윈도우 10은 데스크톱 애플리케이션에 치중하기 때문에 이는 화면 낭비가 심한 애플리케이션으로 이어진다. 8인치 태블릿의 단일 화면에서 문제 없이 작용했더라도 15인치 노트북과 28인치 모니터라면 이야기가 다르다. 윈도우 10의 메일 앱 패키지와 아웃룩 2016을 비교해보면 UWP 레이아웃에서 소실된 정보가 얼마나 많은지 알게 된다.

2018년 가을로 예정된 윈도우 10 빌드 1809 릴리즈와 함께 나오는 새로운 표준 UWP 뷰는 정보 밀도가 15% 증가한다. 대단한 변화는 아니지만 메일 목록 보기에 이메일 메시지를 두어 개 추가하기에는 충분하다. 그리고 이는 유일한 선택지가 아니다. 미니 UWP 컨트롤 뷰가 있어서 화면에 훨씬 더 많은 정보를 추가할 수 있다. 밀도가 덜한 UWP 레이아웃에서 모든 터치 및 펜 제공성에 여전히 접근할 수 있다. 그러나 이와 동시에 구형 윈도우 UI에서 가능했던 레이아웃들을 복제할 수 있다.

UWP 컴포넌트를 Win32 애플리케이션에 추가하기
밀도 높은 레이아웃을 UWP로 가져온다면 전면적 애플리케이션 재작성에 도움이 된다. 그러나 기반 코드의 변경 없이 UWP 기능들을 이용하고 싶다면? 신규 XAML 아일랜드(Islands) 기능을 이용하면 된다. 이는 기존의 WinForms 또는 WPF 컨트롤들을 UWP 대응물로 교체해 준다. 이들을 현행 디자인에 적용해 UWP 기능을 이용할 수 있게 되는 것이다. XAML 아일랜드에 의해 손글씨 기능을 기존 코드에 신속히 추가할 수 있고, 또는 마이크로소프트의 신규 Fluent Design 언어를 이용할 수 있어서 애플리케이션을 대대적으로 변경할 필요 없이 신속히 업데이트할 수 있다.

빌드 2018에서 ‘간단한 버튼’이라고 칭해진, 일반 컨트롤을 위한 UWP XAML은 WPF 및 WinForms 래퍼(wrapper)로 래핑된다. 구 버전으로의 폴백(fallback)이 있으므로 하나의 바이너리가 윈도우 10과 윈도우 7 애플리케이션에서 여전히 유효하다. 하지만 윈도우 7의 경우 윈도우 10에서 실행되는 코드에 이용할 수 있는 UI 또는 운영체제 수준의 기능은 이용할 수 없다.

XAML 아일랜드에 딸려오는 또 다른 보너스는 최신 엣지 기반 WebView 컨트롤에 액세스할 수 있다는 것이다. 기존의 IE 기반 WebView 컨트롤은 최소한의 업데이트만을 받기 때문에, 사용자는 웹 컴포넌트 안에서 보다 최신의 자바스크립트는 물론 더 새로운 HTML 및 CSS 기능을 이용할 수 있다. 아울러 추가 코드 없이 펜 지원을 추가할 수 있는 클라우드 기반의 잉크 어낼리시스(Ink Analysis) 같은 새로운 폼 기능도 이용할 수 있다.

WebView 지원을 시작으로, 윈도우 10의 현행 인사이더 빌드에서 XAML 아일랜드를 사용할 수 있다. 2018년 가을쯤 최종 릴리즈가 나오기 전에 다른 컨트롤도 추가될 것이다.

마이크로소프트는 기존의 공개 커뮤니티 컨트롤 툴킷 디자인 프로세스를 통해 작업을 진행하기 때문에, 또 대다수 작업이 깃허브(GitHub) 상에서 이루어기 때문에 개발자가 XAML 아일랜드가 지원할 컨트롤을 결정하는 데 영향을 미칠 수 있다.

그러나 모든 컨트롤을 XAML 아일랜드가 지원한다는 것은 아니다. 기존의 컨트롤에 적절한 래퍼를 추가하는 데에는 수많은 작업이 필요하다. 그리고 소스 컨트롤이 없거나 오래 전에 잊혀진 서드파티 컨트롤은 변경되지 않는다. 마이크로소프트는 맟춤형 컨트롤의 래핑을 지원하는 툴을 제공할 것이라고 약속했지만, 2019년에나 기대할 수 있을 것으로 보인다.

기존 코드를 위한 신규 인스톨러
데스크톱 애플리케이션을 현대화하는 이 새로운 접근법의 마지막 부분은 새로운 인스톨러 모델과 .Net 자체를 배치하는 새로운 방식이다. 이 접근법의 핵심 측면은 .Net Core 3.0에서 데스크톱 애플리케이션을 지원하는데 집중하는 것이다. .Net Core의 핵심 역할은 여전히 UI가 없는 크로스 플랫폼 애플리케이션을 지원하는 것이지만, 이는 작은 크기와 더불어 .Net Standard를 통한 .Net API의 지원이 증가함에 따라 독립적으로 설치되고 관리되는 데스크톱 애플리케이션에 이상적이다.

.Net Core와 필수 애플리케이션 코드를 단일 배치 컨테이너로 취합함으로써(bundling), 더 이상 데스크톱 디바이스의 .Net 버전을 유지하는 것을 걱정할 필요가 없다. 앱 실행에 필요한 모든 것이 앱과 함께 있다. 상이한 앱이 동일 라이브러리의 상이한 버전을 필요로 하더라도 버전닝(versioning) 문제가 없다. 각 앱은 해당 라이브러리의 자체적인 격리 사본을 가지고 있기 때문이다.

새로운 배치 패키지인 MSIX가 이와 밀접하게 연관된다. 이는 윈도우의 익숙한 배치 툴을 대다수 취합하고, 직접 또는 마이크로소프트 스토어를 통해 배치할 수 있다. 기존의 MSI와 .appx 패키지는 새로운 포맷으로 변환될 수 있다. IT 전문가는 애플리케이션 패키지와 별도로 커스터마이징을 관리할 수 있다. 각각의 신규 MSIX에 공통 커스터마이징 팩을 단순히 추가함으로써 새로운 릴리즈와 업데이트의 배치가 한층 쉬워진다. 소프트웨어 코드는 윈도우 10 상의 격리된 컨테이너에서 실행할 수 있다. 이는 . appx 격리 모드 상에서 구축되어 데스크톱 브리지 변환 코드와 UWP 앱을 모두 호스팅한다.

마이크로소프트의 하위 호환성 이력을 보면 개발자와 사용자에게 주요 플랫폼 업그레이드의 혜택을 주기 어렵다. 그렇지만 모든 것을 지원하는 윈도우 릴리즈에서 실행될 것이라면 굳이 코드를 업그레이드할 필요가 있겠는가?

애플리케이션 업데이트 및 배치에 있어서의 새로운 길을 제공함으로써 기존의 코드를 제시함과 아울러 신구 애플리케이션을 충돌 없이 나란히 실행할 수 있는 여지가 생겼다. 마지막에는 마이크로소프트가 기업의 윈도우 10 마이그레이션을 촉진하는 데 필요한 구성요소를 제공할 수도 있을 것이다.  editor@itworld.co.kr


2018.05.17

레거시 윈도우 앱을 윈도우 10 앱으로 변환하는 방법

Simon Bisson | InfoWorld
칩이나 운영체계 등의 플랫폼 변환은 쉽지 않은 작업이다. 그런데 이보다 더 어려운 작업이 하나 있다면, 그것은 한 SDK를 다른 SDK로 변환하는 작업이다. 마이크로소프트는 10년이 넘은 Win32 코드와 이의 다양한 사용자 경험층을 새로운 WinRT와 유니버설 윈도우 플랫폼(UWP)으로 변환하는 작업을 진행 중이다.

Image Credit : GettyImagesBank

이는 수십억 대에 이르는 PC와 온갖 버전의 윈도우 설치물, 그리고 세련되지 않은 Win32로 제작된 코드, 윈폼(WinForms), WPF가 관련된 거대한 프로젝트이다. 이들 모두를 UWP로 하룻밤 사이에 이식하는 것은 점증적 업그레이드로만 기존 LOB(line-of-business) 소프트웨어를 지원하는 데 집중해온 업종에서 불가능한 요구이다. 그리고 마이크로소프트 데스크톱 브리지가 윈도우 10 기능과의 통합을 부분적으로 허용하긴 하지만, 윈도우 7용으로 제작된 소프트웨어로 이들을 소환하거나, 구형 윈도우 SDK에는 등가물이 없는 새로운 사용자 인터페이스 컴포넌트는 이용할 수 없다.

UWP 데스크톱 UI의 개선
핵심 UWP 플랫폼을 전달하는 작업이 대부분 마무리되면서, 현재 마이크로소프트는 관련 기능을 구형 SDK로 역이식하는 방법을 개발하고 있다. 목표는 스스로 ‘현대적 애플리케이션’이라고 칭하는 것과 데스크톱 애플리케이션을 더욱 근접시키는 것이다. 데스크톱에 치중하는 최신 UWP 컨트롤 세트는 이런 과정의 일부이고, 이들 컨트롤을 구형 소프트웨어 코드에 이식하는 방법, 구형 애플리케이션의 신규 버전 제작을 용이하게 하는 신규 배치 모델들이 이에 동반된다.

UWP의 윈도우 레이아웃은 컨트롤과 공간 설계의 많은 부분을 태블릿에서 처음 쓰인 윈도우 8 WinRT로부터 물려받았다. 윈도우 10은 데스크톱 애플리케이션에 치중하기 때문에 이는 화면 낭비가 심한 애플리케이션으로 이어진다. 8인치 태블릿의 단일 화면에서 문제 없이 작용했더라도 15인치 노트북과 28인치 모니터라면 이야기가 다르다. 윈도우 10의 메일 앱 패키지와 아웃룩 2016을 비교해보면 UWP 레이아웃에서 소실된 정보가 얼마나 많은지 알게 된다.

2018년 가을로 예정된 윈도우 10 빌드 1809 릴리즈와 함께 나오는 새로운 표준 UWP 뷰는 정보 밀도가 15% 증가한다. 대단한 변화는 아니지만 메일 목록 보기에 이메일 메시지를 두어 개 추가하기에는 충분하다. 그리고 이는 유일한 선택지가 아니다. 미니 UWP 컨트롤 뷰가 있어서 화면에 훨씬 더 많은 정보를 추가할 수 있다. 밀도가 덜한 UWP 레이아웃에서 모든 터치 및 펜 제공성에 여전히 접근할 수 있다. 그러나 이와 동시에 구형 윈도우 UI에서 가능했던 레이아웃들을 복제할 수 있다.

UWP 컴포넌트를 Win32 애플리케이션에 추가하기
밀도 높은 레이아웃을 UWP로 가져온다면 전면적 애플리케이션 재작성에 도움이 된다. 그러나 기반 코드의 변경 없이 UWP 기능들을 이용하고 싶다면? 신규 XAML 아일랜드(Islands) 기능을 이용하면 된다. 이는 기존의 WinForms 또는 WPF 컨트롤들을 UWP 대응물로 교체해 준다. 이들을 현행 디자인에 적용해 UWP 기능을 이용할 수 있게 되는 것이다. XAML 아일랜드에 의해 손글씨 기능을 기존 코드에 신속히 추가할 수 있고, 또는 마이크로소프트의 신규 Fluent Design 언어를 이용할 수 있어서 애플리케이션을 대대적으로 변경할 필요 없이 신속히 업데이트할 수 있다.

빌드 2018에서 ‘간단한 버튼’이라고 칭해진, 일반 컨트롤을 위한 UWP XAML은 WPF 및 WinForms 래퍼(wrapper)로 래핑된다. 구 버전으로의 폴백(fallback)이 있으므로 하나의 바이너리가 윈도우 10과 윈도우 7 애플리케이션에서 여전히 유효하다. 하지만 윈도우 7의 경우 윈도우 10에서 실행되는 코드에 이용할 수 있는 UI 또는 운영체제 수준의 기능은 이용할 수 없다.

XAML 아일랜드에 딸려오는 또 다른 보너스는 최신 엣지 기반 WebView 컨트롤에 액세스할 수 있다는 것이다. 기존의 IE 기반 WebView 컨트롤은 최소한의 업데이트만을 받기 때문에, 사용자는 웹 컴포넌트 안에서 보다 최신의 자바스크립트는 물론 더 새로운 HTML 및 CSS 기능을 이용할 수 있다. 아울러 추가 코드 없이 펜 지원을 추가할 수 있는 클라우드 기반의 잉크 어낼리시스(Ink Analysis) 같은 새로운 폼 기능도 이용할 수 있다.

WebView 지원을 시작으로, 윈도우 10의 현행 인사이더 빌드에서 XAML 아일랜드를 사용할 수 있다. 2018년 가을쯤 최종 릴리즈가 나오기 전에 다른 컨트롤도 추가될 것이다.

마이크로소프트는 기존의 공개 커뮤니티 컨트롤 툴킷 디자인 프로세스를 통해 작업을 진행하기 때문에, 또 대다수 작업이 깃허브(GitHub) 상에서 이루어기 때문에 개발자가 XAML 아일랜드가 지원할 컨트롤을 결정하는 데 영향을 미칠 수 있다.

그러나 모든 컨트롤을 XAML 아일랜드가 지원한다는 것은 아니다. 기존의 컨트롤에 적절한 래퍼를 추가하는 데에는 수많은 작업이 필요하다. 그리고 소스 컨트롤이 없거나 오래 전에 잊혀진 서드파티 컨트롤은 변경되지 않는다. 마이크로소프트는 맟춤형 컨트롤의 래핑을 지원하는 툴을 제공할 것이라고 약속했지만, 2019년에나 기대할 수 있을 것으로 보인다.

기존 코드를 위한 신규 인스톨러
데스크톱 애플리케이션을 현대화하는 이 새로운 접근법의 마지막 부분은 새로운 인스톨러 모델과 .Net 자체를 배치하는 새로운 방식이다. 이 접근법의 핵심 측면은 .Net Core 3.0에서 데스크톱 애플리케이션을 지원하는데 집중하는 것이다. .Net Core의 핵심 역할은 여전히 UI가 없는 크로스 플랫폼 애플리케이션을 지원하는 것이지만, 이는 작은 크기와 더불어 .Net Standard를 통한 .Net API의 지원이 증가함에 따라 독립적으로 설치되고 관리되는 데스크톱 애플리케이션에 이상적이다.

.Net Core와 필수 애플리케이션 코드를 단일 배치 컨테이너로 취합함으로써(bundling), 더 이상 데스크톱 디바이스의 .Net 버전을 유지하는 것을 걱정할 필요가 없다. 앱 실행에 필요한 모든 것이 앱과 함께 있다. 상이한 앱이 동일 라이브러리의 상이한 버전을 필요로 하더라도 버전닝(versioning) 문제가 없다. 각 앱은 해당 라이브러리의 자체적인 격리 사본을 가지고 있기 때문이다.

새로운 배치 패키지인 MSIX가 이와 밀접하게 연관된다. 이는 윈도우의 익숙한 배치 툴을 대다수 취합하고, 직접 또는 마이크로소프트 스토어를 통해 배치할 수 있다. 기존의 MSI와 .appx 패키지는 새로운 포맷으로 변환될 수 있다. IT 전문가는 애플리케이션 패키지와 별도로 커스터마이징을 관리할 수 있다. 각각의 신규 MSIX에 공통 커스터마이징 팩을 단순히 추가함으로써 새로운 릴리즈와 업데이트의 배치가 한층 쉬워진다. 소프트웨어 코드는 윈도우 10 상의 격리된 컨테이너에서 실행할 수 있다. 이는 . appx 격리 모드 상에서 구축되어 데스크톱 브리지 변환 코드와 UWP 앱을 모두 호스팅한다.

마이크로소프트의 하위 호환성 이력을 보면 개발자와 사용자에게 주요 플랫폼 업그레이드의 혜택을 주기 어렵다. 그렇지만 모든 것을 지원하는 윈도우 릴리즈에서 실행될 것이라면 굳이 코드를 업그레이드할 필요가 있겠는가?

애플리케이션 업데이트 및 배치에 있어서의 새로운 길을 제공함으로써 기존의 코드를 제시함과 아울러 신구 애플리케이션을 충돌 없이 나란히 실행할 수 있는 여지가 생겼다. 마지막에는 마이크로소프트가 기업의 윈도우 10 마이그레이션을 촉진하는 데 필요한 구성요소를 제공할 수도 있을 것이다.  editor@itworld.co.kr


X