[싸피에서 뭐했니?] #Servlet #JSP #MVCPattern

안녕하세요~!! 11기 최민주 기자입니다 👋

3월달에는 웹 프론트엔드와 백엔드에 대해 학습했는데요, 친절하신 하이쌤의 설명 덕분에 이해가 쏙쏙 되었답니다!

 

그 중에서도 제 관심사인 웹 백엔드 흐름에 대해 개인적으로 정리한 내용을 간단히 공유드리도록 하겠습니다! 🙌 

 

웹의 역사와 흐름에 따라 각 개념이 등장한 순서는 아래와 같습니다.

`CGI -> Servlet -> JSP -> MVC Pattern`

 

CGI (Common Gateway Interface)

예전의 서버는 정적인 페이지만을 제공할 수 있었기 때문에, 사용자의 요청을 받아 정보를 동적으로 생성하고 이를 클라이언트에게 다시 보내주는 것이 불가능했습니다.

따라서 서버에서 다른 프로그램을 불러내고 그 프로그램 처리 결과를 보내줄 수 있는 인터페이스가 필요했는데, 이것이 바로 CGI입니다.

CGI의 등장으로 웹서버가 동적인 페이지를 생성할 수 있게 되었습니다.

 

CGI의 한계

하지만 CGI는 요청이 있을 때마다 새로운 `프로세스`가 생성되어 응답합니다. 따라서 사용자의 요청이 많을 때 서버에 부하가 크게 가게 되었고, 프로세스보다 더 작은 단위로 실행하는 것이 필요했습니다.

 

Servlet

이에 따라 프로세스보다 더 가벼운 `스레드` 단위로 실행하여 서버 부하를 줄이고 성능을 개선한 `Servlet`이 등장했습니다.

Servlet은 톰캣이 이해할 수 있는 순수 Java 코드로만 이루어진 웹서버용 클래스로, 서블릿을 이용하면 웹 프로그래밍이 가능합니다. 

(자바 코드 안에 HTML 코드를 포함)

 

Servlet의 LifeCycle

Servlet LifeCycle

 

1. 먼저 WAS는 클라이언트로부터 서블릿 요청을 받으면 해당 서블릿이 메모리에 있는지 확인합니다. 

2. (만약 해당 서블릿이 처음실행되어 메모리에 없다면) 서블릿 클래스를 메모리에 올리고 `init()` 메소드와 `service()` 메소드를 실행합니다. 

3. (만약 해당 서블릿이 메모리에 있다면) service() 메소드를 실행합니다.

4. WAS가 종료되거나 웹 어플리케이션이 갱신되어 서블릿 종료 요청이 있을 경우 `destroy()` 메소드를 실행합니다. 

 

Servlet의 한계

하지만 서블릿은 화면 인터페이스 구현에 너무 많은 코드를 필요로 하는 비효율적인 측면이 있었습니다. 또한 Java 클래스이기 때문에 테스트하기 위해서는 항상 빌드를 다시 하여 확인해야 하는 한계까 있었습니다.

 

JSP

서블릿의 한계를 보완하기 위해 등장한 것이 `서블릿 기반의 서버 스크립트 기술`인 JSP입니다.

(HTML 코드 안에 자바 코드를 포함)

 

스크립트 기술이란 ASP, PHP 처럼 미리 약속된 규정에 따라 간단한 키워드를 조합하여 입력하면,
실행 시점에 각각의 키워드에 매핑되어 있는 어떤 코드로 변환 후에 실행되는 형태입니다.

 

JSP가 서블릿으로 변환되어 실행되는 과정

 

일반적으로 정적인 페이지만 제공하는 웹서버가 동적인 페이지를 생성할 수 있도록 하는 것이 CGI이며,
마찬가지로 서블릿과 JSP 모두 동적 페이지 제공을 돕는 어플리케이션으로, CGI의 범주에 든다고 할 수 있습니다.

 

JSP의 한계

JSP만 이용한 개발(Model 1)방식에서는 Client의 요청에 대한 Logic 처리와 response page(view)에 대한 처리를 모두 했습니다. 이러한 방식으로 인해, 점차 유지보수 측면의 한계를 느끼게 되었습니다.

 

Model 1 구조

 

MVC Pattern (Model 2)

이후 서블릿과 JSP를 각각 Controller와 View의 역할을 나누어 사용하는 개발 방식(Model 2)이 등장했습니다.

따라서 JSP는 response page(view)에 대한 처리만 하게 되었습니다.

 

Model 2 구조

 

오늘은 입과 세 달차, 싸피에서 무엇을 배웠는지를 다뤄보았습니다!

그럼 다음에 만나요-! 👋