내가 공부한것을 올리며, 중요한 단원은 저 자신도 곱씹어 볼겸 상세히 기록하고 얕은부분들은 가겹게 포스팅 하겠습니다.
1. AOP 소개 - 핵심 기능과 부가 기능
애플리케이션 로직은 크게 핵심 기능과 부가 기능으로 나눌 수 있다.
1) 핵심 기능
해당 객체가 제공하는 고유의 기능이다. 예를 들어서 OrderService 의 핵심 기능은 주문 로직이다.
2) 부가 기능
핵심 기능을 보조하기 위해 제공되는 기능이다. 예를 들어서 로그 추적 로직, 트랜잭션 기능이 있다. 이러한 부가 기능은 단독으로 사용되지 않고, 핵심 기능과 함께 사용된다.
주문 로직을 실행하기 직전에 로그 추적 기능을 사용해야 하면, 핵심 기능인 주문 로직과 부가 기능인 로그 추적 로직이 하나의 객체 안에 전부 모여있다.
부가 기능이 필요한 경우 이렇게 둘을 합해서 하나의 로직을 완성한다.
이제 주문 서비스를 실행하면 핵심 기능인 주문 로직과 부가 기능인 로그 추적 로직이 함께 실행된다.
따라서 다음과 같이 여러곳에 공통 로직이 포함되게 돤다. 중복이 너무 많아지는 것 이다.
보통 부가기능은 여러 클래스에서 공통으로 가져다가 사용한다.
예를 들어서 모든 애플리케이션 호출을 로깅 해야 하는 요구사항을 생각해보자.
이러한 부가 기능은 횡단 관심사(cross-cutting concerns)가 된다.
쉽게 이야기해서 하나의 부가 기능이 여러 곳에 동일하게 사용된다는 뜻이다.
이러한 부가기능 적용에 몇가지 문제가 있다.
부가 기능을 여러 곳에 적용하려면 너무 번거롭다. 예를 들어서 부가 기능을 적용해야 하는 클래스가 100개면 100개 모두에 동일한 코드를 추가해야 한다.
해당 부가기능을 Utils 성 class의 메서드로 만들어도, 해당 유틸 메서드를 호출하는 부분이 100곳에 모두 동일하게 들어가야 한다.
더 큰 문제는 수정이다. 만약 부가 기능에 수정이 발생하면, 100개의 클래스 모두를 하나씩 찾아가면서 수정해야 한다.
더 나아가 부가 기능이 적용되는 위치를 변경한다면 어떻게 될까?
예를 들어서 부가 기능을 모든 컨트롤러, 서비스, 리포지토리에 적용했다가, 로그가 너무 많이 남아서 서비스 계층에만 적용한다고 수정해야하면 어떻게 될까?
또 수 많은 코드를 고쳐야 할 것이다.
부가 기능 적용 문제를 정리하면 다음과 같다.
- 부가 기능을 적용할 때 아주 많은 반복이 필요하다.
- 부가 기능이 여러 곳에 퍼져서 중복 코드를 만들어낸다.
- 부가 기능을 변경할 때 중복 때문에 많은 수정이 필요하다.
- 부가 기능의 적용 대상을 변경할 때 많은 수정이 필요하다.
소프트웨어 개발에서 변경 지점은 하나가 될 수 있도록 잘 모듈화 되어야 한다. 즉, 단일책임원칙을 지키도록 하는것이 좋다.
그런데 부가 기능처럼 특정 로직을 애플리케이션 전반에 적용하는 문제는 일반적인 OOP 방식으로는 해결이 어렵다.
이를 AOP를 통해 다음 단락부터 해결해보자.
2. AOP 소개 - 애스펙트
부가 기능과 부가 기능을 어디에 적용할지 선택하는 기능을 합해서 하나의 모듈로 만든것이 바로 애스펙트(aspect)이다.
우리가 직전에 알아본 @Aspect가 바로 그러한 역할을 해준다.
또한 Spring이 제공하는 Advisor(Pointcut + Advice) 또한 개념상 하나의 aspect 이다.
Aspect의 뜻은 관점으로, 애플리케이션을 바라보는 관점을 하나하나의 기능에서 횡단 관심사(cross-cutting concerns)로 바라보는 것 이다.
애스펙트를 사용한 프로그래밍 방식을 관점 지향 프로그래밍 AOP(Aspect-Oriented Programming)
참고로 AOP는 OOP의 대체용도 가 아닌, OOP의 단점을 보완하는 개념이다.
이러한 관점지향 프로그래밍을 도와주는 도구로 AspectJ 가 있다.
물론 스프링도 AOP를 지원하지만 대부분 AspectJ의 문법을 차용하고, AspectJ가 제공하는 기능의 일부만 제공한다.
AspectJ 프레임워크는 스스로를 다음과 같이 설명한다.
- 자바 프로그래밍 언어에 대한 완벽한 관점 지향 확장
- 횡단 관심사의 깔끔한 모듈화
- 오류 검사 및 처리
- 동기화
- 성능 최적화(캐싱)
- 모니터링 및 로깅
3. AOP 적용 방식
AOP를 적용하여 부가기능을 추가하는 로직은 크게 3가지가 가능하다.
- 컴파일 시점
- 클래스 로딩 시점
- 런타임 시점(프록시)
3-1) 컴파일 시점
.java 소스 코드를 컴파일러를 사용해서 .class 를 만드는 시점에 부가 기능 로직을 추가할 수 있다.
AspectJ가 제공하는 특별한 컴파일러를 사용해야 한다.
AspectJ 컴파일러는 Aspect를 확인해서 해당 클래스가 적용 대상인지 먼저 확인하고, 적용 대상인 경우에 부가 기능 로직을 적용한다.
컴파일 된 .class 를 디컴파일 해보면 애스펙트 관련 호출 코드가 들어간다.
간단히 부가기능 코드들이 컴파일 된 핵심기능 코드에 추가되어 버린다.
이렇게 원본 로직에 부가 기능 로직이 추가되는 것을 위빙(Weaving)이라 한다.
▶ 컴파일 시점 - 단점
컴파일 시점에 부가 기능을 적용하려면 특별한 컴파일러도 필요하고 복잡하다.
3-2) 클래스 로딩 시점
보통 컴파일된 .class 파일은 JVM 내부의 클래스 로더에서 보관한다.
이때 중간에서 .class 파일을 조작한 다음 JVM에 올릴 수 있다.
자바 언어는 .class 를 JVM에 저장하기 전에 java Instrumentation 을 통하여 조작할 수 있는 기능을 제공한다.
이 시점에 애스펙트를 적용하는 것을 로드 타임 위빙 이라 부른다.
▶ 클래스 로딩 시점 - 단점
로드 타임 위빙은 자바를 실행할 때 특별한 옵션( java -javaagent )을 통해 클래스 로더 조작기를 지정해야 하는데, 이 부분이 번거롭고 운영하기 어렵다.
3-3) 런타임 시점
런타임 시점은 컴파일도 다 끝나고, 클래스 로더에 클래스도 다 올라가서 이미 자바가 실행되고 난 다음을 말한다.
즉, Java의 main 클래스가 실행중인 상태이다.
따라서 Java 언어가 제공하는 범위 안에서 부가 기능을 적용해야 한다.
스프링과 같은 컨테이너의 도움을 받고 프록시와 DI, 빈 포스트 프로세서 같은 개념들을 총 동원해야 한다.
이렇게 하면 최종적으로 프록시를 통해 스프링 빈에 부가 기능을 적용할 수 있다.
지금까지 우리가 학습한 것이 바로 프록시 방식의 AOP이다.
Proxy를 사용하는 방식이기 때문에 몇가지 제약사항이 있지만, 특별한 컴파일러 라던가, 별도의 컴파일 옵션이 필요하지 않다.
Spring만 있으면 AOP 적용이 가능한 것 이다.
▶ 부가 기능이 적용 차이 정리
1) 컴파일 시점
실제 대상 코드에 애스팩트를 통한 부가 기능 호출 코드가 포함된다. AspectJ를 직접 사용
2) 클래스 로딩 시점
실제 대상 코드에 애스팩트를 통한 부가 기능 호출 코드가 포함된다. AspectJ를 직접 사용
3) 런타임 시점
실제 대상 코드는 그대로 유지된다. 대신에 프록시를 통해 부가 기능이 적용된다.
따라서 항상 프록시를 통해야 부가 기능을 사용할 수 있다. 스프링 AOP는 이 방식을 사용한다.
AOP를 적용할 수 있는 지점을 조인 포인트(Join point)라고 부른다.
AspectJ를 사용해서 컴파일 시점과 클래스 로딩 시점에 적용하는 AOP는 바이트코드를 실제 조작하기 때문에 해당 기능을 모든 지점에 다 적용할 수 있다.
하지만 Proxy를 사용하는 AOP는 메서드 실행 지점에만 AOP를 적용할 수 있다.
(프록시는 메서드 오버라이딩 개념으로 동작한다. 따라서 생성자나 static 메서드, 필드 값 접근에는 프록시 개념이 적용될 수 없다.)
즉, Proxy 방식의 스프링 AOP의 조인 포인트는 메서드 실행으로 제한 된다.
또한 Spring Container에 등록되어 있는 Bean에만 AOP를 적용할수가 있다.
참고
스프링은 AspectJ의 문법을 차용하고 프록시 방식의 AOP를 적용한다. AspectJ를 직접 사용하는 것이 아니다.
4. AOP 용어 정리
우선 다음 그림을 살펴보자.
▶ 조인 포인트(Join Point)
어드바이스 가 적용될 수 있는 위치를 말한다. 보통 메서드나 생성자, 필드값, static 메서드 같은 프로그램 실행 중 지점을 말한다.
조인 포인트는 AOP를 적용시킬 수 있는 모든 지점이라 생각하면 된다.
다만, 우리는 Spring 상에서 Proxy기반의 AOP를 사용하므로 항상 메서드로 조인 포인트가 제한된다.
▶ 포인트컷(Pointcut)
조인 포인트 중에서 어드바이스가 적용될 위치를 선별하는 기능을 한다.
실무에서는 거의 AspectJ 표현식을 사용하게 된다.
▶ 타켓(Target)
어드바이스를 받는 객체로써, 실제로 호출되는 대상을 말한다.
▶ 어드바이스(Advice)
target에 적용되는 부가 기능을 의미하며, 특정 조인 포인트에서 Aspect에 의해 취해지는 조치이다.
Around(주변), Before(전), After(후)와 같은 다양한 종류의 어드바이스가 있다.
▶ 애스펙트(Aspect)
어드바이스 + 포인트컷을 모듈화 한 것을 의미한다. 우리가 봤었던 @Aspect 를 생각하면 된다.
Aspect안에 여러 어드바이스와 포인트 컷이 함께 존재
▶ 어드바이저(Advisor)
하나의 어드바이스 + 하나의 포인트 컷 으로 구성된다. 스프링 AOP에서만 사용되는 특별한 용어이다.
▶ 위빙(Weaving)
포인트컷으로 결정한 타켓의 조인 포인트에 어드바이스를 적용하는 것이다.
핵심 코드는 그대로 두고, 위빙을 통해 부가적인 기능만 추가하는 것 이다.
AOP 적용을 위해 애스펙트를 객체에 연결한 상태로, 컴파일 타임 위빙, 로드 타임 위빙, 런타임 위빙이 있다.
▶ AOP 프록시
AOP 기능을 구현하기 위해 만든 프록시 객체, 스프링에서 AOP 프록시는 JDK 동적 프록시 또는 CGLIB 프록시이다.
'BackEnd > Spring' 카테고리의 다른 글
| [Spring] 스프링 AOP - 포인트컷 - 1 (0) | 2022.08.19 |
|---|---|
| [Spring] 스프링 AOP 구현 (0) | 2022.08.18 |
| [Spring] @Aspect AOP (0) | 2022.08.16 |
| [Spring] 빈 후처리기 - 2 (0) | 2022.08.16 |
| [Spring] 빈 후처리기 - 1 (0) | 2022.08.15 |
댓글