'WPF의 현대적 재해석' 아발로니아 UI의 이해

마이크로소프트가 윈도우 XP의 후속작을 한참 개발할 당시, 업체는 데이터베이스 기반 객체 파일 시스템 WinFS, 웹 서비스에 기초한 새로운 의사소통 툴 세트 인디고(Indigo, 코드명), 그래픽 설명 언어에 기초한 새로운 표시 레이어 아발론(Avalon, 코드명) 등 이른바 ‘롱혼의 3가지 기둥’을 중심으로 한 '롱혼(Longhorn)' 전략을 갖고 있었다. 그러나 결국은 이 중 인디고와 아발론만 살아남아 닷넷(.NET)의 WCF(Windows Communication Framework)와 WPF(Windows Presentation Framework)로 윈도우 비스타(Vista)에 포함됐다.
 

WPF는 20년이 지난 지금도 여전히 강력하며 많은 닷넷 프레임워크 애플리케이션을 지원한다. 하지만 크로스 플랫폼 닷넷 6으로의 전환으로 WPF는 다소 뒤쳐졌다. 여전히 오픈 소스 닷넷 개발에 포함되어 있기는 하지만 윈도우 애플리케이션 지원으로만 제한된 상황이다. 즉, 이를 활용해 리눅스나 맥OS에서 구동하는 코드를 작성할 수는 없다. 결국 WPF 기반 코드를 닷넷 프레임워크에서 닷넷 6 이상으로 가져오기 힘들어졌고, WPF, UWP(Universal Windows Platform), 윈UI 3(Windows UI Library)을 윈도우 앱 SDK로 통합할 때도 마찬가지다.
 

아발로니아, 최신 애플리케이션을 위한 WPF의 재설계 

여기에서 등장하는 것이 바로 아발로니아(Avalonia)다. XAML 기반 WPF 애플리케이션을 최신 크로스 플랫폼 세계로 가져오는 방법을 제공한다. 아발로니아 기반 코드는 윈도우 외에도 맥OS, 리눅스에서 구동할 수 있으며, x86, x64뿐 아니라 ARM을 네이티브로 지원한다. 최신 아발로니아 빌드는 대부분  데스크톱 애플리케이션을 지원하는 데 방점이 찍혀 있지만, 모바일 애플리케이션 지원도 개발 중이며 현재 공개 프리뷰 상태다. 여기에는 iOS, 안드로이드, 웹어셈블리(WebAssembly)까지 포함된다. 깃허브(GitHub) 저장소에서 최신 개발 성과를 확인하고 직접 개발에 참여할 수 있다.

아발로니아는 C# 애플리케이션을 위해 개발됐으며, 주요 개념을 공유한다. 그러나 WPF의 직접적인 이식은 아니다. 기존의 WPF 컨트롤을 아발로니아 기반 애플리케이션에 넣을 수 없으며, 대신 이를 포팅(Porting)해야 사용할 수 있다. 이유는 아발로니아의 주요 개념 중 일부가 WPF보다 웹 개발과 더 긴밀하게 관련돼 있기 때문이다. 예를 들어, 아발로니아는 여전히 XAML 디스플레이 마크업 언어에 기초하고 있으며, 스타일링은 CSS에 가깝게 처리되고 스타일(Style)은 CSS 같은 문법을 사용하고 자체 콜렉션이 있다. 다른 주요 차이점으로는 아발로니아가 데이터를 처리하는 방식, 데이터템플릿(DataTemplate)을 인터페이스와 파생된 클래스로 확대하는 것, 자체 콜렉션이 있는 것 등이다.
 

아발로니아 설치 및 사용 

아발로니아를 사용하는 것은 다른 일련의 닷넷 부가기능을 사용하는 것과 비슷하다. C# 개발을 위해 제트브레인스 라이더(JetBrains Rider)를 사용하고 있다면 아발로니아가 내장돼 있을 것이다. 그렇지 않으면 단순히 실시간 프리뷰와 함께 XAML 디자이너가 포함된 비주얼 스튜디오 확장기능을 설치하면 된다. 실제로, 라이더용 디자이너는 여전히 개발 중이며 애플리케이션용 아발로니아 UI를 구축하고 설계하기 위해 2가지 툴 모두 필요할 가능성이 높다. 익숙한 리샤퍼(ReSharper)에는 아발로니아로 작업하는 툴이 포함돼 있어 분석 툴과 코드 완성 기능을 통해 개발 속도를 높일 수 있다.

이들을 설치하면 툴을 바로 사용할 수 있다. WPF 또는 UWP 코드를 개발한 경우 XAML 구현이 매우 비슷하다. XAML을 사용해 앱 레이아웃과 이면의 코드를 설계해 상호작용을 추가하면 된다. 데이터 바인딩(Binding)은 코드와 컨트롤 사이의 연결을 관리한다. 

