Spring_정리2_Spring 이전 JAVA 웹 개발의 역사 훑어보기

※ 이 포스트는 스프링 실습 과정에서 작성하기 때문에 정보가 부정확할 수 있는 부분이 있습니다.

특히 Spring의 전체적인 이해를 돕기 위해 논리의 비약이나 내용 축약으로 인한 정보의 질적저하가 있을 수 밖에 없습니다. 따라서 전체 흐름 이해를 위한 참고만 해주시고 틀린 부분이 있을 경우 알려주시면 감사하겠습니다.

 

이번 포스트는 김영한님의 '스프링 핵심원리 기본편' 강의의 인트로 부분을 일부 인용하였습니다.
스프링에 대해 더 자세히 공부하고 싶으신 분은 인프런에서 해당 강의를 수강하시길 추천합니다.

 

---

우선 이 시리즈의 keyword는 역사, 용어, 구조입니다. 제가 작성한 다른 포스트를 보면 하나의 주제를 설명하기 위해 등장하는 개념은 인용문이나 짧은 설명으로 넘어가고 진행하기에 용어를 파악하기 어려울 때가 많았을 것이라 생각합니다. 따라서 이 시리즈는 용어가 등장하게 된 배경을 이해하기 위해 스프링이 밟아온 역사를 따라가며 하나하나 설명해볼 것이고 그 과정에서 나타나는 패턴의 구조를 살펴볼 예정입니다. 그럼 시작하겠습니다.

 

Index
1 스프링(Spring) 이전 JAVA 웹 기술의 시작
2 서블릿 (Servlet)
3 JSP (JAVA Server Pages)
4 mvc의 대두와 EJB, JAVA진영의 겨울나기
5 스프링(Spring)의 등장, JAVA진영에 찾아온 봄(?)
6 MVC 프레임워크의 난립, 이를 끝낸 스프링 MVC. 그래도 결국 봄은 온다

 

 

스프링(Spring) 이전 JAVA 웹 기술의 시작

 

웹 개발의 본격적인 시작이 어디라고 생각하시나요? 더 전부터 따지면 군사적인 목적으로 탄생한 ARPANET 이후 인터넷이 등장했고 인터넷이 보급되기 시작한 1994년부터 WWW(World Wide Web)는 인터넷과 동의어처럼 쓰이기 시작했습니다. 이 때 Gopher, Telnet 등을 제친 WWW가 사실상 웹 개발의 본격적인 시작점이라고 생각합니다. 여기서 사람이 언어로 소통하듯 WWW에서도 사람들끼리 소통할 수 있는 언어가 있어야했으며 그 언어가 HTML(HyperText Markup Language)라는 언어였고 이 언어를 통해 우리는 문자를 넘어(HyperText) 그림, 동영상 등의 방식으로 전세계 사람들과 소통할 수 있었고 지금도 HTML은 인터넷을 구성하는 표준이며 시작이라고 볼 수 있습니다.

 

하지만 다른 이가 올린 사진을 보고 동영상을 감상하는 페이지를 제공 받는다는 엄청난 혁신도 시간이 지나자 사람들은 단순히 미리 저장된 정보만 볼 수 있는 정적(static)인 방식 말고 내가 검색한 정보만을 모아서 찾아보고 다른 이들과 실시간으로 소통하는 것처럼 내가 홈페이지를 변화시키는 동적(dynamic)인 방식을 원하기 시작했고 그것은 브라우저에 JavaScript를 사용하는 것으로 어느 정도 해결되었습니다. 하지만 브라우저에서만 작동하는 JavaScript만으로는 사용자가 입력한 결과를 바탕으로 서버와 통신하여 웹을 개발하는 것은 힘들었고 결국 서버는 다른 언어로 개발되어야 했습니다. 여기서 우리는 JAVA의 역사에 대해 살펴보도록 할 것입니다.

 

JAVA는 1995년 제임스 고슬링이 창시하고 썬 마이크로시스템즈에서 개발한 프로그래밍 언어입니다. 이 언어는 전자제품의 임베디드 프로그램을 설계하기 위해 개발되었지만 제가 연도를 볼드체로 강조해놨듯이 인터넷이 보급된 시기와 JAVA의 시작이 맞물리게됩니다. 그렇게 JAVA의 개발 방향은 인터넷 서버를 구축하는 것을 초점으로 바뀌게 되었고 이것이 가전제품에만 존재할 뻔했던 JAVA를 큰 성공으로 이끌었다는 것이 중론입니다. 

 

