Unity에서의 Singleton 2편 - MonoBehaviour Singleton의 문제점

이번에는 MonoBehaviour Singleton을 사용하는 이유 및 문제점을 파악해서 해결 방법을 고민해 볼 겁니다.

사실 Singleton 관련 블로그 글을 써보려고 마음먹은 이유도 이러한 문제점들이 있는데 MonoBehaviour Singleton을 남발하는 경우가 많아서 쓰게 되었는데, 한 명이라도 이 글을 읽고 고민이라도 조금 했으면 해서 쓰게 되었습니다.

1. MonoBehaviour Singleton을 사용하는 이유

이전 글에서도 설명드렸듯이 몇 가지 꼽아보자면 이 정도가 될 것 같습니다.

MonoBehaviour의 기능을 이용하기 위함. (Update, LateUpdate.. 등등 함수들 및 Coroutine기능)
Native Plugin이용 시, SendMessage로 전달받아야 하는 경우
에디터에서 쉽게 확인 가능 (Hierarchy View, Inspector View)

이 부분들은 직접 사용해보시면 체감하시게 될 것이라 생각됩니다.

주로 MonoBehaviour의 기능을 사용하기 위함이 가장 큰데, 하나하나 다 설명하자면 너무 길어지고 글 주제인 "문제점"과도 맞지 않아 이 글을 읽는 여러분들이 체감하시길 바랍니다.

하지만, 정말 유용하고 많이 쓰이고 필수로 써야 할 곳들이 존재한 다는 것은 꼭 알아두시길 바랍니다.

2. MonoBehaviour Singleton의 문제점

지금부터는 문제점들을 다뤄볼 예정인데, 사용하는 이유보다 좀 더 디테일하게 설명드려보겠습니다.

2.1 플레이 중이 아닐 때 호출 시 문제.

Unity로 개발하다 보면 너무나 당연하게 플레이 중일 때를 가정하고 코딩할 때가 많은데, 협업을 하다 보면 플레이 중이 아닐 경우에 해당 Singleton을 접근해야 하는 경우가 생깁니다. 보통은 저의 경우에는 기획파트 혹은 아트 파트 요청으로 개발 툴을 개발하면서 발생하게 됩니다.

예로 들자면 Map에 몬스터를 배치하는 Map Tool이라고 있다고 하면, 이 툴에서는 Map ID만으로 Map을 불러와야 하는데 그러기 위해서는 Map의 정보가 저장된 데이터를 로드해야 하는 상황이고, 해당 데이터를 로드하는 코드는 MonoBehaviour Singleton으로 짜여 있는 상황입니다.

만약에 플레이 중이 아닐 때 MonoBehaviour Singleton의 Instance로 접근 시에 우리가 짜두었던 코드대로 동작한다면 GameObject가 생성되고 해당 오브젝트에 Component가 붙게 됩니다.

[UnityEditor.MenuItem("TestMenu/Singleton2/GetMapDat_10205")]
public static void GetMapData_10205()
{
    TableDataManager.Instance.GetMapData(10205);
}

간단하게 테스트 코드를 만들어보았습니다.

에디터에서 그대로 실행 시에 왼쪽으로 오른쪽처럼 GameObject가 생성되었습니다.

당장에는 문제가 되지 않을 수 있습니다만, 이대로 불러들인 Scene을 저장하게 될 경우 다음에 소개해드릴 "중복으로 생성되었을 때의 문제"가 발생하게 됩니다.

2.2 중복으로 생성되었을 때의 문제

게임을 플레이 중인데 똑같은 MonoBehaviour Singleton이 있다면 어떤 것을 참조할까 고민해보면, 이전 글에서 만들어둔 코드를 기준으로 한다면 기존에 만들어진 오브젝트가 있더라도 새롭게 만들어서 Instance에 등록해줄 것입니다.

여기서 문제가 되는 부분은 Update, LateUpdate와 같이 MonoBehaviour 함수로 Instance와 동일한 오브젝트가 아니더라도 동작하는 경우입니다.

public class CameraManager : MonoBehaviourSingletonTemplate<CameraManager>
{
    private void Start()
    {
        Invoke("OnOneSec", 1f);
    }

    private void Update()
    {
        Camera.main.transform.Translate(Vector3.forward * Time.deltaTime);
    }

    private void OnOneSec()
    {
        Debug.Log(Camera.main.transform.position);
    }

    public Camera GetMainCamera() => Camera.main;
}

