[원티드 프리온보딩 챌린지 7월] CSR/SSR 개념 정리&강의 후기

원티드 프리온보딩 프론트엔드 챌린지 7월
CSR/SSR 개념 정리&강의 후기

 

 

프리온보딩 프론트엔드 챌린지 7월 | 원티드

 

 

이번 7월의 주제는 CSR/SSR과 Next.js였다. 지난 1월에 CRUD w React Query 챌린지를 진행하셨던 오종택 멘토님께서 Next.js 13에 대해 강의하신다고 해서 바로 신청했다. 1월 챌린지는 당시 나의 수준으로는 이해하기 어려워서 머리에 인덱싱만 해둔다는 생각으로 강의를 들었다. 그때 들어놓았던 개념이 이후에 도움이 되었는데, 특히 stale while revalidate 등이 그랬다. ('너... 상했어.') 나는 문사철 비전공자 출신이라 딱딱하고 이론적인 개념 설명이 잘 이해되지 않을 때가 있는데, 종택님은 비유를 통해 재미있게 설명해 주셔서 그런 부분이 특히 마음에 들었다. 이번 챌린지에서도 개발 경선식이라는 별명이 생길 정도로 최대한 쉽게 이해시켜주려고 하셨다.

 

Next.js에 대해 공식문서와 강의로 어느정도 학습을 했고 가벼운 프로젝트도 경험해봤으나 아직 부족하다 느껴졌고, 특히 이번 13버전에서 어떤 점이 달라졌는지 제대로 알지 못해서 이번 챌린지가 기대되었다. 이번에도 반절 정도만 이해가 된 것 같지만 이 또한 언젠가 깨닫는 순간이 오리라 믿으며, Next.js보다는 CSR과 SSR의 차이에 중점을 두고 이번 챌린지에서 배운 내용을 가볍게 정리해보았다.

 

 

---

 

 

이번 강의의 핵심은 '낙곱새'였다. 사실 낙곱새가 뭔지 몰라서 검색이 필요했다. 낙지, 곱창, 새우를 넣고 만든 요리라고 한다. 내가 좋아하지 않는 두 가지가 들어있어서 딱히 앞으로도 먹을 일이 없을 것 같지만 😂 CSR과 SSR을 낙곱새 포장 방식으로 비유할 수 있다. 낙곱새를 배달시키면 2개의 옵션이 있는데, 비조리 방식 포장과 조리 방식 포장이 그것이다. 비조리의 경우 집에서 끓이면 되는 형태이고, 조리의 경우 완성된 요리가 도착한다. 취향에 따라 다르겠지만 배달을 시키는 이유 중에는 요리가 불가능한 상황이거나, 무엇보다 직접 요리하기 귀찮아서인 경우가 많다. 딱 봐도 식당에서 조리된 낙곱새가 조금 식긴 했겠지만 훨씬 간편할 것이다. 이것이 SSR이다. 서버가 왜 서버인가? Server, 제공하는 대상이다. 서버는 낙곱새를 serving해준다. CSR로 비유할 수 있는 비조리 방식의 경우 빨리 도착하더라도 먹는 사람이 조리해서 먹어야 한다. 브라우저에서 직접 끓여야 한다. 이 비유를 생각하며 다음의 내용을 본다면 좀 더 쉽게 이해할 수 있다. 

 

 

 

🔖 CSR (Client-side rendering)

클라이언트가 데이터를 가져와서 그린다. CSR로 구현한 페이지에 들어가면 처음은 빈 HTML이 로드된다. 이후 자바스크립트, CSS 등의 에셋을 다운받고 실행한 뒤에 렌더링이 완료된다. 

 

CSR 렌더링 과정

 

 

 

🔖 SSR (Server-side rendering)

서버가 데이터를 가져와서 그린다. SSR로 구현된 페이지에 접속하면 서버에 최초의 GET 요청이 발생한다. 서버에서 사용자가 요청한 경로를 확인하고 React 애플리케이션을 렌더링한다. 응답이 오면 화면에 출력되고, 렌더링이 완료된다. 

 

SSR 렌더링 과정

 

SSR의 특징 

