기술 스택 선정 고민 : Vite vs Next.js

앞서 포스팅한 번들러 스택 선정 고민에서 내린 결론은 아래와 같았다.

 

 

즉, 우리 프로젝트에서 서버 사이드 렌더링(SSR)이 더 효율적이라면 Next.js를, 클라이언트 사이드 렌더링(CSR)이 더 효과적이라면 Vite를 쓰는 것이다. 하지만, 이와 같은 단편적인 이유 뿐만 아니라 종합적인 pros and cons를 비교하기 위해 포스팅을 하며 개념을 정리해보고자 한다.

 

CRA와 Vite

 

React 팀의 공식 문서 참조 (새로운 React의 공식문서에서 CRA 부분은 삭제되었다.)

 

CRA (과거 공식 문서 참고)

• Create-React-App(이하 CRA)는 React 애플리케이션을 쉽고 빠르게 생성하기 위한 공식적이었던(과거형) 툴체인이다.
• 프로젝트 구성, 개발 서버, 번들링 등을 사전 구성하여 별도의 설정 없이 React 애플리케이션을 시작할 수 있도록 해준다.
• 즉, 프론트엔드 빌드 파이프라인을 생성하며 Babel이나 Webpack과 같은 build 도구를 사용하나, 설정 없이도 동작한다.
• 현재 "CRA로 프로젝트를 생성하기" 파트는 업데이트된 React 공식 문서에서 사라졌으며 그 이유는 아래와 같다.

It is slow and bulky compared to the modern methods. The initial setup is quite bulky as there are a lot of dependencies to be installed. 

 

Vite (비트)

• Vite는 빠른 개발 속도를 강조하는 웹 개발 빌드 도구이다.
• 네이티브 ES 모듈(ESM)을 기반으로 사전번들링 기능으로 Esbuild를 사용한다.
• 번들러가 아닌 ESM을 이용하는 HMR을 지원한다.
  • 어떤 모듈이 수정되면 Vite는 그저 수정된 모듈과 관련된 부분만을 교체하고, 브라우저에서 해당 모듈을 요청하면 교체된 모듈을 전달한다.
  • 전 과정에서 완벽하게 ESM을 이용하기에, 앱 사이즈가 커져도 HMR을 포함한 갱신 시간에는 영향을 끼치지 않는다.

 

본격적으로 툴들을 비교해보기 전에, 프로젝트에 적용하기 위해 미리 알고 있어야 하는 개념들을 우선적으로 정리해보았다.

 

CSR, SSR, SSG, ISR

 

웹 애플리케이션의 렌더링 방식을 나타내는 용어이다.

 

Client-Side Rendering

개념 : 클라이언트인 브라우저가 렌더링을 처리

• CSR은 초기 요청 시에 서버로부터 빈 HTML 파일을 받아오고, 그 이후 클라이언트 측에서 JavaScript를 사용하여 동적으로 컨텐츠를 렌더링하는 방식이다.
• 클라이언트 측에서 JavaScript가 실행되어야 페이지가 완전히 렌더링된다.
• SPA를 구현하는 주요 방법 중 하나이다.
  • SPA(Single-Page Application) : 클라이언트 측에서 동적으로 페이지를 업데이트하는 방식

 

장점

• 사용자 경험: 클라이언트 측에서 컨텐츠를 동적으로 렌더링하기 때문에 사용자 경험이 향상될 수 있다.
  • 즉, 페이지 전환과 상호작용이 매끄럽게 이루어진다.
  • 모든 로직, 데이터 가져오기, 템플릿, 라우팅은 서버가 아닌 클라이언트에서 처리된다.
• 서버의 적은 부담: 서버 측에서는 단순히 정적 파일을 제공하므로 서버 부담이 상대적으로 낮다.
• 캐싱: 이미 스크립트가 캐싱된 경우 인터넷 없이도 해당 CSR 웹 애플리케이션을 실행할 수 있다.

단점

• 초기 로딩 속도: 페이지 초기 요청 시에는 서버로부터 빈 HTML 파일만 전달받고, 이후 JavaScript 파일을 다운로드하고 실행해야 하므로 추가적인 시간이 소요된다.
  
  • 서버에 첫 요청 시 전체 페이지에 대한 모든 문서 파일을 받기 때문에 SSR보다 로딩 속도가 느리다.
  • 자바스크립트 번들 크기의 영향을 많이 받기 때문에 적극적인 코드 분할(code splitting)을 고려해야 한다.
