[FE] 웹 렌더링의 과거와 현재, 그리고 미래 ⏱ / 2️⃣ - 현재 < SPA와 CSR, SSR에 대해>
들어가며
1️⃣ - 과거 <정적웹 에서 동적 웹으로>
[FE] 웹 렌더링의 과거와 현재, 그리고 미래 ⏱ / 1️⃣ - 웹 서비스의 역사 <정적웹 에서 동적 웹
들어가며 '역사를 잊은 민족에게 미래는 없다' 라는 말이 있죠. 과거를 아는 것은 현재를 살 때의 엄청난 메리트입니다! 웹이 어떻게 발전되어 왔는지, 그 맥락을 알고 있는 사람은 새로운 정보
programming119.tistory.com
1부에서는 과거 렌더링의 발전 과정에 대해서 알아봤죠.
2부에서는 현재 가장 많이 쓰이는 렌더링 방식인 CSR 과 SSR 그리고 SPA 에 대해서 다뤄보고자 합니다.
SPA (Single Page Application)?
기존까지의 웹은, 각각의 페이지가 존재하고, 다른 컨텐츠를 보기 위해서 클릭을 할 때마다 해당 페이지로 넘어가게 되는 구조였습니다. 즉, 사용자가 인터랙션을 할 때마다 새로운 html을 불러오는 과정이 필요했고, 페이지로 넘어가는 과정인 깜빡임은 불가피했죠. 오히려 너무나도 당연하게 생각해서 이 깜빡임이 불편하다고 느껴본 적도 없을 겁니다. 아무리 깜빡여도 마우스가 모래시계 모양으로 바뀌고 하얀 화면만 하염없이 바라보는 상황에 비하면 새발의 피였죠.
하지만 새로운 시대가 시작됩니다. (⚠️ 과장주의)
AJAX 가 도입되고, 사용자의 PC 사양이 좋아지고, 웹 서버들의 사양이 좋아지고, 브라우저가 발달되는 등 여러가지 흥겨운 박자가 맞아 떨어지면서 단일 페이지 웹이 등장하기 시작합니다.
분명 다음 페이지로 넘어갔는데 깜빡임이 없다고? 사용자들은 마치 플래시게임을 하는 듯한 웹의 동작을 경험할 수 있게 되죠. 저 또한 react를 처음 접하고 spa 웹을 처음 만들어봤을 때의 경험은 엄청 신기헀던 것으로 기억합니다.
https://www.awwwards.com/websites/single-page/
Best Single Page Websites | Web Design Inspiration
DEV SOTD
www.awwwards.com
(SPA 의 예시)
※ 아, 그리고 제 소개 사이트도 SPA로 구성돼있습니다! (자랑 아님 예시임. 암튼 아님.) https://i-am-seo-sang.vercel.app/
SPA의 구조와 구현방식
SPA 는 특별한 기술이 아닙니다. 그냥 페이지 첫 로드 시에 모든 동작을 고려한 JS, CSS, HTML을 내려줍니다. 이 때, HTML에 모든 페이지의 HTML이 포함된 것은 아니고, 앞서 말한 AJAX 를 이용해서 부분부분 필요한 데이터를 전송해서 가져오게 되는 것이죠. 이 부분을 클라이언트 요청에 의해서 데이터가 fetch 되고 페이지가 그려지기 때문에 CSR(Client Side Rendering)이라고 부릅니다. 여기서 client 는 웹 페이지 사용자의 기기(브라우저) 를 의미합니다.
그렇다면 페이지 이동, url 조절은 어떻게 컨트롤하냐? 이 부분은 사실 리액트의 라우터 기능이라던가 프레임워크 들에서 지원을 해주기 때문에 원론적인 방식은 모르시는 분이 더 많을 겁니다. (어쩌면 저만 몰랐던 걸지도,,) 저도 이 기회에 조금 찾아보았는데요, 페이지를 컨트롤 할 때는 History API 를 이용해서 브라우저 세션에 히스토리 스택을 조절해줍니다. 그리고 JS로 DOM 컨트롤을 해주면서 직접 화면을 변경시켜줍니다. SPA 프레임워크들에서 지원하는 페이지 라우팅기능 들은 이런 raw한 기능들을 포팅시켜서 사용하기 좋게 해둔 것이겠죠.
SPA가 언제나 정답일까?
SPA 가 당시 혁신적이었던 이유는 이 부분이라고 생각합니다. 페이지 사이의 느린 이동을 default로 깔고가던 웹 생태계에서,
페이지 이동이 느리던 이유는, html, css, js 를 서버에서 fetch 하고 렌더링하는 과정이 길었던 탓이죠.
하지만, 이제는 SPA만이 반드시 정답인 것은 아니다 라는 쪽으로 가고 있는 것 같습니다.
가장 큰 이유는 아래와 같습니다.
웹이 발전해 나아가면서 페이지 이동 시에 깜빡임이 점점 짧아져서, 체감상 불편하지가 않다!!
네트워크의 발전
- 요즘은 벌써 3세대 HTTP가 도입된 곳도 있다. HTTP/3 (https://velog.io/@sehyunny/everthing-you-need-to-know-about-http3)
- CDN, 캐싱, 디자인 패턴 등의 구조적인 발전
- 물리적인 네트워크 장비들도 발전했을 듯. (사실 하드웨어 쪽은 잘 모름)
사람들이 사용하는 기기(모바일, 데스크탑 등)들이 기본적인 http 요청 따위는 전혀 힘들어하지 않을 정도로 발전했습니다.
- 본인 어렸을 때 램 256MB 짜리 썼는데, 지금 램 8GB는 기본임. 모바일 기기도 램 1GB 이하는 거의 안보임.
- 요새 마우스에 모래시계 버튼 안본지 오래됨
웹 서버 자체의 최적화
- 예전에는 렌더링 등을 고려하지 않은 웹이 많았고, 하드코딩 되어있거나 이런저런 버그들이 즐비함.
- 프레임워크, 언어 들의 발전함.
- 웹 생태계의 효율적인 디자인 패턴들이 자리잡음.
그리고 제가 생각하는 두 번째 이유는 협업 관점에서인데요,
조그만한 사이드 프로젝트나 웹 페이지가 그렇게 중요하지 않은 비즈니스에서는 SPA로 뚝딱 구현해버리면 깔끔하고 좋아요. 하지만, 일반적인 웹 페이지는 하나의 팀이 모든 부분을 구성하지 않습니다. 웹 규모가 커질수록 물리적으로 하나의 장비 혹은 하나의 클러스터에서 구동되지 않는 경우도 많구요, 이런 경우에는 깔끔하게 페이지를 분리 시켜서 여러 팀이 각각의 페이지를 온전하게 도맡아 처리하는 방식이 일반적으로 좋습니다. (저 또한 이 방식으로 일합니다.)
하나의 페이지를 모든 팀이 관리한다는 것은 현실적으로 쉽지 않은 부분이죠. 한 부분에 문제가 생겼을 때 하나의 페이지로 구성이 되어있다 보니까 줄줄이 소시지로 대규모 장애가 되어버리기도 쉽구요. 페이지의 배포할 때의 문제, 책임 문제 등 여러모로 깔끔하지가 않습니다. 전체 서비스를 온전한 SPA로 구현한다는 것은 사용자 측면에서는 너무나도 이상적인 부분이지만, 유지하는 입장에서는 그리 좋은 방식은 아니죠. 그래서 요즘에는 서비스 부분부분 도메인별로 SPA를 적용하는 방식을 많이 사용하는 듯 합니다.
요약하자면, 현대의 웹들은 온전한 SPA가 적용되지 않았다고 하더라도 사용자 경험에 크게 문제가 없다는 점, 장애방지나 번들링 최적화, SEO 최적화 등 유지보수 관점에서 SPA가 좋지 않게 작용할 수 있다는 점에서 굳이 SPA에 목매일 필요는 없다 정도로 생각하고 있습니다.
CSR (Client Side Rendering) 과 SSR(Sever Side Rendering)
CSR과 SSR, FE에서의 대표적인 렌더링 구분 방식입니다. 현대 웹 서버를 구현하는 데에 있어서 매우매우매우 중요한 개념입니다.
결국 어느 쪽에서 렌더링 과정을 담당할 것이냐에 대한 분류 인데요, 여기서의 렌더링은 데이터를 받아와서 html로 파싱하고, DOM에 적용시키는 일련의 과정을 의미합니다. 쉽게 말하면 raw하던 데이터를 화면에 그리는 과정이죠!
CSR은 말 그대로 client (사용자의 기기, 브라우저를 의미합니다.) 쪽에서 렌더링을 담당하는 방식입니다.
SSR은 반대로 server (사용자의 기기로 데이터를 내려주는 웹 서버를 의미합니다.) 쪽에서 렌더링을 담당하는 방식입니다.
CSR과 SSR 원리에 대한 이야기는 사실 이미 좋은 글들이 너무나도 많아서, 그런 글들을 찾아보는 것이 좋을 것 같아요. 저는 발전과정과 현대 적용 추세 측면에서 얘기를 다뤄볼게요. 원리 자체에 대해 잘 모르신다면 아래 글을 읽어보시는 것을 추천드립니다.
[ 기술 스터디 ] SSR과 CSR의 차이
자강두천
velog.io
CSR과 SPA?
사실, CSR과 SPA는 주로 같이 따라다닙니다. 저는 초반에 이 두 용어가 헷갈린 적도 많아요. SPA는 어플리케이션 관점에서, 어떤 사이트가 하나의 페이지로만 동작한다면 SPA 인 것이고, CSR은 단일 페이지의 렌더링 관점에서 그 페이지가 어떻게 렌더링 되고 있는 가에 대한 용어이죠.
보통 SPA 를 구현하기 위해서는 CSR 방식이 필수적으로 선택됩니다. 페이지 이동 없이 AJAX로 데이터를 불러와서 페이지를 그리는 방식으로 구현이 되는데 그 방식이 페이지 관점에서는 결국 CSR 이기 때문이죠. (글재주가 없어서 이 똑같은 애기를 벌써 3번째 하고 있네요 허허;) 하지만 결코 SPA = CSR 은 아닙니다. SPA도 첫 페이지 로드는 SSR로 구성하고 그 이후에 인터렉션들은 CSR로 구현되어 있는 경우가 많죠.
Why CSR? Why SSR?
그렇다면 어떤 상황에서 CSR과 SSR 을 적용하는지에 대해 생각해봅시다.
CSR의 등장배경과 적용하는 상황은 사실 SPA와 AJAX 를 얘기하면서 많이 얘기했던 것 같습니다. 페이지 깜빡임 없이 바로 페이지 변화를 줄 수 있다는 점, 서버에 부담이 줄어든다는 점에서 적용되었고 SPA 구현에 큰 역할을 담당하고 있다고 이야기했었죠. 그렇다면 SSR은? 왜 SSR을 사용할까요?
SSR이 필요했던 순간 들
위 이미지는 첫 페이지가 로드되는 부분에서의 CSR을 의미하는데요, 첫 페이지가 CSR로 그려진다면, 사용자는 로딩 바나 스켈레톤 컴퍼넌트를 보는 부분이 불가피할 것입니다. 예전에는 이런 로딩 바가 나오는 시간이 불편함을 느낄 정도로 긴 것이 일반적이었고, 이런 로딩바가 페이지 전체 단위로 적용되는 케이스가 많았었기 때문에 좋지 않았습니다.
이런 단점은 SSR 방식으로 커버가 되는데요,
서버 단에서 모든 data fetching 작업, 렌더링 작업들을 처리하고, 그냥 단일 html 페이지를 만들어서 전달해줍니다. 그러면 브라우저는 JS를 받는 시간에 먼저 화면을 그리는 것이 가능해집니다. 사용자 입장에서는 웹 페이지가 로드되자마자 로딩 바나 스켈레톤 컴퍼넌트 없이 화면이 한번에 깔끔하게 떨어집니다. 서버의 역할이 더 커지게 된다는 불안한 요소가 있지만, 사용자 경험(최초 로딩) 측면에서, 그리고 SEO 측면에서 많은 이점이 생기게 됩니다. 그래서 일반적으로 첫 페이지에 나와야 하는 모든데이터를 서버에서 다~~~ 처리해버린 후에 클라이언트에서는 그냥 html을 이용해서 그리게만 하면 되는 방식을 채택하게 됩니다. 서버에서 온전한 페이지를 펭귄밀크처럼 하나하나 떠먹여주므로 클라이언트에서는 주는대로 받아먹기만 하면 되는 것이죠.
BUT?
하지만 현대 FE 트렌드에서는 조금 관점이 달라지고 있습니다!
'첫 로드는 SSR, 그 이후에 data interaction들은 CSR 적용, 서비스 도메인이 달라지는 경우는 페이지 이동'
현대까지는 이 방식이 국룰이었다면, 이제는 조금 더 관점이 달라지고 있구요, 위 방식에서 심화된, 조금 더 업그레이드된 개념들이 생겨나고 있습니다.
이부분 에 대한 자세한 내용은 3장에서 다뤄볼 것인데요, 사실상 3장이 진짜 핵심일 것 같아요. 3장은 저도 공부나 리서치를 많이 해보고 작성해야할 것 같네요 ㅎㅎ
마치며
1장에서는 웹 서버의 발전과 역사에 대해서 간단하게 알아봤습니다.
2장에서는 이런 사실을 바탕으로 구체적인 렌더링 방식이 어떻게 적용되고 있는지, SSR CSR SPA 에 대해서 얘기해 보았습니다.
3장에서는 2장 내용을 바탕으로 앞으로 FE 생태계의 렌더링 방식이 어떻게 발전해 나아갈 것인지에 대해 다뤄보겠습니다.
새해복 많이 받으셔요 다들!
출처
https://velog.io/@hlna0308/SPA%EC%99%80-CSR%EC%9D%80-%EA%B0%99%EC%9D%84%EA%B9%8C