스프링의 등장 배경과 스프링부트와의 차이는?

자바를 공부를 하다 보면 자연스럽게 스프링에 관심을 가지게 되고,

스프링을 공부를 하다 보면 한 번쯤은 다음과 같은 질문을 해보셨을 겁니다.

 

"스프링과 스프링부트는 무엇이 다르지?"

 

저도 단순하게 스프링보다 설정이 간편하고 내장 톰켓을 지원한다 정도로만 넘겼었습니다.

이번에 개인적으로 공부를 하며 비슷하지만 서로 엄연히 다른 스프링과 스프링부트에 대해 알아보기로 했습니다.

 

Java기반 웹 기술의 발전

시작하기 앞서 스프링의 등장 배경부터 스스로에게 질문해 보았습니다.

 

1989 - 1997

인터넷의 등장 이후, 1989년에 처음으로 Website가 등장하게 됩니다.

웹사이트의 첫 등장 이후 1997년에 100만 번째 도메인이 등록되고,

인터넷과 가정용 PC가 보급되면서 웹 사용자가 급격히 증가하게 되었습니다.

 

1997 - 2000

출처: https://www.protechtraining.com/bookshelf/jboss_admin_tutorial/web_tier

 

웹의 첫 등장부터 1990년도 중반까지 CGI(Common Gateway Interface)라는

웹 서버 기술이 활발하게 사용되고 있었습니다.

하지만 CGI는 멀티스레드를 지원하지 않고 각 요청별로 하나의 프로세서가 담당하다 보니

부화가 많이 걸리는 비효율적인 동작 방식을 가지고 있었습니다.

 

1995년에 첫 출시된 Java는 멀티스레드를 지원하는 언어 중 하나였고, 덕분에 높은 트래픽을 감당이 가능하고

개발 및 유지보수가 편리했던 Java의 Servlet 기술이 자연스럽게 CGI를 대체하게 됩니다.

 

1999 - 2004

상업용 웹 애플리케이션 개발을 돕기 위한 EJB(Enterprise JavaBeans)라는 하나의 스펙이 등장하게 됩니다.

EJB를 통해 웹 애플리케이션 개발이 보다 편해졌지만, 아직도 무겁고 과하게 복잡하다는 평이 많았습니다.

 

복잡하고 어려운 EJB의 대체안!

• 어려운 테스트 (Using EJB makes applications harder to test)
• 어려운 배포 (Using EJB makes applications harder to deploy)
• 객체지향 디자인의 방해요소(Using EJB with remote interfaces may hamper practicing OO design)
• 간단한 작업의 불필요한 난이도 상승 (Using EJB may make simple things hard)
• 제한적 WAS 선택 (Reduced choice of application servers)

 

위와 같은 EJB의 단점을 개선하여 나온 것이 바로 Spring Framework입니다.

스프링 프레임워크는 2004년에 첫 등장을 했고, 이로부터 10년 후 스프링부트가 첫 등장하게 됩니다.

 

스프링 프레임워크의 특징

 

 

스프링에서 주장하는 대표적인 강점으로는 POJO, AOP, IoC/DI 등이 있습니다.

위 특징들이 조금 더 현실적으로 와닿으려면 스프링 1.0 첫 출시 당시의 EJB와 비교를 해보아야 합니다.

 

POJO (Plain Old Java Object)

스프링은 출시 당시부터 POJO 모델을 기반으로 채택하였습니다.

POJO는 이름 그대로의 순수 Java 객체로 특정 프레임워크나 컨테이너에 대한 종속성이 없다는 특징이 있습니다.

덕분에 스프링은 비교적 입문하기 쉽고, 유연하고, 단위 테스트하기 편리한 코드를 작성하는데 유리하였습니다.

 

EJB는 상업용 애플리케이션을 위해 Java Beans 확장한 형태로서 POJO에 비해 많은 규약들이 존재했습니다. 

EJB Container에서 관리가 가능하도록 규격 인터페이스를 구현하거나 별도 설정을 필요로 하는 등

EJB의 환경과 스펙에 종속적으로 코드를 작성해야만 했습니다.

EJB 3.0부터 POJO를 지원한다고 합니다.

 

AOP (Aspect Oriented  Programming)

스프링은 AOP(관점 지향 프로그래밍)를 통해 개발자가 비즈니스 로직에만 집중할 수 있도록 하였습니다.

특정 기능을 수행하는데 필요한 로직을 핵심적인 로직과 부가적인 로직으로 나누어,

부가적인 로직은 따로 분리하여 공통적으로 처리하도록 하였습니다.

그로 인해 중복코드가 줄어듦으로써 불필요한 코드의 수정과 유지보수의 비용을 줄여주었습니다.

 

E = mc²
Error = (More Code)²

 

스프링에서는 JDBC, Trasaction, Logging 등에 AOP를 활용하였습니다.

위 코드는 Spring JDBC를 활용하여 DB연동을 하는 예제 코드입니다.

 

