[Web] 웹의 진화과정(SSR, CSR, SSG, JAM Stack)

[Web] 웹의 진화과정(SSR, CSR, SSG, JAM Stack)

 

20여년 간 웹 기술은 폭발적으로 성장해온 것 같다. 위와 아래를 비교해보면 우리는 그 변화를 실감할 수 있다.

예전에는 서버에서 모든 문서를 가지고 있고, 구현을 할 것이 있으면 구현을 해서 사용자의 컴퓨터에 그 데이터를 쏴주었다면, 지금의 애플 공식 홈페이지와 같은 것은 서버단에서 구현을 해서 보내주는 것이 아니라, 이런 식으로 브라우저에서 구현을 하라는 코드를 쏴준다. 기술이 많이 발전했기 때문에, 무엇인가 스르륵 움직이는 것도 구현이 가능해진 것이다.

 

어케했냐를 물어볼 때에는, 과거를 살펴보고 발자취를 들여다보는 것이 좋을 때가 있다. 웹의 발전사가 그러하다.

이번 포스팅에서는 SSR SSG JAM Stack(CSR, SEO, Next js, Nuxt js, Gatsby) 등을 살펴보면서 어떻게 웹 기술이 발달했는 지 살펴볼 것이다.

 

 

 

 

 

 

 

 

 

 

SSR : Server Side Rendering

 

네이버의 홈페이지와 같이 내용이 많이 변동이 없는 것, 구글 처럼 검색 창만 딱 띄워놓는 것. 많이 변화가 필요가 없다. 그럴 때에는 서버에서 작동하는 것을 구현해서 사용자의 컴퓨터에 웹 문서와 관련된 데이터를 전송한다. 이 경우, 우리의 컴퓨터는 그 정보를 받아들이기만 하면 그것을 바로 화면으로 보여주기만 하면 되기 때문에 굉장히 빠르게 창을 열고 닫고 다른 페이지로 넘어갈 수 있다. 

 

 

CSR : Client Side Rendering

 

조금 더 동적인 화면을 보여주려고 하는 사람들의 열망에 의해 탄생했다.

 

SPA인 React or Vue가 이런 역할을 한다. 정적 웹사이트처럼 서버에게서 같은 것을 받아가는데 그곳에 있는 자바스크립트로 서버로부터 데이터를 요청해서 받아온 정보들을 가지고 사용자의 컴퓨터에 깔린 브라우저가 직접 구현해서 보여주는 것이다. 링크를 클릭할 때마다 다른 페이지로 이동하는 것이 아니라 같은 페이지의 자바스크립트를 사용해서 HTML 요소들을 계속 동적으로 바꿔주는 것을 클라이언트의 브라우저가 해주는 것이다. 

 

++ SPA가 이런 방식으로 처리를 하지만, SPA만 CSR 방식으로 무엇인가를 하는 것은 아니다. 

 

CSR, SPA로 어느정도 규모가 있는 사이트를 만들면, 처음에 화면이 로딩되는 속도가 느리다고 느껴질 때가 있다. 

보통 SPA 웹의 HTML 파일에는 body에 보통 빈 태그 하나만 들어간다. 화면에 보이는 HTML 요소들은 자바스크립트 코드에 들어있거나 서버로부터 요청해 받아온 데이터를 자바스크립트 코드가 동작하도록 만들어서 사이트 요소를 렌더링 해내는 것이다.

브라우저가 렌더링 해야하는 시간이 있기 때문에, 딜레이가 생기는 것이다.

 

 

하이브리드 프레임워크(Next.js, Nuxt.js)

 

SSR과 CSR의 장점들을 다 가져와서 웹 개발을 하기 위해 Next.js나 Nuxt.js 등 하이브리드 프레임워크가 나왔다.

Next.js는 React, Nuxt.js는 Vue에 각각 SSR로 페이지를 제공하는 기능들을 추가한 것이다. React나 Vue 사이트를 SSR로 사이트의 원하는 부분을 만들 수 있는 것이다.

 

쉽게 설명하자면 다음과 같다.

 

li 태그 8개를 보여준다고 했을 때, 4개를 정적인 요소로 보여주고, 나머지 4개를 동적인 요소로 계속 불러오는 것이다.

