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

이번에 다룬 내용은 토비님과의 스터디에서 시작하여 토비님의 강의와 영한님의 강의 및 직접 학습하며 배운 내용들을 기반으로 작성되었습니다. 추가할 내용 있으면 공유 부탁드리겠습니다! 감사합니다:)

 

 

 

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

---

[ 기존의 스프링 배포 방식 ]

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

• 톰캣 같은 웹 애플리케이션 서버(WAS) 설치
• 애플리케이션 코드를 WAR로 빌드
• 빌드한 WAR 파일을 WAS로 옮기고(배포) WAS 실행

 

 

이러한 작업은 톰캣과 같은 WAS를 서버에 직접 설치해야 하므로 상당히 번거로울 뿐만 아니라 개발 환경 설정과 배포 과정도 복잡하는 등 많은 단점이 있었다. 예를 들어 WAR 압축파일로 만들기 위한 WEB-INF 구조 등의 작업이 필요하기도 하였고, WAS를 위한 별도 설정을 web.xml 이라는 파일에서 관리해주어야 하기도 했다.

또한 톰캣의 버전을 올려주는 작업도 상당히 힘들었다. 만약 12개의 서버가 떠있는 상황에서 보안 취약점 등과 같은 이유로 톰캣의 버전을 올려줘야 한다고 해보자. 그러면 모든 서버에 들어가서 톰캣을 다시 설치해주고, WAR 파일을 WAS로 옮기는 등의 작업이 필요한데, 대충 떠올려도 상당히 번거롭다. 이러한 번거로움은 서버 스펙이 꾸준히 올라가지 못하는데 일조하기도 하였다.

 

 

 

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

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

하지만 스프링 진영은 앞서 설명한대로 복잡한 과정들이 많이 필요했기 때문에, 개발자들의 불만이 많았다. 2012년에 스프링은 JIRA 이슈 트래커를 통해 기능 제안 등을 관리하고 있었는데(현재는 GitHub Issuses로 관리하고 있다.), 어떤 사람이 컨테이너리스(Containerless) 방식의 웹 애플리케이션 아키텍처 지원을 요구하였다.

그 내용은 다음과 같으며, 내용이 길어 이미지 상에서 생략되었다. 해당 내용은 당시에 JIRA 이슈 트래커에 등록되었지만, 현재는 GitHub Issues로 마이그레이션 되기도 하여서 두 군데 중 한 곳에서 내용을 볼 수 있다.

 

 

 

해당 내용을 요약하면 다음과 같다.

"기존의 서블릿 컨테이너에 스프링이 내장되어 의존하는 방식은 개발자들에게 다방면으로 어려움을 주고 있는 상황이다. 따라서 스프링이 애플리케이션의 설정을 처음부터 끝까지 지원하는 아키텍처를 제공해준다면, 단순히 main 메소드를 호출하는 것 만으로도 애플리케이션의 실행과 종료를 관리하게 될 것이고, 많은 불편함을 해소하고 구성들을 간소화할 수 있다"

 

 

참고로 관련 전문을 번역한 내용은 아래를 참고하도록 하자.

엔터프라이즈 개발 환경이 더욱 다양해짐에 따라 개발자는 단순한 프레임워크를 선택할 가능성이 높습니다. 이전에는 일반적이었던 서블릿 컨테이너와 같은 지식을 갖는 개발자는 점점 더 드물어지고 있습니다. 스프링 컴포넌트 외의 프레임워크와 서블릿 컨테이너에 대한 의존도는 스프링 애플리케이션을 만들고 유지보수하려는 신규 개발자의 학습 곡선을 증가시킵니다.

전통적으로 스프링 애플리케이션은 서블릿 컨테이너에 내장되었습니다. 이는 과거 대부분의 엔터프라이즈 애플리케이션이 서블릿 컨테이너에서 실행되고, 서블릿 컨테이너에 배포와 구성을 의존하던 시절에는 유용했습니다. 그러나 서블릿 컨테이너에는 신규 개발자가 이미 극복했을 것이라고 가정하기 힘든 학습 곡선이 있습니다. 학습 곡선에는 다음과 같은 것들이 포함됩니다.

• web.xml과 기타 서블릿을 지향하는 설정 개념
• WAR 디렉토리 구조
• 컨테이너 구현을 위한 항목들(포트, 쓰레드 풀 등)
• 복잡한 클래스 로딩 계층 구조
• 애플리케이션 외부에 구성된 모니터링 및 관리 기능
• 로깅 기능
• 애플리케이션 컨텍스트 루트 구성
• 기타 등등

