Servlet과 Web app

2024-08-17 8 분 소요

Web Application

옛날에는 HTML만을 이용하여 사용자에게 정보를 전달하고, 반대로 사용자들은 해당 웹 페이지에 아무런 정보도, 요청도 전달할 수 없는 일방적인 관계에 놓인 웹 페이지들이 많았다고 한다. 즉, 일방적인 정보 전달만을 목적으로 하는 웹 사이트들이 대부분이었다고 한다. 그러나 요즘 들어서는 쇼핑몰, sns, 유튜브 등의 여러 웹앱(Web app, Web application) 형태의 웹 페이지들이 많아졌다. 이들의 공통점은 컨텐츠 제공자가 웹 페이지를 통해 사용자에게 일방적으로 정보만 전달하는 역할에서 더 나아가, 이젠 사용자도 특정 정보를 입력하여 어떠한 요청을 할 수 있게 되었고, 이 요청에 대한 결과로 사용자마다 각각 다른 결과물을 받아볼 수 있게 되었다. 또한, 이러한 웹 페이지에서 사용자는 이제 특정 목적을 수행할 수 있게 되었다. 예를 들어 쇼핑몰 사이트에서 특정 물품을 구매하기 위해 구매수량, 배송지 등을 입력하면 이러한 정보가 처리되어 결국에는 물품이 배달되는 것처럼 말이다. 이제는 웹에서도 마치 앱 또는 프로그램처럼 특정 목적을 달성하기 위한 웹 페이지를 만들 수 있게 되었다.

이렇듯, 웹앱은 웹 브라우저에서 실행되는 애플리케이션이다. 웹 브라우저, 그리고 인터넷만 연결되어 있으면 언제 어디서든 접근할 수 있기에 별도의 프로그램을 설치하지 않아도 된다는 장점이 있다. 이러한 웹앱을 통해 사용자에게 다양한 서비스를 제공할 수 있게 된다. 쇼핑몰, 블로그, sns 등이 그 예이다.

아무래도 대부분의 웹앱들은 사용자가 입력한 정보, 또는 그 외에 어떠한 상황 등의 여러 변수들에 의해 사용자에게 보여주는 결과물이 달라지기 마련이다. 예를 들어, 같은 유튜브라도 만약 A 사용자는 주로 “먹방” 컨텐츠를 보고, B 사용자는 “과학” 관련 컨텐츠를 본다면, 같은 유튜브 사이트라도 A 사용자는 추천 영상이 대부분 “먹방”일테고, B 사용자는 “과학”을 주제로 한 영상들이 추천으로 뜰 것이다. 또는, 로그인 화면에서 만약 잘못된 정보를 입력하면 로그인이 실패했다는 화면을 띄우고, 만약 로그인이 성공되었다면 해당 사용자에 맞는 개인화된 정보들을 보여주는 것도 그 예이다.

이렇듯 웹앱은 그 특성 상 “동적 웹 페이지”의 특징을 띤다.

정적 웹 페이지 VS 동적 웹 페이지

웹 페이지는 크게 두 종류로 나눌 수 있다. 정적 웹 페이지(Static Web Page)와 동적 웹 페이지(Dynamic Web Page)이다.

정적 웹 페이지는 웹 서버에 미리 저장된 HTML, CSS, JS, 이미지 등의 파일들을 클라이언트(여기선 주로 브라우저)에 전송하는 방식의 웹 페이지를 말한다. 이러한 특징에 의해, 서버에 저장된 데이터가 변경되지 않으면 고정된 웹 페이지만을 볼 수밖에 없다. 따라서 모든 사용자가 언제 어디서든 해당 웹 페이지를 보면 항상 똑같은 화면만을 볼 수밖에 없다는 단점이 있다. 옛날에 정보 전달만을 목적으로 한 웹 페이지들이 아마 이 방식이었을 것이다.

이러한 정적 웹 페이지로는 한계가 많다. 예를 들어 웹 사이트 메인 페이지에 “오늘의 날씨”를 띄우고 싶어도 정적 웹 페이지로는 구현하기 힘들 것이다. 오늘의 날씨란 게 그 날씨 데이터가 하루하루마다 바뀌는 건데, 날씨 데이터를 개발자 또는 서버 운영자가 매일매일 서버에 업데이트하는 것은 정말 곤욕일 것이다. 이렇듯 정적 웹 페이지를 사용하면 데이터의 생성, 수정, 삭제 등의 변형 작업을 서버에서 직접 수행해야 하기 때문에 번거로우며, 아주 빠른 시간 내에 데이터의 업데이트가 잦은 작업에 대해서는 사실상 대응을 할 수가 없다. (유튜브를 생각해보라. 하루에도 몇 천, 몇 십만 개의 영상들이 업로드될 텐데 이걸 일일이 서버 관리자 또는 개발자가 서버에 업로드해야 한다고?) 따라서 정적 웹 페이지로 웹앱을 구현하는 게 사실상 불가능하다고도 말할 수 있을 것이다.

