어느정도 파악을 하고 있었지만, 명확하게 안다고 확신을 할 수 없는 상황에서 이 질문을 받았다.
IoC가 왜 필요한지
DI가 왜 필요한지
그래서 적어보는 포스트, 해당 포스트는 Node.js 디자인 패턴 바이블이라는 서적과 제 지식이 짬뽕되서 적힙니다.
싱글톤패턴이란?
객체지향 프로그래밍에서 싱글톤 패턴은 사실상 핵심이라고 볼 수 있다.
객체지향 자체가 요즘은 클래스가 중심이 되서 이야기를 하다보니 오히려 설명은 더 쉽게 할 수 있지만
클래스 내부에 만들어진 메소드를 이곳저곳에 활용하는 것이 특징이라고 볼 수 있다.
여기서 싱글톤 패턴은 클래스(객체)의 인스턴스 가 한개만 존재하도록 하여
접근하는 것을 한개로 다 몰아버리는 것을 이야기한다.
싱글톤 패턴의 장점은 아래와 같다.
- 다양한 곳에서 인스턴스 선언을 새로 하지 않아 메모리의 낭비를 줄일 수 있고
- 인스턴스의 정보가 변경되더라도 결국은 한개의 인스턴스를 사용하기 때문에 동기화의 문제도 없으며
- 인스턴스의 상태가 모두 동일하기 때문에 어디서 사용하더라도 같은 결과를 확인할 수 있다.
하지만 이것에는 단점이 있는데, 객체간의 결합이 강해진다는 문제가 발생한다.
도서관으로 보는 싱글톤 패턴의 문제
어떤 느낌으로 비유를 할까 고민을 해봤는데, 도서관으로 비유가 가능할 것 같다.
위에 적어놓은 장점을 도서관으로 비유를 해서 확인을 해보자.
- 도서관에는 책을 빌려서 볼 수 있기 때문에 내가 구매를 해서 발생하는 비용을 줄일 수 있다.
- 새로운 책이 입고되었을 경우에 어떤 책인지 확인할 수 있다.
하지만 여기서 발생할 수 있는 문제는 무엇일까?
우리는 도서관에서 책을 빌리는 것으로 내가 구매를 하지 않더라도 책을 볼 수 있다.
하지만 그 책을 다른 사람이 보고 있다면 나는 볼 수 없다.
현재 이 상태는 책과 사람은 서로 의존을 하고 있다, 결합이 강하다 하여 강한 결합 이라는 용어로 부르게 된다.
그렇다면 이것을 어떻게 해결을 할 수 있을까?
생각을 해보면 몇가지 조건이 존재한다는 것을 알 수 있다.
- 책을 사지 않아야한다.
- 다른 사람이 보더라도 내가 볼 수 있어야한다.
- 신간이 들어오는 것을 언제나 확인할 수 있어야한다.
위와 같은 과정을 해결해주는 것을 의존성 주입(DI, Dependency Injection)이라는 용어를 사용한다.
도서관으로 보는 의존성 주입(DI)
이것을 해결하기 위해서는 책과 사람의 의존성을 느슨하게 만들어줘야한다. 이것을 느슨한 결합이라는 용어로 부른다.
이렇게 하면 해결을 할 수 있지 않을까?
- 바로 책을 E-Book의 형태로 만드는 것이다.
그렇다면 위에 말했던 모든 문제를 해결할 수 있고, 조건 또한 만족을 할 수 있게 된다.
이게 어떤식으로 바뀌었는지 알아보자.
기존의 방식대로였다면 아래 사진과 같다.
직접적으로 연결이 되어있기 때문에 위에서 이야기를 했던 것처럼 강한 결합이라는 느낌을 받을 수 있다.
변경된 방식은 어떨까? 아래 사진으로 보자.
이제 책을 읽는 사람은 직접적으로 책과의 관계가 형성된 것이 아니라, E-Book이라는 것을 통해서 읽을 수 있게 됐다.
- 책을 유료로 사지 않고 볼 수 있고
- 다른 사람이 책을 읽고 있더라도 나는 E-Book을 통해서 볼 수 있고
- 새로운 책이 업데이트가 된다면 E-Book을 확인할 수 있다.
모든 문제를 해결을 한 것이다.
무엇을 통해서? 도서관 앱이라는 매개체를 통해서
여기서는 바로 제어의 역전(IoC Inversion of Control)이라는 용어와 개념이 도입이 된다.
변경 되기 전에는 사람은 책을 직접적으로 다루는 상태에 속해있었다.
하지만 변경 후에는 책은 도서관 앱이 알아서 관리를 해주고, 도서관 앱에 들어가있는 E-Book을 통해서 볼 수 있게 됐다.
이렇게 관리해주는 주체가 바뀌는 것을 제어의 역전(IoC)라는 용어를 사용한다.
정확하게는 개발자가 권한을 가지고 있었는데, 프레임워크가 그 역할을 가져가는 것을 뜻한다.
대표적으로 내가 사용하고 있는 Nest에서는 프로바이더, Spring에서는 빈 컨테이너라는 것이 이 역할을 해준다.
사람이 직접적으로 접근을 하던 책은, 이제 앱이 관리를 해주게 된다.
즉 책의 정보는 앱이라는 것에 모두 입력이 되는 것이다.
이렇게 책에 대한 정보를 앱에 넣는 것을 위에서 이야기한 의존성 주입(DI)이라고 이야기를 하는 것이다.
위의 사진에서 생성자로 E-Book을 가져오는 것과 동일하다고 보면 된다.
객체지향 프로그래밍 OOP에서 중요하게 여기는 SOLID 원칙이라는 것이 있다.
이것을 모두 지키는 방법이 바로 의존성 주입(DI)을 통한 싱글톤 패턴을 사용하는 것이고
의존성 주입을 하기 위해서는 다른 누군가가 해줘야하기 때문에 제어의역전(IoC)라는 개념이 생겨난 것으로 추측하고 있다.
이것을...조금 더 정확하게 알기 위해서는 엄청 과거로 돌아가야한다고해서 (....) 한번 찾아보긴 하겠지만 시간이 좀 걸릴 것 같다.
결론
- 싱글톤을 사용하는 이유
- 인스턴스를 재사용하기 위하여
- IoC가 필요한 이유
- 강한 결합으로 인한 의존성을 풀어내기 위하여
- 개발자가 아닌 프레임워크 단에서 인스턴스를 관리함
- DI가 필요한 이유
- 관리를 하려면 기존의 인스턴스에 대한 정보를 주입해줘야함. 안하면 뭔지 모르니까
- 그래서 IoC 컨테이너에 DI를 하는 것으로 다른 파일에서 사용할 수 있게 됌
- 생성자로 가져오는 것을 대부분 사용함.
NestJS가 어떤식으로 IoC와 DI, 싱글톤패턴이 적용되는지에 대해서는 아래 글을 보면 알 수 있다.
프로바이더 스코프에 관한 내용은 추가를 해야할 것 같지만 :(
끝!
