@Aspect AOP, @Aspect 프록시(적용/설명), 스프링 AOP 개념, AOP 소개(핵심 기능과 부가 기능/Aspect), AOP 적용 방식, AOP 용어 정리

출처 : 인프런 - 스프링 핵심 원리 - 고급편 (유료) / 김영한님  
유료 강의이므로 정리에 초점을 두고 코드는 일부만 인용

---

1. @Aspect 프록시 - 적용

1) 적용

• 스프링은 @Aspect애노테이션으로 매우 편리하게 포인트컷과 어드바이스로 구성되어있는 어드바이저 생성 기능을 지원함
• 직접 어드바이저를 만들었던 부분을 @AspectJ 애노테이션을 사용해서 생성

** 참고

• @Aspect는 관점 지향 프로그래밍(AOP)을 가능하게 하는 AspectJ 프로젝트에서 제공하는 애노테이션이며 스프링은 이것을 차용해서 프록시를 통한 AOP를 가능하게 함
• AOP와 AspectJ 관련한 자세한 내용은 다음에 설명하며 지금은 프록시에 초점을 맞춰 이 애노테이션을 사용해서 스프링이 편리하게 프록시를 만들어 준다고 생각하면됨

(1) LogTraceAspect

• config하위에 v6_aop.aspect 패키지를 생성 후 작성
• @Aspect: 애노테이션 기반 프록시를 적용할 때 필요함
• @Around() : 애노테이션 값으로 AspectJ 표현식을 사용하여 포인트컷 표현식을 입력, 해당 애노테이션이 적용된 메서드는 어드바이스가 됨
• ProceedingJoinPoint joinPoint : 어드바이스에서 살펴본 MethodInvocation invocation과 유사한 기능이며 내부에 실제 호출 대상, 전달 인자, 어떤 객체와 어떤 메서드가 호출되었는지에 대한 정보가 포함되어있음
• joinPoint.proceed()로 실제 호출 대상(target)을 호출함

package hello.proxy.config.v6_aop.aspect;

@Slf4j
@Aspect
public class LogTraceAspect {

    private final LogTrace logTrace;

    public LogTraceAspect(LogTrace logTrace) {
        this.logTrace = logTrace;
    }
	
    /**
     * 어드바이저 생성
     */
    // 포인트컷 적용
    @Around("execution(* hello.proxy.app..*(..)) && !execution(* hello.proxy.app..noLog(..))")
    public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {

        // 어드바이스 적용 (로직)
        TraceStatus status = null;
    
        log.info("target={}", joinPoint.getTarget());   // 실제 호출 대상
        log.info("getArgs={}", joinPoint.getArgs());    // 전달 인자
        log.info("getSignature={}", joinPoint.getSignature());  // joinPoint 시그니처
        
        try {
            // joinPoint에서 정보를 꺼내서 message를 생성
            String message = joinPoint.getSignature().toShortString();
            status = logTrace.begin(message);

            Object result = joinPoint.proceed();   // 실제 비즈니스 로직 동작

            logTrace.end(status);
            return result;
        } catch (Exception e) {
            logTrace.exception(status, e);
            throw e;
        }
    }
}

 

(2) AopConfig 생성 / ProxyApplication 수정

• AopConfig 설정파일을 생성하여 V1, V2 애플리케이션의 설정파일을 @Import로 스프링 빈 등록
• @AspectJ가 있어도 스프링빈으로 등록해주어야 하기에 @Bean을 통해서 LogTraceAspect를 스프링 빈으로 등록
• 물론 LogTraceAspect자체에 @Component를 적용하여 자동 스프링빈 등록을 해주어도 됨
• ProxyApplication에서 AopConfig를 @Import하여 스프링빈으로 등록한 후 애플리케이션을 실행해보면 프록시가 잘 적용되어 컨트롤러의 모든 매핑 url에 접속했을 때 로그 추적기가 정상 동작함

