[NNN]_Next.js 의 필요성

들어가며

개인 프로젝트를 진행하기에 앞서 Next.js 를 프로젝트에

적용하는 이유와 Next.js 의 필요성에 대한 생각을 적어보려고 합니다.

 

 

Next 를 왜 사용하는지?

실무와 연관이 있다고 생각하는데, 리액트로도 충분히 웹사이트를 만들 수 있습니다. 근데 넥스트는 리액트를 사용한 프레임워크거든요. 즉 실무를 위해서 더 갖춰진 것들이 많습니다.

대신에 프레임워크 특성상 정해진 틀 안에서 코딩을 해야되기 때문에 자유도는 조금 더 줄어드는 그런 단점이 있죠.

대신에 넥스트가 해주는 것 중에 가장 큰 장점이 서버사이드 렌더링이라고 생각합니다.

서버사이드 렌더링에 대해 알아보기 전에 웹사이트의 동작원리에 대해 알아보도록 하겠습니다.

 

SPA 의 구동방식

브라우저, 프론트 서버, 백엔드 서버, 데이터베이스가 있습니다.

만약 브라우저에서 프론트엔드로 블로그페이지를 요청했다면 프론트엔드 서버에서는 백엔드 서버로 블로그페이지의 게시글들을 요청을 하게 되면, 백엔드 서버에서는 다시 데이터베이스에다 실제 게시글 데이터들을 요청하게 됩니다. 게시글 데이터를 받아서 프론트 서버로 보내주고, 프론트 서버에서 다시 그 데이터와 html 을 합쳐서 다시 브라우저로 보내주게되죠.

이런 복잡하게 보이는 왕복과정이 그나마 단순한 편에 속합니다. 이렇게 한 번 쭉 데이터베이스까지 갔다가 다시 데이터베이스에서 백엔드 서버, 프론트 서버, 브라우저로 돌아오는데 리액트 같은 싱글 페이지 애플리케이션 페이지 하나의 동작과정입니다. 리액트에서 페이지가 넘어가고 이런 건 눈속임이고, 페이지가 넘어가는 것처럼 보이지만, 사실 하나의 페이지고 그 안에 있는 컴포넌트만 바꿔치기를 해서 마치 페이지가 넘어가는 것처럼 눈속임을 해주는 거거든요.

그래서 자세히 들여다보면, 프론트엔드 서버는 브라우저로부터 블로그페이지를 요청받으면 어떤 페이지를 요청받든 하나의 자바스크립트 파일과 하나의 HTML 파일 정도와 CSS 나 이미지들 정도만 내려줍니다. 데이터는 빠져 있는 상태로요.

HTML 파일과 CSS, 자바스크립트 파일로 화면은 그려주지만, 데이터가 아직 존재하지 않습니다. 그래서 데이터가 없으면, 프론트엔드 개발자는 데이터가 없기 때문에 로딩창을 띄우고 있어야겠죠.

백엔드 서버에 게시글 데이터들을 프론트엔드 서버가 요청하면, 백엔드 서버는 데이터베이스에서 실제 게시글 데이터들을 가져와 프론트 서버에게 주고, 프론트는 브라우저로 넘겨줍니다. 그럼 브라우저에서는 로딩창을 없애고, 백엔드 서버에서 받았던 데이터를 받아서 화면에다 그려주는거죠. 

이런 일련의 과정들이 React 나 Vue, Angular, Svelte 와 같은 싱글페이지 애플리케이션이 구동하는 방식입니다.

 

전통적인 웹사이트 vs SPA

그래서 전통적인 웹사이트에서는 브라우저에서 페이지를 요청하면, 프론트 서버에서 다시 백엔드 서버로 바로 데이터를 달라고 요청을 합니다. 데이터베이스에서 데이터 받아와서 프론트 서버로 보내주고, 프론트 서버는 HTML 과 데이터를 합쳐서 브라우저로 보내주죠.

아까처럼 일자로 데이터의 흐름으로 표현되는데, React 나 Vue, Angular 이런 곳에서는 데이터 없이 화면만 먼저 받고, 그 다음에 데이터는 로딩창 돌아가고 있는 와중에 백엔드 서버에서 직접 받아옵니다. 이것이 전통적인 웹사이트와 SPA 의 가장 큰 차이점이죠. 왜냐면 싱글 페이지 화면은 딱 한 번만 받아오고, 데이터가 변경될 때, 업데이트가 필요로 할 때에만 페이지를 새로 받아오기 때문입니다.

 둘의 장단점을 정리해보겠습니다.

전통적인 방법은 데이터를 받아온뒤, 한 번에 화면에 그려진다는 장점은 있지만, 이 과정이 길기 때문에 로딩속도가 오래 걸리는 뚜렷한 단점이 존재합니다.

