CSR/SSR 그리고 MPA/SPA 이해하기

MPA/SPA 과 CSR/SSR에 대해 헷갈리는 것들이 많았다. 공부했던 내용이라 생각했지만 이후에 CSR, SSR 글을 보면 개념이 뒤섞일 때가 많았다. 공부하는 과정에서 발산한 생각을 구조화한 글로 수렴하도록 만들고자 한다.

렌더링

CSR/SSR을 공부하기 전에 렌더링이 무엇인지 알아볼 필요가 있다. 백엔드를 공부하는 나의 관점에서 렌더링은 브라우저의 렌더링이라 생각했다. 하지만, CSR/SSR에서 말하는 렌더링은 브라우저의 렌더링과는 사뭇 달랐다. 브라우저 렌더링을 설명하는 것은 글의 요지를 해칠 수 있지만 공부했던 과정이므로 간략하게 설명하겠다.

브라우저 렌더링 과정

브라우저 렌더링은 아래의 과정으로 이루어진다.

1. DOM Tree 생성 - HTML을 파싱하고 객체로 만들어(노드화) DOM(Document Object Model)을 생성한 다.
2. CSSOM Tree 생성 - DOM Tree를 만드는 과정과 유사하게 CSS 텍스트를 파싱하고 스타일 시트 객체로 만들어 CSSOM(CSS Object Model)을 생성한다.
3. Rendering Tree 구성 - Dom Tree와 CSSOM Tree로 화면에 표시할 노드만 포함하여 렌더링 트리를 만든다. 이때, display: none과 같은 속성을 가진 요소들은 제거된다.
4. 레이아웃 - 렌더 트리를 기반으로 각 요소의 크기, 위치, 간격 등을 계산하여 화면에 어디에 위치할지 결정한다.
5. 패인트 - 레이아웃 단계의 정보를 바탕으로 요소들을 화면의 실제 픽셀로 변환한다.

CSR/SSR이 말하는 렌더링은 무엇인가

앞서 말했듯이 CSR/SSR의 렌더링은 브라우저의 렌더링과 다르다. 그렇다면, CSR/SSR이 말하는 렌더링은 무엇인가? 나는 렌더링을 ‘사용자에게 보이는 화면(UI)을 만드는 행위’로 이해했다. CSR/SSR의 차이를 알아보기 전에 렌더링이 무엇인지 생각하는 것은 전체적인 과정을 이해하는데 중요하다고 생각한다.

CSR(Client Side Rendering)은 ‘클라이언트에서 UI를 만든다’, SSR(Server Side Rendering)은 ‘서버에서 UI를 만든다’로 큰 틀을 잡고 시작하기 위해 렌더링을 설명했다.

CSR(Client Side Rendering)

CSR은 무엇인가

CSR은 클라이언트가 JS로 DOM 생성에 관여하여 화면을 그리는 방식이다.

CSR은 아래의 과정을 거친다.

1. 클라이언트는 페이지 요청시 서버로부터 최소한의 HTML을 받는다.
2. HTML을 파싱한다.
3. JS를 다운받고 백엔드 서버의 API로 데이터를 요청한다.
4. 데이터(JSON/XML)을 받으면 브라우저의 DOM API를 이용해 DOM 트리를 구성한다

CSR의 장단점

• CSR은 HTML을 받고 API로 데이터를 또 다시 요청하기 때문에 초기 응답이 느리다.
• HTML 태그의 값이 비어있기 때문에 SEO에 불리하다.
• 화면을 변경할 땐 필요한 데이터만 가져오므로 빠르게 느껴지고 서버 부하가 감소한다.

구글의 크롤러는 JS를 실행할 수 있어서 구글에서 SEO는 그나마 낫다고 한다.

CSR의 예시

CSR은 SNS 서비스의 피드를 떠올리면 된다. 최소한의 HTML을 받기 때문에 SNS 게시물은 처음에 화면에 표시되지 않는다. Javascript를 실행하고 API에서 게시물 데이터를 받아와야 화면에 표시되기 시작한다. 이후 무한스크롤과 같은 기능으로 게시물을 넘기다보면 페이지를 다시 로드하지않고 추가적인 게시물들을 볼 수 있다.

SSR(Server Side Rendering)

SSR은 무엇인가