이러한 정적 웹 페이지는 그 사이트의 url를 복사하고 다시 주소창에 해당 url을 입력하여 들어갔을 때 똑같은 내용이 나오는 것이 특징이다.

반면, 동적 웹 페이지는 사용자의 요청 또는 여러 상황 등에 의해 동적으로 HTML 문서를 생성하여 웹 페이지를 보여주는 방식이다. 예를 들어, 로그인 화면에서 사용자가 자신의 아이디 및 패스워드를 입력하면 해당 사용자의 정보들로 구성된 이메일 페이지 등을 보여주고, 로그인에 실패하면 실패한 결과를 보여주는 것이 그 예이다. 사용자가 입력한 정보와 요청에 따라 화면에 보여질 결과물이 달라지도록 할 수 있는 특징이 있다. 이러한 특성 때문에, 모든 사용자들은 같은 웹 페이지에 들어가더라도 각자 다른 형태의 웹 페이지를 보게 된다. 꼭 사용자가 정보를 입력하여 요청하지 않더라도 “오늘의 날씨”, “오늘의 추천상품” 등 시간에 따라서도 유연하게 웹 페이지에 보일 정보들을 다르게 할 수 있다.

정적 웹 페이지와 동적 웹 페이지 각각의 장단점을 정리해보면 다음과 같다.

정적 웹 페이지의 장점
- 요청에 대해 파일만 전송하면 되는 방식이라 서버 간 통신이 거의 없어 속도가 빠른 편.
- 사용자가 입력한 정보에 따라 유연하게 대처하여 요청에 대한 결과물을 다르게 보여줘야 하는 동적 웹페이지에 비해, 정적 웹 페이지는 단순한 정적 파일들만으로 구성되어 있기에 모든 웹 호스팅 서버에서도 작동할 수 있으며, 웹 사이트 구축에 적은 비용이 든다. 그 예로, Github Pages는 정적 웹 사이트 호스팅을 지원하며, 무료로 사용할 수 있다. 따라서 간단한 정적 웹 사이트를 만들어 이를 repository에 올리고, 이 repo를 토대로 웹 호스팅을 할 수 있다.
정적 웹 페이지의 단점
- 사용자가 입력한 정보를 토대로 한 요청에 대해 유연하게 대처하여 각기 다른 결과물을 보여줄 수가 없다.
- 이로 인해 웹 앱 구현에는 부적합함.
동적 웹 사이트의 장점
- 사용자 요청 등의 여러 변수에 따라 각기 다른 정보들을 조합하여 웹 페이지를 제공할 수 있기에 제공할 수 있는 서비스가 다양해지며, 이로 인해 사용자에게 좀 더 다양한 경험을 제공할 수 있다.
- 사용되는 데이터나 웹 페이지 구조가 자주 변경되는 방식일 때 사용할 수 있어 웹 페이지 관리가 용이해진다.
동적 웹 페이지 단점
- 사용자로부터 입력된 정보와 함께 전달된 요청을 처리하는 별도의 작업이 필요하기에 상대적으로 느리다.
- 웹 서버 외에 요청 처리를 위한 앱 서버가 별도로 필요하기에 추가 비용이 들 수 있다.

동적 웹 페이지의 종류

한 편, 동적 웹 페이지에도 두 가지 종류로 분류할 수 있다.

CSR (Client Side Rendering)

말 그대로 웹 페이지를 클라이언트(브라우저) 쪽에서 동적으로 렌더링하는 방식이다. 동적 요소들을 웹 페이지에 렌더링하기 위해 자바스크립트가 사용된다. CSR 방식에서는 웹 페이지를 사용자 화면에 띄우기 위해 다음의 과정들을 거친다고 한다.