package hello.proxy.config.v6_aop;

@Configuration
@Import({AppV1Config.class, AppV2Config.class})
public class AopConfig {

    @Bean
    public LogTraceAspect logTraceAspect(LogTrace logTrace) {
        return new LogTraceAspect(logTrace);
    }
}

@Import(AopConfig.class)
@SpringBootApplication(scanBasePackages = "hello.proxy.app.v3") //주의
public class ProxyApplication {

    // 기존 코드 생략
}

2) 설명

(1) 자동 프록시 생성기

• 자동 프록시 생성기(AnnotationAwareAspectJAutoProxyCreator)는 Advisor를 자동으로 찾아와서 필요한 곳에 프록시를 생성하고 적용한다고 배웠음
• 자동 프록시 생성기는 여기에 추가로 하나의 역할을 더 하는데 @Aspect를 찾아서 이것을 Advisor로 만들어줌
• 즉, 지금까지 학습한 기능 + @Aspect를 Advisor로 변환하여 저장하는 기능이 포함된 것이라고 보면되며 자동 프록시 생성기의 이름이 AnnotationAware(애노테이션을 인식하는)가 붙어있는 것임

@Aspect의 어드바이저 구성

(2) 자동 프록시 생성기는 2가지 일을 함

1. @Aspect를 보고 어드바이저로 변환해서 저장
2. 어드바이저를 기반으로 프록시를 생성

(3) @Aspect를 어드바이저로 변환해서 저장하는 과정

• 1. 실행: 스프링 애플리케이션 로딩 시점에 자동 프록시 생성기를 호출
• 2. 모든 @Aspect 빈 조회: 자동 프록시 생성기는 스프링 컨테이너에서 @Aspect 애노테이션이 붙은 스프링 빈을 모두 조회함
• 3. 어드바이저 생성: @Aspect 어드바이저 빌더를 통해 @Aspect 애노테이션 정보를 기반으로 어드바이저를 생성
• 4. @Aspect 기반 어드바이저 저장: 생성한 어드바이저를 @Aspect 어드바이저 빌더 내부에 저장함

 

(4) Aspect 어드바이저 빌더

• BeanFactoryAspectJAdvisorsBuilder 클래스
• @Aspect의 정보를 기반으로 포인트컷, 어드바이스, 어드바이저를 생성하고 보관하는 것을 담당함
• @Aspect의 정보를 기반으로 어드바이저를 만들고 @Aspect 어드바이저 빌더 내부 저장소에 캐시하고 이미 캐시에 어드바이저가 만들어져있는 경우 캐시에 저장된 어드바이저를 반환함

(5) 어드바이저를 기반으로 프록시 생성

• 1. 생성: 스프링 빈 대상이 되는 객체를 생성(@Bean, 컴포넌트 스캔 모두 포함)
• 2. 전달: 생성된 객체를 빈 저장소에 등록하기 직전에 빈 후처리기에 전달
• 3-1. Advisor 빈 조회: 스프링 컨테이너에서 Advisor빈을 모두 조회
• 3-2. @Aspect Advisor 조회: @Aspect어드바이저 빌더 내부에 저장된 Advisor를 모두 조회
• 4. 프록시 적용 대상 체크: 3-1,3-2에서 조회한 Advisor에 포함되어있는 포인트컷을 사용해서 해당 객체가 프록시를 적용할 대상인지 아닌지를 판단, 이때 객체의 클래스 정보와 해당 객체의 모든 메서드를 포인트컷에 하나하나 모두 매칭해보고 조건이 하나라도 만족하면 프록시 대상으로 적용됨
• 5. 프록시 생성: 프록시 적용 대상이면 프록시를 생성하고 프록시를 반환, 프록시 적용 대상이 아니라면 원본 객체를 반환
• 6. 빈 등록: 반환된 객체들은 스프링 빈으로 등록됨

** 참고

