MonoBehaviour 없이도 구조를 짤 수 있다고? – 더 유연하고 가벼운 설계 방법

 

모든 걸 MonoBehaviour로 짜면 구조가 무거워진다

Unity 프로젝트를 처음 짜면 모든 매니저를 MonoBehaviour 상속으로 만들기 쉽다.
하지만 프로젝트가 커질수록 의존성, 씬 간 연결, 참조 꼬임이 문제로 떠오른다.
MonoBehaviour를 최소화하고 비상속 구조로 관리하는 방식을 정리해본다.

---

1. 왜 MonoBehaviour 없이 짜려는가?

• new로 생성 불가 → 항상 씬에 넣거나 Instantiate 필요
• Awake()/Start() 시점 불확실 → 초기화 순서 꼬이기 쉬움
• 씬 간 이동 시 DontDestroyOnLoad를 써야만 유지됨 → 오브젝트 난잡해짐
• 디커플링이 어려움 → 단위 테스트, 독립적 재사용 불가

---

2. 대신 사용하는 구조: 정적 매니저 클래스

public static class GameDataManager {
    public static int Gold { get; set; }
    public static void Save() { ... }
}

• 상태 유지가 목적일 때는 static 클래스가 간결하고 명확함
• 단점: GC 누적, 상태가 꼬일 수 있으므로 단순 데이터/로직에 한정

---

3. 싱글턴 클래스를 new로 직접 관리

• MonoBehaviour 상속 없이 new로 생성해서 관리
• 생성 시점 명확하고 테스트도 용이함

public class SoundManager {
    public void Play(string clipName) { ... }
}

public class Game {
    private static SoundManager _sound = new SoundManager();
}

---

4. ScriptableObject 기반 전역 객체

• 런타임 상태가 아닌, 에디터에서 설정하는 값에 적합
• 주로 Config, Constant, 초기 설정값 등
• MonoBehaviour 없이 에셋으로 접근 가능한 단위 정보를 만들 수 있음

---

5. 그럼 MonoBehaviour는 언제 쓰나?

• Unity 엔진과 직접 연결되는 객체일 때:
  • 카메라, 렌더링, 콜리전, 트리거, UI 이벤트 등
• **‘씬에 존재하는 물리적 객체’**에만 MonoBehaviour를 붙이는 방식으로 최소화

---

정리하며

MonoBehaviour는 강력하지만 제약이 많다.
기능 중심 로직은 비상속 구조로 설계하고,
Unity 엔진과 직접 연결된 컴포넌트만 MonoBehaviour로 분리하는 구조가 유지보수에 유리하다.