실행 흐름에 끼어들기

Servlet Filter, Spring Interceptor, AOP의 동작 원리와 차이점 비교 분석

Filter, Interceptor, AOP 는 모두 스프링이 요청을 처리하는 과정에서 가로채어 흐름을 제어하는 역할을 한다.

Filter - 사용자의 요청을 가장 먼저 받으며 부가 기능에 대한 처리가 가능하고, 서블릿 컨테이너에서 관리한다.
Interceptor - 스프링 컨트롤러 호출 전, 후 에서 동작하며 컨트롤러 레벨에서의 요청을 처리할 수 있고 스프링 컨테이너에서 관리한다.
AOP - 메서드 단위에서 제어할 수 있으며 특정 행위에 대한 공통 로직을 관리할 수 있다.

구분

관리 주체

위치 (실행 시점)

주 사용 목적

Filter

Servlet Container

DispatcherServlet 진입 전

보안, 인코딩, CORS

Interceptor

Spring Container

Controller 호출 전/후

인증/인가, API 로깅

AOP

Spring Container

메서드 실행 전/후

트랜잭션, 에러 처리

사용자의 요청을 가장 먼저 처리할 수 있고, 서블릿 컨테이너에서 이를 관리하기 때문에 순수 요청과 순수 응답에 대한 제어가 가능하다.

스프링의 컨트롤러의 동작 전, 후로 요청을 낚아채어 흐름을 제어할 수 있으며, 스프링의 빈 컨테이너를 이용할 수 있다.

스프링에서 제어하는 행위에 대한 공통 로직을 제어할 수 있다. 필터와 인터셉터와 달리 사용자의 요청이 아닌 비즈니스 로직에 대한 공통적인 부분을 제어하는 데 사용한다.

세 가지 키워드 모두 공통적으로 요청을 중간에 가로채어 흐름을 제어하는 데 중점을 두고 있다.

사용자의 요청 정보를 로깅 해야 한다면 무엇을 선택할 것인가?

필터를 이용하면 사용자의 순수 요청 정보인 요청 헤더와 IP 같은 메타데이터를 얻고 정보를 활용할 수 있을 것이다.

다만, 스프링 빈을 활용할 수 없기 때문에 서블릿에서 가공한 정보만 사용할 수 있는 제한적인 부분이 생기게 된다.

컨트롤러 요청이 닿기 전과 요청을 처리한 후에 대한 정보를 가져올 수 있기 때문에 유저의 아이피 정보 뿐 아니라 어떤 유저인지 비즈니스 관점에서 사용자를 식별할 수 있는 정보를 사용할 수 있다.

인터셉터에서 구현 했듯 AOP 도 동일한 역할을 수행할 수 있지만, 사용자가 요청한 컨트롤러 외적인 행위에도 로그를 남길 수 있다.

예를 들어, AOP 를 이용한다면 사용자가 로그인 한 뒤 백그라운드로 동작하는 행위에 대한 정보를 활용할 수 있기 때문에 서버에서 동작하는 모든 흐름에 관여할 수 있게 된다.

결국, 세 가지 키워드가 왜 모두 필요한지 따져보면 책임의 분리인 것 같다. 각 역할 마다 해야 하는 책임을 두어 계층 구조를 나누어 사용 했듯 경계가 있어야 디버깅 과정이 수월하기 때문일 것 같다는 생각이 든다.

Last updated 21 days ago