게임아카데미게임·웹툰·AI 진로 상담
유니티는 혼자서도 게임 하나를 끝까지 만들 수 있게 해 주는 엔진입니다. 수업은 C 언어로 변수와 조건문, 반복문 같은 프로그래밍 기본기를 먼저 다지고, C#…
UGUI: 장면에 오브젝트를 놓아 만드는 UI
UGUI에서는 하이어라키 창에 Canvas를 만들고, 그 아래에 Image, Text, Button 같은 오브젝트를 자식으로 넣어 화면을 구성합니다. 각 요소는 RectTransform으로 위치와 크기를 정하고, 앵커로 화면 가장자리에 붙일지 가운데 둘지를 지정합니다. 클릭 같은 입력은 장면에 있는 EventSystem이 처리합니다.
장점은 눈에 보이는 그대로 만든다는 것입니다. 뷰포트에서 버튼을 끌어 옮기고, 인스펙터에서 색을 바꾸고, 애니메이터로 버튼을 흔드는 연출을 넣을 수 있습니다. 오래 쓰인 방식이라 자료와 예제, 에셋 스토어 패키지가 많아 막혔을 때 해결책을 찾기 쉽습니다.
단점은 화면이 복잡해질수록 오브젝트가 많아져 관리가 어려워진다는 것입니다. 같은 스타일의 버튼 수십 개의 색을 바꾸려면 프리팹을 잘 설계해 두지 않은 이상 하나씩 고쳐야 할 때도 있습니다. 요소 하나만 바뀌어도 캔버스 전체를 다시 그리는 경우가 있어 성능 관리에도 신경 써야 합니다.
UI 툴킷: 구조와 스타일을 파일로 나눠 만드는 UI
UI 툴킷은 웹 개발 방식에서 영향을 받았습니다. 어떤 요소가 어떤 순서로 들어가는지는 UXML 파일에, 색과 크기, 여백 같은 모양은 USS 파일에 씁니다. USS는 웹의 CSS와 문법이 비슷해서 웹 경험이 있는 사람은 금방 적응합니다. 장면에서는 UIDocument 컴포넌트가 이 파일들을 불러와 화면에 띄웁니다.
직접 코드를 쓰지 않아도 UI Builder라는 편집 창에서 요소를 끌어다 놓고 스타일을 지정할 수 있습니다. 버튼 스타일을 USS 클래스 하나로 정해 두면, 그 클래스를 쓰는 모든 버튼의 모양이 한 번에 바뀝니다. 요소 배치는 기본적으로 위아래나 좌우로 흘러가며 쌓이는 방식이라, 화면 크기가 달라져도 자동으로 정렬되도록 만들기 좋습니다.
유니티 에디터 자체의 창과 인스펙터도 UI 툴킷으로 만들어지고 있어, 에디터 확장 도구를 만들 때는 사실상 기본 선택지가 되었습니다. 게임 화면용 기능도 버전이 올라가며 계속 보강되고 있으니, 쓰는 유니티 버전의 공식 문서에서 지원 범위를 확인하는 것이 좋습니다.
같은 기준으로 비교해 보기
| 기준 | UGUI | UI 툴킷 |
|---|---|---|
| 만드는 방식 | 게임 오브젝트를 장면에 배치 | UXML 구조 + USS 스타일 파일 |
| 스타일 일괄 변경 | 프리팹 설계에 의존 | 스타일 클래스로 한 번에 변경 |
| 연출과 애니메이션 | 애니메이터, 트윈 에셋 활용이 익숙함 | USS 전환 효과 중심, 복잡한 연출은 코드 필요 |
| 파티클·셰이더와 섞기 | 비교적 자유로움 | 제약이 있어 방법을 찾아봐야 함 |
| 자료와 예제 | 매우 많음 | 늘어나는 중 |
| 잘 맞는 화면 | 연출이 많은 전투 HUD, 월드 속 UI | 설정, 인벤토리 같은 정보 많은 화면, 에디터 도구 |
표의 내용은 일반적인 경향입니다. 버전에 따라 UI 툴킷의 기능이 빠르게 늘고 있어, 몇 년 전 자료의 '안 된다'는 설명이 지금은 맞지 않을 수 있습니다. 결정 전에 쓰려는 기능을 작은 테스트 장면으로 직접 확인해 보는 것이 가장 확실합니다.
프로젝트에서 고르는 실전 기준
화면 연출이 화려하고 이펙트와 UI가 뒤섞이는 게임이라면 UGUI가 아직 다루기 편한 경우가 많습니다. 스킬 버튼이 빛나고 데미지 숫자가 튀어 오르며 파티클이 겹치는 액션 게임 HUD가 대표적입니다. 캐릭터 머리 위 체력바처럼 3D 공간에 붙는 UI도 UGUI로 만드는 자료가 풍부합니다.
반대로 메뉴와 표, 목록이 많고 디자인 규칙을 일관되게 지켜야 하는 화면은 UI 툴킷의 장점이 큽니다. 설정 창, 상점, 인벤토리, 퀘스트 목록처럼 같은 형태가 반복되는 화면을 스타일 파일로 통일하면 수정이 빨라집니다. 웹 프런트엔드 경험이 있는 개발자라면 진입 장벽도 낮습니다.
한 프로젝트 안에서 둘을 섞어 쓰는 것도 가능합니다. 예를 들어 전투 HUD는 UGUI로, 메뉴 화면은 UI 툴킷으로 나누는 식입니다. 다만 입력 처리와 화면 겹침 순서를 두 시스템에서 따로 관리해야 하므로, 섞기로 했다면 어디서 경계를 나눌지 미리 정해 두세요.
팀 구성도 기준이 됩니다. UI 디자이너가 직접 유니티에서 화면을 다듬는 팀이라면 눈으로 보며 배치하는 UGUI가 편할 수 있고, 프로그래머가 디자인 시안을 받아 구현하는 팀이라면 스타일 규칙을 파일로 관리하는 UI 툴킷이 수정 요청에 대응하기 쉽습니다. 기술만이 아니라 누가 UI 파일을 만지게 될지도 함께 따져 보세요.
처음 배우는 사람에게 권하는 순서
취업 준비 관점에서는 UGUI를 먼저 확실히 다루는 것이 안전합니다. 이미 서비스 중인 많은 게임 프로젝트가 UGUI로 만들어져 있어, 입사 후 바로 마주칠 가능성이 높기 때문입니다. 앵커와 레이아웃 그룹, 캔버스 분리 같은 기본기를 익혀 두면 어떤 프로젝트에 가도 적응이 빠릅니다.
그다음 UI 툴킷으로 같은 화면을 다시 만들어 보세요. 설정 메뉴 하나를 두 방식으로 각각 만들고 소요 시간과 수정 편의성을 비교해 보면, 어떤 화면에 어떤 방식이 맞는지 자기 기준이 생깁니다. 포트폴리오에 이 비교 과정을 정리해 두면 기술 선택을 고민할 줄 아는 개발자라는 인상도 줄 수 있습니다. 지원하려는 회사의 장르를 기준으로 UI 공부 범위를 정하고 싶다면, 목표 직무에 맞춘 학습 우선순위를 SBS아카데미게임학원 유니티3D(Unity) 과정 상담에서 한번 정리받아 보세요.
자주 묻는 질문
UI 디자이너도 UI 툴킷을 알아야 하나요?
필수는 아니지만, 스타일 파일 구조를 이해하면 개발자에게 넘길 디자인 규칙을 정리하기 쉬워집니다. 팀이 UI 툴킷을 쓴다면 UI Builder 정도는 다뤄 보는 것이 협업에 도움이 됩니다.
NGUI 같은 외부 UI 도구는 어디에 해당하나요?
UGUI가 나오기 전부터 쓰이던 외부 에셋으로, 오브젝트를 배치하는 방식이라 UGUI와 사고방식이 비슷합니다. 오래된 프로젝트에서 여전히 볼 수 있습니다.
가까운 캠퍼스에서 유니티 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.