🥊 AOP를 활용해 중복코드를 제거해보자! (feat. AOP란?🤔)

👀 Overview

나는 포민(포장의 민족) 프로젝트에서 사장님 서버에서 가게 도메인과 메뉴 도메인을 맡았다.

 

포장의 민족 프로젝트에서의 특이점이라고 한다면, 고객팀과 사장팀이 각각 서버를 나누고, 서버를 나눴으니 DB 또한 각각 나눠 진행을 했다.

그랬기 때문에, 해당 사장 서버의 DB와 고객 서버의 DB의 정합성을 맞추는 것이 핵심이였고 항상 사장 서버에서 자원이 생성되거나 변경될 때 마다 고객팀 서버로 정보를 전송해 주어야 했다.

 

따라서 아래와 같이 InfoSender 빈을 통해서 RestTemplate을 통해 정보를 고객팀 서버로 전달했다.

@Component
@RequiredArgsConstructor
public class InfoSender {

    private final RestTemplate restTemplate;

    private static final String URL_PREFIX = "http://52.78.144.166:8080/api/v1"; // 고객팀 url

    public void send(Store store) {
        StoreInfo body = StoreInfo.from(store);

        HttpEntity<StoreInfo> storeInfoHttpEntity = new HttpEntity<>(body);
        ResponseEntity<String> response = restTemplate.exchange(URL_PREFIX + "/stores", POST, storeInfoHttpEntity, String.class);
        validateResponse(response);
    }

    public void send(Menu menu) {
        MenuInfo body = MenuInfo.from(menu);

        HttpEntity<MenuInfo> menuInfoHttpEntity = new HttpEntity<>(body);
        ResponseEntity<String> response = restTemplate.exchange(URL_PREFIX + "/menus", POST, menuInfoHttpEntity, String.class);
        validateResponse(response);
    }

    public void send(Menu menu, OptionGroup optionGroup) {
        OptionGroupInfoToSend body = OptionGroupInfoToSend.from(optionGroup, menu);
        
        HttpEntity<OptionGroupInfoToSend> optionGroupInfoToSendHttpEntity = new HttpEntity<>(body);
        ResponseEntity<String> response = restTemplate.exchange(URL_PREFIX + "/options", POST, optionGroupInfoToSendHttpEntity, String.class);
        validateResponse(response);
    }

 

그리고 해당 빈을 주입 받아서 Service 메서드 마다 변경이 일어날 때마다 해당 엔티티 정보를 고객팀 서버로 보내 주어야 했는데,

그렇다 보니 Cross Cutting Concern, 횡단 관심사가 다음과 같이 발생하게 되었다.

횡단 관심사의 발생..

이렇게 되면 문제점이

1. InfoSender 빈을 의존하고 있어야 하기 때문에 InfoSender와 StoreService 간의 강한 결합이 발생한다.

2. 메서드가 두 가지 일을 하고 있고, 코드의 중복이 발생한다.

 

이를 Spring에서 제공하는 Spring AOP를 사용해 해결 할 수 있었다.

 

🥊 AOP란?

AOP(Aspect Oriented Programming)이란, 관점 지향 프로그래밍이다.

Aspect란 무엇일까?

그것 전에 AOP를 통해서 횡단 관심사를 처리할 수 있다고 하는데 어떻게 그게 가능한 것일까?

 

애플리케이션은 크게 핵심 기능과 부가 기능으로 나뉜다.

핵심기능은 해당 객체가 제공하는 고유의 기능을 말한다. 예를 들어 위의 StoreService에서 핵심 기능은 Store에 대한 정보를 저장하고, 변경하는 것이다.

부가 기능은 핵심 기능을 보조하기 위해 제공되는 기능으로 로그 추적, 트랜잭션을 예로 들 수 있는데, 위에서 해당 변경된 엔티티 정보를 고객 서버에 보내는 것을 부가 기능이라고 볼 수 있다.

 

이렇게 부가 기능을 모듈화 해서 어디에 적용할지를 선택하는 기능을 합해 하나의 모듈로 만든 것을 Aspect라고 한다.

 

이렇게 부가기능과 핵심 기능을 분리함으로서 AOP를 사용하면 정말 메서드가 하나의 일만 할 수 있도록, 더 객체 지향적으로 코딩이 가능해진다.

 

🥊 Spring에서는 AOP를 어떻게 구현하는가?

횡단관심사, cross cutting concern을 처리하기 위해서 AOP를 구현하는 방법에는 세 가지가 있다.

1. 컴파일 시점에 .class 파일로 변환 될때 바이트코드를 덧붙혀 AOP를 적용할 수 있다.

2. 클래스 로더에 로드 될 때 코드를 덧붙혀 AOP를 적용할 수 있다.

3. 런타임 시점에 있어서 AOP를 적용할 수 있는데, 프록시를 사용해 AOP를 적용할 수 있다.

 

첫번째, 두 번째 방식, 즉 컴파일 시점과 클래스 로더에 로드 되는 시점에 AOP를 적용하는 방식은 AOP에 대한 거의 모든 기능을 지원하는 AspectJ 라이브러리를 통해 구현할 수 있지만, 상당히 학습량도 많고 복잡하다고 한다.

그래서 Spring에서는 AOP를 프록시를 사용해 런타임에 적용하는 방식을 택했다.

 

그럼 스프링에서는 AOP를 적용할 대상을 프록시를 통해 어떻게 구현할 수 있을까?

이것에 대해서 설명하기위해 먼저 용어정리를 하자면, AOP를 적용할 대상인 Joinpoint, 적용할 부가 로직인 Advice, 적용 위치를 설정하는 Pointcut, 하나의 Advice와 하나의 Pointcut을 합친 Advisor가 있다.

Pointcut에 해당하는 메서드가 있는 클래스를 빈 등록 시 CGLIB 라이브러리를 사용해 대상 빈을 프록시로 등록해 Advice를 적용하는 방식으로 프록시 패턴을 통해 AOP를 런타임에 실행할 수 있다.

 

그럼 PointCut으로 설정된 대상에 Proxy적용을 어떻게 하느냐?

빈 후 처리기(Bean Post Processor)를 통해 다른 설정없이 Bean으로 등록 된 것을 프록시 객체로 바꿀 수 있는데, @Aspect 어노테이션을 사용해 Pointcut과 Advice를 설정하면, AnnotationAwareAspectJAutoProxyCreator가 자동으로 프록시를 빈으로 등록 시켜 준다.

 

여러 부가기능과 적용위치 Pointcut을 합친 Aspect를 설정하면, 자동으로 프록시를 만들어 AOP를 런타임에 설정해 주는 것이 Spring에서 제공하는 AOP 기능이다.

 

🥊 AOP를 적용해보자!

먼저, 처음 위 StoreService에서 InfoSender를 분리해 보자.

그러기 위해서 Aspect를 설정해 주어야 하는데, Aspect의 Pointcut 설정하는데 있어 아래와 같이 @TransmitData 어노테이션을 생성해 어노테이션 대상으로 Pointcut을 설정해 주었다.

 

그 이유는 StoreService, MenuService에 AOP를 설정하고 싶은데, 모든 클래스의 메서드에 적용하는게 아니라 어떤 메서드는 고객팀에 전송기능이 필요하고, 어떤 메서드는 필요 없었기 때문에 사용하기 간편한 어노테이션 기반으로 Pointcut을 설정했다.

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface TransmitData {

}

 

@Slf4j
@Aspect
@Component
@RequiredArgsConstructor
public class DataTransferAspect {

