[SpringBoot] 빈 등록과 생성은 다르다 (feat. BeanDefinition)

🕵🏻‍♀️ 궁금증을 갖게 된 계기

학습 과정에서 다음과 같은 예시 코드를 마주하게 됐다.

@Test
void test3() {
    StaticApplicationContext context = new StaticApplicationContext();
    context.registerBeanDefinition("printer", new RootBeanDefinition(Printer.class));

    BeanDefinition helloDef = new RootBeanDefinition(Hello.class);
    helloDef.getPropertyValues().addPropertyValue("name", "Spring");
    helloDef.getPropertyValues().addPropertyValue("printer", new RuntimeBeanReference("printer"));
    context.registerBeanDefinition("hello", helloDef);

    Hello hello = context.getBean("hello", Hello.class);
    hello.print();
}

 

위의 코드를 보고, 왜 #registerbeanDefinition 을 사용했을까 하는 의문이 들었다. 그냥 registerBean 을 하면 되는 게 아닌가? 이러한 단순한 궁금증과 일종의 반발심에 찾아보기 시작했다.

 

---

✅ BeanDefinition 이란?

A BeanDefinition describes a bean instance, which has property values, constructor argument values, and further information supplied by concrete implementations.

 

공식 문서에서는 BeanDefinition 을 위와 같이 정의하고 있다. 해석하자면 BeanDefinition 은 빈 인스턴스를 설명하는 역할을 한다. 또한 속성 값과 생성자의 인자 값, 그리고 구체적인 구현체들에 의해 제공되는 정보들을 갖는다는 것이다.

BeanDefinition 의 속성 값

정의에서 이야기하는BeanDefinition 의 속성 값이란 무엇일까? 이는 단순히 객체의 필드값이라고 생각하면 된다.

 

Student 라는 객체가 있을 때 name 이라는 필드의 값도 속성 값이고, Service 가 Repository 를 의존한다면 이 역시도 속성 값이다. BeanDefinition 에서는 이를 직접 설정해줄 수 있다.

 

BeanDefinition helloDef = new RootBeanDefinition(Hello.class);
helloDef.getPropertyValues().addPropertyValue("name", "Spring");
helloDef.getPropertyValues().addPropertyValue("printer", new RuntimeBeanReference("printer"));

 

앞서 제시한 예시 코드에서도 이와 같은 내용을 확인할 수 있다.

BeanDefinition 의 속성 값들을 #getPropertyValues 를 통해 모두 가져오고, key 와 value 를 정의해 #addPropertyValue 를 통해 속성을 추가한다.

속성 값이 세팅되는 원리

문득 이 속성 값은 어떻게 세팅되는지 궁금했다. key 와 value 형태이니 필드명일까? 아니면 setter 의 이름일까?

우선 정답은 setter 이다. 

helloDef.getPropertyValues().addPropertyValue("name", "Spring");

public class Hello {
	private final String name; 
	
	public void setName(String name){
	}
}

helloDef.getPropertyValues().addPropertyValue("naaame", "Spring");

public class Hello {
	private final String name; 
	
	public void setNaaame(String name){
	}
}

위의 두 코드는 모두 정상 작동한다. 즉, setXXX 를 통해 속성이 세팅되는 것이다.

RuntimeBeanReference

BeanDefinition helloDef = new RootBeanDefinition(Hello.class);
helloDef.getPropertyValues().addPropertyValue("name", "Spring");
helloDef.getPropertyValues().addPropertyValue("printer", new RuntimeBeanReference("printer"));

 

앞선 예시 코드에도 나타나 있듯, RuntimeBeanReference 를 생성해 내부에 "printer" 를 단순히 문자열로 넣고 있다.

그럼에도 어떻게 Helllo 라는 클래스의 필드에 정상적으로 Printer 클래스에 대한 의존성 주입이 이뤄지는 것일까?

 

우선 RuntimeBeanReference 는 빈 설정 정보 중 다른 빈을 참조할 필요가 있는 경우 사용하는 클래스이다. 즉, ‘나중에 나 이 값 필요하니까 런타임에 찾아서 주입해줘~’ 하는 요구사항인 것이다.

 

또한 문자열로만 정의하더라도 해당 Printer 의 인스턴스를 정상적으로 찾아 주입할 수 있는 이유는, ApplicationContext 에서 printer 라는 이름을 가진 빈을 찾아 주입해주기 때문이다.

---

✅ 왜 Bean 을 등록하지 않고 BeanDefinition 을 등록할까?

스프링 부트의 본질은 Bean 이라는 생각을 했다. 그렇기에 앞서 이야기했던 것처럼 왜 굳이 #registerBean 을 사용하지 않고, #registerBeanDefinition 을 사용하는지에 대한 의문이 들었다.

 

그러나 실제로 공부를 하다 보니, 컴포넌트 스캔이 이뤄질 때 사실상 등록되는 것은 Bean 이 아니라 BeanDefinition 이라는 것을 알게 됐다. 

 

🙋 내가 생각했던 스프링부트의 컴포넌트 스캔 과정

 

1. @Bean 이 붙은 클래스들을 모두 스캔
2. 해당 클래스의 인스턴스들을 모두 생성해서 ApplicationContext 에 등록

☀️ 실제 컴포넌트 스캔 과정

1. 컴포넌트 스캔 시작
2. @Component 관련 어노테이션이 붙은 클래스들에 대한 BeanDefinition 을 만들어서 BeanDefinitionRegistry 에 등록
3. 컨테이너가 초기화 될 때 적절한 시점에 따라 빈을 생성한다

그렇기에 ApplicationContext 에 registerBeanDefinition 을 하는 것은 오히려 더 맞는 수순인 것이다.

---

✅ 왜 정의를 등록하고 바로 생성은 하지 않는 것일까?

