[Next.js] 3가지 렌더링 SSR, CSR, SSG 이해하기: 장단점 분석

웹 애플리케이션을 만들 때 가장 중요한 것 중 하나는 사용자에게 컨텐츠를 어떻게 전달할 것인가이다. 웹 페이지를 렌더링하는 방법에는 여러 가지가 있고, 각 방법마다의 장점과 단점이 있다. 이 글에서는 웹 페이지 렌더링의 세 가지 주요 방법인 SSR(Server Side Rendering), CSR(Client Side Rendering), 그리고 SSG(Static Site Generation)에 대해 알아보고, 각각의 방법이 언제 사용되는지, 그리고 그 방법의 장단점은 무엇인지를 초보자도 이해할 수 있도록 상세하게 설명할 것이다.

SSR(Server Side Rendering) 이해하기

SSR(Server Side Rendering)은 웹 페이지를 서버에서 렌더링하는 방식을 의미한다.

사용자가 웹 페이지에 접속 요청을 하면, 서버는 해당 페이지의 내용을 완전히 렌더링하여 사용자의 웹 브라우저로 HTML 형식의 완성된 페이지를 전송한다. 이렇게 되면 브라우저는 추가적인 JavaScript의 실행 없이 페이지를 바로 표시할 수 있게 된다.

SSR(Server Side Rendering)의 작동 과정

1. 요청: 사용자가 웹 페이지에 접속을 요청하면, 이 요청은 서버에 전달된다.
2. 데이터 획득: 서버는 데이터베이스나 API를 통해 웹 페이지에 필요한 데이터를 가져온다.
3. 렌더링: 서버는 가져온 데이터를 사용하여 웹 페이지를 완전히 그린다.
4. 응답: 서버는 그려진 웹 페이지를 사용자에게 보내준다.
5. 표시: 사용자의 브라우저는 서버로부터 받은 완성된 웹 페이지를 화면에 표시한다.

SSR 예시: Next.js를 사용한 간단한 예제

Next.js는 SSR을 쉽게 구현할 수 있는 도구를 제공한다. 아래는 Next.js를 사용하여 간단한 SSR을 적용한 웹 페이지의 예시이다.

1. 데이터를 가져오는 함수 작성: 먼저, 서버에서 데이터를 가져오는 함수를 작성한다. 이 예시에서는 임의의 데이터를 반환하는 함수를 사용한다.

function fetchData() {
  return {
    title: "Next.js와 SSR",
    content: "Next.js를 사용한 서버 사이드 렌더링에 대한 이해"
  };
}

2. 페이지 렌더링: Next.js에서는 getServerSideProps라는 함수를 사용하여 서버에서 데이터를 가져오고, 이 데이터를 페이지 컴포넌트에 전달할 수 있다.

export async function getServerSideProps() {
  const data = fetchData();
  return {
    props: { data }
  };
}

function HomePage({ data }) {
  return (
    <div>
      <h1>{data.title}</h1>
      <p>{data.content}</p>
    </div>
  );
}

export default HomePage;

위의 예제에서, getServerSideProps는 서버에서만 실행되며, 이 함수를 통해 가져온 데이터는 HomePage 컴포넌트로 전달된다. 따라서 사용자는 HomePage 컴포넌트가 렌더링된 결과를 바로 볼 수 있다.

이처럼 Next.js를 사용하면 간단한 코드 몇 줄만으로 SSR을 적용할 수 있다. 웹 페이지의 로딩 속도를 향상시키고, SEO를 개선하려는 개발자들에게 SSR은 매우 유용한 도구가 될 수 있다.

SSR(Server Side Rendering)의 장점과 단점

SSR은 웹 애플리케이션에서 페이지를 서버에서 렌더링하는 방식이다. 이 방식은 특정 상황에서 큰 이점을 제공하지만, 몇몇 단점도 있다. 이를 이해하면 SSR이 자신의 프로젝트에 적합한지 판단하기 쉽다.

SSR의 장점

