[💬] 싱글턴 패턴 쓰지말라는 얘기에 반박글

[GMP(growy920)]

가장 일반적으로 유니티에서 사용하는 C# 싱글턴.

(디시는 티스토리의 코드블럭같은게 없어서 걍 내가 쓰고서 캡쳐해옴 ㅅㅂ)

참고로 위 코드는 Lazy Initialization(게으른 초기화)를 적용한 방식인데 이거는 아래에서 설명함

class UIManager : Singleton<UIManager> { } 처럼 싱글턴을 상속받은 UIManager 클래스를 만들고

다른 스크립트에서는 UIManager.Instance.ShowStatus() 이런 식으로 쉽게 사용 가능.

흔히들 싱글턴은 안티패턴이다 뭐다 하면서 프로그래머가 지양해야하는 코드라고 많이 함

일단 장점에 대해서는 따로 설명 안하겠음. 구글링하면 나오는 대표적인 단점 세 가지에 대해서 반박해봄.

(1) 객체지향 원칙이 파괴된다. 클래스간의 결합도가 높아져서 객체지향을 이루는 방법 중 하나인 모듈화에 실패할 수 있다.

맞는 말이긴함. 제일 큰 단점임. 싱글턴 클래스 내부에 있는 변수와 함수에 쉽게 접근이 가능하다보니

A에서 B접근, B에서 C접근, C에서 A접근과 같은 코드가 만들어질 가능성이 높긴함

근데 클래스 간의 의존성은 굳이 싱글턴이 아니어도 프로그래머의 실력에 따라서 발생할 수도 있고 원천 차단될 수도 있다고 생각함

예를 들어서, 싱글턴 클래스인 UIManager에 UpdateStatusUI()라는 함수가 있다치자.

플레이어의 HP, MP를 표시하는 UI를 갱신해주는 함수임.

이 UpdateStatusUI 함수 안에서 또 다른 싱글턴 클래스인 PlayerStats에 접근하기 보다는

이런식으로 바꾸려는 스텟의 key(HP인지 MP인지)와 value값을 파라미터로 받아서 처리하는 것임

아주 단순한 예시긴한데 '싱글턴 클래스 안에서는 다른 클래스에 절대 접근하지 않는다'라는

원칙을 지킨다면 결합도, 의존성 이런 문제는 크게 없을거라고 봄.

(2) 단위 테스트가 어려워진다.

단위 테스트? 대충은 알지만 해본적은 없어서 구글링을 해봤다.

A 함수를 테스트함에 있어서 그 결과가 B 함수를 테스트할 때 영향을 끼치면 안된다고 한다.

근데 싱글턴 패턴을 쓰면 하나의 객체를 공유하기 때문에 영향을 끼칠 수 밖에 없다.

예를 들어, UIManager를 테스트해보는 것이 목적이라면

A 함수에서 new UIManager를 생성(인스턴스화)해서 실행해보고, B에서도 다시 생성해서 테스트하면 끝인데

UIManager가 싱글턴이면 A 함수에서 UIManager의 변수를 조작한 것이 B에서 UIManager에 접근했을 때 그대로 유지가 되어있다.

음... 이런게 단위 테스트라고는 하는데...

스튜디오가 제공하는 디버깅만으로도 부족해서 추가 테스트를 거치는, 게임이 아닌 프로젝트라면 모르겠지만

일반적인 인디 게임에서는 이런 단위 테스트가 필요한가 싶다.

결국 싱글턴을 쓰지 말아야하는 이유로서는 현실성이 떨어진다고 생각한다.

(3) 멀티쓰레드 환경에서 문제가 생길 수 있다.

예를 들어 A 쓰레드와 B 쓰레드가 동시에 하나의 객체인 UIManager에 접근해서 데이터를 수정한다면?

뭐 이런거 때문에 싱글턴 클래스 안에서 Instance를 반환하는 함수(get)에 lock을 걸기도 하는데

중요한건 대부분 유니티에서 싱글턴 클래스는 MonoBehavior를 상속받아서 만든다.

모노는 유니티의 메인 쓰레드(Awake, Start, Update 생명주기 함수들 실행하는 그 녀석)에서 돌기 때문에

멀티쓰레드 환경에서 발생할 문제들은 고려하지 않아도 된다.

'유니티는 멀티쓰레드를 전혀 고려안해도 된다'라는 말이 여기서 나오는 것이고

이 역시 싱글턴을 쓰는데에 문제를 일으키진 않는다.

(4) 게으른 초기화

그리고 내가 예시로 올려놓은 코드는 게으른 초기화(최초 Instance 접근했을 때 그제서야 객체 생성)를 하는 방식의 싱글턴인데