만약에 위 코드처럼 Update함수에서 Camera의 Transform을 Translate함수로 이동시킨다고 가정했을 때, 로그로 보이는 것처럼 나오는 값이 달라지게 됩니다. 분명한 오작동입니다.

protected void Awake()
{
    if (m_Instance != this)
    {
        Destroy(gameObject);
        return;
    }

    DontDestroyOnLoad(gameObject);
}

임시로 Awake함수를 수정했습니다. Instance와 비교하여 Instance와 다르면 제거하도록 작업해두었습니다.

물론, 제가 생각하기에 이 상황이 제대로 된 상황은 아니며 임시방편으로 사용하는 코드입니다.

하지만 이 코드 역시 다른 문제를 만들게 되는데, 아래 코드로 설명드리겠습니다.

private void OnDestroy()
{
    Destroy(Camera.main.gameObject);
}

Component가 파괴될 때 OnDestroy함수가 호출되는데, 파괴되면서 실행하는 코드들이 또 문제를 일으키게 됩니다.

private void OnDestroy()
{
    if (Instance != this) return;
    Destroy(Camera.main.gameObject);
}

결국 이번에도 Instance와 비교하여 실행할지 말지를 결정해주어야 합니다.

중복 오브젝트 덕분에 덕지덕지 덮어씌워 주는 느낌이라 별로 좋지 않습니다.

2.3 OnDestroy때 호출 시 문제

Unity에서 게임 종료 시에 모든 오브젝트들을 제거하고 OnDestroy함수들이 호출되게 되는데, 여기서 MonoBehaviour Singleton오브젝트가 먼저 파괴되고 다른 오브젝트 OnDestroy함수에서 이미 파괴된 MonoBehaviour Singleton의 Instacne를 참조하는 경우 우리가 짜두었던 코드대로라면 새롭게 GameObject를 생성하게 됩니다.

Some objects were not cleaned up when closing the scene. (Did you spawn new GameObjects from OnDestroy?)

위 상황일 때 위와 같은 에러가 나오게 되고, GameObject가 생성되지 못했기 때문에 이후에 Instance의 멤버 접근하는 코드들은 Null Reference Exception을 뱉어내게 됩니다.

어차피 게임이 종료되는 상황이라 이 에러가 나와도 문제가 없다고 생각하실 수 있지만, 실제로 빌드하여 확인해보면 게임 종료 시에 "비정상 종료"도 나오게 되어 저장되어야 하는 것이 저장되지 못하고 사용자에게 에러 창을 보여주는 것으로 부정적인 이미지를 줄 수 있습니다.

이 부분은 OnDestroy함수들 마다 Instance를 참조하는 부분을 다 제거해주거나 이미 파괴되었는지 체크해주는 코드를 넣어야 합니다.

이 또한 매우 번거롭고 임시방편으로 보입니다.

3. MonoBehaviour의 문제점 해결 방법

제가 생각하는 가장 쉬운 방법 위 문제점들을 인지하고 MonoBehaviour Singleton을 "꼭 필요할 때만 쓰는 것"입니다.

이 글 가장 처음에 어느 상황에서 사용하면 좋을지 모두 설명드렸습니다. 해당 상황에 잘 맞는 경우 사용하고, 그 외의 상황에서는 최대한 지양하는 것입니다.

하지만, 이 또한 예외적인 상황이 너무 많아 MonoBehaviour Singleton을 만들지 않고 Singleton과 MonoBehavior의 기능을 이용하는 스크립트를 추가하여 해결해 보는 것이 최선이지 않나 싶습니다.

public class MonoBehaviourEventListener : MonoBehaviour
{
    static MonoBehaviourEventListener m_Instance = null;

    public static MonoBehaviourEventListener Instance
    {
        get
        {
#if UNITY_EDITOR
            if (UnityEditor.EditorApplication.isPlayingOrWillChangePlaymode == false)
                return null;
#endif

            if (m_Instance == null)
            {
                var obj = new GameObject("MonoBehaviourEventListener");
                m_Instance = obj.AddComponent<MonoBehaviourEventListener>();
            }
            return m_Instance;
        }
    }

    public System.Action OnUpdateEvent;
    public System.Action OnLateUpdateEvent;


    private void Update()
    {
        OnUpdateEvent?.Invoke();
    }

    private void LateUpdate()
    {
        OnLateUpdateEvent?.Invoke();
    }
}

우선은 간단하게 MonoBehaviour EventListener를 만들어보았습니다.