1. 빠른 초기 페이지 로딩 시간: 사용자는 필요한 모든 데이터와 함께 렌더링된 페이지를 바로 받기 때문에 초기 페이지 로딩 속도가 빠르다. 이는 사용자 경험(UX)을 크게 향상시킨다.
2. SEO 최적화: 검색 엔진 크롤러는 JavaScript가 실행되지 않는 환경에서도 서버에서 렌더링된 페이지의 내용을 쉽게 인식하고 색인화할 수 있다. 이로 인해 SEO 효과가 향상된다.
3. 효과적인 캐싱: SSR의 경우, 한 번 렌더링된 HTML 페이지를 캐시에 저장해두고 동일한 요청이 올 경우 캐시된 데이터를 사용하여 빠르게 응답할 수 있다. 예를 들면, 인기 있는 블로그 게시글이나 변경이 자주 일어나지 않는 고정된 페이지 등은 한 번 렌더링되면 그 결과를 캐시에 저장하여 후속 요청에 대해 빠른 응답이 가능하게 된다. 이로 인해 서버의 부하가 줄어들며 사용자에게는 빠른 로딩 시간으로 페이지를 제공할 수 있게 된다.
4. 브라우저 호환성: JavaScript 기반의 프론트엔드 프레임워크를 사용할 경우, 구형 브라우저에서는 지원하지 않는 JS 기능을 사용할 수 있다. SSR을 사용하면, 서버에서 페이지를 렌더링하고 완성된 HTML을 클라이언트에 제공하기 때문에 클라이언트 측에서의 JavaScript 실행에 의존하지 않게 된다. 이는 구형 브라우저에서도 페이지가 제대로 표시되도록 도와준다.

SSR의 단점

1. 서버 부담: 사용자마다 페이지를 렌더링해야 하므로 서버에 추가 부담이 생긴다. 대규모 트래픽에서는 서버의 부하가 크게 증가할 수 있다.
2. 개발 복잡성: 클라이언트와 서버 간의 상호 작용이 더 복잡해질 수 있다. 이는 개발 및 디버깅을 복잡하게 만들 수 있다.
3. TTFB(Time to First Byte) 지연: 서버에서 페이지를 렌더링하는 시간이 추가되므로, 첫 번째 데이터가 사용자에게 도달하는 시간이 약간 늘어날 수 있다.

CSR(Client Side Rendering) 이해하기

CSR(Client Side Rendering)은 서버에서 페이지를 미리 렌더링하는 것이 아니라, 클라이언트(즉, 사용자의 웹 브라우저)에서 페이지를 렌더링하는 방식이다.

사용자가 웹 페이지에 접속하면, 서버는 초기 HTML 구조를 제공하지 않고 JavaScript 파일만을 보내준다. 브라우저는 이 JavaScript를 실행하여 필요한 데이터를 API 호출 등을 통해 가져온 후, 웹 페이지를 구성한다.

CSR(Client Side Rendering)의 작동 과정

1. 요청: 사용자가 웹 페이지에 접속을 요청하면, 초기 HTML은 거의 비어 있다. 대신 필요한 자바스크립트와 CSS가 포함되어 있다.
2. 다운로드: 사용자의 브라우저는 필요한 자바스크립트 파일과 CSS를 다운로드한다.
3. 렌더링: 한 번 자바스크립트가 다운로드되고 실행되면, 자바스크립트는 필요한 데이터를 API나 다른 외부 소스에서 가져옵니다. 그 후, 데이터를 기반으로 웹 페이지를 클라이언트 측에서 그린다.
4. 표시: 데이터가 브라우저에 도착하면, 웹 페이지는 사용자에게 그려진 내용을 화면에 표시한다.

이러한 방식은 초기 로딩 시간이 다소 길 수 있지만, 데이터나 뷰가 변경될 때 페이지 전체를 다시 로드하지 않고 변화된 부분만 업데이트하기 때문에 사용자 경험을 부드럽게 만들어 준다.

CSR을 사용할때 Next.js가 꼭 필요한가?

CSR을 구현할 때 React.js만 사용해도 충분한다. 그런데 Next.js를 사용하는 것은 React.js만 사용하는 것보다 몇 가지 큰 이점이 있다. 다음은 Next.js의 주요 특징 및 이점입니다:

1. 페이지 기반의 라우팅: Next.js는 파일과 폴더 구조를 기반으로 자동적인 라우팅을 제공한다. 따라서 별도의 라우터 설정 없이도 간편하게 페이지 간의 이동이 가능하다.
2. 빌트인 최적화: Next.js는 자동 코드 분할, 최적화된 이미지 처리, 글로벌 CSS 및 모듈 CSS 지원 등 다양한 최적화 기능을 내장하고 있다.
3. API 라우트: Next.js는 /pages/api 안에 API 라우트를 만들어 백엔드 로직을 간단하게 처리할 수 있다. 이를 통해 별도의 서버 없이도 API 요청을 처리할 수 있다.
4. 플러그인 및 커뮤니티 지원: Next.js는 다양한 플러그인과 확장 기능을 지원하며, 크고 활발한 커뮤니티로 인해 다양한 문제 해결과 리소스가 제공된다.

