리액트를 사용하는 이유 (SPA, CSR, SSR)

리액트를 사용하는 이유 (SPA, CSR, SSR)

 

 

많은 개발자들에게 사랑받고 있는 리액트!! 현재, 많은 현업 개발자들에 의해 쓰이고 있고, 프론트엔드 개발에 관심이 있다면 다들 한번씩은 들어봤을 것 같다. 그러나 다른 사람들이 다 쓰니까, 인기 있으니까 무작정 리액트를 쓰게 된다면 우리는 리액트가 주는 장점이나 본질을 이해하지 못하고 제대로 사용하지 못 하게 된다.

 

SSR (서버사이드 렌더링) 과 CSR (클라이언트사이드 렌더링)

 

우선 리액트의 장점을 이해하려면 SSR과 CSR의 개념에 대해서 알아야 한다.

웹문서는 브라우저에 표시되어야 할 정보들을 담고 있다. 이 정보들은 브라우저가 해석할 수 있는 프로그래밍 언어로 되어 있으며, 서비스를 제공하는 회사 혹은 개인의 서버(요즘엔 클라우드 서버)에 저장되어 있다. 사용자(Client)는 url을 통해 그 정보를 요청하게 되고, 그 요청을 받은 서버는 웹문서를 사용자 브라우저에 전달해주게 된다.

그리고 나서, 브라우저가 사용자가 보기 편하게 예쁘게 표시하는 과정을 ‘렌더링(Rendering)’이라고 한다.

 

- SSR

SSR (Server Side Rendering) 의 경우에는 먼저 인덱스 페이지에 표시되어야 할 html 파일을 먼저 브라우저가 다운 받는다. 그리고 나서 javascript 파일도 다운 받는다. javascript 파일을 다운 받는 동안에 이미 html 파일의 렌더링을 시작하기 때문에 웹페이지 표시가 빠르다. 그러나 컴퓨터의 속도가 느리다면 처음에 javascript가 다 다운이 받아지지 않아서 기능이 동작하지 않을 수도 있다.

그 다음 사용자가 네비게이션의 링크를 클릭하여 페이지를 이동했을 때 해당 페이지의 html 파일을 다운 받고 이어서 javascript 파일을 다운 받는 일련의 과정이 반복된다. 그래서 렌더링이 빠른 장점이 있지만 페이지를 이동할 때마다 화면 깜박임(화면이 로드될 때마다 화면이 백지로 변하고 다시 화면이 출력되는 과정)이 있다. 웹페이지의 용량이 가벼울 경우에는 문제가 없으나 무거워질 경우에는 화면 깜박임이 길어져 사용자 경험이 나빠질 수 있다.

 

- CSR

CSR (Client Side Rendering) 의 경우에는 맨 처음 url 요청에 웹문서가 가지고 있는 모든 정보, 링크페이지까지도 한번에 다 받아온다. 그래서 초기 화면 로드가 느리다. 그러나 일단 로드가 되고 나면 사이트 내에서 돌아다닐 때 로드되는 과정이 없어지므로 사용성이 좋아진다. 우리가 흔히 쓰는 페이스북과 같은 대형 플랫폼들의 화면이 많은 사진과 정보가 있음에도 페이지를 이동할 때 화면 깜박임이 없는 이유는 바로 이 때문이다. 그래서 보통 로드가 될 때 ‘Loading’임을 표시해주는 화면이 먼저 표시되도록 만든다.

그렇지만 CSR이 사용성이 좋아서 무조건 CSR 방식을 채택해야 하는 것은 아니다. CSR 방식은 보통 링크 이동을 할 때 자바스크립트를 이용해 동적으로 화면을 바꿔주므로, index.html 문서가 가지고 있는 정보가 적어서 검색엔진들이 웹사이트를 분석해서 내용들을 파악하고 검색 시에 뿌려주어야 할 때 제대로 걸러지지 못 하게 된다. 이를 SEO(검색엔진최적화)가 나쁘다고 말한다.

 

SPA (Single Page Application)

 

