스프링 부트(SpringBoot) 탄생 배경

1. 스프링 부트(SpringBoot) 의 탄생 배경, 컨테이너리스(ContainerLess) 웹 애플리케이션 아키텍처

기존의 스프링 배포 방식

• 스프링 부트가 없었던 환경에서는 배포를 하려면 다음의 번거로운 작업을 거쳐야 했다.

  • 톰캣 같은 웹 어플리케이션 서버(WAS) 설치

  • 애플리케이션 코드를 WAR 파일로 빌드

  • 빌드한 WAR 파일을 WAS로 배포하고 WAS 실행

• 이러한 작업은 톰캣과 같은 WAS 를 서버에 직접 설치해야 하므로 상당히 번거로울 뿐 아니라 개발 환경 설정과 배포 과정도 복잡하는 등 많은 단점이 있었다.

  • 예를 들어 WAR 압축파일로 만들기 위한 WEB_INF 구조 등의 작업이 필요하고, WAS 를 위한 별도 설정을 web.xml 이라는 파일에서 관리해주어야 했다.

  • 또한 톰캣의 버전을 올려주는 작업도 상당히 힘들었다. 만약 12개의 서버가 올라와 있는 상황에서 보안취약점 등을 이유로 톰캣 버전을 올려주어야 한다면, 12개 서버의 톰캣을 업데이트하고 WAR 파일을 WAS 로 옮기는 과정이 필요하다. (귀찮다..)

컨테이너리스(Containerless) 웹 애플리케이션 아키텍처에 대한 요구

• 당시의 모던한 기술들은 커맨드 라인에서 명령어 몇 개만 입력하면 기본적인 구성이 나오고, 웹 컴포넌트들이 동작할 수 있는 컨테이너가 준비되었다. (이를 통해 빠르게 개발할 수 있었다)

• 하지만 스프링 진영은 앞서 설명한대로 복잡한 과정이 필요했기에 개발자들의 불만이 많았다.

• 이에 따라 컨테이너리스 웹 애플리케이션 아키텍처에 대한 요구가 발생했다.

컨테이너리스(Containerless) 웹 애플리케이션 아케텍처란?

• 여기서 컨테이너란 톰캣과 같은 서블릿 컨테이너를 의미한다. 서블릿 컨테이너는 우리가 등록한 서블릿들을 관리해주는 역할을 한다.

• 스프링 프레임워크를 이용해 개발한다면 디스패처 서블릿을 사용하게 되는데, 디스패처 서블릿을 서블릿 컨테이너에서 이용하려면 다음과 같이 등록을 해주어야 한다.

• 그러면 서블릿 컨테이너는 요청을 처리할 서블릿을 먼저 선택한다. 스프링 프레임워크를 사용중이라면 디스패처 서블릿을 찾게 된다 그러면 요청을 디스패처 서블릿으로 전달되고, 이후에 요청을 처리할 빈(컨트롤러) 를 찾아서 위임하는 것이다.

• 그렇다면 여기서 말하는 컨테이너리스(Containerless) 웹 애플리케이션 아키텍처란 무엇일까?

  • 서버리스가 서버를 직접 준비하지 않는 것처럼,

  • 컨테이너리스란 서블릿 컨테이너에 대한 준비를 직접하지 않아도 되는 방식을 의미한다.

  • 복잡한 서블릿 구성과 같은 설정 부분을 스프링 프레임워크에 맡기는 것이다.

• 이를 통해 어려운 서블릿 컨테이너에 대한 학습을 줄이고, 순수하게 제공해야 하는 기능 개발에만 집중할 수 있다.

2. 스프링부트(SpringBoot) 탄생

• 스프링부트는 기존 스프링과 별개의 프로젝트로

• 이제는 서블릿을 등록하는 등의 번거로운 작업 없이 메인 메서드만 실행하면 웹 애플리케이션을 실행할 수 있게 되었다.

• 뿐만 아니라, 컨테이너리스에 더해 디폴트로 설정들을 제공해주는 Auto Config 를 포함한 다양한 것들을 만들게 되었다.

  • 그렇다고 서블릿 컨테이너가 사용되지 않는 것은 아니고, 내부에서 톰캣같은 내장 WAS 가 사용되고 있고, 스프링은 이러한 복잡한 설정들을 완전히 내장해 보이지 않을 뿐이다.