NextJS

왜 NextJS를 사용해야 하는가?

우리는 React를 사용하면서 어떤 이점을 얻을 수 있는가? 그 이점을 위해 포기해야하는 부분은 어떤것이 있는지에 대해 알아볼 필요가 있다.

React는 SPA(single page application)으로 하나의 HTML에 javascript를 통한 다이나믹 페이지를 만들어 내는 방식이다. SPA는 전통적인 방식인 MPA(Multiple pages application)과 반대되는데, 매 요청마다 새로운 HTML파일을 서버로 부터 제공받는 방식을 MPA라고 하며, 이 과정 때문에 SSR이라고 볼 수도 있다. 그렇다면, 자연히 SPA는 CSR과 연결된다고 할 수 있다. (다만, MPA와 SSR이 같은 말은 아니다.)

CSR의 단점은,

1. 초기 렌더링이 오래 걸린다. (모든 파일을 다 불러와서 해당 페이지만 만들어내기 때문에)
2. SEO가 어렵다. (한 페이지에서 모든 엔드포인트 정보를 가지고 있기 때문에)

크게 두 가지 정도를 생각해 볼 수 있다. 두 가지 이슈를 해결하려면 어떻게 해야할까?

그 해결책이 NextJS가 될 수 있다.

NextJS는 무엇인가?

React기반의 SSR지원 Framework이다. SSR뿐만 아니라 정적 파일 배포도 가능하다. 어찌보면 React와는 거리가 좀 있어보이는 부분이 있다.

React는 하나의 HTML파일을 통해 app을 구성하는 반면 NextJs에서는 여러개의 HTML파일을 통해 App을 구성한다. 실제로 nextjs를 통해 프로젝트를 구성하고, 이후 빌드를 해보면 여러개의 html파일이 생성되는 것을 볼 수 있다. (S3를 통해 배포하게 된다면 여러개의 html파일을 업로드 하게 된다. index, 404, 등)

잘 따지고 보면 실제로 NextJS는 완전한 CSR은 아니지만, 그렇다고 CSR이 전혀 아닌 것은 아니다. SSG를 통해 정적 파일을 배포하나 그 파일 안에서의 페이지 변화등을 CSR방식으로 구현하고 있다.

SSR, CSR, SSG는 무엇인가

Next의 성질을 살펴보면서 가장 많이 등장했던 세 가지 키워드를 살펴보자

1. SSR(Server-Side Rendering) 서버 사이드 랜더링
2. CSR(Client-Side Rendering) 클라이언트 사이드 랜더링
3. SSG(Static-Site Generation) 정적 페이지 생성

SSR

서버사이드 랜더링은 NextJS를 찾는 가장 큰 이유라고 볼 수 있다. React를 사용하면서 NextJS접하게 되는건 SSR이 가장 큰 이유이니까..

그렇다면, 서버 사이드 랜더링을 하면 어떤 이점이 있을까?

CSR을 하게되면 많은 JS파일이 한번에 불러와지면서 초기 랜더링이 느려질 수 있다. JS파일을 모두 읽기 전에 페이지 랜더가 진행되지 않는 상태가 발생하고, 이로인해 처음 진입한 사용자는 페이지가 로드 되는 시간을 온전히 기다려야 한다. 다음으로, SEO의 문제가 있다. SEO(Search Engine Optimization)에서 문제가 생기는데, 한가지 페이지에서 모든 뷰를 만들어내다보니 HTML Head에 들어가야하는 Meta tag가 정상적으로 생성되지 않는 문제와 Bot이 페이지에 접근했을 때 올바른 Meta tag를 전달하지 못하는 이슈가 있다.

이 문제를 해결하기 위한 방법으로 SSR이 있다. CSR은 골격에 JS파일이 그림을 그린다고 생각하면, SSR은 이미 완성된 그림을 전달 받아서 표시하는 방식이라고 생각할 수 있다. (간단하게 설명하자면..)

다만, 매 페이지를 서버에 요청해야 하기 때문에 처리과정에서 서버에 부하가 많이 생길 수 있다. 또한 서버의 처리속도에 따라 사용자 경험이 상이하게 나타 날 수 있다.

CSR

SSR설명에서 비교한 것과 같이 CSR은 클라이언트에서 Javascript파일을 통해 랜더링 하는 방식을 말한다. 때문에, JS파일을 불러온 이후에는 빠른 속도로 랜더링이 가능하다.

또한, HTML파일의 교체 없이도 페이지 변환이 가능해 페이지 변환 시 화면을 새로고침 하지 않고 페이지를 변경할 수 있다.

SSG

정적 페이지 생성방식은 고전적 웹 페이지의 구조라고 볼 수 있다. 초기 웹 페이지는 모든 엔드포인트에 해당되는 HTML을 생성하고 해당 엔드포인트의 Response로 HTML 파일, 코드를 넘겨주어 화면에 표시하는 방식 이었다.

이처럼 HTML파일을 생성하여 해당 엔드포인트의 Response로 넘겨주는 방식이 SSG이다.

NextJS는 빌드해보면 실제로 SSG방식의 App을 구성하는 것 처럼 보인다. 내가만든 모든 페이지를 생성하는 모습을 볼 수 있다.

SSG는 페이지 교체에서 새로운 HTML파일을 불러오기 때문에, 화면이 새로고침 되는 것을 볼 수 있다.

사용 이점

서버의 개념을 client에서 사용할 수 있기 때문에, 서버에서 사전 처리하여 페이지를 생성하거나 데이터 처리를 통한 페이지 관리를 조금 더 정교하게 작업 할 수 있다. SPA형식의 앱을 사용하는 경우 api호출 및 데이터 처리를 client에서 진행하기 때문에, 화면 전환후 데이터 패칭의 과정을 필연적으로 지나가게 된다.
이러한 경우 데이터처리 이후 페이지 변경을 진행하게 되는데, 이 과정에서 화면 깜빡거림이나 데이터 분기에 대한 처리가 복잡해 진다.
컴포넌트 안에서 데이터에 따른 분기 처리가 추가됨으로써 큰 덩어리의 컴포넌트는 기능이 비대해지거나 많은 상태를 가지고 페이지를 그리게되는 경우를 겪게 된다.

물론, 컴포넌트를 조금 더 정교하게 디자인하게 되면 해당 과정은 조금 더 분리해서 진행할 수 있으며, 외부 library를 통해 별도의 state를 가지고 미리 처리하는 경우도 가능하다.

제한 사항

구조 적으로 프로젝트가 정형화 되는 사항이 있다. Nextjs는 화면을 전환하기 위한 route의 구조가 잡혀져 있으며, 컴포넌트 분리 및 빌드 방식을 정해진 방식으로 진행한다. 때문에, Nextjs의 이점을 누리기 위해서는 정해진 구조에 맞춰서 프로젝트를 구성하는게 유리하다.