[Unity] 견고한 UI 설계를 위한 8가지 고려사항 (김기헌 튜터님 특강 정리)

안녕하세요! 스파르타내일배움캠프 김기헌 튜터님의 '유니티 UI 설계 시 고려사항' 특강 내용을 학습하며 정리한 포스트입니다.

기획이 불분명한 상황부터 팀원과의 협업까지, 실무에서 마주할 수 있는 다양한 문제에 대처하는 방법을 다루고 있습니다. 버그를 줄이고 확장성 높은 UI를 만드는 데 이 내용이 큰 도움이 되기를 바랍니다.

---

1. 텍스트/숫자 범위: UI가 깨지지 않게 설계하기

문제: 기획서에 나온 내용대로만 UI를 만들면, 기획 범위를 벗어나는 긴 텍스트나 큰 숫자가 들어왔을 때 UI가 깨집니다.

• 해결:
  1. UI 요소는 항상 여유 공간을 확보하여 설계합니다.
  2. 기획자와 협의하여 표현할 값의 최대치를 명확히 정하고 그에 맞게 설계합니다.
  3. int(~21억), long(~922경), BigInteger(무한대) 등 데이터의 크기에 맞는 자료형을 선택하고, 성능을 고려해야 합니다.

자료형	크기	범위 (대략)
int	32-bit	-21억 ~ 21억
long	64-bit	-922경 ~ 922경
unsigned long	64-bit	0 ~ 1844경
BigInteger	가변	이론상 무한대 (성능 주의)

2. 다국어 지원: 3배의 법칙

문제: 독일어처럼 단어에 성(gender)이 붙어 문장이 길어지는 언어는 한국어나 영어보다 훨씬 많은 공간을 차지합니다.

• 해결: 글로벌 출시를 조금이라도 고려한다면, 텍스트 영역은 원문 길이의 최소 2배, 안전하게는 3배까지 여유 공간을 확보하는 것이 좋습니다. 미래의 재작업을 막는 최고의 예방법입니다.

3. InputField: 안정적인 입력 처리

• Content Type: InputField의 Content Type을 Integer Number로 설정하여 숫자 외 입력을 1차적으로 막습니다.
• 한글(IME) 문제: InputField 포커싱 시 IME 모드를 강제로 비활성화하거나, OnValueChanged 이벤트에서 정규식(Regex)으로 숫자 외 문자를 제거하는 로직을 추가하여 막을 수 있습니다.
• 가독성: ToString("N0") 포맷을 이용해 세 자리마다 콤마(,)를 자동으로 찍어주면 사용자 경험이 크게 향상됩니다.

4. Singleton: DontDestroyOnLoad의 함정

중요: DontDestroyOnLoad는 하이어라키(Hierarchy)의 최상단(Root)에 있는 게임 오브젝트에만 정상적으로 작동합니다.

• 문제: UI 매니저(싱글톤)를 Canvas의 자식으로 두면, 씬 전환 시 Canvas가 사라지면서 매니저도 함께 파괴됩니다.
• 해결: 싱글톤 매니저는 Canvas와 분리된 독립적인 최상단 오브젝트로 만들어야 합니다.

5. 팀 프로젝트: 프리팹으로 충돌 방지하기

• 문제: 여러 명이 하나의 씬, 특히 하나의 Canvas를 수정하면 머지 충돌(Merge Conflict)이 발생하기 쉽습니다.
• 해결: UI의 기능 단위(입금 패널, 출금 패널, 인벤토리 등)로 프리팹(Prefab)을 만들어 작업을 분리합니다. 각 팀원은 자신이 맡은 프리EB만 수정하면 충돌을 최소화할 수 있습니다.

6. 하위 캔버스: Graphic Raycaster를 잊지 말자

• 문제: 프리팹으로 분리한 UI의 버튼 클릭이 안 되는 경우가 있습니다.
• 해결: 자식 캔버스에는 UI 이벤트를 감지하는 Graphic Raycaster 컴포넌트가 자동으로 붙지 않습니다. 이 컴포넌트를 수동으로 추가해주어야 합니다.

7. 이름 규칙: 한글 이름 사용을 피하자

• 문제: 게임 오브젝트에 한글 이름을 사용하면 씬(.unity) 파일 내에서 UTF-8 코드로 인코딩되어 저장됩니다 (현금 -> ed 98 84 ea b8 88).
• 해결: 씬 파일 내에서 검색이나 파싱이 어렵게 되므로, 유지보수를 위해 가급적 영어로 이름을 짓는 것을 권장합니다.

8. 이벤트 연결: 인스펙터 vs 코드

방식	장점	단점
인스펙터 (OnClick)	직관적, 비개발자도 확인 가능	코드에서 역추적이 어려움
코드 (AddListener)	명확한 참조 관계 추적 가능	인스펙터에서 보이지 않음, 중복 등록 위험

AddListener 사용 시 핵심: 리스너 중복 등록 버그를 막기 위해, OnEnable에서 AddListener를 했다면, 반드시 OnDisable에서 RemoveListener를 호출하여 쌍으로 관리하는 습관을 들여야 합니다.

---

📝 핵심 요약

1. 방어적 설계: 기획이 불분명할수록 UI는 깨지지 않도록 여유 있게, 확장 가능하게 설계해야 합니다.
2. 미래 대비: 다국어 지원을 생각해 텍스트 공간은 3배로, 팀 협업을 생각해 기능별로 프리팹을 분리하세요.
3. 안정성 확보: Singleton은 최상단에, AddListener는 RemoveListener와 한 쌍으로, 이름은 영어로 짓는 등 안정성을 높이는 규칙을 지키는 것이 중요합니다.

이상으로 UI 설계 시 고려사항에 대한 강의 내용 정리를 마칩니다. 읽어주셔서 감사합니다!