[FrameWork] Next.js를 시작하기 전에 (SSR은 무엇인가?)

요즘 내 최대 관심사가 딱 두가진데, 첫번째는 앱개발이고 두번째가 NEXT.js다 

왜 두가지에 관심이 많냐면, 일단 전자에 대한 이유는 앱을 안할 수가 없다. 사람들이 PC를 사용하지 않을 수는 없다만, 결국 제일 쉽고 가볍게 접근 할 수 있는건 모바일 환경이라 일반적인 웹프론트는 구하는데도 상당히 적고 대부분 운영되고 있는 서비스의 Admin 페이지 같은거만 웹프론트로 개발하는 것 같음. 때문에 개발 시장에서 프론트 개발자가 앱 안하면 도태될게 뻔하다는게 보인다. 

후자에 대한 이유는 UX 향상에 대한 관심도 때문이기도 한데, 어디서 지나가는 얘기로 대충 일반적으로 화면 렌더링 되는데 3초이상 걸리지 않는게 좋다고 들었어서 생각해보니 지금 주로 내가 개발하는 웹어플리케이션들이 그 시간을 넘어가는 것 같더라. 꼭 Next를 사용하는 이유가 SSR을 같이 넣어서 초반 렌더링 속도를 향상시키는것에만 있는게 아니긴 하지만 채용을 하는걸 통해 어느정도 UX 향상을 기대해볼 수 있으니 공부해서 나쁠건 없다는 생각이 있다. 

 

그래서 오늘은 NEXT에 대한 기본적인 이야기를 할건데, 사실 기본적이라고 하기보단 대부분 구글링에서 나오는 첫 렌더링 속도 향상에 대한 설명들이 뭔가 이상해서 이해하는데 상당한 어려움을 겪기 때문에 써둔다고 보면 되겠다. 

 

1. NEXT.JS란?

Next.js는 서버 사이드 렌더링, 정적 웹 페이지 생성 등 리액트 기반 웹 애플리케이션 기능들을 가능케 하는 Node.js 위에서 빌드된 오픈 소스 웹 개발 프레임워크이다. - 위키백과 -

위키적 정의는 이런데, 실제 React 홈페이지에서도 툴체인 세계관 얘기하면서 SSR을 통해 렌더링 속도 향상이 필요한 웹개발을 하고 있다면 NEXT를 함께 쓰는 것을 권하도록 작성 되어있다. 

뭐 React-router-dom 같은거 안써도 라우팅 할 수 있다던가. 다양한 용도가 있지만 오늘은 이 렌더링이 중심이니까 이 이야기를 해보려한다.

자 그럼 자세하게 SSR이 뭔지 어째서 렌더링 속도가 빨라지는지 한번 이야기 해보도록 하자.

 

2. SSG / SSR / CSR

소제목을 보면 이게 뭔가 싶은데, 이건 우리가 웹페이지를 브라우저에 띄울 때 어떻게 해왔었는지 기존의 웹 어플리케이션의 역사를 살펴보면 이해하기 참 좋다. 아 물론 더 예전에 주로 사용하던 방식이 구리고, 요 근래 사용하고 있는 방식이 좋다. 이런 얘기가 아니라 애초에 웹어플리케이션의 용도에 따라서 더 좋은 방식이 있다고 생각할 수 있으면 좋겠다.  그럼 순서대로 이야기해보자.

 

1) SSG (Static Site Generation)

1990년대 웹사이트를 막 만들기 시작할 때 사용되던 방식이다. 해당 웹사이트를 구성하는 HTML을  개발자가 싹 다 만들어두고 빌드/배포를 하면 해당 HTML/CSS 파일을 가지고 있는 웹서버(ex ==>  Apache Web Server)(80 포트)가 요청하는 브라우저에 보내주고, 브라우저는 받은 그 정적자산들을 그려주는 방식이다. 

사용자와 상호작용하는 웹사이트가 아니라 딱 정해진 화면만 볼 수 있는 Read-Only 화면이라고 보면 되겠다. 