스프링에서 다루는 빈은 우리가 POJO 에서 생성하는 객체의 인스턴스와는 다르다. 스프링에서의 빈은 많은 부가적 기능을 수행해야 한다. 또한 이를 위해서는 스프링 컨테이너가 객체의 생성 시점이나 과정을 제어해야 한다.

 

1. 지연 생성을 통해 메모리와 리소스를 절약한다.

바로 빈으로 모두 만들게 되면 메모리와 리소스가 낭비될 수도 있다. 스프링 부트에는 '지연 생성'이 존재한다.

이를 통해 해당 빈을 실제로 호출할 때까지 인스턴스화하는 시점을 미룰 수 있다. 따라서 스프링에서는 정의만 등록해두고 생성 시점은 따로 관리하도록 하는 것이다.

 

2. 의존성 그래프를 관리하기 위해

스프링에서는 순환 참조를 방지할 수 있게 해준다. 이가 가능한 이유는, 빈의 정의를 먼저 쭉 탐색하며 스프링 컨테이너가 의존성을 파악해 순환 참조가 존재하는지 확인해주기 때문이다.

모든 정의를 확보한 뒤에야 인스턴스 생성을 하기 때문에 생성 시점에 대한 문제를 방지할 수 있다.

 

3. 프록시 구조를 위해

스프링에서는 프록시 구조를 사용한다. 예를 들어, @Configuration 이 붙은 클래스의 경우 Bean 을 등록할 수 있다. 이 때, 단순히 POJO 로만 해당 클래스를 관리하게 되면 Bean 으로 등록되는 특정 클래스의 인스턴스가 여러개가 될 수도 있다.

 

그러나 해당 @Configuration 이 붙은 클래스를 프록시로 관리함으로서 모든 인스턴스들을 싱글턴으로 관리할 수 있게 된다.

인스턴스를 생성하는 과정에서 빈을 변형해 조작할 수 있어야 하기에, 즉 객체의 인스턴스화를 할 권리가 온전히 스프링 컨테이너에게 있어야 하기에 정의를 먼저 등록하게 되는 것이다.

---

✅ #registerBean 메서드는 왜 존재하는걸까?

그렇다면 ApplicationContext 에 registerBean 메서드가 왜 존재하는지에 대한 의문이 들 것이다.

그러나 사실 registerBean 메서드를 실제로 확인해보면, 내부적으로는 BeanDefinition을 등록하고 있다는 것을 확인할 수 있다.

private <T> void doRegisterBean(Class<T> beanClass, @Nullable String name,
    @Nullable Class<? extends Annotation>[] qualifiers, @Nullable Supplier<T> supplier,
    @Nullable BeanDefinitionCustomizer[] customizers) {

    AnnotatedGenericBeanDefinition abd = new AnnotatedGenericBeanDefinition(beanClass);
    if (this.conditionEvaluator.shouldSkip(abd.getMetadata())) {
        return;
    }

	//.. 생략

   // BeanDefinition 을 등록
	BeanDefinitionReaderUtils.registerBeanDefinition(definitionHolder, this.registry);
}

 

즉 이는 단순히 Bean 으로 인식하고 있는 개발자에게 편의성을 제공하기 위한 메서드에 지나지 않는 것이다.

---

✅ 우리는 BeanDefinition 을 언제 사용할까?

실제로 스프링부트 개발을 하면서 BeanDefinition 을 직접적으로 다룰 일은 거의 없었다. 왜냐하면 이제까지 모든 빈들은 대부분 컴포넌트 스캔에 의해 처리할 수 있었기에 내부적으로는 BeanDefinition 을 다루고 있을지 몰라도, 직접 사용할 일은 없었기 때문이다.

 

그러나 이는 빈 구성과 주입 대상이 사전에 고정되어 있는 경우에만 해당된다. 외부 조건에 의해 런타임에 만약 어떤 빈을 주입할지 모른다면 어떻게 해야 할까?

 

예를 들어, json 파일을 읽고 경우에 따라 특정 빈을 주입해야 한다고 가정해보자.

{
  "usePaymentService": true,
  "useNotificationService": false
}

if (config.isUsePaymentService()) {
    RootBeanDefinition bd = new RootBeanDefinition(PaymentService.class);
    registry.registerBeanDefinition("paymentService", bd);
}
if (config.isUseNotificationService()) {
    RootBeanDefinition bd = new RootBeanDefinition(NotificationService.class);
    registry.registerBeanDefinition("notificationService", bd);
}

 

만약 위와 같이 주입해야 하는 빈이 고정되어 있지 않고, 외부 조건에 따라 주입해야 하는 빈을 런타임에만 인식할 수 있다면 개발자가 직접 BeanDefinition 을 정의해 등록해줘야 한다.

---

✅ BeanDefinition 은 언제 Bean 이 될까?

정의로만 남아있었는데, 언제 인스턴스화가 되어 실제 빈이 되는 걸까? 이는 크게 두 가지가 존재한다.

 

1. ApplicationContext 가 refresh 되는 경우

ApplicationContext 가 refresh 되는 경우에는 의존성 주입과 인스턴스화가 일어난다. 컴포넌트 스캔이 이뤄지고 나면 내부적으로 바로 refresh 가 되기 때문에 우리는 Bean 이 인스턴스화 되어 있는 채로 마주하게 된다.

 

2. 실제 빈이 호출되는 경우 (#getBean)

Bean이 지연 초기화 대상인 경우, 또는 런타임에 어떤 빈이 주입될지가 결정되는 경우에는 refresh() 이후에 BeanDefinition이 등록되기도 한다. 이런 경우, 명시적으로 refresh()를 호출하거나, 실제로 빈을 요청하는 시점에서야 인스턴스화가 이루어진다.