Next.js 와 SSR

설영환·2021년 12월 29일

React로만으로는 안되는걸까?

이번에 넥스트를 사용하는게 어떻겠느냐의 회사 내부에서의 의견이 있었고, 저는 왜 넥스트를 사용하는지 넥스트를 이용하면 장점이 무엇인지, trade off할만한 충분한 장점인지에 대하여 고민하게 되었습니다.

그래서 이번에 넥스트의 이해도를 높이고, 넥스트를 써야되는 이유를 찾아보자! 라는 취지에서 알고있는 내용부터 새로 알았던 내용까지의 정리, 그리고 저나 고민하고 있는 사람들을 납득시키기 위해 이 글을 작성 해봤습니다.

SSR & CSR

넥스트와 그냥 리액트 사이에서의 차이점을 말한다면 여러가지가 있겠지만 제목 한단어로 정리가 됩니다. 이것을 알기위해 웹의 구조?를 순서대로 정리하려합니다. 저는 기본적으로 리액트 개발자라서 리액트,Next 위주의 예제가 될것입니다.

웹이 발전해온 모습

1. 제일 초창기 웹

팀 버너스리가 만든 초창기 웹 (브라우저)

이당시의 웹에서는 문서전달 그 이상도 그 이하도 아니었습니다. 그렇기 때문에 고정적인 문서를 저장하고 있고 그 문서의 형식을 html로 저장해 두었습니다. 읽기 쉽게 하기위해서 태그라는것으로 간단히 위치 구분이나 이미지등은 올릴수있었지만 정적인 웹을 저장하고 그 저장된 곳을 들어가서 저장된 html을 읽는 형식으로 웹이 사용이 되었습니다. 하이퍼 링크라는 기능을 통해 위치를 이동해가며 다른 문서를 열람가능했습니다.

2. 동적인 웹

위 사진은 1999년 11월의 다음

점차 정보의 양이 많아지고 정보가 매 순간 변하는 상황에서 정적인 웹은 문서의 값어치 만으로는 만족도가 점점 떨어지기 시작했다고 생각합니다. 그래서 나온것들이 동적 웹서버 (WAS)입니다. html를 바로 내려주는것이 아니라 데이터를 db에서 받아와서 동적으로 html를 만들어주고 웹서버에서 만들어진 html을 클라이언트에 내려주는 방식으로 진행이 되었습니다. 그렇기 때문에 server에 대한 지식도 필요하고 html에 관련된 지식도 필요하게 되었습니다.

이전부터도 있었지만 이때 정보전달 만이 다가 아니라는 생각을 가지고 css도 발전하게 되었고 이를 더 동적으로 보이기 위하여 JS도 이용하여 탭메뉴 슬라이드 등등의 html과 css를 가지고 돔을 조작하여 사람들에게 더 좋은 경험을 줄수 있게 되었습니다.

게다가 페이지 내부에서 따로 통신하는 방식의 AJAX통신이 많아졌고, 점차 기존의 웹개발자의 롤만으로는 어려움이 오기 시작합니다.

html css 서버 까지 전부 담당하는 웹개발자들은 추후에 프론트 백 둘다 나뉘게 되었고, php jsp asp등의 다양한 방법으로 웹을 전부 만들수 있던 이 당시 개발자들은 풀스택이라고 하시기도 합니다.(하지만 모던 웹을 전부다 할줄안다의 의미와는 조금 거리가 멀수 있습니다.)

3. CSR/SPA의 등장

SPA 라이브러리/ 프레임워크 중 사용도가 가장 높은 React

클라이언트들과 개발자들은 점차 이전까지의 웹에서 단점들을 느끼기 시작합니다. 매번 페이지 이동마다 중복적으로 다운로드 받아야되는 리소스들이 많습니다. 동적인 부분이 진짜 한두군데밖에 안되는데도 서버를 구동하여 html을 생성해야될수도 있습니다. 그러면서 유저는 새로운 페이지를 이동할때마다 흰색 페이지를 잠깐이나마 봐야되는 문제도 있었고, 협업에도 문제가 있었습니다.

여러가지 문제를 보안하기 위해 나온것이 Single Page Application입니다. 이는 제일 처음 리소스를 전부 다운로드 받고 페이지 이동은 클라이언트에서 다 알아서 한다음 필요한 정보만 다운받는 방식입니다. 페이지 이동시에도 새로 html을 다운받아서 하는 방식이 아니기 때문에 유저들은 깜빡임도 사라지고 프론트와 백 두 부분으로 나뉘어서 협업이 좀더 편해진 부분도 있습니다.

이전까지의 웹들은 was가 필요했지만 매번 html을 새로 만들필요가 없이 csr을 통한 spa는 was를 만들 필요가 없어졌고 백앤드의 서버만 따로 두기만 하면 되었습니다. 클라이언트에서는 이전까지에서 안되었던 기능들을 더 많이 개발할수있게 되었고, 더 나은 화면 뿐만아니라 클라이언트의 모든것을 담당하는 사람들을 프론트엔드 개발자라고 하게 되었습니다.

