렌더링 전략(CSR/SSR/SSG)

학습 목표

백엔드에서 제공하는 API 응답이 같은 화면에서 다르게 보이는 이유를 판단하고, 어떤 렌더링 방식이 언제 유리한지 스스로 고를 수 있습니다.

1) 렌더링 방식 개념

CSR(Client-Side Rendering)

초기 HTML은 최소한의 틀로 전달되고, 브라우저가 JavaScript로 데이터를 받아 화면을 완성합니다. 상호작용이 많은 화면에서 자주 사용됩니다.

SSR(Server-Side Rendering)

서버가 요청 단위로 HTML을 만들어 전달합니다. 초기 노출 속도와 SEO 관점에서 유리한 페이지에서 자주 사용됩니다. 서버 렌더링 부하와 캐시 전략을 함께 설계해야 합니다.

SSG(Static Site Generation)

빌드 시 HTML을 미리 만들어 배포합니다. 변경이 적고 공개 페이지 성격이 강한 화면에서 유리합니다.

2) 렌더링 방식 선택 기준

렌더링은 단순히 “빠른 화면 생성 방식”이 아니라 “데이터를 어떻게 다루는지”로 보는 것이 중요합니다.

1. 실시간성/개인화가 강한가요?
   • 사용자별 데이터가 자주 바뀌면 SSR/CSR 쪽이 자연스럽습니다.
2. 초기 노출이 중요하고 변화가 적은가요?
   • 공개/공지/랜딩 성격이면 SSG가 유리합니다.
3. 권한/토큰/민감 데이터가 개입하나요?
   • 클라이언트 개인화 처리 방식과 함께 SSR의 캐시 정책을 같이 봐야 합니다.
4. 캐시 재검증/무효화 비용이 부담되나요?
   • 화면 일관성 기준에 맞는 정책이 가능한 방식을 선택합니다.

3) 운영 시 주의 포인트

• 모든 방식에서 초기 렌더와 최종 인터랙션 가능 시점을 분리해 측정해야 합니다.
• API 실패 시 폴백 UI(빈 상태, 에러 상태, 재시도)가 없다면 사용자 신뢰가 떨어집니다.
• 캐시와 무효화 정책은 렌더링 방식과 분리해 설계할 수 없습니다.
• 재요청 빈도, 무효화 시점, 오래된 데이터 허용 범위를 함께 정의해야 합니다.

4) Next.js(App Router)와의 연결

App Router에서는 라우트 단위로 렌더링 성격이 드러납니다. 여기서는 “무엇이 달라지는지”를 먼저 기억하고, 구체 구현(서버/클라이언트 경계, 라우트 분기)은 다음 문서에서 이어서 정리합니다.

다음 문서: Next.js(App Router)로의 연결