대표적인 예시로 우리가 주로 깃 블로그를 만들면 사용하게 되는게 이 SSG방식을 대표한다. 코드 상에서 모든걸 편집하고 빌드 배포 과정만 지나가면 그 내용을 확인 할 수 있는 그런 방식이다. 

 

단점은 화면을 추가할 때마다 HTML을 추가해서 다시 빌드/배포과정을 거쳐야한다는 단점이 있다.

(깃 블로그에 포스팅 할때마다 마크다운 파일 추가해서 빌드 배포해야하는거랑 같은 얘기)

 

2) SSR (Server Side Rendering)

여기부터 이제 Servlet/JSP 가 등장하면서 동적처리가 추가된다. DB와 연계 해서 같은 HTML 파일안에 데이터를 바꿔치기하며 렌더링을 할 수 있는 그런 형태다.  우리가 학원에서 Spring으로 Java코드 짜고 Jsp 파일들 만들어서 HttpRequest. 뭐시기 해서 데이터 전달받고 Tomcat으로 구동되는 그거 말이다. 이 경우에는 jsp/Servlet의 구동환경을 제공하여 동적 데이터 처리를 가능케하는 WebContainer라는 부분이 추가 되어서 WebServer가 아닌 WAS(Web Application Server)라는 이름이 되는데 대표적인 예시가 그 유명한 톰캣이다.

 

단점은 애초에 정적인 HTML을 만들어서 저장해두는게 아니다보니, 매번 WAS가 HTML을 생성하여 그것을 전달해주고 브라우저가 그걸 그려주는 과정을 거치는데 해야하는 일이 많아지다보니 서버에 부담이 생기기 시작한다. 또한, 새로운 화면을 매번 만들어내니까 로드하는 과정에서 화면깜빡임이 발생하는 상황이 생긴다. 

(예시로 맞을진 모르겠지만 학원에서 주로 이커머스 쇼핑몰을 만드는 예제를 보여주니까 그걸 예로 들면 될 것 같다. )

 

3) CSR (Client Side Rendering)

드디어 React의 출현 이후 시기까지 왔다. 앞선 SSR의 단점으로 나오는 서버의 부담, 화면 깜빡임 등의 문제를 해결하기 위해 SPA(Single Page Application) 라는 아이디어가 고안됐는데, 하나의 HTML파일만 가지고 바뀌어야할 부분의 데이터만 계속 받아오면서 그 부분만 업데이트 해주는 방식을 의미한다. (컴포넌트 조립식 화면 개발의 시작) 하나의 HTML만을 사용하니 새로 HTML을 만들 이유가 없어졌고, 그로 인해 화면깜빡임 문제를 해결하게 됐다. 또한, 서버가 하는 일이 많아져서 부담이 생기던 걸 렌더링 같은 일들을 Client 차원으로 업무분담을 시켜주니 당연히 서버의 부담이 줄어들었다. 

 

단점으로는 최초에 렌더링 할 요소들을 모두 받아와야하다보니 최초 렌더링 시간이 상당히 오래 걸린다는 문제가 발생한다. 

 

3. NEXT === SSR ? =>  False!

이제 다시 돌아와 NEXT.JS가 SSR를 가능케 한다는 말을 SSR을 한다 라는 말로 해석하는 것들 때문에 혼란을 야기하는데, 그렇게 말하면 과거로 회귀했다는 의미가 되어버리니까, NEXT.JS는 SSR의 장점과 CSR의 장점을 모두 사용할 수 있게 하는 프레임워크다 라고 말해주면 될 것 같다. 초기 화면 렌더링이 느린 CSR의 단점을 보완하기 위해 서버에서 미리 그려준 HTML을 가져와서 뿌리는 SSR에서 사용하던 방식을 일부 이용해, 전체적인 화면의 렌더링 속도를 향상시켜준다고 생각하면 될 것 같다. 물론 그게 가능케 하는거니까 굳이 사용하지 않을 수도 있다.