웹 서버의 흐름을 살펴보고 그에서 파생된 궁금증을 다뤄보겠다.
우선 웹 서버의 흐름을 살펴보자.
웹 서버는 클라이언트의 요청에 의해서 실행된다. 단독으로 알아서 막 수행되지 않는다.(물론 그렇게 실행되는 방식도 존재하지만 보통은 그렇다.)
(client) 도메인으로 웹 페이지에 접속하기
우리가 웹 페이지에 접속하는 과정을 생각해보자.
실은 과정이랄 것도 없이, 특정 도메인을 검색창에 입력하면 된다.
내부적으로 이 도메인은 모든 도메인 정보가 집결되어있는 DNS 서버(이는 계층 구조의 DNS 시스템으로 구성된다)에서 IP 주소를 얻는다.
IP 주소로 TCP 3-way hand shake를 수행해 연결을 맺는다.(이제 HTTP 요청 준비완.)
(server) 웹 서버에 도착한 클라이언트의 요청 처리하기
이는 현대적 방식의 웹 서버를 표현한 것이다.
Reverse Proxy Server?
크게 두 가지 이유에서 존재한다.
1. 원본 서버를 감춘다. 보안적인 측면에서 클라이언트가 직접 접근하는 것을 방지하여 클라이언트는 프록시 서버의 정보만을 알게 한다.
2. 로드 밸런싱 역할을 한다. 특정 서버에 트래픽이 집중되면 다른 서버 풀로 분산한다.
최근 웹 서버는 대부분 리버스 프록시를 두어 보안을 강화하고 트래픽을 분산한다.
Web Application Server?
동적 컨텐츠를 처리하는 주체를 별도의 서버로 분리한 실행 환경이다.
Node.js, Python(Django + WSGI 등) 등 다양한 언어 생태계에서 구현된다.
비즈니스 로직을 수행하고, 데이터베이스와 통신하며 응답을 생성한다.
이 응답은 프록시 서버로 전송한다.
이제 흐름을 알아보았다.
여기서 궁금증이 두 가지 뻗어 나왔다.
- 이 구조에서 프론트엔드의 영역은 어디인가?
- SSR과 CSR은 어떻게 구현되는 걸까?
Frontend developer vs Backend developer
이렇게 나눌 수 있겠다.
Frontend
프론트엔드는 사용자에게 보여지는 영역의 UIUX 통틀어 말한다.
IP로 접속한 사용자의 브라우저에 처음으로 표시될 HTML/CSS/JS 화면을 구현한다.
그리고 사용자와의 상호작용을 통하여 HTTP 요청을 수행한다. 예컨대, 로그인 입력 포맷을 입력하고 확인 버튼을 누르면 POST 요청으로 연결된다.
또한, 서버로부터 받은 응답을 데이터 형식에 따라 재조립하여 브라우저에 띄운다.
이 과정에서 브라우저를 대신하여 서버로 HTTP 요청(이 방법은 API 요청이라 칭한다.)을 한다.
Backend
백엔드는 사용자에게 보이지 않는 모든 처리 로직을 담당하며, 인증, 데이터베이스 통신, API 응답 생성 등 다양한 역할을 수행한다.
더 세부적으로는 DevOps, DB, 보안 등으로 나뉠 수 있지만, 일반적으로 이를 통틀어 백엔드 개발 영역이라고 부른다.
SSR vs CSR
SSR
서버에서 HTML을 완성해서 클라이언트에 전달하면, 클라이언트는 이를 바로 렌더링하면 된다.
이를 Server-Side Rendering 이라고 한다.
이 방식은 서버가 전부 다 해주기 때문에 클라이언트(브라우저)에 부담이 적다는 점이 장점이다. 그리고 초기 렌더링 속도가 빠르기 때문에 사용자 이탈률이 감소한다.
하지만 모든 HTML 문서가 네트워크로 오가기 때문에 네트워크 부하가 생길 수 있다.
또한 매 요청마다 전체 HTML을 다시 받아오기 때문에 브라우저는 기존 DOM을 모두 버리고 새로 렌더링하게 된다.
그 결과 사용자 입장에서는 자꾸 초기화되는 느낌을 받아 불편감을 느낄 수 있다.
CSR
초기에는 최소한의 HTML과 JS만 받고, 클라이언트가 서버에서 받은 JSON 데이터를 사용하여 브라우저에서 동적으로 HTML을 생성한다.
이를 Client-Side Rendering 이라고 한다.
이 방식은 빨라진 브라우저 속도에 따라 현대에서는 SSR 보다 많이 사용된다.
CSR은 React 등에서 Virtual DOM을 사용하여 변경된 부분만 효율적으로 갱신한다.
전체 페이지를 다시 그리지 않고 필요한 부분만 빠르게 렌더링하므로 부드러운 UX를 제공한다.
하지만, CSR은 초기 로딩 시 HTML에 콘텐츠가 없기 때문에 검색 엔진 크롤러가 페이지 정보를 제대로 수집하지 못한다는 문제가 있다.
따라서 검색 최적화(SEO)가 중요한 서비스에는 불리할 수 있다.
+ 혼합 방식
최근에는 SSR과 CSR을 적절히 혼합한 구조도 널리 사용된다.
Next.js는 서버에서 HTML을 미리 렌더링하고,
클라이언트가 이를 이어받아 동적으로 업데이트하는 Hydration 방식을 사용한다.
