Filter와 Interceptor는 어떻게 작동할까 ?

[Uechann]

• 어떤 개념인가요 ?
• 왜 존재 하나요 ?
• 어떻게 동작하나요 ?

[koreaioi]

Filter는 웹 요청/응답에 대해 공통 관심사를 처리할 수 있도록 돕습니다. (Servlet이 제공)

Interceptor는 Controller 실행 전 후 공통 관심사를 처리할 수 있도록 돕습니다. (Spring MVC 제공)

Filter나 Interceptor모두 공통 관심사를 처리하기 위한 목적이 있지만, Filter는 웹 요청/응답에 대한 관심사 Interceptor는 Controller에 호출 맥락에 따른 관심사의 차이를 가진다 생각합니다.

Filter도 url패턴으로 특정 요청에만 동작하도록 할 수 있습니다. 그러나, Handler가 정해진 뒤 수행하는 Interceptor가 처리하는 게 역할과 책임 측면에서 낫다고 생각합니다!

---

Filter는 Spring MVC가 진입하기 전, 웹 요청/응답에 대한 공통 관심사를 다룹니다. 요청/응답 로깅, 요청 인코딩, 비정상 요청 차단 etc..

Interceptor는 HandlerMapping으로 Handler가 정해진 뒤 실행되므로, 호출할 Controller가 정해진 상태로 Interceptor가 실행됩니다.
따라서, 해당 Controller 호출 맥락이 관심사라고 생각합니다.

---

Filter는 Servlet Container가 관리하는 FilterChain이라는 체인으로 동작합니다.
각 Filter는 chain.doFilter()으로 필터체인으로 엮여있는 다음 필터를 호출하고 더이상 실행할 필터가 없으면 DispatcherServlet으로 요청이 넘어갑니다.
이때, Filter는 Spring MVC 밖에서 동작하기 때문에 Filter에서 일어난 예외는 Filter단에서 따로 처리해야합니다.

Interceptor는 HandlerExecutionChain으로 동작합니다.
HandlerMapping으로 Handler를 찾은 뒤, HandlerAdapter가 Handler를 호출하기 전후로, mappedHandler.applyPreHandle()과 mappedHandler.applyPostHandle()를 호출합니다. 이때 Interceptor 구현체가 정의한 preHandle(), postHandle() 등이 실행됩니다. (메서드 중, afterCompletion도 있습니다. )

[softmoca]

Filter와 Interceptor는 모두 여러 API에 반복되는 공통 관심사를 컨트롤러 밖에서 처리하기 위해 존재한다고 생각합니다.
예를 들어 인증 확인, 요청 로깅, 인코딩, 권한 체크처럼 모든 컨트롤러 메서드마다 직접 작성하면 중복되고 실수하기 쉬운 로직을 요청 흐름 중간에 끼워 넣는 장치입니다.

둘의 가장 큰 차이는 동작 위치입니다.

Filter는 서블릿 영역의 가장 바깥에서 동작해 DispatcherServlet에 요청이 들어가기 전부터 요청/응답을 감쌀 수 있고,
Interceptor는 Spring MVC 영역 안에서 컨트롤러가 호출되기 전후에 동작합니다.

요청 흐름으로 보면 요청 → Filter → DispatcherServlet → Interceptor → Controller에 가깝습니다.

Filter는 스프링 MVC보다 앞단에서 처리해야 하는 인코딩, 보안, 로깅 같은 넓은 범위의 처리에 적합하고,
Interceptor는 어떤 컨트롤러가 호출될지 알 수 있는 위치에서 로그인 여부 확인, 경로 기반 인증, 관리자 API 접근 제한 같은 MVC 맥락의 처리에 적합하다고 이해했습니다.

특히 이번 미션의 인증 관점에서는 Interceptor를 “문지기”처럼 사용해 요청을 통과시킬지 막을지 판단하고,
이후 ArgumentResolver가 현재 로그인 사용자를 컨트롤러 파라미터로 전달하는 식으로 역할을 나눌 수 있다고 생각합니다.

Filter는 어떤 개념인가?

Filter는 서블릿 스펙에서 제공하는 요청/응답 전/후처리 장치라고 이해했습니다.
Spring MVC의 DispatcherServlet에 요청이 도달하기 전, 가장 바깥쪽에서 동작합니다.
흐름으로 보면 대략 아래와 같습니다.

