왜 NEXT.js?

왜 SSR?

Vue 2로 간단한 프로젝트를 진행하고 나서 든 생각은 '서버에 요청을 너무 많이 보낸다'는 점과 '로딩이 오래 걸린다'는 점이었다.
물론 상태관리 툴을 통해, 혹은 Local Storage를 통해 데이터를 저장할 수 있는 덕에 '데이터가 있으면 서버에 요청을 보내지 말라'고 로직을 짤 수는 있었지만, 여러개의 그림 파일을 포함하는 경우, 혹은 여러 번의 요청을 수행해야만 하나의 페이지를 구성할 수 있는 경우에는 로딩이 오래 걸릴 수 밖에 없었다. (흔히들 하는 넷플릭스 클론 코딩이 그렇다.)

SSR을 이용한다면 서버사이드에서 페이지를 구성한 후, 클라이언트 사이드로 넘겨준다고 한다. 이를 이용하면 로딩을 줄일 수 있을 것이며, 로딩 시간이 크게 줄지 않는다고 한들, 여러 번의 요청고 함께 순차적인 렌더링을 할지, 혹은 약간의 점멸이 있더라도 한번의 요청과 함께 한 번에 렌더링을 할지를 정할 수 있게 된다.

더 나아가 SSR로 페이지를 구성하면 검색 엔진 노출이 가능해진다.

왜 Next.js?

Next.js의 특징은 다음과 같다.

1. 토탈 솔루션이다 : 리액트와 리액트-라우터 기능은 물론, Code Splitting과 같은 성능 최적화, express와 비슷한 문법으로 사용 가능한 서버사이드 기능 또한 포함하고 있다.
2. 가장 많이 쓴다 : Next js 특유의 확장성과 편의성으로 국내 기업의 서버사이드 렌더링 프레임워크 점유율 70%의 지분을 담당한다. 해외에서의 검색 순위에서도 매년 React와 비슷하거나, 경우에 따라서는 React를 앞지르기도 하는 등, 꾸준히 롱런하며 인기를 얻고 있다.

개인 프로젝트에서 적용하기 좋은 Gatsby와 비교했을 때에 내가 생각하는 강점은 아래와 같다.

1. SSG와 SSR을 모두 지원한다 : SSG에 집중하는 Gatsby에 비해 SSR도 지원한다. 나는 간단하게 빠른 로딩을 취하고자 하므로 SSR이 필요하다.
2. GraphQL을 안써도 된다 : Gatsby는 GraphQL을 통한 자동화를 지원한다...고는 하는데 나는 GraphQL을 모른다. Next.js에 axios를 도입하여 간단한 기능들을 구현할 예정이다.
3. 정보가 많다 : 말했듯이 Next.js는 인기도 많고 국내 취업시장에서도 환영받는 기술스택이다. 초보 개발자인 나는 이들이 만들어놓은 자료를 찾아가면서 개인 프로젝트를 진행할 예정이다.

추가적으로 내 개인적으로 Next.js를 사용하고자 하는 이유는 아래와 같다.

1. 배포가 편하다 : 서버사이드와 클라이언트사이드를 한 번에 배포할 수 있다.
2. 서버사이드가 간단하고, 자바스크립트를 쓴다 : 기존에 장고의 DRF를 다루어 보았다. 장고의 CBV 기능은 매우 편리하지만, 장고를 위해서 파이썬 공부를 지속해야 했다는 점, 자바스크립트 개발자들의 관습에서 벗어난 변수명과 디자인 패턴, 배포가 복잡하고 보안 문제가 발생할 수 있다는 점 등 때문에 본격적인 프로젝트를 시작하기에는 망설여 졌다. Next.js는 서버사이드 기능을 함께 지원하고, Express를 배우고 싶었기에 Next.js로 간단한 서버사이드를 구성하는 것은 학습에도 좋고, 실제 배포에도 유리한 점이 있을 것이다. 보안이 중요한 기능에 대해서는 추가로 파이어 베이스를 자유롭게 도입할 수 있다.
3. 타입 스크립트의 훌륭한 교보재이다 : 나같은 초보 개발자들에게 타입스크립트는 '귀찮은 존재'이다. 있으면 문법체크도 해주고 자동완성도 해주기 때문에 좋긴한데, 코테에서 쓸 것도 아니고, 어짜피 소규모 프로젝트인데 내 머릿속에 혹은 리드미 파일에 적당히 적어두면 되지???라는 생각 때문에 타입스크립트를 선뜻 시작하기에 망설여지느 점이 사실이다. 하지만 Next.js는 타입스크립트를 정석으로 치며, 실제 Next.js의 학습 자료들은 리액트와는 달리 타입스크립트가 적용된 학습 자료들이 많다. 이는 소규모 프로젝트에서부터 탄탄하게 타입을 관리하는 습관을 들이기에도 좋고, 타입스크립트를 배우고 써야하는 동기부여가 된다.
4. 프레임워크라 편리하고, 체계적이다. : 나 같은 초보 개발자들은 '기능만 돌아가면 되지'라며 폴더 관리를 개판으로 하고, 모듈화도 대충대충 떼운다. 또한 react-router-dom이나 useMemo와 같은 기능들을 쓸 때에도 무엇이 정석적인 문법인지 알고 싶을 때가 많다. Next.js는 파일 구조도 체계적이라 프로젝트에서 아키텍처를 디자인하고 기획하기에 알맞게 느껴진다. 또한 대부분의 Next.js 학습 자료들이 비슷한 문법을 활용하는데, 이는 Next.js가 다양한 예제들을 공식 문서를 통해 배포하고, 이것이 정석으로 취급받기 때문으로 보인다. '의식적인 훈련'을 하기 위해서는 이러한 '정석'들을 체화할 필요가 있다.

