Bean 생성 과정 — 설계도에서 완성된 객체까지

클래스에 @Component를 붙이고, 다른 곳에서 @Autowired로 받아 쓰면 끝. 스프링을 쓰면 이만큼 단순하다. 하지만 그 사이에서 컨테이너는 꽤 여러 단계를 거쳐 객체를 만들어 낸다. 이 글은 "빈 하나가 태어나 쓸 수 있는 상태가 되기까지" 의 흐름을 순서대로 연다.

이 과정을 알아 두면 좋은 이유가 있다. @Autowired가 왜 생성자에선 되는데 필드 초기화 시점엔 아직 null인지, @PostConstruct가 왜 그 타이밍에 불리는지, @Transactional을 붙인 빈이 왜 내가 만든 클래스가 아니라 프록시인지 — 전부 이 생성 순서에서 설명된다.

1. 설계도부터 모은다 — BeanDefinition

스프링은 객체를 만들기 전에, "무엇을 어떻게 만들지"의 설계도를 먼저 모은다. 이 설계도가 BeanDefinition이다. 실제 객체가 아니라, 객체를 만드는 데 필요한 메타데이터다.

2. 설계도대로 객체를 찍는다 — 인스턴스화

설계도가 모이면, 컨테이너는 싱글턴 빈들을 (ApplicationContext 기준) 부팅 시점에 실제로 생성하기 시작한다. 이때 먼저 일어나는 게 인스턴스화 — 곧 생성자 호출이다.

// 컨테이너가 사실상 이렇게 한다
Object bean = beanDefinition.getConstructor().newInstance(args);

여기서 중요한 순서 감각이 하나 생긴다. 생성자가 불리는 이 시점엔, 아직 필드 주입(@Autowired 필드)은 채워지지 않았다. 그래서 필드에 @Autowired로 받은 의존성을 생성자 본문에서 쓰면 null이다. 반면 생성자 파라미터로 받는 의존성은 이 시점에 이미 넘어와 있다 — 그래서 생성자 주입이 안전하다.

3. 빈 사이를 연결한다 — 의존성 주입

객체가 만들어졌으면, 이제 그 객체가 필요로 하는 다른 빈들을 채워 넣는다. 필드/세터 주입이 이 단계에서 처리된다. 컨테이너는 타입(또는 이름)으로 맞는 빈을 찾아 꽂는다.

이 "타입으로 맞는 빈을 찾아 꽂는" 일을 실제로 수행하는 건 컨테이너 자신이 아니라, @Autowired를 해석하는 후처리기다. 그 후처리기가 어떻게 동작하는지는 5단계에서 다시 나온다.

4. 쓸 준비를 마친다 — 초기화 콜백

의존성까지 다 채워졌으면, "이제 협력 객체가 다 준비됐으니 초기 세팅을 해라"는 신호를 줄 차례다. 이게 초기화 콜백이다.

순서 감각을 한 번 더 못 박자: 생성자 → 의존성 주입 → 초기화 콜백. @PostConstruct가 생성자보다 나중인 건 우연이 아니라, "의존성이 준비된 뒤"라는 계약을 지키기 위한 설계다.

5. 마지막에 손을 댄다 — 후처리(BeanPostProcessor)

초기화 앞뒤로, 컨테이너는 BeanPostProcessor라는 확장 지점에 빈을 한 번씩 통과시킨다. 이게 스프링 마법의 상당 부분이 벌어지는 곳이다.

// 개념적으로 컨테이너는 각 빈에 대해 이렇게 한다
bean = postProcessBeforeInitialization(bean);   // 초기화 전
invokeInitMethods(bean);                        // @PostConstruct 등
bean = postProcessAfterInitialization(bean);    // 초기화 후 ← 프록시 교체 지점

@Autowired를 해석해 값을 꽂는 것도, @PostConstruct를 찾아 호출하는 것도 실은 각각의 BeanPostProcessor가 하는 일이다. 즉 후처리기는 생성 과정 곳곳에 끼어들어 "애노테이션을 실제 동작으로 바꾸는" 일꾼이다. 자세한 건 BeanPostProcessor 글로 이어진다.

6. 전체 순서 한눈에

정리하면, @Component 하나 뒤에는 설계도 → 생성 → 주입 → 초기화 → 후처리라는 정해진 파이프라인이 돌고 있다. 이 순서를 손에 쥐고 있으면, 스프링에서 마주치는 타이밍 관련 버그의 절반은 "아, 이 시점엔 아직 그게 준비 안 됐구나"로 스스로 풀린다.

한 장 요약