Spring

Spring Boot(스프링부트) 핵심 특징과 Spring과의 관계

천방지축 개발노트 2024. 10. 30. 23:18
Spring Boot와 Spring의 관계

Springboot(스프링부트)라는 단어를 처음 마주하면 그래서 Spring Framework와 다른 거야? 다르다면 어떻게 다른 건데?라는 궁금증이 생긴다. 굳이 구분을 짓자면 이름에서도 알 수 있듯이 Springboot는 Spring과 별개이다. 그래서 Spring의 버전과 Springboot의 버전을 말할 일이 있다면 잘 주의해서 말해야 한다. 하지만 그렇다고 Springboot가 Spring을 대체하거나 승계하여 나온 새로운 기술도 아니다.

 

결론부터 말하자면, Springboot는 Spring Framework를 더 쉽게 사용하도록 돕는 도구들의 모음이다. 즉, Springboot는 Spring을 효과적으로 사용하는 방법에 대한 강한 의견이 반영된 프레임워크로써 우리는 Springboot로 Spring 프로젝트를 만든다. 결과적으로 Springboot로 Spring Framework를 사용하는 애플리케이션을 만드는 것이기 때문에, 'Spring의 동작 원리를 이해하지 못한 채로 Springboot를 잘 활용할 수는 없다' 라는 말이 그래서 나오는 것이다.

 

 

Spring Boot의 두 가지 핵심 특징

1) Springboot는 Containerless 하다.

Springboot의 역사는 Containerless 웹 개발 아키텍처의 지원 요청으로부터 논의 및 개발이 시작됐다. 아래는 실제 Spring 프로젝트의 issues tracker(이슈 관리)에 한 개발자가 개선 요청을 했던 문의글인데, 지금도 글을 볼 수 있다.

 

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

Mike Youngstrom opened SPR-9888 and commented As the enterprise development landscape grows more diverse the simpler the application framework the more likely developers are to adopt the framework....

github.com

내용을 보면, 서블릿 컨테이너에 대한 스프링의 의존도가 스프링 웹 애플리케이션을 만들려는 개발자의 학습 난이도를 높인다는 문제를 제시하고 있다. 실제로 Spring을 사용하더라도 Java의 웹 개발 환경에 적용하려면 spring 자체에 대한 지식 이외의 알아야 할 것들이 많고 생각보다 진입 장벽이 높다. 그래서 몇 가지 예를 나열하며 기능 업그레이드를 해달라는 요청이었다.

Spring project issue tracker

최종적으로 스프링의 개발자들은 위 요구사항을 수용하기는 하되, Spring을 고치기보다 Spring Boot라고 이름 붙인 새로운 프로젝트를 시작하기로 결정했고. 그러한 댓글을 남기며 정식으로 Boot 프로젝트를 공개했다.

 

어쨌든 위 이슈의 포인트인 Containerless라는 단어의 의미는 Container가 필요 없다는 것이 아니고 Serverless와 유사하다. 개발자들은 Spring 개발에 있어 서버(Servlet Container)와 관련된 모든 번거로운 작업들(설치/관리 등)을 신경 쓰지 않고 개발해서 배포하고 운영하는 방법을 원했고, Springboot는 마치 이 Container가 없는 것처럼 감춰줘서 즉, Servlet Containerless한 개발을 할 수 있게 해준다.

@MySpringBootApplication
public class HellobootApplication {
	
    public static void main(String[] args) {
        SpringApplication.run(HellobootApplication.class, args);
    }
}

 

그래서 위와 같이 Springboot가 처음 만들어준 main 메소드를 딸깍 실행하기만 하면 전혀 셋팅하지 않은 Tomcat이 동작하면서 Spring 애플리케이션이 실행되는 것이다. Springboot가 자동 구성(auto-configuration)으로 복잡한 설정을 대신해 주고 있는 것인데, 이것이 "Spring 개발(Spring을 기반으로 하는 독립 실행형 애플리케이션을 잘 만들 수 있도록)을 도와주는. Spring 자체를 확장하고 있는 프레임워크"라고 불리는 이유이다.

 

 

2) Springboot는 Opinionated 하다.

