IOC (Inversion of Control)
IOC 이란 무엇일까요? 단어 그대로 ‘제어의 역전’ 입니다. 아래 그림을 살펴보겠습니다.
제어의 주체의 변화에 중점을 두고 보면 이해가 쉽습니다.
내가 제어 주체인 App1 은 외부 라이브러리를 불러와 내 입맛에 맞게 사용하는 전통적인 형태의 절차적 프로그래밍이라고 볼 수 있겠습니다. 라이브러리가 늘어나면 늘어날 수록 프로그램이 커지면 커질수록 ‘내가’ 제어해야하는 책임은 계속 늘어나게 됩니다.
누군가(외부) 가 프로그램 App2을 만들었습니다. App2 에서는 누군가가 만든 코드가 내가 만든 코드를 호출하여 사용합니다. 이제 App2 에서는 ‘나’ 는 많아지는 책임에서 벗어나 행복할 수 있습니다. ‘나’ 는 멋진 프로그램을 만든 누군가에게 고맙다고 생각하며 리스펙 합니다. App2 에서 누군가 만든 코드는 프레임 워크 (Spring, Laravel, Django, Rails)이라는 이름으로 불리고 있습니다.
소스 코드의 흐름이 내 코드에 있었다면 외부로 흐름이 변경되는 경우 Inversion of Control 이 생겼다고 볼 수 있습니다. IOC 를 구현한 대표적인 예시로는 DI 패턴, Strategy 패턴 등이 있습니다. 제 이전 포스팅에서 IOC 가 발생한 부분을 쉽게 찾아볼 수 있을 겁니다.
IOC Container ?? DI Framework ??
프레임 워크에서 IOC 를 구현하는 방법으로 컨테이너 라는 개념이 도입되었습니다. 이 컨테이너는 보통 객체 의존 관계를 관리하며 의존성 주입하는 역할을 담당합니다. 보통 IOC 를 구현하여 IOC Container 라는 포괄적인 이름으로 불리기도 하며 DI 를 구현하고 있어 DI Framework 라는 이름으로 불리기도 합니다. 명칭 정의가 확실히 되지 않은 부분이 있어 두 가지가 혼용되어 사용된다고 합니다. 명칭보다 역할에 집중하여 자동으로 객체 의존 관리를 해주는 Container 라고 생각하면 될 거 같습니다.
TL;DR
- 제어의 권한을 외부 소스 코드가 관리하는 형태가 되는 경우 제어 주체가 소스 작성자에서 외부 소스로 이동하면서 IOC( Inversion of Control) 가 발생되었다라고 볼 수 있다.
- DI 를 구현하는 프레임 워크에서는 객체 의존성을 관리하는 컨테이너가 존재하는데 보통 IOC Container 또는 DI Framework 라고 불린다.