Filter, Interceptor, AOP 알아보기

개요

스프링의 HandlerInterceptor, Filter, AOP 는 비슷한 문제를 해결하려 쓰인다. 공통점은 무엇이며 차이점은 무엇일까?

Interceptor, Filter, AOP 의 공통 목적을 알아보자

공통 관심사를 처리하는 데에 있다. (Factoring out common repetitive code)

Interceptor 에 대한 설명 포스팅
Filter 에 대한 설명 포스팅

Interceptor 와 AOP 의 차이는?

일단 Interceptor 와 AOP 둘 다 스프링에서 자체적으로 기술을 제공하며, 공통 관심사 코드를 뽑아내 적용시키기 위해 나왔다. (물론 AOP 는 스프링이 원조는 아니고, 스프링에서 AOP 를 흉내낸 기술을 제공할 뿐이다.)

• AOP 는 메서드 동작의 전 후 과정에 부가로직을 입힐 수 있다.
• Interceptor 는 핸들러 동작의 전 후 과정에 부가로직을 입힐 수 있다.

Filter 는 일단 Interceptor 와 비슷하다고 치고 넘어가고 뒤에서 알아보자.

그림으로 살펴보기

위는 사용자에게 받는 요청과 사용자에게 주는 응답인 ServletRequest 와 ServletResponse 는 컨트롤러에 도달하기까지의 그림을 도식화한 것이다.

단순하게 보았을 때, Filter 는 스프링 영역 (ApplicationContext) 밖에 있고 Interceptor 와 AOP 는 스프링 영역 (ApplicationContext) 내부에 있다.

위의 그림을 보면, Filter 와 Interceptor, AOP 는 존재하는 영역이 다르며, 호출 순서도 다르다는 것을 알 수 있다.

Interceptor 의 적절한 사용 용례는?

특정한 경로에 대한 권한 체크를 한다고 생각해보자. 이를테면 /admin 은 관리자 권한이 있는 유저만 접근이 가능하도록 만든다고 할 때, Interceptor 를 이용하는 것이 더 편리할 것이다.

Controller 에서 제공하는 경로에 접근하기 전에 권한을 체크하는 것은 스프링 내부에서 핸들러를 이용하기 때문에 Interceptor 를 이용해 편리하게 공통 관심사를 적용시킬 수 있다.

AOP 의 적절한 사용 용례는?

Service 에서 수행하는 메서드가 각각 얼마나 걸리는지 시간을 측정하는 로그를 뿌리기에는 AOP 가 적절할 수 있다. Controller 로직 내부에서도 Service 에 있는 메서드를 몇번이고 호출할 수 있기 때문이다.

메서드 단위의 공통 로직은 AOP 로 적용하면 편리하다.

Filter 와 Interceptor 의 차이는?

기술 제공자

• Filter: J2EE 표준 스펙을 구현한 기술이다. 톰캣과 같은 웹 컨테이너에 의해 관리된다.
• Interceptor: 스프링에서 제공하는 기술이다. 디스패처 서블릿이 컨트롤러를 호출하기 전과 후에 응답을 참조하거나 가공한다.

관리되는 컨테이너가 각각 웹 컨테이너와 스프링 컨테이너이다.

실행 시점

• Filter
  • doFilter(): 요청이 디스패처 서블릿에 전달되기 전에 수행된다.
  • doFilter(): 응답이 디스패처 서블릿을 거치고 난 이후에 수행된다.
• Interceptor
  • preHandle(): 요청이 디스패처 서블릿에 전달된 이후에 수행된다.
  • postHandle(): 응답이 디스패처 서블릿을 거치기 전에 수행된다.

Request/Response 조작 가능 여부

필터는 Request, Response 객체 자체를 조작할 수 있다. 반면에 인터셉터는 불가능하다. 이를 조작할 수 있다는 것은 다른 객체로 변경하여 전달할 수 있다는 뜻이다.

public class CustomFilter implements Filter {
  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
    // 조작된 request, response 로 doFilter() 의 호출이 가능하다.
    chain.doFilter(request, response);
  }
}

public class MyInterceptor implements HandlerInterceptor {
  default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
    // true, false 만 반환 가능하다.
    return true;
  }
}

용도

• 사실상 비슷한 용도로도 많이 쓰는 것 같다.
  • ex. 보안, 인가 작업, 로깅, Audit
• Filter 는 스프링과 분리되어야 하는 기능을 적용 가능하다.
  • ex. 이미지/데이터 압축 및 문자열 인코딩
• Interceptor 는 스프링과 연관이 많은 작업을 하기 쉽다.
  • ex. 빈 호출에 대한 로깅, Audit

빈 등록 여부

사실상 둘 다 빈으로 등록이 가능하다고 보는 것이 맞다.

Interceptor 는 당연히 스프링에서 제공하는 기술이기에 빈 등록이 가능하다.

Filter 는 서블릿에서 제공하지만, 스프링에서 제공하는 DelegatingFilterProxy 로 프록시 필터 형태로 빈 등록이 가능하다.

스프링 부트에서는 내장 톰캣을 이용해 서블릿 컨테이너까지 스프링 부트가 제어하게 되므로 DelegatingFilterProxy 로 감싸서 등록할 필요도 없다.

레퍼런스

• Java EE 6 Filter 오라클 공식문서
• 망나니 개발자 필터 vs 인터셉터