UI Toolkit이 UGUI보다 더 나은 7가지 이유

비디오: UI Toolkit이 UGUI보다 더 나은 7가지 이유
채널: Game Dev Guide
길이: 13분 51초
출처: 자막 (자동 생성, 영문)

스크립트:
UI Toolkit은 Unity에서 여전히 매우 의견이 갈리는 기능입니다. 어떤 것을 사용해야 할지 고민 중이거나, UGUI를 사용하면서 UI Toolkit으로 전환할 적절한 시기나 이유를 기다려온 분들이라면 이 영상이 도움이 될 것입니다. 왜냐하면 UI Toolkit을 시작하는 데 필요한 초기 이해 과정이, 장기적으로 사용자 인터페이스 (UI)를 구축할 때 제공하는 많은 이점과 잠재적인 완화 효과를 고려하면 충분히 가치 있는 투자라고 믿기 때문입니다. [음악] 저는 지난 몇 년 동안 제 프로젝트에 UI Toolkit을 사용해 왔으며, 저에게는 다시 돌아갈 수 없는 선택이 되었습니다.

안녕하세요, 저는 Matt이며 Game Dev Guide에 오신 것을 환영합니다. 이 영상에서는 UI Toolkit이 UGUI와 비교했을 때 UI 구축 경험을 개선한 7가지 방식과, 왜 여러분도 프로젝트에서 UI Toolkit 사용을 고려해야 하는지에 대해 살펴보겠습니다. UI Toolkit의 몇 가지 독특한 기능과 일반적인 사용자 인터페이스 구현 시 발생하는 문제점들을 해결하는 방식을 탐구할 것이며, UGUI로 인터페이스를 구축할 때 본질적으로 어렵거나 복잡한 작업들을 UI Toolkit이 얼마나 쉽게 처리하는지도 살펴볼 것입니다. 이 영상이 끝날 때쯤이면, 여러분은 UI Toolkit 워크플로 (workflow)가 제공할 수 있는 이점에 대해 더 포괄적인 이해를 갖게 될 것이며, 기존 방식을 고수할지 아니면 저와 함께 UI Toolkit의 세계로 합류할지 판단하는 데 필요한 모든 정보를 얻게 될 것입니다.

이제 첫 번째 UI Toolkit 기능인 데이터 바인딩 (data bindings)으로 넘어가겠습니다. [음악] UGUI에서는 데이터가 변경됨에 따라 모든 UI를 동기화하기 위해 많은 상용구 코드 (boilerplate code)가 필요합니다. [음악] UI 컴포넌트가 관심 있는 데이터와 연결되려면 스크립트가 필요하며, UI를 추가하거나 변경할 때마다 동기화를 유지하기 위해 많은 코드를 작성해야 합니다. 따라서 프로젝트와 데이터가 커질수록 모든 UI를 최신 상태로 유지하는 데 더 많은 작업이 수반됩니다.

복잡한 UI 시스템은 프로젝트가 성장함에 따라 무질서해지며, 이를 유지 관리하는 데 필요한 코드 또한 함께 늘어납니다. UI Toolkit에서는 데이터 바인딩 (Data Bindings) 덕분에 단 몇 줄의 코드만으로 대부분의 UI 요소를 데이터와 동기화된 상태로 유지할 수 있습니다. 이것이 어떻게 작동하는지 예시를 보여드리겠습니다. 에디터나 UI XML 파일에서 바인딩하고자 하는 데이터 경로 (Data paths), 소스 (Sources), [music] 및 속성 (Properties)을 설정하기만 하면 됩니다. 그런 다음 스크립트에서 추적하려는 데이터를 UI 요소의 데이터 소스 (Data source) 속성에 할당하면, 모든 과정이 자동으로 처리됩니다. 게임 내에서 데이터가 변경될 때마다 UI는 해당 변경 사항을 반영하여 업데이트됩니다.

또한 변경 사항이 단방향 (One-way)인지 양방향 (Two-way)인지도 제어할 수 있습니다. 양방향 바인딩을 의미하는 후자의 경우, 입력 필드 (Input fields)가 바인딩된 데이터의 값을 즉시 설정할 수도 있습니다. 솔직히 이 겉보기에 단순해 보이는 바인딩 시스템에는 상당한 깊이가 내장되어 있으며, 이에 대해서는 영상 뒷부분에서 조금 더 자세히 살펴보겠습니다. 하지만 기본 설정을 사용하면 코드 작성 거의 없이도 몇 분 만에 간단한 UI를 구축하고 실행할 수 있습니다. 소스에 새로운 데이터를 추가하고 해당 데이터를 나타낼 추가 UI 요소가 필요한 경우, 여기 에디터에서 단순히 구성하기만 하면 자동으로 작동합니다. 데이터를 추적하며 시간을 허비하는 대신, UI 자체를 디자인하는 데 더 많은 시간을 집중할 수 있습니다.

