AOP(Aspect Oriented Programming)

 

728x90

SMALL

이제 드디어 AOP에 대해 진지하게 알아보는 시간을 가져보자. 우선 AOP란 번역 하면 관점 지향 프로그래밍이다. 여기서 관점이란 무엇일까? 관점은 애플리케이션의 핵심적인 관점과 부가적인 관점으로 분류할 수 있다. 애플리케이션의 핵심적인 관점이라고 하면 비즈니스 로직이다. 그리고 부가적인 관점은 애플리케이션의 비즈니스 로직을 수행하면서 있으면 도움이 되는 로직이다. 예를 들면 비즈니스 로직을 처리하는 시간에 대한 로그 출력이나, 데이터베이스와의 트랜잭션 기능.

 

이러한 부가 기능은 단독으로 사용되지 않고 핵심 기능과 함께 사용된다. 즉, 이름 그대로 핵심 기능을 보조하기 위해 존재한다고 볼 수 있다.

 

핵심 로직을 수행하기 직전 부가 로직이 수행되어야 하면 핵심 기능 로직과 부가 기능 로직이 하나의 객체 안에 섞여 들어가게 된다. 부가 기능이 필요하면 이렇게 둘을 합해서 하나의 로직을 완성한다.

 

그러나, 보통 부가 기능은 여러 클래스에 걸쳐서 함께 사용된다. 예를 들어, 모든 애플리케이션 호출을 로깅해야 하는 요구사항이 있으면 하나의 객체에서 끝나지 않고 여러 객체를 거쳐야 할 것이다.

 

이렇게 여러 객체에 걸쳐 공통의 관심사를 횡단 관심사라고 하는데 이러한 횡단 관심사를 모든 객체에 적용하려면 모든 객체의 로직이 수정되어야 한다. 즉, 할 수 없는 것이다. 또는 너무너무 비효율적이거나. 예를 들어 부가 기능을 적용해야 하는 클래스가 100개면 100개 모두 로직을 수정해야 하고 동일한 코드를 추가해야 한다.

 

코드의 중복이라도 줄이고자 부가 기능을 별도의 유틸리티 클래스로 만든다고 해도 해당 유틸리티 클래스를 호출하는 코드가 결국 필요하다. 그리고 부가 기능이 구조적으로 단순 호출이 아니고 try - catch - finally 같은 구조가 필요하다면 더욱 복잡해진다. 그리고 부가 기능에 변경 사항이 발생하면? 클래스 100개 모두 변경해줘야 하며 적용 대상이 변경된다고 해도 마찬가지 문제점이 발생한다. 

 

요약하자면, 다음과 같은 문제점이 발생한다.

• 부가 기능을 적용할 때 아주 많은 반복이 필요하다.
• 부가 기능이 여러 곳에 퍼져서 중복 코드를 만들어낸다.
• 부가 기능을 변경할 때 중복 때문에 많은 수정이 필요하다.
• 부가 기능의 적용 대상을 변경할 때 많은 수정이 필요하다.

소프트웨어 개발에서 변경 지점은 하나가 될 수 있도록 잘 모듈화를 해야 한다. 

 

AOP

그럼 이러한 부가 기능 도입의 문제점들을 어떻게 해결할 수 있을까? 부가 기능을 핵심 기능에서 분리하여 한 곳에서 관리하는 것이다. 그리고 해당 부가 기능을 어디에 적용할지 선택하는 기능을 만드는 것이다. 이렇게 부가 기능과 부가 기능을 어디에 적용할지 선택하는 기능을 합해서 하나의 모듈로 만들었는데 이것이 바로 애스펙트(Aspect)이다. 애스펙트는 부가 기능과, 해당 부가 기능을 어디에 적용할지 정의한 것이다. 예를 들어 로깅 기능(부가 기능)을 모든 서비스에 적용해라(어디에) 라는 것이 정의되어 있는 것이다.

 

저번 시간에 살펴본 @Aspect가 바로 이것이다. 그리고 스프링이 제공하는 어드바이저도 어드바이스(부가 기능) + 포인트컷(대상)을 가지고 있어서 개념상 하나의 애스팩트이다.

 

그리고 참고로 AOP는 OOP를 대체하기 위함이 아니다. 횡단 관심사를 깔끔하게 처리하기 어려운 OOP의 부족한 부분을 보조하는 목적으로 개발되었다.

 

AspectJ 프레임워크

AOP의 대표적인 구현으로 AspectJ 프레임워크가 있다. 스프링은 AOP를 지원하고 있으나 대부분 AspectJ의 문법을 차용하고 AspectJ가 제공하는 기능의 일부만 제공한다.

그러나, 결론은 스프링 AOP를 사용하면 실무에서 어지간한 모든 기능을 다 사용할 수 있다. 이는 이후에 차차 알아보도록 하자.

 

