[로블록스]#20 - 확장 가능한 UI 구조

[로블록스]#20 - 확장 가능한 UI 구조

게임 개발에서 UI는 항상 이렇게 취급된다.
“일단 기능부터 만들고, UI는 나중에 정리하자.”
그리고 나중에 보면, 가장 먼저 망가진 것이 UI다.
이번 글에서는 로블록스에서 UI를 망치지 않는 구조를 정리한다.

---

 

 

1. UI가 가장 먼저 썩는 이유

UI는 게임의 모든 시스템과 맞닿아 있다.

• 게임 상태
• 플레이어 입력
• 데이터 변화
• 이벤트 결과

구조 없이 붙이기 시작하면 가장 먼저 복잡해진다.

UI가 더럽다는 건
UI 문제가 아니라
설계 문제다.

 

 

 

---

2. Unity Canvas 사고를 그대로 가져오면 안 되는 이유

Unity에서는 Canvas 하나에 모든 UI를 올려도 어느 정도 버텨준다.

하지만 로블록스에서는 이 방식이 빠르게 한계를 드러낸다.

• ScreenGui 중첩 증가
• Visible 제어 난립
• UI Script 서로 참조

결과는 “고치기 무서운 UI”다.

 

 

 

---

3. 로블록스 UI 구조의 핵심 원칙

확장 가능한 UI는 아래 원칙을 따른다.

• UI는 상태의 결과다
• UI는 직접 판단하지 않는다
• UI는 입력만 전달한다
• UI 간 직접 참조를 금지한다

이 원칙은 16화(상태 설계)와 정확히 맞물린다.

 

 

 

---

4. 추천 UI 계층 구조

PlayerGui
 ├─ ScreenGui_HUD
 ├─ ScreenGui_Menu
 ├─ ScreenGui_Result
 └─ UIController (LocalScript)
    

핵심은 UIController 하나로 제어를 모으는 것이다.

각 ScreenGui는 “보여주기만” 한다.

 

 

 

---

5. UIController의 역할

UIController는 UI의 두뇌 역할을 한다.

• 게임 상태 수신
• 어떤 UI를 보여줄지 결정
• UI 입력을 서버로 전달

버튼은
로직을 몰라도 된다.

 

 

 

---

6. 상태 기반 UI 제어 예시

UI는 게임 상태에 따라 단순하게 반응한다.

if GameState == "PLAYING" then
  HUD.Visible = true
  Menu.Visible = false
elseif GameState == "RESULT" then
  HUD.Visible = false
  Result.Visible = true
end
    

이 구조의 장점은 상태가 늘어나도 UI가 꼬이지 않는다는 점이다.

 

 

 

---

7. 입력 처리의 올바른 위치

UI 버튼이 서버 로직을 직접 호출하면 구조는 바로 무너진다.

• 버튼 → UIController
• UIController → RemoteEvent
• 서버 → 상태 변경

이 흐름을 지키면 UI 수정이 게임 로직에 영향을 주지 않는다.

 

 

 

---

8. UI 확장이 쉬워지는 순간

구조가 잡히면 이런 변화가 생긴다.

• 새 메뉴 추가가 두렵지 않다
• 이벤트 UI를 쉽게 붙일 수 있다
• 모바일 UI 분리도 수월하다

UI는 이제 “고통”이 아니라 “확장 포인트”가 된다.

 

 

 

---

9. 개발자가 가장 많이 하는 실수

• 버튼마다 서버 로직 연결
• UI Script끼리 직접 참조
• Visible 토글 남발

로블록스 UI는 제어 지점을 하나로 모으는 것이 핵심이다.

 

 

 

---

10. 확장 가능한 UI 구조 핵심 요약

• UI는 상태의 결과
• UIController로 제어 집중
• 입력과 로직 분리
• ScreenGui 역할 분리
• UI는 구조가 전부다

 

 

 

---

11. 마무리

여기까지가 심화 기본기다.

이제는
“어떻게 만들까”보다
“어떤 구조로 만들까”를 고민할 단계다.

---