아발로니아는 보편적인 컨트롤을 제공하며, 이벤트 프레임워크를 통해 코드에 상호작용을 제공한다. 컨트롤은 광범위하며, 레이아웃은 다양한 창과 디스플레이 크기에 맞춰 상대적인 위치 설정을 사용한다. 컨트롤은 레이아웃(그 자체가 일련의 계층적 컨트롤 세트)에 위치와 공간 요건에 관한 정보를 제공하고, 레이아웃은 컨트롤을 표시하기 위한 정보를 제공한다. 

아발로니아의 기본 그래픽은 크기가 고정된 기기 독립적인 픽셀이다. 모든 컨트롤과 그래픽 요소는 해상도와 독립적이다. 1/96인치로 정의되어 있기 때문에 디스플레이의 가용 DPI로 자동 맵핑 된다. 기본 도형 라이브러리를 사용해 자체 컨트롤을 구성하거나 레이아웃에 확장 가능한 디자인 및 레이아웃을 추가할 수 있다. 아발로니아의 애니메이션 모델은 CSS와 유사하기 때문에 역동적인 컨트롤을 통해 상호작용이나 창 변화를 표현할 수 있다.

마이크로소프트가 최신 GUI 기반 앱에 선호하는 디자인 패턴은 자체 MAUI 크로스 플랫폼 UI 툴에 사용하는 MVVM(model-view-viewmodel) 패턴이며, 아발로니아도 같은 접근방식을 도입했다. UI 레이어를 애플리케이션과 따로 유지해야 할 때 합리적이며, 바인딩을 사용해 뷰(view) 및 뷰모델(viewmodel) 계층을 연결할 수 있다. 우선 아발로니아 컨트롤을 사용해 뷰를 구축하고 뷰 모델은 바인딩을 사용해 속성을 뷰의 컨트롤과 연계하면 된다. 여기에 약간의 개념상 도약이 필요하지만 이런 방식으로 유지 관리가 쉽고 다양한 장치 클래스에서 다양한 사용자 인터페이스와 사용하기 쉬운 코드를 만들 수 있다.
 

아발로니아의 브라우저 같은 데브툴 사용하기 

특히 유용한 기능은 테스트하는 코드에 브라우저 같은 데브툴(DevTools) 창을 추가하는 옵션이다. 기반 템플릿에 기초하고 있으며 디버그 모드에서 프로그램을 컴파일할 때 활성화된다. 구동하면 F12를 눌러 툴 창을 연다(또한 적절한 방법으로 전달되는 제스처 또는 기타 키 입력을 선택할 수 있다). 그러면 현재 뷰의 논리 및 시각 트리에 액세스하고 컨트롤과 그 표시 방법을 보여준다. 이 툴을 사용해 애플리케이션을 다시 컴파일 하지 않고 컨트롤의 속성을 신속하게 변경할 수 있으며 레이아웃에 어떤 스타일이 왜 적용되는지 파악할 수 있다. 

닷넷 애플리케이션에 브라우저 같은 개발자 경험을 제공하는 것은 유용한 작업 방식이며, 특히 C# 및 XAML 개발을 분리한 경우에 더 그렇다. XAML 디자이너는 일반 비주얼 스튜디오 창에서는 불가능한 방식으로 라이브 앱을 작업할 수 있어 깃허브 같은 툴에서 제공되는 소셜 코딩 모델에 가까운 더욱 역동적이고 양방향적인 코드 디자인 방식이 가능하다. 디자이너는 브랜치(Branch)를 신속하게 컴파일하고 XAML의 변경사항을 테스트한 후 새로운 디자인에 대한 pull 요청을 전송할 수 있다. 애플리케이션에 새로운 컨트롤이 추가되지 않는 한 C# 개발자가 개입할 필요가 없다.

개발자는 데브툴을 사용해 이벤트를 추적하고 컨트롤이 올바르게 연결되어 있는지 확인할 수 있다. 이벤트를 시각 트리에 연결해 레이아웃에 어떤 영향을 미치는지 보여줄 수 있다. 심지어 C# REPL이 있는 콘솔이 있어서 코드 조각을 애플리케이션에 추가하기 전에 실행하는 것도 가능하다.

이전의 WPF와 마찬가지로 아발로니아에는 장점이 많다. WPF 이면의 원리를 현대적인 방식으로 재해석했으며, 20년 동안의 개발 방법 변화를 반영해 최신 애플리케이션에 적용할 수 있다. WPF를 바로 대체할 수는 없지만 닷넷 프레임워크에서 닷넷 6 이상으로 그리고 윈도우 외에 다른 운영체제로 애플리케이션 디자인을 적용할 수 있다. 앞으로 추가적인 플랫폼 지원을 통해 마이크로소프트의 MAUI는 어느 정도 경쟁력을 확보할 것이며, 오픈 소스에 기반한 이 플랫폼을 통해 모든 닷넷이 활성화될 것으로 기대된다.
editor@itworld.co.kr