프론트엔드 렌더링 정리

HelloPong·2025년 10월 24일
공부렌더링프론트엔드

공부

목록 보기
37/39
post-thumbnail

🚀 프론트엔드 렌더링 정리 — SPA, CSR, SSR, SSG, ISR, PWA

웹을 개발하다 보면 SPA, CSR, SSR, SSG, ISR, PWA 같은 용어를 자주 접한다.
겉보기엔 비슷하지만, “언제”와 “어디서” 페이지를 렌더링하느냐에 따라 완전히 다르다.
이 글에서는 이 개념들을 하나의 흐름으로 정리한다.

🧩 1. SPA (Single Page Application)

한 개의 HTML로 시작해 화면을 동적으로 교체하는 웹앱 구조.
초기에 /index.html 한 장만 불러오고, 이후 라우팅은 브라우저가 직접 처리한다.

  • 대표 기술: React, Vue, Angular
  • 작동 원리: 페이지 이동 시마다 새로 요청하지 않고 JS가 DOM을 변경
  • 장점: 부드러운 화면 전환, 빠른 UX, 서버 요청 최소화
  • 단점: 첫 로딩 느림, SEO 약함, JS 번들 크기 큼

SPA는 구조 개념이다. 실제 화면은 CSR, SSR, ISR 등의 렌더링 방식으로 표시된다.

🧠 2. CSR (Client-Side Rendering)

브라우저에서 JS가 HTML을 그리는 방식.
서버는 빈 HTML + JS만 내려주고, 브라우저가 JS 실행 후 데이터를 불러와 화면을 만든다.

항목내용
렌더링 위치브라우저
HTML 생성 시점클라이언트 실행 시
서버 필요 여부❌ 정적 파일만으로 가능
초기 속도느림 (JS 실행 후 표시)
SEO약함
대표 예시CRA(Create React App), Vue CLI
  • 장점: 서버 부하 거의 없음, 빠른 인터랙션
  • 단점: 초기 로딩 느림, 검색 노출에 불리

대부분의 SPA는 CSR 기반으로 동작한다.

🏭 3. SSR (Server-Side Rendering)

요청이 들어올 때마다 서버가 HTML을 완성해서 전달.
브라우저는 이미 렌더링된 HTML을 즉시 표시한다.

항목내용
렌더링 위치서버
HTML 생성 시점요청 시마다
서버 필요 여부✅ 필요
초기 속도빠름
SEO강함
대표 예시Next.js, Nuxt.js

  • 장점

    • 첫 화면 즉시 표시 (빠른 LCP)
    • SEO 최적화
    • 사용자별 맞춤 데이터 가능

  • 단점

    • 서버 부하 증가
    • 캐싱 설계 복잡
    • 배포 구조 무거움

SSR은 매 요청마다 서버가 페이지를 다시 그린다. 즉 “주문 즉시 조리” 방식이다.

🧱 4. SSG (Static Site Generation)

배포 전에 HTML을 미리 만들어두는 방식.
사용자가 접속하면 이미 생성된 정적 HTML이 즉시 제공된다.

항목내용
렌더링 위치빌드 서버
HTML 생성 시점빌드 시점
서버 필요 여부❌ 불필요
초기 속도매우 빠름
SEO강함
대표 예시Gatsby, Next.js(SSG), Astro

  • 장점

    • 전 세계 CDN 캐시로 빠른 응답
    • 서버 없이 배포 가능 (S3, Netlify)
    • 비용 저렴

  • 단점

    • 데이터 변경 시 빌드 재실행 필요
    • 실시간 업데이트 불가

“미리 조리해 냉장고에 넣어둔 요리”와 같다.

🔁 5. ISR (Incremental Static Regeneration)

SSG의 단점을 개선한 방식.
기본적으로는 정적 페이지를 제공하지만, 일정 시간마다 백그라운드에서 새 HTML을 생성한다.

항목내용
렌더링 위치빌드 + 플랫폼 백엔드
HTML 생성 시점초기 빌드 + 주기적 재생성
서버 필요 여부⚙️ 플랫폼 지원(Vercel 등)
초기 속도SSG 수준으로 빠름
SEO강함
데이터 최신성주기적 갱신 가능

  • 장점

    • 빠른 응답 유지
    • 최신 데이터 자동 반영
    • 서버 부하 낮음

  • 단점

    • 완전 실시간 아님 (갱신 주기 의존)
    • 일부 플랫폼에서만 자동 지원

