유니티 시스템 프로그래밍이라는 인프런의 강의를 보고 학습하는 내용을 정리하고 기록하는 글입니다.
Unity 시스템 프로그래밍 학습 기록 - 섹션 5-1
이번 섹션 5-1에서는 Lobby 씬 구조 및 디자인 패턴에 대해 공부했습니다.
기존에 LobbyManager만 사용했던 것과 달리, 이번에는 LobbyUIController라는 별도의 클래스를 사용했습니다. 유저가 특정 행동을 입력했을 때, 이미지나 UI와 같은 시각적인 작업은 LobbyUIController에서 처리하고, 데이터 관련 작업은 LobbyManager에서 처리하는 구조였습니다. 처음에는 이러한 구조가 왜 필요한지 이해하지 못했지만, 이번 강의를 통해 이 방식이 더 효율적이라는 점을 배웠습니다.
구조 분리의 이유와 장점
책임 분리 (Single Responsibility Principle)
LobbyUIController는 UI와 관련된 모든 시각적 처리를 담당하고, LobbyManager는 데이터 로직과 상태 관리를 담당합니다. 이로 인해 각 클래스가 하나의 역할에만 집중하게 되면서 코드가 더 가독성 있고 유지보수하기 쉬워집니다.
유연성
UI가 변경되거나 새로운 기능이 추가되더라도, UI 관련 작업은 LobbyUIController에서만 수정하면 되고, LobbyManager의 데이터 로직은 별도로 관리할 수 있어 유연성이 높습니다.
확장성
데이터 처리와 UI가 분리되어 있기 때문에, 새로운 UI 요구사항이나 데이터 로직 변경 사항이 생겼을 때 더 쉽게 확장할 수 있습니다.
디버깅과 테스트 용이성
시각적인 부분에서 문제가 발생할 경우 LobbyUIController만 확인하면 되고, 데이터 처리에서 발생한 문제는 LobbyManager에서만 디버깅하면 되므로, 각각의 문제를 독립적으로 추적하고 수정하기가 수월합니다.
그러나 이러한 구조에는 몇 가지 단점도 있음을 알게 되었습니다.
구조의 단점
초기 설계 복잡성
UI와 데이터를 분리하여 관리하면 설계가 더 복잡해질 수 있고, 작은 프로젝트에서는 과도한 설계일 수 있습니다.
클래스 간 통신 복잡성
LobbyManager와 LobbyUIController 간의 데이터 교환을 위한 추가 코드가 필요하고, 이로 인해 작업량이 늘어날 수 있습니다.
디버깅 복잡성
여러 클래스가 서로 데이터를 주고받기 때문에, 어느 부분에서 문제가 발생했는지 파악하는 과정이 복잡해질 수 있습니다.
이러한 점들을 고려하여, 이번 학습을 통해 규모가 커질수록 구조를 나누는 것이 효율적이라는 사실을 깨달았습니다. 앞으로 프로젝트를 진행할 때 이 원칙을 잘 활용하여 확장 가능하고 유지보수하기 쉬운 구조를 만들어 나가야겠습니다.
