SpringBoot와 웹서버

스프링부트를 실무에서 쓰진 않지만 개인적으로 공부나 인강을 들을땐 계속 써왔어서 익숙하긴하지만 기존 레거시와 비교했을때 

어떤점이 편리하고 어떤원리로 제공하는지는 잘 알지 못해서 김영한 강사님의 스프링부트의 원리활용 강의를 듣고 기록해본다.

 

 

WAR 배포 방식의 단점

웹 애플리케이션을 개발하고 배포하려면 다음과 같은 과정을 거쳐야 한다. 톰캣 같은 웹 애플리케이션 서버(WAS)를 별도로 설치해야 한다. 애플리케이션 코드를 WAR로 빌드해야 한다.
빌드한 WAR 파일을 WAS에 배포해야 한다.

웹 애플리케이션을 구동하고 싶으면 웹 애플리케이션 서버를 별도로 설치해야 하는 구조이다.
과거에는 이렇게 웹 애플리케이션 서버와 웹 애플리케이션 빌드 파일(WAR)이 분리되어 있는것이 당연한 구조였다.
그런데 이런 방식은 다음과 같은 단점이 있다.

 

단점

톰캣 같은 WAS를 별도로 설치해야 한다. 개발 환경 설정이 복잡하다.

단순한 자바라면 별도의 설정을 고민하지 않고, main() 메서드만 실행하면 된다.

웹 애플리케이션은 WAS 실행하고 또 WAR와 연동하기 위한 복잡한 설정이 들어간다. 배포 과정이 복잡하다. WAR를 만들고 이것을 또 WAS에 전달해서 배포해야 한다.
톰캣의 버전을 변경하려면 톰캣을 다시 설치해야 한다.

 

 

톰캣도 자바로 만들어져 있으니 톰캣을 마치 하나의 라이브러리 처럼 포함해서 사용해도 되지 않을까? 쉽게 이야기해서 톰캣 같은 웹서버를 라이브러리로 내장해버리는 것이다. 이원리를 바탕으로 스프링부트는 톰캣과 같은 WAS를 라이브러리로 프로젝트에 포함시켜버린다.

 

외장 서버 VS 내장 서버

왼쪽 그림은 웹 애플리케이션 서버에 WAR 파일을 배포하는 방식, WAS를 실행해서 동작한다. 오른쪽 그림은 애플리케이션 JAR 안에 다양한 라이브러리들과 WAS 라이브러리가 포함되는 방식, main() 메서드를 실행해서 동작한다.

 

스프링 부트의 장점

• 내장 톰캣을 사용해서 빌드와 배포를 편리하게 한다.
• 빌드시 하나의 Jar를 사용하면서, 동시에 Fat Jar 문제도 해결한다.(Fat jar는 jar안에 jar를 포함시킬 수 없는 문제를 해결하기위해 libs(jar형태)를 모두 압축을 풀어 class로 포함시켜버린다.  -> 어떤라이브러리 사용하는지 추적불가, 파일명 중복문제 해결 불가)
• 지금까지 진행한 내장 톰캣 서버를 실행하기 위한 복잡한 과정을 모두 자동으로 처리한다.