[Spring] 스프링의 핵심 개념, DI / IoC란 무엇인가? (의존성 주입, 제어의 역전)

🏝 0. 서론

스프링 프레임워크에 대해 학습하고자 한다면, DI와 IoC는 한 번쯤은 들어보았을 키워드이다.

스프링 트라이앵글, 출처 : https://sehun-kim.github.io/sehun/springbean-lifecycle/#2

"스프링이란 IoC와 AOP를 지원하는 경량의 컨테이너 프레임워크이다." - 스프링에 대한 한 줄 설명

스프링의 3대 요소를 나타내는 스프링 트라이앵글에서 당당히 한 자리를 차지하고 있는 DI/IoC는 스프링 프레임워크를 활용하기 위해 반드시 알아야 하는 개념이다.

사실, DI와 IoC는 스프링에만 국한된 개념이 아니다.

출처 : https://www.tutorialsteacher.com/ioc

여기서 볼 수 있듯이, DI와 IoC는 각각 디자인 패턴, 디자인 원칙에 해당하는 것으로

꼭 스프링이 아니더라도 직접 구현할 수 있거나, 다른 프레임워크에서도 나올 수 있는 개념이다.

디자인 원칙은 특정한 효과를 얻기 위해 권장하는 방식을 의미하는 것이다. 즉, best practice를 지향하는 지침이지만, 정확한 세부 구현 방법을 제시하지는 않는다는 것이다.

디자인 패턴은, 디자인 원칙에 대해 구현하는 방법에 대해 제시하는 것으로 빈번하게 나타나는 구현 방법을 패턴으로써 정의해 사용하는 것을 의미한다.

따라서, DI는 IoC를 구현하는 디자인 패턴 중 하나라고 인지하고 있으면 된다.

출처 : https://www.tutorialsteacher.com/ioc

위의 그림과 같이, IoC를 구현하는 디자인 패턴에는 DI도 있지만, 다른 여러 패턴들도 존재한다.

즉, IoC는 다른 패턴으로도 구현이 가능하다는 점을 알고, 그럼에도 스프링에서 IoC와 DI라는 말이 왜 항상 붙어다닐까?를 생각하면 글을 읽는데 더욱 도움이 될 것이다.

필자도 스프링을 사용해 백엔드 개발자가 되길 지망하지만, 정확히 이 개념에 대해 알지 못하고 혼란스러웠다.

따라서 오늘 포스팅에서는 DI와 IoC에 대한 개념과 설명 / Spring에서는 어떻게 DI/IoC가 적용되는지에 대해 정리해보도록 하겠다.

 

---

 

💡 1. DI (Dependency Injection) : 의존관계(의존성) 주입

> 1-1. DI에 대한 요약 설명

한 줄로 설명하면, 어떤 객체가 사용하는 의존 객체를 직접 생성하는 것이 아니라, 주입 받아 사용하는 것이다.

아직은 쉽게 와닿지 않을 수 있으나, 하단의 1-2 챕터에서 '의존 관계'에 관한 설명과 비유를 통해 이를 이해할 수 있을 것이다.

 

> 1-2. '의존관계'이란 무엇인가?

'두 개의 클래스 혹은 모듈이 의존관계에 있다'라는 것은, 누가 누구에게 의존하는 관계에 있다는 식으로 방향성이 있다.

위의 UML을 보면, 의존관계를 위와 같이 점선으로 표현하고, A가 B에 의존하고 있음을 나타낸다.

'A가 B에 의존하고 있다'라는 것은, B가 변화하면 A에 영향을 줄 수 있다는 것을 의미한다.

예를 들어, B의 기능이 추가 혹은 변경되거나, 형식이 바뀌면 그 영향이 A로 전달되는 것이다.

대표적으로 A에서 B에 정의된 메소드를 호출하는 경우 의존관계가 있다고 표현할 수 있는 것이다.

방향성이 있기 때문에, B는 A의 변화에 영향을 받지 않는다는 것도 알아두어야 할 점이다.

 

> 1-3. 비유를 통한 DI에 대한 이해

위의 '의존관계'에 대해서 굉장히 딱딱하게 설명을 했지만, 좋은 비유를 발견해 출처를 남기고 인용하려고 한다.

출처 : https://m.blog.naver.com/PostView.nhn?blogId=ljh0326s&logNo=221395815870&proxyReferer=https:%2F%2Fwww.google.com%2F