• SEO (Search Engine Optimization): 초기 HTML에는 동적으로 생성되는 컨텐츠가 포함되지 않기 때문에, 검색 엔진은 페이지의 내용을 인식하기 어려울 수 있다.
  • 포털사이트 검색엔진 크롤러가 웹사이트에 대한 데이터를 제대로 수집하지 못하는 경우가 발생할 수 있다.
  • 구글의 검색엔진의 경우, 자바스크립트 엔진이 내장되어 있어 크롤링이 되지만 네이버, 다음의 경우에는 검색엔진이 제대로 크롤링하지 못하기 때문에 sitemap 문서 작성 등 별도의 보완작업이 필요하다.
  • 특정 페이지에서 다른 페이지로 변할 경우, 이를 인지시키기 위해 각 페이지에 대한 메타 데이터를 설정해야 한다.

 

Server-Side Rendering

개념 : 클라이언트인 브라우저가 매번 서버에 데이터를 요청하여 서버에서 렌더링을 처리

• SSR은 초기 요청 시에 서버 측에서 렌더링된 HTML을 생성하여 클라이언트에 전달하는 방식이다. 
• 서버에서 컨텐츠를 완전히 렌더링한 후에 클라이언트에 전달한다.

 

장점

• 초기 로딩 속도: 서버 측에서 미리 렌더링된 HTML을 전달하므로 사용자는 초기 페이지를 빠르게 볼 수 있다.
  
  • 해당 첫 페이지에 해당하는 문서만 브라우저에게 전달하여 브라우저가 렌더링하기 때문에 CSR보다 초기 로딩 속도가 빠르다.
• SEO: 모든 컨텐츠가 렌더링된 HTML에 포함되므로 검색 엔진이 페이지의 내용을 쉽게 인식할 수 있다.
• 적은 클라이언트 부담 : 클라이언트의 하드웨어 및 소프트웨어 성능에 영향을 덜 받는다.

단점

• 사용자 경험: 페이지의 전환이나 상호작용 시에 서버 요청이 필요하므로 사용자 경험이 느릴 수 있다.
  • 페이지 갱신 시에 클라이언트가 서버에게 필요한 데이터를 요청하고 서버가 응답해주는 방식이기 때문에 로딩 시간이 소요될 수 있다.
• 서버 부담: 서버 측에서 컨텐츠를 렌더링하기 때문에 서버 부담이 상대적으로 높을 수 있다.
  • 서버 사이드에서 HTML 파일과 안의 내용을 생성해야 하기 때문에 서버 호스팅이 필요하다.
  • 이를 통해 데이터베이스와의 상호 작용이나 사용자의 요청에 따른 동적인 컨텐츠 생성이 가능하다.

 

Static Site Generator

개념 : 클라이언트가 "빌드" 타임에 생성된 HTML을 서버로부터 받아옴

• SSR처럼 서버로부터 완성된 HTML을 받아오지만, 다른 점은 HTML 생성 시점이 빌드 타임이라는 것이다.
• Next.js에서 권장하는 렌더링 방식이다.
• 동작 방식은 아래와 같다. 
  1. 사용자가 웹 페이지를 방문하면 엣지 캐싱(edge cashing)된 HTML 클라이언트로 반환해준다.
     
     • edge cashing : 최종 사용자에게 더 가까운 컨텐츠를 저장하기 위해 캐싱 서버를 사용하는 것
       
     • 캐싱 서버를 사용하면 사용자와 물리적으로 가까운 위치에 서버를 배치하여 지연 시간을 최소화할 수 있다. 이를 위해 전 세계에 분산된 캐싱 서버 네트워크를 구축하는 CDN(Content Delivery Network)을 사용하는 경우가 많다.
  2. 브라우저는 HTML을 다운로드하고 최종 사용자가 사이트를 볼 수 있도록 한다..

장점

