🌱 TIL - Spring AOP

AOP에 대해 알아보자

Spring을 공부하다 보면 @Transactional이나 공통 로그 처리처럼, 비슷한 기능이 여러 곳에서 반복적으로 등장하는 걸 보게 된다.

처음에는 그냥 필요한 곳마다 넣으면 되는 거 아닌가?라고 생각했는데, 정리해보니 이런 공통 기능을 핵심 로직과 분리해서 관리하는 방식이 바로 AOP였다.

예를 들어 API 실행 시간을 측정한다고 하면, 컨트롤러나 서비스 메서드마다 시작 시간과 종료 시간을 직접 넣을 수도 있다. 하지만 이런 코드가 여기저기 반복되기 시작하면 핵심 로직보다 부가적인 코드가 더 눈에 띄게 된다.

이럴 때 공통 관심사를 따로 분리해서 필요한 지점에 적용할 수 있게 해주는 것이 AOP다.

🍒 Spring AOP

AOP는 Aspect Oriented Programming의 줄임말로, 핵심 기능과 공통 부가 기능을 분리해서 관리하는 방식이다.

여기서 핵심 기능은 실제 비즈니스 로직이고, 부가 기능은 로깅, 실행 시간 측정, 트랜잭션, 예외 처리처럼 여러 곳에서 공통으로 필요한 기능이다.

즉, AOP를 적용하면 메서드마다 같은 코드를 반복해서 작성하지 않고, 공통 기능을 한 곳에 모아두고 필요한 지점에 끼워 넣을 수 있다.

예를 들어 주문 생성, 회원 조회, 상품 수정같은 기능은 각각 다른 핵심 로직이지만, 실행 시간 측정이나 공통 로그 기록은 여러 곳에서 비슷하게 필요할 수 있다.

이런 부분을 비즈니스 로직과 분리해서 관리하는 것이 AOP의 핵심이다.

🍓 AOP에서 자주 나오는 용어

AOP를 처음 보면 Aspect, Advice, Pointcut 같은 용어가 한꺼번에 나와서 헷갈릴 수 있다. 나도 처음에는 이름이 비슷해서 어렵게 느껴졌는데, 역할로 나눠서 보면 생각보다 단순했다.

• Aspect: 공통 기능을 모아둔 AOP 설정 단위
• Advice: 부가 기능을 언제 실행할지 정의한 코드
• Pointcut: 부가 기능을 어디에 적용할지 정하는 조건
• JoinPoint: 부가 기능이 끼어들 수 있는 지점. Spring AOP에서는 보통 메서드 실행 시점이라고 이해하면 된다.

Aspect = 공통 기능 묶음
Advice = 언제 실행할지
Pointcut = 어디에 적용할지

🍊 @Aspect

@Aspect는 해당 클래스가 AOP 설정 클래스라는 걸 나타내는 어노테이션이다.
즉, 이 클래스 안에서 부가 기능을 언제, 어디에 적용할지 정의하겠다고 스프링에게 알려주는 역할을 한다.

AOP를 적용하려면 보통 이 어노테이션이 붙은 클래스 안에 Advice와 Pointcut을 작성하게 된다.

🍋 Advice

Advice는 부가 기능을 언제 실행할지 정하는 것이다.

@Before

핵심 기능이 실행되기 전에 동작한다.
요청값 검증이나 실행 전 로그 기록처럼, 메서드가 시작되기 전에 처리해야 하는 작업에 사용한다.

@After

핵심 기능의 성공 여부와 상관없이 항상 실행된다.
자바의 finally처럼 동작한다고 보면 이해하기 쉬웠다.

@AfterReturning

메서드가 정상적으로 끝났을 때만 실행된다.
반환값을 사용할 수 있기 때문에, 성공한 결과를 로그로 남길 때 활용할 수 있다.

@AfterThrowing

메서드 실행 중 예외가 발생했을 때만 동작한다.
공통 예외 로그를 남기거나 알림을 보낼 때 사용할 수 있다.

@Around

핵심 기능 실행 전과 후를 모두 감쌀 수 있는 Advice다.
직접 실제 메서드 실행 시점을 제어할 수 있어서 가장 많이 사용된다고 느꼈다.
실행 시간 측정 같은 기능도 보통 @Around로 구현한다.

🍐 Pointcut

Pointcut은 부가 기능을 어디에 적용할지 정하는 조건이다.
Advice가 “언제”라면 Pointcut은 “어디에”에 해당한다.

