💡기록 계기
프로젝트를 진행할 때 마다 라이브러리나 프레임워크, 패키지, 툴 등 작업 환경이 동작하는 원리에 대한 이해도가 높을 수록 다양한 시도나 디버깅, 환경 개선 같은 것들을 좀 더 효율적으로 체크할 수 있었던 것 같다.
이번에는 경험 차원에서 Next.js를 사용하여 프로젝트를 진행하려 하는데 어중간하게 이해하고 있던 Next.js의 동작 순서와 동작 원리에 대해 좀 더 명확히 이해하고 싶어서 SSR, CSR, Next.js와 React의 차이를 알아보게 되었다.
아래의 내용은 OpenAI의 ChatGPT가 제공한 내용을 기반으로 작성하였습니다.
SSR이란
정의
SSR(서버 측 렌더링, Server-Side Rendering)은 웹 애플리케이션에서 사용자에게 보여지는 콘텐츠를 서버에서 렌더링하여 초기 로딩 시에 완전한 HTML 페이지를 제공하는 방법입니다.
장점
- 초기 로딩 속도 향상: 사용자는 초기 요청 시에 완전한 HTML을 받아 볼 수 있으므로, 초기 로딩 속도가 향상됩니다.
- SEO(검색 엔진 최적화) 향상: 검색 엔진은 페이지의 콘텐츠를 초기 HTML에서 쉽게 읽을 수 있으므로, 검색 엔진 최적화에 유리합니다.
- 소셜 미리보기 개선: 소셜 미리보기(예: 페이스북 링크 미리보기)를 생성할 때 초기 HTML이 사용되므로, 미리보기의 품질이 향상됩니다.
- 안정성: 클라이언트 측 자바스크립트 실행에 의존하지 않고 서버 측에서 콘텐츠를 렌더링하므로, 일부 사용자의 환경에서 발생할 수 있는 자바스크립트 실행 오류를 방지할 수 있습니다.
단점
서버 리소스가 추가로 필요.
서버 사이드 렌더링의 복잡성을 관리해야 한다는 단점.
요청당 HTML을 생성하는 것이므로 서버 부하가 증가할 수 있다.> 서버 리소스가 추가로 필요하다?
- 서버 CPU 및 메모리: 서버 측 렌더링은 서버에서 페이지의 HTML을 생성해야 하므로, CPU 및 메모리 리소스가 추가로 필요할 수 있습니다. 특히 사용자가 많은 웹 애플리케이션의 경우 많은 수의 동시 요청을 처리하기 위해 충분한 서버 리소스가 필요할 수 있습니다.
- 네트워크 대역폭: 서버에서 생성된 HTML을 클라이언트로 전송해야 하므로, 더 많은 네트워크 대역폭이 필요할 수 있습니다. 특히 페이지의 콘텐츠가 크고 많은 사용자가 동시에 접속하는 경우 네트워크 대역폭이 부족할 수 있습니다.
- 서버 캐싱 및 로드 밸런싱: SSR을 사용하는 경우 캐싱(Caching)이나 로드 밸런싱(Load Balancing)과 같은 추가적인 서버 인프라를 구성할 수 있습니다. 캐싱을 통해 렌더링된 페이지의 재사용성을 높이고, 로드 밸런싱을 통해 서버 부하를 분산시킬 수 있습니다.
- 코드 및 인프라 관리: SSR을 구현하는 데에는 코드와 인프라의 복잡성이 증가할 수 있습니다. 서버 측 렌더링을 위한 추가적인 코드 작성과 서버 인프라의 설정 및 관리가 필요할 수 있습니다.
CSR이란
정의
CSR은 클라이언트 측 렌더링(Client-Side Rendering)의 줄임말로, 웹 애플리케이션에서 사용자에게 보여지는 콘텐츠를 브라우저에서 동적으로 생성하는 방식을 의미합니다. CSR에서는 초기에는 빈 HTML 페이지가 브라우저로 전송되고, 이후에 JavaScript가 로드되어 클라이언트 측에서 UI가 동적으로 생성됩니다.
장점
- 빠른 초기 로딩: 초기 HTML은 최소한의 콘텐츠만 포함하므로, 페이지 로딩 시간이 단축됩니다. 사용자는 빠르게 페이지를 볼 수 있습니다.
- 동적인 UI 업데이트: JavaScript가 로드된 후에는 클라이언트 측에서 UI가 동적으로 업데이트됩니다. 사용자의 상호작용에 따라 페이지의 내용이 실시간으로 변경될 수 있습니다.
- 클라이언트 측 라우팅: 페이지 간 이동은 브라우저의 클라이언트 측 라우터가 담당하며, 새로운 페이지를 렌더링할 때마다 서버로부터 HTML을 받지 않습니다. 이는 페이지 간 전환이 부드럽고 빠릅니다.
- SPA(Single Page Application) 구조: CSR은 SPA 아키텍처를 기반으로 합니다. SPA는 단일 HTML 페이지를 기반으로 동작하며, 필요한 모든 리소스를 한 번에 불러오고, 이후에는 데이터만 변경하여 새로고침 없이 페이지를 갱신합니다.
단점
초기 로딩 시간이 길어질 수 있음.
SEO(검색 엔진 최적화)에 제한이 있을 수 있음.> SEO(검색 엔진 최적화)에 제한?
- 검색 엔진 크롤러의 한계: 일부 검색 엔진 크롤러는 JavaScript를 실행하여 동적으로 생성된 콘텐츠를 크롤링할 수 있지만, 모든 크롤러가 그렇지는 않습니다. 따라서 일부 검색 엔진은 초기 HTML 페이지에 포함된 콘텐츠만 인식할 수 있을 수 있습니다.
- 인덱싱의 지연: 동적으로 생성된 콘텐츠는 초기에는 HTML에 포함되지 않기 때문에 검색 엔진이 해당 콘텐츠를 인덱싱하는 데 시간이 걸릴 수 있습니다. 이로 인해 새로운 콘텐츠가 검색 결과에 나타나는 데 지연이 발생할 수 있습니다.
- 메타 데이터 제한: CSR에서는 페이지의 메타 데이터를 동적으로 변경하는 것이 일반적입니다. 그러나 일부 검색 엔진은 페이지를 크롤링할 때 초기 HTML에 포함된 메타 데이터만 사용할 수 있을 수 있습니다. 따라서 동적으로 변경된 메타 데이터가 검색 결과에 반영되지 않을 수 있습니다.
Next.js VS React
Next.js를 사용하지 않는 React로 만들어진 어플리케이션은 대부분 CSR방식으로 렌더링 되는걸로 알려져 있다.
여기서 프로젝트의 목적에 따라 CSR방식 이외에도 SSR의 방식을 사용할 수도 있는데, 이것이 바로 Next.js이고 React를 기반으로 만들어진 프레임워크다.
Next.js는 위쪽에서 언급한 SSR방식과 CSR방식을 모두 사용할 수 있다.
따라서 프로젝트 내에서 서버 컴포넌트와 클라이언트 컴포넌트 모두 사용할 수 있다.
이 둘의 동작에서 대표적인 차이를 정리하면 아래와 같다.
React - CSR
- 서버에서 초기 HTML 제공하지 않음:
React CSR에서는 초기 페이지 로딩 시 빈 HTML 페이지가 먼저 로드됩니다. 그 후에 JavaScript가 로드되고, 클라이언트 측에서 React 앱이 실행되어 UI가 동적으로 렌더링됩니다.- SEO 문제:
초기 HTML이 비어있기 때문에 검색 엔진은 페이지 콘텐츠를 인덱싱하기 어려울 수 있습니다. 이는 CSR의 주요 단점 중 하나입니다.
Next.js -SSR
- 서버 측 렌더링(SSR):
Next.js에서는 초기 페이지 로딩 시 서버 측에서 React 컴포넌트를 렌더링하여 완전한 HTML 페이지를 생성합니다. 따라서 검색 엔진이 페이지 콘텐츠를 쉽게 인덱싱할 수 있습니다. 초기 로딩 속도도 빠르며 SEO에 유리합니다.- 클라이언트 측 렌더링(CSR):
이후 페이지 간 이동이나 사용자 상호작용에 따라 클라이언트 측에서 React가 실행되고, CSR과 유사한 방식으로 동적으로 UI가 업데이트됩니다.- 코드 분할 및 최적화:
Next.js는 자동 코드 분할을 제공하여 페이지 별로 필요한 JavaScript 코드만 전송하여 초기 로딩 속도를 최적화합니다.- 간편한 개발 경험:
Next.js는 파일 시스템 기반의 라우팅 및 페이지 생성을 제공하여 개발자가 페이지를 관리하고 구성하기 쉽습니다.
- 차이 요약
-- React : 초기에 비어있는 HTML 페이지를 불러옴 -> 이후에 JavaScript를 사용하여 동적으로 UI를 렌더링
-- Next.js : 초기에 완전한 HTML 페이지를 서버에서 렌더링 -> 이후에는 클라이언트 측에서 동적으로 업데이트 -> SEO(Search Engine Optimization, 검색엔진최적화) 개선과 초기 로딩 속도 향상에 큰 장점
