들어가기에 앞서
본 글은 유튜브 크리에이터 '드림코딩 by 엘리'님의 21.02.10일자 영상
을 보고 정리한 글임을 밝힌다. 본 글에서는 영상에 나온 개념을 이미지 없이 정리한 글이다. 이미지와 함께 더 나은 이해를 바란다면 해당 영상을 보면 좋을 것 같다.
목차
- 웹의 역사 (SPA 시대까지)
- CSR (Client Side Rendering)
- SSR (Server Side Rendering)
- TTV(Time To View) / TTI (Time To Interact)
- SSG (Static Site Generation)
웹의 역사
-
1990년 중반 : static sites
서버에 미리 html 파일들을 만들어두고, 경로에 따라 적절한 html 파일을 렌더링 해주는 방식. 서버와 클라이언트가 html 파일을 주고 받는 것이므로 매번 페이지 전체가 업데이트(즉, 새로고침) 되어 사용성이 좋지 못하다는 단점이 있다. -
1996년 :
<iframe>
문서 내에서 다른 문서를 도입 할 수 있는<iframe>태그의 도입으로 페이지 전체가 아닌, 부분적으로 업데이트 할 수 있게 되었다. -
1998년 : XMLHttpRequest API
fetch의 원조 격이라 할 수 있는 XMLHttpRequest API가 개발되었다. 이로 인해 서버에서 html 파일 전체가 아니라,json포맷으로 필요한 데이터만 받아올 수 있게 되었다. 자바스크립트를 활용해 이렇게 받아온 데이터를 동적으로 html 요소를 만들어 페이지에 업데이트 한다. 새로고침으로 사용성이 저하되었던 문제가 해결되기 시작한 것이다. -
2005년 : AJAX(Asynchronous JavaScript and XML)
XMLHttpRequest의 방식이 공식적으로AJAX라는 이름을 갖게 되며 구글에선 이를 이용하여 gmail, google maps와 같은 웹 어플리케이션을 만든다. 이것이 현재 널리 쓰이고 있는 SPA (Single Page Application)이다. SPA는 static sites와는 달리 서버에서 html 파일을 받아오지 않고 사용자가 하나의 페이지에 머무르면서 필요한 데이터만 받아와 부분적으로 업데이트한다.
CSR (Client Side Rendering)
SPA 트렌드와 cpu 성능의 향상, js의 표준화 및 강력해진 커뮤니티를 바탕으로 Angular, React, Vue와 같은 프레임 워크가 등장하게 되고 클라이언트 사이드 렌더링 시대로 접어들게 된다.
CSR이란, 쉽게 말해 '서버에서 다 해먹는 것'이라고 한다. 페이지를 부분적으로 업데이트하는 모든 과정이 클라이언트 사이드에서 이루어지는 것이라고 생각하면 될 것 같다. 제일 처음에 서버에서 클라이언트로 보내주는 html 파일에는 다음과 같은 기본적인 구조만이 담겨있다.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="description"
content="Amazing web site" />
<title>App</title>
</head>
<body>
<div id="root"></div>
<script src="app.js"></script>
</body>
</html>따라서 처음에는 빈 화면만 보이다가 링크된 app.js를 서버로 받게 되는데 이때, app.js에 어플리케이션에서 필요한 로직뿐만 아니라 어플리케이션을 구동하는 프레임워크 및 라이브러리의 소스 코드들도 모두 포함되어 있다.
그러다보니 파일 크기가 매우 커져 다운로드 받는 데에 시간이 소요된다는 특성이 있다. 만약 추가로 데이터가 필요하다면 서버로부터 '데이터만 받아온 후에' 소스 코드가 모두 로드되어있는 클라이언트 측에서 동적으로 html 요소를 만들어 최종적으로 사용자가 어플리케이션을 보게 된다.
단점
이런 CSR 방식의 단점으로는 크게 두 가지를 꼽을 수 있다.
-
첫 로딩이 오래 걸린다.
: 위에서 언급했듯이 자바스크립트 파일 하나에 각종 로직과 프레임워크 / 라이브러리 소스 코드를 모두 받아온 후에 데이터로 html 요소를 가공해서 사용자가 보게되다보니 처음 화면을 보기 전까지 시간이 소요된다는 단점이 있다. 보통의 경우는 이 시간이 매우 길진 않겠지만, 짧은 시간이라도 사용자의 경험에는 치명적일 수 있어 중요하게 생각해 볼 요소인 것 같다. -
SEO가 썩 좋지 못하다.
: SEO는 Search Engine Optimization의 줄임말로, 검색 엔진에 효과적으로 노출되도록 만드는 작업이라고 할 수 있다. 영상을 보기 전까지는 SEO라는 것의 의미만 알고 있어서 단순하게 '검색에 용이하게 키워드 설정 및 태그 활용만 적절하게 하면 되지 않을까?'라고 생각했는데, 실제 페이지가 로드되는 과정과 깊게 연관되어 있다는 것을 새로 알게 되었다. 우리가 구글이나 네이버에서 검색을 하게 되면 서버에 등록된 웹사이트들의 html 요소들을 살펴보며 검색어와의 매칭을 확인한다고 한다. 그런데 CSR에서는 처음에 받아오는html파일에 거의 정보가 담겨있지 않으므로 당연히 SEO에 불리할 수 밖에 없다.
SSR (Server Side Rendering)
위에서 다룬 CSR의 문제점을 보완하기 위해 1990년 중반에 활용했던 static sites의 영감을 받은 SSR 즉, 서버 사이드 렌더링 이 도입된다. 클라이언트에서 모든 것을 처리하는 방식과 다르게 서버에서 데이터를 가지고 html 파일을 만들고, 이를 동적으로 제어할 수 있는 일부 소스코드와 함께 클라이언트 측으로 보내준다. 그럼 클라이언트 측에서는 잘 만들어진 html 파일을 받아와 바로 사용자에게 보여줄 수 있게 된다.
장점
CSR의 단점을 보완했기 때문에 다음과 같은 장점을 지닌다.
- 첫번째 페이지 로딩이 빠르다
- 모든 컨텐츠가 html에 담겨 있으므로 SEO에 좀 더 효율적이다.
하지만, CSR의 단점을 보완했다고 해서 SSR이 완벽한 것은 아니다.
단점
- 블링킹 이슈(blinking issue)
: 결국 SSR의 과정을 살펴보면 static sites와 마찬가지로 사용자의 클릭에 해당하는 html 파일을 다시 서버에서 받아오기 때문에 새로고침이 되어 사용자 경험이 좋지 않을 수 있다. - 서버에 과부화가 걸리기 쉽다.
: 렌더링의 많은 과정이 서버 사이드에서 일어나기 때문에 특히 사용자가 많은 제품일수록 서버의 부담이 커진다. - 서비스의 동적 활용에 딜레이가 있다. (Need to wait before interacting)
: 영상을 제작하신 엘리님의 말씀에 따르면 가장 치명적인 단점이라고 한다. 위에서 html 파일과 이를 동적으로 제어할 수 있는 일부 자바스크립트 소스 코드를 함께 클라이언트 측으로 보내준다고 했다. 여기서 중요한 점은 '일부'라는 것이다. 페이지를 사용하는데 필요한 여러 코드가 모두 보내진 것은 아니기 때문에, 어떤 기능을 사용하기 위해서는 서버에서 해당 동작을 위한 자바스크립트 파일을 요청해 다운로드 하는 시간이 필요한 것이다. 그래서 클릭을 하더라도 반응이 없는 경우가 생길 수 있다.
TTV와 TTI
SSR 방식의 세번째 단점을 좀 더 잘 이해하기 위해선 Time To View(사용자가 웹 사이트를 볼 수 있는 시점) 와 Time To Interact(사용자가 웹 사이트와 상호작용을 할 수 있는 시점) 라는 개념을 알고 있어야 한다.
먼저, CSR과 SSR을 시간 순서로 분석해보면 다음과 같다.
CSR
- 사이트 접속
- 서버에서 인덱스 파일을 받아 온다. (이 때는 컨텐츠가 없는 상태라 빈 화면으로 보인다.)
- html 파일에 링크 되어 있는 웹사이트에 필요한 모든 로직이 담겨 있는 자바스크립트 파일을 요청한다.
- 동적으로 html 요소를 생성할 수 있는 웹 어플리케이션 로직(
angular,react,vue와 같은 것들)이 담긴 자바스크립트 파일을 가져온다. => TTV, TTI
이 과정 속에서 TTV와 TTI는 동시에 4번이다. 왜냐하면 html 요소가 생성되어 사용자가 볼 수 있는 컨텐츠가 생기며(TTV), 웹 사이트에 필요한 로직 역시 미리 로드 되어 있었기 때문에(3번) 렌더링 된 페이지에서 동적으로 활용이 가능해지기 때문이다(TTI).
따라서 CSR을 제작한다면, 필요한 자바스크립트 코드를 번들링해서 한 번에 보내주는 4번 단계에서 어떻게 하면 자바스크립트 코드를 효율적으로 분할해서 첫번째 로딩에 필요한 필수적인 코드만을 보낼 수 있을지 고민할 필요가 있다.
(CSR에서 app.js를 다운 받는다고 해서 모든 자바스크립트 코드를 한 번에 받아오는 것이라고 생각했는데 분할을 언급하는 것으로 보아 '마지막에 자바스크립트 코드를 받아온다'라고 이해하는게 더 정확한 것 같다.)
SSR
- 사이트 접속
- 서버에서 이미 잘 만들어진 인덱스 파일을 받아온다. => TTV
- 자바스크립트 파일을 서버에서 받아온다.
CSR과 다르게 SSR에서는 TTV의 시점이 2번 단계이다. 서버에서 이미 사용자가 볼 수 있는 html 파일을 만들어 보내주었기 때문이다. 하지만 이 단계가 TTI인 것은 아니다. 아직 인터랙션을 수행할 자바스크립트 코드가 없기 때문이다. 인터랙션은 자바스크립트 파일을 서버에서 받아온 이후부터 가능하다(3번 이후).
즉, SSR은 TTV와 TTI 사이의 공백 기간이 꽤 긴 편이다.
따라서 SSR의 경우에는 VVT와 VVI 사이의 공백을 줄이는 것이 핵심이다. 또한 블링크 이슈와 관련하여 매끄러운 UI와 UX를 제공할 수 있을지 고민하는 것도 중요하다.
SSG (Static Site Generation)
요즘은 CSR이나 SSR만을 선택하지 않고 SSG라는 것을 활용하기도 한다. SSG의 특성은 무엇일까? 예를 들어, 리액트는 CSR에 특화된 라이브러리이지만 Gatsby라는 라이브러리와 함께 사용한다면 리액트 웹어플리케이션의 웹페이지를 정적으로 미리 생성해서 서버에 배포해 놓을 수가 있다. 잘 이해한게 맞나 싶지만, TTV까지 시간이 걸린다는 CSR의 문제점을 보완할 수 있다.
이렇게 만들어진 웹사이트들이 모두 정적인 것은 아니다. 서버에서 추가적으로 데이터를 받아오거나, 동적으로 처리해야 되는 로직이 있다면 JS 파일을 함께 가지고 있을 수 있기 때문에 동적인 요소도 충분히 추가 및 활용할 수 있다고 한다. (=> 이 부분은 잘 이해가 되지 않아 나중에 따로 조사가 필요할 것 같다. 지금 드는 생각으로는 정적으로 html 파일과 이 페이지에 활용되는 JS 파일을 함께 만들어두어 관리하기 때문에 인터랙션이 가능하다고 말하는 것 같다)
개츠비 외에도 리액트와 함께Next.js도 많이 사용한다고 한다. Next.js는 강력한 SSR을 지원하는 라이브러리였지만 SSG도 지원하고 CSR를 적절히 섞어 목적에 맞게 활용하도록 지원한다고 한다.
마무리하며
리액트를 공부하며 자주 접하던 용어들을 이번 기회로 정리할 수 있었다. 물론 각 개념을 깊게 이해한 것은 아니지만, 지금 단계에선 이 정도로 알아두는 것도 큰 도움이 될 것이라 생각한다.
SPA의 역사와 CSR과 SSR의 차이점을 정리하며 trade-off를 다시 한 번 생각하게 되었다. 사회와 기술은 발전할 때 마다 그 부작용이 있기 마련이지만 전체적으로 보면 이전 보다 나아지는 방향을 향하고 있다고 생각했다. 자료구조를 공부하며 어떠한 선택은 절대적으로 나은 것이 아니라 선택의 문제라는 trade-off 개념을 자주 접하며 '시간 상으로 나중에 등장한 것이 무조건 더 좋은 것은 아니다'라는 생각을 자주 했는데 이번 CSR과 SSR의 차이가 딱 그런 것 같다는 생각을 했다. 특히 나는 SSR이라는 용어가 더 익숙해 '현재 프론트엔드의 가장 발전된 방식이 SSR인가 보다.'라는 오해를 하고 있었는데 잘못 생각하고 있다는 것을 아는 기회가 되었다.
항상 '구현해 내는 것'에 만족하지 않고 '특성에 맞게 잘 구현'하고자 하는데 '사이트를 이용하기 위해 필요한 데이터들을 어떤 방식으로 가공하는가'라는 중요한 특성 하나를 알게 되어 만족스럽다.
