Spring boot vs Spring Framework

현재 대다수의 기업에서는 spring boot 를 많이 사용 하고 있다. 그리고 대부분의 spring framework 는 학원이나 기존 회사의 레거시 시스템 혹은 학교에서 많이 사용 되는것으로 알고 있다. 

 

그럼 둘사의 차이가 무엇인지 남기고자 한다. 

 

Spring framework 보다 간단해진 설정 

 

 난 2.5 버전부터 사용했었고 현재는 5.0 버전이 나와있다. 스프링 프레임워크의 가장 대표적인 단점은 xml 지옥이다. 모든 설정은 xml 로 사용 했고 실제로 applicationContext.xml 이외에 mybatis, log4j , 프로필별 xml 등 설정을 위한 작업이 대다수였고, 노하우가 없는 사람은 최대 설정만 반나절, 심한경우는 하루 종일 하는 경우도 보았다. 

 

 그래서 스프링은 어렵다라는 인식이 강했고 그와중에 등장한 node.js 같은 경우는 기존 자바스크립트 개발자에게는 굉장히 가벼운 서버 프레임워크였다. 반면에 무겁지 무거운 스프링프레임워크는 자연스레 자바개발자들만 사용할수있는 프레임워크로 인식이 강해졌고 node.js 에 한때 자리를 위협당하기도 했다. ( 물론 그래도 우리나라에선 굳건했던거 같다. ) 

 spring framework 는 가공되지 않은 재료를 모아놓고 집을 지으라고 하는것과 비슷했다. 벽돌을 만드는 기능을 넣어 두었나 벽돌을 만들어내기위해선 시간 투자가 필요 했고 벽돌을 만들고 나서도 그것을 쌓을수 있는 도구들을 자신이 알아서 잘 조합해야만 했다.  그래서 학원이나 학교에서 필요한것만 딱딱 가르쳐서 내보지 않았나 싶다. 실제로 스프링을 배울때도 왜 이렇게 쓰는지 모르고 그냥 쓰는경우가 많았고 나중에 한참지나서야 원리를 깨닫는 경우가 많았다.  그리고 자신이 세팅한 프로젝트를 외장하드에 넣어두고 다녔었다. 주변에 스프링개발자들이 이렇게 하는 경우가 정말 많았다. 왜냐면 그 복잡한 설정을 반복하느니 빈프로젝트에 설정을 다해놓고 그냥 복사 붙여넣기로 프로젝트 생성하는게 더 편했기 때문이다. 

 지금은 굳이 그럴 필요가 없어 보인다. 기본 유틸리티 기능들은 스프링에서 잘지원해주고 있고 특히 intellij 같은 IDE 를 사용한다면 스프링프로젝트 자동생성기능을 통해서 아주 간단히 단 5분만 투자하면 프로젝트 세팅이 가능하다. 

물론 내부 세세한 세팅이라던가 개인화된 옵션을 넣으려면 ( xml 설정 혹은 Java config ) 작업을 해줘야겠지만 순수 스프링 프레임워크에 비하면 정말 아주 적은 투자만 하면된다. 

 

내장 된 WAS 

 

 기존 스프링은 톰캣이랑 땔래야 땔수 없는 관계였고 , 지금도 그닥 다르지 않다. 다만 요즘엔 비동기 방식이 사용되면서 다른 대안들이 나왔지만 아마 기본적으로 공부를 하거나 이미 구축된 레거시중에는 톰캣의 사용의 비율이 가장 많다. 구글링을 해봐도 톰캣 관련 내용은 압도적으로 많다. 그럼 스프링 개발자가 왜 톰캣같은 was 에 대해서 알아야 했을까 ?

 내가 참여했던 일부 프로젝트에선 외장 톰캣을 사용했고 그걸 가지고 튜닝을 해주길 요청했다. 메모리 설정부터 커넥션 설정 등 그리고 일단 스프링프레임워크를 사용하기 위해선 톰캣에 프로젝트 설정을 잡아줘야 하겠고 도메인 설정이나 기본적은 톰캣 사용 설정이 필수였다. 프로젝트 세팅이 끝났다고 끝이 아니라 톰캣 설정도 개발자가 해야 했던 것이다. 그리고 실제 서버를 내렸다 올리는건 톰캣을 내렸다 올려야 했기때문에 catalina 설정도 어느정도 건들줄 알아야 했다. 

 그럼 스프링 부트는 ? 결론부터 보면 설정할 것이 거의 없다. 임베디드형의 톰캣을 제공하고 톰캣뿐만 아니라 다른 것들도 부트에서 지원해주고 있다. 그중 요즘 내가 가장 최애하는건 undertow 와 netty 다. 성능적이나 메모리 사용량에서 톰캣보다 가볍고 빠르다. 프로젝트 생성후 바로 실행 시켜보면 별다른 설정없이 톰캣이 실행되는걸 로그상에서 확인이 가능하다. 톰캣같은 was 설정에 대해서 어느정도 자유를 확보 할수 있다. 그리고 생각보다 안정적이다.  지인중 한분은 경험상 외장톰캣이 알수없는 장애를 내는것과 내장 톰캣이 알수없는 장애를 내는 비율을 따져보니 내장톰캣이 더 월등히 안정적인거 같다고 하셨다. 

 물론 부트에서 외장톰캣에 설정하던 옵션값들을 적용이 가능하다 하지만 보통은 그런것들을 신경쓰지 않는거 같다. 스프링부트 프로젝트가 생기면서 지향하는 목적을 잘 보여주는 차이가 아닌가 싶다. 

 

 

