이번 글에서는 2가지 렌더링 방식인 SSR(Server Side Rendering)과 CSR(Client Side Rendering)의 개념, 차이점, 동작 방식, 그리고 어떤 상황에서 어떤 방식을 선택해야되는지를 살펴 보겠습니다.
웹 애플리케이션을 개발할 때 SSR(Server Side Rendering) 과 CSR(Client Side Rendering) 은 반드시 이해해야 할 핵심 개념입니다. 특히 Next.js 같은 현대적인 프레임워크는 두 방식을 모두 지원하기 때문에, 각각의 동작 원리와 차이를 명확히 이해하면 프로젝트 구조와 렌더링 전략을 훨씬 효율적으로 설계할 수 있습니다.
SSR이란? (Server Side Rendering)
서버에서 HTML을 완성해 전달하는 방식
SSR(Server Side Rendering) 은 사용자가 페이지를 요청하면, 서버가 해당 페이지의 HTML을 렌더링한 뒤 완성된 형태로 클라이언트에 전달하는 방식입니다.
즉, 브라우저는 서버로부터 완성된 HTML을 받자마자 즉시 화면을 표시할 수 있습니다.
Next.js의 getServerSideProps() 함수가 바로 SSR을 구현하는 대표적인 예입니다.
아래는 간단한 예시 코드입니다.
// frontend/pages/index.tsx
import { GetServerSideProps } from "next";
export default function Home({ data }: { data: string }) {
return <div>{data}</div>;
}
export const getServerSideProps: GetServerSideProps = async () => {
const res = await fetch("http://localhost:8000/api/hello");
const data = await res.text();
return { props: { data } };
};위 예시는 사용자가 / 경로로 접근할 때마다 서버가 데이터를 가져와 렌더링된 HTML을 즉시 생성해 클라이언트에 전달합니다.
SSR의 장점
- ✅ SEO에 유리: 완성된 HTML이 바로 제공되므로 검색엔진이 쉽게 인덱싱 가능
- ✅ 첫 페이지 로딩 속도 개선: 초기 화면 표시까지의 시간이 짧음
- ✅ 보안성 향상: 클라이언트에 노출되지 않는 서버 데이터 처리 가능
SSR의 단점
- ❌ 서버 부하 증가: 요청마다 HTML을 새로 렌더링해야 함
- ❌ 페이지 전환 속도 느림: 클라이언트에서 페이지 이동 시에도 서버 요청이 반복됨
- ❌ 캐싱 전략 복잡: 서버단 렌더링 결과를 캐싱하지 않으면 성능 저하
CSR이란? (Client Side Rendering)
브라우저에서 렌더링하는 방식
CSR(Client Side Rendering) 은 서버에서 HTML 골격만 전달하고, 실제 콘텐츠는 브라우저가 JavaScript를 실행하여 데이터를 비동기적으로 가져온 후 화면을 구성하는 방식입니다.
React, Vue, Angular 등의 프레임워크가 기본적으로 CSR 방식을 사용합니다.
Next.js에서도 useEffect를 사용하면 CSR 방식으로 데이터를 렌더링할 수 있습니다.
// frontend/pages/dashboard.tsx
import { useEffect, useState } from "react";
import axios from "axios";
export default function Dashboard() {
const [data, setData] = useState<string>("");
useEffect(() => {
axios.get("http://localhost:8000/api/dashboard")
.then((res) => setData(res.data))
.catch(() => setData("데이터를 불러오지 못했습니다."));
}, []);
return <div>{data}</div>;
}
이 경우, 브라우저는 처음에는 비어있는 HTML을 표시하고, JavaScript가 실행된 후 데이터를 불러와 최종적으로 화면을 완성합니다.
CSR의 장점
- ✅ 빠른 페이지 전환: 이미 로드된 앱 내에서 라우팅이 즉시 수행
- ✅ 서버 부하 감소: 서버는 HTML이 아닌 API 응답만 담당
- ✅ 풍부한 인터랙션: SPA(Single Page Application)에 적합
CSR의 단점
- ❌ SEO에 불리: 초기 HTML이 비어있기 때문에 검색엔진 인덱싱 어려움
- ❌ 초기 로딩 지연: JS 번들 다운로드 및 실행 후 렌더링됨
- ❌ JS 의존성 높음: JS 오류 시 페이지 전체가 깨질 가능성
SSR과 CSR의 구조적 차이
아래는 Next.js + FastAPI + PostgreSQL 기반의 프로젝트 구조 예시입니다.
PORTFOLIO-APP/
├── backend/
│ ├── routes/
│ ├── models/
│ ├── schemas/
│ ├── main.py
│ └── db.py
│
├── frontend/
│ ├── pages/
│ ├── components/
│ ├── lib/
│ └── styles/
│
└── docker-compose.yml
이 구조에서 SSR과 CSR은 각각 다음과 같이 작동합니다.
| 구분 | SSR | CSR |
|---|---|---|
| 데이터 요청 | 서버(getServerSideProps)에서 FastAPI 호출 | 브라우저(axios)에서 FastAPI 호출 |
| 렌더링 위치 | Next.js 서버에서 HTML 생성 | 브라우저에서 JS로 DOM 조작 |
| SEO | 우수 | 상대적으로 불리 |
| 초기 속도 | 빠름 | 느림 |
| 인터랙션 | 낮음 | 높음 |
SSR과 CSR의 병행 전략
현대적인 프레임워크인 Next.js는 SSR과 CSR을 혼합(Hybrid Rendering) 하여 사용할 수 있습니다.
예를 들어, 다음과 같은 전략이 가능합니다.
1. 메인 페이지는 SSR로, 내부 페이지는 CSR로
- 홈화면이나 블로그 포스트 등 SEO가 중요한 페이지는 SSR 적용
- 로그인 후 대시보드, 사용자 설정 등 사용자 중심의 동적 페이지는 CSR 적용
2. getStaticProps를 통한 SSG 활용
- 변하지 않는 데이터는 SSG(Static Site Generation) 로 미리 빌드해두면 더 빠른 응답이 가능
- 예: 회사 소개, 공지사항, 블로그 리스트 페이지
SSR vs CSR 선택 가이드
| 고려 항목 | SSR이 유리한 경우 | CSR이 유리한 경우 |
|---|---|---|
| SEO | ✅ 검색 노출이 중요할 때 | ❌ 내부 사용자 중심 서비스 |
| 초기 속도 | ✅ 빠른 첫 화면 필요 | ❌ 초기 JS 로딩 부담 |
| 인터랙션 | ❌ 단순 UI | ✅ 동적, 실시간 UI |
| 서버 리소스 | ❌ 많음 | ✅ 적음 |
| 데이터 변경 빈도 | ✅ 빈번한 변경 반영 가능 | ❌ 클라이언트 갱신 필요 |
결론
SSR과 CSR은 각각 장단점이 명확한 렌더링 전략입니다.
Next.js를 활용하면 두 방식을 상황에 맞게 조합하여 사용할 수 있으며,
FastAPI 백엔드와의 연동을 통해 데이터 fetching 전략을 최적화할 수 있습니다.
- SEO가 중요한 페이지 → SSR
- 사용자 경험이 중요한 대화형 페이지 → CSR
- 변경이 적은 정적 콘텐츠 → SSG
이처럼 렌더링 전략을 명확히 구분하면,
개발 효율성과 성능, 유지보수성 모두를 향상시킬 수 있습니다.