React에서 SSR(Server Side Rendering)을 알아보자

2018-06-04

최근 2 ~ 3년 간 React에 관심을 많이 가졌다. 그래서 그에 관한 포스트를 가장 처음으로 해보고자 한다. 먼저 React는 Facebook이 만든 Javascript(이하 JS) 라이브러리라는 점 부터 매력적이다. 또한 그 것을 직접 자사 서비스에도 적용시키고 에어비앤비에서도 적극 활용하는 모습, 흔히 개밥먹기라고 하는 행동을 하고 있다. 그리고 React 커뮤니티는 굉장히 핫하고 여러 라이브러리가 그것도 아주 많이 나온다는 점에서도 취미로 삼기도 좋아 보인다. 더 나아가서는 React Native라는 네이티브 앱을 구현할 수 있는 라이브러리까지 내놓았다. 기존에 React Web Application을 구현하는 것과 같은 방식으로 할 수 있다는 것이 웹 개발자, JS 개발자에게 굉장히 큰 매력으로 다가온다. 물론, 앱에 대한 기본적인 이해가 있을 때 빛이 나는 기술인 것은 맞는 것 같다.

개발하는 입장에서 보자면 JSX로 UI Component를 작성하고 그 컴포넌트들을 재사용 가능하게 구성하는 점, 그 컴포넌트들을 조합하여 사용하기 용이하다는 점이 매력적이다. 그리고 SSR(Server Side Rendering) 기능이 생소했었던 상황에서 React로 SSR을 구현해보며 개념을 이해할 수 있었다. 또한 MVC 아키텍쳐의 단점을 보완하기 위해 직접 Facebook이 만든 단방향 Data Flow의 Flux 아키텍쳐와 그 구현체인 Redux에 대해서도 알아보며 React와 접목시켜 새로운 영역에 대한 지식을 쌓을 수 있는 계기가 됐다. 그 이후 요즘 흥미를 끄는 것은 React의 SSR을 구현하는 Next.js라는 라이브러리이다.

SSR(Server Side Rendering)

그래서 앞서 몇 번 언급된 SSR이 무엇인지 알아보자. 서버 사이드 렌더링은 문자 그대로 렌더링을 서버에서부터 하는 것이다. 일반적으로 JS 라이브러리/프레임워크를 사용하면 서버에서는 거의 빈 껍데기만을 제공하고 클라이언트에서부터 페이지를 그리는 것이 일반적이다. 그러나 서버 사이드 렌더링은 서버에서 JS 라이브러리/프레임워크를 이용하여 미리 페이지를 그려 클라이언트에 보내고, 클라이언트 단에서 바뀔 부분이나 클라이언트에서만 존재하는 기능에 관한 작업을 하게 된다. 이 때 가상DOM을 활용하여 바뀐 부분만 바꿔주는 등 클라이언트에서의 부하는 최소화한다.

SSR 장점

어느 부분에서나 장단점은 있다. 장점은 SEO(Search Engine Optimization, 검색 엔진 최적화)이다. JS 라이브러리/프레임워크를 사용하면서 고질적인 문제는 SEO이다. 앞서 말했듯이 그냥 미리 그려지지 않고 빈 껍데기만 제공된다면 검색엔진이 당연하게도 내용을 검색하는데 어려움이 있다. (모든 검색 엔진이 검색하지 못 하는 것은 아니다) 하지만 SSR을 이용한다면 서버에서부터 페이지를 제공할 때 컨텐츠가 담겨있기 때문에 SEO에 대한 걱정을 덜어내게 되는 것이다. 그리고 초기 로딩 속도 이슈에 대한 문제가 해결된다. 브라우저에서 빈 화면을 오랫동안 보여주는 일은 사용자 입장에서 유쾌한 일은 아니다. 그러나 SSR을 사용한다면 미리 그려진 페이지를 제공하기 때문에 처음 사용자가 페이지를 열었을 때 비교적 빠른 시간 내로 컨텐츠가 담긴 페이지를 이용할 수 있다.

SSR 단점

SSR이 앞서 말한 장점을 제공하는 만큼 사용하는데에 있어서 어려움과 번거로움이 생기는 것이 사실이다. 먼저 서버 코드에 있어서도 JSX를 사용할 수 있도록 빌드나 변환하는 과정이 필요해진다. 또한 JS 기반인 서버 플랫폼, Node.js로 서버를 할 때, 같은 JS라고 할지라도 클라이언트와 서버가 모든 것을 같이 공유할 수는 없다. (DOM, Document의 URL 등) 이런 부분에 대한 예외 처리는 물론이며 특히 여러가지 라이브러리를 같이 사용하게 되는 경우 더더욱 복잡도는 증가한다. 또한 클라이언트의 부하를 줄였지 서버의 부하는 당연히 일반적인 렌더링보다 더 생길 수 있다.

끝.