위와 같이 장난감들이 있다. 장난감은 배터리를 통해 전력을 공급받아서 작동하는 구조로 되어있다.

장난감은 배터리가 있어야 동작할 수 있으므로, 장난감은 배터리에 의존하고 있다.

즉, 방향성으로 표기하면 장난감 → 배터리로 표기할 수 있다.

클래스의 관점으로 보면, 장난감 클래스와 배터리 클래스가 있고, 장난감 클래스의 기능을 온전하게 구현하기 위해서 멤버 변수로 배터리 클래스로 생성된 인스턴스를 갖고 있다고 볼 수 있다.

 

출처 : https://m.blog.naver.com/PostView.nhn?blogId=ljh0326s&logNo=221395815870&proxyReferer=https:%2F%2Fwww.google.com%2F

 

이때, 배터리 일체형인 장난감과 배터리 분리형의 장난감으로 나누어져있는데, 이 두 가지 장난감을 비교해보자.

배터리 일체형 장난감은 의존객체인 배터리를 직접 생성한 장난감에 해당하고,

배터리 분리형 장난감은 의존객체인 배터리를 주입(전달)받아 사용하는 장난감에 해당한다.

분리형 장난감은 생성자를 통해 배터리를 주입하거나, setter method를 생성해 배터리를 주입한다.

 

> 1-4. DI로 얻을 수 있는 장점은 무엇인가?

배터리 일체형 장난감은, 배터리를 모두 사용하게 되면 장난감을 바꿔야 한다.

장난감이 배터리에 강력한 결합으로 의존하고 있기 떄문이다.

반면에, 배터리 분리형 장난감은, 배터리를 사용하지만 다 떨어지면 장난감을 바꾸는 것이 아니라 배터리만 갈아 끼워주면 된다.

이는 장난감이 배터리에 느슨한 결합으로 의존하고 있기 때문에 가능하다.

배터리를 모두 사용했다는 것은 비유적 표현이고, 정확하게 말하면 '종속 객체에 변화가 생겼다면'을 의미한다.

종속 객체 내부적으로 수정 및 변경 사항이 있는 경우 강력한 결합을 하고 있는 클래스라면 해당 클래스 내부의 코드 역시 수정이 필요하다.

반면 종속 객체 내부의 수정 및 변경이 있더라도(있을 예정이라도) 느슨한 결합을 이루고 있는 클래스라면 setter method나, 생성자를 통해 유기적인 종속 관계 주입이 가능하다.

즉 디자인 패턴인 DI(Dependency Injection)는 모듈간의 결합도를 낮추기 위한 전략적인 방법이라고 볼 수 있다.

 

> 1-5. DI의 한글 번역에 의한 관점

DI는 Dependency Injection의 약어로, 직역하면 의존성 주입으로 나타낼 수 있어서 많은 자료나 도서에서 이와 같이 표현하곤 한다.

그러나 DI의 의미가 무엇인지, 의존성이라는 말로는 잘 표현하기가 어렵다. 이런 모호한 표현보다는, 의존관계 주입이라는 정확한 의도를 가진 표현을 사용하면 DI가 어떤 의미인지 좀 더 명확하게 표현할 수 있을 것 같다.

'Dependency Injection'은 여러 가지 우리말로 번역돼서 사용된다. 그중에서 가장 흔히 사용되는 용어가 의존성 주입이다. 하지만 의존성이라는 말은 DI의 의미가 무엇인지 잘 드러내주지 못한다. 또한 의존(종속) 오브젝트 주입이라고도 부르기도 하는데, 이때는 DI가 일어나는 방법에 초점을 맞춘 것이다. 엄밀히 말해서 오브젝트는 다른 오브젝트에 주입할 수 있는 게 아니다. 오브젝트의 레퍼런스가 전달될 뿐이다. DI는 오브젝트 레퍼런스를 외부로부터 제공(주입)받고 이를 통해 여타 오브젝트와 다이내믹하게 의존관계가 만들어지는 것이 핵심이다. 용어는 동작방식(메커니즘)보다는 의도를 가지고 이름을 짓는 것이 좋다. 그런 면에서 의존관계 주입이라는 번역이 적절할 듯싶고, 이 책에서는 이를 사용한다. 하지만 DI가 무엇인지만 잘 인식하고 있다면 어떤 용어를 사용해도 상관없다. 의도를 강하게 드러내는 '의존관계 설정'이라는 용어도 나쁘지 않다고 생각한다.
- 토비의 스프링 3.1에서 발췌