위의 모든 항목은 일관되지 않은 방식으로 구성되므로 개발팀은 스프링 자체의 설정 모델에 더해 서블릿 컨테이너에 대해서도 학습을 해야합니다.

스프링 컴포넌트와 설정 모델을 처음부터 끝까지 활용하는 도구와 레퍼런스 아키텍처를 제공한다면, 스프링의 웹 애플리케이션 아키텍처를 상당히 단순화할 수 있다고 생각합니다. 간단히 main() 메소드에서 부트스트랩된 스프링 컨테이너 내의 공통 웹 컨테이너의 설정을 내장하고 통합시킬 수 있습니다.

오늘날에는 더 이상 컨테이너를 필요로 하지 않는 프레임워크와 플랫폼이 많이 있지만, **DropWizard**에서 가장 많은 영감을 얻을 수 있었습니다.

DropWizard에서 영감을 받았지만 Spring을 활용하는 또 다른 프로젝트는 HalfPipe입니다. 하지만 HalfPipe 만으로 충분하지 않다고 생각합니다. 진정으로 간편함을 제공하려면 전체 아키텍처를 스프링 컨테이너에 포함시켜야 한다고 생각합니다. 그 외에도 몇 가지 흥미로운 아이디어가 있긴 합니다.

저는 스프링 기반 컨테이너리스 웹 애플리케이션 아키텍처가 다음과 같은 이점을 제공할 수 있다고 생각합니다:

• 서블릿 컴포넌트 모델에 대한 지식이 필요 없는 단일 통합 컴포넌트 모델 제공
• 모든 설정이 통합되어 개발자는 컴포넌트 및 앱 설정 모두에 대해 스프링 설정 모델만 배우면 됨
• void main에서의 실행은 애플리케이션의 시작과 종료를 간소화시켜줌
• 훨씬 더 단순하고 순수한 자바 클래스 로딩 계층 구조
• 더 간단한 개발 도구. WAR를 구성하고 개발 컨테이너에 배포하기 위해 복잡한 IDE 필요 없이 메인 클래스만 실행하면 됨

이러한 아키텍처가 성공하기 위해서는 기존에 서블릿 컨테이너를 통해 구성되었던 Spring MVC와 Spring Security와 같은 일반적인 스프링 도구들을 설정하는 새롭고 간단한 방법도 필요합니다.

이러한 단순화를 달성하기 위해 스프링이 새로운 HTTP 엔진을 만들 필요는 없다고 생각합니다. Jetty와 같은 임베디드 서블릿 컨테이너를 활용하면 됩니다. 물론 가능한 많은 부분을 추상화해야 할 것입니다.

또한 이러한 애플리케이션을 순수하게 스프링 방식으로 구조화하고, 개발하고, 구성하는 방법에 대한 예제를 제시하기 위해 레퍼런스용 애플리케이션도 필요하지 않을 것이라고 생각합니다.

 

 

 

 

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

컨테이너리스(Containerless) 방식의 웹 애플리케이션 아키텍처에서 얘기하는 컨테이너는 톰캣과 같은 서블릿 컨테이너를 의미한다. 서블릿 컨테이너는 우리가 등록한 서블릿들을 관리해주는 역할을 한다.

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

 

 

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

 

 

그렇다면 이 과정에서 컨테이너리스(Containerless) 웹 애플리케이션 아키텍처란 무엇일까?

서버리스(Serverless)가 서버를 직접 준비하지 않는 것을 의미하는 것처럼, 컨테이너리스(Containerless)란 서블릿 컨테이너에 대한 준비를 직접하지 않아도 되는 방식을 의미한다. 복잡한 서블릿 구성과 설정 부분은 스프링 프레임워크에게 맡기는 것이다. 이를 통해 어려운 서블릿 컨테이너에 대한 학습을 줄일 수 있을 뿐만 아니라, 순수하게 제공해야 하는 기능 개발에만 집중할 수 있다.

 

 

 

 

 

 

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

---

[ 스프링 부트(SpringBoot)의 탄생 ]

해당 이슈를 처리하게 된 담당 개발자는 Phil Webb으로, 현재 스프링 부트 프로젝트의 리더이다.

그는 기존의 Spring 프레임워크 Core 모듈에 이를 반영하기 보다는 이 문제를 포함한 다른 여러 문제들을 해결하기 위해 SpringBoot라는 새로운 프로젝트를 시작하기로 결정하였다. 그리고 Spring One 행사에서 이러한 부분을 많이 얘기 나누었다고 한다. 또한 해당 이슈는 스프링 부트의 탄생 배경이며, 더 일찍 프로젝트를 공개하지 못해서 미안하다고 코멘트를 남겼다.

