스프링은 주로 웹 개발에 사용되는데 스프링의 웹 MVC 참조 설명서나 기타 여러 학습 자료를 보면 다음과 같은 유명한 흐름도를 보게 된다.

스프링 웹 MVC의 요청 처리 흐름도

이 그림은 Spring 설명서에서도 밝히고 있지만 Spring뿐 아니라 그동안 여러 웹 프레임웍에서 사용하던 방식이다. (이 그림이 실제 처리 방식이나 프레임웍들간에 꼭 들어맞지는 않는다. 개념적으로 비슷한 사상을 가지고 있다는 것이다.)

모든 사용자의 요청(즉, 웹 URL)을 “프론트 컨트롤러”라는 서블릿 하나가 받아들인 후 URL에 따라 실제 처리를 담당하는 “컨트롤러”로 요청을 넘긴다. 그러면 컨트롤러는 MVC 구조에 따라 업무 로직을 처리한 후 뷰 정보를 만들어내고 사용자에게 뷰를 보여주는 것이다.

Spring에서는 프론트 컨트롤러는 “디스패처 서블릿”이라고 하고 컨트롤러는 “핸들러”라고 한다.

그런데 그 동안 여러 프로젝트들을 진행하면서 디스패처 서블릿과 관련한 동작 항목들이 위 그림에 있는 것보다 참 다양하구나 하는 것을 알게 됐다. 주로 Spring 설명서에 의존해 Spring을 사용했는데 설명 방식으로 이해하는 것보다는 위 그림처럼 좀더 직관적이면서 기억이 쉬운 흐름도를 직접 만들어보는 게 좋을 것 같았다. 그러기 위해서는 디스패처 서블릿의 소스를 읽으면서 어떤 처리 흐름이 있는지 밟아나가야 했다.

그래서 나온 것이 아래 그림이다. 위 그림에서 디스패처 서블릿의 동작을 좀더 자세히 들여다 본 흐름도라고 볼 수 있겠다.

Spring 디스패처 서블릿 처리 흐름도

말로 풀어 설명하자면 다음과 같다. 사용자의 웹 요청이 URL 매핑에 의해 디스패처서블릿으로 들어오면,

1.  디스패처서블릿은 핸들러 인터셉터의 preHandle() 메서드를 호출한다. 핸들러 인터셉터는 Spring 사용자가 등록해놓은 사용자정의(custom) 클래스다.
2. 디스패처서블릿은 URL에 대응하는(매핑된) 핸들러(컨트롤러)의 메서드를 호출해 업무 로직을 처리하게 한다.
3. 디스패처서블릿은 핸들러 인터셉터의 postHandle() 메서드를 호출한다.
   (1 ~ 3 과정에서 오류(예외)가 발생하면 핸들러 예외 해석기 클래스의 resolveException() 메서드를 호출한다. 핸들러 예외 해석기는 Spring 사용자가 등록해놓은 사용자정의(custom) 클래스다.)
4. 디스패처서블릿은 뷰를 처리한다. 일반적으로 jsp include 또는 forward나 redirect가 발생하는 단계다.
5. 디스패처서블릿은 핸들러 인터셉터의 afterCompletion() 메서드를 호출한다.
6. 디스패처서블릿은 해당 웹 애플리케이션 컨텍스트에 서블릿 요청 처리됐음 이벤트를 발생시킨다

출처: http://start.goodtime.co.kr/