BeanPostProcessor — 애노테이션이 실제 동작으로 바뀌는 곳

스프링에서 @Autowired를 붙이면 의존성이 채워지고, @EventListener를 붙이면 이벤트를 받고, @Transactional을 붙이면 트랜잭션이 걸린다. 우리는 이 "붙이면 저절로"에 너무 익숙해서, 그게 누가 해 주는 일인지는 잘 생각하지 않는다.

답은 하나로 모인다: BeanPostProcessor. 빈이 만들어지는 파이프라인 중간에 끼어들어, 애노테이션을 읽고 실제 동작으로 바꿔 주는 확장 지점이다. 스프링의 "마법"이라 부르는 것들의 상당수가 여기서 벌어진다.

1. BeanPostProcessor란 무엇인가

이름을 그대로 풀면 "빈(Bean)을 후처리(PostProcess)하는 것"이다. 인터페이스 자체는 놀랄 만큼 단순하다. 메서드가 딱 두 개다.

public interface BeanPostProcessor {
    // 초기화(@PostConstruct 등) '전'에 각 빈마다 호출
    Object postProcessBeforeInitialization(Object bean, String beanName);
 
    // 초기화 '후'에 각 빈마다 호출
    Object postProcessAfterInitialization(Object bean, String beanName);
}

핵심은 이 두 메서드가 컨테이너가 만드는 모든 빈 하나하나에 대해 호출된다는 점이다. 그리고 결정적으로, 반환값이 다시 그 빈으로 쓰인다. 즉 후처리기는 빈을 들여다보기만 하는 게 아니라, 다른 객체로 바꿔치기할 수도 있다.

2. 파이프라인의 어디에 끼어드나

빈 생성 순서 위에 후처리기를 겹쳐 보면, 정확히 어느 틈에 개입하는지가 보인다.

여기서 재밌는 사실. @Autowired를 채우는 것도, @EventListener를 등록하는 것도 각각 별개의 후처리기가 한다. 스프링은 우리가 아는 애노테이션 기능들을 대부분 "내장 BeanPostProcessor"로 구현해 두었다.

3. 왜 이 구조로 만들었나

스프링이 굳이 이런 확장 지점을 둔 이유는, 애노테이션 기능을 컨테이너 본체에서 떼어내기 위해서다. 이게 왜 좋은지 세 가지로 정리된다.

4. @EventListener는 어떻게 붙나 (예시)

@EventListener를 예로 흐름을 구체화해 보자. 우리는 그저 메서드에 애노테이션을 붙였을 뿐인데, 그게 어떻게 "이벤트를 받는 리스너"가 되는가.

즉 @EventListener도 결국 "애노테이션을 스캔해 실제 등록 동작으로 바꿔 주는 후처리기" 덕에 동작한다. 앞서 본 @Autowired, @Transactional과 완전히 같은 패턴이다. 애노테이션이 마법처럼 보였던 건, 그 뒤에서 조용히 도는 후처리기를 못 봤기 때문일 뿐이다.

한 장 요약