Spring AOP | 서비스 호출 전에 로깅, 꼭 AOP에서 해야만 하나?

Spring AOP

 

 

서비스 호출 전에 로깅, 꼭 AOP에서 해야만 하나?

 

웹 서비스를 만들다 보면, 모든 요청마다 공통적으로 & 반복해서 처리해야 하는 작업이 생기곤한다.

예를들어,

1. 로그인 인증 (보안)
2. Request logging (로깅)
3. 트랜잭션 관리

위와 같은 상황들이 필요한 순간, 매 컨트롤러 마다 반복적으로 코드를 삽입해서 처리하게 되면, 코드 중복 + 유지보수 어려움 이슈가 발생한다. 때문에, 공통 관심사(횡단 관심사)를 분리 해서 처리하는 기술이 필요한데, 이때 등장하는 것이 바로, Filter, Interceptor, AOP 의 개념이다.

 

Interceptor 와 Filter는 Servlet 단위에서 실행된다. 반면에 AOP는 메서드 앞에 Proxy 패턴의 형태로 실행된다. Filter가 가장 밖, 그 안에 Interceptor, 그 안에 AOP가 있는 그런 구조이다.

 

따라서, 요청이 들어오면 Filter → Interceptor → AOP → Interceptor → Filter 순으로 거쳐서 값이 반환된다.

 

 

위 그림에서 보이는 것 처럼, Filter, Servlet에서도 공통기능을 처리할 수 있다.

 

헌데 왜 AOP까지 쓰는것일까? 우리가 로깅을 할 때 AOP를 사용하는 이유는 뭘까?

 

위에서도 한번 언급 했듯, Filter/Interceptor 같은경우 HTTP 요청 레벨의 것들을 많이 처리한다. 위 그림에서 볼 수 있듯, Servlet Level그리고 DispatcherServlet 직후 지점에 위치하고 있다. 하지만, AOP의 경우 메서드 단위에서 정밀하게 실행된다. 때문에, 정확한 타이밍 제어가 가능하기에 AOP에서 로깅/트랜잭션 등에 대한 처리를 하게 되는 것이다.

 

---

 

Aspect-Oriented Programming, 관점 지향 프로그래밍

 

AOP에 대해서 조금 더 자세히 알아보자. AOP는 많이 들어봤을 것이다. AOP는 OOP를 보완하기 위해 나온 개념으로 관점 지향 프로그래밍이라 불린다. 객체 지향 프로그래밍을 했을 때 중복을 줄일 수 없는 부분을 줄이기 위해 횡단면에서 바라보고 처리한다. Spring AOP에서의 AOP또한 이 AOP에서 따온 것으로 AOP라는 개념을 Spring이 실제로 구현한 라이브러리라고 생각하면 된다.

중복되는 부분을 한 군데에서 관리하고, 비즈니스 로직은 핵심만 담당하게 하자는 것.

반복/공통 적인 로직들을 하나의 “관점(Aspect)”으로 보고, 관점을 기준으로 각각 모듈로 만들어 사용하는 방식이라고 생각하면 된다.

---

 

Proxy 패턴 기반 동작

 

Spring AOP는 위에서 말한 것 처럼, Proxy 패턴의 형태로 실행된다. Proxy 패턴이 뭐냐고?

 

Proxy → 대리 / 중계 를 뜻한다. 의미에서도 알 수 있듯, Proxy 는 원래 객체를 감싸서 대리로 요청을 처리하는 구조를 제안한다. 그러니까, Spring AOP에서는 프록시 객체가 바깥에 있고, 실제 객체를 내부에 갖고 있는 그런 구조라고 보면된다.

Spring AOP는
1. 스프링 빈 메서드 호출 자체를 가로채서 작동한다.
2. 다른 2개 (Filter, Interceptor) 보다 훨씬 더 정밀하게 특정 메서드 중심으로 작동한다.

 

대표적인 사용 목적으로는 접근제어, 로깅, 지연로딩, 보안, 트랜잭션 처리 등이 있다.

 

---

흐름

Client
  ↓
[ Proxy ] ← Spring이 만든 것 (CGLIB or JDK Proxy)
  ↓
[ RealSubject (실제 대상 객체) ]

 

 

 

다음번엔 AOP에서 사용되는 주요 개념들에 대해 알아보려 한다.