• @Aspect를 사용한 클래스에도 @Around가 적용된 메서드의 이름만 다르게 하면 여러 개의 어드바이저를 생성하여 적용할 수 있음

3) 정리

(1) 횡단 관심사(cross-cutting concerns)

• @Aspect를 사용해서 애노테이션 기반 프록시를 매우 편리하게 적용할 수 있었으며 실무에서는 프록시를 적용할 때 대부분 이방식을 사용함
• 지금까지 우리가 진행한 애플리케이션 전반에 로그를 남기는기능은 특정 기능 하나에 관심있는 기능이 아니라 애플리케이션의 여러 기능들 사이에 걸쳐 들어가는 관심사임
• 이것을 횡단 관심사라고하며 지금까지 학습한 내용은 이렇게 여러곳에 걸쳐있는 횡단 관심사의 문제를 해결하는 방법이었음
• 프록시를 사용하여 이러한 횡단 관심사를 어떻게 해결하는지 점진적으로 매우 깊이있게 학습하고 기반들 다졌으며, 이후의 학습은 이 기반을 바탕으로 횡단 관심사를 전문으로 해결하는 스프링 AOP를 본격적으로 학습을 진행함

---

2. AOP 소개

1) 핵심 기능과 부가 기능

• 애플리케이션 로직은 크게 핵심 기능과 부가 기능으로 나눌 수 있음

(1) 핵심 기능

• 해당 객체가 제공하는 고유의 기능
• 예를 들어 OrderService의 핵심기능은 주문 로직임

(2) 부가 기능

• 핵심 기능을 보조하기 위해 제공되는 기능
• 로그 추적 로직, 트랜잭션과 같은 기능을 예로들 수 있으며, 이러한 부가기능은 단독으로 사용되지 않고 핵심 기능과 함께 사용됨
• 당연히 로그 추적 기능은 어떤 핵심 기능이 호출되었는지 로그를 남기기 위해 사용되기 때문에 부가 기능은 핵심 기능을 보조하기 위해서 존재함

(3) 핵심 기능과 부가 기능이 함께 있음

• 주문 로직을 실행하기 직전에 로그 추적 기능을 사용해야 한다면 핵심 기능인 주문 로직과 부가 기능인 로그 추적 로직이 하나의 객체 안에 섞여 들어갈 수밖에 없음
• 즉, 부가 기능이 필요한 경우 부가 기능과 핵심 기능을 합해서 하나의 로직을 완성하게 되고 주문 서비스를 실행하면 핵심 기능인 주문 로직과 부가 기능인 로그 추적 로직이 함께 동작하게 됨

좌) orderService의 주문 로직은 핵심기능 / 우) 부가기능과 핵심기능이 함께 있음

 

(4) 여러 곳에서 공통으로 사용하는 부가 기능

부가 기능은 보통 애플리케이션 전반에 걸쳐있는 횡단 관심사임

• 보통 부가기능은 여러 클래스에 걸쳐서 함께 사용됨
• 애플리케이션 호출을 로깅해야하는 요구사항을 생각해보면 애플리케이션 전반에 걸쳐서 함께 사용되며 이러한 부가기능은 횡단 관심사(cross-cutting concerns)라고하며 하나의 부가 기능이 여러 곳에 동일하게 사용됨

(5) 부가 기능 적용 문제

• 이런 부가 기능을 여러 곳에 적용하려면 매우 번거로운데, 위처럼 프록시가 없이 부가 기능과 핵심기능을 합쳐서 하나의 로직으로 구현해야 한다면 핵심 로직을 담당하는 클래스가 100개라면 100개에 모두 동일한 부가 기능을 추가해야함
• 부가 기능을 별도의 유틸리티 클래스로 만든다고 해도 유틸리티 클래스를 호출하는 코드가 필요하며, 부가 기능이 구조적으로 단순 호출이 아니라 실행 시간 측정 로직과 같이 try - catch - finally 같은 구조가 필요하면 더욱 복잡해짐
• 더욱 큰 문제는 수정(유지 보수)인데, 부가 기능에 수정이 발생하면 100개의 클래스를 모두를 하나씩 찾아가서 수정해얌
• 만약 추가로 모든 계층의 클래스에 적용했다가 로그가 너무 많아 서비스 계층에만 적용한다고 수정하게되면 수 많은 컨트롤러, 리포지토리 클래스의 코드를 고쳐야할 것임

