Spring Guide 시리즈는
스프링부트 핵심 가이드 - 스프링 부트를 활용한 애플리케이션 개발 실무책을 통해 학습 및 정리한 내용을 담고 있습니다.
이전 글에서 Spring과 특징 및 구조에 대해 알아봤는데, 이제는 Spring 프레임워크에 Boot가 붙으면 무엇이 다른지 알아보는 시간을 가져보려고 한다.
Spring, Spring Boooooooot
앞서 살펴봤던 Spring 프레임워크는 어플리케이션을 보다 쉽게 작성할 수 있도록 작성된 도구라고 했는데, 실제로 프레임워크 내부에는 기능별로 구분된 약 20여 개의 모듈이 들어있다. 근데 이렇게 기능이 많은 만큼 설정하는데 신경써야할 부분이 많고 복잡해지면서 개발자의 수명이 짧아지기 시작했다.
이런 문제를 해결하고자 나온 것이 Spring Boot다. 앞서 말했던 우리의 수명을 줄이던 복잡한 것들을 하지 않도록 새롭게 등장한 친구이다.
특징
의존성을 보다 쉽게
스프링에서는 내가 어떤 의존 모듈을 추가하고자 하면 직접 설정해야 했고, 나아가 버전을 정확하게 명시해야했다. 그냥 명시하는 것도 아니고 다른 의존 모듈들과의 호환 여부를 체크하며 버전을 찾아나서야 했던 것이다. 그러나 부트에서는 spring-boot-starer라는 멋진 의존성을 이미 제공하고 시작하기 때문에 복잡한 모듈 조합을 간단하게 해결할 수 있게 됐다.
Tomcat,JUnit를 별다른 설정없이 써보았다면, 이미 Boot의 도움을 받은 것이다.
설정도 알아서
스프링 부트는 자동 설정이라는 것을 지원하는데, 우리가 우리의 어플리케이션에 라이브러리를 추가하면 실행할 때 필요한 설정을 알아서 찾아서 관리해준다는 것이다.
@SpringBootApplication 같은 어노테이션이 이에 해당한다.
WAS 기본 제공
Web Application Server (WAS)가 내장에 기본적으로 들어있다. 우리가 웹 어플리케이션을 만든다면 spring-boot-start-web이라는 의존성을 기본적으로 사용하는데, 여기에 tomcat이라는 이름의 귀여운 고양이 WAS가 들어있다. 고양이를 좋아하지 않는다면 다른 웹 서버로 교체도 가능하다.
모니터링
우리는 어플리케이션을 만들었다고해서 끝이 아니다. 그 이후의 유지보수의 일이 가장 중요한데, 부트는 시스템이 사용하는 메모리, 스레드, 세션 같은 주요한 시스템 자원들을 모니터링하는 Spring Boot Actuator(스프링 부트 액추에이터)를 제공한다.
스프링 부트는 어떻게 동작할까?
스프링 부트를 통해 spring-boot-starter-web을 사용하는 웹 어플리케이션을 개발한다면 기본적으로 tomcat 기반의 스프링 MVC 구조로 동작하게 된다. 그림으로 쉽게 이해해보자.
flowchart LR
A(클라이언트) -->|요청| B(서블릿 컨테이너)
B(서블릿 컨테이너) -->|응답| A(클라이언트)
B(서블릿 컨테이너) <--> C(Dispatcher Servlet)
C(Dispatcher Servlet) -->|2. 컨트롤러 호출| D(핸들러 어댑터)
D(핸들러 어댑터) -->|3. 응답 가공 후 ModelAndView 반환| C(Dispatcher Servlet)
C(Dispatcher Servlet) <-->|1. 요청 URI에 매핑된 핸들러 탐색| E(핸들러 매핑)
C(Dispatcher Servlet) <--> F(뷰)
C(Dispatcher Servlet) <-->|4.뷰를 받아 리턴| G(뷰 리졸버)
D(핸들러 어댑터) <--> H(컨트롤러)
여기서 서블릿(Servlet)에 대해 알아야하는데 이는 클라이언트의 요청을 받고 결과를 반환하는 기술이다. 이 서블릿은 서블릿 컨테이너에서 관리되고, 컨테이너는 서블릿 인스턴스를 생성 및 관리한다. 앞서 귀여운 고양이 tomcat을 기억해보자. tomcat은 WAS 역할뿐만 아니라 이 서블릿 컨테이너의 역할을 담당해준다.
컨테이너는 서블릿들을 모두 싱글톤 패턴으로 관리하고, 생명주기도 관리한다. 나아가 멀티 스레딩도 지원해준다! 스프링에서는 Dispatcher Servlet이라는 친구가 서블릿의 역할을 수행한다. 똑같은 역할인데 Dispatcher가 붙었다고 생각하자. 간단히 정리를 보고 싶다면 관련 정리 포스트를 확인해도 좋을 것 같다.
위에서 봤던 다이어그램은 뷰 형식으로 리턴하는 컨트롤러인 경우의 모습이다. 하지만 뷰를 사용하지 않고 단순 JSON을 내려주는 형태라면 뷰 리졸버를 호출하지 않는다. 뷰를 사용하는 형태는 직접 찾아보고 실습해보며 공부해보는 것을 추천한다.
뷰 리졸버를 사용하지 않는 REST형식이라면 아래와 같은 모습이 된다.
flowchart LR
A(클라이언트) <--> B(Dispatcher Servlet)
B(Dispatcher Servlet) <--> REST
subgraph REST
direction TB
C(핸들러 매핑) --> D(RestController)
D(RestController) --> E(MessageConverter)
E(MessageConverter) --> F(Response HTTP)
end
여기서 MessageConverter가 요청에 해당하는 Body를 응답으로 내려주는 역할을 해준다.
MessageConverter는 어떻게 자동으로 다양한 Content-Type에 대응하여 반환해주는걸까? MessageConverter는 스프링 부트 자동 설정에 의해 HttpMessageConverter 인터페이스를 사용하고 있다. 이 인터페이스의 구현체가 굉장히 다양한데, 이는 들어오는 Content-Type를 참고해서 스프링 부트가 자동으로 알맞은 Converter를 선정하여 사용하게 된다.