처음에는 뭣도 모르고 썼었는데 요즘에는 쓰잘데기 없다고 느꼈음

게으른 초기화를 하면 장점이다라고 하는 것들이 주로

(1) 이 싱글턴 객체가 사용되기 전까지는 객체 생성을 하지 않음

게임이 종료될 때까지 사용하지도 않을 객체를 생성해서 메모리 낭비하는 경우를 방지할 수 있다.

라고 하는데.. 과연 현실적인가? 게임이 종료될 때까지 사용되지 않을 가능성이 있다는건

그만큼 특수한 상황에서만 사용되는 클래스라면 싱글턴으로 만드는거 자체가 비효율적인거같음

(2) Hierarchy 뷰가 깔끔해짐.

사실 나도 이거 때문에 썼었음.. 씬 안에 빈 게임오브젝트들을 만들고 무슨 매니저, 무슨 매니저

붙여놓는거 자체가 좀 클린해보이지 않았었음..

근데 뒤늦게 싱글턴 객체를 초기화하다가 여기서 많은 시간이 걸리면 이거에 대한 처리는??

보통 다음 씬으로 넘어갈 때 게임을 멈춰놓고 여러가지 객체 초기화하는 시간을 따로 할당하는데

여기에 싱글턴 객체를 포함시키지 않는다?

물론 싱글턴 객체가 매우 가볍고 초기화하는데 지연시간이 생길 가능성이 0%라면 노상관이지만

초기화 함수(생성자 함수)에 데이터 로딩같은게 있다면 비동기 처리를 따로 해줘야함

결국에 유저 입장에서는 인벤토리를 클릭했더니 게임이 멈춘건 아닌데 2초동안 로딩 UI가 나오는 경험을 해야함

아무튼 싱글턴을 단순히 쓸 때도 의외로 여러가지 고민은 해봐야함

[익명(222.110)]

좋은 글입니다

[익명(106.102)]

이거 봐. 반박하는 애들도 유닛테스트 싸본적 없다잖냐 ㅋㅋㅋ 걍 꼴리는대로 쓰면 됨. 테스트코드를 작성해본적도 없는 사람들 노는곳 수준인데 무슨 의존성 운운하며 뭐가 좋다 나쁘다 그럼? 걍 아무렇게나 짜도 출시해서 돈벌면 되는거지 뭐

[익명(106.102)]

걍 스태틱으로 변수 데이터 다 꼬라박아도 겜 잘만 돌아간다. 유지보수니 의존성이니 그런 건 출시한놈들이 알아서 고민하게 되어있음.

[정산적인닉(58.120)]

인디게임에는

[정산적인닉(58.120)]

if문으로 다 써도 문제없다고 생각함 ㅋㅋㅋㅋㅋㅋㅋㅋ

[익명(222.110)]

> 일반적인 인디 게임에서는 이런 단위 테스트가 필요한가 싶다. 이것에 대해서만 조금 이견이 있음.

[익명(222.110)]

테스트 코드의 역할은 두 가지가 있음. - 테스트 목적 클래스가 정상적으로 동작하는지 테스트한다. - 테스트 목적 클래스의 사용법을 전달한다. 따라서 테스트 코드는 생산성을 위해서도, 차후 본인 또는 다른 개발자의 이해를 돕기 위해서라도 간단하게 작성될수록 유용함. 물론 본인이 현재 테스트 코드 작성이 부담되지 않는다고 한다면 그것을 외부에서 이래라 저래라 하는건 오지랖이지만 그렇다고 '간결한 테스트는 불필요해.' 라고 주장하는 것은 동의가 안됨.

[익명(222.110)]

무엇보다.. 게임이 조금만 복잡해져도 테스트 환경에서 재현하기 어렵거나 불가능한 코드가 생기기 시작할 것. 대표적으로 예를 들면 네트워크가 잠시 중단된다거나, 파일 디스크립터가 닫혀있다던가.. 알림을 보내보려는데 심야 시간대라던가 모바일 게임이라서 디바이스 쪽 기능을 사용할건데 Nugat 의 경우 해당 API에 문제가 있어 막혀있어야 한다던가.. 그것은 별도로 가짜 환경을 만들고 테스트해줘야 함. 인디건 아니건 개발은 기본적인 유닛 테스트까진 작성해야 끝났다고 생각하는 것이 좋음. 오히려 큰 개발사에선 UI Controller 로직들은 테스트 안해도 QA에서 다 해결해주지니까 테스트좀 빼먹어도 문제 없음. 하지만 인디게임은.. 기껏 게임이 잘되는데, 사소한 로직 하나때문에 크래시가 터지면..

[익명(222.110)]

누가 내 프로젝트를 지켜주겠음.. 기껏 좋은 게임을 만들고 그런 이상한 이유로 실패하면 아쉽잖음.

