🎮 Unity6 - 싱글톤(singleton)

프로젝트 하다 보면 매니저 스크립트(GameManager, SoundManager, UIManager)를 여기저기서 불러야 할 때가 많다.
구조를 잘 짜서 철저히 관리해주는 게 베스트긴 한데, 막상 만들다 보면 씬에 하나 놓고 레퍼런스 물려서 쓰다가 BGM이 두 번 재생된다든지, 데이터가 초기화된다든지 같은 사고가 터진다.

이때 비교적 쉽게 문제를 해결할 수 있는 방법이 싱글톤(Singleton) 패턴이다.

---

🔮개념

클래스의 인스턴스가 오직 하나만 생성되도록 보장하고, 이 인스턴스에 대한 전역적인 접근 지점을 제공하는 생성 디자인 패턴

이지만 비유로 표현하자면 영어에서 “유일한 것 / 누구나 같은 걸 떠올리는 것”에 the를 붙이듯이 그 조건을 만족하는 애를 싱글톤이라고 보면 된다. 즉

• 인스턴스가 오직 하나만 생성되도록 보장 -> 프로젝트내 단 한개만 존재
• 전역적인 접근 지점 제공 -> 이름을 부르면 누구나 해당 인스턴스라고 생각

한다는 것이다(전역 오브젝트).

---

🔮일반적인 사용

일반적인 싱글톤 구현은 보통

생성자를 외부에서 못 부르게 막고(private constructor)

클래스 내부에 정적(static) 인스턴스를 들고 있다가

필요할 때 생성해 반환하는 방식

public class Singleton
{
    private static Singleton _instance;

    public static Singleton Instance
    {
        get
        {
            if (_instance == null)
                _instance = new Singleton();
            return _instance;
        }
    }

    private Singleton() { }
}

보통 앱내 설정 정보나 전역 상태 관리, 여러 곳에서 동일한 자원에 접근하여 공유해야 할 때(캐시, 로거)에서 사용하고 생성 비용이 큰 객체를 한번만 생성하여 재사용하는 방식으로 사용되기도 한다.

---

🔮유니티에서의 사용

유니티에서는 아래 코드와 같이 세팅한다.

using UnityEngine;

public class GameManager : MonoBehaviour
{
    public static GameManager Instance { get; private set; }
	
    public int num=0;
    
    void Awake()
    {
        // 싱글톤 셋업
        if (Instance != null && Instance != this)
        {
            Destroy(gameObject);
            return;
        }

        Instance = this;
        // 씬 전환해도 유지
        DontDestroyOnLoad(gameObject);
    }

	public void plus(int n)//호출할 함수
    {
    	num+=n;
    }
}

이후 접근은 다른 스크립트에서 GameManager.Instance.plus(1);
이런식으로 접근하면 된다.

따로 상속받거나 import하지 않아도 바로 사용 가능

주로 사용하는 경우는 앞서 말했든 매니저 스크립트제작시 사용한다.

---

🔮왜씀 VS 왜안씀

우선 장점으로는

• 어디서든 접근이 쉬움
• 매니저가 여러 개 생기는 실수 방지
• 공유 데이터/기능을 한곳에 모으기 좋음
• DontDestroyOnLoad랑 조합하면 씬 전환에도 유지되는 “서비스” 만들기 편함

또 매번은 아니지만 비싼 비용의 오브젝트를 한번만 초기화 하고 또 생성 삭제주기를 없애기 때문에 성능이 향상되는 경우도 있다.

하지만 쉽다고 그랬지 최적의 방법이 아니라고 한 이유는

• 전역 접근 때문에 결합도가 올라감
  - 여기저기서 Instance를 부르면, 결국 시스템 전체가 그 매니저에 의존하게 됨
• 테스트/대체 구현이 어려움
  - 전역 인스턴스라 상태가 남아 테스트끼리 간섭하기도 함
• 숨은 의존성
  - 이 클래스가 무엇에 의존하는지 코드 구조상 드러나지 않고, 그냥 Instance로 쓰게됨
• 남용 Goat Object
  - "편하게 다 이걸로 쓰자"가 되면 유지보수 난이도 급상승

물론 전역으로 오래 살아서 메모리 점유가 늘수도 있고 초기화/로딩을 한 프레임에 몰아서 오히려 순간 프레임 드랍을 만들 수도있어 성능에 악영향을 주는 경우도 있다.

---

싱글톤 패턴으로 구현하는 것에 관해 부정적인 여론이 좀 있는 것 같지만
간단한 게임에서는 크게 문제될 건 없고
사실 GameManager를 구현하는데 가장 직관적이고 좋은 방법이라
적당히 잘 써먹자