“냉장고 음식이 일정 시간이 지나면 자동으로 새로 조리되는 구조”와 같다.

⚙️ Next.js 기준 코드 예시

// SSR
export async function getServerSideProps() {
  const data = await fetch(...);
  return { props: { data } };
}

// SSG
export async function getStaticProps() {
  const data = await fetch(...);
  return { props: { data } };
}

// ISR
export async function getStaticProps() {
  const data = await fetch(...);
  return { props: { data }, revalidate: 60 }; // 60초마다 새로 생성
}

📱 6. PWA (Progressive Web App)

렌더링 방식이 아니라, 웹을 설치형 앱처럼 만드는 기술 세트.

  • 핵심 구성

    • manifest.json — 앱 이름, 아이콘, 시작화면 지정
    • service worker — 캐시, 오프라인, 푸시 기능 담당

  • 장점

    • 오프라인에서도 동작 가능
    • 홈화면 설치, 푸시 알림 가능
    • 백그라운드 동기화로 데이터 유실 방지

  • 단점

    • 브라우저 권한 제한 (특히 iOS)
    • 복잡한 캐시 전략 필요

PWA는 CSR/SSR/SSG 어느 방식과도 함께 사용할 수 있다.
특히 오프라인 기록 → 연결 시 동기화가 필요한 서비스(현장 기록, 구급일지 등)에 유용하다.

🔍 7. 요약 비교

방식생성 시점서버 필요속도SEO데이터 최신성대표 사용
CSR브라우저 실행 시❌느림약함실시간내부 대시보드
SSR요청 시✅빠름강함실시간검색, 상품
SSG빌드 시❌매우 빠름강함고정블로그, 소개
ISR빌드 + 주기적 재생성⚙️빠름강함주기적 최신뉴스, 리스트

🪜 8. 실무 사용 경향

방식실제 사용 비율대표 서비스
CSR약 40%관리자, 내부 시스템
SSR약 30%커머스, 포털, 검색 서비스
SSG약 15%기업 블로그, 문서
ISR약 10%뉴스·상품 리스트
PWA약 5%모바일·오프라인 현장 서비스

🚀 9. 핵심 정리 문장

  • SSR: 요청마다 서버가 새로 그림을 그린다.
  • SSG: 미리 그림을 그려 벽에 걸어둔다.
  • ISR: 걸어둔 그림을 일정 시간마다 새로 교체한다.
  • CSR: 사용자가 직접 브라우저에서 그림을 완성한다.
  • PWA: 그 그림을 오프라인에서도 볼 수 있게 한다.

⚙️ 프론트엔드 렌더링 전략 — CSR, SSR, ISR, PWA를 어떻게 섞을까

모던 프론트엔드에서는 한 가지 렌더링 방식만 쓰지 않는다.
서비스의 성격(로그인, 검색, 콘텐츠, 속도, 트래픽)에 따라
CSR + SSR + ISR + PWA를 조합해 최적의 사용자 경험과 서버 효율을 만든다.
이번 글에서는 그 조합의 원리와 실제 사용 패턴을 정리한다.

🧭 1. 왜 혼합이 필요한가?

각 방식은 장단점이 분명하다.

방식강점약점
CSR빠른 상호작용, 서버 부담 없음초기 로딩 느림, SEO 약함
SSR첫화면 빠름, SEO 강함서버 부하 큼
SSG/ISR빠르고 저비용데이터 최신성 한계
PWA오프라인, 설치형 UX브라우저 제약

서비스 전체를 하나로 고정하면 일부 화면은 과잉 설계가 된다.
예를 들어,

  • 검색 페이지는 SSR이 효율적이지만,
  • 내부 대시보드는 CSR이면 충분하다.
  • 공지·소개 페이지는 ISR로 캐시를 유지하는 편이 더 빠르다.

그래서 Next.js 같은 프레임워크는 “페이지별 렌더링 전략”을 지원한다.

🧩 2. Next.js 하이브리드 구조 예시

