DevDino

의존성 주입 패턴(Dependency Injection Pattern)게임을 개발하다 보면 플레이어가 데미지를 입었을 때 소리를 내기 위해 AudioManager.Instance.PlaySound()처럼 싱글톤(Singleton)을 호출하는 경우가 아주 흔합니다.하지만 이렇게 작성하면 플레이어 클래스는 특정 오디오 매니저에 '강하게 결합(Tight Coupling)'되어버립니다. 만약 테스트를 위해 소리를 끄고 싶거나, 다른 씬에서 다른 오디오 매니저를 사용해야 한다면 플레이어의 내부 코드를 직접 수정해야 하는 문제가 발생합니다. 이처럼 객체가 스스로 필요한 부품(의존성)을 찾거나 만들어 쓰는 대신, 외부에서 조립해서 넣어주는(주입하는) 방식인 '의존성 주입(DI)'패턴에 대해 알아보겠습니다. 의존성 주..

업적 시스템은 다양한 상황을 체크해야 합니다. 만약 액션과 업적 처리 로직이 서로 직접 참조하게 된다면 코드가 복잡하게 얽히게 될 것입니다. 이런 의존성 문제를 해결하고 확장성 있는 구조를 만들기 위해 이벤트 버스(Event Bus) 패턴을 도입하게 되었습니다. 이전까지 전역 이벤트를 관리할 때는 이벤트 데이터를 object 타입으로 넘기는 형태의 이벤트 버스를 주로 사용해 왔습니다. 호출이 빈번하지 않았기 때문에 문제가 없었지만, 새 프로젝트를 진행하면서 터치 이벤트가 발생할 때마다 업적 달성 여부를 체크하는 기능을 도입하게 되었습니다. 터치 입력은 플레이 중에 호출 빈도가 높기 때문에 object 기반 이벤트 버스를 그대로 사용하면 지속적인 박싱/언박싱(Boxing/Unboxing)이 발생하게 되어..

처음에는 프로젝트 내 주요 클래스에만 싱글톤을 썼지만, 나중에는 참조하기 편하다는 이유로 남용하곤 했습니다. 하지만 프로젝트 규모가 커지면서 기존에 사용하던 싱글톤 패턴의 한계가 명확해졌습니다. 클래스 간 결합도가 높아져 수정 사항이 생길 때마다 참조하는 코드들을 일일이 찾아 고쳐야 했습니다. 게다가 싱글톤은 게임이 시작될 때부터 끝날 때까지 메모리에 남아 있다 보니, 초기화 순서가 꼬여 에러가 나거나 메모리 관리가 제대로 되지 않는 문제도 잦았습니다. 그렇다고 임의로 생명주기를 건드리면, 다른 클래스에서 언제 해당 싱글톤을 호출할지 몰라 참조 오류가 날 위험이 생겼습니다. 이러한 문제를 해결하기 위해 의존성 주입(DI, Dependency Injection)을 도입했습니다. 이번 글에서는 유니티 환경..