[Spring Boot] 스프링 부트란?

스프링 프레임워크의 등장

인터넷의 등장 이후, 1989년에 처음으로 website가 등장하게 되고 이후 인터넷과 가정용 pc 가 보급되면서 web 사용자가 급격히 증가하게 된다.

 

웹의 첫 등장부터 1990년도 중반까지는 CGI(Common Gateway Interface)라는 웹 서버 기술이 활발하게 사용 되었지만 멀티스레드를 지원하지 않아 각 요청별로 하나의 프로세스가 담당하다 보니 부화가 많이 걸리는 비효율적인 동작 방식이었다.

 

이 때에 등장한 Java는 멀티스레드를 지원하는 언어 중 하나였고, 높은 트래픽을 감당할 수 있고 개발 및 유지보수가 편리해 Java의 Servlet 기술이 자연스레 CGI 기술을 대체하게 된다.

 

이 후, 자바에서 상업용 웹 애플리케이션을 돕기 위한 EJB(Enterprise JavaBeans)가 등장하였고 EJB를 통해 웹 애플리케이션 개발이 보다 편해져 순식간에 많은 사랑을 받았지만 여전히 무겁고 과하게 복잡하다는 단점이 있었다.

 

이에 EJB의 단점들을 개선하여 나온 것이 바로 Spring Framework이다. 

 

 

 

스프링 프레임 워크의 특징

 스프링 프레임 워크의 특징으로는 크게 POJO, AOP, IoC/DI 등이 있다.

 

POJO( Plain Old Java Object )

스프링 프레임워크 이전, EJB는 상업용 애플리케이션을 위해 Java Beans를 확장한 형태로서 POJO 비해 많은 규약들이 존재했고 EJB 컨테이너에서 관리가 가능하도록 규격 인터페이스를 구혀하거나 하는 등 EJB 환경과 스펙에 종속적으로 코드를 작성해야 하는 단점이 있다.

 

그에 반해  스프링을 출시 당시부터 POJO 모델을 기반으로 채택하였는데, POJO는 이름 그대로의 순수 JAVA 객체로 특정 프레임워크나 컨테이너에 대한 종속성이 없다는 특징을 가진다. 때문에 스프링은 비교적 입문하기 쉽고, 유연하고, 단위 테스트하기 편리한 코드를 작성하는데에 이점을 가지고 있다.

 

 

AOP( Aspect Oriented Programming )

AOP는 관점 지향 프로그래밍을 뜻하는 말로, 스프링은 AOP를 통해 개발자가 비즈니스 로직에만 집중할 수 있도록 하였다. 특정 기능을 수행하는데 필요한 로직을 핵심적인 로직과 부가적인 로직으로 나누어, 부가적인 로직은 따로 분리하여 공통적으로 처리하도록 하여 핵심적인 로직에 더욱 집중할 수 있게 한 것이다.

 

그로 인해 중복 코드가 줄어들어 불필요한 코드의 수정과 유지 보수가 훨씬 용이해졌다.

 

 

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

IoC란 제어의 역전을 의미하며, 이는 작성한 메서드나 객체의 호출을 개발자가 결정하는 것이 아닌 외부, 즉 스프링 프레임워크에서 이루어지게 되는 것을 말한다.

 

이러한 객체의 호출을 스프링 프레임워크에서 결정하게 되면 객체의 생명주기(Lifecycle) 관리를 스프링 프레임워크에서 도맡아서 하기 때문에 개발자는 온전히 비즈니스 로직 작성에 집중할 수 있는 환경을 갖게 된다는 이점을 가지게 된다. 

 

또한 객체 호출에 대한 제어권을 스프링 프레임워크가 가지게 됨으로써 의존성 주입 또한 가능하게 되었는데, 이는 스프링 프레임워크가 제공하는 특별한 기능으로 객체를 직접 생산하여 사용하는 것이 아닌, 스프링 프레임워크에게 주입받아 사용하는 기능이다,

 

 

 

스프링 부트의 등장

혁신적인 스프링 프레임워크가 등장하였지만, 사용할 라이브러리들을 하나 하나 채택하고 서로 간의 호환성을 따지는 등 여전히 사용하기 어려운 문제가 있었다. 또한 시간이 지남에 따라 무거운 프레임워크보다는 빠르게 웹 애플리케이션을 개발하고 배포할 수 있는 Nodejs나 Django 같은 경량 프레임워크들이 인기를 얻어 가고 있었다.

 

이러한 배경에서 스프링 프레임워크도 Containerless 웹 애플리케이션 아키텍쳐를 지원해달라는 요청이 들어오게 되면서, 스프링 프레임워크가 출시된지 10년만에 스프링 부트가 등장하게 된 것이다.

 

하지만, 스프링 부트는 완전 새로운것이 아닌 스프링 프레임워크를 보다 쉽고 간편하게 사용하도록 등장한 것이고, 스프링 프레임워크를 기반으로 동작하기 때문에 두 개가 서로 다른 것은 아니다!! 단지, 스프링 부트가 훨씬 사용하기 편할 것일뿐!!

 

 

 

스프링 부트의 특징

스프링 부트는 스프링 프레임워크와는 다른 특징을 가지고 있다.

 

Containerless

Containerless는 Serverless와 유사한 의미를 가진다. Serverless는 개발자가 서버에 대한 설치나 관리를 신경쓰지 않고 애플리케이션을 개발하고 배포할 수 있는 환경을 뜻하며 서버가 필요하지 않음을 의미하는 것은 아닌 것처럼, Containerless 도 사용자가 Container를 신경쓰지 않고 개발할 수 있는 환경을 제공한다는 뜻이지 필요없다는 의미는 아니다.

 

기존의 스프링은 프로젝트 생성 후 추가적으로 web.xml 설정, WAR 구조, 배포관리 등등 WAS 서버를 설치 및 설정해주어야 하는 번거로움이 있었지만, 스프링 부트는 내장되어 있는 WAS 와 초기 설정들 덕분에 보다 더 개발에 집중할 수 있게 되었다.

 

 

Opinionated

스프링 프레임워크는 개발자 스스로 특정 기술에 필요한 라이브러리를 선택하고, 버전 호환성을 확인하여 수동으로 추가해주어야하는 번거로움이 존재했다.

 

하지만 스프링 부트는 Web, DB 연동, Security, Batch와 같은 기술에 필요한 여러 선택지들 중에서 꼭 필요하고 적합하다고 판단되는 라이브러리들을 미리 정해놓고 상호 호환되는 버전을 결정하여 개발자에게 제공해주기 때문에 위의 번거로움을 보완하였다.

 

 

Configuration

DB연동, MyBatis 설정 방법 등, Configuration을 지정해주는 방식 또한 기존의 불필요한 내용이 없어지고 많이 단순해졌다.

 

 

 

결론

스프링 프레임워크는 더 유연하고 더 다양한 커스터마이징에 초점을 두었기 때문에, 해당 부분에서는 강점을 가지지만 스프링 부트는 보다 더 빠르고 효율적이게 웹 애플리케이션을 개발하는데에 강점을 가지고 있다.

 

이러한 차이점이 존재하지만, 위에서도 언급하였듯이 스프링과 스프링 부트는 완전히 다른 것이 아니다. 결국 스프링 부트는 스프링 프레임워크 기반위에 돌아가는 것이고 스프링 프레임워크를 보다 편리하게 사용하기 위해 나온 것이기 때문이다.

 

 

 

 

reference : darren's devlog