지난 포스트에서 예고한 대로 컨테이너가 빈을 생성하는 과정에 대해서 살펴보겠습니다.
1. 컨테이너 생성
SpringApplication.run()
위의 코드가 실행되면 내부적으로 ApplicationContext가 만들어집니다. 이는, bean 생성을 위한 초기 상태입니다.
2. 어떤 클래스를 빈으로 만들지 찾기
다음은 후보 찾기 입니다.
컨테이터는 바로 객체가 만드는게 아니라 설계도(BeanDefinition) 를 먼저 작성합니다.
후보 등록되는 경로들은 아래와 같습니다.
@ComponentScan으로 찾는 것들
@Component, @Service, @Repository, @Controller 등
@Configuration 안의 @Bean 메서드
스프링부트의 @EnableAutoConfiguration(자동 구성)으로 들어오는 수많은 빈들
--> 이 과정을 거치고 BeanDefinition Registry에 목록이 채워집니다.
3. 빈 후처리기 준비
빈 생성 전후에 개입하는 일종의 플러그인입니다.
BeanFactoryPostProcessor (빈 생성 전)
- BeanDefinition 자체를 수정할 수 있다.
- 예 : @ConfigurationProperties 바인딩 준비, 플레이스홀더 치환 등
BeanPostProcessor (빈 생성 후)
- 실제 빈 인스턴스를 만든 뒤, “가공/감싸기” 가능
- 예 : AOP 프록시 생성, @Autowired 처리 등
4. 실제로 빈 만들기
이제 컨테이너가 빈을 만듭니다. 이때 생성자 호출(주입)이 일어납니다.
5. 의존성 주입
@Autowired, @Value, 세터 주입 등 필드/세터 기반 주입이 일어납니다.
6. 라이프사이클 콜백 호출
- Aware 계열 (예: BeanNameAware, ApplicationContextAware)
- @PostConstruct
- InitializingBean.afterPropertiesSet()
- initMethod (@Bean(initMethod="..."))
7. BeanPostProcessor 개입 (AOP 프록시 포함)
- @Transactional, @Async 같은 애들이 프록시 빈으로 바뀐다.
- 즉, “감싼 객체(프록시)”가 최종 빈이 될 수 있음.
8. 싱글톤이면 캐시에 보관 (Singleton Registry)
기본 스코프는 singleton이기 때문에, 만들어진 빈은 컨테이너 내부 캐시에 저장되고 그 후엔 재사용됩니다.
'Spring' 카테고리의 다른 글
| [Spring] Spring WebFlux와 Spring MVC - 1 (0) | 2026.02.11 |
|---|---|
| [Spring] controller에서 repository를 참조하는 코드를 짜면? (0) | 2026.02.02 |
| [Spring] 필터와 인터셉터 (0) | 2026.01.31 |
| [Spring] IoC, DI (0) | 2026.01.28 |
| [Spring/JPA] @Transactional을 활용한 엔티티 수정 방식 비교 (0) | 2026.01.19 |