하지만, SPA 는 데이터를 받아오기 전, 데이터에 의존하지 않는 부분은 미리 보여주고, 데이터를 필요로 하는 부분만 로딩창을 띄워줘 그런 단점을 해소시켜줍니다. 실은 전체적인 로딩시간은 사실 비슷할 수도 있다고 생각이 듭니다. 어쩌면 리액트 방식이 전체적인 시간이 더 오래 걸릴 수도 있죠. 처음 화면 가져올 때, 이 로딩 창은 표현해주지만, 모든 화면을 다 가져와야 되기 때문에 앞으로 바뀔 거에 대비한 화면들도 다 가져와야 되기 때문에 결국 데이터까지 받아오는 시간은 더 걸릴 수도 있는데 로딩창 화면에 뭐라도 보이는 시간이 단축돼서 리액트를 쓰는 거죠.

 

이런 학습과정을 거치는 이유는 무턱대고 자세히 알지 못한 채 리액트를 사용했었기에 다시 이론으로 돌아가 리액트의 역할과 필요성을 느끼기 위해서입니다.

 

다시 설명 이어 붙이자면, 때문에 적재적소에 리액트를 이용해야 하는데, 서비스적으로 비즈니스적으로 그런데도 리액트를 사용하는 경우는 사용자에게 바르게 인터랙션이 필요할 때가 될 것입니다. 근데 사용자가 이렇게 빠르게 인터랙션이 필요할 때에도 단점이 있죠. 위와 같이 로딩창이 아닌 데이터가 담긴 페이지를 업로드하는 데에는 오히려 느려질 수도 있고, 첫 페이지에서 로딩창이 렌더링되면, 검색 엔진이 해당 페이지에는 아무런 컨텐츠가 없고, 로딩 창밖에 없구나 하고 검색 엔진에서 순위가 확 떨어져 버릴 수가 있습니다. 

 

SPA 의 검색엔진 문제점 해결방법 두 가지

이런 문제를 해결해줄 수 있는 것이 서버 사이드 렌더링입니다.

검색 엔진을 위해서 서버 사이드 렌더링이 나오고, 아까 여기서 첫 요청 때 모든 페이지를 프론트 서버에서 브라우저로 보내준다고 했는데, 이건 너무 비효율적일겁니다. 그래서 코드 스플리팅이라는 기술로 방문한 페이지에 대한 코드만 보내주게 하는 기능이 있습니다.

서버 사이드 렌더링에는 두 가지가 존재합니다. 프리렌더랑 서버사이드 렌더링이 있는제, 프리렌더는 검색 엔진이라는 것을 알아차린 다음에 그 검색 엔진일 때만 아까처럼 백엔드 서버에서 데이터를 받아서 html 을 완성해서 주고, 그냥 일반 유저일 땐 기존 리액트 방식으로 주는 방법이 프리렌더입니다.

조금 복잡한 프리렌더를 대신해 서버 사이드 렌더링은 첫 방문만 전통적인 방법대로 하고, 그 다음 페이지 전환일 때는 리액트 방식으로 하는 하이브리드와 같은 방식이죠.

대부분의 서비스는 검색 엔진에도 노출이 돼야 하고, 사용자를 대상으로 하는 페이지는 속도도 빨라야 하기 때문에 코드 스플리팅도 적용을 해야합니다.

 

그럼 모든 페이지에서 서버사이드 렌더링과 코드 스플리팅이 적용되어야 할까?

코드 스플리팅도 필요하지 않고, 서버 사이드 렌더링도 필요 없는 페이지는 대표적으로 어드민(관리자) 페이지가 있을겁니다. 어드민 페이지는 검색엔진에 나올 이유도 없고, 어드민 페이지 조금 느리다해서 관리자들은 조금 불편할 수 있겠지만, 고객들한테 반응속도가 중요한 것만큼 관리자한테 그렇게 중요하지 않겠죠.

그래서 어드민 페이지를 만들 때는 굳이 복잡하게 넥스트를 사용하지 않고, 리액트로만 사용하면 됩니다. 그렇지만, 웬만한 costomer B2C 서비스를 할 때엔 넥스트 같은 서버사이드 렌더링을 지원하는 프레임워크를 고려하는 것이 좋습니다.

 

 

요약해서

1. React 의 단점으로 모든 페이지를 한 번에 업로드하면서 느려지는 초기 렌더링 시간과 떨어질 수 있는 검색엔진 순위가 있다.

2. 이를 해결하기 위해 리액트에서도 Code Splitiing 과 검색엔진 최적화 방법이 있지만, 서버사이드 렌더링은 이 두 가지 기능을 수행한다.

3. 어드민 페이지에서는 조금 느려져도, 검색엔진 순위에서 밀려나도 상관없기 때문에 Next 를 사용하지 않는다.

 

무분별하게 React, Next 를 사용하는 것보단 적재적소에 서비스에 맞게 사용하기 위해 고민하는 시간을 가져야 한다.