HTTP 요청
→ Filter
→ DispatcherServlet
→ Interceptor
→ Controller

Filter는 Spring MVC보다 앞단에 있기 때문에,
특정 컨트롤러나 핸들러 메서드보다는 HTTP 요청/응답 자체에 가까운 처리를 담당하기 좋다고 생각합니다.

예를 들면 아래와 같은 작업이 어울립니다.

• 요청/응답 인코딩 처리
• 공통 로깅
• 보안 필터
• CORS 처리
• 요청/응답 래핑

즉, Filter는 “이 요청이 어떤 컨트롤러로 갈지”보다는,
요청이 애플리케이션에 들어오고 나가는 가장 바깥 흐름을 다루는 장치라고 생각했습니다.

Filter는 어떻게 동작하나요?

Filter는 보통 doFilter()를 통해 동작합니다.

핵심은 chain.doFilter(request, response)를 호출하느냐입니다.

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
// 요청 전처리

chain.doFilter(request, response);

// 응답 후처리

}

chain.doFilter()를 호출하면 다음 Filter 또는 DispatcherServlet으로 요청이 넘어갑니다.

반대로 특정 조건에서 chain.doFilter()를 호출하지 않으면 요청 흐름을 중간에서 끊을 수 있습니다.

if (인증_실패) {
    response.setStatus(401);
    return;
}

chain.doFilter(request, response);

즉, Filter는 요청을 다음 단계로 넘길지 말지 결정할 수 있고, 요청과 응답을 감싸거나 조작할 수도 있습니다.

다만 Filter는 Spring MVC 바깥쪽에 있기 때문에, 컨트롤러 메서드 정보나 HandlerMethod 같은 Spring MVC의 세부 정보를 활용하기에는 Interceptor보다 덜 적합하다고 생각합니다.

Interceptor는 어떤 개념인가?

Interceptor는 Spring MVC에서 컨트롤러 호출 전후에 끼어들 수 있는 장치라고 이해했습니다.
Filter보다 안쪽, 즉 DispatcherServlet 이후에 동작합니다.
흐름으로 보면 아래와 같습니다.

HTTP 요청
→ Filter
→ DispatcherServlet
→ Interceptor
→ Controller

Interceptor는 Spring MVC 안에서 동작하기 때문에,
어떤 컨트롤러가 호출될 예정인지에 대한 정보를 다룰 수 있습니다.

그래서 인증 여부 확인이나 경로 기반 접근 제어처럼 Spring MVC 요청 처리 흐름과 밀접한 공통 로직에 적합하다고 생각합니다.

이번 미션 기준으로는 Interceptor를 아래처럼 이해할 수 있을 것 같습니다.
Interceptor = 요청을 컨트롤러까지 통과시킬지 막을지 판단하는 문지기

예를 들어 로그인하지 않은 사용자가 내 예약 조회 API를 호출하면 Interceptor에서 먼저 막을 수 있습니다.

Interceptor는 어떻게 동작하나요?

Interceptor는 대표적으로 세 시점에 개입할 수 있습니다.

1. preHandle

   • 컨트롤러 호출 전 실행
   • false를 반환하면 컨트롤러로 가지 않음

2. postHandle

   • 컨트롤러 호출 후, View 렌더링 전 실행

3. afterCompletion

   • 요청 처리가 완전히 끝난 뒤 실행

인증 확인에서는 주로 preHandle()을 사용합니다.

@Override
public boolean preHandle(
        HttpServletRequest request,
        HttpServletResponse response,
        Object handler
) {
    HttpSession session = request.getSession(false);

    if (session == null || session.getAttribute("loginMemberId") == null) {
        response.setStatus(401);
        return false;
    }

    return true;
}

여기서 true를 반환하면 컨트롤러로 요청이 넘어가고, false를 반환하면 요청 흐름이 중단됩니다.

즉, Interceptor는 컨트롤러 앞에서 요청을 검사하고, 통과 여부를 결정하는 역할을 할 수 있습니다.

Filter와 Interceptor는 왜 존재하나요?

둘 다 존재하는 이유는 공통 관심사를 컨트롤러에서 분리하기 위해서라고 생각합니다.