SSR은 클라이언트가 서버로부터 완성된 HTML을 받아 화면에 그리는 방식이다. 서버는 템플릿 엔진(JSP,EJS)의 도움으로 동적인 데이터를 HTML에 삽입할 수 있다.

SSR은 아래의 과정을 거친다.

1. 클라이언트는 페이지를 요청한다.
2. 서버는 DB를 조회하여 게시글 데이터를 불러온다.
3. 서버는 불러온 데이터를 템플릿 엔진의 도움으로 HTML을 완성한다.
4. 브라우저는 완성된 HTML을 받아 바로 DOM 트리를 구성하고 화면에 그린다.

SSR의 장단점

• SSR은 서버에서 HTML을 완성해야하기 때문에 서버의 부하가 증가한다.
• SEO에 유리하고 클라이언트는 다시 데이터를 요청할 필요가 없어 빠른 초기 로딩이 가능하다.
• 새로운 요청이 있을 때마다 서버에서 HTML을 다시 만들어 보내주기 때문에, 화면이 깜박이고 UX는 떨어진다.

SSR의 예시

이커머스 웹사이트를 생각하면 된다. 서버는 제품 정보 데이터를 HTML에 완성하여 클라이언트에 보낸다. 클라이언트는 컴퓨터 성능, 네트워크 환경에 덜 영향을 받으면서 전체 페이지를 즉시 볼 수 있다.

MPA

MPA는 여러 페이지로 구성된 웹 애플리케이션을 말한다.

각 페이지마다 별도의 URL, HTML을 가지고 있어 SEO에 유리하다. 페이지 이동시 전체 페이지를 새로 요청한다.

장단점

• 사용자는 웹 사이트의 특정 부분을 공유해서 볼 수 있다. 예) 쿠팡의 특정 상품을 카카오톡에 공유한다.
• 페이지 전환마다 화면이 깜빡여 UX가 떨어진다.

SPA

SPA는 하나의 페이지로 구성된 웹 애플리케이션을 말한다. 이후의 페이지 이동은 클라이언트가 JS로 DOM을 변경하고 특정 영역을 업데이트하는 식으로 진행한다. 최초 페이지를 로드할 땐 index.html만 받고, 이후에는 데이터(JSON)을 서버와 주고 받는다.

장단점

• 페이지를 새로고침 하지않고 콘텐츠를 업데이트한다. 그래서, 애플리케이션의 반응성이 뛰어나고 사용자는 매끄러운 인터랙션을 경험할 수 있다.
• SEO가 불리하고 초기에 많은 리소스들을 다운로드하므로 초기 로딩이 느리다.

현대의 SSR

웹은 비즈니스를 이루기 위해 만든다. 검색 엔진 상위에 표시되지 않는다면 비즈니스에 큰 타격을 줄 것이다. SSR의 장점은 서버에서 완성된 HTML을 내려주어 SEO가 최적화되는 것이다.

이 장점을 ‘SPA + CSR’ 구조에서 이용하기 위해 SSR을 일부 사용한다. 첫 메인 페이지는 SSR로 내려받아 SEO와 초기 로딩 속도를 높인다. 이후에 사용자 인터랙션, 페이지 전환시 ‘SPA + CSR’ 을 사용하여 부드럽게 동작하게 만든다. 대표적으로 ‘next.js’ 프레임워크가 있다.

MPA와 SSR, SPA와 CSR의 관계

MPA = SSR, SPA = CSR이라고 단순히 생각하기 쉽다. 하지만 이것들은 서로 다른 개념이다.

• MPA vs SPA:
  • MPA는 페이지 구조의 차이 (여러 HTML 페이지 vs 하나의 HTML 페이지).
  • SPA는 하나의 HTML만 사용하고, URL 변경 시에도 JS로 화면 일부만 바꾼다.
• SSR vs CSR:
  • SSR/CSR은 렌더링 시점과 위치의 차이 (서버에서 HTML 완성 vs 클라이언트에서 JS로 HTML 완성).
  • 즉, SSR/CSR은 “누가 화면을 완성하는가”에 관한 이야기다.

따라서 MPA는 보통 SSR과 함께 쓰였고, SPA는 보통 CSR을 사용했지만, SPA+SSR, MPA+CSR 같은 조합도 가능하다. 예를 들어 Next.js는 SPA 구조를 가지면서도 SSR/SSG를 지원하여 SEO 문제를 해결한다.