UI 디자인에 대해 이야기하자면, UI Toolkit은 목록의 두 번째 항목인 UI 테마 (UI themes) 덕분에 UI를 시각화하는 방식에서 훨씬 더 다양한 선택지를 제공합니다. [music] 이 기능은 겉보기에는 사소해 보일 수 있지만, 깊이 생각해보면 매우 강력한 힘을 가지고 있습니다. UGUI에서는 구현하기 상당히 어려울 뿐만 아니라, 다양한 시나리오에서 활용할 수 있는 믿을 수 없을 정도로 다재다능한 기능이기 때문입니다. 이 예시에서는 세 가지 서로 다른 바이옴 (Biomes)을 설정해 두었는데, 보시는 것처럼 씬 (Scenes)을 전환할 때마다 UI가 변경되어 우리가 이동하는 환경과 일치하게 됩니다. 이는 USS 테마 (USS themes)와 변수 (Variables) 덕분에 매우 간단하게 처리됩니다.

변수 (Variables)를 사용하면 서로 다른 USS 셀렉터 (selectors) 간에 값을 공유할 수 있습니다. 변수는 사용 중인 USS 파일 내에 직접 존재하거나 최상위 USS 테마 (USS theme)에 존재할 수 있습니다. 테마는 모든 UI XML 문서가 볼 수 있는 일종의 글로벌 USS 스크립트라고 할 수 있습니다. 따라서 여기 USS 테마에 기본 색상 (base colors)이나 강조 색상 (accent colors)과 같은 몇 가지 핵심 변수를 정의한 다음, UI 요소들을 위한 다양한 스타일 시트 (style sheets)에서 이 변수들을 참조할 수 있습니다. 여기서 우리는 런타임 (runtime) 중에 테마를 전환하여, 우리가 원하는 스타일에 따라 본질적으로 이 값들을 재정의 (override)할 수 있습니다. 따라서 이 예시에서는 플레이어가 씬 (scenes)을 전환할 때, 우리가 사용 중인 테마를 교체하기만 하면 됩니다.

자, 이것 보세요, 완전히 다른 컬러 팔레트 (color palette)가 나타납니다. 지금 저는 단순히 여기서 색상을 교체하는 데 사용하고 있지만, 여러분도 상상할 수 있듯이 이는 UI가 활용할 수 있는 믿을 수 없을 정도로 다재다능한 기능입니다. 아마도 게임이 실행되는 기기에 따라 서로 다른 테마를 가질 수도 있고, 입력 장치 (input device)에 따라 UI의 전체 레이아웃 (layout)을 변경할 수도 있을 것입니다. 이것으로 잠재적으로 할 수 있는 멋진 일들이 아주 많지만, 팔레트 스왑 (palette swap)만 하더라도 UGUI로는 매우 쉽게 구현하는 것을 상상조차 하기 어렵습니다. 아마도 교체 가능한 스크립터블 오브젝트 (Scriptable Objects)를 사용하는 복잡한 보일러플레이트 (boilerplate) 아키텍처에 의존해야 할 것이고, 이를 처리하기 위해 UI 컴포넌트의 커스텀 버전을 직접 구축해야 할 것입니다. 그 시점이 되면 여러분은 기본적으로 USS가 하는 일을 훨씬 더 복잡한 방식으로 직접 수행하고 있는 셈입니다. 따라서 UI Toolkit에서 이 모든 변수를 가지고 다른 테마 파일로 교체하는 것이 확실히 정답입니다. 그리고 파일에 대한 이야기로 넘어가자면, UI Toolkit 파일은 병합 (mergeable)이 가능합니다. 이미 알고 계시겠지만, 팀 단위로 Unity를 사용할 때 가장 큰 골칫거리 중 하나는 여러 사람이 동시에 씬 (scene)이나 프리팹 (prefab)의 변경 사항을 만들려고 할 때입니다.

따라서 UGUI가 이 두 구조 모두의 일부이기 때문에, 만약 제가 UI의 특정 부분을 변경하려고 할 때