(6) 문제 정리

• 부가 기능을 적용할 때 아주 많은 반복이 필요함
• 부가 기능이 여러 곳에 퍼져서 중복 코드를 만들어냄
• 부가 기능을 변경할 때 중복 때문에 많은 수정이 필요함
• 부가 기능의 적용 대상을 변경할 때 많은 수정이 필요함
• 소프트웨어 개발에서 변경 지점은 하나가 될 수 있도록 잘 모듈화 되어야하는데 부가 기능처럼 특정 로직을 애플리케이션 전반에 적용하는 문제는 일반적인 OOP 방식으로는 해결이 어려움

2) AOP - 애스펙트(Aspect)

(1) 핵심 기능과 부가 기능을 분리

• 누군가는 이러한 부가 기능 도입의 문제점을 해결하기 위해 오랜기간 고민해왔고 그 결과 부가 기능을 핵심 기능에서 분리하고 한 곳에서 관리하고 해당 부가 기능을 어디에 적용할지 선택하는 기능도 만들었음
• 이것이 바로 애스펙트(Aspect)이며 부가 기능과 해당 부가 기능을 어디에 적용할지 모듈화하여 만들고 정의한 것임
• @Aspect 애노테이션으로 사용했던것이 바로 애스펙트이며 스프링이 제공하는 어드바이저도 어드바이스와 포인트컷을 가지고 있으므로 개념상 하나의 애스펙트임
• 애스펙트는 우리말로 해석하면 관점이라는 뜻인데 이름 그대로 애플리케이션을 바라보는 관점을 하나하나의 기능에서 횡단 관심사관점으로 달리 보는 것임
• 이렇게 애스펙트를 사용한 프로그래밍 방식을 관점 지향 프로그래밍(AOP; Aspect-Oriented Programming)이라함

** 참고

• AOP는 OOP를 대체하기 위해 개발된 것이 아니라 횡단 관심사를 깔끔하게 처리하기 어려운 OOP의 부족한 부분을 보조하는 목적으로 개발되었음

핵심로직에 AOP로 부가기능을 적용한 구상도

(2) AspectJ 프레임워크

• AOP의 대표적인 구현으로 AspectJ 프레임워크가 있음, 공식URL
• 물론 스프링도 AOP를 지원하지만 대부분 AspectJ 문법을 차용한 것으로 AspectJ가 제공하는 기능의 일부만 제공함
• 즉, AspectJ 프레임워크를 직접 사용해도되고 스프링 AOP를 사용해도 되며 적용방식에 대한 차이가 있음

(3) AspectJ 프레임워크 설명

• 자바 프로그래밍 언어에 대한 완벽한 관점 지향 확장
• 횡단 관심사의 깔끔한 모듈화(오류 검사 및 처리 - validation기능  / 동기화 / 성능 최적화 - 캐싱 / 모니터링 및 로깅)

---

3. AOP 적용 방식

1) 컴파일 시점에 적용

(1) 컴파일 타임 - 위빙

• .java 소스 코드를 컴파일러를 사용해서 .class를 만드는 시점에 부가 기능 로직을 추가할 수 있음
• 이때는 AspectJ가 제공하는 특별한 컴파일러를 사용해야하며 컴파일 된 .class를 디컴파일 해보면 애스펙트 관련 호출 코드가 들어가있음
• 즉, 부가 기능 코드가 핵심 기능이 있는 컴파일된 코드 주변에 실제로 붙어 버린다고 생각하면됨
• AspectJ 컴파일러는 Aspect를 확인하여 해당 클래스가 적용 대상인지 먼저 확인하고 적용 대상인 경우에 부가 기능 로직을 적용함

