관점 지향 프로그래밍(aspect-oriented programming, AOP)

핵심 기능과 부가 기능

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

• 핵심 기능 : 해당 객체가 제공하는 고유의 기능
  • 예를 들어 BookPrinter의 핵심 기능은 Print 로직
• 부가 기능 : 핵심 기능을 보조하기 위해 제공되는 기능
  • 예를 들어 로그 추적 로직, 실행 시간 출력 등

보통 부가 기능은 여러 클래스에 걸쳐서 함께 사용된다.

• 예를 들어 모든 애플리케이션 호출을 로깅해야 하는 요구사항을 생각해보자
  • 로그 추적 로직 같은 부가 기능은 횡단 관심사(cross-cutting concerns)가 된다.
  • 쉽게 말해 하나의 부가 기능이 여러 곳에 동일하게 사용된다는 뜻이다.

 

하지만 부가 기능을 적용할 때 생기는 문제점이 있다

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

 

부가 기능 도입의 문제점을 해결하는 방법

핵심 기능과 부가 기능을 분리

• 부가 기능을 핵심 기능에서 분리하고 한 곳에서 관리하도록 했다.
• 부가 기능을 어디에 적용할지 선택하는 기능도 만들었다
• 이러한 기능을 합해서 하나의 모듈로 만들었는다. 바로 그게 aspect 애스펙트이다.
  • 다시 말해, 부가 기능과 해당 부가 기능을 어디에 적용할지 정의 한 것

 

 

 

관점 지향 프로그래밍 AOP

애스팩트는 우리말로 해석하면 관점이라고 한다. 이름 그대로 애플리케이션을 바라보는 관점을 하나하나의 기능에서 횡단 관심사 관점으로 달리 보는 것이다. 이렇게 애스펙트를 사용한 프로그래밍 방식을 관점 지향 프로그래밍이라고 한다.

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

장점

• 부가 기능과 핵심 기능을 분리하여 핵심 로직을 깔끔하게 유지할 수 있다
• 부가 기능 변경이 필요 할 때 다른 부분의 변경 없이 부가 기능만 변경하면 된다.

 

AOP 적용 방식

1. 컴파일 시점

.java 소스 코드를 컴파일러를 사용해 .class를 만드는 시점에 부가 기능 로직을 추가할 수 있다. 부가 기능 코드가 핵심 기능이 있는 컴파일된 코드 주변에 실제로 붙어 버린다고 생각하면 된다. 이처럼 원본 로직에 부가 기능 로직이 추가되는 것을 weaving 위빙이라고 한다.

단점 : 컴파일 시점에 부가 기능을 적용하려면 특별한 컴파일러도 필요하고 복잡하다.

2. 클래스 로딩 시점

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

단점 : 로드 타임 위빙은 자바를 실행할 때 특별한 옵션( java -javaagent )을 통해 클래스 로더 조작기를 지정해야 하는데, 이 부분이 번거롭고 운영하기 어렵다

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

런타임 시점은 컴파일도 다 끝나고, 클래스 로더에 클래스도 다 올라가서 이미 자바가 실행되고 난 다음을 말한다. 자바의 main 메서드가 이미 실행된 다음이다. 따라서 자바 언어가 제공하는 범위 안에서 부가 기능을 적용해야 한다. 이 방식은 실제 대상 코드는 그대로 유지되고 프록시를 통한 부가 기능이 적용되는 방식이다. 스프링 AOP는 이 방식을 사용한다.

• 프록시 방식을 사용하는 스프링 AOP는 메서드 실행 지점에만 AOP를 적용할 수 있다
• 프록시는 메서드 오버라이딩 개념으로 동작한다. 따라서 생성자나 static 메서드, 필드 값 접근에는 프록시 개념이 적용될 수 없다.
• 프록시를 사용하는 스프링 AOP의 조인 포인트는 메서드 실행으로 제한된다.
• 프록시 방식을 사용하는 스프링 AOP는 스프링 컨테이너가 관리할 수 있는 스프링 빈에만 AOP를 적용할 수 있다

참고 : 조인 포인트(join point)란 AOP를 적용할 수 있는 지점을 말한다. 조인 포인트에는 생성자, 필드 값 접근, static 메서드 접근, 메서드 실행 등 다양한 위치가 존재한다.

 

 

내부 호출시 문제점

스프링은 프록시 방식의 AOP를 사용하기 때문에, AOP를 적용하려면 항상 프록시를 통해서 대상 객체를 호출해야 한다. 이런 과정을 거쳐야 프록시에서 어드바이스를 호출하고 이후에 대상 객체를 호출한다. 만약 프록시를 거치지 않는다면 AOP는 적용되지 않는다.

AOP를 적용하면 스프링은 대상 객체 대신 프록시를 스프링 빈으로 등록한다. 따라서 스프링은 의존관계 주입시에 항상 프록시 객체를 주입한다.
하지만 대상 객체의 내부에서 메서드 호출이 발생할 때 프록시를 거치지 않고 대상 객체를 직접 호출하는 문제가 발생한다.

 

내부 호출 문제 해결 방법

1. 자기 자신 주입

/**
* 참고: 생성자 주입은 순환 사이클을 만들기 때문에 실패한다.
*/
@Slf4j
@Component
public class CallServiceV1 {
    private CallServiceV1 callServiceV1;
    
    @Autowired
    public void setCallServiceV1(CallServiceV1 callServiceV1) {
        this.callServiceV1 = callServiceV1;
    }
    
    public void external() {
        log.info("call external");
        callServiceV1.internal(); //외부 메서드 호출
    }
    
    public void internal() {
        log.info("call internal");
    }
}

자기 자신을 수정자(setter)를 통해 주입 받는 방법이다. 스프링에서 AOP가 적용된 대상을 의존관계 주입 받으면 주입받은 대상은 실제 자신이 아니라 프록시 객체이다.

주의 : 스프링 부트 2.6부터는 순환 참조를 기본적으로 금지하도록 정책이 변경 되어 위의 코드는 별도의 설정을 추가하지 않으면 정상 실행되지 않는다.

2. 지연 조회

ObjectProvider를 사용해서 객체를 스프링 컨테이너에서 조회하는 것을 스프링 빈 생성 시점이 아니라 실제 객체를 사용하는 시점으로 지연할 수 있다.

3. 구조 변경

/**
 * 구조를 변경(분리)
 */
@Slf4j
@Component
@RequiredArgsConstructor
public class CallServiceV3 {
    private final InternalService internalService;
    public void external() {
        log.info("call external");
        internalService.internal(); //외부 메서드 호출
    }
}

@Slf4j
@Component
public class InternalService {
    public void internal() {
    	log.info("call internal");
    }
}

구조를 변경하여 내부 호출 자체를 삭제했다.


출처
https://inf.run/fnKP