이제 우리는 서블릿을 등록하는 등의 번거로움 없이 메인 메소드만 실행하면 웹 애플리케이션을 실행할 수 있게 되었다. 뿐만 아니라 컨테이너리스에 더해 디폴트로 설정들을 제공해주는 자동 구성(Auto Config)를 포함한 다양한 것들을 만들게 되었다.

스프링 부트는 컨테이너리스 웹 애플리케이션 아키텍처를 지원하지만, 그렇다고 서블릿 컨테이너가 사용되지 않는 것이 아니다. 내부에서는 톰캣이나 네티와 같은 내장 WAS가 사용되고 있고, 스프링은 이러한 복잡한 설정들은 완전히 내장되어 보이지 않을 뿐이다.

아직도 서블릿 컨테이너에 의존적인 방식으로 남아있었다면, 스프링은 레거시 기술로 도태 되었을 수도 있다. 하지만 언제나 그랬듯 스프링은 빠른 기술의 변화에 맞춰 진화하였고, 또 다시 한번 혁신에 성공하였고, 스프링 부트는 이제 선택이 아닌 필수이다. 스프링 부트는 2014년에 1.0으로 처음 등장하여 2018년에 2.0이 나왔으며, 2022년에 3.0까지 나오며 계속해서 활발히 개발되는 중이다.

 

 

 

[ 스프링 부트(SpringBoot)의 탄생 ]

스프링 부트 공식 문서에서 스프링 부트를 소개하는 내용은 다음과 같다. 아래의 내용을 번역하면 다음과 같다.

 

 

스프링 부트는 독립 실행 가능하며, 프로덕션 수준에 이르는 스프링 기반의 애플리케이션을 만들 수 있도록 도와준다. 스프링 부트는 스프핑 플랫폼과 외부 라이브러리에 대해 독단적인(주관이 있는) 견해를 내세움으로써, 최소한의 번거로움으로 시작할 수 있도록 지원한다. 대부분의 스프링 부트 애플리케이션은 스프링 구성을 거의 필요로하지 않는다.

 

 

여기서 우리가 주목할 단어는 바로 “opinionated” 이다. opinionated란 독단적인 또는 주관이 있는 이라는 뜻으로, 스프링 부트가 스스로 사용할 도구를 선택하고 기본적인 구성을 해준다는 것이다. 따라서 개발자들은 바로 웹 애플리케이션 개발을 시작할 수 있다.

이러한 부분은 극단적인 유연함을 추구하는 기존의 스프링 프레임워크와 상당히 대비되는 관점이다. 왜냐하면 기존의 스프링은 기술적인 선택은 개발자들에게 맞기고, 대신 추상화를 통해 유연한 기술 변경을 가능하게 해주었기 때문이다.

하지만 이러한 기술 선택 및 버전 충돌 등에 의한 번거로움이 상당히 크다는 것을 스프링 부트 개발자들은 이미 파악하고 있었다. 그래서 스프링 부트는 다양한 기술들 중에서 가장 좋고 적합한 기술을 스스로 선택하고, 호환되는 라이브러리 버전들을 자체적으로 검증하고, 자동으로 필요한 빈들을 등록하는 자동 구성 기능까지 갖추게 된 것이다.

과거에 라이브러리 버전이 맞지 않아서 충돌이 발생했던 경험이 있었다. 이러한 부분을 직접 관리했던 개발자들이라면, 얼마나 귀찮고 번거로운 부분들을 프레임워크가 대신 검증하고 선택해주는지 알 수 있을 것이다. 거기에 번거로운 배포 작업도 간소화시켜주는 등 개발자들의 생산성을 엄청나게 증가시켜주니, 오늘날 스프링 부트는 선택이 아닌 필수가 되었다.

 

 

 

 

 

이번에 다룬 내용은 토비님과의 스터디에서 시작하여 토비님의 강의와 영한님의 강의 및 직접 학습하며 배운 내용들을 기반으로 작성되었습니다. 추가할 내용 있으면 공유 부탁드리겠습니다! 감사합니다:)

 

 

 

 

관련 포스팅

• POJO 프로그래밍과 스프링 프레임워크의 탄생
• 스프링 부트(SpringBoot)의 탄생 배경, 컨테이너리스(Containerless) 웹 애플리케이션 아키텍처