AI로 게임 UI를 엔진에 옮기기

UI를 옮긴다는 말의 의미

Figma에서 만든 화면을 엔진에 옮긴다는 것은 이미지를 그대로 붙여 넣는 일이 아니다. 버튼은 눌려야 하고, 목록은 데이터에 따라 늘어나야 하며, 팝업은 열리고 닫혀야 한다. 해상도가 바뀌어도 중요한 정보가 잘려서는 안 되고, 게임패드나 터치 입력에서도 조작할 수 있어야 한다.

따라서 이 단계의 목표는 "Figma와 똑같이 보이는 정지 화면"이 아니라 "Figma의 의도대로 동작하는 엔진 UI"다. AI는 이 사이의 번역 작업을 도울 수 있다. 레이어 이름, 디자인 토큰, 컴포넌트 상태가 정리되어 있으면 AI는 Figma 구조를 Unity의 UI Toolkit, Canvas, Unreal의 UMG 위젯 계층으로 더 안정적으로 바꿀 수 있다.

하지만 AI가 알아서 화면의 목적을 이해한다고 기대하면 안 된다. Figma에는 시각 구조가 있고, 엔진에는 실행 구조가 있다. 둘 사이를 연결하는 기준은 사람이 먼저 정해야 한다.

AI 생성 이미지

Figma 화면을 엔진 UI 단위로 나누기

엔진으로 옮기기 전에 먼저 화면을 기능 단위로 분해해야 한다. Figma 프레임 하나가 그대로 엔진 위젯 하나가 되는 경우는 많지 않다. 게임 UI는 표시 위치, 표시 조건, 입력 방식, 데이터 갱신 주기에 따라 나누는 것이 좋다.

가장 먼저 구분할 단위는 다음과 같다.

이 분해가 중요한 이유는 각 단위의 생명주기가 다르기 때문이다. HUD는 게임 상태와 계속 연결되어야 한다. 팝업은 필요할 때 생성되거나 표시되고, 닫히면 입력 권한을 원래 화면으로 돌려줘야 한다. 상점과 인벤토리는 UI 자체보다 데이터 구조가 더 중요할 때가 많다.

AI에게도 이 단위를 알려줘야 한다. "이 Figma 화면을 구현해 줘"라고 요청하면 AI는 보이는 요소를 나열하는 수준에 머물기 쉽다. 반대로 "이 화면을 HUD 루트, 체력 표시 위젯, 무기 정보 위젯, 알림 팝업, 일시정지 메뉴로 분리하라"고 요청하면 엔진 구조에 가까운 결과를 얻을 수 있다.

정지 화면에서 상태가 있는 UI로 바꾸기

Figma 화면은 보통 특정 순간을 보여준다. 그러나 게임 UI는 여러 상태를 가진다. 버튼에는 기본, hover, pressed, disabled 상태가 있고, 체력 바에는 정상, 낮음, 위험 상태가 있다. 인벤토리 슬롯에는 비어 있음, 선택됨, 장착됨, 잠김 상태가 있을 수 있다.

엔진으로 옮길 때는 각 컴포넌트를 다음 질문으로 점검한다.

• 이 요소는 단순 장식인가, 클릭 가능한 요소인가?

• 데이터가 바뀌면 텍스트나 이미지도 바뀌는가?

• 표시되지 않는 상태가 있는가?

• 애니메이션이 필요한가?

• 마우스, 터치, 게임패드 중 어떤 입력을 받아야 하는가?

• 로컬라이징으로 글자 길이가 늘어나도 버틸 수 있는가?

예를 들어 Figma의 shop-item-card는 엔진에서 단순 이미지가 아니다. 아이콘, 이름, 가격, 희귀도 배지, 구매 버튼, 품절 상태, 선택 상태를 가진 반복 위젯이다. AI에게 이 사실을 알려주지 않으면 카드 전체를 하나의 배경 이미지처럼 처리할 수 있다. 그러면 데이터 변경, 접근성, 입력 처리, 애니메이션을 나중에 다시 만들어야 한다.

Unity에서 옮기는 방식: UI Toolkit과 Canvas

Unity에서는 프로젝트 성격에 따라 UI Toolkit 또는 Canvas 기반 UI를 선택할 수 있다. UI Toolkit은 UI를 개발하기 위한 기능과 도구 모음이며, 구조는 UXML 또는 C#으로 만들고 스타일은 USS로 지정할 수 있다. 런타임 UI와 이벤트 처리도 지원한다¹. Figma의 레이어와 디자인 토큰이 잘 정리되어 있다면 UI Toolkit은 구조와 스타일을 분리하기 좋다.

UI Toolkit으로 옮길 때는 다음처럼 매핑한다.

