[Spring] MVC 요청 흐름 - Intercerptor가 먼저일까? DispatcherServlet이 먼저일까?

💬 들어가기 전에

그동안 on-premise 환경에서 개발하다가 처음으로 AWS에 배포를 하게 되었다.

서버 구성은 흔히 볼 수 있는 Spring 서버 앞단에 Nginx가 있는 구조다.

 

그런데 배포가 무사히(?) 되고 이런저런 테스트를 하다가 이상한 부분을 발견했다.

 

갑자기 유효하지 않은 엔드포인트로 요청을 보내면 어떻게 될까 궁금해서 포스트맨으로 API 요청을 날려봤는데

내가 생각했던 Spring MVC 요청 흐름과 달랐다.

 

🌎 내가 인지하고 있던 Spring MVC 요청 흐름

일단 흐름을 크게 정리하면 다음과 같은 흐름으로 처리되는 것으로 알고 있었다.

Filter → DispatcherServlet → Interceptor → Controller

 

관련해서 구글링 해보면 내가 보았던 수많은 블로그들도 똑같이 설명하고 있다.

 

배포된 백엔드 구조상 컨트롤러 앞단에는 Filter도 없고 토큰 검증을 하는 Jwt 관련 Interceptor 하나밖에 없기 때문에

잘못된 엔드포인트로 요청했다면 내 예상으로는 DispatcherServlet이 핸들러를 찾지 못해 404나 502를 뱉어내야 했다.

 

근데 왠걸 Authorization 헤더가 없다고 401 에러가 떴다.

그리고 토큰을 헤더에 담아 다시 요청해보니, 그때서야 404 에러가 떴다.

 

그렇다면 DispatcherServlet이 실행되기 전에 Interceptor가 먼저 실행이 되었다는 것인데...

 

이상해서 공식문서를 찾아보았다.

 

📄 HandlerInterceptor 관련 공식 문서 설명

🔗 공식 문서:

• https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/servlet/HandlerInterceptor.html

 

공식 문서에서는 HandlerInterceptor 관련해서 다음과 같이 설명하고 있다.

 

A HandlerInterceptor gets called before the appropriate HandlerAdapter triggers the execution of the handler itself.

 

즉 인터셉터는 핸들러 어댑터가 실행되기 전에 실행된다는 것이다.

 

👋 정리

공식 문서를 봐도 너무 많은 블로그들이 반대로 적혀있어 뭔가 좀 찝찝한 결말이긴 하다.

내가 공식 문서를 잘못 찾아봤을 수도 있으니...

 

일단 이정도로 정리하고 추후에 뭔가를 더 알게 된다면 글을 수정해야겠다.

 

그리고 이전에 Jwt 검증 로직을 Filter로 만들다가 사정상 Interceptor로 만들게 되었다.

 

그렇게 바꾸면서도 영 마음이 찜찜했는데,

공식 문서에서 아래와 같은 글을 보니 Interceptor를 다시 Filter로 바꿔야 하나 고민이 된다.

출처: https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-servlet/handlermapping-interceptor.html#page-title