아까 얘기했듯 초기의 인터넷은 정적이었습니다. 동적이라고 할만한 것은 기껏해야 사용자가 서버에 어떤 요청을 보내면 서버가 정보를 제공해주는 것이 다였고 서버가 미리 사진, 동영상 등의 정보를 저장해뒀다가 요청에 의해 반환하면 되었습니다. 하지만 과거에는 그냥 사진들이 저장된 페이지만 반환해주면 만족했던 사용자들은 점점 본인들이 원하는 주제와 작가의 사진들을 모아서 페이지를 만들어줄 것을 요구하듯 필요한 자료만을 원했고 서버는 좀더 동적으로 변할 필요가 있었습니다. 여기서 원래 서버를 뜻했던 기존에 가지고 있던 정보만을 정적으로 보여주는 WEB 서버는 한계를 직면했고 그렇게해서 등장한 것이 바로 WAS(Web Application Server)입니다.

 

개발에 대한 지식이 조금 있으신분은 브라우저 > 웹서버 > WAS > DB의 과정의 예시로 브라우저 > NginX > Tomcat > MySQL를 들면 대충 감이 오실테지만 더 자세히 설명해보겠습니다.

 

예를 들어 서버가 어떤 동물사전을 가지고 있다고 할 때, 사용자가 동물 사전의 고양이 페이지를 열람하길 원하여 정적인 요청을 하면 서버는 미리 만들어둔 여러 동물사전 페이지 중 고양이만 제공하면 되었습니다. 이처럼

기존의 WEB 서버는 사용자가 어떤 정보를 요구하면 서버에서 저장하던 정보를 그냥 반환하는 것이 전부였습니다.

하지만 사용자가 동물사전에 있는 고양이과 동물들 중 맹수들만 빼고 나머지 전부를 몇 페이지에 묶어서 열람하고 싶은 동적인 요청을 보낸다면 기존의 WEB 서버는 그런 페이지를 미리 만들어두지 않았기 때문에 요구를 맞춰줄 수 없습니다. 이제 서버가 가지고 있는 정보들 중 고양이과만 categorizing하고 그 중 맹수인 것들을 제외시키는 연산이 필요합니다. 그래서 WAS는 반환만이 아닌 연산 기능을 포함하고 연산을 토대로 정보를 가공하여 동적인 페이지를 사용자에게 반환합니다. 

위 그림에선 설명이 쉽도록 Web server를 거쳐 WAS로 가는 것처럼만 그려졌지만 사실 WAS 안에도 정적 페이지를 처리하는 Web Server와 동적 요청을 처리하는 Web Container가 있습니다.

따라서 현재 구조는 크게 위 사진을 따르며 여기서 Web Container에서 동적인 컨텐츠를 생산하여 페이지를 반환합니다. 최근 개발하는 대부분의 웹 서비스는 웹 서버와 WAS를 동시에 사용하며 그 아키텍쳐들은 이해를 위해 위 같은 그림으로 표현한 것이기에 좀 더 복잡한 형태를 갖고 있음을 알고 있으면 됩니다.

 

이제까지 서버가 client 요청을 받고 반환하는 파이프라인을 설명했습니다. 하지만 대략적인 흐름을 파악했을지언정 과정에 대한 이해가 아직 잘 되지 않습니다. 그렇기 때문에 첫째로 서버에서의 연산은 JAVA 코드가 그대로 수행하고 요청인 html 코드는 따로 처리하는 기술인 CGI(Common Gateway Interface)를 이해해야합니다. 같은 Interface인 API가 그렇듯 이 역시 기술이자 사양입니다. API를 잘 모르신다면 https://fadet-coding.tistory.com/7 이 글을 참고해주세요. 이렇게 설명하고 끝내면 좀 아리송할테니 예시를 들겠습니다.

 