예를 들어 Figma의 inventory-slot 컴포넌트는 Unity에서 InventorySlot.uxml, inventory-slot USS 클래스, InventorySlotController.cs로 나눌 수 있다. UXML은 아이콘과 수량 텍스트의 구조를 담고, USS는 크기와 색상, 선택 테두리를 담는다. C#은 클릭 이벤트, 선택 상태, 아이템 데이터 연결을 담당한다.

Canvas 기반 UI는 기존 uGUI 프로젝트, 월드 스페이스 UI, 이미 만들어 둔 프리팹과 애니메이션을 활용할 때 여전히 많이 쓰인다. 이 경우 Figma의 프레임은 Canvas 또는 Panel 프리팹으로, 오토 레이아웃은 Horizontal Layout Group, Vertical Layout Group, Grid Layout Group 같은 레이아웃 컴포넌트로 옮긴다. 위치 고정이 필요한 HUD 요소는 Anchor와 Pivot을 명확히 잡아야 한다. 해상도 대응은 Canvas Scaler 설정과 함께 확인한다.

Unity에서 AI에게 맡기기 좋은 일은 다음과 같다.

• Figma 레이어 목록을 보고 UI Toolkit UXML 초안 만들기

• 디자인 토큰을 USS 클래스 이름으로 정리하기

• Canvas 프리팹 계층 설계안 만들기

• 버튼 클릭, 팝업 열기, 목록 갱신용 C# 스크립트 초안 만들기

• Play Mode에서 확인할 UI 테스트 체크리스트 만들기

반대로 사람이 판단해야 할 일도 있다. 텍스트 가독성, 입력 흐름, 게임패드 포커스 순서, 중요한 정보의 시선 흐름, 애니메이션의 속도감은 자동 생성 결과만 보고 결정하면 안 된다.

Unreal에서 옮기는 방식: UMG 위젯 계층

Unreal에서는 Figma 컴포넌트를 UMG의 Widget Blueprint 단위로 재구성한다. 큰 화면 하나를 한 개의 위젯에 모두 넣기보다, 반복되거나 상태가 있는 요소를 작은 User Widget으로 분리하는 편이 유지보수에 좋다.

예를 들어 인벤토리 화면은 다음처럼 나눌 수 있다.

• WBP_InventoryScreen: 전체 인벤토리 화면 루트

• WBP_InventoryGrid: 슬롯 목록을 배치하는 영역

• WBP_InventorySlot: 아이템 아이콘, 수량, 선택 테두리

• WBP_ItemDetailPanel: 선택한 아이템 설명과 능력치

• WBP_ConfirmPopup: 버리기, 장착 해제 같은 확인 팝업

Figma의 레이아웃은 UMG의 패널로 다시 구성한다. 자유 배치가 필요한 전체 화면에는 Canvas Panel을 쓸 수 있고, 가로·세로 정렬에는 Horizontal Box와 Vertical Box가 적합하다. 격자형 인벤토리에는 Uniform Grid Panel이나 Wrap Box를 검토할 수 있다. 여러 이미지를 겹치는 슬롯에는 Overlay가 유용하다.

Figma 컴포넌트는 Unreal에서 다음 요소로 바뀐다.

UMG로 옮길 때 특히 주의할 점은 입력 모드다. PC 마우스 중심 UI인지, 콘솔 게임패드 중심 UI인지에 따라 포커스 흐름이 달라진다. Figma에서는 버튼이 그려져 있어도, Unreal에서는 어떤 위젯이 처음 포커스를 받을지, 위아래 입력으로 어디로 이동할지, 팝업이 열렸을 때 뒤쪽 화면 입력을 막을지 정해야 한다.

AI에게 Unreal UI 작업을 요청할 때도 "화면을 만들어라"보다 "다음 Figma 컴포넌트를 UMG Widget Blueprint 계층으로 분해하고, 각 위젯의 변수, 이벤트, 애니메이션 상태를 제안하라"가 낫다. MCP 기반 자동화를 쓴다면 실제 에셋 생성 전에 위젯 계층 계획을 먼저 받고, 승인 후 작은 단위로 생성하게 해야 한다.

AI에게 줄 변환 요청서 만들기

AI가 Figma 구조를 엔진 UI로 옮기려면 시각 설명만으로는 부족하다. 최소한 다음 정보가 필요하다.

• 대상 엔진과 UI 시스템: Unity UI Toolkit, Unity Canvas, Unreal UMG 중 무엇인지

• 기준 해상도와 대응 범위: 예를 들어 1920×1080 기준, 16:9와 21:9 지원 여부

• 입력 방식: 마우스, 터치, 게임패드, 키보드

• Figma 레이어 이름: 역할 기반 이름으로 정리된 계층

• 디자인 토큰: 색상, 폰트, 간격, 라운드, 그림자

• 컴포넌트 상태: default, hover, pressed, disabled, selected, locked 등