기본 설정된 옵션들

 

기본 적으로 스프링프레임워크 개발자가 해야만하는 많은 옵션들을 생략해도 괜찮다. 기본 logback 이 설정 되있으며 spring-boot-web-stater 같은 라이브러리에는 다수의 개발자들이 반복적으로 하던 설정들이 기본 디폴트로 잡혀있다. 스프링을 안써본 사람은 이게 왜 편한지에 대해서 몸에 와닿지 않겠지만 스프링을 오래 써온 개발자들은 정말 세상 편해졌다는걸 피부 가까이 느낄수 있다. 그리고 옵션수치에 따른 성능이나 내가 설정한 옵션에 대한 불신감을 가지지 않아도 된다. 어떤 사람들은 디테일하게 설정할경우에는 안좋은거 아닌가 하지만 대부분 컨트롤이 가능하기때문에 크게 걱정 안해도 될거 같다. 

 

 

간단한 배포와 실행

 

스프링프레임워크를 시작하면 아마 war 파일을 많이 보게 된다. war 파일을 서버에 배포하고 was 가 그걸 deploy 해서 경로를 잡고 그리고 was 실행 명령을 내리고 로그를 보고 .... 

 부트는 기본이 jar 이다. java 개발자라면 아주 익숙한 자바 실행 파일이다. 외장을 안쓰고 내장이 되있는 경우에는 단순한 데몬형태로 실행이 가능하기때문에 딱히 was 사용법과 명령어를 알필요가 없다. 그리고 무식하지만 nohup 을 걸어서 실행하면 데몬에서 실행되는 모든 로그가 다 보이게 된다. 그리고 개인적으로 흥미로웠던건 빌드시 vue.js 파일들을 같이 resource 폴더에 넣어두고 빌드를 하면 서버랜더링된 웹페이지 호출이 가능하단것이다. 기존엔 war 파일이 붙인 폴더 안에 별도의 html 폴더가 있어야 했었는데 데몬형태다보니 웹서비스를 할때에도 파일 하나로 퉁쳐진다. 

 파일 하나로 되기 때문에 배포도 쉽고 빠르며 특히 롤백시에도 강점이있다. 그리고 단순 자바 어플리케이션 실행이다 보니 자바 실행 명령어만 주면 충분히 실행이 되며, 톰캣에다가 메모리 설정하던걸 자바 실행 옵션에 줘서 메모리 할당이 제어 가능하고 덤프 명령어도 줄수 있기 때문에 여러가지로 편하다.  

 

같은 성능

 

 스프링프레임워크 기반으로 태어난게 스프링 부트이다. 그렇기 때문에 스프링프레임워크가 안되는기는은 스프링부트도 안된다고 봐야한다. 스프링프레임워크의 버전이 올라가면 스프링 부트버전도 같이 올라간다. 현재 스프링프레임워크는 5버전이 시작됬고 그에 맞쳐 스프링부트는 2버전이 릴리즈 중이다. 

 스프링프레임워크를 경량화 한게 스프링 부트이다. 성능은 그럼 차이가 있을까 하고 고민이 되지만 결론적으로는 차이가 없다. 아마 코어자체는 동일하게 사용하고 코어가 아닌부분들만 경량화 했기 때문이 아닐까 싶다. 현재 프로젝트를 생성할땐 스프링부트 2버전에 API 서버 같은경우 스프링프레임워크 5 부터 지원하는 webflux 를 사용하려고 노력중이다. 

 

 성능이 같고 기능도 동일하게 지원하는데 가볍고 신경쓸게 더 적다는 이점이 있다면 난 자신있게 부트를 사용하라고 말할거 같다. 하지만 공부를 위해선 스프링프레임워크를 먼저 경험해 보고 부트를 사용하는게 좀더 좋지 않을까 싶다.