Spring에서의 요청 흐름 3 - Spring MVC

Updated: Categories:

Spring MVC가 무엇인지, 그리고 필수 개념인 DispatcherServlet에 대해 알아보자~

Spring

전 포스팅에서는 Spring에서의 초기 MVC 패턴이 어떻게 생겨먹었는지(?)에 대해 알아봤다.
이번 포스팅에서 Spring MVC를 살펴보기… 전에! Spring 프레임워크의 정의에 대해 알아보자

자바 플랫폼을 위한 오픈소스 어플리케이션 프레임워크

음. 이건 얼추 알고 있는 정의인데, 여기서 프레임워크라고 부른다.
자주 헷갈리는 라이브러리, 프레임워크에 대해 살펴보면,

  • 라이브러리 : 개발자가 호출하여 사용할 수 있는 도구의 집합
  • 프레임워크 : 소프트웨어의 특정 문제를 해결하기 위한 상호 협력하는 클래스와 인터페이스의 집합

이렇게 한줄로 정의할 수 있는데, 라이브러리와 프레임워크의 가장 큰 차이점은 어플리케이션의 흐름 주도권이 누구에게 있느냐 이다.
즉, 프레임워크가 정의한 흐름 위에서 개발자가 코드를 써내려가는 스프링은 그야말로 프레임워크인 것이다.


Spring MVC

그럼 Spring MVC는 뭘까?
Spring MVC 또한 프레임워크라 할 수 있다. 여기서 갑자기 또 헷갈린다. 그럼 Spring과 Spring MVC는 다른 것인가?

Spring, Spring Boot, Spring MVC의 상관관계를 대충 나타내면 아래와 같다.

Spring은 관련 기술을 모두 통칭하는 프레임워크이고, Spring MVC는 스프링 내에 존재하는 코어 모듈 프레임워크이다.
그림을 보면 Spring Boot 또한 Spring에 포함되며, 개발자가 원하는 코어 모듈 의존성을 추가하여 사용할 수 있는 것이다.

자, 다시 본론으로 돌아와 MVC2에 비교해 Spring MVC는 어떤 점이 개선되었는지 알아보자

Spring MVC에서의 요청 흐름

MVC2에서는 서블릿이 컨트롤러 역할을 해서 직접 요청을 매핑시켜줬어야 했는데, Spring MVC에서는 DispatcherServlet 이라는 서블릿이 직접 모든 컨트롤러로 요청을 매핑시키는 것을 볼 수 있다.

따라서 컨트롤러가 늘어나도 DispatcherServletweb.xml에 등록되어 있다면 요청이 컨트롤러와 잘 매핑될 수 있는 것이다.
(Spring Boot에서는 따로 등록할 필요 없이 @SpringBootApplication이 AutoConfiguration 할때 자동으로 매핑시킨다.)

그렇다면 DispatcherServlet이 뭔지에 대해 자세히 살펴보자


DispatcherServlet

Spring MVC에서는 Front Controller 패턴을 적용하였다.
그림에서 봤듯이 Front Controller == DispatcherServlet이고 Spring Container의 제일 앞단에서 요청을 처리해주는 녀석이다.

그럼 DispatcherServlet이 어떻게 요청을 매핑하고 MVC 패턴을 적용하는지 살펴보자.

DispatcherServlet에서의 요청 흐름

그림의 숫자에 맞게 설명을 한번 써보면,

  1. 요청이 들어온다.
  2. Handler Mapping을 통해서 매핑할 핸들러를 찾아낸다 (실행할 컨트롤러 메소드를 찾는 과정)
  3. 찾아낸 핸들러를 실행시킬 수 있는 Handler Adapter를 찾는다
  4. Handler Adapter를 실행시킨다.
    • 여기서 컨트롤러가 실행되어 서비스 로직이 돌아간다.
  5. 결과값으로 나온 Model이 생성되고, 선택한 View의 이름을 반환한다
  6. 반환값의 View 이름을 가지고 View Resolver에서 해당 View 오브젝트를 찾은 후 Model과 데이터 바인딩 시킨다
  7. 최종적으로 완성된 ViewDispatcherServlet이 반환하면, 동적 웹페이지가 완성된다

위와 같은 과정을 통해서 Spring MVC 위에서 동적 웹페이지를 만들어 내는 것이다.

여기서 ViewResolver에 따라 JSP나 Thymeleaf와 같은 템플릿 엔진을 선택할 수도 있는데, 이를 좀더 자세히 알아봐야 한다.


ViewResolver

뷰 리졸버 또한 Spring Bean으로 등록되기에 WebMvcConfigurer 빈을 수정함으로써 템플릿 엔진을 변경할 수 있다.

일단 default 뷰 리졸버는 InternalResourceViewResolver로, JSP를 뷰로 사용한다.
Thymeleaf를 사용하기 위해선 뷰 리졸버에 ThymeleafViewResolver를 추가해주면 된다.

하지만 CSR이 등장하면서, 현재 스프링은 Rest API와 같은 형태로 많이 사용된다.
그럼 Rest API에서 반환되는 json은 어떻게 만들어지는 것일까?

image

위 그림과 같이 HandlerAdapter에서 뷰 리졸버가 아닌 MessageConverter가 동작하게 된다.
분명 메시지 컨버터 적용하기를 데브코스에서 배웠었는데, 너무 어려웠어서 까먹었다…


정리

이제 서블릿 컨테이너를 넘어 스프링 컨테이너의 영역까지 들어오게 되었다.
이번 포스팅에서는 간단히 DispatcherServlet의 동작에 집중해서 살펴보았는데, 사실 응답을 주기 전에 스프링 컨테이너에서 일어나는 특별한 동작들이 있다.
(스프링 배움의 길은 끝도없다 … 😇)

다음 포스팅에서는 스프링 컨테이너의 시작, Interceptor에 대해 알아보도록 하겠다.