스프링부트가 @EnableConfigurationProperties를 사용하는 이유

사실 강의에서 구현한 @EnableMyConfigurationProperties와 스프링 부트의 @EnableConfigurationProperties는 내부 구현이 다릅니다. 스프링 부트는 ImportBeanDefinitionRegistrar라는 상당히 로우레벨의 복잡한 코드를 사용해서 프로퍼티 빈을 만들고, 강의 예제에서는 이를 보다 단순한 방식인 DeferredImportSelector를 사용했습니다. 예제 코드가 너무 난이도가 올라가지 않도록 가능한 단순한 구현 방법을 선택한 것입니다.

여기서 중요한 건 자동 구성 클래스에서 이와 연결되는 프로퍼티 정보를 담은 빈을 선언하는 방식으로 동작한다는 것입니다. 그래서 자동 구성을 하나 분석할 때, 여기에서 사용되어지는 프로퍼티 클래스를 살펴보는 것이 필요하다는 설명을 하려고 했습니다.

스프링에서 @Enable로 시작하는 애노테이션은 거의 모두 내부에 @Import를 메타 애노테이션을 가지는 방식으로 정의되어있습니다. 결국 @Import를 사용한 것과 같은 결과인데 뭐하러 애노테이션을 하나 더 선언을 해서 사용했는가라는 의문을 가질 수 있습니다. 이게 스프링 3.1 시절부터 확장을 위한 애노테이션을 정의하는 관례인데요. 제가 추측하는 이유는 @Import보다는 @Enable이 붙은 애노테이션을 사용하는 것이 빈 구성정보의 사용 의도를 잘 표현할 수 있기 때문입니다. 그리고 단순히 @Configuration 클래스를 가져오기만하는 @Import에 비해서 추가로 애노테이션 엘리먼트를 선언하거나 @Enable 클래스 내부에 다른 설정을 넣을 수도 있어서 활용하기에 더 유리합니다.

이런면에서 @Enable로 시작하는 다양한 애노테이션이 스프링과 스프링 부트에 정의되어있고 사용되어지고 있습니다. 그래서 개발자가 스프링이나 부트로 애플리케이션을 개발하는 경우 @Import를 직접 이용하는 일은 거의 없습니다. 애플리케이션 내부에서 정의한 구성정보는 @Configuration 클래스를 컴포넌트 스캐너로 한번에 가져오기 때문에 @Import할 필요가 없습니다. 그리고 재사용 가능하도록 정의한 자동 구성정보 내지는 설정에 따라 추가되도록 만든 구성정보는 @Enable로 시작하는 애노테이션을 거쳐서 @Import로 뒤에서 끌어오게 만드는 것이 스프링의 관례를 따르는 방식이라서 권장됩니다.