[정직하게 배워보는 Next.js] (번외) 웹의 발전 과정으로 보는 CSR 그리고 SSG와 SSR

해당 블로그 시리즈는 정직하게 배워보는 Next js 시리즈로써 총 8부작으로 이루어져 있습니다.
Next.js공식 홈페이지에서 이야기하는 내용을 최대한 이해하기 쉽고 직관적이게 구성하였습니다.

0. 목차

1. create-next-app으로 next 개발 환경 세팅하기

2. create-next-app에서 만난 첫 번째 핵심 pages. 그리고 동적 라우팅

3. 페이지를 연결하기 위한 Link-Component 그리고 Pre-Fetch

Dynamic Routing과 Link를 이용해 간단한 게시판을 만들어보자.

4. Next.js에서 head 태그를 조작하는 멋진 방법

번외 & 실습) 이미지와 동영상을 저장하고 사용해보자.

5. 웹의 발전 과정으로 보는 SSG와 SSR

6. next의 두 번째 핵심 Pre-Rendering

7. SSG로 검색 엔진 최적화 노리기

8. 정직하게 배워보는 Next.js 시리즈를 마치며..

---

우리는 다음 시간에 배울 SSR, Pre-Rendering과 같은 기술들을 배우기 위해서 SSG와 SSR에 대해서 차이를 명확히 인지해야 한다.

 

나에게 왜 Next JS를 배우려 했는지 물어본다면 아마도 Server Side Rendering이라고 한다.

 

Create-react-app은 Single Page Application 이라 검색 엔진 최적화가 힘드니 Next를 이용해서 SSR을 해보고 싶었다.

 

하지만 next는 모든 페이지를 SSG 한다고 한다.

엥? 난 SSR을 하러 왔는데 SSG를 한다고?
그나저나 SSG는 뭐지?

그래서 이번 기회에 CSR은 무엇이고 SSG와 SSR은 뭔지 알아보고 공유해보고자 번외로 해당 챕터를 만들었다.

 

설명을 하기 위해서 어떤 방법으로 할까 고민을 하였고 많은 레퍼런스를 찾아봤는데, 내가 겪어본 바로 웹의 진화 과정을 따라가면서 학습하는게 정말 도움이 많이 되었다.

 

시작해보자.

CSR vs SSR vs SSG

웹의 발전 과정

우선 웹이 어떤 과정을 거쳐서 발전했는지 간략하게 그림으로 확인해보자.

여기서 말하는 발전 과정은 팀 버너스 리부터 시작해서 튜링 머신 이런 발전 과정이 아니라 html을 서버에서 보내는 일련의 과정을 말한다.

이와 같은 과정을 거쳐서 발전해왔다.

최초의 렌더링 SSR

 

최초에는 static한 html 파일만 존재했다.

사용자와 상호작용을 할 수도 없을 뿐더러 웹이란 특정 분야에서만 사용하던 것이었기 때문에 대중적이게 꾸밀 필요도 없어 더 가벼웠으며 간단했다.

그래서 최초에는 매 요청마다 static 한 html 파일이 클라이언트에게 전달되었지만 점점 동적인 페이지를 원하게 되었다.

그래서 탄생한 Server Template Engine

사용자가 증가함에 따라 더 Dynamic한 Rendering 을 원했고 php나 JSP와 같은 Template Engine이 탄생하게 되어 html을 더 동적이게 만들었다.

그래도 여전히 서버에서 HTML을 렌더링한다는 것은 동일했다.

ajax의 탄생과 CSR

위에서 사용한 동적인 페이지는 문제가 하나 있었는데, 그것은 바로 전체 리로딩이었다.

 

만약 네이버 인기 검색 순위가 그 당시에 있었다고 가정해보자.

 

그럼 인기 검색어는 매번 업데이트 되어야 하는데, 그때의 기술력에서는 매번 데이터를 가져올 때 마다 페이지가 새로고침 되었다.

 

그래서 탄생한 것이 바로 ajax.

축구팀 아약스 로고. 웹의 ajax 아님

화면 깜빡임 없이 특정 부분만 변경할 수 있는 기술이 나오게 되었고, 비동기 컴포넌트들이 점점 등장하게 되었다.

 

그리고 이 때부터 js가 동적으로 페이지를 생성해내는 Client Side Rendering이 탄생하게 되었다.

다시 돌아온 SSR

CSR에 호황을 맞으며 탄생한 Facebook의 React, Google의 Angular, 개인의 Vue와 같은 SPA.

 

하지만 이런 CSR 프레임워크들에도 문제가 있었는데

1. seo
2. 성능

바로 성능과 seo 였다.

SEO
SEO는 웹 크롤러가 웹 사이트를 읽고 인덱싱하는 과정을 거치며 웹 페이지가 검색 엔진에 노출될 수 있게 하는데, SPA에서는 사용자의 클릭에 따라 동적으로 JS를 이용해 페이지를 생성하므로 검색 엔진 최적화가 힘들었다.

성능 문제
페이지를 렌더링하기 위해서는 브라우저가 Js를 실행하고 그를 감당할만한 cpu 기기가 필요했다.

하지만 CPU 성능이 좋지 않거나 대용량 js 파일을 받을 수 있는 네트워크 여건이 잘 갖춰지지 않은 곳에서는 SPA가 오히려 독이 되기 시작했다.

그래서 사람들은 다시 SSR을 찾기 시작했다.

사람들은 위의 방법을 해결하고자 다시 SSR을 찾기 시작했는데, 이제는 새로운 SSR을 찾기 시작하였다.

 

위에서 사용한 SSR과는 다르게 HTML을 생성하기 위해서 Template Engine이나 JSP 처럼 서버측 프로그래밍 언어를 사용하지 않고 최신의 JS 라이브러리와 프레임워크를 사용하게 되었으며 Next나 Gatsby와 같은 것들을 사용하기 시작했다.

 

이제는 서버에서 미리 dom을 렌더링하기 시작했고 html만을 return 해줄 서버를 만들어 사용하기도 했다.

발전된 SSR SSG

아래의 SSR의 동작 과정을 봐보자.

SSR 동작 과정

1. 사용자 요청
2. 서버가 페이지의 html 파일 생성
3. 서버가 html을 반환
4. 브라우저는 html을 렌더링

사람들은 이 SSR을 더 발전시키길 원했고 더욱 좋은 성능을 기대하게 되었다.

 

여기서 만약 서버가 매 요청마다 항상 같은 페이지를 리턴해준다면 비효율이지 않나? 이란 생각을 갖게 되었고 이를 해결할 방법으로 SSG가 탄생하게 되었다.

SSG

SSG는 페이지가 사용자와 상호작용해서 데이터가 변하지 않는 about과 같은 항상 같은 페이지를 미리 서버에서 생성해서 요청에 따라서 재사용하는 캐싱을 하기 시작했고 이런 방법을 Next에서는 기본적으로 사용한다.

그럼 언제 뭘 써야해?

그럼 언제 무엇을 사용하는게 좋을까?

SSR

• 표시된 데이터가 항상 최신의 데이터일 때
• 자주 변경할 수 있는 사용자별 혹은 동적 데이터 일 때,

SSG

• 정적인 정보를 항상 보여주는 페이지일 때
• 상호작용 데이터가 존재하지 않을 때.