• 빠른 FP, FCP, TTI: 빌드 타임에 HTML 파일을 생성하기 때문에 빠른 FP, FCP, TTI를 제공한다.
  • FP(First Paint) : 사용자가 브라우저에서 처음으로 콘텐츠를 볼 수 있는 시점 (로고, 배경색 등)
  • FCP(First Contentful Paint) : 브라우저가 처음으로 실제 컨텐츠를 렌더링하는 시점 (이미지, 비디오 등)
  • TTI(Time to Interactive) : 페이지가 완전히 로드되고 상호작용이 가능한 상태가 가능한 시점 (이벤트 처리 등)
• 빠른 TFB: 매 요청마다 생성하는 것이 아니므로, SSR과 달리 빠른 TFB를 달성할 수 있다.
  • TFB(Time to First Byte) : 웹 페이지 요청 시 서버로부터 첫 번째 바이트를 수신하는 데 걸리는 시간
  • 즉, 매 요청 마다 HTML 파일을 생성하는 것이 아니라 사전에 생성되기 때문에 SSR과는 다른 특징을 지닌다.
  • SSR은 매 요청마다 서버 측에서 동적으로 HTML을 생성하는 방식이고, 정적 사이트 생성은 빌드 타임에 HTML 파일을 제공하므로 일관성있는 빠른 TFB를 제공한다. 
• SEO: 이미 생성된 HTML 파일을 받기 때문에 SEO 친화적이다. 

단점

• URL에 종속: SSG는 웹 애플리케이션의 모든 URL에 대한 개별 HTML 파일을 생성하는 방식이다.
  
  • 따라서 URL을 예측할 수 없는 동적인 콘텐츠에 대해서는 SSG를 적용하기 어렵다.
    • SSR은 매 요청마다 서버에서 페이지를 생성하므로 동적인 컨텐츠에 대해서도 적용이 가능하다.
    • CSR은 페이지를 브라우저에서 동적으로 생성하므로 서버측에서 HTML 파일을 생성할 필요가 없다.

 

따라서 SSR과 SSG를 비교했을 때, SSG의 성능이 더 좋다고 말할 수 있다.

• SSR의 장점은 SSG에서 가능한 것보다 더 많은 "실시간" 데이터를 가져와서, 보다 완전한 요청에 대한 응답을 하는 것이다.

 

동적인 컨텐츠의 예 : 실시간 주식 시세, 소셜 미디어 피드, 사용자 인터랙션 결과, 실시간 채팅 또는 댓글, 실시간 게임 점수판 등

 

Incremental Static Regeneration

개념 : 런타임 중에 정적 페이지를 만들거나 업데이트되게 해주는 SSG와 SSR의 하이브리드 솔루션

• ISR(증분 정적 재생성)은 전체 사이트를 다시 빌드할 필요 없이 페이지별로 정적 생성을 사용할 수 있게 해준다.
• 즉, SSG와는 달리 ISR은 데이터가 업데이트 되면 해당 페이지만 다시 생성하고 나머지 페이지는 그대로 유지할 수 있다.
• Next.js에서 제공하는 기능이기도 하다.
• 동작 방식은 아래와 같다. 
  1. SSR과 달리 즉시 placeholder 및 스켈레톤과 같은 대체 페이지(fallback page)가 제공된다.
  2. 데이터가 확인되면 최종 페이지가 캐시되고, SSG와 마찬가지로 캐시된 버전의 페이지를 받게 된다.
  3. 데이터가 업데이트되면 변경된 페이지만 다시 생성하고 캐시를 업데이트 한다. (백그라운드에서 이루어짐)
  4. 재검증시에도 먼저 캐시된 버전의 페이지를 받고, 업데이트된 버전을 받아 항상 빠른 응답을 받을 수 있다.
• 다시 말해, SSG처럼 정적 콘텐츠의 장점을 가지며 동시에 동적인 데이터 업데이트를 처리할 수 있다.

장점

• 빠른 사용자 경험 : SSR과 달리 페이지가 즉시 제공되어(fallback page) 사용자 경험이 좋아진다.

단점

• 페이지 디자인에 종속 : 웹 페이지 디자인 요소가 FMP를 지연시킬 수 있다.
  • FCP(First Contentful Paint) : 사용자에게 의미 있는 콘텐츠가 표시되는 시점
  • 새로운 데이터가 도착하기 전까지는 이전에 캐시된 버전의 페이지가 표시되며 이는 페이지의 크기와 복잡성, 서버의 성능에 따라 달라질 수 있다.

 

정리

