Spring Web MVC의 Dispatcher Servlet 파헤치기

서론

보통 Spring으로 백엔드를 개발하다보면, Controller를 통해 URL를 정의해주고 요청을 받아 처리한다. 

하지만 이때 그래서 "Client의 요청이 들어오면 어떤식으로 처리가 되는 것일까" 하고 생각을 해보면 대부분 잘 모른다. 

때문에, 이번에는 실제로 요청이 들어오면 어떤식으로 처리가 되어 Client 요청을 처리하는지에 대해 정리해보았다.

 

본론

Dispatcher Servlet이란?

Dispatcher 서블릿은 Front Controller 패턴을 구현한 Spring MVC의 중앙 집중식 컨트롤러로 요청 URL을 분석해 적절한 핸들러를 결정해 호출하고 실행결과를 반환하는 역할입니다.

 

그림을 통해 좀 더 쉽게 알아볼 수 있다. 

출처: https://velog.io/@ejung803/Spring-Web-MVC%EC%9D%98-Dispatcher-Servlet%EC%9D%98-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC

 

예시로,

Spring에 Controller가 다음과 같이 정의되어 있다고 하자.

@RestController
@RequestMapping("/api") // 공통 URL prefix
public class SampleController {

    // GET 요청 예제: http://localhost:8080/api/hello
    @GetMapping("/hello")
    public String sayHello() {
        return "Hello, Spring!";
    }
}

 

그럼 이제 처음에 요청이 들어오면 바로 @GetMapping의 hello가 처리하는 것이 아니라,

Dispatcher Servlet에서 이를 가로챈다. 가로챈다기 보다는 먼저 거쳐서 지나간다는 표현이 맞다.

 

요청 과정

1. 클라이언트가 domain/api/hello 로 요청을 보냄
2. Dispatcher Servlet은 이 요청을 handler Mapping으로 보냄
3. handler Mapping은 이제 해당 엔드포인틀 가진 Controller가 있는지 확인
4. 해당 Controller로 요청을 전달하고 로직 실행

 

쉽게 생각하면 Dispatcher Servlet은 요청 처리를 위한 징검다리와 이정표라고 생각하면 편하다.

 

그렇다면, Dispatcher Servlet은 바로 요청을 처리하는 것일까? 

 

정답은 아니다. 

앞뒤로 Filter와 Interceptor가 존재하는데 아래와 같다.

 

 

Filter는 Web Context의 일부로, Dispatcher Servlet으로 넘어가기전 보안, 인코딩 설정, 로깅, CORS 등을 확인하는 작업이다.

 

즉, 만약 filter에서 걸려버린다면 해당 서비스의 아무런 정적 리소스가 로드 되지 않는다. 흔히 우리가 서버의 인바운드, 아웃바운드 Security Info를 설저할때 걸리는 부분이라고 보면 된다. 대부분 dofilter()의 메서드로 실행이된다.

 

Interceptor는 Spring Context의 일부로, Dispatcher Servlet으로 넘어가고 Controller로 넘어 가기전, 로그인 검사, 권한 체크, 비즈니스 로직 관련 등을 확인하는 작업이다.

 

가장 대표적인 예시로는 JWT나 Controller에 따른 권한, CORS등을 확인하는 작업이라고 생각하면 된다.

 

결론

결국 Dispatcher Servlet은 Spring Controller로 요청을 보내고 받는 과정에서 하나의 바리게이트 같은 역할이라고 보면 될 것 같다. 

그냥 무작정 SpringConfig, Spring Security, EC2 inbound를 설정하기 보다 이를 이해하고 프로젝트를 하면 더 좋을 것 같다.