과거 웹사이트는 현재처럼 유저 인터랙션이 많은 페이지가 없었고, 페이지의 용량도 가벼웠다. 그러나 현재에 들어서면서 실시간으로 많은 유저의 인터랙션이 일어나는 페이스북, 인스타그램, 유튜브 등의 서비스들이 생겨나면서 화면 깜박임이 없으면서 부드럽게 잘 동작하는 웹사이트의 개발이 필요하게 되었다.

이러한 문제를 해결하기 위해 많은 프레임워크들이 생겨났지만, 리액트가 가장 성공적으로 자리를 잡게 되었다. 리액트는 CSR 방식을 채택한 것이며, Single Page Application 의 구축을 가능하게 해준다. 초반에 표시되는 index.html 파일 외에 html 문서는 없으며, index.html 파일의 내용을 자바스크립트를 이용해 재 렌더링 해주는 방식으로 페이지를 구성한다. 그래서 페이지 별로 파일을 구성하지 않고, 표시해주어야 할 내용을 각각의 컴포넌트 형식으로 구성한다.

 

- Virtual DOM

DOM 이란 ‘Document Object Model’의 약자로 주로 html 문서 내에 요소를 말한다. html, css, javascript 로 만들었던 웹사이트에서는 querySelector 나 getElementbyID 같은 것들로 직접 DOM 요소를 찾아 직접 조작한다. 이렇게 직접 요소를 조작하는 방식은 페이지 내에 정보가 변할 때마다 다시 페이지를 로드해야 해서 페이지 용량이 크면 클수록 느려지는 단점이 있다. 그러나 CSR 방식으로 한번에 모든 정보를 받고 Virtual DOM 을 이용해 페이지 내에 변한 부분만을 감지해서 그 부분만 변경해주게 되면 훨씬 부담을 줄일 수 있다.

여기서 Virtual DOM이 동작하는 방식은 이러하다. 유저 인터랙션이 일어나면 Virtual DOM에 의해 구성된 DOM 트리는 이전 페이지와 바뀐 부분들을 감지한다. 그래서 변화된 부분만 재 렌더링을 해준다. 그럼 변화를 감지하고 렌더링을 다시 하는 일이 뭔가 더 오래걸리는 일이 아닌가 싶지만, 렌더링이라는 게 훨씬 더 부담이 많이 가는 동작이고 Virtual DOM 이 감지하는 일은 실제 렌더링을 하지 않기 때문에 빠르다.

바로 이 때문에 바닐라 자바스크립트와 리액트의 코드를 짤 때 생각하는 방식의 차이가 생긴다. 가령, 바닐라 자바스크립트로 classList 등 같은 직접 요소를 조작하는 방식에서 useState와 같은 상태 변화를 감지할 수 있는 Hook(훅) 들을 사용해야 하기 때문에, 바닐라 자바스크립트만 사용하고 리액트를 처음 배운 사람에게는 혼란이 올 수 있다.

 

컴포넌트별 구성

 

- JSX

리액트에서는 JSX 문법을 사용해서 요소를 만들기 때문에(필수는 아님, 주로 그렇게 사용함) html 문법에 익숙한 사용자에게는 빠르게 친숙해질 수 있다는 장점이 있다. 사실, JSX는 html과 비슷하게 생겼지만, 자바스크립트의 확장 문법이다. 고로 html이 아니기 때문에 코드가 번들링되는 과정에서 BABEL이 html 문서로 변환시킨다.

이러한 JSX 문법 덕분에 컴포넌트 별로 구성이 가능하다. 컴포넌트 별로 문서를 만들게 되면 재사용성이 좋아진다.

 

리액트 네이티브

 

리액트로 웹을 개발을 하면 리액트 네이티브를 통해 앱 개발이 쉬워지는다는 장점이 있다. 리액트 네이티브를 통해 IOS, Android 앱을 만들 수 있기 때문에 리액트를 통해 개발하면 코드를 재사용하여 네이티브 앱을 개발할 수 있다.