
SSR vs CSR: 우리 프로젝트에 맞는 선택은?
웹 애플리케이션의 성능과 사용자 경험(UX)을 결정짓는 가장 중요한 요소 중 하나는 바로 렌더링 방식입니다. 최근 React, Next.js와 같은 프레임워크가 인기를 끌면서 SSR과 CSR에 대한 논의는 더욱 활발해졌습니다.
SSR (Server-Side Rendering)이란?
SSR은 사용자가 페이지를 요청할 때마다 서버에서 완전히 렌더링된 HTML 파일을 생성하여 브라우저에 전달하는 방식입니다.
SSR의 작동 방식
- 사용자가 웹사이트를 요청합니다.
- 서버는 즉시 렌더링 가능한 HTML 파일을 만듭니다. (데이터 포함)
- 브라우저는 서버로부터 받은 HTML을 즉시 화면에 그립니다.
- 브라우저가 자바스크립트 파일을 다운로드하고 실행(Hydration)하여 인터랙티브한 상태가 됩니다.
SSR의 장점
- 빠른 초기 로딩 속도 (FCP): 사용자가 빈 화면을 보는 시간이 짧습니다.
- 최적의 SEO: 검색 엔진 로봇이 완성된 HTML 데이터를 완벽하게 크롤링할 수 있습니다.
- 보안: API 키 등 민감한 정보를 서버에서만 처리할 수 있습니다.
SSR의 단점
- 서버 부하: 매 요청마다 서버에서 렌더링을 처리해야 하므로 서버 자원이 많이 필요합니다.
- TTV와 TTI의 간극: 화면은 보이지만 자바스크립트가 로딩될 때까지 클릭 등의 동작이 안 될 수 있습니다.
CSR (Client-Side Rendering)이란?
CSR은 브라우저가 최소한의 HTML 파일을 받은 후, 클라이언트(브라우저)에서 자바스크립트를 사용하여 페이지를 렌더링하는 방식입니다.
CSR의 작동 방식
- 사용자가 웹사이트를 요청합니다.
- 서버는 빈 HTML 파일과 자바스크립트 링크를 보냅니다.
- 브라우저는 자바스크립트 파일을 다운로드합니다.
- 자바스크립트가 실행되면서 API로부터 데이터를 가져오고 화면을 그립니다.
CSR의 장점
- 후속 페이지 로딩 속도: 첫 로딩 이후에는 바뀐 부분만 업데이트하므로 전환이 매우 빠릅니다.
- 서버 부하 분산: 렌더링 책임이 사용자 기기로 넘어가므로 서버 비용을 아낄 수 있습니다.
- 앱과 같은 경험: 깜빡임 없는 매끄러운 화면 전환이 가능합니다.
CSR의 단점
- 느린 초기 로딩: 자바스크립트 파일이 크면 사용자는 오랫동안 로딩 화면만 봐야 합니다.
- SEO의 어려움: 빈 HTML만 보내기 때문에 검색 엔진이 내용을 파악하기 어려울 수 있습니다. (최근 구글 등은 개선됨)
언제 무엇을 선택해야 할까?
| SSR이 유리한 경우 | CSR이 유리한 경우 |
|---|---|
| SEO가 매우 중요한 마케팅 홈페이지 | 사용자 로그인이 필수인 대시보드 |
| 초기 로딩 속도가 중요한 뉴스/블로그 | 복잡한 UI 인터랙션이 많은 데이터 도구 |
| 사용자의 네트워크 환경이 열악할 때 | 관리자 페이지, 인트라넷 시스템 |
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) 등 더 다양한 전략들이 나오고 있으니, 프로젝트에 가장 적합한 조합을 찾아보는 것을 추천합니다.