즉, CSR만 필요하다면 React.js만으로도 충분하겠지만, 웹 애플리케이션의 성장과 확장성, 다양한 렌더링 방식의 필요성, 최적화 기능 등을 고려한다면 Next.js를 사용하는 것이 많은 장점을 가지게 된다.

CSR 예시: Next.js를 사용한 간단한 예제

import { useEffect, useState } from 'react';

function HomePage() {
  const [data, setData] = useState({ title: '', content: '' });

  useEffect(() => {
    async function fetchData() {
      // 여기서 실제 데이터를 API 호출로 가져올 수 있다.
      // 예제에서는 setTimeout을 사용하여 비동기 처리를 시뮬레이션한다.
      const mockData = await new Promise(resolve => {
        setTimeout(() => {
          resolve({
            title: 'CSR로 렌더링된 제목',
            content: 'CSR로 렌더링된 내용이다.'
          });
        }, 1000);
      });
      setData(mockData);
    }

    fetchData();
  }, []);

  return (
    <div>
      <h1>{data.title}</h1>
      <p>{data.content}</p>
    </div>
  );
}

export default HomePage;

이 코드는 Next.js 프로젝트 내에서 CSR 방식으로 데이터를 불러와 렌더링하는 예제이다. useEffect와 useState는 React의 Hooks로, 컴포넌트의 상태 관리와 생명주기를 관리하는 데 사용된다.

코드에서 useEffect 내부의 fetchData 함수는 웹 페이지가 처음 로드될 때 한 번만 실행되어 비동기적으로 데이터를 가져온 후, 이를 상태로 설정한다. 이렇게 가져온 데이터는 그 후 컴포넌트에서 렌더링된다.

CSR(Client Side Rendering)의 장점과 단점

CSR(Client Side Rendering)은 모든 렌더링 작업이 브라우저(클라이언트 측)에서 이루어지는 방식을 말한다.

이러한 접근법은 웹 애플리케이션의 동적인 부분들을 처리하기에 유용하며, 특히 SPA(Single Page Application)와 같은 현대의 웹 애플리케이션에서 자주 사용된다.

CSR의 장점

1. 빠른 상호작용: 초기 로딩 후에는 모든 렌더링 리소스가 클라이언트에 로드되어 있기 때문에 사용자와의 상호작용이 매우 빠르다. 즉, 페이지 전환, 애니메이션 등의 UI 상호작용이 매끄럽게 진행된다.
2. 서버 부하 감소: 서버는 오직 정적 파일(JavaScript, CSS, HTML)만을 제공하면 되기 때문에, 렌더링에 대한 부하가 감소한다.
3. 프론트엔드와 백엔드의 분리: API를 통해 데이터를 가져오는 구조이기 때문에 프론트엔드와 백엔드의 개발이 분리될 수 있다. 이로 인해 동시에 개발이 진행될 수 있으며, 재사용성이 높은 컴포넌트 기반의 구조를 쉽게 구축할 수 있다.

CSR의 단점

1. 초기 로딩 지연: 클라이언트는 모든 자바스크립트 파일을 다운로드하고 실행해야 하기 때문에 초기 페이지 로딩 속도가 느릴 수 있다.
2. SEO 문제: 전통적인 웹 크롤러는 JavaScript 실행 없이 HTML 내용만을 스캔하기 때문에 CSR 방식으로 완전히 렌더링된 페이지의 내용을 인식하기 어려울 수 있다. 하지만 최근의 검색 엔진들은 이 문제를 해결하기 위해 자바스크립트를 실행할 수 있는 기능을 갖추고 있다.
3. 브라우저의 부하: 모든 렌더링 작업이 브라우저에서 이루어지기 때문에 낮은 사양의 기기나 브라우저에서는 성능 저하가 발생할 수 있다.
4. 보안 문제: 클라이언트 측에서 처리되는 코드는 사용자에게 완전히 노출되므로, 중요한 로직이나 데이터를 클라이언트 측에서 숨기기는 어렵다.

