AOP와 Dynamic Proxy — @Transactional·@Cacheable의 비밀

메서드 위에 @Transactional을 붙이면, 그 메서드가 실행되기 직전에 트랜잭션이 열리고, 정상 종료되면 커밋, 예외가 나면 롤백된다. 그런데 이상하다 — 내 메서드 본문엔 트랜잭션을 열고 닫는 코드가 한 줄도 없다. @Cacheable도 마찬가지다. 캐시를 확인하고 저장하는 코드는 어디에도 없는데 캐싱이 된다.

이 "없는데 동작하는" 비밀의 정체가 AOP와 그 구현 수단인 다이내믹 프록시다. 핵심 한 줄로 먼저 말하면 이렇다 — 스프링이 내 객체를, 그것을 감싼 대역(프록시)으로 몰래 바꿔치기해 두었다.

1. AOP — 흩어지는 공통 관심사를 한데 모으기

AOP(Aspect-Oriented Programming, 관점 지향 프로그래밍)는 거창해 보이지만, 푸는 문제는 아주 구체적이다. 트랜잭션·로깅·캐시·권한 검사 같은 부가 기능은 수많은 메서드에 똑같이 반복된다.

그럼 스프링은 이 "앞뒤로 두르기"를 기술적으로 어떻게 실현할까? 여기서 프록시가 등장한다.

2. 프록시 — 원본을 감싼 대역

프록시(proxy)는 "대리인"이다. 호출자와 원본 객체 사이에 끼어들어, 같은 인터페이스로 요청을 받은 뒤 앞뒤에 부가 동작을 끼우고 원본에게 넘긴다.

// 스프링이 대략 이런 프록시를 자동 생성한다 (개념 코드)
class OrderServiceProxy extends OrderService {
    OrderService target;         // 내 진짜 객체
    TransactionManager txManager;
 
    @Override
    public void pay() {
        txManager.begin();       // ← 부가 기능 (앞)
        try {
            target.pay();        // ← 내 실제 코드 호출
            txManager.commit();  // ← 부가 기능 (뒤: 성공 시 커밋)
        } catch (Exception e) {
            txManager.rollback();// ← 부가 기능 (뒤: 실패 시 롤백)
            throw e;
        }
    }
}

내 pay() 본문엔 트랜잭션 코드가 없는데도 동작하는 이유가 이제 보인다. 컨테이너에 등록된 건 내 원본이 아니라, 이렇게 감싼 프록시이기 때문이다. 다른 빈이 OrderService를 주입받으면 실제론 이 프록시를 받는다.

3. 프록시를 만드는 두 방식 — JDK vs CGLIB

스프링이 이 프록시 객체를 실제로 찍어내는 방법은 두 가지다. 대상이 인터페이스를 구현했느냐에 따라 갈린다.

4. 이 원리를 알면 피하는 함정 — 자기 호출

프록시 방식의 가장 유명한 함정이 하나 있다. 같은 클래스 안에서 자기 메서드를 호출하면 AOP가 안 걸린다.

@Service
class OrderService {
    public void process() {
        this.pay();   // ← @Transactional이 안 걸린다!
    }
 
    @Transactional
    public void pay() { ... }
}

정리하면, @Transactional·@Cacheable의 "마법"은 마법이 아니라 프록시로 원본을 감싸 앞뒤에 부가 동작을 끼우는 기법이다. 컨테이너에서 꺼낸 빈이 내가 만든 클래스가 아니라 프록시라는 사실 하나만 붙잡으면, 자기 호출 함정도, final 함정도 전부 같은 원리에서 설명된다.

한 장 요약