두 가지 접근법
메뉴 안에 여러 슬롯이 있는 UI를 만든다고 가정하자.
1번: 모듈화 방식
MenuWidget
└─ SlotWidget (재사용 가능한 별도 위젯)
└─ Button → EventDispatcher로 상위에 알림
- 슬롯 위젯과 메뉴 위젯을 분리
- 버튼 클릭 시 Event Dispatcher → Delegate 체인으로 상위 전달
- 텍스트 등 설정값은 스폰 시 동적으로 Set
- Pre Construct, Construct에서 초기화
2번: 통합 방식
MenuWidget (슬롯까지 포함)
└─ Button1 → 직접 함수 호출
└─ Button2 → 직접 함수 호출
└─ Text (하드코딩)
- 슬롯과 메뉴를 한 위젯에 통합
- 버튼 클릭 시 바로 함수 처리
- 텍스트는 디자이너에서 직접 입력
- 비슷한 UI 필요하면 레이아웃 복붙
성능 차이는?
거의 없다.
| 항목 | 차이 |
|---|---|
| 델리게이트 바인딩 오버헤드 | 무시할 수준 |
| 위젯 생성 비용 | 동일 |
| 메모리 사용량 | 비슷 |
UMG에서 1번과 2번의 성능 차이는 측정 불가능할 정도로 미미하다. 최적화 때문에 모듈화하는 게 아니다.
진짜 차이점
| 모듈화 (1번) | 통합 (2번) | |
|---|---|---|
| 초기 개발 속도 | 느림 | 빠름 |
| 유지보수 | 한 곳 수정 → 전체 반영 | 복붙한 곳 다 찾아서 수정 |
| 디버깅 | 이벤트 체인 추적 필요 | 직관적 |
| 팀 작업 | 역할 분담 용이 | 충돌 가능성 |
| 확장성 | 새 타입 추가 쉬움 | 또 복붙 |
업계 표준이 모듈화인 이유
대형 스튜디오에서 모듈화를 선호하는 건 성능 때문이 아니다.
협업 구조 때문이다:
- UI 디자이너: 슬롯 위젯의 비주얼 담당
- UI 프로그래머: 메뉴 로직, 데이터 바인딩 담당
- 각자 영역이 분리되어 있어야 충돌 없이 작업 가능
혼자 개발하거나 소규모 팀이면 이 구조가 오히려 오버헤드다.
현실적인 기준
프로젝트 규모와 반복 횟수로 판단한다:
소규모 / 혼자 개발 → 통합 방식이 현실적
대규모 / 팀 개발 → 모듈화가 장기적으로 이득
같은 슬롯이 몇 번 반복되는가?
| 반복 횟수 | 권장 방식 |
|---|---|
| 1~5회 | 통합 (복붙) |
| 10회+ | 모듈화 |
| 50회+ | 반드시 모듈화 + 오브젝트 풀링 고려 |
실제 적용 예시:
- 상점 아이템 슬롯 (100개+) → 모듈화
- 설정 메뉴 버튼 (5개) → 통합
- 인벤토리 슬롯 (수십 개) → 모듈화
- 1회성 특수 팝업 → 통합
정리
- 성능 차이는 없다
- 모듈화의 장점은 유지보수와 팀 협업
- 통합의 장점은 빠른 개발 속도
- 반복 횟수가 많으면 모듈화, 적으면 통합
- “업계 표준”을 맹목적으로 따르지 말고, 상황에 맞게 선택
빠르게 프로토타이핑해야 하면 2번으로 시작하고, 나중에 반복이 많아지면 그때 1번으로 리팩토링해도 된다. 처음부터 완벽한 구조를 만들려다 개발 속도만 늦어지는 경우가 더 많다.