의문의 시작
프로젝트를 만들고 있는 도중에 문득 이러한 생각이 들었다.
나는 스프링을 사용하는 것일까? 스프링 부트를 사용하는 것일까?
스프링을 사용한다고 가정을 해보면, 내가 프레임워크를 gradle에 주입 받을 때 spring-boot-starter 인 것을 보면 스프링만 사용한다고는 할 수 없다.
그렇다면 스프링 부트를 사용한다고 가정한다면, 스프링과 관련이 없는 것인가?
이렇게 의문이 들 때, 가장 이해하기 쉬운 방법은 정의를 파악하면서 어떠한 문제들로 인해 어떻게 발전해왔는지에 대한 역사의 흐름을 파악하는 것만큼 명확히 이해하기 쉬운 것은 없다고 생각한다.
스프링과 스프링부트
스프링
스프링의 정의를 살펴보면
엔터프라이즈용 Java 애플리케이션 개발을 편하게 할 수 있게 해주는 오픈소스 경량급 애플리케이션 프레임워크
스프링 원서에서는 스프링을
The Spring Framework provides a comprehensive programming and configuration model for modern Java-based enterprise applications - on any kind of deployment platform.
위에 두 설명을 보고 Java, deployment platform, enterprise의 공통점을 보았다.
스프링은 사용자들의 요구사항을 충족시키기 위해, 자바 기반의 코드를 기업이 제공하는 서비스로 이어나가는데 집중할 수 있도록 해주는 것임을 알 수 있다.
그렇다면 스프링 등장 이전에는 위와 같은 비지니스 로직 뿐만 아니라 로직을 서비스로 나가기까지에 더 많은 공부와 기술이 필요했을 것입니다.
스프링의 역할은 개발 초기에 기본 설정과 적용 할 기술(라이브러리 등)을 잘 선택해서 개발자들이 비지니스 로직에 집중할 수 있도록 도와주는 것입니다.
무엇보다도 스프링은 오픈소스 이기에, 기업 뿐만 아니라 개인이 스프링을 사용할 수도 있고, 사용자의 니즈에 맞게 스프링의 코드를 일부 수정하여 사용할 수도 있습니다.
스프링부트
스프링부트 정의를 살펴보면
스프링 부트는 스프링으로 애플리케이션을 만들 때에 필요한 설정을 간편하게 처리해주는 별도의 프레임워크입니다.
스프링 원서에서 스프링부트를
Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run".
We take an opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss. Most Spring Boot applications need minimal Spring configuration.
스프링부트는 스프링 기반으로 사용 가능한 수준의 독립실행형 어플리케이션을 만들게 도와주는 여러가지 도구들의 모임이다.
스프링부트가 나온 배경을 살펴보면, 2012년 이슈로 등록된 "Improved support for 'containerless' web application architectures" 을 통해 더 개선이 필요함을 느낀 개발자들이 많았습니다.
https://github.com/spring-projects/spring-framework/issues/14521
Containerless
Containerless 웹 개발 아키텍처를 원하는 개발자로부터 시작되었고, 서버에 대한 설치, 관리에 대한 신경을 덜 쓰기 위해 스프링부트 프로젝트가 시작되었던 것입니다.
Containerless가 무엇인지 부터 알아보아야 하는데, 컨테이너가 없다라는 의미로 해석하기엔 너무 극적으로만 생각한다고 생각했습니다. 이러한 생각을 하던 중 serverless에 관한 내용도 찾게 되었고, less라는 부분이 없다는 의미가 아니라 "신경쓰지 않도록 한다"는 의미에 가깝다는 것을 알게되었습니다.
그렇다면 개발자가 컨테이너를 고려하지 않는 다는 것을 고려해서 만든 것이 스프링부트 라면, 개발자들이 스프링부트를 사용한다면 컨테이너의 관리에 대해 신경을 안써도 된다는 의미가 됩니다.
여태 스프링부트를 쓰면서 스프링 컨테이너(Application Context)를 고려하지 않았지만, 이 내용을 알고는 있어야 된다는 것은 인지하고 있습니다. 되돌아보니 스프링부트의 수많은 장점 중 하나를 벌써 알게되었습니다.
이제 생각해보아야 한다. 어떻게 스프링부트가 이것을 관리하는 걸까?
Web 클라이언트가 요청을 보내면 Web component가 요청을 받고 동적인 컨텐츠를 response하게 된다.
Web Conatiner에서 component들의 생명주기를 관리하는 것이다. 또한 요청된 request에 해당하는 component를 연결(routing, mapping)해주는 것도 하는 것이다.
자바입장에서 본다면 component는 servlet이 될 것이고, web Container는 Servlet Container가 되는 것이다.
이렇게 웹에서 요청이 들어오면 Servlet Containe에 들어오게 되고, 그 후에 Spring 컨테이너에 들어가게 된다.
요청 -> servlet Conatainer -> Spring Container 이러한 방식으로 진행되는 것인데, 자바의 웹 표준 기술을 사용하기 위해 servlet Conatiner를 사용 해야 한다는 것이다. 그치만 servlet Container 설정은 진입 장벽이 높은 편인데다, 초반에 설정을 해두고 나중에는 사용하지 않는 다는 것이다.
돌고 돌아 봤더니 이것이 문제의 근본이었던 것이다. 나는 여태 개발 공부를 하면서 이러한 것을 설정해 본적이 없다는 것을 알게된 순간 또 한번 스프링부트의 장점을 알게 되었다. Servlet Container의 기본적인 세팅은 스프링 부트가 자동으로 해준다는 것이다. (개인이 커스텀으로 직접 할 수도 있는 건 당연)
다시 정의를 보았을 때, 독립실행형(stand-alone)이라는 말이 이 부분이라는 것임을 알 수 있다. 스프링부트를 실행하면 자동으로 서블릿 컨테이너를 설정하고 실행해주어 우리에게 익숙한 8080포트로 톰캣을 띄어주었다는 문구를 보이게 해준다.
참고
인프런 - 토비의 스프링 부트 이해와 원리