Next.js에서는 페이지마다 서로 다른 렌더링 방식을 설정할 수 있다.
다음은 실제 실무형 구조 예시다.

/pages
 ├─ index.tsx             → ISR (홈, 공지, 이벤트)
 ├─ product/[id].tsx      → SSR (상품 상세)
 ├─ dashboard/index.tsx   → CSR (로그인 사용자 대시보드)
 └─ offline.tsx           → PWA 오프라인 페이지

✅ (1) 메인/소개 페이지 → ISR

  • 데이터가 자주 변하지 않음.
  • 방문자 많음 → 빠른 캐시 필요.
export async function getStaticProps() {
  const data = await fetch(...);
  return { props: { data }, revalidate: 300 }; // 5분마다 갱신
}

✅ (2) 검색/상품 상세 → SSR

  • 사용자별, 요청별 데이터 다름.
  • SEO 중요, 초기 로딩 빨라야 함.
export async function getServerSideProps() {
  const res = await fetch(...);
  return { props: { product: await res.json() } };
}

✅ (3) 로그인 후 대시보드 → CSR

  • 개인별 API 호출 많음.
  • SEO 필요 없음, 동적 상호작용 중심.
function Dashboard() {
  const { data } = useSWR('/api/me');
  return <div>{data?.name}님 환영합니다</div>;
}

✅ (4) 오프라인 지원 → PWA

  • next-pwa 라이브러리로 Service Worker 등록.
  • 캐시 전략: HTML은 NetworkFirst, JS/CSS는 StaleWhileRevalidate.
// next.config.js
const withPWA = require('next-pwa')({
  dest: 'public',
  register: true,
  skipWaiting: true,
});
module.exports = withPWA({});

🔗 3. 실제 서비스 조합 예시

서비스 유형렌더링 조합이유
기업 랜딩/소개ISR트래픽 많고 업데이트 간헐적
상품 리스트ISR + CSR빠른 응답 + 즉시 필터링
검색결과SSRSEO, 정확한 실시간 데이터
로그인 후 내부 페이지CSR비공개, 상호작용 위주
오프라인 기능 (모바일)PWA연결 끊겨도 사용 가능

⚙️ 4. 서버·클라이언트 역할 분리 원칙

구분적합한 렌더링이유
초기 진입 속도SSR/ISR즉시 렌더링된 HTML 제공
빈번한 사용자 입력/대시보드CSR잦은 API 호출에 유리
정적 콘텐츠SSG/ISR캐싱 효율 극대화
오프라인·설치형PWA연결 의존도 제거

요약하면,

“보여주는 속도는 서버가,
상호작용은 브라우저가 담당한다.”

🧱 5. 인프라 배포 구조 예시

계층기술역할
CDNCloudFront / Vercel EdgeSSG/ISR 캐싱
Web ServerNext.js (Node)SSR 처리
API ServerSpring / Express비즈니스 로직
StorageS3 / Redis정적 자산, 캐시
OfflinePWA Service Worker오프라인 캐싱

Vercel이나 Netlify는 SSR·ISR·SSG를 동시에 처리하는 인프라를 자동 제공한다.
클라우드 없이 직접 운영할 경우,

  • SSR 페이지는 Node 서버에서
  • 정적 페이지(SSG/ISR)는 CDN에서
    서빙하도록 분리하면 된다.

📊 6. 실제 현업 비율

방식 조합사용 비율(체감)주요 사용처
CSR 단독약 40%내부용 시스템, 관리자 페이지
SSR + CSR 혼합약 30%쇼핑몰, 검색, 로그인 기반 서비스
ISR + CSR 혼합약 20%콘텐츠, 커머스 메인, 뉴스
PWA 추가 조합약 10%모바일, 오프라인 환경 서비스

🧩 7. 결론

  • 한 가지 방식만 고집하지 말 것.
  • 초기 진입·SEO → SSR/ISR,
    상호작용·개인화 → CSR,
    오프라인 안정성 → PWA.
  • 프론트엔드 최적화의 핵심은 균형 잡힌 조합이다.
profile
HelloPong
INTJ
이전 포스트

Multipass + Ubuntu

다음 포스트

k8s - Ingress

0개의 댓글