예를 들어 모든 컨트롤러 메서드마다 아래와 같은 코드를 반복한다고 생각해볼 수 있습니다.

if (loginMember == null) {
    throw new UnauthorizedException();
}

이 방식은 문제가 있습니다.

• 컨트롤러마다 중복 코드가 생긴다.
• 어떤 API에서 인증 체크를 빠뜨릴 수 있다.
• 컨트롤러의 핵심 책임이 흐려진다.
• 인증 정책이 바뀌면 여러 컨트롤러를 수정해야 한다.

Filter나 Interceptor를 사용하면 이런 반복 로직을 한 곳으로 모을 수 있습니다.

컨트롤러는 요청을 받아 비즈니스 흐름을 호출하는 데 집중하고,
인증 확인 같은 공통 처리는 Filter나 Interceptor가 담당하게 됩니다.

즉, 존재 이유는 단순히 “중간에 끼어들기 위해서”가 아니라,
공통 관심사를 한 곳에 모아 중복을 줄이고,
컨트롤러의 책임을 명확히 하기 위해서라고 생각합니다.

Filter와 Interceptor의 차이

가장 큰 차이는 동작 위치와 다룰 수 있는 정보의 범위라고 생각합니다.

구분	Filter	Interceptor
위치	Servlet 영역	Spring MVC 영역
실행 시점	DispatcherServlet 전	DispatcherServlet 후, Controller 전후
관심사	요청/응답 자체	Spring MVC 핸들러 흐름
적합한 예	인코딩, CORS, 보안 필터, 로깅	로그인 체크, 경로 기반 인증, 관리자 접근 제한
컨트롤러 정보 접근	어려움	HandlerMethod 등을 통해 가능

Filter는 더 바깥쪽에서 넓게 동작하고,
Interceptor는 Spring MVC 안쪽에서 컨트롤러 호출 흐름에 더 가깝게 동작합니다.

그래서 “HTTP 요청 자체를 다뤄야 하는가?”에 가까우면 Filter,
“컨트롤러 호출 전후의 MVC 흐름을 다뤄야 하는가?”에 가까우면 Interceptor를 고려할 수 있다고 생각합니다.

이번 선택 미션에서 Interceptor를 어디에 쓰면 좋을까?

이번 미션에서는 Interceptor를 인증 여부 확인에 사용하기 적절하다고 생각합니다.

예를 들어 내 예약 조회, 예약 생성, 예약 취소 같은 API는 로그인한 사용자만 접근해야 합니다.

이때 각 컨트롤러마다 로그인 여부를 확인하기보다, Interceptor에서 먼저 막을 수 있습니다.

로그인 안 함
→ Interceptor에서 401
→ Controller까지 가지 않음

반대로 로그인한 사용자는 Interceptor를 통과하고, 이후 컨트롤러에서 현재 사용자 정보가 필요하면 ArgumentResolver가 @LoginMember 파라미터를 채워줄 수 있습니다.

@GetMapping("/reservations/mine")
public List<ReservationResponse> myReservations(@LoginMember Member member) {
    return reservationService.findMyReservations(member.getId());
}

이렇게 보면 역할이 나뉩니다.

Interceptor = 로그인 여부를 확인하고 요청을 통과시킬지 결정
ArgumentResolver = 통과한 요청에서 현재 로그인 사용자를 컨트롤러 파라미터로 전달

즉, Interceptor와 ArgumentResolver는 경쟁 관계가 아니라 분업 관계라고 생각합니다.

인증과 인가는 같은 위치에서 처리해야 할까?

저는 인증과 인가는 처리 위치가 다를 수 있다고 생각합니다.

인증은 “로그인했는가?”를 확인하는 것입니다.

이 정보는 세션이나 토큰만 보면 알 수 있기 때문에 Interceptor에서 처리하기 좋습니다.

세션에 loginMemberId가 있는가?
토큰이 유효한가?

반면 인가는 “이 사용자가 이 리소스를 다룰 권한이 있는가?”를 확인하는 것입니다.

예를 들어 매장 매니저가 자기 매장 예약만 관리할 수 있는지 판단하려면, 현재 사용자뿐 아니라 접근하려는 예약 데이터도 조회해야 합니다.

