스프링 부트란?

스프링 부트를 조금 더 자세히 알기 전 내가 생각하는 스프링 부트란 무엇일까?

 

스프링을 통해 개발을 한다면 수많은 관행을 따라야 합니다.

관행에 맞춰서 프레임워크의 도구를 사용해 여러 가지 설정을 해주어야 하며, 개발부터 테스트, 배포까지 모든 과정을 매우 자세하게 커스텀해야 합니다. 

 

스프링 부트는 이러한 스프링 기반의 관행을 기본적인 옵션으로 가져가되 필요한 부분을 커스텀하여 독립적으로 실행할 수 있는 애플리케이션을 많은 고민 없이 빠르게 개발할 수 있는 여러 도구(라이브러리, 설정.. 등)를 제공하는 프레임 워크라고 생각합니다. 

 

기존의 스프링으로 애플리케이션을 개발하는 것은 복잡한 고민이 필요했습니다. 

 

스프링을 어떻게 사용할 것인지 많은 고민이 동반됩니다.

다양한 표준기술, 라이브러리 중 어떻게 사용할지 결정을 해야 스프링으로 애플리케이션 개발을 시작할 수 있었습니다. 

 

2010년대 초반. 루비온레일즈, NodeJS, 파이썬 프레임워크처럼 커맨드라인에서 몇 줄을 치면 바로 개발할 수 있는 프로젝트가 생성되고 몇 가지 작업만 하면 바로 애플리케이션 개발을 시작할 수 있는 툴들이 인기가 있었습니다. 

 

하지만 반대로 스프링은 천천히 설계 이후에 개발에 들어가는 어찌 보면 약간 구시대적으로 개발을 하는 것이 일상이었습니다.

 

그렇기 때문에 스프링 진영에서는 이와 발맞춰서 스프링 기반으로 고속 개발을 할 수 있는 장점을 내세워 스프링 부트가 등장했습니다.

 

스프링 부트의 핵심 목표는 무엇일까?

 

1. 스프링 영역을 뛰어넘는 빠르고, 광범위한 경험을 제공한다.

2. 즉시 적용 가능한 기술 조합을 강제하면서도, 필요에 따라 원하는 방식으로 손쉽게 변형할 수 있다.

3. 매우 큰 서비스에서 필요로 하는 요구사항, 다양한 비기능적인 기술도 제공한다.

4. XML이 없는 스프링 개발, 코드 생성 방식을 선호하지 않는다.

 

 

"Containerless 웹 개발 아키텍처의 지원 요청" 이슈에 대한 고민으로 Spring-Boot가 만들어졌다고 한다. 

Improved support for 'containerless' web application architectures [SPR-9888] · Issue #14521 · spring-projects/spring-framework · GitHub

Improved support for 'containerless' web application architectures [SPR-9888] · Issue #14521 · spring-projects/spring-framewor

 

 

컨테이너리스 웹 개발 아키텍처?

 

우선 여기서 말하는 컨테이너가 무엇일까?  생각해 보자. 

 

과거에 웹 애플리케이션을 만들면 우리는 war 파일로 빌드하여 서블릿 컨테이너의 도움을 받았다. 

 

그렇기 때문에 서블릿에 대해 공부했고, 생명주기, 컴파일, jsp.. 등등 Http 프로토콜을 받는 지점이 서블릿 컨테이너 였고

 

서블릿 컨테이너는 서블릿들을 관리했고 그 서블릿 중 하나가 스프링 웹 컨테이너라고 할 수 있다. 

 

보통 서블릿 컨테이너를 좀 더 공통화시키기 위해 Web Container라고 부르자.

그리고 서블릿 컨테이너가 관리하는 서블릿을 공통화시켜 웹 컴포넌트라고 불러보자.

 

여기서 웹 컨테이너는 어떤 역할을 할까?

 

1. 웹 컨테이너는 웹 컴포넌트를 관리하는 역할을 한다. 즉 라이프 사이클을 관리한다.

2. 웹 컨테이너는 단 하나의 컴포넌트를 관리하지 않고 여러 개의 컴포넌트를 관리한다. 

3. 클라이언트로 오는 요청을 적절한 컴포넌트로 매핑해 주는 역할을 한다.

이러한 전통적인 구성을 사용하여 웹 애플리케이션을 개발하기 위해서는  비개발적인 부분도 개발자가  직접 하나씩 설정해주어야 했다. 

