스프링 부트 1 - 스프링 부트의 탄생과 철학

스프링 부트란 무엇일까?

스프링 개발을 도와주는 여러가지 도구의 모음이자 스프링 자체를 확장하고 있는 프레임 워크, 라이브러리

기존의 스프링을 사용하기 위해선 너무 복잡한 고민이 필요하고, 시작을 빠르게 하기 어려웠다.

스프링이 제공하는 많은 선택지와 스프링과 함께 사용하는 표준 기술, 라이브러리를 어떤 것을 어떤 식으로 사용해야 할지에 대해서 결정해야지만 스프링 애플리케이션을 만들 수 있었다.

스프링 부트가 등장했던 2010년대 초반에 ruby on rails, node js 처럼 커맨드라인에서 몇 개의 명령어로 코딩이 가능한 프로젝트가 시작되고, 몇 가지 작업만 하면 웹 페이지 및 API를 빠르게 작성할 수 있는 고속 개발이 가능한 툴과 도구들이 인기가 있었다. 복잡한 설정을 해줘야 하는 스프링의 성격과는 달랐다.

2012년 스프링 프레임워크 프로젝트에 이슈로 등록된 ‘Improved support for ‘containerless’ web application architectures’ 에서부터 스프링 부트의 논의와 개발이 시작됐다.

https://github.com/spring-projects/spring-framework/issues/14521

스프링 부트 레퍼런스

스프링 부트의 핵심 목표(레퍼런스)

• 매우 빠르고 광범위한 영역의 스프링 개발 경험을 제공
• 강한 주장을 가지고 즉시 적용할 수 있는 기술 조합을 제공하면서, 필요에 따라 원하는 방식으로 손쉽게 변형 가능
• 프로젝트에서 필요로 하는 다양한 비기능적인 기술(내장형 서버, 보안, 메트릭, 상태 체크, 외부 설정 방식 등) 제공
• 코드 생성이나 XML 설정을 필요로 하지 않음

스프링은 사용자가 결정해야 하는 것들이 많다. 스프링 부트로 빠르게 개발이 가능한 이유는 스프링 부트가 스프링의 많은 부분을 대신 결정해주기 때문이다.

많은 부분을 대신 결정해주는 것은 단점도 존재한다. 대규모의 서비스 또는 본격적인 엔터프라이즈 수준의 애플리케이션으로 확장을 하다보면 한계에 부딪치고, 필요한 도구들이 부족한 경험을 하게 된다. 즉, 커스텀하기 어려울 수 있다.

그래서 스프링 부트는 스프링 애플리케이션을 가지고 스타트업이나 일반 기업에서 주요한 시스템을 만들 때 운영 환경에서 꼭 필요로 하는 기술들을 담았다. 빠르게 만들지만, 계속 성장하는 서비스나 대규모의 기업에서 사용할 수 있도록 커스텀이 가능하다는 것을 특징으로 내세웠다.

Containerless

Container 관리를 신경 쓰지 않아도 되는..

2012년 스프링 부트 개발의 시발점이 되는 깃 이슈의 제목에 존재하는 단어이다. 해당 개발자가 사용한 Containerless의 의미는 무엇일까?

Container가 ‘없다’ 라고 해석하기보다는, ‘개발자가 신경 쓰지 않아도 되는’ 으로 해석하는 게 알맞다. 마치 Serverless와 유사하다. server가 필요 없다는 것이 아니라, 설치 관리 등을 신경 쓸 필요 없다는 것을 의미하는 것처럼 말이다.

웹 프로그램을 개발한다는 것은 서버에서 동작하면서 기능을 제공해주는 Component를 만드는 것을 말한다. 예를 들면, ‘로그인’ 기능을 제공하는 Component가 있을 수 있다. Web Component는 Web Client로부터 Request를 받으면 동적인 콘텐츠(Dynamic Content) 를 response를 해주는 역할을 한다.

Web Container는 Web Component들의 lifecycle(메모리에 올리기, 인스턴스 생성하기, 쓰레드 생성 및 제거)을 관리하고, 정해진 룰에 따라 요청된 Request를 어떤 Web Component가 담당할지 연결(routing, mapping)해주는 역할을 한다.

자바에서는 Web Component를 Servlet(서블릿), Web Container를 Servlet Container(서블릿 컨테이너)라고 부른다. Servlet Container의 대표적인 예시가 톰켓(Tomcat)이다.

Spring Container은 Servlet Container 뒤에 존재한다. 그리고 Servlet의 역할을 하는 Bean이 존재한다.

그럼 Spring Container가 Servlet Container을 완전히 대체하면 안될까?

그 답은 ‘안되다’이다. 기본적으로 자바의 표준 웹 기술을 사용하려면 Servlet Container을 사용해야 한다.

하지만 우리는 스프링 개발만 집중하고 싶다. Servlet Container을 직접 설정하고 띄우고 싶지 않다. 톰켓 설치, war 배포, xml로 설정, port 설정, classloader 등을 직접 설정하고 싶지 않은 것이다. 진입 장벽이 높고(초반 학습 곡선이 완만하다), 그다지 학습이 도움이 되지 않는다.

다시 처음 질문으로 돌아가자. Containerless란 Servlet Container은 필요하지만, 이를 설치하고 관리, 실행 등의 수고들을 하고 싶지 않다는 뜻이다.

Servlet Container의 기본적인 세팅은 스프링 부트가 자동으로 해준다. 물론 나중에 디테일한 커스텀을 원한다면 가능하다. 일단은 몰라도 된다.

스프링 부트 소개 레퍼런스에 ‘독립실행형(standalone) 애플리케이션’이란 말이 등장한다. 이 뜻은 스프링 부트만 실행하면 자동으로 서블릿 컨테이너까지 설정 및 실행 해준다는 의미이다. 개발자가 별도로 서블릿 컨테이너를 실행시킬 필요가 없다.

Opinionated

내가 다 정해줄게. 넌 일단 개발만 해

Opinionated : 자기 의견을 고집하는
스프링 부트 소개 레퍼런스에 이 단어가 등장한다. 이는 스프링 프레임워크의 설계 철학과 상반되는 단어이다.

스프링 프레임워크의 설계 철학

• 극단적인 유연함 추구 → 추상화를 이용하여 다양한 기술을 교체하며 사용할 수 있다.
• 다양한 관점을 수용 → 표준 기술, 사용 기술, 오픈 소스 기술 등을 사용할 수 있다.
• 수많은 선택지를 다 포용

장점일 수 있겠으나, 개발자가 다 신경 써야 한다는 단점으로도 작용한다.

스프링 부트의 설계 철학은 ‘Opinionated’ 이다. 스프링 부트의 주장이 매우 강하다.
일단 이미 정해져 있는 대로 빠르게 개발하고, 디테일한 고민이나 커스텀은 나중에 하라는 의미이다.

그럼 스프링 부트가 결정해주는 것은 무엇일까? 사용 기술, 사용할 라이브러리, 버전, 구현체, 디폴트 설정값 등을 제공해준다. 스프링 부트 개발팀이 오랜 시간 고민하고 검증하는 과정을 통해 결정하고 제안해주는 표준 기술들이 있다. 우리는 이 개발팀을 믿고 사용만 하면 된다.

---

Reference

해당 게시물은 인프런 - 토비의 스프링 부트 이해와 원리을 기반으로 작성되었습니다.