스프링은 프록시 방식의 AOP를 사용한다. 따라서 AOP를 적용하려면 항상 프록시를 통해서 대상 객체를 호출해야 한다. 이렇게 해야 프록시에서 어드바이스를 호출하고, 이후에 대상 객체를 호출한다. 만약, 프록시를 거치지 않고 대상 객체를 직접 호출하게 되면 AOP가 적용되지 않고, 어드바이스도 호출되지 않는다.
AOP를 적용하면 스프링은 대상 객체 대신에 프록시를 스프링 빈으로 등록한다. 따라서 스프링은 의존관계 주입시에 항상 프록시 객체를 주입한다. 프록시 객체가 주입되기 때문에 대상 객체를 직접 호출하는 문제는 일반적으로 발생하지 않는다. 하지만 대상 객체의 내부에서 메서드 호출이 발생하면 프록시를 거치지 않고 대상 객체를 직접 호출하는 문제가 발생한다. 실무에서 반드시 한번은 만나서 고생하는 문제이기 때문에 꼭 이해하고 넘어가자.
예제를 통해서 내부 호출이 발생할 때 어떤 문제가 발생하는지 알아보자.
CallServiceV0
package cwchoiit.springadvanced.aop.internalcall;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;
@Slf4j
@Component
public class CallServiceV0 {
public void external() {
log.info("external");
internal();
}
public void internal() {
log.info("internal");
}
}
CallServiceV0.external()을 호출하면 내부에서 internal() 이라는 자기 자신의 메서드를 호출한다. 자바 언어에서 메서드를 호출할 때 대상을 지정하지 않으면 앞에 자기 자신의 인스턴스를 뜻하는 this가 붙게 된다. 그러니까 여기서는 this.internal() 이라고 이해하면 된다.
InternalAspect
package cwchoiit.springadvanced.aop.internalcall.aop;
import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
@Slf4j
@Aspect
public class InternalAspect {
@Before("execution(* cwchoiit.springadvanced.aop.internalcall..*.*(..))")
public void before(JoinPoint joinPoint) {
log.info("[Before] {}", joinPoint.getSignature());
}
}
CallServiceV0에 AOP를 적용하기 위해서 간단한 @Aspect를 하나 만들자.
이렇게 하면, CallServiceV0의 external(), internal() 모두 AOP 적용 대상이 된다.
@Import(InternalAspect.class)를 사용해서 앞서 만든 @Aspect를 스프링 빈으로 등록한다. 이렇게 해서 CallServiceV0에 AOP 프록시를 적용한다.
먼저, callServiceV0.external()을 실행해보자. 이 부분이 중요하다.
실행 결과 - external()
target = class cwchoiit.springadvanced.aop.internalcall.CallServiceV0$$SpringCGLIB$$0
[Before] void cwchoiit.springadvanced.aop.internalcall.CallServiceV0.external()
external
internal
실행 결과를 보면, callServiceV0.external()을 실행할 때는 프록시를 호출한다. 따라서 InternalAspect 어드바이스가 호출된 것을 확인할 수 있다.
그리고 AOP Proxy는 target.external()을 호출한다.
그런데 여기서 문제는, callServiceV0.external() 안에서 internal()을 호출할 때 발생한다. 이때는 실행 결과를 보면 알 수 있듯 어드바이스가 호출되지 않는다!
자바 언어에서 메서드 앞에 별도의 참조가 없으면 this 라는 뜻으로 자기 자신의 인스턴스를 가리킨다. 결과적으로 자기 자신의 내부 메서드를 호출하는 this.internal()이 되는데, 여기서 this는 실제 대상 객체(target)의 인스턴스를 뜻한다. 결과적으로 이러한 내부 호출은 프록시를 거치지 않는다. 따라서 어드바이스도 적용할 수 없다. 아래 그림을 보면 좀 더 이해가 될 것이다.
이번에는 외부에서 internal()을 호출하는 테스트를 실행해보자.
실행 결과 - internal()
target = class cwchoiit.springadvanced.aop.internalcall.CallServiceV0$$SpringCGLIB$$0
[Before] void cwchoiit.springadvanced.aop.internalcall.CallServiceV0.internal()
internal
외부에서 호출하는 경우, 프록시를 거치기 때문에 internal()도 InternalAspect 어드바이스가 적용된 것을 확인할 수 있다.
이런 문제를 프록시 내부 호출 문제라고 한다. 일단 이 문제가 왜 발생하는지 이해하는 게 가장 중요하다.
참고로, 실제 코드에 AOP를 직접 적용하는 AspectJ를 사용하면 이런 문제가 발생하지 않는다. 프록시를 통하는 것이 아니라 해당 코드에 직접 AOP 적용 코드를 바이트 조작으로 코드를 직접 아예 붙여버리기 때문에 내부 호출과 무관하게 AOP를 적용할 수 있다. 그러나 이 방법은 매우 복잡하고 JVM 옵션을 주어야 하는 부담이 있기 때문에 사용하지 않고 이 문제를 해결할 대안이 여럿 있기 때문에 그 대안을 알아보자.
프록시와 내부 호출 - 대안1 (자기 자신 주입)
결론부터 말하면 이 대안은 좋은 대안은 아니다. 그러나 방법 중 하나이긴 하다. 우선, 스프링 부트 2.6 이상부터는 순환 참조를 기본적으로 금지하도록 정책이 변경되었기 때문에 이 자기 자신을 주입하려면 다음과 같이 application.yaml 파일에 이 옵션을 추가해줘야 한다.
spring:
main:
allow-circular-references: true
CallServiceV1
package cwchoiit.springadvanced.aop.internalcall;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
@Slf4j
@Component
public class CallServiceV1 {
private CallServiceV1 callServiceV1;
@Autowired
public void setCallServiceV1(CallServiceV1 callServiceV1) {
this.callServiceV1 = callServiceV1;
}
public void external() {
log.info("external");
callServiceV1.internal();
}
public void internal() {
log.info("internal");
}
}
이 방법은 생성자 주입이 아니다. 생성자 주입은 아예 불가능하다. 왜냐하면? 내가 빈으로 만들어져야 생성자에 주입을 할텐데 나를 만들기 전에 생성자에 나를 주입한다? 닭이 먼저냐 달걀이 먼저냐의 문제가 되는 것이다.
그래서, 세터 주입을 사용하는데 세터 주입은 스프링이 띄워지고 빈으로 등록된 후에 주입이 가능하기 때문에 오류가 발생하지 않는다.
세터에 자기 자신을 주입하고 있는 모습을 확인할 수 있다. 여기서 주입 받는 것은 '프록시'다. external() 안에서 자기 자신을 호출하는 게 아니라 또 프록시의 internal()을 호출하기 때문에 문제를 해결할 수 있다.
실행 결과를 보면, 이제는 internal()을 호출할 때 자기 자신의 인스턴스를 호출하는 것이 아니라 프록시 인스턴스를 통해서 호출하는 것을 확인할 수 있다. 당연히 AOP도 잘 적용된다.
프록시와 내부 호출 - 대안2 (지연 조회)
CallServiceV2
package cwchoiit.springadvanced.aop.internalcall;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.stereotype.Component;
@Slf4j
@Component
@RequiredArgsConstructor
public class CallServiceV2 {
private final ApplicationContext applicationContext;
public void external() {
log.info("external");
CallServiceV2 callServiceV2 = applicationContext.getBean(CallServiceV2.class);
callServiceV2.internal();
}
public void internal() {
log.info("internal");
}
}
ApplicationContext를 직접 주입받고, 여기서 자기 자신의 빈을 꺼내는 것이다. 그럼 똑같이 프록시가 꺼내질 것이고 문제가 해결된다. 그런데 ApplicationContext이건 너무 거대하다. 그냥 스프링 하나가 있다고 보면 되는데 우리는 굳이 이렇게 큰 것을 가져올 필요가 없다.
그래서 다음과 같이 ObjectProvider를 사용해보자.
CallServiceV2
package cwchoiit.springadvanced.aop.internalcall;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Component;
@Slf4j
@Component
@RequiredArgsConstructor
public class CallServiceV2 {
private final ObjectProvider<CallServiceV2> callServiceV2Provider;
public void external() {
log.info("external");
CallServiceV2 callServiceV2 = callServiceV2Provider.getObject();
callServiceV2.internal();
}
public void internal() {
log.info("internal");
}
}
이렇게 ObjectProvider를 사용하면 된다. 딱 원하는 빈 하나만을 가져올 수 있도록 말이다.
이렇게 딱 필요한 시점에 필요한 빈을 가져오니까 조회를 늦게 한다고 해서 지연 조회라고 한다.
프록시와 내부 호출 - 대안3 (구조 변경) ⭐️
앞선 방법들은 자기 자신을 호출하거나 또는 Provider를 사용해야 하는것처럼 조금 어색한 모습을 만들었다. 가장 나은 대안은 내부 호출이 발생하지 않도록 구조를 변경하는 것이다. 실제 이 방법을 가장 권장한다.
CallServiceV3
package cwchoiit.springadvanced.aop.internalcall;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Component;
@Slf4j
@Component
@RequiredArgsConstructor
public class CallServiceV3 {
private final CallServiceInternal internalCallService;
public void external() {
log.info("external");
internalCallService.internal();
}
}
CallServiceInternal
package cwchoiit.springadvanced.aop.internalcall;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;
@Slf4j
@Component
public class CallServiceInternal {
public void internal() {
log.info("internal");
}
}
구조를 변경한다는 게 별게 아니라 그냥 internal() 메서드를 따로 빼버리고 별도의 클래스로 만들고 이 클래스를 주입받아 사용하면 된다.
내부 호출 자체가 사라지고, callService → internalService를 호출하는 구조로 변경되었다. 덕분에 자연스럽게 AOP가 적용된다.
참고로, AOP는 주로 트랜잭션 적용이나 주요 컴포넌트의 로그 출력 기능에 사용된다. 쉽게 이야기해서 인터페이스에 메서드가 나올 정도의 규모에 AOP를 적용하는 것이 적당하다. 더 풀어서 이야기하면, AOP는 public 메서드에만 적용한다. private 메서드처럼 작은 단위에는 적용하지 않는다. 적용할 수도 없다. AOP 적용을 위해 private 메서드를 외부 클래스로 변경하고 public으로 변경하는 일은 거의 없다. 그러나 위 예제와 같이 public 메서드에서 public 메서드를 내부 호출하는 경우에는 문제가 발생한다. AOP가 잘 적용되지 않으면 내부 호출을 의심해보자.
프록시 기술과 한계 - 타입 캐스팅
JDK 동적 프록시와 CGLIB를 사용해서 AOP 프록시를 만드는 방법에는 각각 장단점이 있다. JDK 동적 프록시는 인터페이스가 필수이고, 인터페이스를 기반으로 프록시를 생성한다. CGLIB는 구체 클래스를 기반으로 프록시를 생성한다.
물론, 인터페이스가 없고 구체 클래스만 있는 경우에는 CGLIB를 사용해야 한다. 그런데 인터페이스가 있는 경우에는 둘 중 하나를 선택해서 프록시를 만들 수 있다.
proxyTargetClass=false → JDK 동적 프록시를 사용해서 인터페이스 기반 프록시 생성
proxyTargetClass=true → CGLIB를 사용해서 구체 클래스 기반 프록시 생성
참고로, 옵션과 무관하게 인터페이스가 없으면 무조건 CGLIB를 사용한다.
JDK 동적 프록시 한계
인터페이스를 기반으로 프록시를 생성하는 JDK 동적 프록시는 구체 클래스로 타입 캐스팅이 불가능한 한계가 있다. 사실 생각해보면 당연하다.
테스트 코드를 보면, 인터페이스로는 캐스팅이 가능하고 구체 클래스로 캐스팅을 할 때 ClassCastException이 발생할 것으로 예측하고 있다.
실행 결과는 참이다.
JDK 동적 프록시는 인터페이스를 기반으로 프록시를 생성한다. 그래서 당연히 인터페이스로는 캐스팅이 가능하다. 그런데 인터페이스는 자기를 구현한 구현체에 대한 정보를 아무것도 모른다. 당연하다. 그러면 프록시가 구체 클래스로 캐스팅 할 수 있을까? 없다. 아무것도 모르는데 어떻게 캐스팅을 하겠는가? 따라서 당연히 캐스팅 에러가 발생한다.
위 그림만 봐도 바로 이해가 될 것이다. JDK 동적 프록시는 인터페이스만 알고 있다. 인터페이스 만으로는 구현 클래스에 대한 정보를 알 수 없다.
그리고 인터페이스와 구체클래스 둘 다 주입받아보자. (이럴 일은 거의 없고 인터페이스를 주입받아야 좋은 설계가 맞지만 일단 테스트를 위해 이렇게 해보자)
application.yaml
spring:
aop:
proxy-target-class: false
JDK 동적 프록시로 프록시를 생성하도록 옵션을 적용하자.
실행 결과
org.springframework.beans.factory.BeanNotOfRequiredTypeException:
Bean named 'memberServiceImpl' is expected to be of type 'cwchoiit.springadvanced.aop.member.MemberServiceImpl'
but was actually of type 'jdk.proxy3.$Proxy65'
이러한 타입 관련 에러가 발생한다. 왜냐? 위에서 설명한대로 JDK 동적 프록시는 구체 클래스에 대해 전혀 알 길이 없기 때문에 구체 클래스로 캐스팅이 불가능하기 때문이다.
반면, CGLIB로 프록시를 만들도록 옵션을 수정하고 실행해보자.
application.yaml
spring:
aop:
proxy-target-class: true
실행해보면 정상 동작하는 것을 알 수 있다. 마찬가지 이유로 CGLIB는 구체 클래스를 기반으로 프록시를 만들고 구체 클래스는 당연히 구체 클래스도 알고 있고 그 상위인 인터페이스도 알고 있기 때문에 어떤 것으로도 캐스팅이 가능하기 때문이다.
정리를 하자면
지금까지 JDK 동적 프록시가 가지는 한계점을 알아보았다. 실제로 개발할 때는 인터페이스가 있으면 인터페이스를 기반으로 의존관계 주입을 하는 게 맞다. DI 장점이 무엇인가? DI를 받는 클라이언트 코드의 변경 없이 구현 클래스를 변경할 수 있다는 것이다. 이렇게 하려면 인터페이스를 기반으로 의존관계 주입을 받아야 한다. MemberServiceImpl 타입으로 의존관계 주입을 받는것처럼 구현 클래스에 의존관계를 주입하면 향후 구현 클래스를 변경할 때 의존관계 주입을 받는 클라이언트 코드도 함께 변경해야 한다. 따라서 올바르게 잘 설계된 애플리케이션이라면 이런 문제가 자주 발생하지는 않는다. 그럼에도 불구하고 테스트, 또는 여러가지 이유로 AOP 프록시가 적용된 구체 클래스를 직접 의존관계 주입 받아야 하는 경우가 있을 수 있다. 이때는 CGLIB를 통해 구체 클래스 기반으로 AOP 프록시를 적용하면 된다.
여기까지 듣고보면 CGLIB를 사용하는 것이 좋아보인다. CGLIB를 사용하면 이런 고민 자체를 하지 않아도 되니까 말이다.
이번엔 CGLIB의 단점을 알아보자.
프록시 기술과 한계 - CGLIB
스프링에서 CGLIB는 구체 클래스를 상속 받아서 AOP 프록시를 생성한다. CGLIB는 구체 클래스를 상속받기 때문에 다음과 같은 문제가 있다.
CGLIB 구체 클래스 기반 프록시 문제점
대상 클래스에 기본 생성자 필수
생성자 2번 호출 문제
final 키워드 클래스, 메서드 사용 불가
대상 클래스에 기본 생성자 필수
CGLIB는 구체 클래스를 상속 받는다. 자바 언어에서 상속을 받으면 자식 클래스의 생성자를 호출할 때 자식 클래스의 생성자에서 부모 클래스의 생성자도 호출해야 한다. (이 부분이 생략되어 있다면 자식 클래스의 생성자 첫 줄에 부모 클래스의 기본 생성자를 호출하는 super()가 자동으로 들어간다) 이 부분은 자바 문법 규약이다. CGLIB를 사용할 때 CGLIB가 만드는 프록시의 생성자는 우리가 호출하는 것이 아니다. CGLIB 프록시는 대상 클래스를 상속 받고, 생성자에서 대상 클래스의 기본 생성자를 호출한다. 따라서 대상 클래스에 기본 생성자가 필수이다.
생성자 2번 호출 문제
CGLIB는 구체 클래스를 상속받는다. 자바 언어에서 상속을 받으면 자식 클래스의 생성자를 호출할 때 부모 클래스의 생성자도 호출해야 한다. 그런데 왜 2번일까?
실제 target 객체를 생성할 때
프록시 객체를 생성할 때 부모 클래스의 생성자 호출
그러니까, 프록시는 실제 객체가 반드시 있어야 한다. 그러러면 실제 객체를 만들어야 한다. 그때 생성자를 한번 호출한다.
프록시 객체를 생성할 때 CGLIB는 실제 객체를 상속받는다. 상속을 받을 때 부모 클래스의 생성자를 호출하는데 부모 클래스가 곧 실제 객체이므로 또 생성자를 호출한다.
final 키워드 클래스, 메서드 사용 불가
final 키워드가 클래스에 있으면 상속이 불가능하고, 메서드에 있으면 오버라이딩이 불가능하다. CGLIB는 상속을 기반으로 하기 때문에 두 경우 프록시가 생성되지 않거나 정상 동작하지 않는다. 그런데, 사실 이 부분은 크게 문제가 되지는 않는다. 거의 대부분 애플리케이션을 개발할 때 final 키워드를 붙인 클래스를 만들지 않기 때문에.
정리를 하자면
JDK 동적 프록시는 대상 클래스 타입으로 주입할 때 문제가 있고, CGLIB는 대상 클래스에 기본 생성자 필수, 생성자 2번 호출 문제가 있다. 그렇다면 스프링은 어떤 방법을 권장할까?
프록시 기술과 한계 - 스프링의 해결책
스프링은 AOP 프록시 생성을 편리하게 제공하기 위해 오랜 시간 고민하고 문제들을 해결해왔다.
스프링의 기술 선택 변화, 스프링 3.2, CGLIB를 스프링 내부에 함께 패키징
CGLIB를 사용하려면 CGLIB 라이브러리가 별도로 필요했다. 스프링은 CGLIB 라이브러리를 스프링 내부에 함께 패키징해서 별도의 라이브러리 추가 없이 CGLIB를 사용할 수 있게 되었다.
CGLIB 기본 생성자 필수 문제 해결
스프링 4.0부터 CGLIB의 기본 생성자가 필수인 문제가 해결되었다. objenesis 라는 특별한 라이브러리를 사용해서 기본 생성자 없이 객체 생성이 가능하다. 참고로 이 라이브러리는 생성자 호출 없이 객체를 생성할 수 있게 해준다.
생성자 2번 호출 문제 해결
스프링 4.0부터 CGLIB의 생성자 2번 호출 문제가 해결되었다. 이것도 역시 objenesis 라는 특별한 라이브러리 덕분에 가능해졌다. 이제 생성자가 1번만 호출된다.
스프링 부트 2.0 - CGLIB 기본 사용
스프링 부트 2.0 버전부터 CGLIB를 기본으로 사용하도록 했다. 이렇게 해서 구체 클래스 타입으로 의존관계를 주입하는 문제를 해결했다. 스프링 부트는 별도의 설정이 없다면 AOP를 적용할 때 기본적으로 proxyTargetClass=true로 설정해서 사용한다. 따라서 인터페이스가 있어도 JDK 동적 프록시를 사용하는 것이 아니라 항상 CGLIB를 사용해서 구체 클래스를 기반으로 프록시를 생성한다. 물론 스프링은 우리에게 선택권을 열어주기 때문에 다음과 같이 설정하면 JDK 동적 프록시도 사용할 수 있다.
이런 경우 이 TestContainer가 장점을 발휘할 수 있다. 혹자는 그냥 H2로 테스트할때만 하면 되는거 아닌가? 싶을수 있다. MySQL과 H2는 같은 데이터베이스가 아니다. 즉, 동일한 작업을 해도 둘 중 하나는 에러가 발생하는데 둘 중 하나는 발생하지 않을 수 있다. 그래서 정확한 테스트라고 할 수는 없다.
또 다른 혹자는 그럼 그냥 Mocking하면 되는거 아닌가? 싶을수 있다. 이 또한, 사실 Mocking은 데이터베이스 연동 테스트가 전혀 아니다. 비즈니스 로직의 결함을 찾는것에 더 가까운 테스트이지 데이터베이스까지 연동한 테스트는 전혀 아니다.
그리고 실제로 컨테이너를 생성해서 데이터베이스를 만들어야 하는데 나는 Redis를 사용해서 테스트해보기로 한다. 그래서 다음과 같이 필드 하나를 추가한다.
@Container
private static final GenericContainer<?> redisContainer =
new GenericContainer<>(DockerImageName.parse("redis:latest")).withExposedPorts(6379);
@Container 애노테이션을 붙여서 이 필드가 컨테이너가 될 것임을 알려준다.
가장 최근의 이미지인 "redis:latest"를 사용하고, Redis의 기본 포트인 6379를 Expose한다.
중요한 부분은 이 부분이다. 컨테이너를 띄울때 6379와 매핑되는 포트는 임의로 지정된다. 같은 6379:6379면 좋갰지만 그게 아니다. 그래서 컨테이너가 띄워진 후 6379와 매핑된 포트를 스프링 부트의 설정값 중 spring.data.redis.port에 지정해줘야 한다. 그래야 정상적으로 통신이 가능해질테니.
그래서, 동적으로 속성값을 설정할 수 있는 방법을 이렇게 @DynamicPropertySource 애노테이션으로 제공한다.
이 부분은 실제 테스트 코드다. 사실 이 부분은 별 게 없다. 나의 경우 getDeveloperByMemberId()는 Redis로 캐시할 수 있게 구현했다. 그래서 저 메서드를 두번 호출헀을 땐, 첫번째는 redis에 저장된 값이 없기 때문에 실제 데이터베이스에서 값을 가져올 것이고, 두번째 호출했을 땐, redis에 저장된 값이 있기 때문에 바로 캐싱이 가능해진다.
그리고, redis에 저장됐기 때문에, redisContainer.execInContainer("redis-cli", "get", "developer:xayah")를 호출하면 저장된 캐시의 value가 반환될 것이다.
그 반환된 값을 JSON으로 역직렬화를 하여 객체가 가진 값들을 비교한다.
어떻게 JSON으로 직렬화해서 저장이 바로 됐나요? → 이전 포스팅을 참고해야 한다. RedisConfig 클래스로 설정을 했다. 그리고 @SpringBootTest이므로 스프링 컨테이너가 온전히 띄워지기 때문에 설정값이 적용된 상태에서 이 테스트가 진행되는 것이다.
테스트 결과는 다음과 같이 성공이다.
참고. 컨테이너가 띄워지고 삭제되는 것을 확인
저 테스트가 실행되면, 컨테이너가 실제로 띄워진다. 그리고 테스트가 끝나면 컨테이너가 자동으로 삭제된다. 확인해보면 좋을것이다.
우선, 여러 방법으로 설정을 할 수 있는데, application.yaml 파일에서도 redis 설정을 할 수 있다. 근데 이렇게 하지 않을 것이다. 왜냐하면, 우선 첫번째 이유로는, redis가 로컬에 설치된 게 아니라 다른 외부에 있는게 아니라면 추가적인 설정이 필요가 없다.
두번째로는, 이후에 알아보겠지만 관련 설정을 이 외부 설정 파일 말고 자바 코드로 풀 것이다.
그래서, 자바 코드로 하나씩 풀어보자. 나는 일단, RedisConfig라는 클래스 하나를 만들것이다.
RedisConfig
package cwchoiit.dmaker.config.redis;
import org.springframework.cache.annotation.EnableCaching;
import org.springframework.context.annotation.Configuration;
@Configuration
@EnableCaching
public class RedisConfig {}
빈 껍데기의 클래스이다. 우선은 @Configuration, @EnableCaching 이 두개의 애노테이션만 있어도 충분하다.
이제 캐시를 적용할 것이다. 실제로 캐시가 적용되길 원하는 메서드에 다음과 같이 애노테이션을 붙여준다.
@Cacheable("developer")
public DeveloperDetailDTO getDeveloperByMemberId(@NonNull String memberId) {
log.info("[getDeveloperByMemberId] memberId = {}", memberId);
return developerRepository.findByMemberId(memberId)
.map(DeveloperDetailDTO::fromEntity)
.orElseThrow(() -> new DMakerException(NO_DEVELOPER));
}
@Cacheable() 애노테이션을 붙여준다. 그러면, 이 메서드가 호출되면 캐시된 값이 있으면 그 값을 가져오게 된다. 저기서 "developer"는 key를 의미한다.
이대로 끝나면 안된다. 왜냐하면, redis는 스프링 부트 외부에 있는 서비스이다. 그렇다는 것은 서비스와 서비스간 통신을 하려면 규약이 필요하다. 데이터가 전송될 때, 전송할 때 같은 포맷, 형식으로 데이터를 주고 받아야 한다. 그래서 가장 간단한 방법은 캐시하려는 데이터(여기서는 DeveloperDetailDTO가 된다) 객체가 Serializable을 구현하면 된다. 다음 코드처럼.
최초에는 캐시가 없기 때문에, 직접 데이터베이스에서 값을 가져오는 모습이 보인다. SELECT문이 실행됐다.
저 이후에 다시 한번 API를 날려보면, 다음과 같이 캐시데이터를 가져온다.
아예 서비스의 memberId를 보여주는 로그조차 찍히지 않았다. 즉, 캐시 데이터를 그대로 반환한 것이다.
그리고 실제로 redis-cli로 확인을 해보면 잘 저장되어 있다.
그럼 실제로 저 데이터가 어떻게 저장되어 있나 확인해보자.
우리가 알아볼 수 없는 유니코드로 보여진다. 직렬화를 하기 위해 Serializable을 구현했는데, 이게 자바 Serialization이기 때문에 사람이 알아보기가 힘들다. 그래서 사람이 알아보기 좋은 포맷이 뭘까? 바로 JSON이다. JSON으로 직렬화할 수 있겠지? 당연히 있다! 해보자!
JSON으로 직렬화 방법 바꾸기
이제 자바의 Serialization이 아닌 JSON 형태로 직렬화하기 위해 아까 빈 껍데기로 만들어 두었던 RedisConfig를 사용할 차례다.
given() 메서드는 `org.mockito.BDDMockito.given`에서 제공하는 메서드이고, 사전 조건을 정의할 수 있다. 이때 developerRepository가 가지고 있는 findByMemberId() 메서드가 어떤 값을 받을 때 반환하는 가짜 데이터를 임의로 생성할 수 있다. 저기서는 anyString() 이라는 `org.mockito.ArgumentMatchers.anyString`에서 제공하는 메서드를 사용해서 어떤 문자열이 들어와도 동일한 반환을 할 수 있게 정의했다.
findByMemberId는 반환값이 Optional이다. 그렇게 때문에 willReturn(Optional.of(...))을 사용한다.
이제 적절한 데이터를 만들어서 이 메서드가 호출되면 어떤 문자열이 들어와도 항상 코드에서 정의한 객체가 반환되도록 하였다.
@Test
void createDeveloper_fail() {
// DMakerService.createDeveloper()를 호출할 때 검증 단계에서 실행되는 findByMemberId()
given(developerRepository.findByMemberId(anyString()))
.willReturn(Optional.of(Developer.builder()
.developerLevel(SENIOR)
.developerType(BACK_END)
.experienceYears(15)
.name("Xayah")
.age(33)
.memberId("xayah")
.build()));
CreateDeveloperRequestDTO xayah = CreateDeveloperRequestDTO.builder()
.developerLevel(SENIOR)
.developerType(BACK_END)
.experienceYears(15)
.name("Xayah")
.age(33)
.memberId("xayah")
.build();
// 서비스 호출 시 중복 memberId로 Developer 생성 시, DMakerException 발생
assertThatThrownBy(() -> dMakerService.createDeveloper(xayah)).isInstanceOf(DMakerException.class);
}
한 라인씩 알아보자.
// DMakerService.createDeveloper()를 호출할 때 검증 단계에서 실행되는 findByMemberId()
given(developerRepository.findByMemberId(anyString()))
.willReturn(Optional.of(Developer.builder()
.developerLevel(SENIOR)
.developerType(BACK_END)
.experienceYears(15)
.name("Xayah")
.age(33)
.memberId("xayah")
.build()));
이번엔 DeveloperRepository.findByMemberId()의 Mocking을 우리가 생성하고자 하는 데이터와 동일하게 해서 반환하도록 설정한다.
CreateDeveloperRequestDTO xayah = CreateDeveloperRequestDTO.builder()
.developerLevel(SENIOR)
.developerType(BACK_END)
.experienceYears(15)
.name("Xayah")
.age(33)
.memberId("xayah")
.build();
// 서비스 호출 시 중복 memberId로 Developer 생성 시, DMakerException 발생
assertThatThrownBy(() -> dMakerService.createDeveloper(xayah)).isInstanceOf(DMakerException.class);
그리고 생성 테스트를 위해 서비스의 createDeveloper()를 호출하면, DMakerException 예외를 터트릴 것을 예상한다.
왜냐하면, 검증 단계에서 같은 memberId가 있는 경우 다음과 같이 예외를 터트린다.
Optional<Developer> findDeveloper = developerRepository.findByMemberId(createDeveloperRequestDTO.getMemberId());
if (findDeveloper.isPresent()) {
throw new DMakerException(DMakerErrorCode.DUPLICATE_MEMBER_ID);
}
컨트롤러 테스트
이번엔 아래와 같은 컨트롤러에 대한 테스트도 진행해보자.
DMakerController
package cwchoiit.dmaker.controller;
import cwchoiit.dmaker.dto.*;
import cwchoiit.dmaker.service.DMakerService;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.validation.annotation.Validated;
import org.springframework.web.bind.annotation.*;
import java.util.List;
/**
* This RESTful controller provides endpoints for retrieving developer names.
*/
@Slf4j
@RestController
@RequiredArgsConstructor
public class DMakerController {
private final DMakerService dMakerService;
/**
* Retrieves a list of developer names.
*
* @return A list of developer names.
*/
@GetMapping("/developers")
public List<DeveloperDTO> getDevelopers() {
log.info("GET /developers");
return dMakerService.getAllEmployedDevelopers();
}
@GetMapping("/developers/{memberId}")
public DeveloperDetailDTO getDeveloperByMemberId(@PathVariable String memberId) {
log.info("GET /developers/{}", memberId);
return dMakerService.getDeveloperByMemberId(memberId);
}
/**
* Creates a new developer.
*
* @param createDeveloperRequestDTO The request object containing the details of the developer to be created.
* @return A message indicating that the developer was created successfully.
*/
@PostMapping("/developers")
public CreateDeveloperResponseDTO createDeveloper(@Validated @RequestBody CreateDeveloperRequestDTO createDeveloperRequestDTO) {
log.info("POST /developers");
return dMakerService.createDeveloper(createDeveloperRequestDTO);
}
@PutMapping("/developers/{memberId}")
public DeveloperDetailDTO updateDeveloperByMemberId(@PathVariable String memberId,
@Validated @RequestBody UpdateDeveloperRequestDTO updateDeveloperRequestDTO) {
log.info("PUT /developers/{}", memberId);
return dMakerService.updateDeveloperByMemberId(memberId, updateDeveloperRequestDTO);
}
@DeleteMapping("/developers/{memberId}")
public DeveloperDetailDTO deleteDeveloperByMemberId(@PathVariable String memberId) {
log.info("DELETE /developers/{}", memberId);
return dMakerService.deleteDeveloperByMemberId(memberId);
}
}
DMakerController가 주입 받아야 하는 DMakerService를 Mock으로 빈 등록을 한다.
위에서 서비스 관련 테스트를 할때는 필요한 주입을 @Mock 애노테이션으로 사용했는데 여기서는 @MockBean으로 하는 이유는 이 테스트를 실행해보면 알겠지만 스프링이 띄워진다. @WebMvcTest는 스프링을 띄우긴 띄우는데 선언한 빈들만 등록하게 해서 띄우는 간단한 스프링이라고 생각하면 좋다. 그래서 스프링 Bean으로 등록될 Mock을 선언하는 @MockBean 애노테이션을 선언한다.
실제 테스트 코드는 다음과 같다. 주입 받은 MockMvc를 사용해서 HTTP 요청을 날린다. 이때 Content-Type은 JSON으로 지정하기 위해 필드로 선언한 `contentType`을 사용한다. 그리고 그 응답 결과를 우리가 만든 가짜 데이터가 나올 것으로 예상한 테스트 코드를 작성한다.
andDo(print())는 이 요청에 대한 요청-응답 정보를 출력하는 메서드이다.
실행 결과
정리를 하자면
이렇게 간단하게 데이터베이스가 필요한 서비스지만, 데이터베이스를 사용하고 싶지 않을 때 Mockito를 사용해서 가짜로 데이터를 만들어 내는 방법을 배워봤다. 간단한 단위 테스트를 작성할 때 Mockito를 사용하면 코드 자체적인 문제를 잘 찾아낼 수 있을 것 같다.
우선, 두 개의 애노테이션을 만들었다. 하나는 클래스 레벨에 적용할 애노테이션이고 하나는 메서드 레벨에 적용할 애노테이션이다.
애노테이션을 만드려면 기본적으로 두 개의 애노테이션이 필요하다. @Target, @Retention.
@Target은 이 애노테이션이 어디에 달릴지를 설명하는 애노테이션이다. ElementType.TYPE으로 설정하면 클래스 또는 인터페이스에 레벨에 적용할 애노테이션이고 ElementType.METHOD는 메서드 레벨에 적용할 애노테이션이다.
@Retention은 이 애노테이션이 살아있는 레벨을 말한다고 보면 된다. RetentionPolicy.RUNTIME으로 설정하면 런타임에도 해당 애노테이션은 살아 있는 상태로 남아있다. 그래서, 동적으로 애노테이션을 읽을 수 있다. RUNTIME말고 SOURCE도 있는데 이는 컴파일하면 컴파일된 파일에서 애노테이션이 보이지 않고 사라진다. 그래서 동적으로 이 애노테이션을 읽을 수 없다.
그리고 MethodAop 애노테이션은 value() 라는 값을 가질 수 있다. 값의 형태는 문자열이다.
MemberService
package cwchoiit.springadvanced.aop.member;
public interface MemberService {
String hello(String param);
}
MemberServiceImpl
package cwchoiit.springadvanced.aop.member;
import cwchoiit.springadvanced.aop.member.annotation.ClassAop;
import cwchoiit.springadvanced.aop.member.annotation.MethodAop;
import org.springframework.stereotype.Component;
@ClassAop
@Component
public class MemberServiceImpl implements MemberService {
@Override
@MethodAop("test value")
public String hello(String param) {
return "ok";
}
public String internal(String param) {
return "ok";
}
}
이번엔 인터페이스와 그 인터페이스를 구현한 클래스를 만들었다. 간단하게 하나의 메서드를 가지는 인터페이스(MemberService)와 그를 구현한 MemberServiceImpl이 있고, 이 구현 클래스는 @ClassAop 애노테이션을 달았다. 그리고 이 구현 클래스 내부에 hello(String param)은 @MethodAop 애노테이션이 달려있다.
'*'은 와일드카드로 모든것을 허용한다는 의미로 받아들이면 될 것 같다. 여기서 생략을 할 수 없는 필수 키워드인 반환 타입, 메서드명, 파라미터만을 작성했다. 반환 타입은 전체(*)이며 메서드명 또한 어떠한 것도 상관 없다는 의미의 '*'이고 파라미터는 어떤 파라미터라도 상관없다는 의미의 (..)를 사용했다. (..)는 파라미터가 없거나 여러개거나 한개거나 어떠한 상태여도 상관이 없다는 의미이다.
packageExactFalse()를 확인해보면 cwchoiit.springadvanced.aop.*.*(..)로 되어 있는데 이는 하위 패키지도 포함하는게 아니다. 즉, 정확히 cwchoiit.springadvanced.aop경로의 모든 타입(인터페이스, 클래스)의 모든 메서드를 지정하는 포인트 컷이다. 하위 패키지도 포함하려면 packageMatchSubPackage1()처럼 cwchoiit.springadvanced.aop..*.*(..)로 작성해야 한다.
자식은 부모에 들어가는 게 가능하기 때문에, 포인트컷 표현식을 부모로 설정하면 자식 클래스들은 포인트컷을 만족한다. 단, 인터페이스에서 선언된 메서드에 한한다. 이 말은 무슨말이냐면 부모일지언정 부모에 선언된 메서드가 아니라 자식 내부적으로만 가지고 있는 메서드는 포인트컷을 만족하지 못한다는 말이다.
위에서 MemberService와 MemberServiceImpl을 보면 부모인 인터페이스에는 hello 메서드만 있고 internal은 없다. 자식인 구현 클래스에는 internal 이라는 내부 메서드가 있다. 이 땐 부모 타입으로 포인트컷을 지정하면 자식 내부적으로만 가지고 있는 메서드에는 포인트 컷 조건이 만족하지 않는다.
/**
* String 타입의 파라미터 허용
*/
@Test
void argsMatch() {
pointcut.setExpression("execution(* *(String))");
assertThat(pointcut.matches(helloMethod, MemberServiceImpl.class)).isTrue();
}
/**
* 파라미터가 없음
*/
@Test
void noArgsMatch() {
pointcut.setExpression("execution(* *())");
assertThat(pointcut.matches(helloMethod, MemberServiceImpl.class)).isFalse();
}
/**
* 정확히 하나의 파라미터만, 타입은 노상관
*/
@Test
void argsMatchStar() {
pointcut.setExpression("execution(* *(*))");
assertThat(pointcut.matches(helloMethod, MemberServiceImpl.class)).isTrue();
}
/**
* 숫자와 타입에 무관하게 모든 파라미터
*/
@Test
void argsMatchAll() {
pointcut.setExpression("execution(* *(..))");
assertThat(pointcut.matches(helloMethod, MemberServiceImpl.class)).isTrue();
}
/**
* String 타입으로 시작, 숫자와 무관하게 모든 파라미터, 모든 타입 허용. 없어도 된다.
*/
@Test
void argsMatchComplex() {
pointcut.setExpression("execution(* *(String, ..))");
assertThat(pointcut.matches(helloMethod, MemberServiceImpl.class)).isTrue();
}
(String) → 정확하게 String 타입 파라미터
() → 파라미터가 없어야 한다.
(*) → 정확히 하나의 파라미터여야하고, 모든 타입을 허용한다.
(*, *) → 정확히 두개의 파라미터여야하고, 모든 타입을 허용한다.
(..) → 숫자와 무관하게 모든 파라미터, 모든 타입을 허용한다. 파라미터가 없어도 상관없다.
(String, ..) → String 타입의 파라미터로 시작하고 그 이후에는 숫자와 무관하게 모든 파라미터, 모든 타입을 허용한다. String 파라미터 이후에 파라미터가 없어도 된다.
within
within 지시자는 특정 타입 내의 조인 포인트들로 매칭을 제한한다. 이 말만 보면 무슨말인지 잘 모르겠다. 쉽게 말하면 작성한 타입(클래스, 인터페이스)이 매칭되면 그 안의 메서드들이 자동으로 매치된다. 참고로, 이건 거의 안쓴다. 거의 대부분은 execution으로 전부 해결이 가능하기 때문도 있고 부모 타입으로 매칭을 해야할 때도 있기 때문에 이건 그냥 알아만 두자!
WithinTest
package cwchoiit.springadvanced.aop.pointcut;
import cwchoiit.springadvanced.aop.member.MemberServiceImpl;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.aop.aspectj.AspectJExpressionPointcut;
import java.lang.reflect.Method;
import static org.assertj.core.api.Assertions.assertThat;
public class WithinTest {
AspectJExpressionPointcut pointcut = new AspectJExpressionPointcut();
Method helloMethod;
@BeforeEach
public void init() throws NoSuchMethodException {
helloMethod = MemberServiceImpl.class.getMethod("hello", String.class);
}
@Test
void withinExact() {
pointcut.setExpression("within(cwchoiit.springadvanced.aop.member.MemberServiceImpl)");
assertThat(pointcut.matches(helloMethod, MemberServiceImpl.class)).isTrue();
}
@Test
void withinStar() {
pointcut.setExpression("within(cwchoiit.springadvanced.aop.member.*Service*)");
assertThat(pointcut.matches(helloMethod, MemberServiceImpl.class)).isTrue();
}
@Test
void withinSubPackage() {
pointcut.setExpression("within(cwchoiit.springadvanced.aop..*)");
assertThat(pointcut.matches(helloMethod, MemberServiceImpl.class)).isTrue();
}
/**
* within 의 경우, execution 과는 반대로 부모 타입으로는 안된다.
*/
@Test
void withinSuperTypeFalse() {
pointcut.setExpression("within(cwchoiit.springadvanced.aop.member.MemberService)");
assertThat(pointcut.matches(helloMethod, MemberServiceImpl.class)).isFalse();
}
}
주의
주의할 부분이 있다. 마지막 테스트 코드인 withinSuperTypeFalse()를 보면, 표현식에 부모 타입을 지정하면 안된다. 정확하게 타입이 맞아야 한다. 이 점이 execution과 다른 점이다.
args
인자가 주어진 타입의 인스턴스인 조인 포인트로 매칭. 말이 또 어려운데 쉽게 말해 파라미터가 매치되는 녀석들이 다 조인 포인트가 된다고 보면 된다. 아래 코드를 보면 바로 이해가 될 것이다. 기본 문법은 execution의 args 부분과 같다. 참고로, 이 또한 그렇게 중요한게 아니다. 그냥 참고만 해도 무방하다.
execution과 args의 차이점
execution은 파라미터 타입이 정확하게 매칭되어야 한다. execution은 클래스에 선언된 정보를 기반으로 판단한다.
args는 부모 타입을 허용한다. args는 실제 넘어온 파라미터 객체 인스턴스를 보고 판단한다.
pointcut() → AspectJExpressionPointcut에 포인트컷은 한번만 지정할 수 있다. 이번 테스트에서는 포인트컷을 바꿔가면서 테스트 할 목적으로 포인트컷 자체를 생성하는 메서드를 만들었다.
자바가 기본으로 제공하는 String은 Object, Serializable의 하위 타입이다.
정적으로 클래스에 선언된 정보만 보고 판단하는 execution(* *(Object))은 매칭에 실패한다.
동적으로 실제 파라미터로 넘어온 객체 인스턴스로 판단하는 args(Object)는 매칭에 성공한다.
쉽게 말해, args는 부모 타입도 허용하고, execution은 부모 타입은 허용하지 않는다고 기억하면 된다.
참고로, args 지시자는 단독으로 사용되기 보다는 뒤에서 설명할 파라미터 바인딩에서 주로 사용된다.
@target, @within
정의
@target: 실행 객체의 클래스에 주어진 타입의 애노테이션이 있는 조인 포인트
@within: 주어진 애노테이션이 있는 타입 내 조인 포인트
사실 이 지시자도 그렇게 중요하지도 않고 정의만 보고서는 뭔 말인지 감이 잘 안오지만 코드로 보면 간단하다. 우선 둘 모두 타입에 있는 애노테이션으로 AOP 적용 여부를 판단한다. 아, 그리고 앞에 @ 붙은 지시자(@target, @within, @annotation, ...)들은 애노테이션과 관련된 지시자라고 생각하면 된다.
@target(hello.aop.member.annotation.ClassAop)
@within(hello.aop.member.annotation.ClassAop)
@ClassAop
class Target {
}
여기서 두 개의 차이는 다음과 같다.
@target은 애노테이션이 달린 클래스의 부모 클래스의 메서드까지 어드바이스를 전부 적용하고, @within은 자기 자신의 클래스에 정의된 메서드만 어드바이스를 적용한다.
그래서 한 문장으로 정리를 하자면 @target, @within 둘 모두 애노테이션으로 AOP를 적용하는데 @target의 경우 애노테이션이 달린 클래스와 그 상위 클래스의 메서드 모두에게 어드바이스를 적용하고 @within의 경우 애노테이션이 달린 클래스의 메서드에만 어드바이스를 적용한다.
AtTargetAtWithinTest
package cwchoiit.springadvanced.aop.pointcut;
import cwchoiit.springadvanced.aop.member.annotation.ClassAop;
import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Import;
@Slf4j
@Import(AtTargetAtWithinTest.Config.class)
@SpringBootTest
public class AtTargetAtWithinTest {
@Autowired
Child child;
@Test
void success() {
log.info("child proxy = {}", child.getClass());
child.childMethod();
child.parentMethod();
}
static class Config {
@Bean
public Parent parent() {
return new Parent();
}
@Bean
public Child child() {
return new Child();
}
@Bean
public AtTargetAtWithinAspect atTargetAtWithinAspect() {
return new AtTargetAtWithinAspect();
}
}
static class Parent {
public void parentMethod() {
log.info("[parentMethod] Start");
}
}
@ClassAop
static class Child extends Parent {
public void childMethod() {
log.info("[childMethod] Start");
}
}
@Aspect
static class AtTargetAtWithinAspect {
// @target: 인스턴스 기준으로 모든 메서드의 조인 포인트를 선정 = 부모 타입의 메서드도 적용
@Around("execution(* cwchoiit.springadvanced.aop..*(..)) && @target(cwchoiit.springadvanced.aop.member.annotation.ClassAop)")
public Object atTarget(ProceedingJoinPoint joinPoint) throws Throwable {
log.info("[@target] {}", joinPoint.getSignature());
return joinPoint.proceed();
}
// @within: 선택된 클래스 내부에 있는 메서드만 조인 포인트로 선정 = 부모 타입의 메서드는 적용되지 않음
@Around("execution(* cwchoiit.springadvanced.aop..*(..)) && @within(cwchoiit.springadvanced.aop.member.annotation.ClassAop)")
public Object atWithin(ProceedingJoinPoint joinPoint) throws Throwable {
log.info("[@within] {}", joinPoint.getSignature());
return joinPoint.proceed();
}
}
}
Child, Parent 클래스가 있다. Child 클래스는 상위 클래스로 Parent 클래스가 있다.
두 클래스를 모두 스프링 빈으로 등록한다.
에스팩트가 있고 두 개의 어드바이저가 있다. 하나는 @target, 하나는 @within을 사용하여 만들어진 포인트컷이다.
@target과 @within 모두 같은 애노테이션인 ClassAop애노테이션이 달린 클래스를 찾아 AOP로 적용한다.
이 @Aspect 역시 스프링 빈으로 등록해야 한다.
스프링 빈으로 등록한 Child 클래스를 테스트 코드에서는 주입받는다.
주입받은 Child 클래스의 childMethod(), parentMethod()를 각각 호출한다. 여기서 parentMethod()는 부모 클래스인 Parent에서 정의된 메서드이다.
결과는 childMethod() 호출 시, @target과 @within 모두 적용된다. parentMethod() 호출 시 @target만 적용되고 @within은 적용되지 않는다.
주의 다음 포인트컷 지시자는 단독으로 사용하면 안된다. args, @args, @target 이번 예제를 봐도 execution(* cwchoiit.springadvanced.aop..*(..))를 통해 적용 대상을 줄여준 것을 확인할 수 있다. args, @args, @target은 실제 객체 인스턴스가 생성되고 실행될 때 어드바이스 적용 여부를 확인할 수 있다. 실행 시점에 일어나는 포인트컷 적용 여부도 결국 프록시가 있어야 실행 시점에 판단할 수 있다. 프록시가 없다면 판단 자체가 불가능하다. 그런데 스프링 컨테이너가 프록시를 생성하는 시점은 스프링 컨테이너가 만들어지는 애플리케이션 로딩 시점이다. 실행 시점에 일어나는 포인트컷 적용 여부도 프록시가 있어야 판단이 가능한데 프록시가 없으면 실행 시점에 판단 자체가 불가능하다. 그래서 이 args, @args, @target 과 같은 지시자를 단독으로 사용할 경우, 스프링은 모든 스프링 빈에 AOP를 적용하려고 시도한다. 그런데 문제는 스프링이 내부에서 사용하는 빈 중에는 final로 지정된 빈들도 있기 때문에 프록시를 만들어내질 못하고 오류가 발생한다. 따라서 이러한 표현식은 최대한 프록시 적용 대상을 축소하는 표현식과 함께 사용해야 한다.
@annotation, @args
@annotation: 메서드가 주어진 애노테이션을 가지고 있는 조인 포인트를 매칭
@args: 전달된 실제 인수의 런타임 타입이 주어진 타입의 애노테이션을 갖는 조인 포인트
BeanAspect를 보면 orderService라는 bean 또는 *Repository라는 bean을 포인트컷의 조건으로 어드바이스를 만든 모습을 확인할 수 있다.
그 후 테스트 success()는 orderService의 orderItem()을 호출한다.
실행 결과
[bean] void cwchoiit.springadvanced.aop.order.OrderService.orderItem(String)
[orderService] 실행
[bean] String cwchoiit.springadvanced.aop.order.OrderRepository.save(String)
[orderRepository] 실행
매개변수 전달 ⭐️
매개변수 전달 - 메서드 파라미터 값 가져오기 (JoinPoint)
어드바이스 쪽에서 메서드의 파라미터를 전달받고 싶을 땐 어떻게 해야 할까? 예를 들어 다음 코드를 보자.
orderService.orderItem("item");
이런 코드가 있을 때, 어드바이스가 저 파라미터 "item"을 어떻게 받을 수 있을까? 이를 알아보자.
args(arg, ..)은 첫번째 파라미터를 받고 그 이후에 파라미터는 있거나 없거나 신경쓰지 않는다는 뜻이다. 그리고 이 arg를 어드바이스의 파라미터로 이름 그대로(arg) 동일하게 받아야 한다.
@Around를 사용하든, @Before를 사용하든 동일한 방식으로 접근이 가능한데 @Around는 ProceedingJoinPoint를 반드시 첫번째 파라미터로 받아야 하기 때문에 꼭 필요한 경우가 아니라면 더 깔끔한 @Before를 사용하면 된다. 상황에 따라 달라질 것이다.
@target, @within 은 타입 애노테이션에 대해 정보를 가져오는 것이다. 즉, 클래스, 인터페이스 레벨에 붙어있는 애노테이션을 가져오는 지시자이다.
@annotation은 메서드 레벨에 붙은 애노테이션을 가져오는 지시자이다. 그리고 난 위에서 그 애노테이션의 value()라는 속성에 "test value"를 넣었다. 이 값을 가져오고 싶을 때 저렇게 할 수 있다.
여기서, @annotation(annotation)이라고 썼으면 파라미터에서도 annotation이라는 이름으로 받아야 한다. 만약 @annotation(methodAop)로 썼으면 파라미터도 methodAop라는 이름으로 받으면 된다. 물론 @target, @within도 동일하다.
실행 결과
[@annotation] String cwchoiit.springadvanced.aop.member.MemberServiceImpl.hello(String), obj = test value
[@target] String cwchoiit.springadvanced.aop.member.MemberServiceImpl.hello(String), obj = @cwchoiit.springadvanced.aop.member.annotation.ClassAop()
[@within] String cwchoiit.springadvanced.aop.member.MemberServiceImpl.hello(String), obj = @cwchoiit.springadvanced.aop.member.annotation.ClassAop()
그리고 한가지 더, 원래는 @annotation 지시자를 사용할 때 패키지명부터 쭉 써줘야 한다. 아래와 같이 말이다. 근데 위에서처럼 저렇게 파라미터로 애노테이션 타입을 명시하면 이름으로 치환할 수 있다.
똑같이 MemberService를 조건으로 입력해도 this는 스프링 빈으로 등록된 프록시를, target은 스프링 빈으로 등록된 프록시가 참조하는 실제 객체를 바라본다는 뜻인데 이게 뭐 큰 의미가 있고 달라지나 싶을 수 있다. 그러나,JDK 동적 프록시와 CGLIB의 프록시 생성 방식이 다르기 때문에 차이점이 발생할 수 있다.
JDK 동적 프록시일 때
이 방식은 인터페이스가 필수이고 인터페이스를 구현한 프록시 객체를 생성한다. 다음이 그 그림이다.
그럼 이 방식으로 프록시를 만들 때 this와 target 지시자가 어떻게 다른지 보자.
MemberService 인터페이스 지정
this(hello.aop.member.MemberService)
proxy 객체를 보고 판단한다. this는 부모 타입을 허용한다. 프록시는 인터페이스인 MemberService를 참조하므로 AOP가 적용된다.
target(hello.aop.member.MemberService)
target 객체를 보고 판단한다. target은 부모 타입을 허용한다. target이 상속받는 MemberService가 있으므로 AOP가 적용된다.
MemberServiceImpl 구체 클래스 지정
this(hello.aop.member.MemberServiceImpl)
proxy 객체를 보고 판단한다. 프록시 객체의 부모는 MemberService 인터페이스이다. 인터페이스 위에 있는 것은 없다. MemberServiceImpl에 대한 정보를 아예 알 수 없으므로 AOP 적용 대상이 아니다.
target(hello.aop.member.MemberServiceImpl)
target 객체를 보고 판단한다. target은 바로 MemberServiceImpl 구체 클래스이므로 AOP 적용 대상이다.
결론은 JDK 동적 프록시는 this로 구체 클래스를 받으면 AOP 적용 대상이 아니게 된다. 반면, CGLIB는 어떨까?
CGLIB 프록시일 때
MemberService 인터페이스 지정
this(hello.aop.member.MemberService)
this는 proxy 객체를 바라본다. 프록시 객체는 구체 클래스인 MemberServiceImpl을 상속받는다. 그리고 이 구체 클래스는 부모인 MemberService를 알고 있다. this는 부모 타입을 허용하므로 AOP 적용 대상이다.
target(hello.aop.member.MemberService)
target은 실제 target 객체를 바라본다. target 객체인 MemberServiceImpl의 부모인 MemberService가 있다. target은 부모 타입을 허용하므로 AOP 적용 대상이다.
MemberServiceImpl 구체 클래스 지정
this(hello.aop.member.MemberServiceImpl)
this는 proxy 객체를 바라본다. 프록시 객체는 구체 클래스인 MemberServiceImpl을 상속받는다. this는 부모 타입을 허용하므로 AOP 적용 대상이다.
target(hello.aop.member.MemberServiceImpl)
target은 실제 target 객체를 바라본다. target 객체가 MemberServiceImpl이므로 AOP 적용 대상이다.
결론은 CGLIB 프록시는 모든 경우에 AOP 적용 대상이 된다. 그리고 스프링은 기본으로 CGLIB로 프록시를 만들어낸다.
이 라이브러리를 추가한 후에 다운된 외부 라이브러리 목록을 보면 다음 라이브러리가 있어야 한다.
이 라이브러리를 추가하면 스프링이 자동으로 무엇을 등록해준다고 했던가? 바로 빈 포스트 프로세서 중 AnnotationAwareAspectJAutoProxyCreator이 녀석을 등록해준다고 했다.
이 빈 포스트 프로세서는 빈으로 등록된 어드바이저, @Aspect 애노테이션이 붙은 빈(꼭 빈으로 등록해야 한다!)을 모두 찾아서 그 안에 포인트컷과 어드바이스를 통해 어드바이저로 만들어 둔 후, 모든 빈들에 대해 프록시가 적용될 수 있는지를 검토 후 적용해야 한다면 적용하여 프록시로 빈을 등록하거나 적용대상이 아니라면 빈을 그대로 빈으로 등록해주는 빈 포스트 프로세서다. 다시 복습 차원에서!
예제 프로젝트 만들기
AOP를 적용할 예제 프로젝트를 만들어보자. 지금까지 학습했던 내용과 비슷하다.
OrderRepository
package cwchoiit.springadvanced.aop.order;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Repository;
@Slf4j
@Repository
public class OrderRepository {
public String save(String itemId) {
log.info("[orderRepository] 실행");
if (itemId.equals("ex")) {
throw new IllegalStateException("예외 발생!");
}
return "ok";
}
}
OrderService
package cwchoiit.springadvanced.aop.order;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;
@Slf4j
@Service
@RequiredArgsConstructor
public class OrderService {
private final OrderRepository orderRepository;
public void orderItem(String itemId) {
log.info("[orderService] 실행");
orderRepository.save(itemId);
}
}
@Around 애노테이션의 값인 "execution(* cwchoiit.springadvanced.aop.order..*(..))"는 포인트컷이 된다.
@Around 애노테이션의 메서드인 doLog는 어드바이스(Advice)가 된다.
"execution(* cwchoiit.springadvanced.aop.order..*(..))"는 cwchoiit.springadvanced.aop.order 패키지와 그 하위 패키지(..)를 지정하는 AspectJ 포인트컷 표현식이다. 앞으로는 간단히 포인트컷 표현식이라고 하겠다.
이제 OrderService, OrderRepository의 모든 메서드는 AOP 적용 대상이 된다. 위 포인트컷 조건을 만족하니까.
이렇게만 만들었다고 해서 AOP가 바로 적용되는 것은 아니다. 이 @Aspect 애노테이션이 달린 클래스를 스프링 빈으로 등록해줘야 한다.
참고로, 스프링 AOP는 AspectJ의 문법을 차용하고, 프록시 방식의 AOP를 제공한다. AspectJ를 직접 사용하는 것이 아니다. 스프링 AOP를 사용할 때는 @Aspect 애노테이션을 주로 사용하는데, 이 애노테이션도 AspectJ가 제공하는 애노테이션이다.
또한, @Aspect를 포함한 `org.aspectj` 패키지 관련 기능은 aspectjweaver.jar 라이브러리가 제공하는 기능이다. 앞서, build.gradle에 spring-boot-starter-aop를 포함했는데 이렇게 하면 스프링의 AOP 관련 기능과 함께 aspectjweaver.jar도 함께 사용할 수 있게 의존 관계에 포함된다. 그런데 스프링에서는 AspectJ가 제공하는 애노테이션이나 관련 인터페이스만 사용하는 것이고 실제 AspectJ가 제공하는 컴파일, 로드타임 위버 등을 사용하는 것은 아니다. 스프링은 지금까지 우리가 학습한 것처럼 프록시 방식의 AOP를 사용한다.
AopTest - 테스트 코드
package cwchoiit.springadvanced.aop;
import cwchoiit.springadvanced.aop.aspect.AspectV1;
import cwchoiit.springadvanced.aop.order.OrderRepository;
import cwchoiit.springadvanced.aop.order.OrderService;
import lombok.extern.slf4j.Slf4j;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.aop.support.AopUtils;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.context.annotation.Import;
import static org.assertj.core.api.Assertions.*;
@Slf4j
@SpringBootTest
@Import(AspectV1.class) //@Import 만으로도 빈으로 등록하는것과 동일하다. 주로 @Configuration 에서 추가할 때 자주 사용됐지만, @Import 로도 그 안에 클래스들을 빈으로 등록한다.
public class AopTest {
@Autowired
OrderService orderService;
@Autowired
OrderRepository orderRepository;
@Test
void aopInfo() {
log.info("isAopProxy, orderService = {}", AopUtils.isAopProxy(orderService));
log.info("isAopProxy, orderRepository = {}", AopUtils.isAopProxy(orderRepository));
}
@Test
void success() {
orderService.orderItem("itemA");
}
@Test
void exception() {
assertThatThrownBy(() -> orderService.orderItem("ex")).isInstanceOf(IllegalStateException.class);
}
}
@Aspect는 애스팩트라는 표식이지, 컴포넌트 스캔이 되는 것은 아니다! 따라서 AspectV1을 AOP로 사용하려면 반드시 스프링 빈으로 등록을 해야 한다!
스프링 빈으로 등록하는 방법은 여러가지가 있다.
@Bean을 사용해서 직접 등록
@Component 컴포넌트 스캔을 사용해서 자동 등록
@Import 주로 설정 파일을 추가할 때 사용하지만, 이 기능으로 스프링 빈도 등록할 수 있다.
실행 결과 - success()
[log] void cwchoiit.springadvanced.aop.order.OrderService.orderItem(String)
[orderService] 실행
[log] String cwchoiit.springadvanced.aop.order.OrderRepository.save(String)
[orderRepository] 실행
어드바이스 기능이 적용된 모습을 확인할 수 있을 것이다.
스프링 AOP 구현2 - 포인트컷 분리
@Around에 포인트컷 표현식을 직접 넣을 수도 있지만, @Pointcut 애노테이션을 사용해서 별도로 분리할 수도 있다.
AspectV2
package cwchoiit.springadvanced.aop.aspect;
import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
@Slf4j
@Aspect
public class AspectV2 {
/**
* 반환 타입은 'void' 여야 한다.
* 다른 곳에서 이 포인트컷을 사용하려면 public 이어야 하고 이 내부 안에서 사용하는 건 private 이어도 된다.
* */
@Pointcut("execution(* cwchoiit.springadvanced.aop.order..*(..))")
private void allOrder() {} // pointcut signature
@Around("allOrder()")
public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable {
log.info("[log] {}", joinPoint.getSignature());
return joinPoint.proceed();
}
}
@Pointcut에 포인트컷 표현식을 사용한다.
메서드 이름과 파라미터를 합쳐서 포인트컷 시그니처라 한다.
메서드의 반환 타입은 void여야 한다.
블록 내부는 비워둔다.
포인트컷 시그니처는 allOrder()이다. 이름 그대로 주문과 관련된 모든 기능을 대상으로 하는 포인트컷이다.
@Around 어드바이스에서는 포인트컷을 직접 지정해도 되지만, 포인트컷 시그니처를 사용해도 된다. 여기서는 @Around("allOrder()")를 사용한다.
private, public 같은 접근 제어자는 내부에서만 사용하면 private을 사용해도 되지만, 다른 애스팩트에서 참고하려면 public을 사용해야 한다.
이렇게 포인트컷을 분리하여 얻는 이점은 다음과 같다.
포인트컷에 의미를 부여할 수 있다. (모든 주문에 대해: allOrder())
여러 어드바이스에서 해당 포인트컷을 가져다가 사용할 수 있다. (쉽게 말해 모듈화가 된다는 것)
이 애스팩트(AspectV2)를 임포트해서 테스트 코드를 돌려도 동일한 결과를 얻는다.
AopTest - 테스트 코드
package cwchoiit.springadvanced.aop;
import cwchoiit.springadvanced.aop.aspect.AspectV1;
import cwchoiit.springadvanced.aop.aspect.AspectV2;
import cwchoiit.springadvanced.aop.order.OrderRepository;
import cwchoiit.springadvanced.aop.order.OrderService;
import lombok.extern.slf4j.Slf4j;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.aop.support.AopUtils;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.context.annotation.Import;
import static org.assertj.core.api.Assertions.*;
@Slf4j
@SpringBootTest
@Import(AspectV2.class) //@Import 만으로도 빈으로 등록하는것과 동일하다. 주로 @Configuration 에서 추가할 때 자주 사용됐지만, @Import 로도 그 안에 클래스들을 빈으로 등록한다.
public class AopTest {
@Autowired
OrderService orderService;
@Autowired
OrderRepository orderRepository;
@Test
void aopInfo() {
log.info("isAopProxy, orderService = {}", AopUtils.isAopProxy(orderService));
log.info("isAopProxy, orderRepository = {}", AopUtils.isAopProxy(orderRepository));
}
@Test
void success() {
orderService.orderItem("itemA");
}
@Test
void exception() {
assertThatThrownBy(() -> orderService.orderItem("ex")).isInstanceOf(IllegalStateException.class);
}
}
실행 결과 - success()
[log] void cwchoiit.springadvanced.aop.order.OrderService.orderItem(String)
[orderService] 실행
[log] String cwchoiit.springadvanced.aop.order.OrderRepository.save(String)
[orderRepository] 실행
스프링 AOP 구현3 - 어드바이스 추가
이번에는 어드바이스를 하나 더 추가해서 좀 더 복잡한 예제를 만들어보자.
앞서, 로그를 출력하는 기능에 추가로 트랜잭션을 적용하는 코드도 추가해보자. 여기서는 진짜 트랜잭션을 실행하는 것은 아니고 기능이 동작하는 것처럼 로그만 남겨보자.
AspectV3
package cwchoiit.springadvanced.aop.aspect;
import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
@Slf4j
@Aspect
public class AspectV3 {
/**
* 반환 타입은 'void' 여야 한다.
* 다른 곳에서 이 포인트컷을 사용하려면 public 이어야 하고 이 내부 안에서 사용하는 건 private 이어도 된다.
*/
@Pointcut("execution(* cwchoiit.springadvanced.aop.order..*(..))")
private void allOrder() {
} // pointcut signature
// 클래스 이름 패턴이 *Service
@Pointcut("execution(* *..*Service.*(..))")
private void allService() {
}
@Around("allOrder()")
public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable {
log.info("[log] {}", joinPoint.getSignature());
return joinPoint.proceed();
}
@Around("allOrder() && allService()")
public Object doTransaction(ProceedingJoinPoint joinPoint) throws Throwable {
try {
log.info("[트랜잭션 시작] {}", joinPoint.getSignature());
Object result = joinPoint.proceed();
log.info("[트랜잭션 커밋] {}", joinPoint.getSignature());
return result;
} catch (Exception e) {
log.info("[트랜잭션 롤백] {}", joinPoint.getSignature());
throw e;
} finally {
log.info("[리소스 릴리즈] {}", joinPoint.getSignature());
}
}
}
allOrder() 포인트컷은 cwchoiit.springadvanced.aop.order 패키지와 그 하위 패키지를 대상으로 한다.
allService() 포인트컷은 타입 이름 패턴이 *Service를 대상으로 하는데 쉽게 이야기해서, XxxService처럼 Service로 끝나는 것을 대상으로 한다.
여기서 타입 이름 패턴이라고 한 이유는 클래스, 인터페이스에 모두 적용되기 때문이다.
@Around("allOrder() && allService()")
포인트컷은 이렇게 조합할 수도 있다. &&, ||, ! 3가지 조합이 가능하다.
cwchoiit.springadvanced.aop.order 패키지와 그 하위 패키지이면서 타입 이름 패턴이 *Service인 것을 대상으로 한다.
결과적으로 doTransaction() 어드바이스는 OrderService에만 적용된다.
doLog() 어드바이스는 OrderService, OrderRepository에 모두 적용된다.
orderService에는 doLog(), doTransaction() 두가지 어드바이스가 적용되어 있고, orderRepository에는 doLog() 하나의 어드바이스만 적용된 것을 확인할 수 있다. 그런데, 여기에서 로그를 남기는 순서가 [doLog()→doTransaction()] 순서로 작동한다. 만약, 어드바이스가 적용되는 순서를 변경하고 싶으면 어떻게 하면 될까? 예를 들어서 실행 시간을 측정해야 하는데 트랜잭션과 관련된 시간을 제외하고 측정하고 싶다면 [doTransaction()→doLog()] 이렇게 트랜잭션 이후에 로그를 남겨야 할 것이다. 그 방법을 알아보자!
스프링 AOP 구현4 - 포인트컷 참조
다음과 같이 포인트컷으르 공용으로 사용하기 위해 별도의 외부 클래스에 포인트컷들을 모아두어도 된다. 참고로 외부에서 호출할 때는 포인트컷의 접근 제어자를 public으로 열어두어야 한다.
Pointcuts
package cwchoiit.springadvanced.aop.aspect;
import org.aspectj.lang.annotation.Pointcut;
public class Pointcuts {
@Pointcut("execution(* cwchoiit.springadvanced.aop.order..*(..))")
public void allOrder() {
}
@Pointcut("execution(* *..*Service.*(..))")
public void allService() {
}
@Pointcut("allOrder() && allService()")
public void allOrderAndService() {
}
}
allOrderAndSerivce()는 allOrder() 포인트컷과 allService() 포인트컷을 조합해서 새로운 포인트컷을 만들 수도 있다는 것을 보여주기 위함이다.
이 클래스가 실제로 외부의 포인트컷을 가져다가 사용하는 방식이다. @Around 애노테이션은 외부 포인트컷을 참조하면 된다. 살짝 불편한 부분은 패키지명까지 작성해줘야 한다는 것인데 이는 어쩔 수 없다. 문자로 입력해야 하기 때문에.
이러한 에스팩트를 가지고 위에서 사용한 테스트 코드를 수행해도 여전히 동일하게 동작한다.
스프링 AOP 구현5 - 어드바이스 순서
어드바이스는 기본적으로 순서를 보장하지 않는다. 순서를 지정하고 싶으면 @Aspect 적용 단위로 org.springframework.core.annotation.Order 애노테이션을 적용해야 한다. 문제는 이것을 어드바이스 단위가 아니라 @Aspect 적용 단위, 즉, 클래스 단위로 적용할 수 있다는 점이다. 그래서 지금처럼 하나의 애스팩트에 여러 어드바이스가 있으면 순서를 보장받을 수 없고 애스팩트를 별도의 클래스로 분리해야 한다.
첫번째, 우선 모든 어드바이스는 JoinPoint를 첫번째 파라미터로 받을 수 있다. 생략도 가능하다. 그러나, @Around는 반드시 ProceedingJoinPoint를 받아야 한다.
그 이유는 @Around 같은 경우 개발자가 직접 타겟을 호출하는 코드를 작성해야 한다.joinPoint.proceed()이 코드. 그 외 나머지 어드바이스는 개발자가 직접 타겟을 호출하지 않는다. 그래서 @Around는 ProceedingJoinPoint를 첫번째 파라미터로 받아야 하고 그 외 나머지 어드바이스는 JoinPoint를 받거나 생략할 수 있다.
두번째, @Before는 실제 타겟을 호출하는 코드를 작성안하지만 @Before의 모든 코드가 다 수행되면 자동으로 호출한다. 물론, 예외가 발생할 경우엔 다음 코드가 호출되지는 않는다.
세번째, @AfterReturning, @AfterThrowing은 각각 실제 타겟 호출의 결과와 에러를 파라미터로 받고 그 파라미터의 이름은 애노테이션에서 작성한 이름과 동일해야 한다.
네번째, @AfterReturning, @AfterThrowing에서 파라미터로 받는 실제 타겟 호출 반환값과 에러의 타입은 해당 타입과 일치하거나 그 상위 타입이어야 한다.
다섯번째, @AfterReturning에서는 @Around와 다르게 실제 타겟 호출 반환값에 대한 변경이 불가능하다.
이는 단순하게 생각해보면 된다. @Around는 개발자가 직접 실제 타겟을 호출하여 돌려받는 결과를 리턴하는데 그렇기 때문에 리턴값에 변경이 가능한것이고 @AfterReturning은 그렇지 않기 때문에 불가능한 것. 다만, 이 반환값을 가지고 어떤 행동을 취할 순 있다. 그 반환값을 변경하지 못한다는 말이다.
여섯번째, @Around는 joinPoint.proceed()를 여러번 호출할 수도 있다.
일곱번째, @Around는 joinPoint.proceed()를 반드시 호출해야 한다. 그래야 다음 어드바이스 또는 실제 객체를 호출할 수 있다.
여덟번째, @After는 메서드 실행이 정상적이든 예외가 발생하든 상관없이 종료되면 실행된다.
참고로, ProceedingJoinPoint는 JoinPoint의 하위 타입이다.
JointPoint 인터페이스의 주요 기능
getArgs() → 메서드 인수를 반환한다.
getThis() → 프록시 객체를 반환한다.
getTarget() → 대상 객체를 반환한다.
getSignature() → 조인 포인트(스프링 AOP면 메서드에 한함)에 대한 여러 정보를 반환한다.
toString() → 포인트컷에 대한 설명을 인쇄한다.
ProceedingJoinPoint 인터페이스의 주요 기능
proceed() → 다음 어드바이스나 타겟을 호출한다.
이 여러 어드바이스의 호출 순서는 다음과 같다.
스프링은 5.2.7 버전부터 동일한 @Aspect 안에서 동일한 조인포인트의 우선순위를 정했다.
적용되는 순서는 이렇게 적용되지만, 호출 순서와 리턴 순서는 반대라는 점을 알아두자. 위 그림을 보면 이해가 될 것이다.
물론, @Aspect 안에 동일한 종류의 어드바이스가 2개 이상이면 순서가 보장되지 않는다. 이 경우에 보장된 순서를 원한다면 @Aspect를 분리해서 @Order를 적용해서 순서를 적용해야 한다.
그럼 왜 @Around만 사용하더라도 모든게 가능한데 이렇게 부분적으로 나뉘어진 어드바이스가 있을까?
이 부분에 대한 답은 이런것들이다. 다음 코드엔 심각한 문제가 있다.
@Around("hello.aop.order.aop.Pointcuts.orderAndService()")
public void doBefore(ProceedingJoinPoint joinPoint) {
log.info("[before] {}", joinPoint.getSignature());
}
어떤 문제가 있을까? 바로 @Around 어드바이스인데도 실제 객체를 호출하지 않는다. 이 코드를 작성한 개발자의 의도는 실제 객체를 호출하기 전에 무언가를 로그로 출력하고 싶었던 것 뿐인데 @Around이기 때문에 실제 객체를 반드시 호출해야 한다.
그럼 이 코드를 보자. 이 코드에는 문제가 전혀 없다.
@Before("hello.aop.order.aop.Pointcuts.orderAndService()")
public void doBefore(JoinPoint joinPoint) {
log.info("[before] {}", joinPoint.getSignature());
}
@Before이기 때문에 실제 객체를 호출하는 고민을 전혀 할 필요가 없다.
이 말은, @Around는 가장 넓은 기능을 제공하나 실수할 가능성이 있다. 반면, @Before, @After 같은 어드바이스는 기능은 적더라도 실수할 가능성이 적으며 코드가 단순해진다. 그리고 가장 중요한 부분은 이 코드를 작성한 의도가 분명해진다는 것이다. @Before 애노테이션을 본 순간 "아, 이 코드는 실제 객체를 호출하기 전에 무언가를 하기 위해 만들어진 어드바이스구나." 라고 자연스레 생각할 수 있다.
즉, 좋은 설계는 제약이 있는 것이다. 제약은 실수의 가능성을 줄여준다. 애시당초 @Around가 아니라 @Before를 사용하면 실제 객체를 호출할 고민조차 할 필요가 없기 때문에 그 부분을 고려하지 않아도 되는것이다.
핵심 기능은 해당 객체가 제공하는 고유의 기능이다. 예를 들어서 OrderService의 핵심 기능은 주문 로직이다.
부가 기능은 핵심 기능을 보조하기 위해 제공되는 기능이다. 예를 들어서 로그 추적 로직, 트랜잭션 기능이 있다. 이러한 부가 기능은 단독으로는 사용되지 않고, 핵심 기능과 함께 사용된다. 예를 들어서 로그 추적 기능은 어떤 핵심 기능이 호출되었는지 로그를 남기기 위해 사용한다. 그러니까 부가 기능은 이름 그대로 핵심 기능을 보조하기 위해 존재한다.
주문 로직을 실행하기 직전에 로그 추적 기능을 사용해야 하면, 핵심 기능인 주문 로직과 부가 기능인 로그 추적 로직이 하나의 객체 안에 섞여 들어가게 된다. 부가 기능이 필요한 경우 이렇게 둘을 합해서 하나의 로직을 완성한다. 이제 주문 서비스를 실행하면 핵심 기능인 주문 로직과 부가 기능인 로그 추적 로직이 함께 실행된다.
여러 곳에서 공통으로 사용하는 부가 기능
보통 부가 기능은 여러 클래스에 걸쳐서 함께 사용된다. 예를 들어서 모든 애플리케이션 호출을 로깅해야 하는 요구사항을 생각해보자. 이러한 부가 기능은 횡단 관심사(cross-cutting concerns)가 된다. 쉽게 이야기해서 하나의 부가 기능이 여러 곳에 동일하게 사용된다는 뜻이다.
부가 기능 적용 문제
그런데 이런 부가 기능을 여러 곳에 적용하려면 너무 번거롭다. 예를 들어서 부가 기능을 적용해야 하는 클래스가 100개면 100개 모두에 동일한 코드를 추가해야 한다. 코드의 중복이라도 줄이고자 부가 기능을 별도의 유틸리티 클래스로 만든다고 해도 해당 유틸리티 클래스를 호출하는 코드가 결국 필요하다. 그리고 부가 기능이 구조적으로 단순 호출이 아니고 try - catch - finally 같은 구조가 필요하다면 더욱 복잡해진다. 더 큰 문제는 수정이다. 만약, 부가 기능에 수정이 발생하면, 100개의 클래스 모두를 하나씩 찾아가면서 수정해야 한다. 여기에 추가로 부가 기능이 적용되는 위치를 변경한다면 어떻게 될까? 예를 들어서 부가 기능을 모든 컨트롤러, 서비스, 리포지토리에 적용했다가, 로그가 너무 많이 남아서 서비스 계층에만 적용한다고 수정해야하면 어떻게 될까? 또 수 많은 코드를 고쳐야 할 거이다.
요약하자면, 다음과 같은 문제점이 발생한다.
부가 기능을 적용할 때 아주 많은 반복이 필요하다.
부가 기능이 여러 곳에 퍼져서 중복 코드를 만들어낸다.
부가 기능을 변경할 때 중복 때문에 많은 수정이 필요하다.
부가 기능의 적용 대상을 변경할 때 많은 수정이 필요하다.
소프트웨어 개발에서 변경 지점은 하나가 될 수 있도록 잘 모듈화를 해야 한다. 그런데 부가 기능처럼 특정 로직을 애플리케이션 전반에 적용하는 문제는 일반적인 OOP 방식으로는 해결이 어렵다.
AOP 소개 - 애스펙트
핵심 기능과 부가 기능을 분리
누군가는 이러한 부가 기능 도입의 문제점들을 해결하기 위해 오랜기간 고민해왔다. 그 결과 부가 기능을 핵심 기능에서 분리하고 한 곳에서 관리하도록 했다. 그리고 해당 부가 기능을 어디에 적용할지 선택하는 기능도 만들었다. 이렇게 부가 기능과 부가 기능을 어디에 적용할지 선택하는 기능을 합해서 하나의 모듈로 만들었는데 이것이 바로 애스팩트(aspect)이다. 애스팩트는 쉽게 이야기해서 부가 기능과 해당 부가 기능을 어디에 적용할지 정의한 것이다. 예를 들어서 "로그 출력 기능을 모든 컨트롤러에 적용해라" 라는 것이 정의되어 있다.
그렇다 바로 우리가 이전에 알아본 @Aspect 바로 그것이다. 그리고 스프링이 제공하는 어드바이저도 어드바이스(부가 기능)과 포인트컷(적용 대상)을 가지고 있어서 개념상 하나의 애스팩트이다. 애스팩트는 우리말로 해석하면 관점이라는 뜻인데, 이름 그대로 애플리케이션을 바라보는 관점을 하나하나의 기능에서 횡단 관심사(cross-cutting concerns) 관점으로 달리 보는 것이다. 이렇게 애스팩트를 사용한 프로그래밍 방식을 관점 지향 프로그래밍(AOP, Aspect-Oriented Programming)이라 한다.
참고로, AOP는 OOP를 대체하기 위한 것이 아니라 횡단 관심사를 깔끔하게 처리하기 어려운 OOP의 부족한 부분을 보조하는 목적으로 개발되었다.
AspectJ 프레임워크
AOP의 대표적인 구현으로 AspectJ 프레임워크가 있다. 스프링은 AOP를 지원하고 있으나 대부분 AspectJ의 문법을 차용하고 AspectJ가 제공하는 기능의 일부만 제공한다. 그러나, 결론은 스프링 AOP를 사용하면 실무에서 어지간한 모든 기능을 다 사용할 수 있다. 이는 이후에 차차 알아보도록 하자.
AOP 적용 방식
AOP를 사용하면 핵심 기능과 부가 기능이 코드상 완전히 분리되어서 관리된다. 그렇다면 AOP를 사용할 때 부가 기능 로직은 어떤 방식으로 실제 로직에 추가될 수 있을까?
크게 3가지 방법이 있다.
컴파일 시점
클래스 로딩 시점
런타임 시점(프록시)
컴파일 시점
.java 소스 코드를 컴파일러를 사용해서 .class를 만드는 시점에 부가 기능 로직을 추가할 수 있다. 이때는 AspectJ가 제공하는 특별한 컴파일러를 통해 이루어진다. .class를 디컴파일 해보면 에스팩트 관련 호출 코드가 들어간다. 쉽게 말해서 부가 기능 코드가 핵심 기능이 있는 컴파일된 코드 주변에 실제로 붙어 버린다고 생각하면 된다. AspectJ 컴파일러는 Aspect를 확인해서 해당 클래스가 적용 대상인지 먼저 확인한 후 적용 대상인 경우에 부가 기능 로직을 적용한다. 이렇게 원본 로직에 부가 기능 로직이 추가되는 것을 위빙(Weaving)이라고 한다. 이 방법의 단점은 특별한 컴파일러가 필요하다는 것 그 자체이고 사용하기에 굉장히 복잡하다. 그래서 결론적으로 이 방법은 잘 사용하지 않는다.
클래스 로딩 시점
자바를 실행하면 자바 언어는 .class 파일을 JVM 내부의 클래스 로더에 보관한다. 이때 중간에서 .class 파일을 조작한 다음 JVM에 올릴 수 있다. 자바 언어는 .class를 JVM에 저장하기 전에 조작할 수 있는 기능을 제공한다. 자세한 내용을 알려면 java instrumentation을 검색해 보면 된다. 참고로 수많은 모니터링 툴들이 이 방식을 사용한다. 이 시점에 에스팩트를 적용하는 것을 로드 타임 위빙이라고 한다. 이 방법의 단점은 자바를 실행할 때 특별한 옵션을 통해 클래스 로더 조작기를 지정해야 하는데 이 부분이 번거롭고 운영하기에 단점이 있다. 그래서 이 방법 역시 스프링 AOP에서 잘 사용되지 않는다.
런타임 시점 ⭐️
런타임 시점은 컴파일도 다 끝나고, 클래스 로더에 클래스도 다 올라가서 이미 자바가 실행되고 난 다음을 말한다. 자바의 메인(main) 메서드가 이미 실행된 다음이다. 따라서 자바 언어가 제공하는 범위 안에서 부가 기능을 적용해야 한다. 스프링과 같은 컨테이너의 도움을 받고 프록시와 DI, 빈 포스트 프로세서 같은 개념들을 총 동원해야 한다. 이렇게 하면 최종적으로 프록시를 통해 스프링 빈에 부가 기능을 적용할 수 있다. 그렇다. 지금까지 우리가 학습한 것이 바로 프록시 방식의 AOP이다.
프록시를 사용하기 때문에 AOP 기능에 일부 제약이 있다. 하지만 특별한 컴파일러나 자바를 실행할 때 복잡한 옵션과 클래스 로더 조작기를 설정하지 않아도 된다. 스프링만 있으면 얼마든지 AOP를 적용할 수 있다.
부가 기능이 적용되는 차이를 정리하면 다음과 같다.
컴파일 시점: 실제 대상 코드에 애스팩트를 통한 부가 기능 호출 코드가 포함된다. AspectJ를 직접 사용해야 한다.
클래스 로딩 시점: 실제 대상 코드에 애스팩트를 통한 부가 기능 호출 코드가 포함된다. AspectJ를 직접 사용해야 한다.
런타임 시점: 실제 대상 코드는 그대로 유지된다. 대신에 프록시를 통해 부가 기능이 적용된다. 따라서 항상 프록시를 통해야 부가 기능을 사용할 수 있다. 스프링 AOP는 이 방식을 사용한다.
AOP 적용 위치 (조인 포인트)
AOP는 지금까지 학습한 메서드 실행 위치뿐만 아니라 다음과 같은 다양한 위치에 적용할 수 있다.
생성자
필드 값 접근
static 메서드 접근
메서드 실행
이렇게 AOP를 적용할 수 있는 지점을 조인 포인트(Join point)라 한다. AspectJ를 사용해서 컴파일 시점과 클래스 로딩 시점에 적용하는 AOP는 바이트코드를 실제 조작하기 때문에 해당 기능을 모든 지점에 다 적용할 수 있다. 그러나,프록시 방식을 사용하는 스프링 AOP는 메서드 실행 지점에만 AOP를 적용할 수 있다. 잘 생각해보자, 프록시는 실제 객체를 어떻게 호출할 수 있지? 메서드를 호출해서만 가능하다. 즉, 메서드 실행 지점에만 AOP를 적용할 수 밖에 없다. 프록시 방식을 사용하는 스프링 AOP는 스프링 컨테이너가 관리할 수 있는 스프링 빈에만 AOP를 적용할 수 있다. 스프링이 자동으로 등록해주는 빈 포스트 프로세서를 사용해야 하니까.
참고로, 스프링은 AspectJ의 문법을 차용하고 프록시 방식의 AOP를 적용한다. AspectJ를 직접 사용하는 것이 아니다.
중요! 그러면, 이러한 의문이 들 수 있다. "스프링 AOP 방식인 프록시보다 그냥 AspectJ를 사용하면 더 좋은 거 아니야?"라고 생각할 수 있다. 그러나, AspectJ 프레임워크를 사용하기 위해 공부해야 할 내용이 어마어마하게 많고 설정 방법도 굉장히 복잡하다고 알려져 있다. 반면 스프링 AOP는 별도의 추가 자바 설정 없이 스프링만 있으면 편리하게 AOP를 사용할 수 있고 실무에서는 스프링이 제공하는 AOP 기능만 사용해도 대부분의 문제를 해결할 수 있다. 게다가 개발자가 직접 해야할 일은 결국, 포인트컷과 어드바이스 만드는 것 밖에 없다 사실. 나머지는 스프링이 알아서 다 해주니까. 그러니 스프링 AOP가 제공하는 기능을 학습하는 것에 집중하자.
AOP 용어 정리
조인 포인트(Join Point)
어드바이스가 적용될 수 있는 위치. 메서드 실행, 생성자 호출, 필드 값 접근, static 메서드 접근 같은 프로그램 실행 중 지점
조인 포인트는 추상적인 개념이다. AOP를 적용할 수 있는 모든 지점이라 생각하면 된다.
스프링 AOP는 프록시 방식을 사용하므로 조인 포인트는 항상 메서드 실행 지점으로 제한된다.
포인트컷(Pointcut)
조인 포인트 중에서 어드바이스가 적용될 위치를 선별하는 기능
주로 AspectJ 표현식을 사용해서 지정
프록시를 사용하는 스프링 AOP는 메서드 실행 지점만 포인트컷으로 선별 가능
타겟(Target)
어드바이스를 받는 객체(프록시가 참조하는 실제 객체를 말한다). 포인트컷으로 결정된다.
어드바이스(Advice)
부가 기능
Around, Before, After와 같은 다양한 종류의 어드바이스가 있다.
에스팩트(Aspect)
어드바이스 + 포인트컷을 모듈화 한 것
@Aspect를 생각하면 된다.
여러 어드바이스와 포인트 컷이 함께 존재
어드바이저(Advisor)
하나의 어드바이스와 하나의 포인트 컷으로 구성
스프링 AOP에서만 사용되는 특별한 용어
위빙(Weaving)
포인트컷으로 결정한 타겟의 조인 포인트에 어드바이스를 적용하는 것
위빙을 통해 핵심 기능 코드에 영향을 주지 않고 부가 기능을 추가할 수 있음
AOP 적용을 위해 에스팩트를 객체에 연결한 상태
컴파일 타임
로드 타임
런타임(스프링 AOP는 런타임이고 프록시 방식이다)
AOP 프록시
AOP 기능을 구현하기 위해 만든 프록시 객체. 스프링에서 AOP 프록시는 JDK 동적 프록시 또는 CGLIB 프록시이다.
정리를 하자면
지금까지가 AOP, 스프링 AOP의 개념이었다. 그러니까 결론은 AOP는 여러 컴포넌트 단위에서 공통적으로 가지는 공통의 관심사를 처리하기 위한 방법으로 고안된 개념이다. 공통의 관심사에 대한 코드를 작성하기 위해 모든 컴포넌트(객체)에 같은 코드를 작성하는 것은 비효율적이고 중복 코드가 발생하며 유지보수에 적합하지 않기 때문에 모듈화 하여 모듈 하나를 관리하는 방식이 AOP라고 생각하면 될 것 같다. 스프링 AOP는 프록시 방식을 사용한다고 했고 그렇기에 조인 포인트는 메서드 실행 지점으로 제한된다. 그러나, 그렇다 한들 대부분의 문제를 해결할 수 있기 때문에 스프링 AOP를 사용하는 것만으로 충분하다. 이제 실제로 AOP를 구현해보자.
스프링 애플리케이션에 프록시를 적용하려면 포인트컷과 어드바이스로 구성되어 있는 어드바이저(Advisor)를 만들어서 스프링 빈으로 등록하면 된다. 그러면 나머지는 앞서 배운 AnnotationAwareAspectJAutoProxyCreator 가 모두 자동으로 처리해준다. AnnotationAwareAspectJAutoProxyCreator는 스프링 빈으로 등록된 어드바이저들을 찾고, 스프링 빈들에 자동으로 프록시를 적용해준다.
스프링은 @Aspect 애노테이션으로 매우 편리하게 포인트컷과 어드바이스로 구성되어 있는 어드바이저 생성 기능을 지원한다. 지금까지 어드바이저를 직접 만들었던 부분을 @Aspect 애노테이션을 사용해서 만들어보자. 그러니까, @Aspect를 사용해서 빈으로 등록한 것들도 저 AnnotationAwareAspectJAutoProxyCreator이 녀석이 다 찾아서 프록시 적용 여부를 확인하고 적용 대상에는 프록시를 입혀 빈으로 등록해준다.
참고로, @Aspect는 관점 지향 프로그래밍(AOP)을 가능하게 하는 AspectJ 프로젝트에서 제공하는 애노테이션이다. 스프링은 이것을 차용해서 프록시를 통한 AOP를 가능하게 한다. AOP와 AspectJ 관련된 자세한 내용은 이후에 나온다. 지금은 프록시에 초점을 맞추자. 우선 이 애노테이션을 사용해서 스프링이 편리하게 프록시를 만들어준다고 생각하면 된다.
LogTraceAspect
package cwchoiit.springadvanced.proxy.config.v6_aop.aspect;
import cwchoiit.springadvanced.trace.TraceStatus;
import cwchoiit.springadvanced.trace.logtrace.LogTrace;
import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.Signature;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
@Slf4j
@Aspect
public class LogTraceAspect {
private final LogTrace trace;
public LogTraceAspect(LogTrace trace) {
this.trace = trace;
}
@Around("execution(* cwchoiit.springadvanced.proxy.app..*(..))")
public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {
TraceStatus status = null;
Signature signature = joinPoint.getSignature();
try {
String message = signature.toShortString();
status = trace.begin(message);
Object result = joinPoint.proceed();
trace.end(status);
return result;
} catch (Exception e) {
trace.exception(status, e);
throw e;
}
}
}
* → 모든 반환 타입을 의미. (원래 맨 앞에 접근 제어자가 가장 먼저인데 생략이 가능하다. 그래서 한 개만 있는 경우 반환 타입을 나타낸다)
cwchoiit.springadvanced.proxy.app.. →cwchoiit.springadvanced.proxy.app 패키지와 그 하위 모든 패키지(..)를 나타낸다.
*(..) → 모든 메서드(*)의 모든 파라미터(..)를 의미한다.
그래서 결론적으로 * cwchoiit.springadvanced.proxy.app..*(..) 은 해당 패키지부터 그 하위 모든 패키지의 모든 반환 타입의 모든 메서드의 어떠한 파라미터도 상관없이 해당되는 메서드들을 가리킨다.
그리고 해당 메서드의 파라미터를 보면 ProceedingJoinPoint joinpoint를 받는다. 이건 예전 포스팅에서 어드바이스를 만들 때 MethodInvocation invocation과 유사하다. 내부에 실제 호출 대상, 전달 인자, 그리고 어떤 객체와 어떤 메서드가 호출되었는지 정보가 포함되어 있다.
그래서 joinpoint.proceed()를 호출하는 게 실제 호출 대상(target)을 호출하는 것이다.
@Aspect 프록시 - 설명
우선 스프링의 AnnotationAwareAspectJAutoProxyCreator는 2가지 일을 한다.
스프링 빈으로 등록된 Advisor를 가져와서 프록시 적용 대상 판단 후 적용
스프링 빈으로 등록된 @Aspect를 보고 어드바이저로 변환하고 프록시 적용 대상 판단 후 적용
3. 모든 Advisor 빈 조회: 스프링 컨테이너에서 Advisor 빈을 모두 조회한다.
3-1. 모든 @Aspect 빈 조회: @Aspect 어드바이저 빌더 내부에 저장된 Advisor를 모두 조회한다. (사실 이 과정 전에 먼저 빈으로 등록된 @Aspect 애노테이션이 달려있는 모든 클래스를 찾고 어드바이저로 만든 후 @Aspect 어드바이저 빌더에 저장하는 과정이 생략되어 있다)
4. 프록시 적용 대상 체크: 앞서 3, 3-1 에서 조회한 Advisor에 포함되어 있는 포인트컷을 사용해서 해당 객체가 프록시를 적용할 대상인지 아닌지 판단한다. 이 때 객체의 클래스 정보는 물론이고, 해당 객체의 모든 메서드를 포인트컷에 하나하나 모두 매칭해본다. 그래서 조건이 하나라도 만족하면 프록시 적용 대상이 된다. 예를 들어, 메서드 하나만 포인트컷 조건에 만족해도 프록시 적용 대상이 된다.
5. 프록시 생성: 프록시 적용 대상이면 프록시를 생성하고 프록시를 반환한다. 그래서 프록시를 스프링 빈으로 등록한다. 만약 프록시 적용 대상이 아니라면 원본 객체를 반환해서 원본 객체를 스프링 빈으로 등록한다.
6. 빈 등록: 반환된 객체는 스프링 빈으로 등록된다.
정리를 하자면
@Aspect를 사용해서 이전 작업과는 비교도 안되게 편리하게 프록시를 적용할 수 있다. @Aspect 애노테이션이 달린 클래스를 빈으로 등록하면 스프링이 자동으로 만들어주는 AnnotationAwareAspectJAutoProxyCreator 빈 후처리기를 통해 알아서 포인트컷의 조건을 기반으로 프록시를 만들어준다. 실무에서는 프록시를 적용하려고 하면 대부분 이 방식을 사용한다.
지금까지 우리가 진행한 애플리케이션 전반에 로그를 남기는 기능은 특정 기능 하나에 관심이 있는 기능이 아니다. 애플리케이션의 여러 기능들 사이에 걸쳐서 들어가는 공통 관심사이다. 이것을 바로 횡단 관심사(cross-cutting concerns)라고 한다. 우리가 지금까지 진행한 방법이 이렇게 여러곳에 걸쳐 있는 횡단 관심사의 문제를 해결하는 방법이었다.
지금까지 프록시를 사용해서 이렇게 횡단 관심사를 어떻게 해결하는지 점진적으로 매우 깊이있게 학습하고 기반을 다져두었다. 이제 이 기반을 바탕으로 이러한 횡단 관심사를 전문으로 해결하는 스프링 AOP에 대해 본격적으로 알아보자!
@Aspect 애노테이션을 붙이고 그 안에 @Around, @AfterReturning, @Before, ... 등등의 애노테이션만 달아주면 어떻게 여기서 작성한 포인트컷에 해당하는 객체들이 프록시로 등록되고 그 안에 로직이 어드바이스가 될까? 즉, 결국 그 메서드가 어떻게 Advisor가 되어 프록시 팩토리에 의해 프록시를 만들까? 정답은 이 빈 후처리기다.
빈 후처리기
스프링에서@Bean이나 컴포넌트 스캔으로 스프링 빈을 등록하면 스프링은 대상 객체를 생성하고 스프링 컨테이너 내부의 빈 저장소에 등록한다. 그리고 이후에는 스프링 컨테이너를 통해 등록한 스프링 빈을 조회해서 사용하면 된다.
스프링이 빈 저장소에 등록할 목적으로 생성한 객체를 빈 저장소에 등록하기 직전에 조작하고 싶다면 빈 후처리기를 사용하면 된다.
BeanPostProcessor는 번역하면 빈 후처리기로, 이름 그대로 빈을 생성한 후에 무언가를 처리하는 용도로 사용한다.
빈 후처리기는 강력하다. 객체를 조작하는게 가능하고 완전히 다른 객체로 바꿔치기 하는 것도 가능하다. 빈 후처리기 과정을 자세히 살펴보자.
빈 후처리기 과정
1. 생성: 스프링 빈 대상이 되는 객체를 생성한다 (@Bean, 컴포넌트 스캔 모두 포함)
2. 전달: 생성된 객체를 빈 저장소에 등록하기 직전에 빈 후처리기에 전달한다.
3. 후 처리 작업: 빈 후처리기는 전달된 스프링 빈 객체를 조작하거나 다른 객체로 바꿔치기 할 수 있다.
4. 등록: 빈 후처리기는 빈을 반환한다. 전달된 빈을 그대로 반환하면 해당 빈이 등록되고, 바꿔치기 하면 다른 객체가 빈 저장소에 등록된다.
여기서 '3. 후 처리 작업'을 보면 스프링 빈 객체를 조작 또는 바꿔치기 한다고 되어 있는데 이 말은 무슨 말일까? 다음 그림을 보자.
빈 후처리기에서 객체 A를 객체 B로 바꿔버린 모습을 볼 수 있다. 그리고 그 바꾼 객체 B를 스프링 빈 저장소에 전달하면 최초 객체 A가 객체 B로 최종 등록된다. 이것을 객체를 조작 또는 바꿔치기한다 말한다.
빈 후처리기를 사용하려면 BeanPostProcessor 인터페이스를 구현하고, 스프링 빈으로 등록하면 된다.
이 BeanPostProcessor 인터페이스는 두 개의 메서드를 제공한다.
postProcessBeforeInitialization: 객체 생성 이후에 @PostConstruct 같은 초기화가 발생하기 전에 호출되는 포스트 프로세서
postProcessAfterInitialization: 객체 생성 이후에 @PostConstruct 같은 초기화가 발생한 다음에 호출되는 포스트 프로세서
이 빈후처리기를 통해 특정 객체를 다른 객체로 변경해버리는 예시 코드를 작성해보자.
빈 후처리기 - 예제 코드1
BeanPostProcessorTest
package cwchoiit.springadvanced.proxy.postprocessor;
import lombok.extern.slf4j.Slf4j;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.BeanCreationException;
import org.springframework.beans.factory.NoSuchBeanDefinitionException;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import static org.assertj.core.api.Assertions.*;
@Slf4j
public class BasicTest {
@Test
void basicConfig() {
AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(BasicConfig.class);
A a = applicationContext.getBean("beanA", A.class);
a.helloA();
assertThatThrownBy(() -> applicationContext.getBean(B.class))
.isInstanceOf(NoSuchBeanDefinitionException.class);
}
@Configuration
static class BasicConfig {
@Bean(name = "beanA")
public A a() {
return new A();
}
}
static class A {
public void helloA() {
log.info("helloA");
}
}
static class B {
public void helloB() {
log.info("helloB");
}
}
}
new AnnotationConfigApplicationContext(BasicConfig.class) → 스프링 컨테이너를 생성하면서 BasicConfig.class를 넘겨주었다. BasicConfig.class 설정 파일은 스프링 빈으로 등록된다.
빈 등록
@Configuration
static class BasicConfig {
@Bean(name = "beanA")
public A a() {
return new A();
}
}
beanA라는 이름으로 A 객체를 스프링 빈으로 등록했다.
빈 조회
A a = applicationContext.getBean("beanA", A.class);
빈 후처리기를 사용하려면, BeanPostProcessor 인터페이스를 구현하고, 스프링 빈으로 등록하면 된다.
참고로, 스프링 부트를 사용하면 이미 수많은 빈 후처리기가 자동 등록된 상태이다. 우리도 필요하면 추가적으로 빈 후처리기를 이렇게 등록할 수 있다.
postProcessBeforeInitialization: 객체 생성 이후에 @PostConstruct 같은 초기화가 발생하기 전에 호출되는 포스트 프로세서이다.
postProcessAfterInitialization: 객체 생성 이후에 @PostConstruct 같은 초기화가 발생한 다음에 호출되는 포스트 프로세서이다.
BeanPostProcessorTest
package cwchoiit.springadvanced.proxy.postprocessor;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.NoSuchBeanDefinitionException;
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import static org.assertj.core.api.Assertions.assertThatThrownBy;
@Slf4j
public class BeanPostProcessorTest {
@Test
void basicConfig() {
AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(BeanPostProcessorConfig.class);
B b = applicationContext.getBean("beanA", B.class);
b.helloB();
assertThatThrownBy(() -> applicationContext.getBean(A.class))
.isInstanceOf(NoSuchBeanDefinitionException.class);
}
@Configuration
static class BeanPostProcessorConfig {
@Bean(name = "beanA")
public A a() {
return new A();
}
@Bean
public AToBPostProcessor toBPostProcessor() {
return new AToBPostProcessor();
}
}
static class A {
public void helloA() {
log.info("helloA");
}
}
static class B {
public void helloB() {
log.info("helloB");
}
}
static class AToBPostProcessor implements BeanPostProcessor {
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
log.info("beanName = {}, bean = {}", beanName, bean);
if (bean instanceof A) {
return new B();
}
return bean;
}
}
}
이번엔 빈 후처리기를 직접 구현해봤다. AToBPostProcessor는 인터페이스인 BeanPostProcessor를 구현하고, 스프링 빈으로 등록하면 스프링 컨테이너가 빈 후처리기로 인식하고 동작한다.
이 빈 후처리기는 A 객체를 새로운 B 객체로 바꿔치기한다. 파라미터로 넘어오는 빈 객체가 A의 인스턴스이면 새로운 B 객체를 생성해서 반환한다. 여기서 A 대신에 반환된 값인 B가 스프링 컨테이너에 등록된다. 다음 실행결과를 보면 beanName = beanA, bean = A 객체의 인스턴스가 빈 후처리기에 넘어온 것을 확인할 수 있다.
실행 결과
beanName = beanA, bean = cwchoiit.springadvanced.proxy.postprocessor.BeanPostProcessorTest$A@50916ff4
..B - hello B
실행 결과를 보면, 최종적으로 beanA 라는 스프링 빈 이름에 A 객체 대신에 B 객체가 등록된 것을 확인할 수 있다. A는 스프링 빈으로 등록조차 되지 않는다. 이게 빈 후처리기이다.
정리
이렇게 빈 후처리기를 통해 스프링이 빈 저장소(스프링 컨테이너)에 등록할 객체를 강력한 방식으로 조작하고 변경할 수 있다. 여기서 조작이란 메서드를 호출함을 의미한다. 일반적으로 스프링 컨테이너가 등록하는, 특히 컴포넌트 스캔의 대상이 되는 빈들은 중간에 조작할 방법이 없는데 빈 후처리기를 사용하면 개발자가 등록하는 모든 빈을 중간에 조작할 수 있게 된다. 이 말은 빈 객체를 프록시로 교체하는 것도 가능하다는 뜻이다. 약간 느낌이 애노테이션 프로세싱과 비슷하다. 중간에 후킹을 할 수 있는 어떤 포인트를 만들어주는 것이 유사하다.
실제로 스프링은 AOP를 구현할 때 빈 후처리기를 통해 컴포넌트 스캔으로 등록되는 빈 중 프록시로 만들어져야 하는 객체를 포인트컷을 통해 찾아 프록시로 변경하여 등록해준다.
참고로, @PostConstruct는 스프링 빈 생성 이후에 빈을 초기화 하는 역할을 한다. 그런데 생각해보면 빈의 초기화라는 것이 단순히 @PostConstruct 애노테이션이 붙은 초기화 메서드를 한번 호출만 하면 된다. 쉽게 이야기해서 생성된 빈을 한번 조작하는 것이다. 따라서 빈을 조작하는 행위를 하는 적절한 빈 후처리기가 있으면 될 것 같다. 스프링은 CommonAnnotationBeanPostProcessor라는 빈 후처리기를 자동으로 등록하는데, 여기에서 @PostConstruct 애노테이션이 붙은 메서드를 호출한다.
빈 후처리기 - 적용
빈 후처리기를 사용해서 실제 객체 대신 프록시를 스프링 빈으로 등록해보자. 이렇게 하면 수동으로 등록하는 빈은 물론이고, 컴포넌트 스캔을 사용하는 빈까지 모두 프록시를 적용할 수 있다. 더 나아가서 설정 파일에 있는 수많은 프록시 생성 코드도 한번에 제거할 수 있다.
이 빈 후처리기는 원본 객체를 프록시 객체로 변환하는 역할을 한다. 이때 프록시 팩토리를 사용한다. 프록시 팩토리는 advisor가 필수이기 때문에 이 부분은 외부에서 주입받도록 했다.
모든 스프링 빈들에 프록시를 적용할 필요도 해서도 안된다. 여기서는 특정 패키지와 그 하위에 위치한 스프링 빈들만 프록시를 적용한다. 그러기 위해 외부에서 특정 패키지 경로를 주입받는다. 외부에서 프록시가 적용되길 원하는 특정 패키지 경로를 주입받고 postProcessAfterInitialization 메서드에서 이 패키지 또는 이 패키지 하위 경로인지 체크한다.
BeanPostProcessorConfig
package cwchoiit.springadvanced.proxy.config.v4_postprocessor;
import cwchoiit.springadvanced.proxy.config.AppV1Config;
import cwchoiit.springadvanced.proxy.config.AppV2Config;
import cwchoiit.springadvanced.proxy.config.v3_proxyfactory.advice.LogTraceAdvice;
import cwchoiit.springadvanced.proxy.config.v4_postprocessor.postprocessor.PackageLogTracePostProcessor;
import cwchoiit.springadvanced.trace.logtrace.LogTrace;
import lombok.extern.slf4j.Slf4j;
import org.springframework.aop.Advisor;
import org.springframework.aop.support.DefaultPointcutAdvisor;
import org.springframework.aop.support.NameMatchMethodPointcut;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Import;
@Slf4j
@Configuration
@Import({AppV1Config.class, AppV2Config.class})
public class BeanPostProcessorConfig {
@Bean
public PackageLogTracePostProcessor packageLogTracePostProcessor(LogTrace trace) {
return new PackageLogTracePostProcessor("cwchoiit.springadvanced.proxy.app", getAdvisor(trace));
}
private Advisor getAdvisor(LogTrace trace) {
NameMatchMethodPointcut pointcut = new NameMatchMethodPointcut();
pointcut.setMappedNames("request*", "order*", "save*");
LogTraceAdvice logTraceAdvice = new LogTraceAdvice(trace);
return new DefaultPointcutAdvisor(pointcut, logTraceAdvice);
}
}
빈 후처리기를 구현했으면 스프링 빈으로 등록해야 한다. 빈 후처리기는 스프링 빈으로 등록만 하면 자동으로 동작한다. 여기에 프록시를 적용할 패키지 정보와 어드바이저를 넘겨준다.
이제 프록시를 생성하는 코드가 설정 파일에는 필요가 없다. 순수한 빈 등록만 고민하면 된다. 프록시를 생성하고 프록시를 스프링 빈으로 등록하는 것은 빈 후처리기가 모두 처리해준다.
실행 결과
...
2025-01-09T16:03:55.688+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = org.springframework.boot.autoconfigure.http.JacksonHttpMessageConvertersConfiguration, bean = class org.springframework.boot.autoconfigure.http.JacksonHttpMessageConvertersConfiguration
2025-01-09T16:03:55.688+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = org.springframework.boot.autoconfigure.http.client.HttpClientAutoConfiguration, bean = class org.springframework.boot.autoconfigure.http.client.HttpClientAutoConfiguration
2025-01-09T16:03:55.689+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = spring.http.client-org.springframework.boot.autoconfigure.http.client.HttpClientProperties, bean = class org.springframework.boot.autoconfigure.http.client.HttpClientProperties
2025-01-09T16:03:55.691+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = clientHttpRequestFactoryBuilder, bean = class org.springframework.boot.http.client.JdkClientHttpRequestFactoryBuilder
2025-01-09T16:03:55.692+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = clientHttpRequestFactorySettings, bean = class org.springframework.boot.http.client.ClientHttpRequestFactorySettings
2025-01-09T16:03:55.693+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = spring.info-org.springframework.boot.autoconfigure.info.ProjectInfoProperties, bean = class org.springframework.boot.autoconfigure.info.ProjectInfoProperties
2025-01-09T16:03:55.693+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = org.springframework.boot.autoconfigure.info.ProjectInfoAutoConfiguration, bean = class org.springframework.boot.autoconfigure.info.ProjectInfoAutoConfiguration
2025-01-09T16:03:55.694+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = org.springframework.boot.autoconfigure.sql.init.SqlInitializationAutoConfiguration, bean = class org.springframework.boot.autoconfigure.sql.init.SqlInitializationAutoConfiguration
2025-01-09T16:03:55.694+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = spring.sql.init-org.springframework.boot.autoconfigure.sql.init.SqlInitializationProperties, bean = class org.springframework.boot.autoconfigure.sql.init.SqlInitializationProperties
2025-01-09T16:03:55.695+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = org.springframework.boot.autoconfigure.task.TaskSchedulingConfigurations$ThreadPoolTaskSchedulerBuilderConfiguration, bean = class org.springframework.boot.autoconfigure.task.TaskSchedulingConfigurations$ThreadPoolTaskSchedulerBuilderConfiguration
2025-01-09T16:03:55.695+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = spring.task.scheduling-org.springframework.boot.autoconfigure.task.TaskSchedulingProperties, bean = class org.springframework.boot.autoconfigure.task.TaskSchedulingProperties
2025-01-09T16:03:55.696+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = threadPoolTaskSchedulerBuilder, bean = class org.springframework.boot.task.ThreadPoolTaskSchedulerBuilder
2025-01-09T16:03:55.697+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = org.springframework.boot.autoconfigure.task.TaskSchedulingConfigurations$SimpleAsyncTaskSchedulerBuilderConfiguration, bean = class org.springframework.boot.autoconfigure.task.TaskSchedulingConfigurations$SimpleAsyncTaskSchedulerBuilderConfiguration
2025-01-09T16:03:55.698+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = simpleAsyncTaskSchedulerBuilder, bean = class org.springframework.boot.task.SimpleAsyncTaskSchedulerBuilder
2025-01-09T16:03:55.698+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = org.springframework.boot.autoconfigure.task.TaskSchedulingAutoConfiguration, bean = class org.springframework.boot.autoconfigure.task.TaskSchedulingAutoConfiguration
2025-01-09T16:03:55.698+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = org.springframework.boot.autoconfigure.web.client.RestClientAutoConfiguration, bean = class org.springframework.boot.autoconfigure.web.client.RestClientAutoConfiguration
2025-01-09T16:03:55.698+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = httpMessageConvertersRestClientCustomizer, bean = class org.springframework.boot.autoconfigure.web.client.HttpMessageConvertersRestClientCustomizer
2025-01-09T16:03:55.699+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = restClientSsl, bean = class org.springframework.boot.autoconfigure.web.client.AutoConfiguredRestClientSsl
2025-01-09T16:03:55.699+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = restClientBuilderConfigurer, bean = class org.springframework.boot.autoconfigure.web.client.RestClientBuilderConfigurer
2025-01-09T16:03:55.699+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = org.springframework.boot.autoconfigure.web.client.RestTemplateAutoConfiguration, bean = class org.springframework.boot.autoconfigure.web.client.RestTemplateAutoConfiguration
2025-01-09T16:03:55.700+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = org.springframework.boot.autoconfigure.web.embedded.EmbeddedWebServerFactoryCustomizerAutoConfiguration, bean = class org.springframework.boot.autoconfigure.web.embedded.EmbeddedWebServerFactoryCustomizerAutoConfiguration
2025-01-09T16:03:55.700+09:00 INFO 72763 --- [springadvanced] [ main] c.s.p.c.v.p.PackageLogTracePostProcessor : param beanName = multipartResolver, bean = class org.springframework.web.multipart.support.StandardServletMultipartResolver
...
무수히 많은 로그가 찍힌다. 왜일까? 자동으로 등록되는 스프링 빈이 이렇게 많다는 것이다. 그리고 빈 후처리기는 그 모든 빈들에 대해서 호출되기 때문에 당연히 이렇게 많은 로그가 찍힌다. 그래서 위에서 특정 패키지로 제한한 것이다.
우리의 프록시로 등록된 녀석들을 확인하기 위해 /v1/request, /v2/request, /v3/request 를 호출해보자. 아래와 같이 로그가 잘 찍히는 것을 확인할 수 있다.
빈 후처리기는 스프링 빈을 생성한 후에 초기화 하기 직전 또는 직후 이 빈을 조작하거나 바꿔치기할 수 있는 기술이다. 그리고 이 빈 후처리기를 우리가 직접 만들어서 어떤 문제를 해결했는지 보자.
문제1 - 너무 많은 설정
프록시를 직접 스프링 빈으로 등록하는 ProxyFactoryConfigV1, ProxyFactoryConfigV2와 같은 설정 파일은 프록시 관련 설정이 지나치게 많다는 문제가 있다. 예를 들어, 애플리케이션에 스프링 빈이 100개가 있다면 여기에 프록시를 통해 부가 기능을 적용하려면 100개의 프록시 설정 코드가 들어가야 한다.
문제2 - 컴포넌트 스캔
V3처럼 컴포넌트 스캔을 사용하는 경우, 프록시 설정 코드를 직접 작성하는 것으로 프록시를 등록하지도 못한다. 왜냐하면 컴포넌트 스캔으로 이미 스프링 컨테이너에 실제 객체를 스프링 빈으로 등록을 다 해버린 상태이기 때문이다.
문제 해결
빈 후처리기를 사용해서 프록시를 생성하는 부분을 하나로 집중할 수 있다. (바로 빈 후처리기를 작성하는 코드).
그리고 컴포넌트 스캔처럼 스프링이 직접 대상을 빈으로 등록하는 경우에도 중간에 빈 등록 과정을 가로채서 원본 대신에 프록시를 스프링 빈으로 등록할 수 있다. 덕분에 애플리케이션에 수많은 스프링 빈이 추가되어도 프록시와 관련된 코드는 전혀 변경하지 않아도 된다. 그리고 컴포넌트 스캔을 사용해도 프록시가 모두 적용된다.
하지만 개발자의 욕심은 끝이 없다.
스프링은 프록시를 생성하기 위한 빈 후처리기를 이미 만들어서 제공한다.
중요!
프록시의 적용 대상 여부를 여기서는 간단하게 패키지를 기준으로 설정했다. 그런데 잘 생각해보면 포인트컷을 사용하면 더 깔끔할 것 같다. 포인트컷은 이미 클래스, 메서드 단위의 필터 기능을 가지고 있기 때문에, 프록시 적용 대상 여부를 정밀하게 설정할 수 있다. 참고로 어드바이저는 포인트컷을 가지고 있다. 따라서 어드바이저를 통해 포인트컷을 확인할 수 있다. 스프링 AOP는 포인트컷을 사용해서 프록시 적용 대상 여부를 체크한다. 결과적으로 포인트컷은 다음 두 곳에서 사용된다.
프록시 적용 대상 여부를 체크해서 꼭 필요한 곳에만 프록시를 적용한다. (빈 후처리기 - 자동 프록시 생성)
프록시의 어떤 메서드가 호출 되었을 때 어드바이스를 적용할 지 판단한다. (프록시 내부)
스프링이 제공하는 빈 후처리기1
결론을 먼저 말하자면, 저렇게 직접 빈 후처리기를 만들 일은 없다. 적어도 프록시를 만들기 위해서라면 말이다.
왜냐? 스프링이 저 역할을 하는 빈 후처리기를 이미 다 만들어서 제공해주기 때문이다. 그것들을 사용하려면 다음 라이브러리를 추가해야한다.
이 라이브러리를 추가하면 aspectjweaver 라는 aspectJ 관련 라이브러리를 등록하고, 스프링 부트가 AOP 관련 클래스를 자동으로 스프링 빈에 등록한다. 스프링 부트가 없던 시절에는 @EnableAspectJAutoProxy를 직접 사용해야 했는데, 이 부분을 스프링 부트가 자동으로 처리해준다. 스프링 부트가 활성화하는 빈은 AopAutoConfiguration인데 이 빈을 활성화하면 자동 프록시 생성기라는 빈 후처리기가 스프링 빈에 자동으로 등록된다.
AnnotationAwareAspectJAutoProxyCreator
이 녀석이 스프링 부트가 자동으로 스프링 빈으로 등록해주는 빈 후처리기다.
이름 그대로 자동으로 프록시를 생성해주는 빈 후처리기. 이 빈 후처리기는 스프링 빈으로 등록된 Advisor들을 자동으로 찾아서 프록시가 필요한 곳에 자동으로 프록시를 적용해준다.
Advisor안에는 Pointcut과 Advice가 이미 모두 포함되어 있다. 따라서 Advisor만 알고 있으면 그 안에 있는 Pointcut으로 어떤 스프링 빈에 프록시를 적용해야 할지 알 수 있다. 그리고 Advice로 부가 기능을 적용하면 된다.
그리고 @Aspect도 자동으로 인식해서 프록시를 만들고 AOP를 적용해준다.
자동 프록시 생성기의 작동 과정
1. 생성: 스프링이 스프링 빈 대상이 되는 객체를 생성한다. (@Bean, 컴포넌트 스캔 모두 포함)
2. 전달: 생성된 객체를 빈 저장소에 등록하기 직전에 저 AnnotationAwareAspectJAutoProxyCreator 빈 후처리기에 전달한다.
3. 모든 Advisor 빈 조회:AnnotationAwareAspectJAutoProxyCreator 빈 후처리기는 스프링 컨테이너에서 모든 Advisor를 조회한다.
4. 프록시 적용 대상 체크: 앞서 조회한 Advisor에 포함되어 있는 포인트컷을 사용해서 해당 객체가 프록시를 적용할 대상인지 아닌지 판단한다. 이 때 객체의 클래스 정보는 물론이고, 해당 객체의 모든 메서드를 포인트컷에 하나하나 모두 매칭해본다. 하나라도 조건이 만족하면 프록시 적용 대상이 된다. 예를 들어 10개의 메서드 중에 하나만 포인트컷 조건에 만족해도 프록시 적용 대상이 된다.
5. 프록시 생성: 프록시 적용 대상이면 프록시 팩토리를 사용해 프록시를 생성하고 반환해서 프록시를 스프링 빈으로 등록한다. 만약 프록시 적용 대상이 아니라면 원본 객체를 반환해서 원본 객체를 스프링 빈으로 등록한다.
6. 빈 등록: 반환된 객체는 스프링 빈으로 등록된다.
코드를 통해 바로 적용해보자.
AutoProxyConfig
package cwchoiit.springadvanced.proxy.config.v5_autoproxy;
import cwchoiit.springadvanced.proxy.config.AppV1Config;
import cwchoiit.springadvanced.proxy.config.AppV2Config;
import cwchoiit.springadvanced.proxy.config.v3_proxyfactory.advice.LogTraceAdvice;
import cwchoiit.springadvanced.trace.logtrace.LogTrace;
import org.springframework.aop.Advisor;
import org.springframework.aop.support.DefaultPointcutAdvisor;
import org.springframework.aop.support.NameMatchMethodPointcut;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Import;
@Configuration
@Import({AppV1Config.class, AppV2Config.class})
public class AutoProxyConfig {
@Bean
public Advisor getAdvisor(LogTrace trace) {
NameMatchMethodPointcut pointcut = new NameMatchMethodPointcut();
pointcut.setMappedNames("request*", "order*", "save*");
LogTraceAdvice logTraceAdvice = new LogTraceAdvice(trace);
return new DefaultPointcutAdvisor(pointcut, logTraceAdvice);
}
}
이전에 했던 방식을 잠깐 떠올려보자. 분명 내가 직접 만든 빈 후처리기를 빈으로 등록했다. 그런데 이제 그럴 필요가 없다. 왜냐? 스프링이 프록시를 만들어주는 빈 후처리기를 이미 자동으로 등록해주기 때문이다.
그래서 나는 Advisor만 빈으로 등록하면 된다. 그럼 이 안에 있는 포인트컷을 참고해서 프록시로 만들어야 할 녀석들이 누구인지 AnnotationAwareAspectJAutoProxyCreator는 알아서 판단 후 프록시로 만들어준다.
강조: 포인트컷은 2가지에 사용된다.
1. 프록시 적용 여부 판단 - 프록시를 생성하는 단계
AnnotationAwareAspectJAutoProxyCreator는 등록된 모든 Advisor, @Aspect를 찾고 그 안에 포인트컷을 사용해서 해당 빈이 프록시를 생성할 필요가 있는지 없는지 체크한다.
클래스 + 메서드 조건을 모두 비교한다. 이 때 모든 메서드를 체크하는데, 포인트컷 조건에 하나하나 매칭해본다. 만약 조건에 맞는 것이 하나라도 있으면 프록시를 생성하고, 조건에 맞는 것이 하나도 없을 땐 프록시를 생성하지 않는다.
2. 어드바이스 적용 여부 판단 - 프록시를 사용하는 단계
프록시가 호출되었을 때 부가 기능인 어드바이스를 적용할지 말지 포인트컷을 보고 판단한다. 즉, 특정 메서드가 호출됐을 때 그 메서드가 포인트컷 조건에 만족하는 메서드인지 확인 한다는 뜻이다.
프록시를 모든 곳에 생성하는 것은 비용 낭비라고 했고 AnnotationAwareAspectJAutoProxyCreator는 포인트컷으로 한번 필터링해서 어드바이스가 사용될 가능성이 있는 곳에만 프록시를 생성한다고 했다. 그럼 만약 여러개의 포인트컷 조건을 만족한다고 하면 프록시는 여러개가 생길까? 아니다. 프록시는 딱 하나만 생기고 그 안에 여러 어드바이저가 등록되는 것이다.
AnnotationAwareAspectJAutoProxyCreator 상황별 정리
advisor1의 포인트컷만 만족: 프록시 1개 생성, 프록시에 advisor1만 포함
advisor1, advisor2의 포인트컷을 모두 만족: 프록시 1개 생성, 프록시에 advisor1, advisor2 모두 포함
advisor1, advisor2의 포인트컷을 모두 만족하지 않음: 프록시가 생성되지 않음
스프링이 제공하는 빈 후처리기2
위 방식대로 애플리케이션을 실행하면 원하는 기능은 제대로 동작하는데 애플리케이션 로딩 로그를 자세히 보면 이상하다.
Advice: 프록시가 제공하는 추가 기능에 대한 로직을 가지고 있는 곳을 말한다. (조언)
Pointcut: 프록시가 제공하는 추가 기능을 어디에적용할것인가?을 가지고 있는 곳을 말한다. (어디에?)
Advisor: Advice와 Pointcut을 한 개씩 가지고 있는 곳을 말한다. (조언자)
그리고 ProxyFactory는 Advisor가 필수이다. 근데 저번 포스팅에서는 Advisor를 안 사용했고 addAdvice()만 호출해서 Advice만 넘겼는데 이렇게 하면 기본 Advisor에 모든 곳에 적용하는 Pointcut으로 할당된다. 단순 편의 메서드인 것 뿐이다.
역할과 책임
이렇게 구분한 것은 역할과 책임을 명확하게 분리한 것이다.
포인트컷은 대상 여부를 확인하는 필터 역할만 담당한다.
어드바이스는 깔끔하게 부가 기능 로직만 담당한다.
둘을 합치면 어드바이저가 된다. 스프링의 어드바이저는 하나의 포인트컷 + 하나의 어드바이스로 구성된다.
위 그림은 이해를 돕기 위해 만들어진 그림이다. 실제 구현은 약간 다를 수 있지만, 흐름은 동일하다.
클라이언트가 프록시를 호출하면, 이 프록시는 먼저 Advice 적용 여부를 확인한다. 만약 적용되지 않았다면 부가 기능을 적용하지 않은 채로 실제 객체만 호출하고, 적용 대상이라면 부가 기능을 적용한다.
한번 Advisor, Advice, Pointcut을 적용해 보는 코드를 작성해보자.
예제 코드1 - 어드바이저
AdvisorTest
package cwchoiit.springadvanced.proxy.advisor;
import cwchoiit.springadvanced.proxy.common.advice.TimeAdvice;
import cwchoiit.springadvanced.proxy.common.service.ServiceImpl;
import cwchoiit.springadvanced.proxy.common.service.ServiceInterface;
import org.junit.jupiter.api.Test;
import org.springframework.aop.Pointcut;
import org.springframework.aop.framework.ProxyFactory;
import org.springframework.aop.support.DefaultPointcutAdvisor;
public class AdvisorTest {
@Test
void advisorTest1() {
ServiceInterface target = new ServiceImpl();
ProxyFactory proxyFactory = new ProxyFactory(target);
DefaultPointcutAdvisor advisor = new DefaultPointcutAdvisor(Pointcut.TRUE, new TimeAdvice());
proxyFactory.addAdvisor(advisor);
ServiceInterface proxy = (ServiceInterface) proxyFactory.getProxy();
proxy.save();
proxy.find();
}
}
이전 포스팅에서 사용했던 ServiceInterface와 TimeAdvice를 그대로 사용해보자. 그리고 이제 어드바이저를 만들어보자. 그 코드는 다음과 같다.
DefaultPointcutAdvisor advisor = new DefaultPointcutAdvisor(Pointcut.TRUE, new TimeAdvice());
Advisor 인터페이스의 가장 일반적인 구현체이다. 생성자를 통해 하나의 포인트컷과 하나의 어드바이스를 넣어주면 된다. 어드바이저는 하나의 포인트컷과 하나의 어드바이스로 구성된다.
Pointcut.TRUE는 항상 true를 반환하는 포인트컷이다. 즉, 모든곳에 프록시의 부가 기능이 적용이 된다는 의미이다.
proxyFactory.addAdvisor(advisor);
프록시팩토리에 적용할 어드바이저를 지정한다. 어드바이저는 내부에 포인트컷과 어드바이스를 모두 가지고 있다. 따라서 어디에 부가 기능을 적용해야 할지 어드바이저 하나로 알 수 있다. 프록시 팩토리를 사용할 때 어드바이저는 필수이다.
실행 결과
실행 결과를 보면, save(), find() 각각 모두 어드바이스가 적용된 것을 확인할 수 있다.
예제 코드2 - 직접 만든 포인트컷
이번에는, save() 메서드에는 어드바이스 로직을 적용하지만, find() 메서드에는 어드바이스 로직을 적용하지 않도록 해보자. 물론 과거에 했던 코드와 유사하게 어드바이스에 로직을 추가해서 메서드 이름을 보고 코드를 실행할지 말지 분기를 타도 된다. 하지만 이런 기능에 특화되어서 제공되는 것이 바로 포인트컷이다. 그리고 그렇게하면 어드바이스의 역할과 책임이 너무 많아진다(=유지보수가 안 좋아진다)
Pointcut 관련 인터페이스 - 스프링 제공
public interface Pointcut {
ClassFilter getClassFilter();
MethodMatcher getMethodMatcher();
}
public interface ClassFilter {
boolean matches(Class<?> clazz);
}
public interface MethodMatcher {
boolean matches(Method method, Class<?> targetClass);
//..
}
포인트컷은 크게 ClassFilter, MethodMatcher 둘로 이루어진다. 이름 그대로 하나는 클래스가 맞는지, 하나는 메서드가 맞는지 확인할 때 사용한다. 둘 다 true로 반환해야 어드바이스를 적용할 수 있다.
일반적으로 스프링이 이미 만들어둔 구현체를 사용하지만, 학습 차원에서 한번 간단히 직접 구현해보자.
@Test
@DisplayName("직접 만든 포인트컷")
void advisorTest2() {
ServiceInterface target = new ServiceImpl();
ProxyFactory proxyFactory = new ProxyFactory(target);
DefaultPointcutAdvisor advisor = new DefaultPointcutAdvisor(new MyPointcut(), new TimeAdvice());
proxyFactory.addAdvisor(advisor);
ServiceInterface proxy = (ServiceInterface) proxyFactory.getProxy();
proxy.save();
proxy.find();
}
/**
* 직접 만들일은 없음, 스프링이 만들어주는 Pointcut을 사용하면 되지만 한번 만들어보자.
* 클래스와 메서드 둘 다 'true' 를 리턴해야만 Pointcut에 적합한 요청이라고 판단하여 Advice를 적용한다.
* */
static class MyPointcut implements Pointcut {
/**
* 클래스를 기준으로 필터링
* ClassFilter.TRUE 를 반환하면 모든 클래스에 대해 Advice 적용을 허용
* */
@Override
public ClassFilter getClassFilter() {
return ClassFilter.TRUE;
}
/**
* 메서드를 기준으로 필터링
* MethodMatcher를 구현해야 한다.
* */
@Override
public MethodMatcher getMethodMatcher() {
return new MyMethodMatcher();
}
}
static class MyMethodMatcher implements MethodMatcher {
private String matchName = "save";
@Override
public boolean matches(Method method, Class<?> targetClass) {
boolean result = method.getName().equals(matchName);
log.info("포인트컷 호출 method = {} targetClass= {}", method.getName(), targetClass);
log.info("포인트컷 결과 result = {}", result);
return result;
}
@Override
public boolean isRuntime() {
return false;
}
@Override
public boolean matches(Method method, Class<?> targetClass, Object... args) {
return false;
}
}
MyPointcut
직접 구현한 포인트컷이다. Pointcut 인터페이스를 구현한다.
현재 메서드 기준으로 로직을 적용하면 된다. 클래스 필터는 항상 true를 반환하도록 했고, 메서드 비교 기능은 MyMethodMatcher를 사용한다.
MyMethodMatcher
직접 구현한 MethodMatcher이다. MethodMatcher 인터페이스를 구현한다.
matches() → 이 메서드에 method, targetClass 정보가 넘어온다. 이 정보로 어드바이스를 적용할지 적용하지 않을지 판단할 수 있다. 여기서는 메서드 이름이 'save'인 경우에 true를 반환하도록 판단 로직을 적용한다.
isRuntime(), matches(..., args) → isRuntime() 이 값이 true이면 matches(..., args) 메서드가 matches() 대신 호출된다. 동적으로 넘어오는 매개변수를 판단 로직으로 사용할 수 있다. isRuntime()이 false인 경우, 클래스의 정적 정보만 사용하기 때문에 스프링이 내부에서 캐싱을 통해 성능 향상이 가능하지만, isRuntime()이 true인 경우 매개변수가 동적으로 변경된다고 가정하기 때문에 캐싱을 하지 않는다. 크게 중요한 부분은 아니니 참고만 하자. 어차피 포인트컷을 직접 만들일은 없다.
위에서 모든 대상에 대해 Advice를 적용했던 예시 코드에 비교해서 바뀌는 부분은 딱 Pointcut이 달라지는것 말고 없다. 우리가 만든 MyPointcut을 전달한다. 대신 실행 결과가 달라질 것이다. 'save()'가 아닌 'find()'에는 Advice는 적용되지 않는다.
실행 결과
위 실행 결과의 흐름을 그림으로 비교해보자.
클라이언트가 프록시의 save()를 호출한다.
포인트컷에게 Service 클래스의 save() 메서드에 어드바이스를 적용해도 될지 물어본다.
포인트컷이 true를 반환한다. 따라서 어드바이스를 호출해서 부가 기능을 적용한다.
이후 실제 인스턴스의 save()를 호출한다.
클라이언트가 프록시의 find()를 호출한다.
포인트컷에게 Service 클래스의 find() 메서드에 어드바이스를 적용해도 될지 물어본다.
포인트컷이 false를 반환한다. 따라서 어드바이스를 호출하지 않고, 부가 기능도 적용되지 않는다.
실제 인스턴스를 호출한다.
예제 코드3 - 스프링이 제공하는 포인트컷
사실, 포인트컷을 저렇게 직접 구현해서 사용할 일은 앞으로 없다. 이미 스프링은 여러 포인트컷을 제공하고 있고 그 중 하나를 골라 사용하거나 결국엔 끝판왕인 AspectJExpressionPointcut을 사용하게 될 것이다. 한번 스프링이 제공하는 여러 포인트컷 중 하나를 골라서 사용해보자.
@Test
@DisplayName("스프링이 제공하는 포인트컷")
void advisorTest3() {
// 실제 객체 서비스
ServiceInterface target = new ServiceImpl();
// ProxyFactory 객체 생성 후 실제 객체를 전달
ProxyFactory proxyFactory = new ProxyFactory(target);
// 스프링이 제공하는 포인트 컷 중 하나인 NameMatchMethodPointcut
NameMatchMethodPointcut pointcut = new NameMatchMethodPointcut();
// Method 명이 save인 애들에게 Advice를 적용해주는 Pointcut을 만든다.
pointcut.setMappedName("save");
DefaultPointcutAdvisor advisor = new DefaultPointcutAdvisor(pointcut, new TimeAdvice());
// ProxyFactory에 advisor 추가
proxyFactory.addAdvisor(advisor);
// ProxyFactory 로부터 proxy 를 꺼내온다.
ServiceInterface proxy = (ServiceInterface) proxyFactory.getProxy();
// Pointcut에 의하여 Advice 적용된다.
proxy.save();
// Pointcut에 의하여 Advice 적용되지 않는다.
proxy.find();
}
스프링이 제공하는 NameMatchMethodPointcut을 사용해보자.
NameMatchMethodPointcut pointcut = new NameMatchMethodPointcut();
pointcut.setMappedName("save");
말 그대로 메서드의 이름으로 Pointcut을 설정하는 Pointcut이다. 위 코드처럼 'save'라는 값을 setMappedName()에 넘겨주면 이 Pointcut은 'save'라는 메서드명을 가진 요청에 한하여 Advice를 적용한다. 나머지는 동일하다.
실행 결과
save()가 호출됐을 땐 TimeProxy가 동작하고 그렇지 않은 find()가 호출됐을 땐 Advice가 적용되지 않았다. 이렇게 스프링이 제공해주는 Pointcut으로 편리하게 Pointcut을 만들 수 있다.
예제 코드4 - 여러 어드바이저 함께 적용
어드바이저는 하나의 포인트컷과 하나의 어드바이스를 가지고 있다. 만약, 여러 어드바이저를 하나의 target에 적용하려면 어떻게 해야할까? 쉽게 이야기해서 하나의 target에 여러 어드바이스를 적용하려면 어떻게 해야할까? 지금 떠오르는 방법은 프록시를 여러개 만들면 될 것 같다.
프록시 여러개로 구현
package cwchoiit.springadvanced.proxy.advisor;
import cwchoiit.springadvanced.proxy.common.advice.TimeAdvice;
import cwchoiit.springadvanced.proxy.common.service.ServiceImpl;
import cwchoiit.springadvanced.proxy.common.service.ServiceInterface;
import lombok.extern.slf4j.Slf4j;
import org.aopalliance.intercept.MethodInterceptor;
import org.aopalliance.intercept.MethodInvocation;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.aop.Pointcut;
import org.springframework.aop.framework.ProxyFactory;
import org.springframework.aop.support.DefaultPointcutAdvisor;
@Slf4j
public class MultiAdvisorTest {
@Test
@DisplayName("여러 프록시")
void multiAdvisorTest1() {
ServiceInterface target = new ServiceImpl();
ProxyFactory proxyFactory1 = new ProxyFactory(target);
DefaultPointcutAdvisor advisor1 = new DefaultPointcutAdvisor(Pointcut.TRUE, new Advice1());
proxyFactory1.addAdvisor(advisor1);
ServiceInterface proxy1 = (ServiceInterface) proxyFactory1.getProxy();
ProxyFactory proxyFactory2 = new ProxyFactory(proxy1);
DefaultPointcutAdvisor advisor2 = new DefaultPointcutAdvisor(Pointcut.TRUE, new Advice2());
proxyFactory2.addAdvisor(advisor2);
ServiceInterface proxy2 = (ServiceInterface) proxyFactory2.getProxy();
proxy2.find();
}
static class Advice1 implements MethodInterceptor {
@Override
public Object invoke(MethodInvocation invocation) throws Throwable {
log.info("Advice1 invoked");
return invocation.proceed();
}
}
static class Advice2 implements MethodInterceptor {
@Override
public Object invoke(MethodInvocation invocation) throws Throwable {
log.info("Advice2 invoked");
return invocation.proceed();
}
}
}
코드상에 새로운 개념은 없다. 프록시를 여러개 입혔다.
실행 결과
11:35:11.287 [Test worker] INFO cwchoiit.springadvanced.proxy.advisor.MultiAdvisorTest -- Advice2 invoked
11:35:11.289 [Test worker] INFO cwchoiit.springadvanced.proxy.advisor.MultiAdvisorTest -- Advice1 invoked
11:35:11.289 [Test worker] INFO cwchoiit.springadvanced.proxy.common.service.ServiceImpl -- find 호출
차례대로 Advice2, Advice1이 실행된다. 그리고 실제 객체인 target의 로직까지 실행됐다.
그러나, 이 방법이 잘못된 것은 아니지만 프록시를 2번 생성해야 한다는 문제가 있다. 만약 적용해야 하는 어드바이저가 10개라면 10개의 프록시를 생성해야 한다.
하나의 프록시, 여러 어드바이저로 구현
스프링은 이 문제를 해결하기 위해 하나의 프록시에 여러 어드바이저를 적용할 수 있게 만들어 두었다.
@Test
@DisplayName("하나의 프록시, 여러 어드바이저")
void multiAdvisorTest2() {
DefaultPointcutAdvisor advisor1 = new DefaultPointcutAdvisor(Pointcut.TRUE, new Advice1());
DefaultPointcutAdvisor advisor2 = new DefaultPointcutAdvisor(Pointcut.TRUE, new Advice2());
ServiceInterface target = new ServiceImpl();
ProxyFactory proxyFactory = new ProxyFactory(target);
proxyFactory.addAdvisors(advisor2, advisor1);
ServiceInterface proxy = (ServiceInterface) proxyFactory.getProxy();
proxy.find();
}
프록시 팩토리에 원하는 어드바이저를 addAdvisors(...)로 등록하면 끝이다. 먼저 넣은 어드바이저가 먼저 실행된다.
정리
결과적으로, 여러 프록시를 사용할 때와 비교해서 결과는 같으나 성능은 더 좋다. 스프링 AOP도 이와 같다. AOP 적용 수만큼 프록시가 생성되는 것이 아니다! 스프링은 AOP를 적용할 때, 최적화를 진행해서 지금처럼 프록시는 하나만 만들고, 하나의 프록시에 여러 어드바이저를 적용한다. 정리하면 하나의 target에 여러 AOP가 적용되어도, 스프링의 AOP는 target마다 하나의 프록시만 생성한다. 꼭 기억하자!
프록시팩토리 - 적용1
지금까지 학습한 프록시 팩토리를 사용해서 애플리케이션에 프록시를 만들어보자. 먼저 인터페이스가 있는 V1 애플리케이션에 LogTrace 기능을 프록시 팩토리를 통해서 프록시를 만들어 적용해보자.
Advice를 만들기 위해 MethodInterceptor를 구현하는 LogTraceAdvice 클래스를 만들었다. MethodInterceptor가 구현해야 하는 invoke()를 기존에 계속 사용했던 LogTrace 기능으로 채워넣었다. Advice는 실제 객체를 주입받지 않아도 되기 때문에 편리함을 준다.
이제 Advice를 만들었으니까 ProxyFactory를 통해서 프록시를 만들고 스프링 빈으로 등록해보자.
끝이다. Advice도 Pointcut도 이미 만들어 놓은거니까 가져다가 사용만 하면 된다.
'/v2/request' 로 요청하면 마찬가지로 LogTrace의 정보를 출력한다.
정리
확실히 프록시로 사용될 코드도 Advice 하나만 만들면 되고, 동적 프록시를 만들기 때문에 프록시를 일일이 만들어 줄 필요도 없으며 구체클래스냐 인터페이스냐에 따라 나뉘어지는 동적 프록시 생성 방법을 스프링의 도움을 받아 프록시 팩토리를 사용하므로써 고민하지 않게됐다.
훨씬 개선되었지만 여전히 불편함은 남아있다.
너무 많은 설정 - ProxyFactoryConfigV1, ProxyFactoryConfigV2와 같이 설정 파일이 지나치게 많다. 예를 들어, 애플리케이션에 스프링 빈이 100개가 있다면 여기에 프록시를 통해 부가 기능을 적용하려면 100개의 동적 프록시 생성 코드를 만들어야 한다. 무수히 많은 설정 파일 때문에 설정 지옥을 경험하게 될 것이다. 최근에는 스프링 빈을 수동으로 등록하는 케이스보다 컴포넌트 스캔을 사용하는게 일반적인데 이렇게 직접 등록하는 것도 모자라서 프록시를 적용하는 코드까지 빈 생성 코드에 넣어야 한다.
컴포넌트 스캔 - 애플리케이션 V3처럼 컴포넌트 스캔을 사용하는 경우, 지금까지 학습한 방법으로는 프록시 적용이 불가능하다. 왜냐하면 실제 객체를 컴포넌트 스캔으로 스프링 컨테이너에 스프링 빈으로 등록을 다 해버린 상태이기 때문이다. 지금까지 학습한 방법으로 프록시를 적용하려면, 실제 객체를 스프링 컨테이너에 빈으로 등록하는 것이 아니라, ProxyFactoryConfigV2에서 한 것처럼, 부가 기능이 있는 프록시를 실제 객체 대신 스프링 컨테이너에 빈으로 등록해야 한다.
