💻 [Spring] 스프링 핵심원리 - 3. IoC, DI, 그리고 컨테이너

안녕하세요. 👋

스프링으로 여러 프로젝트를 개발했었는데 

문득 스프링 자체 핵심 원리에 대한 복습이 하고 싶었습니다.

그래서 김영한님의 스프링 핵심원리 강의를 들으며 

스프링을 왜 사용해야하는지와

스프링 핵심원리에 대해 학습한 내용입니다. 

세번째 포스트입니다.

이전 두번째 포스트에서 직접 순수 자바만을 이용해 객체 지향 원리를 적용해 프로젝트를 개발해보았습니다. 이 과정에서 왜 IoC, DI, 컨테이너 같은 개념들이 필요해지고 등장하게 되었는지를 알 수 있었습니다. 이번 세번째 포스트에서는 앞선 과정에서 등장하게 된 IoC, DI, 컨테이너에 대해 정리하는 시간입니다.

두번째 포스트 와 함께 보시면 이해하기가 더 쉬울 것 입니다.

1. 제어의 역전 IoC (Inversion of Control)

※ 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것 을 제어의 역전(IoC) 이라 한다.

• 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다. 한 마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다.

• 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제 어 흐름은 이제 AppConfig가 가져간다. 예를 들어서 OrderServiceImpl 은 필요한 인터페이스들을 호 출하지만 어떤 구현 객체들이 실행될지 모른다.

• 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있다. 심지어 OrderServiceImpl 도 AppConfig가 생성한다. 그리고 AppConfig는 OrderServiceImpl 이 아닌 OrderService 인터페 이스의 다른 구현 객체를 생성하고 실행할 수 도 있다. 그런 사실도 모른체 OrderServiceImpl 은 묵묵히 자신의 로직을 실행할 뿐이다.

• 이렇듯 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)이라 한다.

2. 프레임워크 vs 라이브러리

※ 작성 되어있는 코드를 내가 직접 호출해 가져다쓰면 라이브러리이고 반대로 내가 작성한 코드를 외부에서 제어하면 그 외부가 프레임워크다.

프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다. (JUnit) 반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리다.

3. 의존관계 주입 DI(Dependency Injection)

• OrderServiceImpl 은 DiscountPolicy 인터페이스에 의존한다. 실제 어떤 구현 객체가 사용될지는 모른다.
• 의존관계는 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계 둘을 분리 해서 생각해야 한다.

정적인 클래스 의존관계

클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있다 (정적). 정적인 의존관계는 애플리케이션을 실행하지 않아도 분석할 수 있다. 클래스 다이어그램을 보자. OrderServiceImpl 은 MemberRepository , DiscountPolicy 에 의존한다는 것을 알 수 있다.

그런데 이러한 클래스 의존관계 만으로는 실제 어떤 객체가 OrderServiceImpl 에 주입 될지 알 수 없다.

클래스 다이어그램

동적인 객체 인스턴스 의존 관계

애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계다.

객체 다이어그램

• 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언 트와 서버의 실제 의존관계가 연결 되는 것을 의존관계 주입이라 한다.

• 객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결된다.

• 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스 를 변경할 수 있다.

• 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽 게 변경할 수 있다.

4. IoC 컨테이너, DI 컨테이너

• AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC 컨테이너 또는 DI 컨테이너라 한다.
• 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라 한다.
• 애플리케이션 전체에 대한 구성을 조립을 한다고 해서 어샘블러라고도 한다.
• 오브젝트를 생성해낸다고 해서 오브젝트 팩토리 등으로 불리기도 한다.

5. 스프링 컨테이너

• 스프링 컨테이너를 부를 때 BeanFactory , ApplicationContext 로 구분해서 이야기 한다. 하지만 BeanFactory 를 직접 사용하는 경우는 거의 없으므로 일반적으로 ApplicationContext 를 스프링 컨테이너라 한다.

• 기존에는 개발자가 AppConfig 를 사용해서 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이 너를 통해서 사용한다.

• 스프링 컨테이너는 @Configuration 이 붙은 AppConfig 를 설정(구성) 정보로 사용한다. 여기서 @Bean 이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 한다.

• 스프링 빈은 @Bean 이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다. ( memberService ,orderService )

• 이전에는 개발자가 필요한 객체를 AppConfig 를 사용해서 직접 조회했지만, 이제부터는 스프링 컨테이너 를 통해서 필요한 스프링 빈(객체)를 찾아야 한다. 스프링 빈은 applicationContext.getBean() 메서드 를 사용해서 찾을 수 있다.

• 기존에는 개발자가 직접 자바코드로 모든 것을 했다면 이제부터는 스프링 컨테이너에 객체를 스프링 빈으로 등록하고, 스프링 컨테이너에서 스프링 빈을 찾아서 사용하도록 변경되었다.

끝

스프링을 더 올바르게 사용하기 위해 김영한님의 스프링 핵심 원리 강의를 들으며 정리한
세번째 포스트였습니다.
감사합니다. 🙏

스프링 핵심원리 포스트

1. 객체 지향 설계와 스프링
2. 스프링 핵심 원리 이해 1,2

Reference

김영한님의 스프링 핵심원리