스프링은 왜 프록시로 감싸고, 왜 자기 호출엔 안 먹을까?

스프링의 핵심은 제어의 역전(IoC)이에요. 객체 생성과 의존 관계 연결을 개발자가 new로 하지 않고 컨테이너에 맡깁니다. 그 컨테이너의 두 얼굴이 BeanFactory와 ApplicationContext예요.

빈은 생성 → 의존성 주입 → 초기화 콜백 → 사용 → 소멸 콜백의 순서로 살아요. 초기화·소멸 시점에 끼어드는 콜백이 세 가지 방식으로 제공돼요.

스코프는 빈이 몇 개 존재하고 얼마나 사는지를 정해요.

@Component  // singleton
class OrderService {
    private final ObjectProvider<PriceCalculator> calculatorProvider; // prototype

    OrderService(ObjectProvider<PriceCalculator> p) { this.calculatorProvider = p; }

    void handle() {
        PriceCalculator calc = calculatorProvider.getObject(); // 호출마다 새 prototype
        calc.calculate();
    }
}

@Transactional·@Cacheable·@Async 같은 기능은 마법이 아니라 프록시예요. 스프링은 대상 빈을 대신하는 프록시 객체를 만들어 컨테이너에 등록하고, 실제 호출 전후에 부가 로직(트랜잭션 시작/커밋 등)을 끼워 넣습니다.

@Service
class ReportService {

    public void run() {
        generate();   // ⚠️ this.generate() 와 같음 → 프록시 안 거침
    }

    @Transactional        // 자기 호출로 들어오면 트랜잭션이 시작되지 않는다!
    public void generate() { /* DB 작업 */ }
}
// run()을 외부에서 호출해도, 내부의 generate()에는 @Transactional 미적용

전파(propagation)는 "이미 트랜잭션이 진행 중일 때 새 트랜잭션 경계를 어떻게 처리할지"를 정해요.

흔한 실수: 트랜잭션 안에서 결제 저장 직후 알림 메일·외부 API를 바로 호출하는 것. 만약 그 뒤에 트랜잭션이 롤백되면, DB는 되돌아갔는데 메일은 이미 나가버려요. "커밋이 확정된 다음"에 실행할 방법이 필요합니다.

이 저수준 API를 선언적으로 감싼 게 @TransactionalEventListener예요. 이벤트를 발행해두면 지정한 트랜잭션 단계에서 리스너가 실행돼요.

// 1) 트랜잭션 안에서 이벤트만 발행
@Transactional
public void placeOrder(Order o) {
    orderRepository.save(o);
    eventPublisher.publishEvent(new OrderPlacedEvent(o.getId()));
}

// 2) 커밋이 성공적으로 끝난 뒤에만 실행 (롤백되면 실행 안 됨)
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void onOrderPlaced(OrderPlacedEvent e) {
    mailService.sendConfirmation(e.getOrderId()); // 안전: 커밋 확정 후
}