간단하게 Singleton으로 만들어서 Update, LateUpdate를 콜백으로 호출하도록 짜두었으니, 이제 Singleton에서 해당 콜백 등록해주면 됩니다.

Application.isPlaying가 아니라 UnityEditor.EditorApplication.isPlayingOrWillChangePlaymode로 체크했던 이유는, 플레이 시작할 때 첫 Awake함수를 호출 시 Application.isPlaying이 false로 반환하는 경우가 있어서입니다.

public class CameraManager : SingletonTemplate<CameraManager>
{
    public CameraManager()
    {
        if (MonoBehaviourEventListener.Instance != null)
        {
            MonoBehaviourEventListener.Instance.OnUpdateEvent += OnMonoBehaviourUpdate;
        }
    }

    private void OnMonoBehaviourUpdate()
    {
        Camera.main.transform.Translate(Vector3.forward * Time.deltaTime);
        Debug.Log(Camera.main.transform.position);
    }

    public Camera GetMainCamera() => Camera.main;
}

이전에 만들었던 CameraManager를 MonoBehaviorSingleton이 아니라 Singleton으로 만들고, MonoBehaviourEventLister를 참조하여 이벤트 등록하도록 만들어봤고, 로그로 정상작동도 확인했습니다.

앞으로도 MonoBehaviourd의 기능들은 MonoBehaviourEventLister를 통해서 작업하면 됩니다.

Update, LateUpdate, FixedUpdate함수의 이벤트로 받거나 Coroutine 역시 MonoBehaviourEventLister.Instance.StartCoroutine 같은 식으로 접근해서 사용하면 됩니다.

대신 MonoBehaviour기능을 사용하지 않고 사용하던 로직을 동작시키려면 다른 방법으로 동작하도록 코드 수정을 해야 해서 이 부분만 추가로 구현을 해주면 됩니다.

하지만, 이렇게 해도 Native Plugin에서 SendMessage로 전달받아야 하는 경우, GameObejct가 없기 때문에 이런 식으로 해결하지는 못하고 어쩔 수 없이 GameObject를 써야 합니다.

public class MonoBehaviourSingletonTemplate<T> : MonoBehaviour where T : MonoBehaviour
{
    static T m_Instance = null;

    public static T Instance
    {
        get
        {
#if UNITY_EDITOR
            if (UnityEditor.EditorApplication.isPlayingOrWillChangePlaymode == false)
                return null;
#endif
            if (m_Instance == null)
            {
                var obj = new GameObject(typeof(T).Name);
                m_Instance = obj.AddComponent<T>();
            }
            return m_Instance;
        }
    }

    protected void Awake()
    {
        if (m_Instance != this)
        {
            Destroy(gameObject);
            return;
        }

        DontDestroyOnLoad(gameObject);
    }
}

어쩔 수 없이 써야 하는 부분은 Application.isPlaying 혹은 UnityEditor.EditorApplication.isPlayingOrWillChangePlaymode로 플레이 중인 것을 체크하여 플레이 중일 때만 생성해주도록 구현해주시면 됩니다.

Null로 리턴될 것이니, 이 부분은 꼭 예외처리가 필요하니 꼭 주의 바랍니다.

4. 마무리

MonoBehavior Singleton의 문제를 체크해보고 저만의 해결 방법을 고민해보았습니다.

이 글을 읽는 여러분들에게 혹시라도 도움이 되셨다면 좋을 것 같네요.

제가 해결해보고자 한 방법이 최선이 아니라고 생각하고 프로젝트마다 해결 방법도 다르다고 생각합니다.

혹시라도 여러분들이 생각하는 방법이 있으시면 덧글로 남겨주시면 감사하겠습니다.

다음 글에서는 MonoBehaviour Singleton 보다는 Singleton을 남발하는 문제를 좀 더 다뤄볼까 합니다.

긴 글 읽어주셔서 감사합니다.

'Unity Tips' 카테고리의 다른 글

Unity에서 Enum.Parse함수 GC 발생 줄이기 (0)	2022.05.01
Unity에서 계층이 있는 데이터 저장 (JSON vs XML vs Scriptable Object) (0)	2022.04.30
Unity에서 C++코드(cpp) Native Plug-ins 사용하기 (0)	2022.03.27
Unity에서의 Singleton 3편 - Singleton끼리 서로 참조하는 문제 (0)	2022.03.09
Unity에서의 Singleton 1편 - 싱글턴 클래스 만들기 (5)	2022.02.20