부트캠프 과정을 들을 떄에도 배웠지만 당시에는 너무나 많은 지식들이 한 번에 들어왔고 또 과제를 제출하기 급급해서 두 렌더링에 대한 차이와 개념을 명확히 이해하기 힘들었다. 때문에 시간이 지난 지금이라도 이를 다시 정리해보고자 한다.
정리를 해보기 전, 드림코딩 유튜브 영상을 먼저 시청하면 좋다. 전체적인 역사의 흐름에 대해서 세세하게 설명을 해주어 이해하는데 더 도움이 되었다.
내가 이전에 사용하였던 iframe tag 와 XMLHttpRequest API 와 fetch API 의 역사 흐름에 대해서도 한 번 더 되짚어볼 수 있었다. 👍
History
1990s: Static Sites, 서버에 이미 잘 만들어진 HTML 문서들이 있고 사용자가 브라우저에서 헬로 닷컴과 같은 주소에 접속하면 서버에 이미 배포 되어져 있는 HTML 문서를 받아와서 보여주는 형식.
한 가지 문제점은, 페이지 내에서 다른 링크를 클릭하면 다시 서버에서 해당 페이지의 HTML을 받아 와서 페이지 전체가 업데이트 되어야 함.
-> 사용자 측면에서 굉장히 사용성이 떨어지는 느낌 (깜빡깜빡 현상 MPA)
1996 iframe: 문서 내에서 또 다른 문서를 담을 수 있는 iframe 태그가 도입이 되었고 이제는 페이지 내에서 부분적으로 문서를 받아와서 업데이트 할 수가 있게 됨. 지금도 간혹 쓰이고 있는 태그!
1998~ XMLHttpRequest API: 우리가 많이 쓰고 있는 fetch API 의 원조
HTML 문서 전체가 아니라 JSON과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아 올 수 있게 됨.
그 데이터를 자바스크립트를 이용해서 동적으로 HTML 요소를 생성해서 페이지에 업데이트 하는 방식.
2005 AJAX: 이런 방식이 드디어 공식적인 AJAX라는 이름을 가지게 되고 구글에서도 AJAX를 이용해서 Gmail, Goolge map과 같은 우리가 많이 쓰고 있는 웹 어플리케이션을 만들기 시작.
SPA (Single-Page-Application)
-> 이것이 현재 널리 쓰이고 있는 "SPA (Single Page Application)".
사용자가 한 페이지 내에서 머무르면서 필요한 데이터를 서버에서 받아와서 부분적으로만 업데이트 하게 된다. 이런 방식으로 하나의 어플리케이션을 사용하듯 웹사이트에서도 사용성이 조금씩 좋아지게 된다.
(구글 맵처럼 지도를 확대해서 pick 되어진 곳을 클릭하면 부드럽게 관련 정보와 위치가 뜨는 것처럼)
이런 SPA 트렌드, 그리고 사용자들의 PC 성능이 점차 좋아져서 많은 것들을 무리 없이 처리할 수 있게 되었고 자바스크립트도 표준화가 잘 되어지게 되면서 강력한 커뮤니티를 바탕으로 Angular, React, Vue와 같은 프레임워크가 나와서 CSR (클라이언트 사이드 렌더링) 시대로 접어든다.
미리 알아두기 -> TTV (Time To View) / TTI (Time To Interact)
CSR (Client-Side-Rendering)
쉽게 얘기하면 클라이언트 측에서 다 해 먹는? 걸 말한다.
-> 사용자의 요청에 따라 필요한 부분만 응답 받아 렌더링 하는 방식
시간이 흘러가는 순서대로 분석해보면,
- 사이트에 접속하게 되면 서버에게서 인덱스라는 HTML 파일을 받아온다. (인덱스 파일은 텅텅 비어져있기 때문에 사용자에게 아무것도 보여주지 않음)
- 이 HTML 파일에 링크 되어져 있는 해당 웹 사이트에서 필요한 "모든 로직이 담겨 있는 자바스크립트를 요청"
(여기 자바스크립트 파일에는 어플리케이션에서 필요한 로직들 뿐만 아니라 어플리케이션을 구동하는 프레임워크와 라이브러리의 소스 코드들도 다 포함이 되어져있다. 때문에 굉장히 사이즈가 커서 다운로드 받는 데도 시간이 소요될 수 있다.)
+) 추가로 필요한 데이터가 있다면 서버에 요청에서 데이터를 받아온 다음에 (JSON Data) 이것들을 기반으로 해서 동적으로 HTML을 생성하여 사용자에게 최종적이 어플리케이션을 보여주게 됨 -> 아래 단계 - 그리고 최종적으로 동적으로 HTML을 생성할 수 있는 웹 어플리케이션 로직이 담긴 자바스크립트 파일을 받아오게 됨.
- 그리고 이 순간부터 웹 사이트가 사용자에게 보여지게 되고 또 사용자가 클릭이 가능해짐.
👉 즉, CSR은 사용자가 웹사이트를 볼 수 있음(TTV)과 "동시에" 클릭을 하거나 인터랙션(TTI)이 가능하게 됨.
큰 문제점
- 사용자가 첫 화면을 보기까지 시간이 오래 걸릴 수 있다는 점
(HTML이 텅텅 비어져있기 때문에 처음에 접속하면 빈 화면만 보이게 됨.)
- 사용자가 첫 화면을 보기까지 시간이 오래 걸릴 수 있다는 점
- 썩 좋지 않은 SEO를 꼽을 수 있다.
(SEO란 서치 엔진 옵티마이제이션의 약자로 구글, 네이버와 같은 검색엔진들은 서버에 등록된 웹사이트를 하나하나씩 돌아다니면서 웹사이트의 HTML 문서를 분석하고 판단해서 우리가 검색할 때 웹사이트를 빠르게 검색할 수 있게 도와줌.)
- 썩 좋지 않은 SEO를 꼽을 수 있다.
하지만, CSR에서 사용되어지고 있는 HTML Body는 아래와 같이
<body>
<div id="root"></div>
<script src="app.js"></script>
</body>대부분 텅텅 비어져 있기 때문에 검색엔진들이 CSR로 작성된 웹페이지를 분석하는데 많은 어려움을 겪고 있음. 구글에서는 조금 개선이 되었으나 여전히 SEO가 좋지 않음!!
(React 에서 html 파일을 보면 알 수 있듯이 위와 같은 형식 id root를 기반으로 페이지가 만들어짐을 알 수 있음 -> id가 root인 노드만 있는 이유)
💡 TIP
때문에 CSR을 정말 많이 사용하는 사람들이라면,
우리가 최종적으로 번들링해서 사용자에게 보내주는 자바스크립트 파일을 어떻게 하면 효율적으로 많이 분할해서 첫 번째로 사용자가 보기 위해서 필요한 정말 필수적인 아이들만 보낼 수 있을지 고민해보면 좋음
이러한 CSR의 과도한 문제점들 때문에 우리가 1990년 중반쯤에 사용했던 Static Sites에서 영감을 받은 SSR 이 도입되게 된다.
SSR (Server-Side-Rendering)
이제 클라이언트에서 모든 것을 처리하는 방식과는 다르게 웹 사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML 파일을 만들게되고 이렇게 잘 만들어진 HTML 파일을 동적으로 조금 제어할 수 있는 소스코드와 함께 클라이언트에 보내지게 된다. 그러면 클라이언트 측에서는 잘 만들어진 HTML 문서를 받아 와서 바로 사용자에게 보여줄 수 있게 되는 것을 뜻한다.
-> 서버로부터 완전하게 만들어진 html 파일을 받아와 페이지 전체를 렌더링 하는 방식
시간이 흘러가는 순서대로 분석해보면,
- 웹 사이트에 접속을 하게 되면 서버에서 이미 잘 만들어진 인덱스 파일을 받아 오게 되고
- 사용자가 웹사이트를 볼 수가 있음.
(하지만 아직 동적으로 제어할 수 있는 자바스크립트 파일은 아직 받아오지 않았으므로 사용자가 클릭을 해도 아무런 것도 처리할 수 없음.) - 그래서 최종적으로 자바스크립트 파일을 서버에서 받아와야지만 그때부터 사용자의 클릭을 처리할 수 있는 인터랙션이 가능해짐.
그래서 서버사이드 렌더링은 사용자가 사이트를 볼 수 있는 시간(TTV)과 실제로 인터렉션(TTI)을 할 수 있는 공백 기간이 꽤 긴편이라고 한다.
CSR을 사용했을 때보다 SSR을 사용함으로써의 장점
- 첫 번째 페이지로딩이 빨라짐
- 모든 컨텐츠가 HTML에 담겨져 있기 때문에 조금 더 효율적인 SEO를 할 수가 있음.
SSR이 가지고 있는 큰 문제점
-
- Static Sites에서 존재했던 "블리킹 이슈"가 여전히 존재한다.
(사용자가 클릭을 하게 되면 전체적인 웹사이트를 다시 서버에서 받아 오는 것과 동일하기 때문에 썩 좋지 않은 유저 경험을 겪음. -> 깜빡임 현상)
- Static Sites에서 존재했던 "블리킹 이슈"가 여전히 존재한다.
-
- 서버에 과부하가 걸리기 쉬움.
(특히 사용자가 많은 제품 일수록 사용자가 클릭을 할 때마다 서버에 요청을 해서 서버에서 필요한 데이터를 가지고와서 HTML을 만들어야 하므로 서버에 과부하가 걸리기가 쉬움.)
- 서버에 과부하가 걸리기 쉬움.
-
- 정말 치명적인 단점..
사용자가 빠르게 웹사이트를 확인할 수는 있지만, 동적으로 데이터를 처리하는 자바스크립트를 아직 다운로드 받지 못해서 여기저기 클릭했을 때 반응이 없는 경우가 발생할 수 있음.. 🤦♀️
- 정말 치명적인 단점..
👉 CSR과는 반대로
TTV(Time To View),TTI(Time To Interact)사이의 공백 기간 발생
💡 TIP
사용자가 보고, 인터렉션 하는 시간의 단차를 줄이기 위해서 어떤 노력을 할 수 있을지, 우리가 어떻게 조금 더 매끄러운 UI와 UX를 제공할 수 있을지 고민해보면 좋음.
또, 요즘에는 꼭 CSR 또는 SSR 만을 고집해서 사용하기보다는 SSG도 있음
SSG (Static Site Generation)
React + Gatsby
리액트는 CSR에 특화된 라이브러리이지만, Gatsby라는 라이브러리와 함께 사용하면 리액트로 만든 웹어플리케이션을 정적으로 웹 페이지를 생성을 미리 해두어서 서버에 배포해둘 수 있다고 한다.
그리고 이렇게 만들어진 웹 사이트들은 모두 다 정적이냐? -> Nope.
우리가 추가적으로 데이터를 동적으로 받아오거나 또는 동적으로 처리해야 되는 로직이 있다면 자바스크립트 파일을 함께 가지고 있을 수 있기 때문에 동적인 요소도 충분히 추가 할 수 있음.
Next.js
강력한 서버 사이드 렌더링을 지원하는 라이브러리였는데, 요즘에는 SSG도 지원을 하고 CSR과 SSR을 잘 섞어서 조금 더 강력하고 유연하게 목적에 맞게 사용할 수 있도록 지원해주고 있다.
면접을 준비하면서 TypeScript와 Next.js를 사용하는 곳을 굉장히 많이 봤었는데 이에 대한 이유임을 알게 되었당..!
또 Low SEO(CSR에서 SEO가 좋지 않은 이유)에 대해서도 한 번 더 정리를 해볼 수 있는 시간이었다.
결론
어떤 것이 최고다! 라고 꼽기 보다는 개발하고자 하는 사이트가 정적인지, 동적인지 서버에서 동적으로 데이터를 받아오는지, 얼마나 자주, 얼마나 많은 사용자가 있는지에 따라서 TTV와 TTI를 고려해서 조금 더 유연하게 섞어가면서 개발해 나가는 것이 좋을 거 같다 👀
내용 출처) 드림코딩 👍
잘못된 내용이 있을 경우 답글 달아주시면 감사합니다! 🙇♀️
