이번 강의 내용을 보고 스프링 컨테이너에 톰캣을 내장했다고 볼 수 있을까요?

스프링부트가 서블릿 컨테이너를 내장한 것이 중요한 특징이긴합니다. 하지만 원한다면 기존 톰캣 서버에 배포하는 형태로도 빌드해서 사용할 수 있습니다. 가장 큰 특징이라고 하기엔 자동 구성이 워낙 중요해서, 하나의 큰 특징 정도로 생각하시면 좋겠습니다. 물론 스프링을 전통적인 방식으로 개발하다가 부트로 넘어온 경우엔 서블릿 컨테이너까지 자동으로 동작하는게 매우 인상적이긴 합니다.

서블릿 컨티이너를 내장하는 방식은 강의에서 설명드린대로 서블릿 컨테이너 팩토리를 스프링의 빈으로 등록한게 중요합니다. 그리고, 그 빈을 가져다가 스프링의 초기 라이프라이클에서 직접 실행하는 것도 의미가 있고요.

서블릿 컨테이너를 내장형해서 사용하는 것은 원래는 상상도 못했던 일입니다. 처음 서블릿 기술이 나왔던 시절에는 서블릿 컨테이너가 일부로 포함된 웹 애플리케이션 서버(WAS)를 기업에서 고가로 구매해서 사용하던 시절입니다. CPU/Core당 천만원이 넘는 라이센스비를 주고, 그러니까 WAS하나에 5천만~1억쯤 매년 라이센스 비용을 내기도 했죠. 그런 고가의 서버 제품을 구매하면 전담 SE(시스템 엔지니어)가 관리를 담당합니다. 필요에 따라 미세한 조정을 하기도 했고요. JVM의 GC 문제라든가, 오류가 생겼을 때 여러가지 분석하고 관리하는 등의 작업도 담당해야 했습니다. 그리고 WAR, EAR 등으로 빌드된 애플리케이션을 개발자들이 가져오면 그걸 서버에 배포하고 동작시키는 것도 전담 엔지니어나 부서에서 처리했죠. 예전엔 서블릿 컨테이너에 여러 개의 웹 모듈을 멀티로 배포했고, 서버를 재시작하지 않고 오래 운영해면서 새로운 웹 모듈을 재배포하는 등의 작업을 했습니다. 그 시절엔 EJB도 중요했기에 WAS를 잘 운영하는게 중요했습니다.

그런데 스프링이 등장하고 서블릿 컨테이너만으로도 기존 WAS에서 지원하던 엔터프라이즈 기술을 사용할 수 있게 되었고, 점차 가볍고 서블릿 컨테이너를 도입하는 게 늘어나기 시작했죠. 그래서 톰캣과 같은 오픈소스, 무료 제품도 점차 사용이 늘게 되었습니다. 그래도 여전히 기존 방식으로 서버를 따로 띄우고 쓰는 방식을 선호했던 것이고요.

그런데 스프링 부트와 같이 컨테이너를 같이 띄우기 시작하게 된 건, 아마도 클라우드의 영향으로 동시에 여러개의 서버를 사용하고, 필요에 따라 이를 늘리기도 하는 등의 최근 배포 방식이 시작되면서인 듯합니다. 마이크로서비스를 도입하거나, 그렇지 않더라도 작은 사양의 서버를 부하에 따라 늘리거나 줄이거나 하는 상황에서 SE가 일일히 서버를 관리하기 힘들게 됐죠.

그래서 점차 서블릿 컨테이너당 웹 모듈 하나만 배포하는 것, 그리고 재배포시 아예 서블릿 컨테이너를 재시작하는 방식도 늘기 시작했고요. 아마 그런 변화가 일어나던 시점에 스프링 부트 혹은 그에 영향을 준 다른 웹 기술 등이 등장으 했던 것 같습니다.

하지만 지금도 일부 기업 등에선 톰캣 서버를 관리하는 팀이 따로 있고, 스프링 부트를 쓰더라도 WAR로 빌드해서 톰캣에 직접 배포하는 방식으로 운용하기도 합니다. 여러가지 필요에 따라 장단점이 달라질 수 있기 때문에 그에 맞는 선택을 하면 됩니다. 스프링부트는 마이크로서비스에 적합하다고도 자주 얘기하는데, 아무튼 그런 애플리케이션 개발과 배포 방식을 선호한다면 기본인 독립실행형 방식이 유리할 것이고요.