• CSR은 웹 애플리케이션의 인터랙티브한 동작이 필요하거나 대화형 컨텐츠를 다룰 때 유용하다.
• 서버 성능이 좋은 상황에서 초기 로딩 속도가 빠른 애플리케이션을 원하고, SEO가 중요할 때 SSR을 쓸 수 있다.
• 초기 로딩 속도가 빠르고 서버 부하가 적으며 동적인 컨텐츠가 중요하지 않을 때 SSG를 쓸 수 있다.
• 사용자 경험과 실시간성이 중요할 때 ISR을 쓸 수 있다.

 

정적 사이트와 동적 사이트

정적 사이트

정적 사이트 생성은 사전에 컴파일된 HTML, CSS 및 JS 파일을 생성하여 웹 서버에 호스팅하는 방식을 의미한다.

• 이는 런타임에 서버나 데이터베이스에 데이터를 쿼리하는 대신, 빌드 시점에 필요한 데이터를 사전에 가져와서 페이지를 렌더링하는 방식이다.
• 정적 사이트 생성은 페이지의 컨텐츠가 변경되지 않거나 자주 업데이트되지 않는 경우에 특히 유용하다.
• 정적 사이트의 예시는 다음과 같다.
  • 포트폴리오 웹사이트, 상품 랜딩 페이지, 사용자 가이드 등의 문서 등과 같이 콘텐츠가 상대적으로 고정적인 경우
  • 빌드 프로세스에서 필요한 데이터를 가져와서 사전에 페이지를 렌더링하고, 이 렌더링된 페이지를 웹 서버에 업로드하여 호스팅한다.
  • 빌드 시점에 정적 HTML 파일로 생성되어 제공되고, 변경이 필요한 경우에는 새로운 빌드를 통해 업데이트 된다.

장점

• 페이지의 로딩 속도가 빠르고, 서버 측의 부하가 적으며 배포가 간단하다.
• 캐싱과 CDN을 통한 성능 향상이 용이하다.
• 검색 엔진은 사전 렌더링된 HTML을 읽고 색인화할 수 있다. (SEO 최적화)
  
  

단점

• 동적으로 변경되는 데이터에 대해서는 제한적이다.
• 페이지가 렌더링되는 시점에 데이터를 동적으로 가져와야 하는 경우에는 정적 사이트 생성이 적합하지 않다.
• 이런 경우, 동적 라우팅 및 서버 사이드 렌더링을 지원하는 프레임워크나 도구를 사용하여 적절한 데이터 흐름을 구성할 수 있다.

 

동적 사이트

동적 사이트는 사용자의 요청에 따라 동적으로 컨텐츠를 생성하는 웹사이트를 말한다.

• 동적 사이트의 예시는 다음과 같다.
  
  • 소셜 미디어 피드: 사용자가 로그인하면 해당 사용자의 친구 목록, 게시물, 알림 등이 동적으로 업데이트되어 표시 
  • 전자상거래 사이트: 사용자가 상품을 검색하거나 주문을 생성할 때마다 데이터베이스에서 정보를 가져와 페이지를 업데이트
  • 실시간 채팅 애플리케이션: 사용자가 메시지를 보내면 다른 사용자의 화면에 즉시 반영되며, 실시간으로 대화가 진행 
  • 블로그 또는 뉴스 사이트: 사용자가 특정 글을 요청하면 해당 글의 내용을 데이터베이스에서 가져와 동적으로 표시 

장점

• 사용자에게 더욱 인터랙티브하고 풍부한 경험을 제공할 수 있다.
• 사용자에게 개인화된 경험을 제공하여 사용자 참여도와 만족도를 높일 수 있다.
• 데이터베이스와의 연동을 통해 복잡한 데이터 처리와 조작이 가능하다. 

단점

• 일부 검색 엔진은 JavaScript를 실행하지 않거나 동적으로 생성된 컨텐츠를 적절히 인덱싱하지 못할 수 있다. (SEO에 불리)
• 서버에서 데이터 처리와 렌더링을 수행해야 하므로 서버 부하가 증가할 수 있다. (트래픽이 많은 경우나 복잡한 데이터 처리가 필요한 경우에는 서버 리소스의 효율적인 관리가 필요)
• 동적 사이트는 서버와 클라이언트 간의 데이터 교환과 사용자 입력 처리가 빈번하게 발생하므로 보안 취약성이 존재할 수 있다. 

 