Opinionated의 사전적 정의를 찾아보면 "자기 의견을 강하게 고집하는, 주장이 강한, 독선적인" 이런 류의 뜻인데, 공식 레퍼런스에 소개되어 있는 전체 문장의 의미는 다음과 같다.

'어떤 기술을 써야 할지 많은 고민을 하고 환경 구성하는 것으로 프로젝트를 시작하는 것이 일반적일 텐데, 일단 내가 정해줄게. 고객에게 가치를 주기 위해 필요한 비즈니스 로직을 개발하는 데에만 집중하고 추가적인 건 나중에 고민하자'

SpringBoot is opinionated

Spring Framework와 Java 표준 그리고 오픈소스가 제공하는 각종 기술을 사용하기 위해 직접 등록해야 하는 객체들을 자동 구성을 통해 Springboot만의 스프링 사용방법을 제시하고 있다. 심지어 다양한 기술을 사용할 때의 최적의 구성으로 default 값들을 다 세팅하여 빈으로 등록해 준다.(유연하게 원하는 부분을 커스터마이징 가능) 그래서 Springboot가 빠르고 광범위한 영역의 Spring 개발 경험 제공한다는 말을 하는 것이다.

 

물론 필요시 직접 Bean을 생성할 수도 있지만, boot가 특정 기술을 어떻게 사용하는 게 좋겠구나 하고 자동 구성으로 만들어준 객체가 있다면, 그 의견(방법)을 따라가는 게 좋겠다. 다시 말해, 무작정 Spring 객체를 생성해서 만들지 말고 Boot가 제공하는 자동구성 빈을 우선적으로 사용하는 것이 좋다. 그래서 특정 오브젝트의 사용 방법을 넘어 Springboot가 Spring을 어떤 식으로 제공하는가? 를 파악해 보는 것도 중요한 것 같다.

 

 

Spring Boot(스프링부트)의 장단점
  특징 추가 설명
장점 빠르고 광범위한 영역의 Spring 개발 경험 제공 기존에는 Spring이 제공하는 많은 선택지 중에서 기술들을 결정하는데 고민하는 시간이 길었음. but 빠르게 Spring 기반의 프로젝트를 시작할 수 있다.
운영환경에서 사용할만한 수준으로의 발전도 어느정도 손쉽게 된다. 외부 파일인 XML을 사용하지 않는 것이 Springboot의 지향점으로 XML작성을 필요로 하지 않는다.
필요할 때 부트의 구성을 수정하거나 확장이 쉽다. boot에 내장된 디폴트 구성을 커스터마이징하는데 매우 유연하다.
단점 많은 부분을 고민하지않고 시작할 수 있기 때문에, Spring의 기본원리에 대한 이해가 없으면 결국 한계가 온다. Springboot가 Spring 기술을 어떻게 활용하는지를 이해해야 하며, 자동으로 만들어주는 구성과 디폴트 설정이 어떤 것인지 확인할 수 있어야만 기본 구성을 수정하거나 확장할 수 있다.

 

 

Spring Boot 3.0 특징

22년도 말에 나온 Springboot 3.0의 가장 큰 특징은 Spring 6 버전을 기반으로 하고 있다는 점이다.

만약 2.x 등의 이전 버전을 Springboot 3.0 이상으로 버전 업을 하려면 확인해야 하는 사항은 다음과 같다.

 

1. build.gradle에서 Springboot 버전 확인.

2. JDK버전 확인(Spring6에 맞춰 따라오는 조건들 중 이전까지는 jdk8도 가능했으나 이제는 최소 JDK 17이상을 지원하도록 설계됨)

3. gradle의 자체 버전 확인(gradle/wrapper/gradle-wrapper.properties파일). Eclipse와 IntelliJ IDEA는 Gradle과 같이 동작하는 것처럼 보이지만 사실 맞물려서 동작할 뿐 별개의 독립적인 툴이다.

4. Java 패키지명 확인. Java의 서버와 관련한 표준을 모아둔 Java EE(Java Enterprice Edition)의 새로운 이름인 jakarta EE 버전으로 패키지명을 변경해야 한다.