choboss00
commented
8 months ago 내용 요약
-
스프링 부트는 개발의 편의를 위해 설계된 프레임워크로, 의존성 추가 시 필요한 라이브러리들을 자동으로 가져와, 사용자가 직접 버전을 설정하지 않아도 스프링 부트가 호환되는 버전을 제공하여, 쉽게 개발을 시작할 수 있게 해줍니다.
-
스프링 부트는 컨테이너리스 웹 애플리케이션 아키텍처를 지원합니다. 덕분에 스프링 부트의 메인 메소드만 실행하면 웹 애플리케이션을 쉽게 구동하고 개발할 수 있습니다.
라이브러리 살펴보기
의존성을 추가할 때, 스프링 부트는 필요한 라이브러리들을 다 가져와 편하게 개발을 할 수 있게 해줍니다. ( 내장 톰캣 등 ) 예시로, web 을 의존성 추가할 경우 그 안에 필요한 의존 라이브러리들을 함께 가져옵니다.
왜 그런가 하면, 스프링 부트를 만든 철학에 대해 알 필요가 있습니다.
1, 스프링 부트는 강한 자기 주장을 가진 도구이다.
우리가 의존성을 추가할 때, 우리가 직접 버전을 설정해줄 수도 있지만, 그렇지 않더라도 잘 동작하는 걸 볼 수 있습니다.
이처럼 우리는 스프링 부트가 추천해주는 구성과 설정을 이용하여 쉽게 개발을 시작할 수 있으며, 스프링에 대해 잘 모르더라도 스프링 부트가 추천해주는 대로 설정만 하면 스프링을 잘 활용할 수 있게 됩니다.
2. 컨테이너리스 웹 애플리케이션 아키텍처 지원
강사님이 말씀하시던 톰캣을 내장서버로 함께 띄운다는 의미를 조금만 더 깊게 생각해볼 필요가 있습니다.
일반적으로 스프링을 이용해 개발을 하는 경우, 웹 클라이언트와 서버 간 메시지 전달 방식은 다음과 같습니다.
WEB CLIENT 에서 요청을 보냄 → Servlet Container 에 존재하는 서블릿 중 하나인 디스패처 서블릿이 요청을 받게 됨 → 이후 요청을 처리할 빈 ( 컨트롤러 ) 을 찾아서 전달해줌 → 응답
이 과정에서 서블릿 컨테이너는 Tomcat 과 같은 서버를 말하며, 스프링 컨테이너는 우리가 인텔리제이 ( 혹은 sts, 이클립스 ) 에서 실행하는 스프링 서버를 의미합니다.
스프링 부트가 없던 시절, 스프링만 사용하여 배포를 하기 위해선 다음과 같은 과정을 거쳐야만 했습니다.
- 톰캣 같은 웹 애플리케이션 서버 ( WAS ) 설치
- 애플리케이션 코드를 WAR 로 빌드
- 빌드한 WAR 파일을 WAS 로 옮기고 WAS 실행 ( 배포 )
이러한 작업은 개발 환경 설정과 배포 과정이 복잡하다는 단점이 존재했고, 각 프로그램의 버전이 올라감에 따라 설정을 전부 다시해줘야한다는 문제점이 존재했었습니다.
이러한 번거로움을 해결하고자, 컨테이너리스 ( Containerless ) 웹 애플리케이션 아키텍처에 대한 요구가 생겨나게 되었고, 여기서 말하는 컨테이너란 톰캣과 같은 서블릿 컨테이너를 의미합니다.
서블릿 컨테이너란 우리가 등록한 서블릿들을 관리해주는 역할을 하며, 서비스가 동작하는 동안 메모리에 계속 떠있을 수 있도록 관리해주는 역할을 합니다.
원래라면 서블릿 컨테이너를 띄우기 위해 Tomcat 서버 ( 서블릿 컨테이너 ) 를 직접 설치하고 설정해 띄울 필요가 있습니다.
하지만 컨테이너리스 웹 애플리케이션 아키텍처를 지원해주는 경우, 이 번거로운 서블릿 컨테이너에 대한 준비를 직접 하지 않아도 됩니다. ( 스프링 부트가 이러함 )
즉 컨테이너리스 웹 애플리케이션 아키텍처란 서블릿 컨테이너에 대한 준비를 직접 하지 않아도 되는 방식을 의미합니다.
덕분에 서블릿 컨테이너에 대한 설정을 하지 않더라도, 스프링 부트가 자동으로 설정해서 서블릿 컨테이너를 띄워주며, 우리는 메인 메소드만 실행하면 서블릿 컨테이너가 동작하는 걸 확인해볼 수 있습니다.
참고
- 토비의 스프링 부트 - 인프런
- https://mangkyu.tistory.com/295
환경 설정
spring boot version : 3.2.2 java version : 17 gradle 사용 dependency : 타임리프, spring-web