만약 AOP가 없었다면, 위처럼 SQL문을 실행하는 핵심로직 외에

DB연결과 종료와 같은 불필요한 부가로직의 공통코드가 증가되었을 겁니다.

 

IoC(Inversion of Control) / DI(Dependency Injection)

 

 

스프링은 이런 방법으로 엄청난 유연함과 간결함을 통해 EJB 개발자들의 불편한 점들을 개선시켜 주었습니다.

그렇다면 스프링과 스프링부트의 차이점은 무엇일까요?

 

스프링과 스프링부트의 차이

기존 스프링을 더 간편하게!

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

스프링부트는 스프링 첫 출시로부터 10년 후에 등장을 하게 되는데요.

스프링도 Containerless 웹 애플리케이션 아키텍처를 지원해 달라는 한 개발자의 요청으로부터 시작됩니다.

 

먼저 배경을 이해해 보자면, 스프링부트가 등장한 2010년 당시에는 JavaScript의 Node.js나 Python의 Django 같은

빠르게 웹 애플리케이션을 개발하고 배포할 수 있는 경량 프레임워크들이 많은 인기를 얻었습니다.

그에 비해 스프링은 프로젝트 생성 시점부터 실제 개발을 시작하여 코드를 작성하기까지

사용할 라이브러리들을 채택하고 서로 간의 호환성 등을 따져가면서 차근차근 프로젝트를 설계했어야 했습니다.

 

Spring Boot makes it easy to create stand-alone,
production-grade Spring based Applications that you can "just run".

 

 

 

스프링부트는 무엇이다!라는 명확한 정의는 없지만, "복잡한 고민 없이 빠르게 스프링 기반 애플리케이션 개발을 시작할 수 있게 도와주는 도구"라고 할 수 있습니다.

본격적으로 스프링부트가 스프링과 비교하였을 때 어떻게 다른지 이야기해 보도록 하겠습니다.

 

Containerless

좌) 일반적인 웹 서버구조, 우) Java기반 웹 서버 구조

웹 프로그램(Component)은 항상 Server의 내부 Container안에 존재하여야 합니다.

Client의 요청에 의해 Server에서 각각의 웹 프로그램이 동작하고, Dynamic Content를 만들어 응답해 줍니다.

ex)  회원가입, 로그인, 게시글 작성

 

여기서 말하는 Containerless란 흔히 알고 있는 Serverless라는 것과 유사합니다.

Serverless란 개발자가 서버에 대한 설치나 관리를 신경 쓰지 않고 애플리케이션을 개발하고

배포할 수 있는 환경을 의미하며 "서버가 필요하지 않다"라는 의미는 아닙니다.

 

기존 스프링 레거시 프로젝트의 경우, 프로젝트 생성 후 추가적으로 web.xml설정, WAR구조, 배포관리 등등

WAS서버를 설치 및 설정을 해주어야만 하는 번거로움이 존재했습니다. 

 

하지만 스프링부트의 경우 내장되어 있는 WAS와 초기 설정들 덕분에

개발자가 WAS를 학습하여 설치하고, 실행 및 관리하는 개발자의 수고를 제거해 주었습니다.

 

Opinionated

첫 프로젝트 생성 후 초기 라이브러리 목록. 좌) 스프링, 우) 스프링부트

스프링 레거시의 경우, 개발자 스스로 특정 기술에 필요한 라이브러리를 선택하고,

버전 호환성을 확인하여 수동으로 추가해주어야 하는 번거로움이 존재했습니다.

 

https://mvnrepository.com/search?q=JSON

예를 들어 JSON과 관련된 기능을 수행하는 라이브러리를 선택을 할 때 약 8000개의 라이브러리 중에서

원하는 라이브러리를 선택하고 버전 호환성을 확인해야 하는 과정이 불가피했습니다.

 

스프링부트는 Web, DB연동, Security, Batch와 같은 기술에 필요한 여러 선택지들 중에서 꼭 필요하고 적합하다고

판단되는 라이브러리들을 미리 정해놓고 상호 호환되는 버전을 결정하여 개발자에게 제공해 줍니다.

나아가 각 라이브러리의 Bean 설정까지 어느 정도 제공해 주어 번거로운 과정을 생략시켜 주었습니다.

 

 

Configuration

좌) 스프링 root-context.xml, 우) 스프링부트 application.yml

위 사진은 스프링과 스프링부트에서 DB연동과 MyBatis 설정을 하는 방식입니다. 

스프링부트는 보시는 것처럼 불필요한 내용이 없어지고 아주 단순해졌습니다.

 

다양한 커스터마이징 vs 빠르고 효율적인 개발

스프링과 스프링부트는 서로 다른 니즈(Needs)에서 시작되었습니다.

 

스프링은 더 유연하고, 더 다양한 커스터마이징에 초첨을 두었다면,

스프링부트는 시대의 변화에 맞춰 애플리케이션 개발의 더 빠르고 효율적인 방법을 제공하는 데 초점을 두었습니다.