사용자가 서버에 요청을 보내는 건 HTML파일의 폼 형식을 이용합니다. 그렇기때문에 html파일이 전달되겠죠? 이럴경우 JAVA로 작성된 WAS는 해당 html을 JAVA코드로 변환해야 연산을 처리하고 다시 응답을 해줄땐 역 과정을 수행해야 할겁니다. 당연히 html을 JAVA로 변환해야할 필요가 있었고 변환을 위해선 개발자가 직접 파싱*해야하니 개발자는 비즈니스 로직도 작성을 해야할 시간에 파싱 작업을 해야하니 시간이 너무 많이 빼앗겼습니다. 결국 그 변환 과정을 대신해줄 어떤 기술이 필요했고 그래서 탄생한 기술이 CGI입니다. html을 JAVA로 파싱해주는 변환 프로그램이 있다고 했을때 요청에 따라 그 변환 프로그램을 실행시키는 기술을 CGI라고 생각하시면 편합니다. CGI를 프로그램으로 착각하시곤 하는데 그것은 과거 C나 Perl로 작성한 CGI 프로그램을 CGI라고 통칭해 부르곤 해서 생긴 오해입니다.

* 파싱(parsing)이란 구문 분석이며 여기선 변환의 의미로 사용됨

 

하지만 설명만 들으면 확장성이 뛰어날 수 밖에 없는 CGI는 단점이 존재했기 때문에 현재는 잘 쓰이지 않습니다. 그 중 가장 큰 문제는 요청 하나마다 CGI 프로세스가 하나 생성된다는 것이었고 이 말은 요청 하나마다 프로세스가 하나 실행되어야한다는 것이입니다. CS를 공부하셨다면 프로세스의 생명주기마다 얼마나 리소스를 잡아먹는지 아실 것이라 생각합니다. 특히 이 단점은 JavaScript나 이후 볼 JSP같은 스크립트 언어에게 매우 치명적입니다. 스크립트 언어(뒤에 설명합니다)는 보통 코드가 실행될 때마다 해석을 해야 했고 아무리 시간이 짧게 걸려도 이 요청들이 많아지면 감당하기 힘들기 때문이죠. 그렇기 때문에 JAVA진영에선 이 CGI를 대체할 기술이 필요했고 여기서 서블릿(Servlet)이 등장합니다.

 

 

서블릿 (Servlet)

 

앞서 CGI부분에서 설명했듯 웹의 사용자쪽 View를 이루고 있는 근간은 html이며 서버쪽의 코드는 JAVA로 작성되어 있습니다. 그렇기때문에 CGI 기술을 사용하여 매번 둘을 변환해줘야 했기 때문에 성능에 큰 이슈가 생길 수 밖에 없습니다. 따라서 CGI처럼 변환을 해주되 좀 더 효율적인 방식의 기술이 필요했고 그 때 등장한 것이 서블릿입니다. 일단 서블릿을 JAVA로 되어있는 CGI라는 오해를 하시는 분들이 많기에 말하지만 서블릿은 하나의 자바 클래스이고 CGI는 프로그램을 실행시키는 기술입니다. 둘의 역할에 있어 공통점은 있을 수 있지만 별개의 개념이라는 것을 알아주세요

 

서블릿은 CGI처럼 html과 JAVA코드를 변환한다는 공통점은 비슷합니다만 큰 차이점이 세 가지 존재합니다. 1 CGI는 요청마다 하나의 프로세스가 실행되지만 서블릿은 이미 프로세스 1개가 실행되어 있고 그 안의 스레드들이 정해진 방식에 따라 요청들을 처리하기 때문에 성능적으로 큰 이득이 있음 2 서블릿을 관리하는 서블릿 컨테이너가 따로 존재하여 개발자들이 서블릿을 작성하기만 해놓으면 생명주기 등의 관리는 서블릿 컨테이너에게 위임되어 개발자가 좀 더 비즈니스 로직에 전념할 수 있게 됨 3 JAVA코드로 쓰인만큼 JAVA의 큰 특징인 플랫폼에 독립적이라는 특성을 가져 제약에서 더 자유로움

 

사실 서블릿은 문장 몇 개로 요약할 수 없을 정도로 JAVA 웹 기술의 근본적인 근간을 이루고 있고 직접 눈에 보이지 않더라도 현재까지 mvc 프레임워크를 동작시키는 핵심 기술입니다. 따라서 다음 포스트에서 차근차근 서블릿에 대해 자세히 알아볼 것이기에 개발자들에게 JAVA 클래스 html로 파싱하는 로직을 위임하지만 성능 이슈를 크게 줄인 중요 기술로 알고 일단 넘어가겠습니다. 

 