---

 

💡 2. IoC(Inversion of Control) : 제어의 역전

> 2-1. 제어의 역전은 무엇인가?

IoC는 객체지향 설계에서 클래스간의 결합도를 느슨하게 하기 위해 다양한 종류의 제어를 반전시킬 것을 권장하는 디자인 원칙이다.

IoC에 대한 개념이 굉장히 헷갈리는 이유는, 용어가 사용되는 범위가 굉장히 광범위하다.

다양한 종류의 제어를 반전시키는 것을 권장하는 IoC라는 단어는,

깊게는 종속성을 가진 클래스의 객체 생성 제어를 역전하는 것(제어를 다른 클래스에 위임)에 쓰이는 자료도 보았고,

얕게는 모든 객체에 대한 제어권을 개발자가 아닌 IoC 컨테이너에게 위임하는 것에 쓰이는 자료도 보았다.

종속성을 가진 클래스의 객체 생성 제어를 역전하는 것(제어를 다른 클래스에 위임)이 IoC 원칙을 따른 것 중의 하나를 잘 나타내는 말이고,

모든 객체에 대한 제어권을 개발자가 아닌 IoC 컨테이너에게 위임하는 것은 스프링 프레임워크가 IoC 원칙과 DI 패턴을 일일히 구현하지 않도록 제공하는 것을 표현한 말이라고 볼 수 있다.

 

> 2-2. Spring에서의 DI와 IoC / DI(IoC) Container의 장점

위에서 말했듯이, 스프링에서는 IoC 원칙과 DI 패턴을 일일히 구현하지 않도록 IoC 컨테이너를 제공한다.

스프링에서 DI와 IoC가 따라다닌 이유는, IoC 컨테이너가 IoC 원칙을 따른 다른 패턴을 대신해주는 것이 아니라 IoC, DIP, DI에 대한 구현을 우리 대신 제공하기 때문이다.

이처럼 IoC가 가지고 있는 말의 범위가 너무 넓기 때문에, DI Container라고 표기하는 것을 권장한다고 한다.

 

한 가지 짚고 넘어갈 것은 여기서 사용하는 IoC라는 용어인데, IoC가 매우 느슨하게 정의돼서 폭넓게 사용되는 용어라는 점이다. 때문에 스프링을 IoC 컨테이너라고만 해서는 스프링이 제공하는 기능의 특징을 명확하게 설명하지 못한다. 스프링이 서블릿 컨테이너처럼 서버에서 동작하는 서비스 컨테이너라는 뜻인지, 아니면 단순히 IoC 개념이 적용된 템플릿 메소드 패턴을 이용해 만들어진 프레임워크인지, 아니면 또 다른 IoC 특징을 지닌 기술이라는 것인지 파악하기 힘들다. 그래서 새로운 용어를 만드는 데 탁월한 재능이 있는 몇몇 사람의 제안으로 스프링이 제공하는 IoC 방식의 핵심을 짚어주는 의존관계 주입(Dependency Injection)이라는, 좀 더 의도가 명확히 드러나는 이름을 사용하기 시작했다. 스프링 IoC 기능의 대표적인 동작원리는 주로 의존관계 주입이라고 불린다. 물론 스프링이 컨테이너이고 프레임워크이니 기본적인 동작원리가 모두 IoC 방식이라고 할 수 있지만, 스프링이 여타 프레임워크와 차별화돼서 제공해주는 기능은 의존관계 주입이라는 새로운 용어를 사용할 때 분명하게 드러난다. 그래서 초기에는 주로 IoC 컨테이너라고 불리던 스프링이 지금은 의존관계 주입 컨테이너 또는 그 영문약자를 써서 DI 컨테이너라고 더 많이 불리고 있다.
- 토비의 스프링 3.1에서 발췌

 

여기까지 스프링이 DI Container를 통해 우리에게 무엇을 제공하는지 알았다.

그렇다면, 우리가 무엇을 제공해야 스프링의 DI Container가 IoC, DIP, DI에 대한 구현을 제공할까? 또 어떻게 이러한 구현을 제공할 수 있을까?

이를 알기 위해 Spring Bean부터 알아야 한다. 오늘은 DI와 IoC에 대한 중점적인 설명이므로, Spring Bean에 대해 간략하게만 설명하겠다.

간단히 설명하면, Spring Bean은 DI 컨테이너가 관리하는 자바 객체를 의미한다.