[music]
여러분이 동일한 UI의 일부를 변경해야 한다면, 소스 제어 (source control) 설정이 잘못되어 머지 충돌 (merge conflict)이 발생하거나, 제가 작업하는 동안 파일이 잠겨 있어 제가 체크인 (check in)할 때까지 기다려야만 합니다. 그런데 아차, 제가 점심을 먹으러 가버렸네요. 결국 여러분은 기다리는 동안 유튜브 영상을 보며 시간을 때우게 됩니다. 이는 대규모 프로젝트를 진행하는 과정에서 쌓여 생산성을 크게 [music] 저하시키는 교묘한 워크플로우 병목 현상 중 하나입니다. 혼자 작업한다면 큰 문제가 되지 않을 수도 있지만, 다른 사람들과 함께 작업하는 우리에게는 머지 충돌을 피하고 소스 제어 프로세스를 단순화하는 것이 매우 절실합니다. 저는 다른 팀원들과 함께 UI XML 및 USS 파일을 정기적으로 작업해 왔는데, 이 파일들은 텍스트 형식이기에 소스 제어 시스템이 문제없이 처리할 수 있었습니다. 만약 게임 개발에 적합한 훌륭한 소스 제어 솔루션을 찾고 계신다면, 이 영상의 스폰서인 Divergence를 소개해 드리겠습니다.

Divergence는 게임 개발자들의 소스 제어 문제를 해결하기 위해 처음부터 설계된 클라우드 기반 버전 제어 (version control) 솔루션입니다. 모든 규모의 프로젝트를 위해 설계되었으며, 게임 프로젝트의 확장성 있는 특성을 쉽게 처리합니다. Divergence를 사용하면 수천 개의 파일을 몇 초 만에 커밋 (commit)할 수 있으며, 사용자 속도를 늦추지 않고도 수백 개의 커밋을 처리할 수 있습니다. 기존 도구들의 오버헤드 없이 대규모 에셋을 관리하고, 충돌을 방지하며, 손쉽게 동기화할 수 있습니다. 개발자를 위해 설계된 만큼, Divergence의 빠르고 브랜칭 (branching)이 가능하며 충돌이 없고 직관적인 UI는 디자이너, 프로그래머, 아티스트 등 모든 종류의 워크플로우에 친숙합니다. 또한 Unity용 무료 Divergence 플러그인을 사용하면, 팀원들이 Unity 에디터 내에서 직접 에셋이나 코드 변경 사항을 공유, 추적 및 롤백 (roll back)할 수 있어 여러분은 항상 프로젝트에만 집중할 수 있습니다.

파일의 특수 마크업 (special markup)과 전용 병합 경고 알림 (merge warning notification)을 통해, 충돌이 발생하기 전에 미리 대처할 수 있습니다. Divergence는 설정이 간편하며 몇 분 내에 프로젝트에 통합할 수 있습니다. 가격은 프로젝트 규모에 따라 확장되므로, 필요하지 않은 기능에 비용을 지불하지 않아도 됩니다. 관대한 무료 티어 (free tier)와 더불어, 인디 및 교육용 사용자를 위한 별도의 가격 티어도 마련되어 있습니다. 또한 도움이 필요할 경우를 위해 전용 Discord 커뮤니티도 운영되고 있습니다. 만약 Divergence를 직접 사용해보고 싶다면, 아래 설명란의 링크를 클릭하거나 지금 화면의 QR 코드를 스캔하세요. 제 코드인 10 Game Dev 12를 사용하면 모든 티어에서 10% 할인을 받을 수 있으며, 동시에 채널을 후원하는 것이 됩니다. 이 영상을 후원해 준 Divergence에 감사드리며, 제가 제공하는 링크를 이용해 주시는 여러분께도 감사드립니다. 이제 다시 영상으로 돌아가서, UI Toolkit을 고려해야 할 다음 이유인 커스텀 바인딩 (custom bindings)에 대해 알아보겠습니다.

커스텀 바인딩 (custom bindings)은 UI Toolkit 워크플로우의 숨겨진 보석 같은 존재입니다. 솔직히 말해서, 이것들이 엄청나게 강력하고 본질적으로 다양한 데이터 형식 간에 동작을 공유하고 조작할 수 있게 하여 UI 요소 (UI elements)에서 다양한 동작을 구현할 수 있게 해주는데도, 이에 대한 다룸이 많지 않다는 점이 놀라울 정도입니다. 이를 이해하는 가장 좋은 방법은 UI 요소 속성 (properties)의 바인딩 로직 (binding logic)을 재정의하여 직접 제어하는 방법이라고 생각하는 것입니다. 예를 들어, 어떤 이유로든 여기 UI에 무작위 숫자 문자열을 표시하고 싶다고 가정해 봅시다. 서로 다른 소스 (sources)를 가진 세 가지 UI 요소가 있습니다. 여기 이 문자열을 무작위 숫자로 바꾸고 싶고, 이 버튼 라벨 (button label)도 무작위 숫자를 표시하게 하고 싶으며, 이 입력 텍스트 박스 (input text box) 또한 무작위 숫자를 표시하게 하고 싶습니다. 이를 수행하는 한 가지 방법은 오브젝트의 UI 스크립트 (UI script)에서 각 요소를 가져와, 이 서로 다른 요소들을 읽은 다음 그 값들을 설정하는 것입니다.

