💡이 포스팅은 토비님의 인프런 강의인 토비의 스프링 부트 - 이해와 원리를 수강하고 학습한 내용을 정리한 포스팅입니다.
토비님의 강의를 수강하며 정리한 GitHub Repository 입니다.
스프링 부트 살펴보기 챕터에서는 스프링 부트가 무엇인지, 스프링과 스프링 부트는 어떤 차이가 있는지에 대해 알아보고
스프링 부트 시작하기 챕터에서는 간단한 RestController를 만들어 스프링 부트가 어떤 식으로 동작하는지 간략하게 확인해 보는 챕터입니다.
스프링 부트 살펴보기
토비님의 강의에서도 언급되듯이, 스프링과 스프링부트는 다릅니다.
스프링 부트 공식 문서를 확인해 보면 스프링 부트는 독립 실행 가능한 개발을 쉽게 할 수 있도록 도와주는 Spring 기반의 애플리케이션이다.라고 하며,
토비님은 스프링 개발을 도와주는 여러 가지 도구의 모음이자 스프링 자체를 확장하고 있는 프레임 워크, 라이브러리라고 설명하고 있습니다.
이 부분은 강의 챕터 중 스프링 부트의 역사를 보면 알 수 있습니다.
2012년에 spring 진영에서 진행한 containerless란 프로젝트가 약 1년 동안 진행이 되었는데 1년 후 나온 결론은 spring boot라는 새로운 프로젝트를 만들어서 진행하겠다고 한 것을 통해 스프링과 스프링 부트는 다른 것임을 알 수 있습니다.
https://github.com/spring-projects/spring-framework/issues/14521
스프링 부트의 특징 중 하나로 containerless가 있는데, containerless는 스프링 부트의 첫 프로젝트의 이름에서도 언급되었는데 과연 containerless가 무엇인지에 대해 궁금했습니다.
containerless?
containerless에서 less 때문에 컨테이너가 없다?라고 생각했었는데, 그렇게 생각하니 뭔가 조금 이해하기가 어려웠습니다.
하지만 그것보다는 개발자가 컨테이너 설정에 대해 신경 쓸 필요가 없다고 이해하는 것이 더 맞는 것 같습니다.
이 부분은 Spring과 Spring Boot에서 각각 Web 프로젝트를 실행해 보았다면 이해가 쉽습니다.
Spring에서 Web 애플리케이션을 실행하기 위해서는 Spring, Java 만 알고 있어서는 안 됩니다.
Web Server도 설치해야 하고 (대표적인 Apache), 그리고 Web Application Server도 설치해야 하고 (대표적인 Tomcat) 또 Context-Path, Port 등등 HTTP 관련 지식도 알아야 하고 개발자가 이 부분도 설정을 직접 해줘야 합니다.
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee https://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<!-- The definition of the Root Spring Container shared by all Servlets and Filters -->
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/spring/root-context.xml</param-value>
</context-param>
<!-- Creates the Spring Container shared by all Servlets and Filters -->
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<!-- Processes application requests -->
<servlet>
<servlet-name>appServlet</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/spring/appServlet/servlet-context.xml</param-value>
</init-param>
<init-param>
<param-name>throwExceptionIfNoHandlerFound</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>appServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<filter>
<filter-name>CharacterEncodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>utf-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CharacterEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
<!-- <servlet-name>appServlet</servlet-name> -->
</filter-mapping>
</web-app>
위 설정은 web.xml 인데 Spring 개발 시 작성해줘야 하는데, 개발자가 이 내용들을 다 일일이 기억하지도 않고 또 한 번 설정하게 되면 거의 다시 볼 일이 없기 때문에 불필요한 시간 낭비가 발생하게 됩니다.
또한 web.xml을 작성하기 위해서 개발자들이 xml에 대한 지식도 가지고 있어야 합니다.
그리고 가장 중요한 점은 Spring 애플리케이션을 배포할 때 반드시 WAR로 패키징해야 한다는 점입니다.
하지만 Spring Boot는 공식 문서 첫 문장에서도 나오듯이 Just Run, 단지 애플리케이션을 실행하는 것 만으로 WebServer, WAS 설정을 직접 해줄 필요 없이 기본 설정으로 Web 애플리케이션이 실행되기 때문에 개발자가 신경 쓸 부분이 적어지게 됩니다.
따라서 Spring 애플리케이션과는 달리 더 이상 WAR로 패키징할 필요 없이 JAR로 패키징할 수 있게 됩니다.
✨ Spring Boot 1.4.2 까지는 WAR 패키징이 가능했지만, 1.4.3 버전부터는 WAR 패키징이 불가능하며 오직 JAR 패키징만 가능했습니다.
(여기서 WAR 패키징이 불가능하다는 말은, 패키징 자체가 가능/불가능 하다는 뜻이 아니라 WAR 패키징 후 애플리케이션이 정상적으로 동작하지 않는다는 의미입니다.)
제 생각엔 아마 Spring Boot 초창기 시기였을 때니 호환성을 위해 어느 정도 유예 기간을 둔 것이 아닐까 싶습니다.
따라서 아래 Spring Boot 특징에서도 언급되듯이 더 이상 WAR 파일로 배포할 필요가 없으며 또 WAR로 배포를 할 수도 없습니다.
위 내용에 관해서는 따로 정리해둔 Git Repository를 참고 부탁드립니다.
그리고 설정을 변경하는 경우에도 Spring에서 처럼 xml을 작성하는 것이 아닌 변경할 설정 값만 입력해 주면 됩니다.
server.servlet.context-path=/app
server.port=9090
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.url=jdbc:h2:mem:
spring.datasource.username=sa
spring.datasource.password=
그래서 Spring Boot는 property 설정을 권장하고 있으며, xml 설정은 권장하고 있지 않습니다.
하지만 xml 설정 지원이 안된다는 것은 아니기 때문에 필요에 따라서는 xml 설정도 가능합니다.
opinionated
opinionated 는 단순히 직역하면 독단적인, 자기 의견을 고집하는 이라는 뜻으로 해석이 되는데,
개발 관점에서 의역을 해보자면 Spring Boot가 자기 의견을 고집해서 어떤 기술에 대해 사용할 때 먼저 기본 설정을 제공하고, 이 설정이 마음에 들지 않고 바꾸고 싶다면 네가 알아서 바꿔라라고 이해했습니다.
containerless에서 언급했던 기본 설정으로 Web 애플리케이션이 실행 부분이 여기에 해당합니다.
따라서 개발자가 특별하게 설정을 바꾸고 싶지 않은 경우에는 Spring Boot가 제공하는 기본 설정이 있기 때문에 따로 설정에 대해서 신경 쓸 필요가 없다는 점에서 containerless, opinionated를 같이 살펴보는 것이 좋을 것 같습니다.
그리고 Spring Boot의 특징에 대해서 아래와 같이 설명이 되어 있는데, 하나씩 살펴보겠습니다.
Create stand-alone Spring applications
Embed Tomcat, Jetty or Undertow directly (no need to deploy WAR files)
Absolutely no code generation and no requirement for XML configuration
→ 이 부분은 containerless에 설명되어 있는 내용입니다.
Provide opinionated 'starter' dependencies to simplify your build configuration
→ 이 부분은 opinionated에 추가되는 내용으로 어떤 특정 기술을 사용하고 싶은 경우에도 네가 이런 기술을 사용하려면 이러이러한 라이브러리들이 필요할 거야라고 미리 해당 기술에 대한 라이브러리 묶음을 제공하고 있으며, 이 역시도 마음에 들지 않을 경우 네가 직접 다른 라이브러리를 사용해.입니다.
Automatically configure Spring and 3rd party libraries whenever possible
→ 이 부분은 opinionated에 설명되어 있는 내용입니다.
Provide production-ready features such as metrics, health checks, and externalized configuration
→ 이 부분은 Spring Boot가 제공하는 또 다른 기능들인데 토비님 강의에서는 진행하지 않기 때문에 이 부분은 나중에 알아보겠습니다.
starter dependencies
마지막으로 Spring Boot의 특징 중 starter dependencies에 대해 알아보겠습니다.
starter란 위에 설명했듯이 개발자가 어떤 기술을 사용하고 싶다면 이러이러한 라이브러리들이 필요할 거야라고 Spring Boot가 미리 해당 기술에 대한 라이브러리 묶음을 제공하는 것입니다.
게임을 해보신 분들은 보다 쉽게 이해할 수 있는데 게임에서 흔히 스타터 팩이라는 상품이 있는데 이 때의 스타터가 동일한 의미로 사용된 것입니다.
네가 어떤 포지션을 하고 싶다면 해당 포지션에서 자주 사용되는 챔피언들과 아이콘, 스킨등을 같이 제공해 줄게! 와 같이 뭔가 자주 사용될 만한 것을 묶음으로 제공한다라고 보면 될 것 같습니다.
Spring Boot에서 Web 애플리케이션을 만들기 위해 starter-web 라이브러리를 추가하면, starter-web 라이브러리는 위와 같이 여러 하위 라이브러리를 가지고 있습니다.
starter-web 이 아니었다면 json, tomcat, web 등등의 라이브러리를 일일이 추가해야 했을 것입니다.
starter dependencies를 더 찾아보고 싶다면 아래 Spring Boot GitHub를 참고하시면 됩니다.
https://github.com/spring-projects/spring-boot/tree/main/spring-boot-project/spring-boot-starters
간단하게 starter-web 부분만 확인해 보면 각 starter dependencies의 build.gradle에 작성된 라이브러리들이 그대로 다운로드된 것을 확인할 수 있습니다.
스프링 부트 시작하기
스프링 부트 시작하기 챕터는 간략하게 스프링 부트 애플리케이션의 흐름을 확인해 보는 챕터이므로 특별한 내용은 없지만,
강의 중 토비님이 사용하시는 프로그램들 중 제가 사용하지 않았던 프로그램들에 대해 정리해보려고 합니다.
SDKMAN
sdkman은 Java 기반의 개발 도구를 설치하고 관리할 수 있도록 도와주는 CLI 프로그램입니다.
sdkman은 Unix 기반 시스템에서 동작하도록 설계되었기 때문에 window에서 사용할 때는 별도의 방법이 필요합니다.
sdkman 설치와 사용 방법에 대해서는 아래 포스팅에 정리해 두었으니 참고 부탁드립니다.
HTTPie
httpie는 터미널 환경에서 http 요청을 보내고 응답을 확인할 수 있게 해주는 프로그램인데,
httpie 또한 리눅스나 맥에서는 apt, brew를 통해 바로 설치가 가능하지만 window에서는 먼저 파이썬을 설치 후 pip를 이용해 httpie를 설치해야 합니다.
저는 강의를 들을 때는 Postman을 사용했지만, 추가로 HTTPie 설치와 사용 방법에 대해서는 아래 포스팅에 정리해 두었습니다.
'Lecture > 토비의 스프링 부트 - 이해와 원리' 카테고리의 다른 글
토비의 스프링 부트 - 자동 구성 기반 애플리케이션 (0) | 2023.02.12 |
---|---|
토비의 스프링 부트 - DI와 테스트, 디자인 패턴 (0) | 2023.02.08 |
토비의 스프링 부트 - 독립 실행형 스프링 애플리케이션 (1) | 2023.02.05 |
토비의 스프링 부트 - 독립 실행형 서블릿 애플리케이션 (0) | 2023.02.02 |
토비의 스프링 부트 - 시작하기 (0) | 2023.01.30 |
댓글