간소화된 종속성 관리를 위한 스타터

스프링 부트의 놀라운 측면중 하나는 종속성을 관리하게 쉽게 만들어 준다는 점이다.

애플리케이션에서 제공하는 모든 기능에는 일반적으로 frontline 종속성이 필요하다. 각 기본 종속성은 기능을 수행하기 위해 수많은 다른 보조 종속성을 통합한다.

종속성과 버젼

라이브러리를 함께 사용하려면 특정 종속성의 한 버전이 다른 종속성의 특정 버전에서만 테스트 되었을 수 있으므로 어느정도 엄격함이 필요하게 되고 이러한 문제가 불가피하게 발생하게 되면 “Dependency Whack-a-Mole”문제가 발생한다. Dependency Whack-a-Mole으로 인해 발생하는 버그를 추적하고 처리하는 데 보상은 없고, 결정적인 진단과 이를 추적하는 데 낭비되는 시간이 생긴다.

spring boot starter은 일종의 Bills of Materials(BOMs)이다. 특정 기능을 제공하는 것이 입증되는,

spring boot starter의 컨셉은 종속성을 간소화 가고 애플리케이션에 기능 셋을 추가하는데 걸리는 작업을 줄여주며, 테스트, 유지 관리 및 업그레이드 시 발생하는 오버헤드도 크게 줄인다.

간단한 배포를 위한 실행 가능한 JAR

spring boot는 애플리케이션 jar와 모든 종속 jar에서 모든 파일을 분리한 다음 단일 대상 jar로 결합하는 대신(shading이라고 불리는 방식), 스프링 부트는 새로운 관점에서 의도되고 전달된 포맷을 유지하며 jar를 중첩하는 방식을 선택했다.

jar를 셰이딩 하는 대신 중접하면 종속 jar A, 종속 jar B가 각각 다른 버전의 C를 사용할 때 발생할 수 있는 버전 충돌이 발생하지 않으므로 잠재적인 문제를 완화 할 수 있다. 또한 소프트웨어를 재 피키징 하고 다른 라이선스를 사용하는 다른 소프트웨어와 결합할 때 발생할 수 있는 법적 문제도 제거 될 수 있다.

모든 종속성이 모함된 단일 스프링 부트 jar를 사용하면 배포가 쉬워진다. java -jar <SpringBootAppName.jar> 커맨드를 실행하기만 하면 JVM이 있는 곳이면 어디에서나 애플리케이션을 실행 할 수 있다.

빌드 파일에서 단일 속성을 설정하면 스프링 부트 빌드 플러그인이 해당 단일 jar 를 자체적으로 실행 가능하게 만들 수 도 있다. 그러므로 위에 기술한 java -jar <SpringBootAppName.jar> 대신 <SpringBootAppName>.jar 만으로 실행 시킬수 있다.

자동 구성

스프링 부트는 개발자에게 반복적으로 널리 사용되는 유즈케이스에 대한 의견을 제공함에 따라 미친 생산성을 제공한다.

개발을 하다보면 몇가지 패턴이 자주 반복되는 것을 알 수 있다. 8~90%정도는 패턴에 속하는 경우가 많을 것이다.

spring data의 예를 들면, 데이터 베이스에 액세스 해야 할 때마다 해당 db에 연결을 열어야 하고, 작업을 완료하면, 해당 연결을 닫아야 한다. 이 과정을 간소화 한다면 db를 지정하면 자동으로 연결이 열리고 애플리케이션이 종료되면 연결이 종료 된다.

이러한 코드 접근 방식을 구성에 대한 관습이라고 하며, 스프링 부트는 구성에 대한 관습을 따르기 때문에 문서화된 관습을 따라 무언가를 수행하면 작성해야 하는 구성 코드가 최소화 되거나 전혀 필요하지 않다.

또한 자동 구성은 개발자를 수많은 설정 작업이 아닌 작업에 집중하게 하여, 생산성을 높인다.

다만 일반적인 유즈케이스가 아닌 경우, 자동 구성을 선택적으로 재정의 하거나 비활성화 할 수 있지만, 모든 권한을 잃게 된다. 이런 경우는 하나 이상의 프로퍼티를 설정하거나, 스프링 부트가 일반적으로 사용자를 대신하여 자동 구성하는 작업을 수행하기 위해 하나 이상의 빈을 제공하는 문제이다.(무슨 의미인지 아직 잘 모르겠음.) 즉, 아주 드물거나, 아주 간단하게 수행할 수 있는 작업이다.