그래도 간단한 구조만 살짝 알아보고 가겠습니다. 서블릿이란 동적인 요청을 받아 연산을 수행하는 자바 클래스이자 웹 기술이며 하나의 패키지입니다. 다음 포스트에서 더 자세히 설명할 것이기 때문에 일단 JAVA를 안다면 서블릿을 하나의 JAVA Class로 생각하고 글을 읽으시면 됩니다. 우리는 앞서 Web Container에서 서블릿이 동적인 컨텐츠를 생산하는 것을 살펴봤습니다. 그 웹 컨테이너 안에 서블릿 컨테이너가 존재하며 Java 코드로 작성된 서블릿은 서블릿 컨테이너에 등록되며 요청이 올 때 서블릿 객체를 만들게 됩니다.

public class myPostServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
	...
    
    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
	...

위 코드에서 메소드 로직은 중요치 않으니 생략하고 전체적인 구조만 설명하겠습니다. 정말 간단히 요약하자면 서블릿은 request와 response를 가지고 있습니다. 이 때 개발자가 사용하기 편하도록 한 구현체들이 HttpServletRequest, HttpServletResponse라 보시면 편합니다.

 

위 코드를 보시면 사용자로부터 myPostServlet에 요청이 왔을때 request를 인자로 받아 글 조회와 같은 get 요청이 오면 doGet을 실행하고 글 작성과 같은 post 요청이 오면 doPost를 실행하여 로직이 이뤄지고 나온 값을 response에 담아 반환합니다. 위의 코드를 아래의 그림으로 간단히 나타내면 HttpServletRequest의 request 객체는 HttpRequest, myPostServlet이 서블릿, HttpServletResponse의 response 객체는 HttpResponse가 될겁니다.

 

 

서블릿으로 인해 좀 더 동적인 서버 구축이 가능해져 사용자도 만족하고 그 동적인 구축이 좀 더 쉬워져 개발자들도 만족하고 넘어갈 수 있었을지도 모릅니다. 하지만 개발자들은 아직 만족하지 않았습니다. 개발자 입장에서는 서블릿을 직접 다뤘을때의 코드가 상당히 길고 이들의 생명주기(서블릿의 생성~소멸) 등을 관리해주는 서블릿 컨테이너도 부하가 걸리면 어떻게해야하는지 신경써줘야 하는 등 시간을 빼았기는 마찬가지였습니다. 하지만 이런 문제들보다 서블릿을 직접 다룬다는 것의 더 큰 산은 바로 'HTML을 직접 작성해줘야 한다'는 것이었습니다.

 

 

결국 서버는 사용자의 요청에 반응하여 페이지를 만들어서 반환해야 했습니다. 하지만 이 짧은 코드만 봐도 디버깅할 생각에 신나실텐데 이 코드가 몇 백줄이라면 어떠실 것 같나요? 이처럼 페이지를 직접 생성해주는 서블릿에는 자바 코드에서 선언한 변수와 html을 조합하여 페이지를 작성해주는 코드를 작성해야 했고 저는 말로만 들었지 상상만 해도 과거 개발자들이 얼마나 고통스러웠을지 가늠이 되는 것 같습니다.

 

JSP (JAVA Server Pages)

 

 

서블릿은 정말 굉장한 기술이지만 직접 서블릿만을 사용하여 서버를 구축하는 것은 개발자들에게 꽤나 고역이었습니다. 이런 서블릿만 사용하던 개발자들에게 등장한 것은 JSP란 서버사이드 스크립트 언어입니다. 스크립트 언어는 프로그래밍 언어의 한 종류이지만 JAVA나 C++과는 조금 결이 다르게 기존에 존재하는 소프트웨어(어플리케이션)을 제어하기 위한 용도로 사용되는 언어입니다.

 

아마 ASP, PHP 등 다른 스크립트 언어들도 들어보셨을 것이라 생각하는데 JSP를 쉽게 설명하면 JSP파일은 HTML코드와 자바 코드로 작동하는 스크립트 영역으로 구성되며 작성된 이 파일은 서블릿으로 변환되어 사용자에게 페이지를 렌더링해주는 것입니다. 이 설명은 JSP는 하나의 스크립트 언어이자 템플릿 엔진이라는 것을 알려줍니다. JSP는 스크립트 언어이기에 HTML과 결합해 템플릿 엔진으로 쓰일 수 있다는 게 더 정확한 설명일겁니다. 템플릿 엔진이란 말 그대로 템플릿 양식에 프로그래밍 언어를 결합한 엔진입니다.

 

