[Spring] @Bean과 @Configuration, @Component

스프링 프레임워크는 객체 생성자를 DI를 위해 IoC 컨테이너에 등록해서 사용하는데, 이때 컨테이너에 등록하는 객체나 그 생성자를 Bean이라고 하며, Bean으로 관리한다는 말을 한다.

 

이렇게 스프링에 필요한 Bean을 '직접' 등록하기 위해서는 @Bean 어노테이션을 사용할 수 있지만, 우리는 보통 @Service, @Repository와 같은 어노테이션을 활용하여 자동으로 IoC 컨테이너에 Bean을 등록한다.

• 스프링은 '컴포넌트 스캔' 과정을 통해 @Component가 선언된 클래스를 Bean으로 등록한다.
• 우리에게 익숙한 @Controller, @Service, @Repository, @Configuration 모두 그 상위에 @Component를 가지고 있다.

 

스프링이 Bean으로 관리하는 것은 객체이다. 스프링은 기본적으로 컴포넌트 스캔이라는 과정을 통해 프로젝트 패키지 내의 모든 클래스를 확인하고 @Component를 가진 클래스를 IoC 컨테이너에 등록해둔다. IoC 컨테이너에 등록된 객체는 개발자가 아니라 스프링이 해당 객체의 생성을 제어(Inversion of Control)하게 된다. 이후 특정 객체(Bean)가 필요하다고 선언되어 있는 곳에 적절하게 그 객체(Bean)의 구현체를 주입해주는 것을 Dependency Injection을 수행해준다고 일컫는 것이다.

IoC가 강력한 이유 중 하나는, 하나의 인터페이스와 여러 구현체를 Bean으로 등록해둔 뒤에, 클래스 코드에는 의존성을 인터페이스로 선언해두어도 주입 관련 설정만 잘 해준다면 코드 간 느슨한 결합을 유지하면서 적절한 구현체를 주입해줄 수 있기 때문에 다형성을 활용한 유연한 디자인이 가능해지기 때문이다.

 

그렇다면 수동으로 직접 Bean을 등록하는 경우는 뭘까?

• 개발자가 직접 제어가 불가능한 라이브러리를 활용할 때
• 애플리케이션 전범위적으로 사용되는 클래스를 등록할 때
• 다형성을 활용하여 여러 구현체를 등록해주어야 할 때

 

여기서, @Configuration 과 @Component에 대해 구별해야 한다.

일반적으로 우리는 Component를 이용하여 Bean을 자동으로 등록하지만, 수동으로 @Bean 어노테이션을 활용하여 사용하고 싶다면 @Configuration을 선언한 클래스 안에서 사용해야 한다. 그 이유에 대해 잠시 알아보자.

 

스프링은 효율적인 메모리 사용을 위해 기본적으로 객체 관리를 싱글톤으로 한다. 즉, 스프링은 애초부터 기본적으로 객체의 재사용성을 높여서 메모리를 효율적으로 사용할 수 있게 디자인되어 있는 것이다.

 

하지만 수동으로 Bean을 등록하겠다고 @Component를 선언한 뒤, 그 하위에 생성 메서드에 단순히 @Bean을 달아주면 싱글톤 패턴을 별도로 설정하도록 세팅을 해줘야 하거나, 싱글톤 패턴을 사용하지 않는 방향으로 디자인해야 한다. 이렇게 되면 손봐야 하는 부분이 많아지므로 생산성이 상당히 저하될 수 밖에 없고, 실수가 발생할 경우 디버깅하는 시간도 소요될 것이다.

 

이러한 이유로 스프링에서는 @Configuaration이라는 어노테이션을 지원하며, 이를 선언한 클래스는 CGLib을 사용하므로 프록시 패턴을 통해 그 하위에서 수동으로 선언된 Bean이 싱글톤으로 생성됨을 보장해준다.(CGLib은 상속을 통해서 프록시 패턴을 구현하고 있다.)

 

결론은 다음과 같다.

스프링 프레임워크의 지향점을 고려한다면, @Configuration을 선언한 클래스 하위에서'만' 수동 Bean을 제어하겠다고 다짐하자.

 

 

출처:

[Spring] 빈 등록을 위한 어노테이션 @Bean, @Configuration, @Component 차이 및 비교 - (1/2)

 

[Spring] @Configuration 안에 @Bean을 사용해야 하는 이유, proxyBeanMethods - (2/2)