본 시리즈는 인프런 학습 사이트의 김영한 강사님의 java spring mvc - 백엔드 웹 개발 핵심 기술 편을 학습한 내용을 바탕으로 정리하였습니다.
지난 포스팅에서 HTML, HTTP API, CSR, SSR을 학습하며 서버 사이드 언어가 어떻게 동작하는지를 학습했다.
오늘 학습한 내용은 자바 백엔드 웹 기술의 역사이다. 백엔드에서의 웹은 처음부터 단박에 스프링 mvc로 개발하지 않았다. 과거 서블릿부터 현재 애노테이션 기반의 스프링 mvc까지 단점을 보완하면서 수 차례 발전해왔다.
따라서 웹 기술이 어떻게 발전해왔는지 아는 것은 웹 애플리케이션의 이해에 있어서 중요하다고 볼 수 있다.
먼저, 지금은 쓰이지 않거나 일부 서비스에서만 쓰이는 레거시 기술들에 대해서 먼저 살펴보았다.
📉 과거 기술
1. 서블릿 (1997)
장점
지난 포스팅에서 학습한 서블릿은 자바 기반의 동적 웹 앱을 개발할 때 사용하는 핵심 기술이라고 배웠다. 스레드로 동작하기 때문에 운영하는데 있어 효율적이며 자바 기반이기 때문에 자바 API를 모두 사용할 수 있다는 것이 장점이었다. 무엇보다 비즈니스 로직과 컨텐츠에 관한 부분을 나누려고 시도했다는 점에서 큰 혁신을 가져왔다.
단점
HTML을 생성하는게 어려워요...
이러한 서블릿도 단점이 존재했는데 HTML을 표현하는 것이 번거롭다는 것이다. 자바 코드 내에서 HTML을 실행시키려니 여간 까다로운 일이 아닐 수 없다. 간단한 태그 하나를 변경하려해도 재컴파일을 해야하는 문제가 있으니 프론트엔드 엔지니어에게는 엄청난 족쇄가 되는 것이다.
2. JSP (1999)
장점
이와 같은 서블릿의 단점을 보완하고자 JSP가 탄생했다. JSP는 Java Server Pages 의 약자로 서블릿과는 반대로 HTML 코드에 자바 코드를 포함시켜 동적 웹 페이지를 구성한다. (<%- %> 태그와 같은 방식) 서블릿과 하는 일은 동일하지만 HTML 코드를 작성하기 간편하다는 장점이 있다.
단점
하나의 파일 안에 이렇게 많은 로직이..?
따라서 JSP로 지금까지 자바 웹 개발을 하게 되었답니다. 라고 해피엔딩으로 마무리 지으면 참 좋겠지만 JSP도 단점 아닌 단점이 존재했다. HTML 생성은 편리하지만 하나의 파일에 HTML, java 코드가 함께 있다보니 로직이 조금만 복잡해져도 수백 줄의 코드가 한데 뒤엉키는 상황이 발생한다.
자바 코드를 유지보수 해야하는 백 엔드 엔지니어를 상상해보라. 그 수백 ~ 수천줄 사이에서 구조를 파악하는 것 자체가 HELL 이 되는 것이다.
3. 서블릿 + JSP, MVC 패턴
따라서 Servlet과 JSP를 섞어서 사용함으로써 서로에게 있는 장단점을 어느 정도 보완할 수 있게 되었다. Servlet은 프로그램의 로직을 담당하고, JSP로 결과를 HTML로 뿌려주는 방식으로 사용하는 것이다.
또한, MVC 패턴을 같이 적용하게 되면서 관심사를 나누게 되었다. 즉, 모델과 뷰 컨트롤러로 역할을 나누어 비즈니스 로직과 화면을 렌더링하는 부분을 완벽하게 분리하게 되었다.
4. MVC 프레임 워크 춘추 전국시대 (2000년 초 ~ 2010년 초)
이러한 MVC 패턴은 말 그대로 '패턴' 이기 때문에 개발 프로세스가 대동소이했다. 이 때부터, 수 많은 개발자들이 자신만의 프레임 워크를 개발하기 시작했다. MVC 패턴을 자동화하고, 복잡한 웹 기술을 편리하게 사용할 수 있는 각기 다양한 기능들을 지원하면서 "MVC 프레임워크 춘추 전국시대"가 열린 것이다. 대표적으로 스트럿츠, 웹워크, 스프링 MVC (과거 버젼)이 있다.
(강사님의 말에 의하면 프레임 워크들을 조합해서 스트럿츠를 앞단에서 사용하고, service, repository, dao 같은 뒷단에는 스프링을 사용했다고 한다.)
📈 현재 기술
1. Spring mvc
이러한 춘추 전국 시대의 대단원을 내린 기술이 있었으니... 그것은 @(애노테이션) 기반의 스프링 MVC였다.
어떤 기술이든지 간에 gain이 있다면 loss가 있기 마련인데, Spring mvc는 그런 점에 있어서 거의 완벽에 가까웠다. 스프링 기술이기 때문에 일단 스프링과 통합이 되어있으며 기능적인 부분에서도 @Controller 와 같이 @ 기호 하나만으로 MVC 패턴을 구성했기 때문에 유연하고 편리하면서 깔끔한 개발을 할 수 있었다. 그렇기에 많은 기능을 제공하는 스프링을 우리는 지금도 사랑하고 애용하고 있다.
2. 스프링 부트의 등장
효자(?) 스프링은 여기서 그치지 않고, 스프링 부트라는 것을 선보인다. 개발자들이 사용하면서 불편해했던 것들을 스프링은 자동화를 통해 해결한다. 개발자들이 스프링을 사용하면서 불편했던 것이 무엇인가라고 한다면 대표적으로 서버에 관련된 이슈일 것이다.
과거에는 WAS(톰캣)를 서버에 직접 설치, 실행하고 소스 코드는 또 따로 War 파일을 만들어서 톰캣을 설치했던 서버에 배포하는 작업을 일일히 해야만 했다.
그야말로 쌩노가다라고 할 수 있는 이 작업을 스프링 부트는 서버를 아예 내장하면서 한방에 해결하게 된다. 빌드할 때, 그냥 서버를 안에 넣어버리는 방식인 것이다. 우리가 스프링에서 웹 애플리케이션을 실행하면 하단 console에서 Tomcat 서버가 자동으로 돌아가는 것이 바로 이 때문이다.
이처럼 빌드 배포가 아주 단순화 되는 혁신이 일어나면서 스프링은 안쓸래야 안 쓸수가 없는 중요한 프레임워크로 자리잡게 되었다.