** 참고

• 원본 로직에 부가 기능 로직이 추가되는 것을 위빙(Weaving)이라함
• 위빙은 옷감을 짜다, 직조하다라는 뜻이며 애스펙트와 실제 코드를 연결해서 붙인다라고 보면 됨

(2) 단점

• 컴파일 시점에 부가 기능을 적용하기위한 특별한 컴파일러가 필요하고 복잡하기 때문에 잘 사용하지 않음

2) 클래스 로딩 시점

(1) 로드 타임 - 위빙

• 자바를 실행하면 자바는 .class 파일을 JVM 내부의 클래스 로더에 보관하는데 이때 중간에서 .class파일을 조작한 다음 JVM에 올릴 수 있음
• 자바는 .class를 JVM에 저장하기 전에 조작할 수 있는 기능을 제공하며 해당 기능에 대해서 궁금하다면 java Instrumentation을 검색해보면 됨
• 수많은 모니터링 툴들이 이 방식을 사용하며 이 시점에 애스펙트를 적용하는 것을 로드 타임 위빙이라함

(2) 단점

• 로드 타임 위빙은 자바를 실행할 때 특별한 옵션(java -javaagent)을 통해 클래스 로더 조작기를 지정해야하는데 이부분이 번거롭기도 하고 운영하기도 어려움, 즉 잘 사용하지 않음

3) 런타임 시점(프록시)

(1) 런타임 - 위빙

• 런타임 시점은 컴파일도 전부 끝나고 클래스 로더에 클래스도 다 올라가서 이미 자바가 실행하고 난 다음을 말하며 자바의 메인(main)메서드가 이미 실행된 다음이기 때문에 자바 언어가 제공하는 범위 안에서 부가 기능을 적용해야함
• 스프링과 같은 컨테이너의 도움을 받고 프록시와 DI, 빈 포스트 프로세서 같은 개념들을 활용하여 최종적으로 프록시를 통해 스프링 빈에 부가 기능을 적용할 수 있으며 지금까지 배워온 방식이 프록시 방식의 AOP임
• 프록시를 사용하기 때문에 AOP기능에 일부 제약이 있으나 특별한 컴파일러를 이용해야하거나 자바를 실행할 때 복잡한 옵션과 클래스 로더 조작기를 설정하지 않아도 되기 때문에 스프링만 있으면 얼마든지 편리하게 AOP를 이용할 수 있음

4) 부가 기능이 적용되는 차이 정리

(1) 컴파일 시점 / 클래스 로딩 시점

• 실제 대상 코드에 애스펙트를 통한 부가 기능 호출 코드가 포함됨
• AspectJ를 직접 사용해야함 

(2) 런타임 시점

• 실제 대상 코드는 그대로 유지되며 프록시를 통해 부가 기능이 적용됨
• 항상 프록시를 통해야 부가 기능을 사용할 수 있으며 스프링 AOP가 이 방식을 사용함

5) AOP 적용 위치

(1) 적용 가능 지점(조인 포인트)

• 지금까지 학습한 메서드 실행 위치 뿐만 아니라 생성자, 필드 값 접근, static 메서드 접근 등 다양한 위치에 AOP를 적용할 수 있으며, AOP를 적용할 수 있는 지점을 조인 포인트(Join Point)라고함
• AspectJ를 사용해서 컴파일 시점과 클래스 로딩 시점에 적용하는 AOP는 바이트코드를 실제 조작하기 때문에 해당 기능을 모든 지점에 적용할 수 있음
• 프록시 방식을 사용하는 스프링 AOP는 메서드 실행 지점에만 AOP를 적용할 수 있음
• 프록시는 메서드 오버라이딩 개념으로 동작하기때문에 생성자나 static 메서드, 필드 값 접근에는 프록시 개념이 적용될 수 없어 프록시를 사용하는 스프링 AOP의 조인 포인트는 메서드 실행으로 제한됨
• 스프링 AOP는 스프링 컨테이너가 관리할 수 있는 스프링 빈에만 AOP를 적용할 수 있음