이 스프링 빈으로 등록된 객체를 DI 컨테이너가 의존 관계를 주입시킨다.

사용자의 시간 절약과 반복 구현에 대한 불편함을 해소하기 위해 프레임워크가 DI를 대신해준다는 것은, 내가 만든 클래스에 대해서도 Spring Bean으로 등록할 수 있다는 것이다.

따라서 이 Spring Bean으로 등록하는 과정에서 의존관계에 대한 메타데이터를 Spring에게 제공하는 것이다.

이 메타 데이터는 XML을 통해서, 어노테이션을 통해서, 자바를 통해서 설정이 가능하다.

 

 

위 다이어그램은, Spring의 DI Container가 어떻게 동작하는지 추상화한 다이어그램이다.

org.springframework.context.ApplicationContext 인터페이스는 DI Container를 나타내며, 클래스들은 구성에 대한 메타 데이터와 함께 결합되어, ApplicationContext가 생성되고 초기화된 이후에는 드디어 실행 가능하고 온전히 구성되어 있는 어플리케이션이 된다.

인스턴스 생성부터 소멸까지의 인스턴스 생명주기 관리를 개발자가 아닌 컨테이너가 대신 해주는 것은, 개발자에게 굉장히 매력적인 장점이다. 객체관리 주체가 프레임워크(Container)가 되기 때문에 개발자는 로직에만 집중할 수 있기 때문이다.

• IoC 컨테이너는 객체의 생성을 책임지고, 의존성을 관리한다.
• POJO의 생성, 초기화, 서비스, 소멸에 대한 권한을 가진다.
• 개발자들이 직접 POJO를 생성할 수 있지만 컨테이너에게 맡긴다.
• 개발자는 비즈니스 로직에 집중할 수 있다.
• 객체 생성 코드가 없으므로 TDD가 용이하다

 

> 2-3. 왜 Spring은 '프레임워크'인가?

'프레임워크'와 '라이브러리'의 차이를 설명하는 핵심 키워드는 IoC이다.

라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다. 단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다. 반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다. 보통 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식이다. 프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 한다. 애플리케이션 코드는 프레임워크가 짜놓은 틀에서 수동적으로 동작해야 한다.
- 토비의 스프링 3.1 중에서 발췌.

---

💡 3. 요약

- IoC는 소프트웨어 개발에서 모듈간의 결합도를 줄이기 위해 제어의 반전을 권장하는 디자인 원칙에 해당하고, DI는 IoC 원칙을 구현하는 디자인 패턴 중 하나로 생성자와 setter method를 통해 의존 관계를 주입함으로써 모듈간의 결합도를 줄인다.

- 스프링은 이러한 IoC 원칙과 DI 구현을 대신 해주는 IoC 컨테이너를 제공하는 프레임워크이다.

- 인스턴스 생성부터 소멸까지의 인스턴스 생명주기 관리를 개발자가 아닌 컨테이너가 대신 해주는 것은, 개발자에게 굉장히 매력적인 장점이다. 객체관리 주체가 프레임워크(Container)가 되기 때문에 개발자는 로직에만 집중할 수 있기 때문이다.

---

😎 참고 자료 출처

[도서] 토비의 스프링 3.1 vol1. 스프링의 이해와 원리

[링크] https://sehun-kim.github.io/sehun/springbean-lifecycle/#2 ([Spring] 예제로 배워보는 IoC/DI & Spring Bean Life Cycle)

[링크] https://devlog-wjdrbs96.tistory.com/165 ([Spring] 스프링 의존성 주입(DI) 이란?)

[링크] https://velog.io/@meme2367/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%8A%B8%EB%9D%BC%EC%9D%B4%EC%95%B5%EA%B8%80Spring-Triangle-IoC-AOP-PSA (스프링 트라이앵글(Spring Triangle) - IoC, AOP, PSA)

[링크] https://prohannah.tistory.com/157 (Java로 알아보는 IoC, DIP, DI, IoC Container)

[링크] https://johngrib.github.io/wiki/inversion-of-control/ (IoC, Inversion of Control)

[링크] https://dev-coco.tistory.com/80 ([Spring] IoC 컨테이너)

 

아직 미흡하지만 의욕많은 개발자입니다.
글 중에 틀린 내용이 있거나, 지적사항이 있다면
좋은 댓글 남겨주시면 반영하겠습니다 :)