CSR SSR SSG 당신의 선택은 무엇인가요?

velog를 탐방하다가 정말 정말 좋은 게시글이 발견했다.

대부분이 모르는 Next에서 SSG가 작동하는 방식 | 리팩토링을 통해 서비스 최적화하기 2편

해당 내용을 읽고 재 정리한 것이니(내용은 동일해요 !!!!)
한번쯤 꼭 읽어보길 추천합니다.

---

CSR (클라이언트사이드 렌더링)

CSR 이전의 웹 사이트

CSR 이전의 사이트들은 페이지마다 HTML로 그려진 파일이 있었다. 그 페이지를 이동할 때 마다 서버에서 HTML를 요청했고

화면에서는 서버에서 받아온 HTML을 그렸었다.

1. 사이트 접속
2. 서버에 HTML 요청
3. HTML을 화면에 그림
4. 사이트에서 다른 페이지로 이동
5. 그 페이지에 맞는 HTML 을 서버에 또 요청
6. HTML 을 화면에 그림
.. 무한반복

즉, 사용자가 한 사이트에서 접속하는 페이지 마다, 매번 그에 맞는 HTML을 서버에 요청을 해야하고

받아온 HTML을 새로 화면에 그려주었다.

 

이 방식의 단점은 매번 HTML을 서버에 요청하고 화면에 새로 그릴 때 마다

실제 사용자는 빈 화면만 보고 기다려야 한다는 점이다.

이방식을 개선하기 위해 Ajax도 나오고..뭐 발전을 했지만, 완벽히 이 문제를 해결하지는 못했다.

수많은 발전 끝에, 이 문제를 완벽하게 해결한 방법이 떠올랐으니.. 바로 CSR 이다.

 

CSR 등장

이름에서 알 수 있듯이, Client에서 화면이 그려진다.

CSR의 과정은 아래와 같다.

1. 빈 HTML를 받아옴
2. JS 파일을 받아옴
3. JS가 화면을 그림
4. 짠!

 

사용자가 새로운 페이지를 요청할 때 마다 HTML을 새로 받아오지 않고 JS가 그 화면을 새로 그리기 때문에,

페이지 이동시 흰 화면이 번쩍이는 경험을 겪지 않아도 된다. (만세!)

 

이렇게 빈 HTML으로 시작해서 JS로 화면을 그리는 것이 정말 획기적일 수도 있겠지만,

한편으로는 치명적인 단점을 가져온다.

 

CSR의 치명적인 단점

모두 들어보았듯이 SEO 측면에서는 좋지않다.

보통 검색엔진은 자바스크립트가 실행되지 않는 환경에서 돌아가는데, 우리의 CSR은 자바스크립트가 화면을 그리기 전까진 빈 HTML에서부터 시작하기 때문에, 검색엔진 입장에선 빈 HTML파일로 보인다.

1. 검색엔진 등장!
2. 검색엔진: 저 좀 크롤러좀 하려고 하는데, 사이트 화면좀 보여주실 수 있나요?
3. CSR 사이트: 네 그럼요 빈 HTML 드려요~
4. 검색엔진: ????

CSR 사이트의 화면은 JS가 그리기 때문에 검색엔진 입장에선 ??? 가 되는 것이다.

 

또 하나의 단점은 JS가 로딩되기 전 까지는 빈 화면만 계속 보고 있어야 한다.

당연하다. JS가 화면을 그리기 전 까지는 가지고 있는 건 빈 HTML 뿐이니, 사용자는 빈 화면을 볼 수 밖에 없다.

 

그럼 뭐 어쩌나. 이러한 단점을 가지고 있더라도 CSR을 안고가야 하나요?

물론 이 단점을 개선한 또 새로운 방식이 등장한다.

---

SSR (서버사이드 렌더링)

말 그대로 Server에서 화면이 그려진다.

앞서 설명한 CSR의 단점은 동작방식의 1번단계인 빈 html을 받아오는 것이 원인이라고 볼 수 있다.

SSR은 이 단점을 개선한다 !

 

SSR의 작동방식

SSR 의 작동방식을 보자.

0. 사용자 등장! 사이트 접속할게요 ~
프론트 서버
1. 요청에 맞는 HTML을 서버에서 생성
2. 생성된 HTML을 클라이언트에게 전달

클라이언트
3. 생성된 HTML을 받아옴.
4. JS 파일을 받아옴
5. JS을 로딩하고 화면을 그림
6. 짜잔.

앞서 과정에서 보았듯이, SSR은 미리 HTML을 서버에서 만들어 클라이언트에게 제공한다.

3-6 단계는 매우 익숙하다고 볼 수 있는데, 맞다. CSR에서 설명한 동작방식과 동일하다.

• CSR: 클라이언트에서 빈 HTML에서 시작
• SSR: 클라이언트에서 데이터가 있는 HTML에서 시작

 

이미 클라이언트는 데이터가 있는 HTML을 가지고 있기 때문에,

이미 HTML에 데이터가 있기 때문에 검색엔진에 노출이 될 수 있고,

유저가 빈 화면을 보면서 기다리지 않아도 된다.

 

여기서 SSR을 제공하는 Next.js 를 쓰는 이유는 충분하다고 생각 할 수 있다.

 