여기서 오해하면 안되는 것은 JSP의 도입이 서블릿이 한계를 봉착하였기에 이것을 더 이상 쓰지 않고 JSP란 신기술을 썼다는 개념이 아니란 것입니다. 서블릿은 현재까지 사용되는 JAVA 웹 기술의 핵심 기술이며 앞서 불편함을 느낀 부분은 서블릿 그 자체가 아닌 서블릿의 View 생성 기능입니다. 서블릿이 동작하는 과정에서 이 View 생성 기능이 불편했기에 JSP라는 스크립트 언어이자 템플릿 엔진을 중간 단계에 도입한 것이죠. 결과적으로 작성된 JSP는 서블릿으로 변환되어 똑같은 파싱 과정을 거칩니다.

 

예시를 들어 설명하면 기존의 서블릿은 자바 코드안에서 변수 total을 선언하고 페이지에 이 값을 넣으려면 println을 통해 html코드와 변수를 함께 출력했어야 했습니다.

// 페이지 생성 서블릿 (.java 클래스)
public vod doGet(HttpServletRequest request, HttpServletResponse respone) {

int total = 0;
PrintWriter out = response.getWriter();
out.println("<HTML>");
...
out.println("1+2+3+4+... = %d, total");

 

하지만 JSP는 .html 파일 안의 html 코드 안에서 <% ... %>같은 스크립트 영역에 자바 코드로 비즈니스 로직을 코딩하여 페이지를 생성하기 위해 개발자가 메서드로 하나하나 html 코드를 출력해야하는 방법을 벗어날 수 있었습니다.

<!DOCTYPE html>
<html>
<head>
</head> <title>Insert title here</title>
</head>
<body>
<%String num_ = request.getParameter("num");
if(num_ != null && !num_.equals(""))
num = Integer.parseInt(num_);%>
<% if(num%2 != 0){ %> 홀수입니다.
<% } else{ %> 짝수입니다.<% } %>
</body> 
</html>

 

이 JSP의 도입으로 자바는 웹 분야에서 점유율을 크게 상승했습니다. 특히 유지보수가 상대적으로 편리하고 안정적이었기에 특히 대규모 기업용 시스템 구축에 사용되었고 실제로 아직도 많은 기업에 JSP로 짜인 레거시들이 남아있습니다.

 

그러나 이렇게 좋아보이는 JSP도 쓰다보니 단점이 명확했습니다. JSP도 결국은 서블릿과 마찬가지로 한 파일 안에 사용자에게 보여주는 View 영역(html 코드)과 서버에서 연산하는 로직이 담긴 영역(스크립트 코드)가 존재했고 jsp파일은 코드가 길어질수록 작동은 하지만 어디서부터 손을 대야할지 모를 일명 '스파게티 코드'가 되어 개발자들을 힘들게 했습니다. 그 일례로 프로덕트에서 한 오류가 발생하여 디버깅을 해야했는데 원인을 해결하기위해 jsp 수정을 해야하는 상황이었지만 코드가 너무 길어 다른 개발자들이 수정할 엄두도 내지 않아 결국 그 부분과 연관된 어떤 문제라도 생기면 항상 그 파일을 작성한 개발자가 직접 해결해야하곤 했다는 썰이 있습니다. 게다가 JSP는 속도도 느렸고 기능도 뭔가 조금 부족한 느낌이었습니다.

 

mvc의 대두와 EJB, JAVA진영의 겨울나기

 

 

결국 서블릿을 그대로 사용하는 것이나 JSP를 사용하는 것 모두 Client에게 보여주는 View와 서버에서 처리해야하는 로직이 섞여 있다는 것이 큰 걸림돌이었고 그렇기에 개발자들은 View와 비즈니스 로직을 분리 하려는 시도를 했고 결국 1979년에 처음 등장했지만 그렇게 주목받지 않았던 MVC 패턴이란 것이 수면 위로 올라오게 됩니다. MVC 패턴이란 Model, View, Controller 세가지 Component로 분리하여 설계하는 디자인 패턴입니다. MVC가 무슨 프로그램이고 프레임워크고 그런 것이 아니라 예시를 들어 설명하면 레스토랑에서 조리를 하기 위해 주문 확인, 재료 준비, 조리, 서빙 같은 업무를 나누고 나뉜 업무에 따라 사람을 배정하듯 MVC 패턴도 요청 분류, 정보 가공, 페이지 제공 등의 업무를 나누고 이를 MVC 각각의 Component에 배정한 것입니다. MVC 패턴에서 각각의 역할은 크게 다음과 같습니다.

MVC 구조에 대한 설명은 다음 포스트에서 더 자세히 설명할테니 여기까지만 알고 넘어가시면 됩니다. 이 다음으로 가기 전에 하나 알아야 할 것이 있습니다. 지금까지 동적인 웹을 개발하기 위해 살펴봤던 서블릿, JSP는 사실 소규모 홈페이지를 운영할때 다른 기술로 충분히 대체 될 수 있습니다. 그렇지만 홈페이지가 거대해지고 어플리케이션이 비대해질수록 이러한 기술은 필수적이게 되고 JAVA를 만든 썬 마이크로시스템즈는 이 점을 알고 J2EE(Java 2 Enterprise Edition)라는 기업용 어플리케이션을 만드는데 사용되는 스펙들을 모아둔 스펙 집합이자 플랫폼을 내놨습니다. 서블릿과 JSP 모두 이 J2EE 스펙 중 일부이고 JAVA 개발자들은 이를 이용해 어플리케이션을 만들었습니다.

 

이 J2EE에서 서블릿, JSP 말고도 하나 더 주목해야할 스펙은 바로 EJB(Enterprise Java Bean)입니다. 개발자들은 어플리케이션을 만들면서 서블릿, JSP를 통해 동적인 페이지를 보다 편리하게 생성할 수 있었지만 대규모 어플리케이션에선 사용자가 몰리면 어떻게 해결할지, 메모리를 어떻게 관리해야 서버가 죽지 않을지, 이후 살펴볼 트랜잭션을 어떻게 처리하여 DB를 관리할지 등의 문제가 산적해 있었고 이를 JAVA코드만으로 해결하기엔 너무 큰 비용이 발생했습니다. 이 때 EJB가 그런 개발자들의 고민을 조금이나마 덜어주었습니다. 현재 개발환경에서 대규모 기업은 프론트엔드, 백엔드, DB, 인프라가 분리되어 있듯 DB 관리, 분산 처리 등 대규모 기업에서 표준처럼 쓰이는 기능들을 개발자가 만들지 않고 EJB라는 기술을 사용함으로 좀 더 빠른 서비스 개발이 가능해졌습니다.

 

하지만 JAVA가 어떤 언어였는지 다시 한 번 생각해봅시다. 그렇죠 JAVA는 OOP에 충실한 언어입니다. 그런데 JSP는 View와 비즈니스 로직을 한데 묶어 객체지향적인 설계를 벗어났고 EJB는 앞서 설명한 장점도 분명히 존재했기에 이론적으로는 훌륭했지만 기업용으로 설계되어 비싸고 게다가 사용하기에 너무 복잡한데다 느려서 개발자들이 다루기 어려웠고 그 난이도때문에 JAVA의 본질인 객체지향적인 설계를 하기 너무나 어려웠습니다. 그래서 그 당시 개발자들은 EJB를 사용하느니 POJO(Plain Old Java Object)를 사용하자는 말도 했었습니다. POJO란 EJB나 다른 기술들 안에서 그 기술들에 의존적으로 작동하는 무거운 JAVA 객체가 아닌 것을 가리키는 용어로 말 그대로 어디서나 작동하는 가벼운 JAVA 객체를 뜻합니다. 그렇게 이런 많은 우여곡절을 지나 개발자들은 J2EE에만 의존하지 않으며 단순하고 쉬운 오픈소스를 하나 둘씩 만들기 시작합니다.

 

스프링(Spring)의 등장, JAVA진영에 찾아온 봄(?)

 

앞서 말했듯 EJB는 이론적으론 매우 훌륭한 기술이었지만 백엔드를 직접 구축하는 JAVA 개발자들에겐 실용적이지 못했고 이 EJB를 사용해서 개발하던 시절을 JAVA진영의 겨울에 빗대어 표현합니다. 하지만 하나 둘 좋은 오픈소스가 등장하기 시작했고 그 때 JAVA 진영을 구해주기 위해 등장한 개발자가 Spring의 로드 존슨과 Hibernate의 개빈 킹입니다. 하이버네이트는 나중에 설명할 일이 있을 것이기에 넘어가고 여기서 우리가 주목해야할 것은 로드 존슨의 Spring입니다. 

 

 

2002년 로드 존슨은 한 책을 출간하여 EJB의 문제점을 비판하고 IoC, Di, POJO(다 뒤에 다시 언급할 겁니다) 등 보다 더 객체지향적인 핵심 기술을 담은 예제 코드를 책에 수록하였고 그 코드를 본 유겐 휠러와 얀 카로프가 로드 존슨에게 오픈 소스 프로젝트를 제안하게 됩니다. 그 프로젝트가 바로 스프링(Spring)이고 이 프로젝트의 의미는 JAVA진영의 추운 겨울을 끝내고 봄을 가져다주길 바라는 뜻에서 지어졌으며 실제로 소설처럼 그 이름은 정말 JAVA 개발자들에게 봄을 가져다주게 됩니다. 하지만 실제로 봄이 찾아온 것은 스프링의 등장 이후 몇 년이 지나서였습니다.

 

MVC 프레임워크의 난립, 이를 끝낸 스프링 MVC
그래도 결국 봄은 온다

 

드디어 우리가 아는 스프링 등장했으니 이건 혁신이었을거야!라고 말하고 싶지만 이전에 말한 것처럼 스프링의 등장 전부터 개발 일선에 MVC 패턴이 떠오르기 시작했고 많은 수의 MVC 프레임워크들이 쏟아져 나왔기에 스프링은 시작부터 그렇게 거물급 유망주는 아니었습니다. 이는 몇 년 전까지 스프링보다는 스트럿츠 등 다른 프레임워크들이 더 인기있다는 것을 생각하면 알 수 있습니다.

 

하지만 시간이 지나며 개발 트렌드가 MSA, 클라우드로 변하며 스프링의 철학인 DI, IoC, PSA 등이 JAVA의 OOP와 결합했을때, 그리고 스프링 프레임워크가 모듈 기반이라는 것이라는 점과 너무 잘 맞았기에 사용이 크게 증가했습니다. 스프링과 MVC가 결합된 과거 스프링 MVC도 나름 선전했으나 MVC 프레임워크의 춘추전국시대를 끝낼 순 없었지만 이후 이 스프링 MVC가 어노테이션 방식과 결합하여 더욱 사용하기 편하고 모듈화라는 특성으로 인해 스프링은 JAVA 개발자들이 그렇게 찾아 헤매던 '단순하고 간단하며 객체지향적인' 프레임워크로 재탄생하며 엄청난 점유율을 차지하게 됩니다. 이 부분은 최종장에서 더 자세히 다룰테니 이 정도로 넘어가겠습니다.

 

.

 

---

이번 포스트에선 스프링의 역사를 한 번 훑어봤는데 중간에 설명한 생략들이 좀 있었고 끝에 사실은 스프링 부트 내용을 일부러 뺐습니다. 글이 너무 길어지기도 했고 스프링의 기능을 소개할 때 같이 언급하면 좋을 것 같다는 판단이었거든요. 다음 포스트부터는 이번 포스트에서 간단하게 짚고 넘어간 스프링의 핵심 기술인 서블릿을 시작으로 스프링의 용어나 구조를 하나하나 소개하는 글이 될 것 같습니다.

 

refer

https://woongsin94.tistory.com/357

EJB(Enterprise Java Bean)

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8#

스프링 핵심 원리 - 기본편 - 인프런 | 강의

https://gyrfalcon.tistory.com/entry/J2EE

J2EE란?

https://velog.io/@jakeseo_me/%EC%9E%90%EB%B0%94-%EC%84%9C%EB%B8%94%EB%A6%BF%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90.-%EA%B7%BC%EB%8D%B0-%ED%86%B0%EC%BA%A3%EA%B3%BC-%EC%8A%A4%ED%94%84%EB%A7%81%EC%9D%84-%EC%82%B4%EC%A7%9D-%EA%B3%81%EB%93%A4%EC%9D%B8

자바 서블릿에 대해 알아보자. 근데 톰캣과 스프링을 살짝 곁들인