예전 포스팅("Goodbye, CRA" 요약) 다시 보기

 

(오.. 이게 또 이렇게 이어지는 구나)

 

예전에 CRA와 관련하여 간단하게 포스팅을 해둔 적이 있다. 그 당시에는 Next.js와 Vite가 뭔지.. 등 개념이 명확히 잡히지 않은 상태에서 단순히 기술 커뮤니티의 블로그("Goodbye, CRA!")와 gitHub의 이슈("CRA을 대체할 만한 추천 툴이 뭘까요?") 내용들을 번역한 내용이었다. 지금의 나는 이제 이 문서들을 읽고 각 툴에 대해 어느 정도 비교를 할 수 있게 되었다..!!! 

 

Vite의 치명적 버그

"Goodbye, CRA" 기사에서는 CRA 대신 모든 면에서 성능이 우수한 Vite 사용을 추천한다. 하지만 기사에 달린 댓글에서는 아직 초기 버전인 Vite에 대한 치명적인 버그가 있다는 것을 알려주며 리액트 팀의 공식적인 권고는 NEXT.JS 등의 프레임워크 사용이라는 것을 다시 한 번 환기한다.

 

Vite의 큰 문제는 개발 환경과 프로덕션 환경이 다르기 때문에 프로덕션에서 어떤 버그가 나올 지는 개발 환경에서 전혀 알 수 없다는 것이다.

• 즉, 개발 환경에서는 ESBuild, ESM을 사용하여 쾌적한 개발 경험을 제공하지만, 프로덕션 환경에서는 Rollup으로 번들링한다.
  • 그 이유는 Vite의 공식문서에 나와있지만 Vite의 현재 플러그인 API가 esbuild를 번들러로 사용하는 것과 호환되지 않기 때문이다.
  • 다만, esbuild는 지난 몇 년 동안 많은 진전을 이루었고 향후 프로덕션 빌드에서 esbuild를 사용할 가능성이 있다고 언급한다.
• 어찌 되었건, 해당 버그를 인식하고 고치기 위한 유일한 방법은 배포를 하는 것이다...
• 아래는 그와 관련하여 오픈된 issue 중 하나며 2021년 초에 문제가 발생했지만 해당 이슈 링크를 들어가보면.. 

 

• 아직까지 해결되지 않은 것을 볼 수 있다.

올해까지도 이어지는 이슈

 

• 그 외에도 sessions/cookies 인증 과정에서 CRA에서 나타나지 않았던 이슈들이 Vite에서 나온 사례 등 아직 안정화되지 않는 모습들이 보인다.

 

React 프레임워크 비교

 

React 공식문서에서는 새로운 프로젝트 환경 세팅을 위해서 Next.js, Remix 등의 프레임워크 사용을 권고한다.

• React 공식 문서에서 Next.js와 함께 React 프레임워크로 추천한 Remix, Gatsby에 대해서도 간단히 알아보았다.

 

Remix

• Remix는 개발자들이 웹 표준에 초점을 맞춘 사용자 경험을 만들 수 있도록 해주는 edge-first 풀스택 프레임워크이다.
  • edge-first : Remix 애플리케이션이 서버가 아닌 전 세계에 분산되어 있는 CDN의 서버에서 실행
• 서버 사이드 렌더링과 클라이언트 사이드 렌더링을 모두 지원한다.
• 라우팅, 데이터 로딩, 상태 관리 등을 포함한 전체적인 애플리케이션 로직을 관리하는 컨트롤러 중심의 아키텍처를 가지고 있다.
• 번들링 및 배포가 매우 빠른 Esbuild를 사용한다. (!!)
• Remix와 Next.js의 차이점은 해당 블로그의 글을 읽어보기를 강력하게 추천한다.(시간이 된다면 레퍼런스 영문 블로그도 포함)

고려해봐야 할 점

• 상대적으로 새로운 프레임워크이기 때문에 커뮤니티의 크기가 아직은 작을 수 있다.
• React 개발자들에게 러닝 커브가 있는 편이다.
• 하지만, Next.js와 비교했을 때 장점이 있는 프레임워크이기 때문에 성장을 지켜봐야할 필요성이 있어보인다.

 

Gatsby

