SSR vs CSR: 우리 프로젝트에 맞는 선택은?

웹 애플리케이션의 성능과 사용자 경험(UX)을 결정짓는 가장 중요한 요소 중 하나는 바로 렌더링 방식입니다. 최근 React, Next.js와 같은 프레임워크가 인기를 끌면서 SSR과 CSR에 대한 논의는 더욱 활발해졌습니다.

SSR (Server-Side Rendering)이란?

SSR은 사용자가 페이지를 요청할 때마다 서버에서 완전히 렌더링된 HTML 파일을 생성하여 브라우저에 전달하는 방식입니다.

SSR의 작동 방식

1. 사용자가 웹사이트를 요청합니다.
2. 서버는 즉시 렌더링 가능한 HTML 파일을 만듭니다. (데이터 포함)
3. 브라우저는 서버로부터 받은 HTML을 즉시 화면에 그립니다.
4. 브라우저가 자바스크립트 파일을 다운로드하고 실행(Hydration)하여 인터랙티브한 상태가 됩니다.

SSR의 장점

• 빠른 초기 로딩 속도 (FCP): 사용자가 빈 화면을 보는 시간이 짧습니다.
• 최적의 SEO: 검색 엔진 로봇이 완성된 HTML 데이터를 완벽하게 크롤링할 수 있습니다.
• 보안: API 키 등 민감한 정보를 서버에서만 처리할 수 있습니다.

SSR의 단점

• 서버 부하: 매 요청마다 서버에서 렌더링을 처리해야 하므로 서버 자원이 많이 필요합니다.
• TTV와 TTI의 간극: 화면은 보이지만 자바스크립트가 로딩될 때까지 클릭 등의 동작이 안 될 수 있습니다.

CSR (Client-Side Rendering)이란?

CSR은 브라우저가 최소한의 HTML 파일을 받은 후, 클라이언트(브라우저)에서 자바스크립트를 사용하여 페이지를 렌더링하는 방식입니다.

CSR의 작동 방식

1. 사용자가 웹사이트를 요청합니다.
2. 서버는 빈 HTML 파일과 자바스크립트 링크를 보냅니다.
3. 브라우저는 자바스크립트 파일을 다운로드합니다.
4. 자바스크립트가 실행되면서 API로부터 데이터를 가져오고 화면을 그립니다.

CSR의 장점

• 후속 페이지 로딩 속도: 첫 로딩 이후에는 바뀐 부분만 업데이트하므로 전환이 매우 빠릅니다.
• 서버 부하 분산: 렌더링 책임이 사용자 기기로 넘어가므로 서버 비용을 아낄 수 있습니다.
• 앱과 같은 경험: 깜빡임 없는 매끄러운 화면 전환이 가능합니다.

CSR의 단점

• 느린 초기 로딩: 자바스크립트 파일이 크면 사용자는 오랫동안 로딩 화면만 봐야 합니다.
• SEO의 어려움: 빈 HTML만 보내기 때문에 검색 엔진이 내용을 파악하기 어려울 수 있습니다. (최근 구글 등은 개선됨)

언제 무엇을 선택해야 할까?

Next.js: 두 마리 토끼를 잡는 방법

최신 Next.js (App Router)에서는 페이지 단위가 아니라 컴포넌트 단위로 SSR과 CSR을 혼용할 수 있습니다.

// app/products/page.js (기본적으로 Server Component - SSR)
export default async function ProductPage() {
  const products = await fetchProducts();
  
  return (
    <div>
      <h1>상품 목록</h1>
      <ProductList initialData={products} />
      {/* 인터랙션이 필요한 부분만 Client Component로 분리 */}
      <CartButton /> 
    </div>
  );
}

SSR과 CSR은 각기 다른 목적과 장단점을 가지고 있습니다. 사용자의 환경과 서비스의 성격에 맞는 최적의 렌더링 방식을 선택하여 최고의 웹 서비스를 만들어 보세요. 최근에는 정적 생성(SSG)이나 증분 정적 재생성(ISR) 등 더 다양한 전략들이 나오고 있으니, 프로젝트에 가장 적합한 조합을 찾아보는 것을 추천합니다.