Spring AOP에서는 주로 execution() 표현식을 사용해서 메서드 실행 지점을 기준으로 대상을 지정한다.

execution(modifiers-pattern? return-type-pattern declaring-type-pattern? method-name-pattern(param-pattern) throws-pattern?)

구성요소

• modifiers-pattern
  • 접근제어자
  • 예: public, private, *
• return-type-pattern
  • 반환 타입
  • 예: void, String, *
• declaring-type-pattern
  • 클래스 경로
    • com.sparta.myselectshop.controller.*
      • controller 패키지의 모든 클래스
    • com.sparta.myselectshop.controller..*
      • controller 패키지와 하위 패키지의 모든 클래스
• method-name-pattern(param-pattern)
  • 메서드 이름과 파라미터 조건
    • addFolders() - addFolders 메서드만 적용
    • add*(..) - add로 시작하는 모든 메서드 적용

처음에는 문법이 길어서 어렵게 느껴졌는데,
결국은 “어느 패키지의 어떤 메서드에 적용할 건지”를 조건으로 적는 거라고 이해하니 훨씬 단순해졌다.

또 @Pointcut을 사용하면 이 표현식을 따로 분리해서 여러 Advice에서 재사용함으로써 중복을 줄이고 가독성을 높이는 데 도움이 된다.

🍇 프록시 기반 동작

Spring AOP는 프록시 기반으로 동작한다.
프록시는 실제 객체를 대신해서 앞에서 동작하는 대리 객체다.

스프링은 AOP 적용 대상 Bean을 그대로 주입하는 것이 아니라, 실제 객체 앞에 프록시 객체를 하나 두고 그 프록시를 주입한다.

그래서 메서드가 호출되면 먼저 프록시가 호출을 가로채고, Advice를 실행한 뒤 실제 메서드를 호출하게 된다.

흐름으로 보면 이렇게 이해할 수 있다.

적용 전
DispatcherServlet → Controller
적용 후
DispatcherServlet → AOP Proxy → Advice → Controller

핵심 로직은 그대로 두고, 프록시가 앞에서 공통 부가 기능을 처리해주는 구조다.

🍉 AOP가 필요한 이유

AOP를 공부하면서 가장 크게 느낀 점은, 공통 기능을 여러 클래스에 직접 넣기 시작하면 코드가 금방 지저분해진다는 것이었다.

예를 들어 요청이 들어올 때마다 메서드 이름이나 파라미터, 실행 여부 같은 로그를 남기고 싶다면 가장 단순한 방법은 컨트롤러나 서비스마다 직접 log.info()를 작성하는 것이다.
실제로는 이 방식만으로도 로그를 남길 수 있다.

하지만 이걸 여러 클래스와 메서드에 반복해서 넣기 시작하면 핵심 로직이 잘 보이지 않고, 중복 코드가 많아지고, 나중에 로그 형식이나 출력 위치를 바꿔야 할 때 수정 범위도 커지게 된다.

반면 AOP를 사용하면 로그를 남기는 기능 같은 공통 작업을 한 곳에 모아서 관리할 수 있다.

핵심 기능은 핵심 기능대로 두고, 부가 기능은 필요한 지점에만 공통 적용할 수 있다.

그래서 AOP는 단순히 문법을 배우는 개념이 아니라, 중복을 줄이고 관심사를 분리하기 위한 방법이라는 점이 더 중요하게 느껴졌다.

🍒 회고

처음에는 AOP를 어노테이션 몇 개 붙이는 기능 정도로 생각했는데,
정리해보니 핵심은 공통 관심사를 핵심 로직에서 분리하는 것이었다.

특히 프록시가 메서드 호출을 가로채서 Advice를 실행한 뒤 실제 메서드를 호출한다는 흐름을 이해하고 나니, 왜 @Transactional 같은 기능도 AOP로 동작하는지 조금 더 자연스럽게 받아들일 수 있었다.

+ @Transactional도 AOP 기반으로 동작한다. 
  스프링은 트랜잭션이 필요한 메서드에 프록시 객체를 생성하고, 
  메서드 호출을 가로채서 실행 전에는 트랜잭션을 시작하고, 
  정상 종료 시 commit, 예외 발생 시 rollback을 수행한다. 

오늘 정리하면서 느낀 건, AOP는 단순히 개념만 외우는 것보다 “어떤 공통 기능을 분리하려고 등장했는가”를 같이 이해해야 훨씬 잘 들어온다는 점이었다.

다음에는 직접 API 실행 시간 측정이나 로깅을 AOP로 구현해보면서 더 익숙해져봐야겠다.