[Spring] 스프링 디스패처 서블릿 (Dispatcher Servlet)

서블릿이 무엇인지는 지난 포스팅 에서 살펴봤다. 이번엔 서블릿이 무엇인지 호기심을 갖게 한 스프링의 디스패처 서블릿에 대해서 살펴보려 한다.

 

디스패처 서블릿 (Dispatcher Servlet)

---

디스패처 서블릿에서 dispatch 는, 보내다라는 뜻을 가지고 있다. 이러한 단어를 포함하고 있는 디스패처 서블릿은 스프링 어플리케이션의 최전방에서 HTTP 프로토콜로 들어오는 모든 요청을 받아 적합한 컨트롤러에 위임하는 프론트 컨트롤러라 볼 수 있다.

 

보다 자세하게 설명을 하자면, 클라이언트로부터 어떤 요청이 오면 톰캣과 같은 서블릿 컨테이너가 요청을 받게 된다. 그리고 이 모든 요청을 프론트 컨트롤러인 디스패처 서블릿이 받아서 공통적인 작업을 수행한 뒤 해당 요청을 처리할 컨트롤러 빈을 getBean() 메소드로 호출해서 받아와 요청에 적합한 컨트롤러의 메소드를 실행시킨다. 예외가 발생했을 때 일관된 방식으로 처리하는 것 또한 프론트 컨트롤러인 디스패처 서블릿에서 담당하고 있다.

 

NOTE.
여기서 프론트 컨트롤러 (Front Controller) 라는 표현이 자주 사용되는데, 프론트 컨트롤러는 주로 서블릿 컨테이너의 제일 앞단에서 서버에 들어오는 클라이언트의 모든 요청을 받아 처리하는 컨트롤러로써, MVC 구조에서 함께 사용되는 디자인 패턴이다.

 

 디스패처 서블릿의 장점

---

Spring MVC 는 디스패처 서블릿이 등장함에 따라 web.xml 의 역할을 상당히 축소시켰다. 기존에는 모든 서블릿에 대해서 URL 매핑을 하기 위해 web.xml 파일에 모두 등록해야 했지만, 디스패처 서블릿이 해당 어플리케이션으로 들어오는 모든 요청을 핸들링하고 공통 작업을 처리하면서 상당히 편리하게 이용이 가능해졌다.

 

디스패처 서블릿의 기능 처리를 표현하면 아래 그림과 같다.

디스패처 서블릿의 요청 처리 흐름

디스패처 서블릿이 모든 요청을 받아 각각의 컨트롤러로 매핑해주는 방식은 효율적으로 보인다. 하지만 디스패처 서블릿이 모든 요청을 처리하다보니 이미지나 HTML 등과 같은 정적 리소스에 대한 요청까지도 모두 가로채 정적 리소스를 불러오지 못하는 상황도 발생하곤 했다.

 

이러한 문제를 해결하기 위해 개발자들은 두 가지 방안을 고안했는데, 그 방안은 다음과 같다.

1. 정적 리소스에 대한 요청과 어플리케이션에 대한 요청 분리

첫 번째 방안은, 클라이언트의 요청 자체를 두 개로 분리하는 것이다.

• /apps 의 URL 로 접근할 경우 디스패처 서블릿이 처리를 담당
• /resources 의 URL 로 접근할 경우 디스패처 서블릿이 컨트롤할 수 없는 요청이므로 담당하지 않음

이러한 방식은, 앞서 언급한 문제는 해결할 수 있지만 소스 코드가 상당히 지저분해지며 모든 요청에 대해 /apps 나 /resources URL 을 붙여야 하므로 직관적인 설계가 될 수 없다.

2. 어플리케이션에 대한 요청을 탐색하고, 없을 경우 정적 리소스에 대한 요청으로 처리

두 번째 방안은 모든 요청에 대해 디스패처 서블릿이 적합한 컨트롤러를 탐색하고, 해당 요청에 대한 컨트롤러를 찾을 수 없는 경우에 2차적으로 설정된 정적 리소스 경로를 탐색해 리소스를 찾는 방식이다. 이렇게 영역을 분리하면 효율적인 리소스 관리가 가능할 뿐 아니라 추후에 확장이 용이하다는 장점을 가지게 된다.

 

#Reference.

[Spring]Dispatcher-Servlet(디스패처 서블릿)이란?