요청을 받은 서버가 HTML 파일과 그 외 컨텐츠 파일(이미지 등)들을 클라이언트(브라우저)에 전송한다.
브라우저는 전송 받은 HTML 파일을 파싱(parse)하고 DOM 트리를 구성한다.
그 후, HTML에서 link로 연결된 CSS 및 자바스크립트 파일들을 브라우저에서 다운로드 받는다. 이 CSS, JS 파일들을 토대로 웹 페이지를 렌더링한다. 이 과정에서 텍스트, 이미지, 버튼, 스타일 등이 웹 페이지에 보인다.
동적 컨텐츠를 추가하는 자바스크립트 코드를 실행시킨다. 여기에는 데이터를 가져오는 과정도 포함되어 있다. 만약 react, vue 등의 프레임워크를 사용했다면 이 프레임워크로 작성된 코드들이 실행되는 단계이다.
만약 사용자가 버튼을 클릭하는 등의 행위로 인해 새로운 요청을 서버에 전송하면 서버는 그에 맞게 웹 페이지의 일부분을 재 렌더링하여 업데이트하여 보여준다.

과정을 좀 더 간략하게 말하자면, 먼저 서버에서 HTML, CSS, JS등의 자료들을 브라우저에 전송한 후, 브라우저에서 이를 렌더링하여 웹 페이지를 구성한다. 그 후 추가적인 데이터가 필요할 때 브라우저에서 서버에 또 요청을 하여 해당 데이터를 받아오는 방식이다. 이로 인해 어떻게 보면 웹 페이지를 구성하기 위해 서버에 두 번이나 요청을 하는 것이다.

CSR을 비유하자면, 어떤 사람이 어떤 가구 회사에서 맞춤 제작형 서랍을 주문했을 때, 배송 기사가 집에 와서 조립되지 않은 서랍들을 조립하는 것과 같다고 볼 수 있겠다. 그런데 생각해보니 각 서랍장에 표시할 라벨을 구매하는 것을 깜빡하여 같은 회사에 라벨을 옵션으로 추가 구매하여 서랍에 장착하는 것이다.

프론트엔드 구현을 위한 자바스크립트의 프레임워크인 react, vue 등이 대표적인 CSR 방식이라고 한다. 또한, 데이터 요청 시 전체 페이지 로딩이 필요없게끔 AJAX을 이용한 비동기 통신 기술이 사용된다.

CSR 방식의 장단점은 다음과 같다.

CSR 장점

사용자와의 웹 상호작용에 빠르게 반응할 수 있다. 이로 인해 컨텐츠 업데이트가 잦으면서도 전체 페이지를 업데이트할 필요가 없는 SNS, 온라인 게임, 채팅 앱 등을 CSR 방식으로 구현하는 게 좋다.
뒤에 소개할 SSR 방식은 웹 페이지가 서버에서 렌더링되는 방식이라서 서버에 많은 부담이 될 수 있다. 그러나 CSR은 클라이언트 쪽에서 렌더링되는 방식이기에 상대적으로 서버에 부담을 덜 줄 수 있다.

CSR 단점

앞서 언급했듯, 서버로부터 HTML 등의 파일들을 요청한 후, 이후 필요한 데이터들을 나중에 또 한번 서버에 요청하는 방식이다. 이로 인한 네트워크 비용이 발생한다.
검색 엔진 최적화(SEO, Search Engine Optimization)에 안 좋다. 봇이나 웹 크롤러가 웹 페이지의 구성을 인식하기 어렵게 하기 때문에 내가 만든 웹 사이트가 검색 엔진에 노출되기 쉽지 않다.
페이지 로딩 시간이 더 오래 걸린다. 웹 페이지 렌더링을 위해선 자바스크립트 파일을 다운로드받고 실행해야하는 구간이 생기기 때문이다. 이러한 페이지 로딩 때문에 사용자 입장에서는 화면에 빈 페이지 또는 로딩 화면만 보게 된다. 제작된 웹 페이지가 자바스크립트에 더 많이 의존할수록 이러한 현상이 뚜렷해진다. 앞서 든 서랍 비유를 들자면, 서랍이 미리 공장에서 생산된 게 아니라, 고객의 집에서 직접 조립되기 때문에 완성품을 보는 데에 시간이 걸리는 것과 같은 이치이다.
만약 사용자가 브라우저에서 자바스크립트 기능을 끈다면 화면 상에서는 HTML 문서만 보일 것이다.

SSR (Server Side Rendering)

서버 사이드 렌더링은 웹 페이지 렌더링이 서버에서 이뤄지는 방식이다. 사용자로부터 어떠한 정보와 함께 요청이 들어오면, 그 요청에 맞게 서버에서 웹 페이지를 렌더링하는 방식이다. 렌더링 과정은 다음과 같다.