1. SSR은 CSR에 비해 SEO에 유리하다. CSR은 요청이 오면 즉석에서 렌더링이 일어나므로 페이지가 정보가 없다. 반면 SSR의 경우 서버에서 미리 만들어놓은 데이터가 있기 때문에, 크롤러가 방문했을 때 제공할 정보값이 있다. 개발자가 개발을 완료하고 빌드하는 순간에 렌더링이 일어나는 SSG(Static Site Generation) 역시 SEO에 유리하다. 

 

2. SSR은 CSR에 비해 서버 부하가 크다. SSR은 렌더링 로직을 서버에서 처리해야 하기 때문에, 많은 사용자가 접속할 경우 서버에 부하가 발생한다. 

 

 

 

렌더링 성능 비교

CSR	SSR
빈 화면(TTFB fast, TTI slow) 번들 크기가 커질수록 두드러짐 코드 스플리팅, 번들 압축, 트리 쉐이킹의 중요성	느린 응답(TTFB slow, TTI fast) 싱글 스레드 renderToString 메서드의 특징 상 최초 응답이 늦어질 수 있음 번들 크기가 커질 경우 TTI까지 속도가 느려져 CSR과 마찬가지 단점을 가질 수 있음

 

최초 bite의 도착 속도(TTFB)는 CSR이 빠르다. 하지만 급하게 나온다고 옷을 제대로 갖춰입지 않은 셈이다. 어쨌든 빠르긴 했다. SSR은 서버에 요청하고 결과를 받느라 TTFB의 속도가 느리다. TTI(Time to Interactive)는 앱이 사용자와 소통할 준비가 된 시점이다. CSR의 경우 일단 빨리 도착하긴 했는데, 옷을 주섬주섬 챙겨 입느라 결과적으로는 SSR보다 TTI가 느리다. SSR은 처음엔 늦었지만 완성된 결과를 들고서 한번에 나타나기 때문에 TTI가 빠르다. 

 

 

 

🔖 Next.js

프레임워크와 라이브러리

프레임워크와 라이브러리의 차이는 '제어의 역전'이라는 글을 읽은 적이 있다. 너무나 이해하기 어려운 개념이다. 간단하게 살펴보자면 라이브러리는 개발자가 라이브러리의 코드를 가져다 사용하는 것이고, 프레임워크는 프레임워크에서 개발자의 코드를 가져다 사용하는 것이다. 누가 핵심을 쥐고 있느냐가 차이다. 강의에서는 이를 연필과 프린터에 비유해 설명해 주셨는데 조금 더 이해가 쉬웠다.

 

라이브러리는 개발자가 ✏️ 연필(코드)을 가지고 쓰는 것이다. 프레임워크는 🖨 프린터가 개발자의 코드를 가져가서 사용하는 것과 같다. 프린터 내부 로직을 알지 못해도 된다. 프린터를 뜯어서 개조하기도 어렵고 자유가 없지만, 편리하다. Next.js는 프레임워크다. 리액트 기반으로 작동하며 Next.js는 개발자의 코드를 이용해 이렇게 저렇게 가져다 쓰고, 우리가 원하는 결과가 출력되는 것이다. 

 

 

---

 

 

이번 기회에 CSR과 SSR에 대해 자세히 배웠다. Next.js를 처음 공부할 때는 무슨 말인지 알아듣지 못했던 내용이 점차 이해되었다. 마지막 강의 시간에 배운 내용은 너무 어려워서 머리에서 튕겨져 나갔는데, 종택 멘토님의 또 다른 장점인 자세한 강의 노트를 참고하면서 복습해봐야겠다. 토요일 오전임에도 불구하고 마지막 강의까지 약 2~300명이 참여했던 것으로 기억하는데 아마도 프리온보딩 챌린지 중 가장 팬(?)이 많은 멘토님이 아닐까 싶다. 재방문율이 높은 맛집이랄까? 👍

 

챌린지를 진행하면서 사전 과제와 매 강의 말미에 주어지는 과제를 했다면 나만의 토이 프로젝트가 완성되었을 것이다. 챌린지 기간 동안 다른 프로젝트를 진행하고 있어서 병행하기에 무리라고 느껴졌고, 그래서 첨부할 실습 링크가 없는게 아쉽다. 본인이 의지가 있고 열심히 참여한다면 배울 것이 매우 많은 챌린지이다. 특히 나 혼자 하는 과제가 아니라 다른 참여자분들이 공유한 과제를 볼 수도 있는 것이 장점이자 동기부여 요소가 되어줄 것이다.