그렇게 되면, 처음 딜레이 시간이 줄어들게 되고, 정적인 요소를 보고 있다보면 나중에 동적인 요소 4개가 차례로 보이게 되는 것이다.

 

API 서버에서 데이터를 받아와서 4개의 태그를 정적인 컨텐츠로 만들고, 나머지를 클라이언트에서 렌더링하게 만드는 것이다.

 

Next.js 또는 Nuxt.js로 제작한 웹을 SSR 모드로 돌리려면 정적 파일들로 빌드해서 올리는 것이 아니라 Node.js가 깔린 서버에서 프로젝트를 어플리케이션으로 실행해서 프론트엔드를 배포하는 것이다. 이런 방식으로 서버에서 페이지의 요소들 중에 페이지 접속 시 바로 나타나야 할 것들을 정해서 그것들은 서버에서 미리 렌더링해서 보내도록 짤 수 있는 것이다. 그 이후 다른 요소들은 기존의 Vue 방식대로 ajax 등을 사용해서 동적으로 동작하는 것이다. 

 

CSR의 단점은 Search Engine Optimization(SEO, 검색 엔진 최적화)이다. SEO는 검색엔진으로 찾아지기에 적합하도록 만드는 것을 말한다. 검색 엔진들은 크롤링으로 웹사이트들을 돌아다니면서 이들의 구조와 컨텐츠를 파악하고 목차와 색인을 만들어두고 이에 기반해서 사용자가 검색을 할 때 적절한 결과물을 보여준다.  

 

이 경우 HTML에 들어있는 요소가 별로 없는 CSR의 경우 검색 엔진 최적화에 불리한 모습을 보인다. 내부에 어떤 목차가 있는지, 내용이 있는지를 알 수 없기 때문에, '빈 페이지'로 인식한다. 그렇기 때문에 내 웹사이트의 컨텐츠와 서브페이지들이 잘 검색되어서 사용자들의 눈에 많이 띄게 하려면 사이트를 어느정도 SSR로 제공하거나 메타태그들을 활용하는 등 검색엔진 최적화를 고민해야 한다. 이런 경우 하이브리드 프레임워크를 쓰면 문제를 어느 정도 해결 할 수 있다.

 

++ 구글 SEO의 경우에는 자바스크립트 엔진도 있기 때문에 자체적으로 렌더링을 해서 그 내용을 알아내기도 한다. 

 

 

Static Site Generator(SSG) : 정적 사이트 생성기

 

React로 CSR이나 SSR 두 방식이 아닌 SSG 방식을 만들 수도 있다. 서버, 클라이언트 어느 단에서도 렌더링을 하지 않는 방식이다.

React 방식으로 코딩을 하고, 이것을 결과물로 내놓을 때는 렌더링을 다 마친 정적파일들을 generate 해서 이것들로 배포를 하는 것이다. 

json이나 yaml 등의 정적 파일 등에 정보를 저장하고 이것을 읽어와서 React 방식으로 렌더링하는 코드를 짠 다음 빌드 명령어를 실행하면 모든 강의마다의 페이지들을 각각 컨텐츠가 들어있는 HTML 파일들로 생성하게 된다. 즉, 사이트에서 접속하는 모든 페이지마다 정적 HTML이 이미 빌드한 시점에서 생성되어 서버에 올라가 있는 것이다. 이것을 정적사이트처럼 배포하는 것이다.

 

Hugo, Gatsby, Jekyll에서만 했던 것을 이제 Next.js, Nuxt.js에서도 제공을 한다. 

 

SSG 방식이 적합한 사이트는 페이지는 많으나 그 내용들이 변할 일은 크게 없고 다른 동적 요소들은 적은 블로그에 많이 쓰인다. 

 

 

JAM Stack(JavaScript API Markup Stack)

 

웹 서비스를 만드는 하나의 설계 방식. 정적 사이트 생성기들을 사용한 서비스 설계를 의미한다.

자바스크립트를 활용한 다양한 라이브러리와 툴들로 정적인 프론트엔드 마크업 페이지들을 미리 생성하고 pre-rendering을 해주고 로그인, 댓글 같은 기능은 외부 API 서비스로 아웃소싱해서 설계를 분리한다. 빌드와 배포를 자동화하는 것과 더불어서 정적 페이지들을 CDN으로 배포함으로써 비용도 절감하고 사용자 경험까지 개선할 수 있는 것이다.