예를 들어 서블릿 컨테이너를 설치하는 과정이 필요했고, war 폴더의 구조를 정하기 위해 노력해야 했으며,

xml을 통해 서블릿 컨테이너가 어떻게 동작해야 하는지 web.xml을 통해 설정해주어야 했으며,

war로 빌드한 후 실제 컨테이너에 배치하는 과정도 필요했고 클래스로더, 로깅 등과 같은 작업을 진행해야 했다. 

 

 

서블릿 컨테이너 자체가 하나의 진입장벽이 되었다. 그래서 이슈에서 말하는 컨테이너리스 웹 개발 아키텍처를 만들어달라 요청했던 것이다. 

서블릿 컨테이너가 필요는 하지만 이를 관리하기 위해 개발자가 학습하고 적용하는 이러한 수고를 제거해 달라고 요청한 것이고  이를 받아들여서 새로운 스프링 부트 프로젝트가 등장했다.

 

이를 독립실행형 애플리케이션, Standalone application이라고 합니다. 실제 main()이라는 진입점이 있고 이를 통해 별다른 서블릿 컨테이너 설치, 배포과정 없이 즉시 실행하게 됩니다. 

 

즉 'containerless' web application architectures는 수많은 이유들에 의해 서블릿 컨테이너를 감추어달라는 하나의 요청이었고 이를 위해 Opinionated, Standalone Application인 Spring-boot가 2013년 첫 릴리즈가 되었습니다.

 

opinionated

 

강한 주장을 가진(opinionated) 도구 스프링 버전, 스프링 생태계의 프레임워크, 표준 자바 기술, 오픈소스 라이브러리 등의 의존 관계를 확인하고 버전 호환성을 체크하는 작업은 매우 고된 일이고 성공적으로 잘 해내기 쉽지 않다.

 

스프링 부트는 매 버전마다 사용할 기술의 종류를 선정하는 것만으로 사전 검증된 추천 기술과 라이브러리 구성, 의존 관계와 적용할 버전, 각 라이브러리의 세부 구성과 디폴트 설정을 제공한다.

 

스프링 부트를 사용한다면 스프링 부트가 추천하는 구성과 설정을 이용하려는 자세가 필요하다.

하지만 원한다면 스프링 부트가 제시한 구성을 오버라이드 하거나 재구성하는 것이 가능한 데, 매우 안전하고 명료한 방법을 통해서 원하는 방법으로 재구성할 수 있다.

 

정말 원한다면 스프링 부트로 시작한 프로젝트의 애플리케이션 코드를 전혀 손대지 않고, 스 프링 부트를 단계적으로 제거하는 것도 가능하다.

 

개발팀 또는 서비스의 특성에 맞게 스프링 부트 스타일의 도구를 만들어 적용할 수 있는 방법을 제공한다.

 

실제로 스프링 부트가 강제하는 구성과 설정을 이용해서 빠르게 개발이 가능하지만 감춰져 있는 부분에 대한 이해가 필요하다. 

스프링 부트가 선택한 기술과 자동으로 만들어지는 구성, 디폴트 설정이 어떤 것인지 확인하는 과정이 있으면 필요에 따라 커스터마이징 하기가 매우 수월해지고 확장도 쉬워진다.  

 

이러한 이해가 부족하면 작은 기술적인 요구 변화에도 당황하게 되고, 시스템의 발전에 따른 다양한 요구를 수용하는 것이 어려워 진다는 이야기다. 

 

마무리

 

스프링 부트를 활용하여 현재에도 미래에도 애플리케이션을 개발할 것 같다. 

 

건강상의 이유로 잠시 공부를 멈춘적이 있었다. 회복 이후 다시 개발을 하려니 많은 부분이 지워져 있었고 이를 다시 채우기 위해 노력하고 있다. 

 

스프링 부트로 최근 애플리케이션을 개발하면서 매우 신기했다. 대부분의 자동 설정으로 인해 신경 쓸게 없었고 커스텀을 위해선 검색하면 되었다. 과거와 스프링 기술을 어떻게 사용하는지 이해하려 하지 않았다. 

 

이번 설 연휴를 맞이하여 스프링 부트를 공부하면서 스프링을 이해하기 위해 공부했던 것을 다시 한 번 복습하고 이를 스프링 부트가 어떻게 활용하였는지 알아보고 어떤 기술을 스프링 부트가 강제하였는지, 이러한 구성을 커스터마이징 하기 위한 방법과 디폴트 설정, 스프링 부트의 기술을 조금 더 알아보는 시간을 가져보자.