[Spring] @Configuration 안에 @Bean을 사용해야 하는 이유

Spring에서 수동으로 빈을 등록할 때에는 @Configuration 클래스 안에서 @Bean을 사용해야 한다. 왜 @Configuraiton 클래스 안에서 @Bean을 사용해야 하는지 살펴보도록 하자.

 

@Configuration 안에 @Bean을 사용해야 하는 이유, proxyBeanMethods

@Configuration 안에 @Bean을 사용해야 하는 이유

 

@Bean 어노테이션을 이용한 수동 빈 등록

스프링에서는 일반적으로 컴포넌트 스캔을 사용해 자동 빈 등록 방법 사용,

그러나 @Bean 어노테이션을 이용해 수동으로 빈을 등록해야 하는 경우도 존재한다.

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

 

@Bean을 이용한 수동 빈 메소드는 스프링 빈 안에만 구현되어 있다면 모두 동작한다.

하지만, 스프링은 @Bean은 반드시 @Configuration 어노테이션을 활용하도록 강조하는데, 그 이유는 @Configuration에 특별한 부가 기능이 적용되기 때문이다.

 

@Configuration에 적용되는 프록시 패턴

@Configuration 어노테이션 안에는 @Component 어노테이션이 붙어이썽서 @Configuration이 붙어있는 클래스 역시 스프링의 빈으로 등록된다. 그럼에도 불구하고 @Configuration을 따로 만든 이유는 CGLib으로 프록시 패턴을 적용해 수동으로 등록하는 스프링 빈이 반드시 싱글톤으로 생성됨을 보장하기 위해서이다.

예를 들어 스프링 빈으로 등록하고자 하는 클래스가 있다고 가정하자.

public class AbcResource {

}

 

위의 클래스를 @Component를 이용해 자동으로 빈 등록을 한다면 스프링이 해당 클래스의 객체 생성을 제어하고 (제어의 역전, IoC) 1개의 객체만 생성되도록 컨트롤할 수 있다. 하지만 위의 클래스를 @Bean을 사용해 직접 빈 등록을 한다면 개발자 입장에서 다음과 같이 빈 등록 메서드를 여러 번 호출할 수 있게 된다.

@Configuration
public class MyBeanConfiguration { 

    @Bean 
    public AbcResource abcResource() {
        return new AbcResource(); 
    } 
    
    @Bean 
    public MyFirstBean myFirstBean() { 
        return new MyFirstBean(abcResource()); 
    } 
    
    @Bean 
    public MySecondBean mySecondBean() { 
        return new MySecondBean(abcResource()); 
    } 
}

 

실수로 위와 같이 빈을 생성하는 메소드를 여러 번 호출하였다면 불필요하게 여러 개의 빈이 생성이 된다. 스프링은 이러한 문제를 방지하고자 @Configuration이 있는 클래스를 객체로 생성할 때 CGLib 라이브러리를 사용해 프록시 패턴을 적용한다. 그래서 @Bean이 있는 메소드를 여러 번 호출하여도 항상 동일한 객체를 반환하여 싱글톤을 보장한다. 이를 이해하기 쉬운 코드로 나타내면 다음과 같다.

@Configuration
public class MyBeanConfigurationProxy extends MyBeanConfiguration { 

    private Object source;

    @Override
    public AbcResource abcResource() {
        if (source == null) {
            source = super.abcResource();
        }
        
        return source; 
    } 
    
    @Override
    public MyFirstBean myFirstBean() { 
        return super.myFirstBean();
    } 
    
    @Override
    public MySecondBean mySecondBean() { 
        return super.mySecondBean();
    } 
}

 

CGLib은 상속을 사용해서 프록시를 구현하므로 다음과 같이 프록시가 구현된다고 이해할 수 있다. 물론 실제로는 이렇게 생성되지 않고 내부 클래스를 사용하는 등의 차이가 있으므로 이해를 돕기 위한 코드로만 생각하면 된다. 

 

 

싱글톤 여부를 제어하기 위한 proxyBeanMethods 

대부분의 경우에는 @Bean에 의한 수동 빈 등록을 할 때 싱글톤으로 생성되기를 원한다. 하지만 @Bean 메소드를 호출할 때 의도적으로 매번 다른 객체가 생성되기를 원할 수 있다. 그럴 때에는 @Configuration 어노테이션이 갖고 있는 proxyBeanMethods를 false로 주면 된다. 예를 들어 아까 봤던 코드에 다음과 같이 proxyBeanMethods를 false로 주었다고 하자.

@Configuration(proxyBeanMethods = false)
public class MyBeanConfiguration { 

    @Bean 
    public AbcResource abcResource() {
        return new AbcResource(); 
    } 
    
    @Bean 
    public MyFirstBean myFirstBean() { 
        return new MyFirstBean(abcResource()); 
    } 
    
    @Bean 
    public MySecondBean mySecondBean() { 
        return new MySecondBean(abcResource()); 
    } 
}

그러면 위의 설정 클래스에 대해서는 프록시가 적용되지 않으며 모든 @Bean 메소드 호출마다 새로운 객체를 생성해준다. 하지만 거의 모든 상황에서 새로운 객체의 생성을 필요로 하는 경우는 거의 없다. @Configuration이 아니라면 빈이 싱글톤임을 보장받을 수 없으므로 반드시 @Configuration 안에 @Bean을 사용해주도록 하자.

 

 

[출처]

[Spring] @Configuration 안에 @Bean을 사용해야 하는 이유, proxyBeanMethods - (2/2) - MangKyu's Diary (tistory.com)

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