    private final InfoSender infoSender;

    @Pointcut("@annotation(com.ray.pominowner.store.service.aop.TransmitData)")
    private void toTransmitDataAnnotation() {}

    @AfterReturning(pointcut = "toTransmitDataAnnotation()", returning = "store")
    public void transmitData(Store store) {
        infoSender.send(store);
        log.info("store info sent");
    }

    @AfterReturning(pointcut = "toTransmitDataAnnotation()", returning = "menu")
    public void transmitData(Menu menu) {
        infoSender.send(menu);
        log.info("menu info sent");
    }

    @AfterReturning(pointcut = "toTransmitDataAnnotation()", returning = "optionInfo")
    public void transmitData(OptionGroupInfoToSend optionInfo) {
        infoSender.send(optionInfo);
        log.info("option info sent");
    }

}

 

❓ 왜 @Around 대신 @AfterReturning을 사용했는가?

또 위와 같이 @Around 대신 @AfterReturning을 사용한 이유는, ProceedingJoinPoint의 proceed() 메서드 호출을 해야할 필요성을 못느꼈던것이 가장 컸고, @AfterReturning을 사용하는것이 target메서드의 메서드가 return되고 동작하는 기능이라는 것이 명확하게 보였기 때문이다.

그리고 return값을 사용해 바로 고객팀 서버에 보내면 되었기 때문에, @AfterReturning을 사용했다.

 

❓ 왜 하나의 advice 메서드에서 처리한 게 아니라 메서드를 각각 만들었는가?

returning에서 설정한 값과 동일한 파라미터가 왔을 때, Object로 파라미터를 받아 instanceof 를 통해 패턴 매칭 후 해당 타입에 맞는 메서드를 호출한다면 메서드 세 개가 아닌 하나로 끝나는 문제였다.

그 이유는, 가독성이 떨어지고 지저분해지기 때문이다.

자바 21의 switch 문을 통한 패턴매칭을 사용할 수 있다면 리펙토링을 할 수 있겠지만, 자바 17버전을 사용하고 있기도 하고, @AfterReturning 사용시 return 값을 받는 것에 있어서 타입이 다르면 AOP 적용이 무시 되기 때문에 각각 메서드를 만들어 주어 가독성을 높히고 역할을 분리 시킬 수 있었다.

 

위와 같이 Aspect를 설정하고, 대상이 되는 Service 코드를 아래와 같이 리펙토링 해 주었다.

MenuService

StoreService

물론 Entity를 반환해 주어야 한다는 점으로 Controller의 코드도 약간 수정되긴 하지만 큰 문제가 되진 않았다.

 

이렇게 AOP를 통해 핵심 로직과 공통 로직을 분리 시킴으로서 객체지향적이고 가독성 높은 코드를 작성할 수 있었다!

 

Reference

https://m.yes24.com/Goods/Detail/17350624

스프링 입문을 위한 자바 객체 지향의 원리와 이해 - 예스24

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B3%A0%EA%B8%89%ED%8E%B8

스프링 핵심 원리 - 고급편 강의 - 인프런