• Gatsby는 정적 사이트 생성기로, React를 기반으로 한 정적 웹사이트를 빌드하는 데 특화되어 있다.
  
  • 빌드할 때 Static HTML을 만들어낸다.
  • Nextjs를 돌리기 위해서는 서버가 필요하지만 Gatsby는 서버를 사용하지 않는다.
• GraphQL을 사용하여 데이터를 쿼리하고, 사전 렌더링을 통해 빠른 로딩 속도와 SEO 최적화를 제공한다.
• 데이터 소스를 통해 컨텐츠를 가져와 정적 HTML, CSS 및 JS 파일을 생성하여 호스팅할 수 있다.
• 따라서 블로그나 웹 사이트 등 정적 사이트를 개발할 때 유용하다.

 

📌 Next.js 

• Next.js는 React 기반의 SSR 및 SSG, ISR를 지원하는 프레임워크이다. (관련 설명은 CSR, SSR, SSG, ISR 챕터 참고)
  
  • React는 기본적으로 클라이언트 사이드에서만 동작하는 SPA 형태로 개발되고, 이는 SEO 효과를 거의 볼 수 없다. 
  • 또, 브라우저가 전체 웹 애플리케이션 번들을 다운로드하여 코드를 실행하기까지의 시간이 오래 걸린다. 
  • 이는 서버에서 미리 렌더링을 해놓는 방식으로 해결할 수 있다.
• Next.js는 Node.js에서 실행되며 SSR, SSG는 서버 사이드에서 실행되기 때문에 브라우저에서 제공하는 전역 객체나 HTML 요소에 직접적으로 접근할 수 없다.
  • fetch, window, document같은 웹 브라우저에서 제공하는 전역 객체에 접근할 수 없다.
    • useEffect 혹은 next/dynamic 모듈을 사용하여 특정 모듈을 동적으로 로드하고, 해당 모듈로 브라우저 전용 객체에 접근할 수 있다. 즉, 클라이언트 측에서만 로드하여 사용한다.
  • canvas같은 HTML 요소에 접근할 수 없다. (canvas란?)
    • HTML5에서 도입된 canvas 요소는 브라우저에서 제공되는 그래픽을 그리기 위한 태그이다.
    • Next.js에서는 서버측에서 canvas를 그리고 이미지로 변환하여 브라우저를 전달할 수 있는 방법을 제공한다.
  • 그러나, Node.js에서만 사용할 수 있는 라이브러리나 API를 사용할 수 있다.
    • fs, child_process 등을 사용해야 할 경우 서버 사이드 코드를 실행(SSR, 서버리스 함수 활용)하거나 페이지 생성 시점에 해당 코드를 처리(SSG)하면 된다. 
    • fs, child_process같은 Node.js에서만 사용할 수 있는 라이브러리나 API를 사용하려는 경우에는 서버 사이드 코드에서 해당 로직을 작성하고 코드를 실행하거나 페이지 생성 시점에 작업을 수행할 수 있다. (관련 블로그 참고)
• (App 라우팅의 경우) 코드 상단에 "use client"를 선언하면 CSR로 작동하게도 해준다.
  • 페이지 전환 시 클라이언트에서 페이지를 동적으로 변경하는 Client-side routing도 지원한다. (공식 문서) 

• Next.js는 프로젝트의 전체 라우팅과 번들링을 관리하며, API 경로와 같은 서버리스 함수도 지원한다.
  • 전체 라우팅 : Next.js는 폴더 기반의 라우팅을 지원한다. (아주 편리!)
  • 번들링 : 내장된 번들러를 통해 코드 스플리팅을 자동으로 처리하여 필요한 자원만을 로드하고 불필요한 자원의 로딩을 최소화하여 성능을 최적화할 수 있다.
  • 서버리스 함수 : api 디렉토리에 API 엔드포인트를 생성하면 해당 엔드포인트는 서버리스 함수로 동작하여 서버 사이드 로직을 처리하거나, 외부 API와의 통신을 수행할 수 있다. (공식 문서)