현재 로그인한 매니저의 storeId
접근하려는 예약의 storeId
두 값이 같은가?

이런 판단은 단순히 요청 경로나 세션만 보고 결정하기 어렵습니다.

따라서 거친 넓은 범위 수준의 인가, 예를 들어 /admin/**은 관리자만 접근 가능하다는 정도는 Interceptor에서 처리할 수 있지만,
“이 예약이 정말 이 매니저의 매장 예약인가?” 같은 세밀한 인가는 Service에서 처리하는 것이 더 자연스럽다고 생각합니다. Interceptor는 역할 기반,경로 기반의 거친 인가까지만 가능하고, 리소스 소유 여부처럼 데이터를 봐야 하는 세밀한 인가는 Service가 적절하다고 생각합ㄴ;다.

정리

정리하면 저는 이렇게 이해했습니다.

• Filter는 Servlet 영역의 바깥쪽 장치이다.
• Interceptor는 Spring MVC 영역에서 Controller 호출 전후에 동작하는 장치이다.
• 둘 다 공통 관심사를 컨트롤러 밖으로 분리하기 위해 존재한다.
• Filter는 요청/응답 자체를 다루는 넓은 처리에 적합하다.
• Interceptor는 로그인 체크처럼 Spring MVC 흐름 안에서 요청 통과 여부를 판단하는 데 적합하다.
• 인증은 Interceptor에서 처리하기 좋다.
• 현재 사용자 객체 주입은 ArgumentResolver가 담당하기 좋다.
• 세밀한 인가는 실제 데이터를 조회할 수 있는 Service에서 처리하는 것이 자연스럽다.

결론적으로 이번 미션에서는 Interceptor를 인증의 “문지기”로 사용하고,
ArgumentResolver를 현재 사용자 전달 역할로 사용하며,
리소스 소유 여부 같은 세밀한 인가는 Service에서 처리하는 방향이 가장 자연스럽다고 생각합니다.

[sangjun121]

어떤 개념인가요 ?

Filter와 Interceptor는 둘다 요청을 가로채어 공통작업을 처리하기 위한 기술입니다. 하지만 작동 위치가 서로 다르기 때문에 서로 다른 레벨의 기술 입니다.

Filter는 MVC 이전의 서블렛 레벨에서 작동하며, 스프링이 아닌 웹 Servlet 스펙 기반 기술입니다. 그래서 MVC 레벨 이전의, 즉 DispatcherServlet 이전에 작동하기 때문에 모든 요청에 대해 처리할 수 있으며, MVC 핵심 로직의 앞단에 넓은 범위의 처리에 보통 사용합니다.

그와 반면에 Interceptor는 Spring MVC가 제공하는 기술이며, Controller 실행 전,후를 제어할 수 있습니다. 따라서 Spring MVC 로직과 관련된 처리가 필요한 경우 Interceptor를 사용할 수 있습니다. 특히 매핑될 컨트롤러가 정해진 이후 실행되는 기술이기 때문에 컨트롤러의 실행 맥락과 연관되는 경우에 사용하는 것이 적절하다고 생각합니다.

웹 서버 구조도

선택 기준

작동 위치가 다르기 때문에, 해당 공통작업이 언제 처리되는지를 먼저 고려해보는 것이 중요합니다. 예를 들어, 보안의 경우, 인증되지 않은 사용자는 MVC 영역인 컨트롤러에 진입하면 안되기 때문에, 보안 작업은 가장 앞단인 Filter 레벨에서 수행해야 합니다.(스프링 시큐리티도 이런 이유로, Interceptor가 아닌 Filter를 사용합니다.)

그리고, 작업의 종류를 먼저 분류하는 것도 하나의 기준이 될 수 있습니다. 예를 들어, 인증 인가, 로깅, 사용자 정보 처리와 같은 MVC 로직과 연관된 경우 인터셉터가 적절하며, CORS 설정이나 Request 매핑과 같은 웹레벨의 작업 처리는 필터가 더 적절합니다.

추가학습

이번 주차에 예외처리에 대해 학습해 보았으니, 필터 단계에서 발생하는 예외를 어디서 처리할지 고민해보는 것도 좋을 것 같습니다!
Security Filter에서 발생한 예외를 GlobalExceptionHandler로 보내는 것이 좋을까?