• 데이터 연결: 체력, 재화, 아이템 목록, 퀘스트 상태처럼 런타임 값이 들어가는 부분

• 출력 형식: UXML/USS/C#, Canvas 프리팹 계획, UMG 위젯 계층 등

• 검증 기준: 화면 비교, 리사이즈, 입력 테스트, 상태 전환 테스트

다음은 Unity UI Toolkit으로 인벤토리 화면을 옮길 때 사용할 수 있는 요청 예시다.

목표: Figma의 Inventory 화면을 Unity UI Toolkit 런타임 UI 구조로 변환한다.

대상:
- Unity 6
- UI Toolkit 사용
- 기준 해상도 1920x1080, 16:9와 21:9 대응
- 입력: 마우스와 게임패드

Figma 구조:
- inventory-screen
  - header-title
  - currency-bar
  - inventory-grid
    - inventory-slot / states: empty, filled, selected, locked
  - item-detail-panel
  - action-button-equip / states: default, disabled, pressed
  - action-button-drop / states: default, disabled, pressed

디자인 토큰:
- color.surface.panel
- color.action.primary
- color.state.selected
- spacing.8, spacing.12, spacing.16
- radius.card.12
- font.body, font.title

요청:
1. UXML 계층을 제안한다.
2. USS 클래스 이름과 토큰 매핑을 제안한다.
3. InventorySlotController와 InventoryScreenController의 역할을 나눈다.
4. 게임패드 포커스 이동 규칙을 제안한다.
5. 구현 후 확인할 테스트 체크리스트를 작성한다.

제약:
- Figma 레이어를 하나의 큰 이미지로 처리하지 않는다.
- 아이템 목록은 런타임 데이터로 갱신될 수 있어야 한다.
- 하드코딩 색상값 대신 토큰 이름을 우선 사용한다.

Unreal UMG라면 출력 항목을 WBP_InventoryScreen, WBP_InventorySlot, WBP_ItemDetailPanel 같은 Widget Blueprint 계획으로 바꾸면 된다. 중요한 것은 AI에게 코드만 요구하지 않는 것이다. 구조, 상태, 데이터, 입력, 검증을 함께 요구해야 엔진에서 실제로 쓸 수 있는 결과에 가까워진다.

옮긴 뒤에는 비교보다 사용을 테스트한다

Figma와 엔진 화면을 비교하는 일은 필요하다. 색상, 간격, 폰트 크기, 아이콘 위치가 의도와 크게 다르면 사용자는 다른 화면으로 느낀다. 하지만 픽셀 단위 비교만으로는 부족하다. 게임 UI는 사용 중에 평가해야 한다.

다음 항목을 반드시 확인한다.

• 해상도를 바꿔도 HUD가 잘리지 않는가?

• 긴 언어 문자열이 들어와도 버튼과 카드가 깨지지 않는가?

• disabled 상태의 버튼이 실제로 입력을 막는가?

• 게임패드로 모든 주요 버튼에 접근할 수 있는가?

• 팝업이 열렸을 때 배경 UI가 조작되지 않는가?

• 목록 데이터가 0개, 1개, 매우 많을 때 모두 자연스러운가?

• 애니메이션이 정보 확인을 방해하지 않는가?

AI가 만든 UI 계층은 이 검증 과정에서 자주 수정된다. 이것은 실패가 아니다. Figma에서 엔진으로 옮기는 작업은 한 번의 변환이 아니라 "구조화 → 구현 → 실행 확인 → 수정"의 반복이다. AI의 가치는 이 반복에서 드러난다. 사람이 매번 빈 파일에서 시작하지 않도록 초안을 만들고, 반복 요소를 정리하고, 누락된 상태를 찾아주는 데 강하다.

첫 번째 실전 성과는 간극을 줄이는 것이다

AI 제작 파이프라인의 첫 번째 실전 성과는 거창한 자동 완성이 아니다. 디자인과 엔진 사이의 간극을 줄이는 것이다. Figma의 컴포넌트가 Unity의 UXML, USS, C# 컨트롤러로 이어지고, Unreal의 UMG Widget Blueprint와 입력 흐름으로 이어지면 팀은 같은 화면을 두고 더 적은 오해로 대화할 수 있다.

잘 정리된 Figma 파일은 AI에게 좋은 입력이 되고, 잘 나뉜 엔진 UI 계층은 다음 자동화의 기반이 된다. 이 장의 핵심은 단순하다. UI를 이미지로 옮기지 말고, 역할과 상태와 입력을 가진 구조로 옮겨야 한다. AI는 그 변환을 빠르게 도와줄 수 있지만, 어떤 구조가 좋은지 결정하고 실제 플레이 경험을 검증하는 일은 여전히 제작자의 몫이다.

참고

¹Unity - Manual: UI Toolkit