와~ 그럼 SSR 방식만 사용하면 되겠네요 ~

ㅎㅎ. SSR이 CSR의 단점을 모두 개선해서인지 모든 면에서 좋아보일 것이라 느낄 수 있다.

하지만.. 이 SSR에도 치명적인 단점이 존재한다.

 

SSR의 치명적인 단점

만약 프론트서버에서 처리하는 HTML생성과정이 오래걸린다면 ?

HTML 을 미리 서버에서 만들어야 하는데, 미리 만들어야 할 HTML의 데이터가 너무 많다면 ?

껄껄.

 

만약, 서버에서 HTML을 생성하기 위한 데이터가 아주아주 많다고 가정해보자.

서버
1. 요청에 맞는 html을 서버에서 생성  (데이터가 너무 많아 10초 이상이 걸림)
2. 생성된 html을 10초 뒤에 클라이언트에게 전달

클라이언트
3. 만들어진 html을 10초뒤에 받아옴
4. 10초뒤에 JS파일을 받아옴.
5. 10초뒤에 JS을 통해 화면을 그림
6. 10초뒤에 짜잔.

사용자는 최소 10초동안 멈춘 화면을 바라보고 있어야 한다.

 

어 근데 CSR도 10초 기다려야 하는건 마찬가지 아닌가요?

맞다. 화면을 그리는데 10초가 걸리는 방대한 데이터가 필요하다면, CSR도 10초라는 시간이 어딘가에 소요될 것이다.

하지만 10초가 소요되는 타이밍이 다르다.

 

10초를 기다린다는 것은 CSR, SSR 모두 동일하지만 유저에겐 다른 경험을 가져다 준다.

 

CSR
1. 빈 HTML을 가져옴 (바로)
2. JS파일을 받아옴( 바로)
3. 화면을 그림 (10초동안 데이터를 가져옴)
4. 짜잔

 

크롬을 켜서 데이터 로딩이 10초가 걸리는 이상한 주소를 입력했다고 가정해보자.

CSR
페이지 이동은 바로 되었지만,(빈 HTML)
빈 화면만 보이고
10초가 지나니 화면이 다 그려짐

SSR
주소를 입력했지만,
페이지 이동이 안되서 브라우저 초기화면에서 멈춤 (서버에서 HTML을 그리는 중)
10초 동안 멈춘 상태에서 갑자기 다 그려진 화면이 나타남

 

사용자에게 사이트에 진입했다는 것을 보여준 CSR 과,

사이트에 진입되지도 않고 먹통 경험..ㅎ을 준 SSR 의 차이는 정말 크다.

 

SSR의 또 다른 단점은 프론트 서버부하가 있다는 것이다.

 

그래서 CSR SSR 둘중 뭘 사용하라고요 ㅎ.. 에이 그냥 죽자!

역시나 그랬듯이, SSR의 단점을 개선한 방식이 또 하나 있다.

어쨋든 문제점은 서버에서 HTML을 만드는데 이게 너무 오래걸려서 생기는 문제아닌가?

그럼 만약에, 서버에서 이미 먼저 HTML파일들을 미리 만들어 놓는다면 해결되는거 아닌가?

 

이게 바로 SSG이다

---

SSG (서버사이드 제너레이션)

빌드타임에 정적 HTML을 만들어 두는 것

Static Site Generation 이라 하는데, 나는 그냥 정적 사이트를 미리 굽는다 라고 이해했다. 

구워지는 정적 HTML..(농담임 ㅎ)

 

SSG는 앞서 설명한 CSR과 SSR의 단점을 말끔히 해결한다 !

SSG는 배포할 때 받아오는데 오래걸리는 데이터를 미리 다 다운받아와서 HTML을 미리 생성하고

추후 사용자가 그 페이지를 접속하면 미리 만들어진 HTML을 보여주는 것이다.

 

서버에서부터 미리 HTML을 만드니 빈화면을 보며 기다릴 시간도 필요 없고

데이터를 넣은 HTML을 미리 만드니, HTML을 만드는데 오래걸리지 않는 것이다 !

 

물론, 빌드타임때 미리 데이터를 불러와 HTML을 만드는 것이니, 실시간으로 가변하는 페이지에는 적합하지 않다.

새로 갱신된 데이터를 화면에 뿌려주기 위해선 재빌드 과정을 거쳐야 한다.

---

그래서 뭐가 좋은데

거의 과제제출 하는 것처럼 최종의 최종, 최종의 최종판 수준으로, 렌더링 방식은 새롭게 개선되고 제공되고 있다.

SSG 방식을 개선한 ISR방식 도 있다. (재빌드 할 필요 없이, 특정 주기에 맞춰 데이터를 업데이트해주는 방식)

SSG를 선택하기엔 이 단점이 맘에 걸리고, 그렇다고 CSR을 쓰기엔 이단점이 걸리고..

확연하게 무엇이 특별하게 좋다 라고 말하기 애매하다.

 

정적인 데이터로 이루어진 사이트거나 검색엔진이 중요하다면 SSG SSR

실시간으로 가변하는 데이터에 맞춘 UI/UX 가 중요하다면 CSR

다양한 이유로 특정 렌더링방식을 선택할 수 있다.