🌳 렌더링의 방식
CSR(클라이언트 사이드 렌더링)과 SSR(서버 사이드 렌더링)은 웹 애플리케이션에서 페이지를 어떻게 렌더링하는지에 대한 접근 방식이다.
🌱 CSR
CSR의 동작 방식은 다음과 같다.
- 클라이언트(웹 브라우저)에서 자바스크립트를 사용하여 페이지를 렌더링한다.
- 초기 요청 시에는 서버에서 필요한 HTML, CSS 및 JavaScript 파일을 제공한다.
- 웹 브라우저에서 JavaScript 파일을 다운로드하고 실행하여 페이지를 동적으로 렌더링한다.
- 데이터는 API 요청을 통해 서버에서 가져와 페이지를 업데이트한다.
이에 따른 장점은 다음과 같다.
- 사용자의 상호작용에 따라 응답하는 페이지를 구축할 수 있다.
- 클라이언트 측에서 라우팅을 처리할 수 있어 부드러운 전환 효과를 기대할 수 있다.
🌱 SSR
SSR의 동작 방식은 다음과 같다.
- 서버에서 페이지의 초기 렌더링을 처리하여 완전한 HTML을 생성한다.
- 초기 요청 시에 서버에서 필요한 데이터를 가져와 페이지에 포함시킨다.
- 완전한 HTML 페이지가 클라이언트에게 제공되고, 웹 브라우저는 이를 받아 표시한다.
- 페이지에 필요한 데이터를 가져오는 추가적인 API 요청은 필요하지 않다.
이에 따른 장점은 다음과 같다.
- 빠른 초기 로딩 속도를 가진다.
- 검색 엔진 최적화(Search Engine Optimization)가 유리하다.
🌳 Next.js의 필요성
🔒 React의 렌더링 특성
React는 자바스크립트와 마찬가지로 CSR을 방식을 사용한다.
React로 개발된 SPA는 빌드 과정에서 클라이언트 측에서 실행될 자바스크립트 파일들이 번들링되어 bundle.js와 같은 파일로 만들어진다. 서버 측에서는 이러한 자바스크립트 파일을 로드하는 HTML만을 전달하게 되고, 서버에서 전달받는 HTML은 비어있게 된다. 빈 HTML을 받아오는데도 불구하고 화면이 예상대로 출력되는 이유는 브라우저가 bundle.js를 해석하여 화면을 렌더링하기 때문이다.
결과적으로 bundle.js는 검색 엔진 최적화에 관여되지 않게 되고, 검색 엔진은 최종적으로 렌더링되는 DOM 결과물만을 참고하게 된다. 따라서 CSR는 검색 엔진 최적화 작업이 어려워진다는 치명적인 단점이 존재하는 것이다.
🔑 Next.js
위 문제를 해결하기 위해서는 서버 측에서 렌더링이 가능하도록 하여 완성된 HTML 파일을 받아오는 작업이 필요하다. Next.js는 이를 가능하게 해주는 프레임워크이다. Next.js를 사용하면 React로 구현한 자바스크립트 코드를 HTML로 변환해서 서버가 내려준다.
아래 명령어를 통해 Next.js를 설치한다.
npm install next@latest react@latest react-dom@latest그리고 package.json 파일에 아래 코드를 추가한다.
{
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start",
"lint": "next lint"
}
}한편, Next.js는 "파일 기반 라우팅 방식"을 사용한다. 즉, 프로젝트 내의 각 페이지마다 개별적인 파일을 생성하고 해당 파일이 경로에 맵핑되는 방식으로 동작한다. 그러므로 "pages"라는 디렉토리를 만들어 파일을 작성해야 한다.
이후 아래 명령어를 통해 실행한다.
npm run dev🌳 Next.js의 렌더링과 라우팅
🌱 Rendering
Next.js는 Client-side의 자바스크립트 파일로 HTML을 생성하는 것이 아니라, Pre-rendering 방식을 취하여 모든 페이지에 대해 HTML 파일을 미리 생성한다. 이것은 각 페이지에 대한 미리 렌더링된 HTML 파일을 생성하고, 서버가 이를 브라우저에 전송하여 페이지를 빠르게 로드할 수 있게 한다. Next.js는 Static Site Generation (SSG) 방식과 Server-side Rendering (SSR) 방식의 두 가지 형태의 Pre-rendering 방식을 제공한다.
🧩 Static Site Generation
Next.js의 Pre-rendering의 기본값이다. 미리 렌더링된 HTML 파일을 빌드 타임에 생성하며, 각 페이지에 대한 데이터를 미리 불러와 HTML 파일에 포함시키고, 재사용한다. 이 방식은 페이지를 최초 로딩 시간을 매우 단축시키며, 검색 엔진 최적화를 용이하게 한다. 또한 CDN 캐시를 이용해 더욱 빠르게 페이지를 제공할 수 있다. 다만 매 업데이트마다 다시 빌드 후 배포해야 하므로, 내용이 거의 변하지 않는 웹사이트에 적합하다.
🧩 Server-side Rendering
브라우저의 요청에 대해 서버에서 동적으로 페이지를 렌더링하여 HTML 파일을 생성한다. 이 방식은 매 요청마다 서버에서 데이터를 불러와 페이지를 생성하기 때문에, 최신 상태의 데이터를 노출할 수 있다. 다만 서버를 거쳐 렌더링되기 때문에 SSG 방식에 비해 페이지 로딩 시간이 길어질 수 있다.
🌱 Routing
🧩 파일 기반 라우팅
리액트에서 사용했던 코드 기반 라우팅과는 달리, Next.js는 파일 기반의 라우팅을 지원한다. 페이지 경로는 페이지 파일의 위치와 파일 이름을 기반으로 생성된다.
대표적인 예로 Next.js의 "pages" 디렉토리가 있다. 이 디렉토리에는 프로젝트의 각 페이지에 해당하는 파일들이 위치하며, 파일의 이름과 경로가 URL 경로와 일치하게 된다.
예를 들어, "pages" 디렉토리에 "about.js" 파일을 생성한다면 "/about" 경로에 해당하는 페이지를 정의한 것이 된다. 만약, 추가적인 경로 없이 기본 페이지에 정의하려면 "index.js"라는 파일을 생성해 코드를 작성하면 된다.
🧩 라우팅 관련 모듈
이 외에도 'next/router' 모듈을 사용하여 동적인 라우팅을 구현할 수 있다. next/router 모듈은 클라이언트 측에서 라우팅을 처리하는 모듈이다. next/router 모듈은 useRouter 훅을 제공하여 현재 경로 정보와 경로 변경을 처리할 수 있는 메서드를 제공한다. 이 훅을 사용하여 페이지를 변경하고, 브라우저의 주소 표시줄을 업데이트하고, 브라우저의 뒤로 가기 및 앞으로 가기 버튼을 지원할 수 있다.
이와 비슷하게, 'next/link' 모듈은 클라이언트 측에서의 내부 링크 처리를 위한 모듈이다. next/link 모듈은 Link 컴포넌트를 제공하여 페이지 간의 링크를 생성할 수 있다. 이 컴포넌트를 사용하면 페이지 이동 시 자동으로 데이터를 불러올 수 있고, 브라우저 캐시를 이용하여 페이지 이동 속도를 높일 수 있다.
next/router 모듈과 next/link 모듈은 모두 Client-side Rendering으로 동작한다. 이는 페이지 전환 시 페이지를 서버로부터 다시 가져오는 대신 브라우저에서 페이지를 렌더링하는 방식으로 작동한다. 따라서 페이지가 실시간으로 업데이트되고, 더 빠르게 사용자 상호 작용을 처리할 수 있다.
