잡쇼퍼와 4주동안 협업을 진행하면서 잡쇼퍼 서비스의 관리자페이지를 리뉴얼했다. 기존의 잡쇼퍼 서비스는 EJS로 구성되어 있었는데, EJS는 코드의 중복이 많고 유지 보수나 확장 측면에서 어려움이 있었다. 그래서 우리 팀은 React를 사용하여 코드를 간결하게 하고 유지,보수에 용이하도록 리팩토링을 진행하기로 했다. 또한 EJS는 SSR방식으로 렌더링이 되기 때문에 React기반의 서버사이드 프레임워크인 Next.js의 사용에 대해 고민하면서 SSR과 CSR에 대해 공부하게 되어 이에 대한 내용과 Next.js에 대해 정리해보려 한다.

SSR? CSR?

-View를 렌더링 하는 위치가 서버인지, 클라이언트인지에 따라 SSR과 CSR로 구분된다.

Server-Side Rendering

asgd.png
SSR은 View를 서버에서 렌더링하여 가져오는 것으로, 브라우저에서 서버로 요청을 하면 요청에 맞는 화면에 데이터가 덧붙은 상태의 완성된 HTML을 response한다.
View가 어떻게 보여질지 서버에서 해석하여 보내주기 때문에 서버 사이드 렌더링이라 한다.
요청시마다 새로고침이 일어나며 서버에 새로운 페이지에 대한 요청을 하는 방식이다.

SSR의 경우,
요청하는 화면의 내용만 받기때문에 초기에 받아야 할 용량이 매우 크진 않다. 따라서, View를 보기까지 첫 로딩이 매우 짧다.
하지만 화면이 전환될 때마다 페이지가 리로딩 되기 때문에 페이지 이동시 화면 깜빡임과 불필요한 템플릿을 중복해서 로딩한다.
또한, 서버의 응답에 의해 페이지를 이동해야하기 때문에 서버에 부담이 크고, 사용자 경험 측면에서 불편함이 느껴질 수 있다.
SEO측면에서 SSR은 완성된 형태(HTML+data)의 템플릿을 서버에서 전달받기 때문에 SEO(검색엔진 최적화)에 유리하다는 장점이 있다.

Client-Side Rendering

sgdgsdg.png
CSR은 클라이언트에서 Javascript를 통해 렌더링하는 방식으로 서버는 단지 JSON 파일만 보내주는 역할을 한다.
화면에 보여줄 내용을 클라이언트에서 생성하기 때문에 클라이언트 사이드 렌더링 이라고 한다.
CSR은 두가지 형태의 요청이 존재하는데, 최초 요청시에는 사이트의 모든 HTML정보가 포함된 리소스를 받고, 이후에는 데이터만 서버로 요청하여 최초 다운로드 된 HTML템플릿과 겹합된 내용을 화면에 렌더링 한다.

SPA ≠ CSR

SPA(Single Page Application)은 단일페이지로 구성되어 브라우저에 최초에 한번 페이지 전체를 로드하고 이후에는 화면 전환시 서버에서 해당 화면에 필요한 데이터만 요청하여 응답받는다.
즉, SPA에서는 화면이 전환될 때, 실제 페이지의 이동이 일어나는 것이 아니라 처음 호출된 HTML상에서 화면을 새로 구성해주는 것이다.
SPA로 개발할 때 CSR 방식을 많이 사용하지만, SPA라고해서 무조건 CSR만을 이야기하는 것은 아니다.

SPA를 CSR으로 구현했을 때,
중복된 리소스 요청이 없이 필요한 부분만 갱신하기 때문에 화면 전환 속도가 빠르고, 자연스러운 사용자 경험을 제공할 수 있다.
또한, 서버에 페이지 전체를 요청하는 것이 아니고, 서버는 필요한 데이터만 JSON형태로 reponse해주면 되기 때문에 SSR에 비해 서버의 부담이 훨씬 적다.
하지만, 초기 접속시 모든 화면에 대한 HTML 템플릿을 다운받아 초기에 받아야 할 용량이 크기 때문에 첫 로딩이 길고, CSR은 View를 생성하는데 Javascript가 필요하고 그 전까지는 HTML의 내용이 비어있기 때문에 검색엔진 크롤러가 데이터들을 제대로 수집하지 못하기 때문에 SEO에 불리한 단점이 있다.

SSR vs CSR

위의 내용을 정리해보면,

  • SSR의 경우, 초기 로딩 속도가 빠르고 SEO에 유리하지만, View 전환시 서버에 계속 요청을 해야하므로 서버에 부담이 크다.
  • CSR의 경우, 초기 로딩 속도는 느리지만 초기 로딩 이후에는 서버에 다시 요청할 필요없이 클라이언트 내에서 작업이 이루어지므로 빠른속도와 자연스러운 사용자경험을 제공하지만 SEO문제가 있다.

이렇듯 두 가지 모두 장단점이 있고, 방법의 차이이기 때문에 어느 것이 좋다기 보다는 구현하고자 하는 서비스의 특성에 따라 적절히 사용하는게 중요하다.

What is Next.js?

Next.js는 React 전용 SSR 프레임워크로 SPA인 React를 사용하여 SSR을 하므로써 CSR의 단점을 극복하고 SSR의 장점을 취할 수 있다.
Next.js는 초기 렌더링만 서버가 담당하고 그 이후에는 서버를 거치지 않은 채 내부 라우팅을 이용해 페이지가 이동되면서 브라우저에서 렌더링을 하는것이다. 이러한 렌더링 방법으로 CSR의 단점인 느린 초기 로딩 속도를 극복할 수 있게 한다.

Next.js가 SSR을 가능하게 하는데 중요한 역할을 하는 getInitialProps가 있다.
getInitialProps 가 plain object 를 리턴하면 해당 객체가 그대로 constructor 의 props로 전달되고, 클라이언트에서는 constructor 에서 props를 통해 전달받은 데이터를 이용해 추가적인 서버 요청없이 원하는 화면을 그려줄 수 있게 되는 것이다.

문서에서 제공하는 NextJS로 할 수 있는 것에 대한 목록을 보면

  • 기본적으로 서버 렌더링
  • 보다 빠른 페이지 로드를 위한 자동 코드 스플리팅
  • 간단한 클라이언트 사이드 라우팅
  • Hot Module Replacement(HMR)을 지원하는 웹팩 기반 개발 환경
  • 익스프레스 혹은 어떤 Node.js HTTP server로 구현이 가능
  • 바벨과 웹펙 설정으로 사용자 정의 가능

등이 있고, 이를 통해 SEO 문제도 해결할 수 있다.

Next.js는 러닝커브가 높지 않고, 사용방법만 익혀도 프로젝트를 진행하는데 큰 어려움은 없다. 하지만 SSR 관련해서 다양한 이슈가 발생했을때 대처하기 위해서는 Next.js의 동작배경을 잘 알고 있어야 한다.

잡쇼퍼 프로젝트를 진행하면서 프로젝트의 방향을 잡기위해 공부했던 SSR/CSR과 Next.js에 대해 정리해보았다.
사실 이 프로젝트를 진행하기 전에는 EJS, Next.js, SSR/CSR에 대해 거의 알지 못했다. 그래서 이 주제들을 공부하고 그것을 토대로 서비스의 특성에 맞는 도구를 고르기 위해 꽤 많은 시간이 소요되었었다.
그럼에도 불구하고 서비스의 특성에 적합한 방법을 사용하여 구현하므로써 사용자 경험을 좋게하고, 프로젝트를 진행하면서 일어나는 다양한 이슈를 해결하기 위해서 중요한 시간이었다고 느껴졌다.