• Next.js는 Vercel 플랫폼과 강력한 통합을 제공하여 배포와 관리를 간편하게 할 수 있다.
  
  • Next.js는 Vercel에서 유지보수되는 프레임워크이다. 
  • Next.js 애플리케이션은 Node.js나 서버리스 호스팅, 또는 자체 서버에 배포 등 유연한 배포 옵션을 갖추고 있다. 
    
    • Node.js : Node.js 런타임과 함께 애플리케이션을 실행하고, 필요한 포트에서 서버를 열어 클라이언트 요청을 수행
    • 서버리스 : Google Cloud Function 등 서버리스 호스팅 플랫폼에서 Next.js 애플리케이션을 함수 단위로 실행
    • 자체 서버 : Docker 등을 사용해 애플리케이션을 컨테이너화하고 관리
• 또한, Next.js는 완전 정적인 애플리케이션을 생성할 수 있다.
  • 이는 미리 렌더링된 페이지를 HTML 파일로 생성하여 어떤 정적 호스팅 환경에도 배포할 수 있다는 것을 의미한다.
  • 이 경우, 서버 사이드 렌더링이 필요하지 않으며, 모든 페이지가 사전에 렌더링되어 정적 파일로 생성된다.
  • 이러한 정적 파일은 CDN (Content Delivery Network)을 통해 전 세계적으로 빠르게 제공될 수 있다.
• 결정적으로 Next.js는 이미 많은 개발자들과 기업에서 사용하고 있는 널리 알려진 프레임워크이다.
  • 생태계와 커뮤니티가 크고, 다양한 리소스와 지원을 받을 수 있다는 큰 장점이 있다.

 

우리 프로젝트에서 Next.js를 사용해야 하는 이유

위와 같이 Next.js를 사용하는 데에 있어서 수 많은 이점이 있지만, 우리 프로젝트에서 가장 결정적으로 Next.js를 사용해야 하는 이유는 아래와 같다.

 

• Next.js는 SEO에 우수한 성능을 제공하고, 동적 라우팅, 데이터 프리페치 등의 고급 기능을 제공한다.
• SEO 최적화 : SSR을 기본적으로 지원하여 페이지의 초기 렌더링을 서버에서 수행한다. 
  • 페이지 렌더링과 관련된 메타데이터, 타이틀, 설명 등을 동적으로 변경할 수 있도록 지원하여 SEO에 필요한 메타 정보를 쉽게 설정할 수 있다.
• 동적 라우팅 : URL 경로에 매개변수를 포함하거나 동적으로 생성하여 사용자에게 보다 개인화된 콘텐츠를 제공할 수 있다.
• 데이터 프리페치 : Next.js에서 ISR의 일부로 사용되는 기능이다. (페이지의 데이터를 사전에 불러와 정적으로 생성)

 

즉, 좀더 검색엔진에 노출이 되기 위해서 프로젝트의 메인 서비스인 SNS 게시글들이 동적 메타태그로 관련 데이터를 검색 결과에 노출시켜야 하는 것이 필요한 것이다.

 

 

그외에도 Next.js가 제공하는 기능은 아래와 같다.

• 코드 분할 (code spliting)
• 타입스크립트에 대한 기본 지원
• 자동 폴리필 적용
• 이미지 최적화
• 웹 애플리케이션의 국제화 지원
• 성능 분석

 

정리 

• 콘텐츠가 많거나 많아질 것이라고 예상된다면, Data에 접근하는 방법에 대해 자유롭고 싶다면 Next.js
• 통합된 개발 환경과 웹 표준에 초점을 맞춘 사용자 경험을 만들고 싶다면 Remix
• 블로그나 웹사이트 등 빠른 로드 시간과 SEO 최적화가 필요한 정적 사이트를 개발한다면 Gatsby
  
  
  

결론

이렇게 비교를 해보니 왜 Next.js를 공부해야 하는 지 확실히 알게 되었다. (너.. 대단한 애였구나)

1줄 요약으로 배포 시 예상치 못한 버그의 위험성이 적고, 특히 모든 방식의 렌더링을 지원해주면서 SEO에 최적화된 Next.js로 프로젝트를 진행하기로 결정했다.

 

 

레퍼런스

- CSR과 SSR의 장단점

- CSR, SSR, SSG, ISR

- Goodbye, CRA!

- Vite 빌드 관련 gitHub 이슈

- React 공식 문서 

- Next.js 스터디 기록

- Next.js vs. Remix vs. Gatsby

- Remix vs Next.js Which One Should You Use? (읽어보길 추천)