** 참고

• 스프링은 AspectJ를 직접 사용하는것이 아니라 AspectJ의 문법을 차용하고 프록시 방식의 AOP를 적용함

** 중요

• 스프링이 제공하는 AOP는 프록시를 사용하기에 프록시를 통해 메서드를 실행하는 시점에만 AOP가 적용되지만 AspectJ를 사용하면 훨씬더 복잡하고 다양한 기능을 사용할 수 있는데, 직접 AspectJ를 사용하는 것이 더 좋을것이라고 생각할 수 있음
• 그러나 AspectJ는 정말 많은 기능을 지원하기에 사용하려면 공부할 내용이 많고 자바 관련 설정(특별한 컴파일러, AspectJ 전용 문법, 자바 실행 옵션)도 매우 복잡하기에 운영하기가 매우 어려움
• 반면 스프링 AOP는 별도의 추가 설정없이 스프링만 있으면 매우 편리하게 AOP를 사용할 수 있으며 실무에서는 스프링이 제공하는 AOP기능만으로도 대부분의 문제를 해결할 수 있기 때문에 스프링이 제공하는 AOP의 기능을 학습하는 것에 집중하는것을 권장함

---

4. AOP 용어 정리

AOP 용어 모음

(1) 조인 포인트(Join Point)

• 어드바이스가 적용될 수 있는 위치, 메소드 실행, 생성자 호출, 필드 값 접근, static 메서드 접근 같은 프로그램 실행 중 지점
• 조인 포인트는 추상적인 개념으로 AOP를 적용할 수 있는 모든 지점이라 생각하면됨
• 스프링 AOP는 프록시 방식을 사용하므로 조인 포인트는 항상 메소드 실행 지점으로 제한됨

(2) 포인트컷(Pointcut)

• 조인 포인트 중에서 어드바이스가 적용될 위치를 선별하는 기능
• 주로 AspectJ 표현식을 사용하여 지정
• 프록시를 사용하는 스프링 AOP는 메서드 실행 지점만 포인트컷으로 선별 가능

(3) 타겟(Target)

• 어드바이스를 받는 객체(실제 객체)
• 포인트컷으로 결정

(4) 어드바이스(Advice)

• 부가 기능
• 특정 조인 포인트에서 Aspect에 의해 취해지는 조치
• Around(주변), Before(전), After(후)와 같은 다양한 종류의 어드바이스가 있음

(5) 애스펙트(Aspect)

• 어드바이스 + 포인트컷을 모듈화한 것으로 @Aspect라고 생각하면 됨
• 여러 어드바이스와 포인트 컷이 함께 존재함

(6) 어드바이저(Advisor)

• 하나의 어드바이스와 하나의 포인트컷으로 구성
• 스프링 AOP에서만 사용되는 특별한 용어

(7) 위빙(Weaving)

• 포인트컷으로 결정한 타겟의 조인 포인트에 어드바이스를 적용하는 것
• 위빙을 통해 핵심 기능 코드에 영향을 주지 않고 부가 기능을 적용할 수 있음
• AOP 적용을 위해 애스펙트를 객체에 연결한 상태
• 컴파일 타임 위빙, 로드 타임 위빙, 런타임 위빙이 있으며 스프링 AOP는 런타임 위빙이며 프록시 방식으로 적용함

(8) AOP 프록시

• AOP 기능을 구현하기 위해 만든 프록시 객체
• 스프링에서 AOP 프록시는 JDK 동적 프록시 또는 CGLIB 프록시임