TIL) AOP와 AspectJ는 세탁기로 비유했다.

📌 2025-03-09 TIL

1. 오늘의 학습 주제

• Spring AOP와 AspectJ를 비교해보자

2. 학습 내용

두 기술 모두 관심사 분리를 위해 제공하는 기술입니다.

애플리케이션에서 하나의 서비스에서 필요한게 아니라 모든 서비스에 필요한게 있습니다.

예를 들면 요즘 메장에 들어가면 주문을 위해 필요한 키오스크가 있습니다.

주문을 할 때(서비스 계층)에서 주문 직전에 어떤 음식 목록이 있는지 보여주려고 키오스크를 사용합니다.

결제를 할 때도 키오스크를 사용하게 됩니다.

실제 주문을 하는 서비스를 제외하고 그 외에는 전반적인 모든 음식점에서 사용하려고 하는 관심사입니다.

하지만 실제 주문을 하는 것과는 다른 관심사이지만 비즈니스 로직에 빠질 수는 없습니다.

객체지향 프로그래밍에서 다른 관심사가 하나의 메서드나 클래스에 포함이 된다면 유지보수와 역할에 의존하여 확장하기에는 어려움이 있습니다. 이것을 횡단 관심사라고 말하며 이 관심사를 분리하기 위해 두 가지 기술을 고려할 수 있다는 것을 알았습니다.

동적 위빙과 정적 위빙

동적 위빙과 정적 위빙의 방식은 세탁기로 비유할 수 있습니다.

동적 위빙은 세탁기(원본 객체) 위에 코인세탁소 목적으로 겉에 추가적인 기능을 넣은 것을 말합니다.

원본 객체는 건들지 않고 외부에 코인 세탁소 목적으로 자물쇠를 달고 동전을 넣을 수 있도록 만드는 것이죠

그래서 동작방식도 런타임에 관심사 로직이 들어갑니다.

정적위빙은 세탁기(원본 객체)를 세탁기 수리 기사분을 불러서 기존에 없던 기능인 세탁기가 돌아갈 때마다 노래가 나오도록 추가하는 것과 같습니다.

컴파일된 파일(원본.class)을 수리기사(AspectJ)가 수정하여 원본(노래기능이첨가된).class 파일로 변경합니다.

그래서 동작방식도 컴파일 시점에 관심사 코드가 들어갑니다.

트레이드 오프

프록시 기반은 상속이나 구현을 기반으로 동작하기 때문에 공개 메서드를 기준으로 동작합니다.

컴파일 기반은 자바 바이트 코드 기반으로 동작하기에 필드나 private 메서드에도 관심사를 적용할 수 있습니다.

대부분의 서비스에서는 컴파일 기반보다 프록시 기반이 구현이 간단하고 스프링 컨테이너의 동작방식을 그대로 사용할 수 있으므로 학습 곡선이 AspectJ보다 낮습니다.

다만 프록시의 한계인 private, final은 관심사를 넣을 수 없으며 self-invocation 처럼 프록시 내에 메서드를 호출하는 것은 적용이 안됩니다.

그게 아니라 시스템 전반적인 모든 필드나 생성자 프록시의 한계를 모두 해결 가능한 것으로 유연한 것이 AspectJ 입니다.

그러면 언제 사용해야할까

대부분 MVC 아키텍처 구간에서는 사용이 가능합니다.

스프링 빈으로 등록된 공개 메서드에 적용해야하는 횡단 관심사라면 모두 가능합니다.

예를 들면 로깅이나 인증, 트랜잭션과 같이 전반적으로 사용되어지며 스프링 빈으로 관리되는 대상들이기 때문이죠

그게 아니라 시스템 전반적인 필드나 스프링 빈으로 관리할 수없는 오브젝트, 레거시 코드, 외부 라이브러리에도 적용이 가능하다는 장점이 있습니다.

간단 정리

스프링 컨테이너에 등록된 오브젝트의 공개 메서드에 관심사 로직을 넣어야 한다 => Spring AOP

그외 private, 스프링 컨테이너의 관리 대상이 아닌 오브젝트에 관심사 로직을 넣어야한다 => AspectJ

주의사항

Spring AOP 주의사항

• Self-Invocation 문제 (내부 호출 시 적용 안됨)
• private, final 메서드 적용 불가능

AspectJ 주의사항

• 컴파일 타임 위빙을 쓰려면 AspectJ 전용 컴파일러(ajc) 사용 필요
• 로드타임 위빙은 JVM 옵션 (-javaagent) 설정 필요
• 과도한 위빙 적용은 디버깅과 코드 유지보수를 어렵게 할 수 있으니, 신중히 사용해야 함