스프링을 공부하면서 컨테이너(Container)와 빈(Bean)을 여러 번 들어봤지만, 정확하게 이해하고 있는지 짚고 넘어가야 할 필요성을 느껴서 개념을 다시 공부하고 정리해보았다😎
📌IOC (Inversion of Control)
컨테이너와 빈을 알아보기 전에, 먼저 스프링의 주요 특징 중 하나인 IoC(Inversion of Control)에 대해 먼저 짚고 넘어가겠습니다.
객체를 다루는 일반적인 방법은 프로그래머가 프로그램 로직 상 필요한 객체를 필요할 때마다 직접 생성하고, 필요한 메소드를 호출하는 것입니다.
예를 들어, 자바에서 new 키워드를 통해 필요한 곳에 인스턴스를 생성하는 로직을 넣는 것처럼 말이죠🤨
하지만, 스프링에서는 클래스들의 객체를 일일이 프로그래머가 다루는 것이 아니라, 스프링에게 관리를 맡기게 됩니다! 이것이 바로 스프링의 주요 특징 중 하나인 IoC(Inversion of Control)이라는 것입니다.
❗이 때, 스프링이 객체들을 미리 생성해 관리하는 공간을 스프링 컨테이너(Container)라고 하며,
이렇게 스프링에 의하여 생성되고 관리되는 자바 객체를 스프링에서는 빈(Bean)이라고 합니다.
📌스프링 컨테이너(Container)와 빈(Bean)
스프링 컨테이너와 빈의 개념을 다시 정리하자면
스프링 컨테이너란, 스프링에서 자바 객체들을 관리하는 공간을 의미하고, 스프링 빈이란, 스프링에 의하여 생성되고 관리되는 자바 객체를 말합니다.
🏷️Application Context
스프링 컨테이너의 종류에는 이렇게 두 가지가 있습니다.
- Bean Factory
- Application Context
이 두 가지 중에서 Application Context는 빈의 생성과 관계 설정 외에 추가적인 기능을 제공해주기 때문에, 주로 Application Context를 사용합니다.
빈(Bean) 요청 시 처리 과정
클라이언트에서 해당 빈을 요청하면 Application Context는 다음과 같은 과정을 거쳐 빈을 반환합니다.
-
Application Context는
@Configuration이 붙은 클래스들을 설정 정보로 등록해두고,@Bean이 붙은 메소드의 이름으로 빈 목록을 생성합니다. -
클라이언트가 해당 빈을 요청합니다.
-
Application Context는 자신의 빈 목록에서 요청한 이름이 있는 지 찾습니다.
-
Application Context는 설정 클래스로부터 빈 생성을 요청하고, 생성된 빈을 반환합니다.
➕Application Context가 빈을 반환할 때, Spring 내부에서 Reflection API를 이용해 빈 정의에 나오는 클래스 이름을 이용하거나 Bean Factory를 통해 빈을 생성합니다.
Application Context의 장점
📍클라이언트는 @Configuration이 붙은 구체적인 팩토리 클래스를 알 필요가 없다.
애플리케이션이 발전하면 팩토리 클래스가 계속해서 증가할텐데, Application Context가 없다면 클라이언트는 원하는 객체를 가져오려면 어떤 팩토리 클래스에 접근해야 하는지 알아야 하는 번거로움이 생깁니다. 반면에, Application Context를 사용하면 팩토리가 아무리 많아져도 이에 직접 접근할 필요가 없어집니다. 즉, 일관된 방식으로 원하는 빈을 가져올 수 있게 되는 것이죠!
📍Application Context는 종합 IoC 서비스를 제공해줍니다.
Application Context는 객체의 생성과 관계 설정이 다가 아닙니다. 객체가 만들어지는 방식과 시점 및 전략 등을 다르게 가져갈 수 있고, 그 외에도 후처리나 정보의 조합 인터셉트 등과 같은 다양한 기능이 존재합니다.
📍다양한 빈 검색 방법을 제공할 수 있습니다.
Application Context에서 빈 목록을 관리하여, 빈의 이름이나 타입 또는 어노테이션 설정 등으로 빈을 찾을 수 있습니다. 이러한 빈을 직접 찾는 방식을 의존성 검색(Dependency Lookup)이라고 부릅니다.
🏷️싱글톤 (Singleton)
이렇게 Application Context에 의해 등록된 빈은 기본적으로 기본적으로 싱글톤(Singleton)으로 관리됩니다.
즉, 스프링에 여러 번 빈을 요청하더라도 매번 동일한 객체를 돌려준다는 것이죠!
Application Context가 싱글톤으로 빈을 관리하는 이유는 대규모 트래픽을 처리할 수 있도록 하기 위함입니다.
스프링은 처음에 설계될 때부터 대규모의 엔터프라이즈 환경에서 요청을 처리할 수 있도록 고안되었습니다. 그리고 그에 따라 계층적으로 처리 구조가 나뉘어지게 되었죠.
그런데, 매번 클라이언트의 요청이 올 때마다 각 로직을 처리하는 빈을 새로 만들어서 사용한다고 생각을 해봤을 때, 무수히 많은 요청을 처리하기에는 감당하기 힘들 것입니다.😣
그래서 이러한 문제를 해결하고자 빈을 싱글톤 스코프로 관리하여 1개의 요청이 왔을 때 여러 스레드가 빈을 공유해 처리하도록 한 것입니다.
싱글톤(Singleton)의 한계
반면에, 이러한 한계들도 존재합니다.
📍private 생성자를 가지고 있어 상속이 불가능하다.
📍테스트를 하기 힘들다.
📍서버 환경에서는 싱글톤이 1개만 생성됨을 보장하지 못한다.
📍 전역 상태를 만들 수 있기 때문에 객체지향적이지 못하다.
싱글톤 레지스트리 (Singleton Registry)
이러한 싱글톤의 한계 때문에, 스프링은 싱글톤 레지스트리라는 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공합니다.
싱글톤 레지스트리를 사용하게 되면 싱글톤 패턴(static 메소드나 private 생성자 사용 등)으로 클래스를 구현하지 않고도, 스프링 컨테이너에 등록된 빈을 기본적으로 싱글톤으로 관리해줍니다.
쉽게 말해서 우리가 평범하게 짠 자바 코드도 싱글톤으로 관리할 수 있다는 뜻입니다.
이렇게 스프링에서 직접 싱글톤으로 객체를 관리해주므로, 우리는 더욱 객체지향적인 개발을 할 수 있게 됩니다👍
📚Reference
스프링 빈과 컨테이너, 그리고 의존 관계
스프링은 빈을 왜 싱글톤으로 생성할까
