※ 이 포스트는 스프링 실습 과정에서 작성하기 때문에 정보가 부정확할 수 있는 부분이 있습니다. 블로그 학습 개발은 위험이 항상 동반됩니다. 따라서 참고만 해주시고 틀린 부분이 있을 경우 알려주시면 감사하겠습니다.
* 비유는 언제나 원관념이 일정 부분 희생됩니다. 이를 감안하셔서 너무 비유에 매몰되지 마시고 처음 학습하신다면 스스로 정확한 개념을 따로 더 학습하시길 바랍니다.
이번 포스트는 인프런 강의 중 김영한님의 '스프링 핵심원리 기본편'과 토비님의 '토비의 스프링 부트' 를 수강하고 배운 내용을 정리하여 작성하였습니다. 그렇기에 조금 더 내용을 깊게 알기 원하시면 직접 강의를 수강하시길 추천합니다.
자 이제 지금껏 자바의 역사, 서블릿, MVC, 프론트 컨트롤러를 왜 포스팅했었는지 정리하는 최종장입니다. 지금껏 포스트를 잘 따라오셨다면 이번 포스트를 보고 스프링 학습 시 단골 질문인 '스프링 부트는 스프링과 뭐가 다른가요?'에 대한 대답을 쉽게 하실 수 있을 것이라 생각하며 진행하겠습니다.
❗ 이번 포스팅은 시리즈의 마지막 정리이자 주니어를 위해 이해가 쉽도록 한 글이므로 장황한 예시보다는 비유를 많이 사용할 것입니다. 따라서 자세한 예의 경우는 링크를 첨부하는 것으로 대신하겠습니다.
❗ 글 시작 전에 맨 처음 짚고 넘어가야할 것은 '토비의 스프링'의 저자이신 토비님이 말하시길 '공식 reference에서조차 스프링 부트가 정확히 무엇인지 명확하게 정의하지 않는다고 합니다. 사실 20년 넘게 스프링 개발을 하신 토비님도 스프링 부트를 프레임워크다! 라이브러리다!라고 정의하는 것이 아닌 도구의 모음이다. 정도로 말씀하셨구요. 하지만 이번 포스트에선 설명을 위해 스프링 부트를 좀 더 프레임워크에 가깝게 말하고자 한다는 점 유의해 주셨으면 합니다.
* 잘 모르시는 기술은 로그인 필요 없이 이 곳에서 AI에게 물어보세요!
우리가 스프링 부트를 처음 배울 때나 개발 면접에서나 늘 물어보는 질문이 있습니다.
스프링과 스프링 부트의 차이는 뭘까요?
잘 모를 때 이를 알아보려 해도 정리된 글들을 보면 대부분 Configuration 자동화, Dependency 버전 관리, 편리한 배포처럼 '부트를 사용하면 좀 더 편리하게 스프링 프레임워크를 사용할 수 있게 된다' 정도에서 끝이 납니다. 물론 이는 틀린 말도 아니고 사실 이런 설정들을 편하게 해주는 것이 엄청나다는 것은 당연합니다. 하지만 이 정도에서 학습이 넘어간다면 나중에 꽤나 고생할 것이라 생각합니다.
일단 먼저 알아야할 것은 Spring과 Spring Boot는 서로 다른 framework라는 것입니다. 만약 이 글을 보는 분이 스프링 부트만 공부하고서 스프링도 다룰줄 안다고 생각하시면 완전히 틀렸습니다. 혹여 서블릿 컨테이너와 스프링 컨테이너가 어떻게 구성되어 돌아가는지 아신다면 완전히는 아니겠네요. 이 부분은 뒤에서 따로 더 언급하겠습니다.
자세한 설명을 미루고 둘의 관계를 아주 이해하기 쉽게 예를 들어보자면 우리가 어릴 때 공부하던 수학책과 수학 익힘책의 관계라고 할 수 있습니다. 분명 두 책은 동일한 수준의 수학 내용을 학생에게 이해시키기 위한 공통의 큰 목적을 가졌습니다. 하지만 두 책은 엄연히 다른 책입니다. 수학 책의 내용을 대부분 수학 익힘책 역시 담고 있지만 수학 익힘책은 이론적인 내용을 숙지한 학생을 위해 설명을 덜어내고 실전적인 문제가 주를 이루고 있습니다. 따라서 학생 대다수가 가진 당장의 목적인 시험 성적의 상승을 위해서라면 수학책보단 수학익힘책을 학습하는 것이 유리할 것 입니다. 하지만 수학책에 적힌 이론을 대충 넘어가고 익힘책의 문제만 풀어서 시험을 잘 봤다고 그 사람이 과연 수학을 잘한다고 할 수 있을까요? 결국 자신에게 모자란 부분이 이론이라면 수학 책을, 실전이라면 수학 익힘책을 보는 것이 옳을 것입니다.
이도 마찬가지입니다. 초보 개발자들의 목적은 복잡한 설정을 거쳐 개발 과정들을 차근차근 배우는 것보다는 우선 백엔드(WAS)를 구축하는 겁니다. 그렇지만 스프링을 처음부터 사용해서 개발에 입문한다면 대부분의 경우 아마 서버 구축도 전에 흥미를 잃게 되리라 생각합니다. 이를 위해 EJB보다 경량화된 스프링 프레임워크에서 더 경량화시켰다고 할 수 있는 스프링 부트 프레임워크를 사용하는 것입니다. 스프링 부트를 사용하면 정말 간단한 설정만 거치고 사용법만 익힌다면 간단하게 web을 구축하고 쉽게 빌드하여 배포할 수 있습니다.
대부분의 백엔드는 기능이 비슷비슷합니다. 우리가 어떤 서비스에 가든 로그인, 회원가입, 페이징, 검색 등의 기본 기능을 만날 수 있고 더 나아가 결제, 조회 등과 같은 비즈니스 로직 또한 흔히 볼 수 있습니다. 이런 비슷한 비즈니스 로직들에 대한 공통 라이브러리 패키징과 설정들을 부트가 대신해 주므로 스프링 부트는 단순히 초보 개발자만 사용하는 것이 아니라 경량화된 어플리케이션을 만드는 개발자라면 기능 구현에만 시간을 쏟게 해주는 아주 좋은 프레임워크입니다. 하지만 이런 설정이 쉽다는 장점은 언제나 장점으로만 남지는 않습니다.
우리가 스프링에 대해서 제대로 학습하지 않고 계속 스프링 부트만 사용한다면 나중에 스프링의 기술들을 사용할 때 생기는 문제점을 해결할 능력을 갖추지 못할 겁니다. 더 나아가서 내가 개발해야 하는 목적에 맞게 프레임워크를 선택하는 능력 역시 부족할 것입니다. 물론 스프링 부트에선 주로 사용되는 스프링의 기술들을 대부분 사용할 수 있습니다. 하지만 위에 든 예처럼 과연 부트만 사용한 사람을 스프링을 잘 다룬다고 해도 될까요? 언제나 개발할 때 중요한 건 내가 개발하고자 하는 목적에 따라 올바른 기술을 사용할 수 있냐는 것입니다.
Spring Module과 Spring Boot
앞서 다뤘던 포스트인 https://fadet-coding.tistory.com/34 에서 우리는 스프링 이전에 EJB 기술을 사용했었고 너무 무거웠기 때문에 그보다 경량화된 프레임워크인 스프링의 등장으로 JAVA 진영에 봄이 찾아왔었다고 배웠습니다. 하지만 스프링이 등장하자마자 그렇게 활짝 피지는 못했다고 했었죠. 여기서 Spring이 나온 지 시간이 꽤 됐음에도 현재의 개발 트렌드에 맞는 큰 특징을 발견할 수 있습니다.
Spring은 등장 초기 중요 철학인 DI, IoC, PSA 등을 내세웠었지만 다른 MVC 프레임워크 또한 경쟁력이 있었기에 그렇게 인기 있지는 않았습니다. 하지만 시간이 지나며 Spring의 정말 중요한 특징 중 하나가 부각되기 시작합니다. 바로 스프링은 여러 개의 모듈로 구성된 경량화 프레임워크라는 사실입니다. 처음 출시 후 시간이 지나며 스프링은 코어 기술인 DI, IoC, PSA를 포함하는 모듈로 시작해 다양한 모듈들이 추가되었습니다.
현재의 개발 트렌드는 MSA, Cloud Native, 빅데이터 등 이런 키워드들로 대표할 수 있을 겁니다. 이 중 대표적으로 MSA(MicroService Architecture)는 스프링의 모듈을 필요한 기능에 따라 취사 선택하여 개발할 수 있는 환경에 매우 적합합니다. 다른 Cloud Native, 빅데이터 등 역시 이후 설명할 Module들과 밀접한 관련이 있으니 또 언급될 것입니다.
Spring의 핵심 Module들은 아래 그림처럼 구성되어 있습니다.
이를 보시면 아시겠지만 우리가 앞선 포스트들에서 살펴봤던 서블릿, Mvc(Web) 등 모두 스프링의 모듈에 속해 있습니다. 그리고 우리가 알고 싶어하는 스프링 부트 또한 이 모듈들 중 하나입니다. 아니 이 그림에 스프링 부트는 없는데 도대체 무슨 소리인가 싶겠지만요. 이는 계속 설명을 듣다 보면 이해가 되실 겁니다.
스프링은 초기에 기본 철학으로 DI, IoC, PSA를 내세웠다고 했었죠? 초기 스프링은 Core Container 모듈이 주를 이뤘습니다. IoC를 기반으로 하는 이 코어 컨테이너 모듈은 DI, PSA를 가능케 하는 Bean, Context 들로 구성되어 있고 우리가 스프링을 사용하여 개발하면 정말 자주 쓰는 어노테이션, 컨버터, 유틸리티 등은 모두 이 코어 컨테이너 모듈에서 제공하는 기술입니다.
여기서 웹 백엔드를 개발한다면 여기서 Web 모듈을 추가해서 사용합니다. Web 모듈은 앞선 포스트에서 다뤘던 서블릿, MVC 등을 포함하죠. 따라서 자신이 웹 백엔드를 구축해야 한다면 코어 컨테이너에 Web 모듈만 추가로 사용하면 됩니다.
또한 백엔드와 DB를 연결하는 JDBC, ORM 등과 서비스 구축에 필요한 Transaction을 포함하는 Data 모듈과 보안/로깅 등 핵심적인 비즈니스 로직은 아니지만 어떤 서비스든 필요한 기능들인 횡단 관심(Cross-Cutting Concerns) 구축에 필요한 AOP, Aspects를 필요에 따라 추가로 사용할 수 있습니다.
이렇게 다양하며 개발에 필수적인 모듈들을 스프링은 모두 지원하지만 이 모듈들을 시작부터 모두 포함하는 것이 아닌 개발자의 필요에 의해 필요한 모듈을 선택하여 사용할 수 있으므로 보다 경량화되었다고 해서 스프링을 '경량화 컨테이너'로 부르는 것입니다.
여기서 스프링 부트는 보다 웹 백엔드 개발에 치중된 Web, Data, Security 등의 모듈들을 사용할 때 개발자가 직접 세팅해 주는 것이 아닌 필요한 기능들을 미리 설정하여 제공해 주므로 어떻게 보면 여러 모듈을 합친 새로운 모듈로 볼 수 있는 것이죠. 마치 분식집에서 잘 나가는 메뉴들을 합쳐서 세트 메뉴를 만들듯이 말입니다.
세트 메뉴인 스프링 부트는 핵심 기능과 달리 그 자체로 개발자가 사용할 수 있는 프레임워크입니다. 여기서 스프링엔 다른 세트 메뉴들이 더 있습니다. 대표적으로 Spring Cloud와 Spring Batch입니다.
스프링 클라우드 같은 경우 현재 개발 트렌드인 MSA에 더욱 최적화된 스프링 부트 기반 프레임워크로 부트에서 로드밸런싱, 프록시, 라우팅 등 분산 시스템을 적용하는 데 더욱 특화되어 있습니다. 따라서 Spring Cloud를 사용함으로 앞서 언급한 최근 개발 트렌드인 MSA 환경에 매우 적합한 개발을 진행할 수 있고 또한 다른 트렌드인 Cloud native 어플케이션 개발을 위해선 빠르게 변화하는 요구사항과 높은 트래픽을 제어하기 위해 높은 확장성과 탄력성이 뒷받침되어야 하는데 스프링 클라우드는 이에 적합한 환경을 제공합니다. 더 자세한 내용은 너무 길어지기에 링크로 대체하겠습니다.
* https://www.samsungsds.com/kr/insights/spring_cloud.html
스프링 배치의 경우 엔터프라이즈급 시스템을 운영할 때 이용하는 대용량 일괄 처리를 위해 만들어진 프레임워크입니다. 배치의 경우 애초에 엔터프라이즈 대상 프레임워크이기에 우리가 자세히 다룰 부분은 아니라 이 역시 설명은 링크로 대체하겠습니다. 대용량 일괄 처리에서 볼 수 있듯 스프링 배치는 최근 개발 트렌드 중 하나인 빅데이터 처리에 이용될 수 있습니다.
* https://devbksheen.tistory.com/284
이렇게 최근 개발 트렌드라 볼 수 있는 MSA, Cloud native, 빅데이터 모두 스프링 개발 환경과 궁합이 좋기에 Java를 사용하는 프레임워크에선 스프링이 압도적인 점유율을 차지한다고 볼 수 있겠죠.
Containerless와 Opinionated
앞서 우리는 스프링 부트가 스프링의 몇몇 모듈들을 묶어서 만든 새로운 모듈이자 그 자체로 사용할 수 있는 프레임워크라고 배웠습니다. 교양 수준으로만 알고 넘어갈 것이라면 이 정도 내용이면 차고 넘치겠지만 우린 좀 더 알아볼 필요가 있겠죠? 이번 항목은 '토비의 스프링 부트' 강의 내용을 정리한 것이니만큼 더 자세히 알고 싶다면 직접 강의를 들어보시는 것을 추천합니다. 또, 이번 내용은 앞선 포스트들을 보지 않으면 이해가 어려울 수 있으니 필요하다면 링크를 참조해주세요.
'토비의 스프링 부트' 강의 초반에 스프링부트를 토비님은 이렇게 정리합니다.
Spring Boot는 스프링을 기반으로 실무 환경에서 사용 가능한 수준의 독립실행형 어플리케이션을 복잡한 고민 없이 빠르게 작성할 수 있게 도와주는 여러가지 도구의 모음이다.
사실 이 정리만으로도 크게 이해하는데 무리는 없겠지만 우리는 스프링 부트가 생긴 시절로 돌아가서 쭉 살펴볼 예정입니다. 조금 궁금해지지 않나요? 스프링 부트는 과연 언제 생겼을까요?
스프링이 발표되고 10년 뒤인 2012년 10월, github 스프링 프로젝트에 Improved support for 'containerless' web application architectures라는 (https://github.com/spring-projects/spring-framework/issues/14521) 이슈 하나가 올라왔습니다.
이 글을 간단히 정리하면 이렇습니다.
요즘 엔터프라이즈 개발 환경이 엄청 다양해져서 개발자들이 보다 사용하기 쉬운 프레임워크를 선호하는데, 스프링은 서블릿 컨테이너를 비롯해서 알아야할 선수 지식들이 너~~무 많다고 생각해요. 그래서 다른 인기 있는 node,js나 python의 비교적 간단한 프레임워크들과 비교했을 때 매력이 떨어지니 한 번 스프링을 개선해보는 것 어떨까요?
이 이슈의 반응은 충분히 타당하고 고민해볼만한 문제라는 것이었고, 이 의견에 대한 개발자들의 결론은 ' 요구사항을 반영하기 위해 스프링 프로젝트 자체를 개선하기 보다는 스프링 부트라는 새로운 프로젝트를 시작하는게 낫겠다.'였습니다. 이후 2013년 스프링 부트 최초 버전이 공개되었고 이를 본 많은 스프링 개발자들은 환호했습니다. 이어서 2014년엔 부트의 정식 버전이 공개되었습니다.
# 스프링부트와 Containerless
이런 과거를 봤을때 우리는 스프링 부트가 탄생한 계기를 알 수 있습니다. 하지만 아직 정확히 짚고 넘어가야할 부분이 존재합니다. 도대체 스프링 부트를 탄생하게 만든 이슈에서 언급된 containerless가 대체 뭐냐는 것이겠죠? 사실 이 개념은 다들 익숙하실 serverless와 비슷하다고 이해하시면 편합니다. serverless 뜻이 서버가 필요없다는 것이 아니고 서버는 필요하지만 서버 인프라를 개발자가 직접 다루지 않는다는 것과 비슷하게 containerless 역시 컨테이너는 필요하지만 개발자가 직접 컨테이너 설정을 직접 다루지 않는다는 것을 의미힙니다.
https://fadet-coding.tistory.com/34에서 말했던대로 일반적으로 백엔드에 http 요청이 오면 요청은 정적인 요청과 동적인 요청으로 분리되고 정적인 요청은 Web 서버가, 동적인 요청은 Web 컨테이너가 받는다는 것을 아실겁니다. 여기서 동적인 요청은 Web 컨테이너 내부의 Web Component들이 받으며, 스프링을 사용하면 이 과정이 각각 Web 컨테이너는 서블릿 컨테이너, Web 컴포넌트들은 서블릿에 대응됩니다.
https://fadet-coding.tistory.com/35에선 서블릿이 하는 일들은 뭐가 있었는지 설명했었습니다. 그렇다면 서블릿들이 요청과 응답에 대한 파싱과 연결은 해주지만 필요한 비즈니스로직은 개발자가 직접 처리해줘야 한다는 것도 기억나실겁니다. 그 비즈니스로직을 처리해주는 것이 스프링 컨테이너입니다. 이 스프링 컨테이너 내부에 Bean들이 있다는 것은 이미 잘 아실겁니다.
Bean은 스프링 부트를 공부하신 분들이라면 모르진 않으실 거라 생각합니다. 눈치가 빠른 분이라면 여기서 알 수 있는게 있습니다. 맞아요! 대부분 스프링 부트를 배우는 초기엔 보통 이 스프링 컨테이너만 다루는게 일반적입니다.
하지만 우리가 이 스프링 컨테이너를 사용하기 위해선 무조건 항상 먼저 서블릿 컨테이너를 띄워야 합니다. '서블릿 컨테이너를 대체할 기술은 없나?'같은 질문을 할 수 있겠지만 앞선 글들에서 얘기했듯 자바 웹 기술의 표준입니다. 그렇기에 우리가 스프링을 사용하기 위해선 반드시 이 서블릿 컨테이너에 대해 자세히 알 필요가 있습니다.
게다가 서블릿 컨테이너는 표준 스펙입니다. 쉽게 말해서 구현체가 필요하단 뜻입니다. 구현체는 우리가 아는 톰캣이 대표적이겠죠? 하지만 서블릿 컨테이너는 톰캣만 있는 것이 아닙니다. JBoss나 WebLogic 등 규모 있는 곳에서 사용하는 서블릿 컨테이너는 다양합니다. 따라서 서비스하는 곳에서 톰캣이 아닌 다른 컨테이너를 사용한다면 그 컨테이너에 대해서도 알아야할텐데 그럴 때마다 개발자는 신경쓸 것이 추가됩니다. 거기다 컨테이너간 구성이나 기타 설정들을 해야하는 xml도 따로 알아야합니다.
따라서 앞서 이슈를 올렸던 개발자는 서블릿 컨테이너들을 개발자가 직접 다루는 것을 위시하여 알아야할 지식이 너무 많다고 주장한 것입니다. 거기다 앞서 서블릿 컨테이너를 다루기 위해 알아야했던 지식들을 학습하는 것이 너무 비효율적이라는 것이죠. 토비님도 20년 넘게 개발하면서 web.xml 파일 구성을 모두 외우시지 못할 정도니까요.
결국 스프링 부트는 이런 서블릿 컨테이너를 개발자가 띄울 필요가 있을까에서 시작된 것이라 봐도 되겠죠. 이렇게 서블릿 컨테이너를 직접 띄우지 않고 main() 메서드를 호출하는 것만으로도 실행이 되는 어플리케이션을 앞서 언급된 독립실행형 어플리케이션이라고 합니다. 이 방식은 분산 어플리케이션의 기초가 되고 이것이 부트를 기반으로 하는 스프링 Cloud가 MSA에 보다 적합해지게 도와줍니다.
# Opinionated
앞에서 containerless에 대해 알아봤는데, 단지 서블릿 컨테이너만 자동화해준다고 스프링 부트가 환호받았던 것은 아닙니다. 그 점은 스프링 부트가 가진 또다른 큰 특징인 opinionated를 보면 이해되실겁니다.
opinionated의 원 뜻은 '독선적인'이지만 여기서 사용되는 의미는 '쓸데 없는 것들 고민할 필요없게 내가 다 정해줄게'라고 보시면 됩니다. 예를 들어 우리가 간단한 음식을 만든다고 하겠습니다. 간단한 음식이지만 조리가 끝나기 전까지 고민해야할 것이 엄청 많습니다. 재료는 어디서 무엇을 얼마나 사야하고, 조리 방법으로 끓일거냐 구울거냐 튀길거냐 정해야하듯이 말이죠.
마찬가지로 우리가 스프링을 사용하면 고민해야할 부분이 정말 많습니다. 내가 어떤 기술을 사용하기 위해선 어떤 라이브러리를 선택해야하고, 구현체는 무엇으로 해야하며, 버전은 뭘로 해야 다른 스프링 프로젝트들과 호환이 되는지 등 말이죠. 또한 이런 고민들 말고도 기술을 스프링에 적용하기 위해 DI 등 구성 및 설정들을 따로 하는 시간도 많이 소요됩니다.
스프링은 개발 철학으로 극단적인 유연함을 추구합니다. 정말 많이 기술들을 포용하고 선택지들을 제공하기에 원래 스프링은 not opinionated한 도구입니다. 이런 특성이 절대 나쁜 것은 아니지만 처음 준비 단계에서 신경써야할 점이 많다는 것은 당연합니다.
그래서 스프링 부트는 개발자에게 부담이 될 수 있는 이런 부분들을 미리 다 세팅해주는 것으로 좀 더 빠르게 개발에 집중할 수 있게 도와주는 것입니다. 스프링을 사용할 수 있는 방법은 정말 다양하지만 그동안 스프링이 사용되며 일반적으로 웹 개발에 사용된 best practice가 있으니 그에 맞춰 초기 설정을 미리 다 해두는 것이죠.
opinionated라는 특성으로 부트를 사용하는 사람들은 빠르게 우선 어플리케이션의 프로토타입을 완성시키고 이후 운영 방식에 맞게 이를 수정해주면 그만이기에 간단한 서비스라면 정말로 빠르게 릴리즈까지 가는게 가능한거죠. 여기서 스프링 부트가 어떤 설정들을 자동화해주는지는 길어지기에 링크로 대체하도록 하겠습니다.
* 스프링과 스프링 부트의 차이점 예시는 https://www.youtube.com/watch?v=YSsl5-q2BR4&t=647s
Spring과 Spring Boot
몇몇 분들이 하는 이런 오해들이 있습니다.
- 어플리케이션 기능 코드들만 잘 작성해도 돼
- 스프링 잘 몰라도 부트만 사용해도 개발 잘할 수 있어(스프링 부트가 정해주는 것들은 몰라도 돼)
- 문제가 생기면 그때 그때 검색해서 해결하면 돼
어느 정도는 맞는 말일 수 있습니다만 이는 스프링 부트의 큰 특징 중 하나인 '유연한 확장'을 고려하지 않고 말하는 경우가 많습니다. 스프링 부트는 정말 많은 부분 개발자를 위해 정해주지만 개발자가 커스터마이징이 필요하다면 디폴트된 부분을 제거하고 수정 가능하도록 설계되었습니다. 마치 전기면도기처럼 그냥 헤드를 계속 사용해도 되지만 필요에 따라서 트리머 헤드로 교체해서 더 정교한 사용이 가능하듯 말이죠.
그런데 우리가 스프링에 대해 전혀 알지 못하고 스프링 부트만 단편적으로 사용할 줄 안다면 앞서 들었던 예시에서 어떤 종류의 헤드로 갈아끼워야 원하는 면도 방법에 어울리는지 모르는 것과 똑같을겁니다. 심지어 스프링을 잘 공부한다면 스프링 부트로 작성되었더라도 부트에 해당되는 설정을 모두 제거했을 때 작동할 수 있도록 재구성이 가능할 정도로 부트는 유연하기 때문에 이를 아는 것과 모르는 것의 차이는 크겠죠.
결국 스프링 부트는 스프링 기반 프레임워크이기에 결국 스프링 부트로 개발한다면 언제나 결과물은 스프링입니다. 그렇기 때문에 절대 스프링 부트만 잘 사용할 줄 안다고해서 끝나는 것이 아니란 얘기죠. 유연한 확장이라는 것은 결국 부트를 사용하지 않았을 때 어떤 부분이 달라지는지 잘 알아야 한다는 것과 일맥상통합니다. 쓸데 없는 커스터마이징이 남발한다면 오히려 부트가 아닌 스프링을 사용했을 때 훨씬 유리할테니까요.
마치며 짧게 스프링과 스프링 부트의 차이를 정리해보자면 아래와 같겠네요.
1 스프링 부트는 스프링 기반 프레임워크이기에 스프링 eco-system의 다양한 기술을 사용할 수 있고
2 Web Mvc에 특화된 모듈을 묶어 관련 설정을 미리 끝내주기에 사용이 간편하고 진입장벽이 낮음
3 그렇기에 필요한 비즈니스 로직을 기능 단위로 빠르게 구현하고 독립실행형 어플리케이션을 간단히 개발할 수 있지만
4 설정을 미리 끝내준다는 말은 다른 말로 구현 방식을 제한한다는 것이므로
5 둘은 엄연히 다른 프레임워크로 취급해야하며 개발자는 목적에 따라 선택을 신중히 고려해야 함
마지막으로 중요한 것은 앞서 살펴본 것처럼 언제 스프링 부트를 사용할 것인지 아는 것입니다. 내가 진행중이거나 진행할 프로젝트가 부트만 이용해도 충분하거나 이미 부트만 이용 중이라면 큰 문제는 없을 수 있겠지만 실무에서 항상 그럴순 없을 겁니다, 항상 내가 사용하는 기술을 무조건 전부 이해하고 사용할 수도 없을 뿐더러 오히려 시니어분들은 그걸 말리시기도 합니다. 하지만 분명히 내가 기술을 사용할 때 이해하고 있는 부분이 있다면 그를 활용하고 응용하는 데 크게 도움이 되는 것도 사실입니다. 그런 부분에 있어서 미리 공부해두면 언제 무엇을 어떻게 사용해야알지 아는 좋은 개발자가 되지 않을까요?
이번 포스트에서 살펴본 것 외에 Security, Shell, Integraion 등 스프링엔 더 많은 project들이 존재합니다. 물론 스프링 부트를 사용할 때 저런 project를 추가로 선택하여 결합하는 것 역시 가능합니다만 내가 개발하는 목적을 고려해서 부트가 아닌 스프링이나 클라우드를 사용할지 결정하기 위해선 이에 대한 지식들을 알아 둬야만 할 겁니다.
스프링 정리 포스트는 여기서 마지막이지만 스프링에 존재하는 여러 project에 대해선 단편적으로 포스팅을 추후에 할 수도 있을 것 같네요.
refer
https://spring.io/projects/spring-boot
Spring | Home
Cloud Your code, any cloud—we’ve got you covered. Connect and scale your services, whatever your platform.
spring.io
토비의 스프링 부트 - 이해와 원리 - 인프런 | 강의
스프링 부트의 핵심 기능을 직접 만들어보면서 스프링 부트의 동작 원리를 이해하고, 이를 통해 스프링 부트를 잘 학습하고 사용하는 방법을 배우는 강의입니다. 스프링 부트가 사용하는 스프
www.inflearn.com
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1
스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의
웹 애플리케이션을 개발할 때 필요한 모든 웹 기술을 기초부터 이해하고, 완성할 수 있습니다. 스프링 MVC의 핵심 원리와 구조를 이해하고, 더 깊이있는 백엔드 개발자로 성장할 수 있습니다., -
www.inflearn.com
'Spring' 카테고리의 다른 글
| Spring_짧2_415 오류와 Content-Type, @RequestBody (0) | 2022.07.24 |
|---|---|
| Spring_짧1_ControllerTest와 @ModelAttribute, @RequestBody (0) | 2022.07.18 |
| 5_짧_th:field와 th:value (0) | 2022.06.25 |
| Spring_정리5_Spring의 구조 훑어보기_FrontController (0) | 2022.05.09 |
| Spring_정리4_Spring의 구조 훑어보기_MVC (0) | 2022.05.08 |