Spring에서 JWT 인증 인가 위치 제안(Filter와 Interceptor) - depromeet/Took-BE GitHub Wiki

1. 문제 제기

  • 현재 Filter에서 sendError를 통해 응답 바디를 일관된 형태로 변환하고 있음.
  • 하지만 코드가 복잡해지고 유지보수성이 떨어지는 문제가 발생함.
  • Filter 대신 Interceptor를 활용하면 응답 바디를 더 쉽게 통일할 수 있지 않을까?

2. Filter를 선택한 이유 (나경호)

  • 요청을 가장 앞단에서 막을 수 있다는 점이 장점.
  • 일반적으로 인증/인가는 Filter에서 처리하는 것이 일반적이므로, 자연스럽게 Filter를 선택.
  • Filter는 보안 및 성능상 이점이 있음.
    • 요청이 DispatcherServlet까지 가지 않고 차단 가능 → 불필요한 리소스 낭비 방지.
    • 클라이언트에서 잘못된 요청을 보낸 경우, 빠르게 차단할 수 있음.

3. Interceptor를 제안한 이유 (손채영)

  • Interceptor는 SpringContainer의 DispatcherServlet 이후에 동작하므로, 요청에 대해 더 상세한 정보를 확인할 수 있음 (특히 다른 비즈니스 로직과 같이 GlobalExceptionHandler 활용이 가능하다는 점)
  • Filter에서 sendError를 호출하는 방식보다, Interceptor를 활용하여 공통된 응답 바디를 처리하는 것이 더 일관적일 수 있음.
  • 필터와 인터셉터 사이에 인증 관련 로직이 존재하는 경우, 반드시 필터에서 처리해야 하지만, 그렇지 않다면 인터셉터에서도 충분히 가능.

4. 필터 vs 인터셉터의 차이점

  Filter Interceptor
동작 시점 DispatcherServlet 실행 전 DispatcherServlet 실행 후
동작 영역 Servlet 레벨 (HttpServletRequest, HttpServletResponse) Spring 레벨 (HandlerMethod 정보 접근 가능)
주요 역할 인증, 인가, 보안, 로깅, 요청/응답 변조 컨트롤러 접근 전후 처리, 추가적인 로깅 및 비즈니스 로직 수행 가능
응답 처리 sendError()로 차단 가능 응답 조작 용이, 예외 핸들링 가능
예외 처리 예외 발생 시 직접 응답 처리 @ControllerAdvice와 연계 가능

5. 추가 참고 자료

  1. Spring에서 Filter를 사용하는 이유
  2. JWT 인증을 왜 Filter에서 처리하는가?

6. 결론 및 제안

  • Filter 유지가 적절한 경우
    • 인증/인가 같은 보안 관련 로직이 포함되어 있는 경우.
    • 요청을 가장 빠르게 차단해야 하는 경우 (불필요한 컨트롤러 접근 방지).
    • DispatcherServlet까지 가기 전에 로직을 수행하는 것이 성능적으로 더 유리한 경우.
  • Interceptor로 변경이 유리한 경우
    • 요청/응답 데이터를 조작할 필요가 있는 경우.
    • 예외 처리를 통합해서 관리하고 싶은 경우.
    • 필터와 인터셉터 사이에서 인증을 처리하는 별도의 로직이 존재하지 않는 경우.
⚠️ **GitHub.com Fallback** ⚠️