하지만 csr을 통한 spa가 무조건 좋은것은 아니었습니다. 사용자 경험과 데이터 전송의 최소화의 트레이드 오프는 SEO와 초기 로딩속도였습니다. 초기에 모든것을 받아오는 SPA에서는 웹 규모가 커질수록 초기에 받아와야되는 리소스들이 많아지게 되었고, 초기 로딩속도가 느려질수밖에 없었습니다.(대안이 나오기는 했습니다.)

그리고 제일 문제점은 검색엔진이 html을 스크래핑 해가는 과정에서 보여지는 데이터는 극히 초기 root div밖에 없는 관계로 스크래핑이 잘 되지 않았습니다. 단점들을 보안하기 위한 방법들은 분명히 존재하나 이도 완전한 보안법이 아니었습니다.

추가적으로 경로문제등...

4. 다시 시작된 SSR

CSR의 단점들은 그냥 넘어갈수 있는 것이 아니었습니다. 검색이 원하는대로 안된다는 것은 큰 문제였습니다. 그리고 초기 로딩속도가 너무 긴 것도 유저 이탈율에 큰 문제였습니다. 다운로드가 되는동안 로딩화면같은 대안을 내 놓았으나 이도 완전한 해결책은 아니었습니다.

다시 사람들은 SSR을 찾기 시작했습니다. 하지만 지금은 예전과 다른 SPA를 SSR에서 도입해보자라는 방식으로 CSR과 MPA의 단점들을 해결했습니다.

SSR을 통한 spa는 rendering된 html을 온전히 내려주기 때문에 검색엔진도 제대로 동작하고, 페이지마다 리소스를 따로 받을수있어(code spliting)유저 경험에도 나은 경험을 주게 됩니다. 게다가 고질적인 문제인 경로 문제도 해결이되었습니다.

Next 의 동작원리

SSR과 SSG의 두개는 엄연히 다르지만 Rendering이 끝난뒤 html을 을 내려주는 과정까지를 SSR로 통칭하겠습니다.

클라이언트에서 get으로 요청이 들어오면 넥스트에서 SSR로 초기 html을 내려줍니다. 이후 리소스를 다운받아 hydration을 통해 자바스크립트를 실행하여 Dom tree와 자체 제작한 tree랑 비교하여 csr한뒤 그것에 맞춰 patch가 이뤄집니다.

이후 페이지 이동시에는 클라이언트에서 감지하여 필요한 정보만 서버에서 받아와서 spa로 동작하게 됩니다.

위의 방법을 통하여 제일 첫 로딩시에는 SSR로써 작동을 하고 이후에는 SPA방식을 사용하여 작동을 하게 됩니다.

Next를 써야되는 이유

SEO 이부분이 제일 큰거 같습니다. 다른 대안이 있다고 한들 대안일뿐 Nextjs만큼의 해결책까지는 아니라고 보입니다. 제일 많이 쓰이는 react helmet도 헤더의 정보에 동적으로 넣어주기는 하지만 body의 정보까지는 보여주지 않아 스크래핑에 문제가 됩니다. 그리고 렌더의 속도에도 문제가 있다고 알고있습니다.(이는 SEO에 문제) 넥스트에서는 렌더링 되는 html을 내려주기 때문에 좋은 SEO의 해결책으로 작용합니다.
더 좋은 유저의 경험 CSR의 한계상 제일 처음에 리소스를 받아오기 전까지의 시간이 길고 서비스가 작더라도 초기 정보를 fetching 해오기까지의 시간에 깜빡임이 있을수 밖에 없습니다. (예를들어 기본 유저정보를 받아오기 전까지 유저 로그인 버튼이 나온다던가) 이런 것들을 클라이언트 사이드에서 데이터를 받아와서 렌더링을 미리 해준다면 유저는 그러한 경험을 하지 않을수 있어 좋은 경험이 됩니다. 게다가 동적 페이지 뿐만아니라 SSG를 이용하여 정적페이지도 생성이 가능해서 더 빠른 유저경험을 얻을수 있습니다.
그 외
- 이미지 최적화 : 이미지 크기 resizing, lazy loading 등 다양한 최적화
- 내장 라우팅 : React dom route가 아닌 내장 라우팅 제공
- Code Splitting : 한번에 받아와야되는 코드의 양을 줄여줄수 있습니다.
- express나 다른 프레임워크랑도 같이 구현가능

결론

저는 다음 서비스부터는 외부에 보여줘야되는 페이지부터는 넥스트로 작업을 시작해볼거 같습니다. 하지만 이 글을 쓰는 저도 무조건 Next다! 라고 말은 못할거 같습니다. next를 쓰려면 드는 리소스(인적, 시간 등)나 동적인 서버를 구동시키기 위한 서버 비용등 들어가는 리소스에 비해 무조건 좋다까지는 아니라고 생각됩니다.

그럼에도 많은 장점이 있는 넥스트에 대하여 고려의 대상에 놓고 현재 서비스에 사용할만한가? 라는 질문에 도움이 될수 있도록 이 글을 적어봤습니다.

처음의 목적은 이해도를 높이기 위해 시작된 레퍼런스 수집이었지만 현재 회사에서 도입을 해보는게 어떻겠냐라는 질문에 리액트에서 넥스트를 적용해야되는 이유는 뭘까가 주요 질문으로 작용하여 핀트가 안맞는 부분도 있습니다. 하지만 읽어보시고 도움이 되셨으면 좋겠습니다.