이러한 장점과 단점을 종합해 보면, CSR은 특정한 웹 애플리케이션에서 매우 효과적일 수 있지만, 사용하기 전에 그 애플리케이션의 요구 사항과 일치하는지 확인하는 것이 중요하다.

SSG(Static Site Generation) 이해하기

SSG(Static Site Generation)은 사전에 모든 웹페이지를 정적 파일로 생성하는 방식을 의미한다.

이렇게 생성된 웹페이지는 서버에 요청할 때마다 동일한 파일을 고객에게 제공한다. 이 방식은 블로그, 마케팅 웹사이트, 문서 사이트 등 내용이 자주 바뀌지 않는 웹사이트에 이상적이다.

SSG(Static Site Generation)의 작동 과정

1. 빌드 시간: 개발자가 웹사이트를 빌드하는 시점에, 모든 웹 페이지는 정적 파일로 사전에 생성된다. 이 때 필요한 데이터를 외부 소스(예: 데이터베이스, API)에서 가져와서 포함시킨다.
2. 요청: 사용자가 웹 페이지에 접속을 요청하면, 이 요청은 서버나 CDN에 전달된다.
3. 응답: 이미 생성된 정적 파일은 바로 사용자에게 제공된다. 추가적인 렌더링이나 데이터 획득 과정 없이 바로 파일을 받게 된다.
4. 표시: 사용자의 브라우저는 서버로부터 받은 정적 파일을 화면에 표시한다.

SSG 예시: Next.js를 사용한 간단한 예제

export async function getStaticProps() {
  const data = await fetchData(); // 외부 데이터를 가져오는 함수
  return {
    props: { data }
  };
}

function BlogPage({ data }) {
  return (
    <div>
      <h1>{data.title}</h1>
      <p>{data.content}</p>
    </div>
  );
}

export default BlogPage;

위 코드는 Next.js의 SSG 기능을 활용하여 블로그 페이지를 정적으로 생성하는 예시이다. getStaticProps 함수는 빌드 시점에 실행되어 데이터를 가져오고, 해당 데이터를 사용하여 정적 페이지를 생성한다.

SSG(Static Site Generation)의 장점과 단점

SSG의 장점

1. 빠른 로딩 속도: 이미 생성된 정적 파일을 제공하기 때문에 서버의 처리 시간이 필요 없으며, CDN을 통해 전 세계 어디서든 빠르게 컨텐츠를 제공할 수 있다.
2. SEO 최적화: 미리 생성된 정적 페이지는 웹 크롤러에게 잘 인식되므로 검색 엔진 최적화에 유리한다.
3. 낮은 서버 비용: 동적 처리가 필요 없기 때문에 서버의 부하가 줄어들며, 이로 인해 호스팅 비용이 절감될 수 있다.
4. 보안: 정적 파일만을 제공하므로 다양한 서버 측 공격에 대해 안전한다.

SSG의 단점

1. 빌드 시간: 큰 웹사이트의 경우 모든 페이지를 생성하는 데 시간이 오래 걸릴 수 있다.
2. 실시간 업데이트 한계: 내용이 바뀌면 웹사이트를 다시 빌드해야 한다. 따라서 실시간으로 데이터가 변경되는 애플리케이션에는 적합하지 않을 수 있다.
3. 동적 처리 제한: 사용자마다 다르게 동작해야하는 기능(예: 사용자 계정 기능)은 별도의 클라이언트 사이드 로직이 필요한다.

이렇게 SSG는 특정 상황과 요구 사항에 따라 매우 유용할 수 있다. 하지만, 애플리케이션의 특성과 필요한 기능을 고려하여 적절한 렌더링 방식을 선택하는 것이 중요하다.

웹 개발에서 렌더링은 매우 중요한 부분을 차지하고 있다. SSR, CSR, 그리고 SSG는 각각의 환경과 요구 사항에 따라 탁월한 성능을 발휘할 수 있다. 하나의 방법이 모든 상황에서 가장 좋다고 말할 수는 없다. 여러분이 개발하고자 하는 웹 사이트나 애플리케이션의 특성, 그리고 사용자의 요구 사항을 잘 파악하고, 이 글에서 소개한 세 가지 방법의 장단점을 고려하여 최적의 방법을 선택하는 것이 중요하다.