요청을 받은 서버는 요청에 포함된 데이터를 추출하여 그에 알맞은 웹 페이지를 생성하기 위해 그에 맞는 응답 데이터를 HTML에 삽입한다.
페이지 구성을 위한 HTML을 생성하고, 컨텐츠를 렌더링하며, 스타일을 적용한다.
이렇게 완전히 렌더링된 페이지를 브라우저에 전송한다. 브라우저는 이미 완성된 웹 페이지를 받는 것이기에 웹 페이지 렌더링을 위한 별도의 자바스크립트 코드를 실행하지 않아도 된다.

앞서 든 가구에 다시 비유를 들자면, SSR은 고객이 맞춤형 서랍을 주문하면 해당 공장에서 조립되어 완성된 “완제품”을 고객의 집에 바로 배송하는 방식인 것이다. SSR은 웹 페이지 구성을 서버에서 모두 진행하기에 CSR과는 달리 브라우저에서 웹 페이지 구성을 위한 추가적인 데이터를 요청하지 않아도 되기에 이로 인한 네트워크 비용이 들지 않는다.

SSR의 장단점으로는 다음이 존재한다.

SSR 장점

서버에서 웹 페이지가 다 만들어져서 오기 때문에 봇이나 웹 크롤러가 해당 웹 페이지의 구성을 쉽게 인식할 수 있어 검색 엔진 최적화(SEO)에 적합하다. 따라서 내가 만든 웹 사이트가 검색 엔진에 노출되는 것이 최우선순위일 경우에 SSR방식을 사용하는 게 적합하다.
CSR이 브라우저에서 웹 페이지를 렌더링하는 방식이라 초기에 페이지 로딩 시간이 길어 사용자로서는 불편하다면, SSR은 서버에서 미리 만들어져 오기에 로딩 시간이 상대적으로 짧다. 주문한 서랍이 이미 공장에서 완제품으로 완성되어서 오기에 완제품을 빨리 볼 수 있는 것과 같은 이치이다. 이로 인해 랜딩 페이지 구현에 적합하다.
서버에서 웹 페이지가 미리 렌더링되어 나오는 방식이어서, 블로그와 같은 정적 컨텐츠가 메인인 사이트 개발에 적합하다.

SSR 단점

아무래도 서버에서 웹 페이지 렌더링 과정이 일어나기에, 서버에 부담이 가는 구조이다. 이로 인해 트래픽이 많거나 동시 접속자가 많은 구조의 웹 사이트 구현에는 부적합하다. 또한 서버의 리소스들을 많이 소비하기에 CPU 및 메모리 사용량이 많다는 단점도 존재한다.
CSR에 비해 사용자와의 상호작용이 즉각적으로 나타나기 어려울 수 있다. 따라서 사용자와의 상호작용이 잦거나, 데이터 및 컨텐츠의 업데이트가 잦은 사이트 구현에는 부적합하다.
CSR에 비해 개발 과정이 더 복잡하다고 한다.

Servlet

서블릿은 동적 웹 페이지 및 웹 앱(앞으로는 웹 애플리케이션을 간단하게 웹 앱이라 부르겠다)을 구현할 때 사용하는 자바 기술로, 사용자가 입력한 정보들을 토대로 클라이언트에서 요청을 보내오면, 서버에서 이 요청을 사용자가 전달한 정보에 따라 동적으로 처리할 때 사용되는 기술이다. HTML의 form 태그에 입력된 사용자의 정보들을 HTTP 요청을 통해 전달받아 이를 서블릿에서 처리할 수 있는 것이다. 자바에서는 서블릿도 클래스로 다뤄진다.

참고로, 웹 앱에는 HTML, 이미지 등의 정적 파일과 서블릿, JSP 등의 동적 파일로 구성되어 있다. 그래서 이후에 서블릿을 이용한 웹 앱 구현 시 정적 파일들과 동적 파일들을 같이 볼 수 있을 것이다.

References

[1] 채규태, “채쌤의 Servlet&JSP 프로그래밍 핵심”, (쌤즈, 2023)

[2] 웹앱

앱의 종류 : 네이티브 앱 vs 웹 앱 vs 하이브리드 앱

[3] 3) 동적/정적 웹 페이지

[4] 정적 웹페이지, 동적 웹페이지의 특징과 장단점

[5] 정적 웹페이지와 동적 웹 페이지

[6] [WEB] 정적 웹 페이지와 동적 웹 페이지

[7] Client-side Rendering (CSR) vs. Server-side Rendering (SSR)

This content is licensed under CC BY-NC 4.0