AOP 적용 방식

그럼 이 부가적인 관점에 해당하는 로직과 핵심 관점에 해당하는 로직은 AOP를 사용할 때 코드상 완전히 분리되어서 관리되는데 어떻게 AOP를 사용할 때 부가 기능 로직은 어떤 방식으로 실제 로직에 추가될 수 있을까?

 

크게 3가지 방법이 있다.

• 컴파일 시점
• 클래스 로딩 시점
• 런타임 시점(프록시)

 

컴파일 시점

AspectJ가 제공하는 특별한 컴파일러를 통해 이루어진다. 다음 그림을 보자.

.java 소스 코드를 컴파일러를 사용해서 .class를 만드는 시점에 부가 기능 로직을 추가할 수 있다. 이때는 AspectJ가 제공하는 컴파일러를 통해 이루어진다. .class를 디컴파일 해보면 에스팩트 관련 호출 코드가 들어간다. 쉽게 말해서 부가 기능 코드가 핵심 기능이 있는 컴파일된 코드 주변에 실제로 붙어 버린다고 생각하면 된다. AspectJ 컴파일러는 Aspect를 확인해서 해당 클래스가 적용 대상인지 먼저 확인한 후 적용 대상인 경우에 부가 기능 로직을 적용한다. 이렇게 원본 로직에 부가 기능 로직이 추가되는 것을 위빙(Weaving)이라고 한다.

 

이 방법의 단점은 특별한 컴파일러가 필요하다는 것 그 자체이고 사용하기에 굉장히 복잡하다.

 

클래스 로딩 시점

 

자바를 실행하면 자바 언어는 .class 파일을 JVM 내부의 클래스 로더에 보관한다. 이때 중간에서 .class 파일을 조작한 다음 JVM에 올릴 수 있다. 자바 언어는 .class를 JVM에 저장하기 전에 조작할 수 있는 기능을 제공한다. 자세한 내용을 알려면 java instrumentation을 검색해 보면 된다. 참고로 수많은 모니터링 툴들이 이 방식을 사용한다. 이 시점에 에스팩트를 적용하는 것을 로드 타임 위빙이라고 한다.

 

이 방법의 단점은 자바를 실행할 때 특별한 옵션을 통해 클래스 로더 조작기를 지정해야 하는데 이 부분이 번거롭고 운영하기에 단점이 있다.

 

 

런타임 시점

런타임 시점은 컴파일도 다 끝나고, 클래스 로더에 클래스도 다 올라가서 이미 자바가 실행되고 난 다음을 말한다. 자바의 메인(main) 메서드가 이미 실행된 다음이다. 따라서 자바 언어가 제공하는 범위 안에서 부가 기능을 적용해야 한다. 스프링과 같은 컨테이너의 도움을 받고 프록시와 DI, 빈 포스트 프로세서 같은 개념들을 총 동원해야 한다. 이렇게 하면 최종적으로 프록시를 통해 스프링 빈에 부가 기능을 적용할 수 있다. 

 

 

부가 기능이 적용되는 차이를 정리하면 다음과 같다.

• 컴파일 시점: 실제 대상 코드에 애스팩트를 통한 부가 기능 호출 코드가 포함된다. AspectJ를 직접 사용해야 한다.
• 클래스 로딩 시점: 실제 대상 코드에 애스팩트를 통한 부가 기능 호출 코드가 포함된다. AspectJ를 직접 사용해야 한다.
• 런타임 시점: 실제 대상 코드는 그대로 유지된다. 대신에 프록시를 통해 부가 기능이 적용된다. 따라서 항상 프록시를 통해야 부가 기능을 사용할 수 있다. 스프링 AOP는 이 방식을 사용한다.

 

AOP 적용 위치

AOP는 지금까지 학습한 메서드 실행 위치뿐만 아니라 다음과 같은 다양한 위치에 적용할 수 있다.

• 생성자
• 필드 값 접근
• static 메서드 접근
• 메서드 실행

생성자, 필드 값 접근, static 메서드 접근 같은 경우는 AspectJ를 직접 사용해서 실제 코드에 부가 로직 코드를 합치는 경우에 가능하다. 당연히 가능하겠지 생성자안에 부가 로직을 추가하면 되니까. 그리고 이런 AOP를 적용할 수 있는 지점을 조인 포인트(JoinPoint)라고 한다. 그러나, 프록시를 사용하는 방식은 메서드 실행 지점에만 AOP를 적용할 수 있다. 프록시는 메서드 오버라이딩 개념으로 동작한다. 따라서 생성자나 static 메서드, 필드 값 접근에는 프록시 개념이 적용될 수 없다. 

 

그러면, 스프링 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를 구현해보자.