Filter → Interceptor → AOP ??

몇몇 블로그 글에서 다음과 같은 설명을 보았습니다.

이게 과연 맞는 말일까요?

AOP는 다른 선상에 둬야

위 내용은 오직 Controller, 혹은 Controller가 호출하는 하위 컴포넌트 객체에 AOP가 적용되어있을 때에만 올바른 말입니다. 하지만 스프링의 AOP는 비단 Controller 뿐만 아니라 모든 스프링 빈에 적용할 수 있습니다.

예를 들어, 여러 Interceptor들이 공유해야하는 부가로직이 있다면 Interceptor가 수행되기 전에 공통 로직을 수행하는 AOP를 만들어 분리할 수 있습니다. 이 경우 요청은 Filter -> AOP -> Interceptor 순으로 수행되므로 위 인용은 틀린 내용이 됩니다.

이러한 오해는 AOP가 Filter, Interceptor와 마찬가지로 어떠한 로직이 수행되기 전에 제어를 가로채서 부가 로직을 수행한다는 공통점이 있기에 발생하는 것 같습니다. 또한 AOP가 Controller 혹은 그 이후에 호출되는 컴포넌트들에 적용되는 경우에는 틀린말이 아니기도 합니다.

그러나 위와 같은 관점으로 바라본다면 AOP를 이해함에 있어 잘못된 인식을 갖게 될 수 있습니다. 많은 블로그 글들이 AOP에 대해 스프링 웹 애플리케이션이 요청을 처리하는 생애주기의 한 과정으로 기술합니다. Filter와 Interceptor는 생애주기로 이해해도 무방하지만, AOP까지 여기에 묶여있다면 AOP의 본질을 오해하게 될 지도 모릅니다. Spring AOP는 요청 흐름과는 독립적이며, 스프링 빈이 있는 곳이라면 어디든 적용될 수 있는 기술입니다.