[익명(211.114)]

다른 개발자의 이해를 돕기 위해 테스트 코드를 쓰느니 문서화를 잘하자. 유닛 테스트를 안해도 누구나 정상적으로 동작하는지 테스트한다

[익명(211.114)]

유닛테스트로 네트워크가 중단되는지, 파일 디스크럽터를 테스트느 하는건 좀... 이거야말로 실제 환경과 유사하게 만들어서 해야 테스트가 되는건데

[익명(222.110)]

> 유닛테스트로 네트워크가 중단되는지, 파일 디스크럽터를 테스트느 하는건 좀... 오해를 하신 것 같은데, 네트워크가 중단되는지 테스트 하려는 것이 아니고 네트워크가 중단된 상태에서 특정 소스코드가 의도된대로 동작하는지 확인하는 테스트입니다. 매번 실제 환경에서 모든 소스코드를 테스트하기엔 너무 리소스가 크니까요.

[익명(222.110)]

> 다른 개발자의 이해를 돕기 위해 테스트 코드를 쓰느니 문서화를 잘하자. 문서화도 당연히 해야합니다. 유닛 테스트가 문서화를 대체 할 수 있는것은 아닙니다. 단, 유닛 테스트는 프로젝트의 최신 환경에서 실행이 가능하며, 우리가 원하는 명제에 대한 성공/실패 결과와 명확한 근거를 얻을 수 있습니다. 하지만 문서는 사람이 갱신해주지 않으면 변화를 반영하지 못합니다. 그것이 우리가 유닛 테스트로도 사용법을 전달해야만 하는 이유입니다.

[익명(222.110)]

결국 두 코멘트 모두 요약하면 유닛 테스트를 충실히 짜는 것, 그걸 위한 환경을 구성하는 것이 당장은 불필요한 업무처럼 보일지 몰라도 장기적으로 어느정도 규모 이상의 프로젝트를 만들때 잠재적인 문제를 통제하며 이를 위한 리소스를 최적화하기 편리합니다.

[익명(222.110)]

> Hierarchy 뷰가 깔끔해짐. 계층을 깔끔하게 만드는 것은 중요하다고 생각함. 좋은 일임. 다만 실제 관계는 깔끔하지 않은데 그걸 억지로 깔끔하게 보이게 만드는건 좋지 않다고 생각함. Scene에 들어갈 필요가 없는 일반적인 비즈니스 로직 객체라면 Scriptable Object를 써도 되고

[익명(222.110)]

그게 아니면 다소 복잡해보여도 정직하게 계층을 구성하고 이를 최대한 독립적으로 프리팹화 시키는게 좋다고 생각함.

[익명(14.52)]

테스트 안써봤다는거에서 고졸검거

[GMP(growy920)]

너님은 단위테스트 언제 해봄

[익명(14.52)]

대학에서 배우게됩니다. 자퇴하셔서 놓치신듯

[익명(218.237)]

지잡부심이 풍년이다 ㅋㅋㅋ

[익명(14.10)]

ㅋㅋㅋㅋㅋ 씹 ㅋㅋㅋ 테스트코드 써본적도 없는새끼들이 남한테 여테껏 꼰대질 해온거네 ㅋㅋㅋ

[-인.(bloodinfirst)]

평소 싱글톤 정말 즐겨써왓는데 주의해야할점 잘 정리해주셔서 감사합니다

[익명(211.114)]

1) 어떤 종류든 테스트를 한다면, 유니테스트를 안한다고 조롱받을 이유가 없다. 유닛 테스트는 은탄환이 아니다. 2) 싱글톤은 쓰든 말든 상관없다. static으로 박아버리고 써도 상관없다...

[익명(222.110)]

아예 테스트를 하지 않는다면 이해가 됩니다. 하지만 안그래도 인력이 부족한 인디 개발에서 테스트 자동화를 검토하지 않는 것은 이상하다고 생각합니다.

[익명(222.110)]

만약 다른 방법 (일반적으로 QA) 로 테스트를 수행해서 게임의 로직을 검증하는게 유닛테스트보다 빠르다면 그것은 해당 테스트 방법으로 검증되는 프로젝트의 커버리지가 현저히 낮다는 것을 반증하는 셈입니다.. UI 제어 코드같은 GO에 종속되며, 테스트가 까다로운 코드들은 테스트 범위에서 제외하더라도 향후 게임의 규칙, 보상 플로우같은 핵심 비즈니스 모델에 영향을 끼칠 수 있는 로직들은 반드시! 유닛테스트를 하는 것을 추천드립니다. (올바르게 구조를 분리해왔다면 이러한 코드들은 테스트가 결코 어렵지 않습니다.)