우당탕탕 개발_𝒍𝒐𝒈

<DI 컨테이너> @ComponentScan과 @Configuration은 반드시 함께 명시해야하는 걸까? 본문

대외 활동/데브코스

<DI 컨테이너> @ComponentScan과 @Configuration은 반드시 함께 명시해야하는 걸까?

hojeong01 2024. 8. 10. 00:08

spring 과정이 시작되었다. 

지금까지는 Gradle을 사용하여 프로젝트를 진행하였고 그러다 막히는 부분이 있으면 그때그때 구글링을 통해 코드를 짜며 스프링에 대해 가볍게 공부를 했다. 

그래서 스프링의 기본 동작 원리에 대해 깊게 고민을 해 본적이 없었는데 이번 수업을 통해 그동안 놓치고 있던 부분들에 대한 궁금증이 생기기 시작했다.

 

특히, 아무런 생각없이 클래스에 어노테이션을 달고 라이브러리를 적용시켜 왔던 과정에 대해 하나하나 '이것을 왜 여기에 사용했지?"라는 의문이 들기 시작했다.

그래서 오늘은 

수많은 의문들 중 Spring Security를 적용할 때 사용했던 @ComponentScan 과 @Configuration에 대해 파헤쳐보려 한다.


1. Bean의 생성과 관리

나의 의문을 완전히 이해하기 위해서는 DI 컨테이너에 Bean을 등록하는 과정들에 대한 이해가 첫 번째라고 생각하였다. 

 우선 위 그림은 메이븐의 의존 그래프이다  BeanFactrory과 관계를 가진 더 많은 interface들이 있지만 우선 생략하고 핵심적인 클래스들만 남겼다. 

 

위 그래프를 토대로 스프링 컨테이너가 Bean을 등록하는 과정을 간단히 살펴보자!

1.Bean 정의

자바 설정 클래스 = Annotation Config Application Context 

XML 설정 클래스 = Generic Xml Application Context 

그루비 스크립트 = Generic Groovy Application Context에서 각각 빈을 정의한다. 

 

2. ComponantScan 진행

위에서 정의된 Bean은 스프링부트애플리케이션이 실행됨과 동시에 ComponantScan에 의해 자동 스캔되어 DI컨테이너에 의해 해석되어 객체의 생성, 검색, 초기화등의 기능이 수행된다.

-> 이때 ComponantScan의 스탠대상은 @Service , @repository 등의  역할을 명시하는 어노테이션이 붙은 클래스와 사용자가 직접 Bean을 등록한 @Configuration 클래스이다. 

 

3.DI 컨테이너에서의 Bean관리   

ComponantScan을 통해 등록된 Bean들은 DI컨테이너에 의해 관리된다. DI 컨테이너는 애플리케이션이 실행되는 동안 Bean을 생성, 초기화 주입하며 애플리케이션이 필요로 하는 의존성을 자동으로 연결한다. 


나의 오해

 @Configuration / 사용자가 설정한 클래스임으로 ComponantScan이 못 읽을 수 있어 @Configuration 어노테이션을 가진 클래스는 반드시 함께  @ComponantScan을 사용해야 한다.라고 생각했는데... 내가 적은 Spring Security클래스를 보면...  @Configuration 만 적혀있고 정상적으로 작동되는 것을 확인했다...

분명 같이 사용해야 하는 거 아니었어..? 

 

 

그렇다 @Configuration 클래스에서 @ComponantScan이 함께 할까 말까의 조건은 @Configuration 클래스가 @SpringBootApplication 같은 또는 하위 패키지로 연결되어 있는가?로 볼 수 있다. 

 

그래서 내 프로젝트에서 @SpringBootApplication이 어디에 위치되어 있는지 찾아보았다.. 왜냐면 난 이 어노테이션을 작성한 기억이 없다!

 

timebean 패키지 가장 하단에 위치한 클래스...

처음부터 만들어져 있길래 사실 부끄럽지만 신경 쓰지 않았던 클래스... 

그런데 혹시.. 하는 마음으로 들어가 보니 

 

찾아버렸다,..  @SpringBootApplication을..

그렇다 나는 Spring Boot Starter을 사용하여 프로젝트를 생성했기에 너무 친절하게도  @SpringBootApplication이 붙은 클래스를 나 대신 만들어 준 것이다!

 

원래는  @SpringBootApplication이 붙은 클래스를 직접 작성하여 애플리케이션의 진입점을 정의할 수 있다. 

 

 @SpringBootApplication은 @configuration의 어노테이션을 포함하고 있어 @configuration가 명시되어있지 않아도 같은  하위 클래스의 bean을 스캔해준다고 한다. 

따라서 

Spring Security클래스와 @SpringBootApplication을 가진 TimebeanApplication클래스가 동일 패키지에 위치해 있었기 때문에 Spring Security클래스에  @Configuration어노테이션만 명시했어도 스캔의 대상이 되었던 것이었다!!

 

누군가에겐 사소한 고민이었겠지만 

평소에 인지하고 있지 않았던 부분이었기에 공부를 할 때 상당히 흥미로웠다!

덕분에 Bean이 어떻게 생성되고 의존성이 어떤 방식으로 주입되는지에 대한 기본적인 동작방법을 알 수 있었다. 

 

앞으로도 사소하지만 중요한 개념들을 잘 찾아보자!!

 

'대외 활동 > 데브코스' 카테고리의 다른 글

kotlin) 표준함수 이론 정리와 고민에 대한 생각의 과정  (5) 2024.10.16
singleton 패턴  (0) 2024.07.20
static에 대해서  (0) 2024.07.20
JVM 실행 과정/구성 요소  (1) 2024.07.17
프로세스와 스레드  (0) 2024.07.16