해결 방안: 구조 설계 변경을 통한 프록시 외부 노출 유도
상위 맥락
04. AOP 한계와 설계 주의 < 01. AOP와 빈 관리 원리 < 01. Spring MVC1 기초와 아키텍처 < MVC < Spring < Web
핵심 정리
Spring AOP의 내부 호출 문제를 해결하는 가장 근본적인 방법은 호출 구조를 바꾸는 것입니다. AOP가 적용되어야 하는 메서드를 같은 클래스 내부에 두지 않고, 별도의 스프링 빈으로 분리하여 외부 호출이 발생하도록 설계해야 합니다.
구조 변경의 원리
문제는 프록시를 통과하지 않는 내부 호출입니다. 따라서 해결의 핵심은 “반드시 프록시를 통과하게 만드는 것”입니다.
구조는 다음과 같이 바꿉니다.
- AOP가 필요한 메서드를 별도의 클래스로 분리합니다.
- 그 클래스를 @Service, @Component 등으로 스프링 빈으로 등록합니다.
- 기존 클래스에서 해당 빈을 의존성 주입으로 받아 사용합니다.
- 기존 클래스가 외부 빈의 메서드를 호출하게 합니다.
이렇게 하면 this.method()가 아니라 otherBean.method() 호출이 되고, 스프링 컨테이너가 제공한 프록시를 통과할 수 있습니다.
MVC 구조에서의 의미
@Controller는 웹 요청의 분석, 파라미터 바인딩, Model 저장, View 또는 데이터 반환에 집중합니다. 핵심 연산, 캐싱, 비동기, 트랜잭션이 필요한 로직은 Service 빈으로 분리합니다. 이 구조는 MVC 계층 분리와 AOP의 프록시 원리를 동시에 만족합니다.
즉, 구조 분리는 단순히 프레임워크의 한계를 피하기 위한 우회책이 아닙니다. 컨트롤러의 비대화를 막고, 서비스 계층의 책임을 명확하게 하며, 스프링이 제공하는 AOP 기능이 정상적으로 동작하도록 만드는 설계 원칙입니다.
주의할 점
같은 클래스 안에서 public 메서드로만 분리해도 내부 호출이면 여전히 AOP가 적용되지 않습니다. 메서드 접근 제한자만 바꾸는 것이 아니라, 호출 대상이 다른 스프링 빈으로 분리되어야 합니다.
한 문장 요약
AOP가 필요한 로직은 별도의 스프링 빈으로 분리하고 DI를 통해 호출하게 만들어, 호출 흐름이 프록시 외부에서 들어오도록 설계해야 합니다.