하지만 어떤 이유에서든 우리의 난수 생성기 (random number generator)가 다른 요소나 다른 문서에서도 작동하기를 원한다면, [music] 우리는 새로운 요소가 생길 때마다 이 동작을 반복해야 할 것입니다. 하지만 UI Toolkit을 사용하면, 커스텀 바인딩 스크립트 (custom binding script)를 작성한 다음 UI Builder에서 해당 스크립트를 UI XML의 다양한 속성 (properties)에 바인딩할 수 있습니다. 이것이 어떤 모습인지 보여드리겠습니다. 여기 제 커스텀 바인딩 스크립트가 있습니다. 이것은 partial class이며 custom binding 타입을 상속받습니다. 상단에 UI XML object 어트리뷰트 (attribute)를 포함하고, UI XML attribute 어트리뷰트를 사용하여 UI XML에 노출하고 싶은 모든 컨트롤 (controls)에 플래그를 지정합니다. [music] 생성자 (constructor)에서는 스크립트가 언제 업데이트될지 지정합니다. 이 예시에서는 숫자가 계속 바뀌기를 원하므로, 업데이트가 매 업데이트마다 트리거되도록 설정하겠습니다. 그런 다음 update 메서드 (method)에서 난수를 생성합니다. 우리가 바인딩하려는 속성 타입 (property type)이 유효한지 확인하기 위해 약간의 에러 핸들링 (error handling)을 수행합니다. 따라서 이 경우에는 문자열 (string) 값을 수용하는 것이라면 무엇이든 해당하며, 유효하다면 그 결과를 반환하고 그렇지 않으면 바인딩 에러 (binding error)를 던집니다. 이제 UI XML의 바인딩 창 (binding window)을 보면, 여기 드롭다운에 이 커스텀 바인딩이 나타나는 것을 볼 수 있습니다. 단순히 바인딩 타입을 선택하고 적용 (apply)을 클릭하기만 하면, 단 한 번의 클릭만으로 다양한 유형의 요소 전반에서 난수 생성기가 작동하게 됩니다. 물론 이것은 여러분이 실제로 하고 싶어 할 법한 아주 희박한 예시이긴 하지만, 이를 통해 서로 일치하지 않는 다양한 UI 컴포넌트 (components)에 동일한 동작을 적용할 수 있는 훌륭한 방법임을 이해하셨기를 바랍니다. 이와 유사하게, 이것 자체가 커스텀 바인딩은 아니지만, 컨버터 그룹 (converter groups)을 통해 바인딩을 더욱 확장할 수 있으며 데이터 컨트롤 (data control)의 특정 값이 다른 스타일 요소 (style elements)를 제어하게 할 수도 있습니다. 저는 제 캐릭터가 레벨업할 준비가 되었음을 나타내는 이 불리언 (boolean) 값을 가지고 있습니다. 또한 이 불리언 값이 true일 때 보여주고 싶은 이 UI 요소 (UI element)도 가지고 있습니다.

기본적으로 우리는 이 요소의 가시성 (visibility)을 불리언 (bool) 값에 바인딩할 수 없지만, 이 컨버터 그룹 (converter group) 스크립트를 사용하면 불리언 값을 읽어 우리가 사용할 디스플레이 스타일 (display style)을 결정하도록 하는 커스텀 컨버터 (custom converter)를 추가할 수 있습니다. 바인딩 (binding) 창에서 불리언을 바인딩하려고 할 때, 여기에 컨버터 그룹을 추가하기만 하면 성공적으로 바인딩을 연결할 수 있습니다. 이제 데이터에서 레벨 업 플래그 (level up flag)를 변경할 때마다 UI 요소가 그에 맞춰 디스플레이를 업데이트합니다. 본질적으로 매우 복잡한 동작들을 사실상 무료로 얻게 되는 셈입니다.

말이 나온 김에, 다음 포인트는 아마도 제가 UI Toolkit에서 가장 아끼는 기능일 텐데, 바로 애니메이션 (animation)이 포함되어 있다는 점입니다. 우리 모두 UI 애니메이션이 가장 큰 고충 중 하나라는 것을 알고 있습니다. UI 오브젝트를 움직이게 하려면 종종 어떤 종류의 트위닝 라이브러리 (tweening library)에 의존하여 엄청난 양의 상용구 코드 (boilerplate code)를 작성해야 하거나, 애니메이터 (animator)에서 다양한 컴포넌트들을 일일이 수동으로 애니메이션화해야 합니다.

윽.