다음 글에서부터는 웹팩 없이 Next.js를 설치하고 파일 구조도 Atomic Design Pattern으로 만들어 앞으로의 미니프로젝트들에서 쓰일 보일러 플레이트를 만들고자 한다.

pre-rendering

next js에서는 모든 내용이 프리렌더링 된다.

참조

기존 리액트의 클라이언트 사이드 렌더링은 다음과 같은 과정을 거친다

0. 요청이 들어온다.
1. 비어 있는 HTML 파일을 받는다.
2. JS 파일을 받는다.
3. 리액트를 실행한다.
4. HTML 파일이 렌더링 된다.

이 과정에서 발생하는 문제점은
1. HTML과 CSS로 만들어진 viewable한 문서를 받는 기존 방식보다 최초 로딩이 느리다.
2. 검색엔진용 크롤링 봇이 방문했을 때에 비어있는 HTML파일을 크롤링하여 검색엔진 최적화에 문제가 발생할 수 있다.

반면 서버 사이드 렌더링은 아래와 같은 과정을 거친다.

• 서버에서 미리 HTML파일을 렌더링한다.

0. 요청이 들어온다.
1. 렌더링 되어있는 HTML 파일을 받는다.
2. viewable한 상태에서 js파일을 받는다.
3. 리액트를 실행한다.
4. HTML 파일이 렌더링 된다.

CSR와 SSR을 비교하면 다음과 같다.

1. 최초로 HTML을 받는 시간은 CSR이 더 빠르다. SSR은 HTML을 생성하기 때문이다.
2. 하지만 '비어 있는 화면'을 보는 시간은 CSR이 훨씬 더 길다. 브라우저를 렌더링하는 데에 가장 오래 걸리는 시간은 JS파일을 받고, 이를 적용하는 시간이다. SSR은 HTML을 이미 렌더링해서 전달한 상태이기에 클라이언트는 Viewable한 상태에서 로딩을 기다리게 된다.
3. CSR은 '비어 있는 화면'에서 로딩을 기다리고, SSR은 'Interaction'이 안 된 상태에서 로딩을 기다린다. Viewable하지만 자바스크립트는 로딩이 안 된 상태이기에 이 상태가 사용자의 혼란을 줄 수 있다.

결과적으로 SSR은 CSR보다 로딩이 소폭 느리고, viewable하지만 실제 인터랙션은 되지 않는 괴리가 생길 수 있다는 문제점이 있다. 하지만 사용자가 문서를 인식하고 실제 반응하기 까지의 반응 속도가 있기 때문에(대체로 그 반응속도 동안 js가 로딩되고 리액트가 실행중에 있다) 문서를 더 빠르게 인식할 수 있다는 점에서 SSR은 사용자 경험을 증진시킨다고 평가된다.

기업의 측면에서, SSR은 서버의 자원을 많이 소모한다, SSR 방식에서는 순간적으로 많은 접속을 처리하기에 불리하다. 하지만 말했듯, 최초로 viewable한 상태로 로딩되기 까지가 빨라 사용자들의 이탈을 막을 수 있고, 검색엔진의 크롤링에 대응할 수 있다.

한편 SSR은 코딩이 복잡하다. 하지만 Next.js와 같은 프레임워크의 등장으로 오히려 코딩이 쉬워졌다.