웹사이트 렌더링 전략의 변천사: JSP부터 SPA, SSR, CSR, 하이브리드까지

JSP와 서버 템플릿부터 SPA·CSR, SSR·SSG·ISR, React Server Components와 부분 사전 렌더링까지 웹사이트 렌더링 전략이 어떻게 변해왔는지 요청 흐름과 선택 기준으로 정리합니다.

작성일2026-07-23수정일2026-08-01

정적 HTML, 서버 렌더링, 클라이언트 렌더링, 하이브리드 렌더링으로 이어지는 웹 렌더링 전략의 흐름

웹사이트 렌더링의 역사는 “HTML을 어디에서 만들 것인가?”라는 질문에 대한 답이 계속 이동해 온 과정입니다. 처음에는 서버가 HTML을 완성해서 보내는 방식이 기본이었고, 이후 브라우저가 JavaScript로 화면을 조립하는 SPA·CSR이 확산되었습니다. 지금은 정적 결과를 최대한 앞에서 제공하면서도 필요한 부분만 서버와 브라우저에서 나누어 처리하는 하이브리드가 일반적인 선택지가 되었습니다.

결론부터 말하면 SSR·CSR·SSG·ISR 중 하나가 항상 우월한 것이 아니라, 데이터의 신선도·개인화·검색 노출·초기 로딩·상호작용·운영 복잡도를 어디에 둘지 결정하는 문제입니다. 이 글에서는 JSP를 포함한 서버 템플릿 시대부터 SPA, SSR, SSG, ISR, React Server Components까지의 변천사를 하나의 요청 흐름으로 연결하고, 실제 프로젝트에서 렌더링 방식을 고르는 기준을 정리합니다.

이 글에서 먼저 잡아둘 세 가지 구분

렌더링 전략을 이해하려면 “서버냐 브라우저냐”와 “언제 생성하느냐”를 분리해서 봐야 합니다. 같은 서버 렌더링이라도 요청 시점에 만들 수 있고, 빌드 시점에 미리 만들 수 있습니다.

구분	질문	대표 용어
생성 위치	HTML을 누가 만드는가?	서버 렌더링, 클라이언트 렌더링
생성 시점	HTML을 언제 만드는가?	빌드 타임, 요청 타임, 재검증 시점
상호작용 연결	정적인 HTML에 동작을 어떻게 붙이는가?	hydration, client navigation

예를 들어 SSG는 서버에서 HTML을 만들지만 요청이 들어올 때마다 만들지는 않습니다. CSR은 브라우저가 화면을 만들지만, 초기 HTML에 일부 콘텐츠가 들어 있는 구조라면 서버 렌더링과 함께 사용할 수도 있습니다. 따라서 “이 사이트는 SSR인가요?”라고 묻기 전에 초기 문서의 생성 위치, 데이터의 생성 시점, JavaScript가 맡는 범위를 각각 확인해야 합니다.

1. 정적 HTML: 가장 단순한 렌더링

정적 HTML은 서버나 CDN에 저장된 파일을 요청마다 그대로 전달하는 방식입니다. 브라우저는 받은 HTML과 CSS를 즉시 파싱하고, 별도의 애플리케이션 런타임 없이 문서를 표시할 수 있습니다.

<!doctype html>
<html lang="ko">
  <head>
    <title>서비스 소개</title>
  </head>
  <body>
    <main>
      <h1>오늘의 서비스</h1>
      <p>모든 방문자에게 같은 내용을 보여줍니다.</p>
    </main>
  </body>
</html>

이 모델에서는 HTML 파일 자체가 결과물입니다. 웹 서버는 데이터베이스를 조회하거나 템플릿을 실행할 필요가 없고, CDN은 파일을 여러 지역에 캐시할 수 있습니다. 소개 페이지, 문서, 블로그처럼 사용자별 데이터가 필요하지 않은 화면에 여전히 강력한 이유입니다.

대신 콘텐츠가 바뀔 때 파일을 다시 생성하거나 배포해야 합니다. 사용자마다 다른 메뉴를 보여주거나 로그인 쿠키를 읽어야 한다면 정적 파일만으로는 부족합니다.

2. JSP와 서버 템플릿: HTML을 서버에서 조립하다

JSP(JavaServer Pages)는 HTML 안에 서버 측 표현식과 태그를 섞어 요청 시점의 데이터를 HTML로 만드는 서버 템플릿 기술입니다. PHP, ASP, Rails ERB, Django template도 같은 문제를 풀었던 계열로 볼 수 있습니다.

<main>
  <h1><%= product.getName() %></h1>
  <p>재고: <%= product.getStock() %>개</p>
</main>

브라우저가 받는 결과는 결국 완성된 HTML입니다. 사용자는 첫 화면을 보기 위해 애플리케이션 JavaScript가 모두 내려오기를 기다릴 필요가 없고, 검색 엔진도 문서 내용을 읽기 쉽습니다. 반면 요청마다 템플릿 실행, 데이터 조회, 세션 확인이 필요하므로 트래픽이 늘면 서버와 데이터베이스가 병목이 될 수 있습니다.

여기서 JSP는 기술 이름이고 SSR은 렌더링 시점에 대한 이름입니다. JSP로 요청 시점 HTML을 만들면 SSR이라고 부를 수 있지만, SSR이 JSP만을 의미하는 것은 아닙니다. 지금의 React·Next.js 서버 컴포넌트도 서버에서 HTML 또는 서버 페이로드를 만들지만, 템플릿 엔진 시대와는 컴포넌트 경계와 클라이언트 상호작용을 나누는 방식이 다릅니다.

3. AJAX와 SPA: 페이지 이동을 브라우저 안으로 가져오다

2000년대 후반부터 AJAX가 확산되면서 전체 문서를 다시 받지 않고 필요한 데이터만 비동기로 가져와 화면 일부를 갱신하는 패턴이 자리 잡았습니다. 이 흐름이 라우팅과 상태 관리까지 브라우저에 맡기는 SPA(Single-Page Application)로 발전했습니다.

SPA는 보통 하나의 HTML 진입점과 JavaScript 애플리케이션을 내려보낸 뒤, 이후 경로 이동을 브라우저에서 처리합니다.

첫 진입:  index.html + JavaScript bundle
이후 이동: API 요청 → 상태 변경 → 현재 DOM 업데이트

Next.js의 SPA 가이드도 CSR을 “하나의 HTML 파일을 제공하고, JavaScript가 필요한 시점에 데이터를 가져와 렌더링하는 방식”으로 설명합니다. 페이지 전체 새로고침을 줄일 수 있고, 드래그·필터·편집기처럼 애플리케이션 상태가 많은 화면을 만들기 편합니다.

하지만 초기 화면의 책임이 브라우저로 이동하면서 비용도 함께 이동했습니다.

JavaScript bundle을 먼저 다운로드하고 실행해야 합니다.
API 응답을 받은 뒤에야 콘텐츠가 채워질 수 있습니다.
초기 HTML에 본문이 없으면 크롤러와 공유 미리보기가 불리할 수 있습니다.
인증·권한·비즈니스 규칙을 브라우저에 두면 보안 경계가 흐려질 수 있습니다.

CSR은 나쁜 선택이 아니라 초기 문서보다 이후 상호작용이 더 중요한 화면을 위한 선택입니다. 내부 어드민, 협업 편집기, 개인화 대시보드처럼 검색 유입이 중요하지 않고 로그인 이후의 상태 변화가 중심인 화면에 잘 맞습니다.

4. SSR: 요청마다 최신 HTML을 만들다

SSR(Server-Side Rendering)은 사용자가 요청할 때 서버가 데이터를 읽고 HTML을 생성해 응답하는 방식입니다. Next.js 문서도 SSR을 요청마다 페이지 HTML을 생성하는 방식, 또는 App Router에서 동적 렌더링이라고 설명합니다.

브라우저 → GET /dashboard
        → 서버: 쿠키·헤더·DB·외부 API 확인
        → 서버: 사용자별 HTML 생성
        ← HTML + 필요한 JavaScript
브라우저 → HTML 표시 → hydration → 상호작용

SSR의 장점은 최신 데이터와 사용자별 결과를 첫 문서에 담을 수 있다는 데 있습니다. 로그인 사용자 이름, 권한에 따른 메뉴, 요청 지역에 맞는 가격처럼 요청 시점에만 알 수 있는 값이 대표적입니다.

반대로 요청마다 서버 작업이 필요합니다. 데이터베이스가 느리거나 외부 API가 지연되면 첫 응답도 늦어지고, 사용자별 응답을 CDN에 공유 캐시하기 어렵습니다. SSR을 선택할 때는 “검색 엔진이 읽을 수 있는가”만 보지 말고 요청당 렌더링 비용과 캐시 가능성까지 함께 계산해야 합니다.

5. SSG: 서버 렌더링을 배포 시점으로 당기다

SSG(Static Site Generation)는 HTML을 빌드 시점에 미리 생성하고, 사용자의 요청에는 완성된 파일을 제공합니다. 요청마다 같은 문서를 다시 계산하지 않으므로 CDN 캐시와 잘 맞고, 서버 비용과 응답 변동성을 줄일 수 있습니다.

Next.js의 정적 렌더링 안내에서도 데이터 fetch와 렌더링이 배포 시점 또는 재검증 시점에 이루어지고, 방문자에게는 캐시된 결과가 제공된다고 설명합니다.

빌드/배포: 콘텐츠 조회 → HTML 생성 → CDN에 배포
방문 요청: CDN 캐시의 HTML 반환

블로그 글, 문서, 제품 소개, 이벤트 랜딩처럼 여러 사용자에게 같은 내용을 보여주는 화면이 SSG의 전형적인 대상입니다. 이 사이트의 블로그 포스트도 MDX 파일을 빌드 시점에 읽어 정적 경로를 생성하는 구조이므로 SSG의 장점을 활용합니다.

SSG의 비용은 최신성입니다. 콘텐츠를 수정했는데 다시 빌드하지 않으면 이전 HTML이 계속 제공됩니다. 이 문제를 완화한 전략이 ISR입니다.

6. ISR: 정적 캐시와 최신 데이터를 절충하다

ISR(Incremental Static Regeneration)은 정적으로 제공하되 일정 시간이나 명시적인 이벤트를 기준으로 페이지를 다시 생성하는 방식입니다. Next.js 공식 가이드에 따르면 ISR은 전체 사이트를 다시 빌드하지 않고 정적 콘텐츠를 업데이트하고, 대부분의 요청에 미리 렌더링된 페이지를 제공할 수 있습니다.

// 개념을 보여주는 단순화된 예시
export const revalidate = 60;

이 설정의 의미는 “60초마다 모든 요청이 서버 렌더링된다”가 아닙니다. 캐시된 정적 결과를 제공하다가 재검증 조건이 충족되면 새 결과를 만들어 다음 요청부터 반영하는 모델입니다. 실제 프레임워크의 캐시 정책, stale-while-revalidate 동작, 태그 기반 무효화 방식은 버전에 따라 확인해야 합니다.

ISR은 상품 목록, 블로그 인덱스, 뉴스처럼 자주 바뀌지만 모든 방문자에게 같은 데이터가 보이는 화면에 유용합니다. 반대로 주식 가격, 좌석 재고, 강한 실시간성이 필요한 화면은 요청 시 동적 렌더링이나 클라이언트 재요청이 더 적합할 수 있습니다.

7. Hydration: 서버가 만든 HTML에 브라우저 동작을 연결하다

서버가 HTML을 먼저 보냈다고 해서 화면이 곧바로 완전히 인터랙티브해지는 것은 아닙니다. React 애플리케이션은 서버가 만든 HTML과 브라우저에서 실행될 컴포넌트 트리를 맞춘 뒤 이벤트 핸들러와 상태를 연결하는 hydration 단계를 거칠 수 있습니다.

서버: <button>좋아요</button> 전송
브라우저: HTML 표시
브라우저: JavaScript 로드 → React가 버튼에 onClick 연결

hydration은 HTML을 다시 처음부터 그리는 과정이라기보다, 이미 있는 DOM을 React의 실행 환경과 연결하는 과정으로 이해하는 편이 좋습니다. 서버와 클라이언트에서 서로 다른 시간, 랜덤 값, 브라우저 전용 API를 사용하면 hydration mismatch가 발생할 수 있습니다.

따라서 SSR이나 SSG를 도입할 때는 다음 경계를 확인해야 합니다.

서버와 브라우저가 처음 표시할 값이 같은가?
window, document, localStorage를 서버에서 읽고 있지 않은가?
시간·난수·지역화 결과가 렌더링마다 달라지지 않는가?
상호작용이 필요한 부분만 Client Component로 분리할 수 있는가?

8. React Server Components와 하이브리드 렌더링

최근의 핵심 변화는 “한 페이지 전체를 서버 또는 브라우저 한쪽에서 렌더링한다”는 선택을 완화한 것입니다. React Server Components(RSC)는 서버 환경에서 실행되는 컴포넌트와 브라우저에서 실행되는 Client Component를 한 트리 안에 배치하도록 합니다.

Next.js App Router에서는 레이아웃과 페이지가 기본적으로 Server Component이며, 상태·이벤트 핸들러·브라우저 API가 필요한 부분만 Client Component로 표시합니다. 서버 컴포넌트는 서버에서 데이터를 읽고 클라이언트 JavaScript bundle에 포함되지 않도록 만들 수 있습니다. 반면 Client Component는 초기 HTML 생성에 참여할 수 있어도, 상호작용을 위해 브라우저 bundle과 hydration 비용이 필요합니다.

// Server Component: 데이터와 마크업을 서버에서 준비
export default async function ProductPage() {
  const product = await getProduct();

  return (
    <main>
      <ProductSummary product={product} />
      <AddToCartButton productId={product.id} />
    </main>
  );
}

// Client Component: 클릭과 브라우저 상태가 필요한 작은 경계
"use client";
export function AddToCartButton({ productId }: { productId: string }) {
  return <button onClick={() => addToCart(productId)}>장바구니</button>;
}

위 코드는 “서버 컴포넌트가 SSR이고 버튼이 CSR이다”라고 단순하게 분류하기 위한 예제가 아닙니다. 실제로는 초기 HTML, RSC payload, Client Component bundle, hydration과 navigation이 함께 동작합니다. 핵심은 상호작용이 필요한 범위를 브라우저로 보내고, 나머지 데이터·마크업·무거운 라이브러리는 서버에 남길 수 있다는 것입니다.

9. Streaming과 부분 사전 렌더링: 기다림을 잘게 나누다

서버 렌더링의 체감 지연은 모든 데이터를 준비한 뒤 한 번에 HTML을 보내는 waterfall에서 자주 발생합니다. Streaming은 준비된 HTML 조각을 먼저 보내고, 느린 부분은 나중에 도착하도록 응답을 나눕니다. React의 Suspense 경계와 Next.js의 loading.js 또는 수동 Suspense 경계가 이 흐름을 표현합니다.

먼저 전송: 헤더 + 정적 본문 + 로딩 경계
나중 전송: 느린 추천 목록, 개인화 카드, 실시간 데이터

Next.js의 Cache Components와 부분 사전 렌더링 안내는 정적으로 렌더링할 수 있는 shell을 즉시 제공하고, 동적 콘텐츠를 준비되는 대로 스트리밍하는 모델을 설명합니다. 이 방식은 “정적 페이지는 빠르지만 오래되고, 동적 페이지는 최신이지만 느리다”는 선택을 한 화면 안에서 분해하는 접근입니다.

단, Streaming을 적용했다고 네트워크·데이터베이스 비용이 사라지는 것은 아닙니다. 어떤 부분을 먼저 보여줄지, 로딩 상태가 레이아웃을 흔들지 않는지, SEO에 필요한 본문이 첫 응답에 포함되는지까지 설계해야 합니다.

브라우저 요청, 서버 계산, 브라우저 hydration과 상호작용으로 이어지는 렌더링 요청 생명주기 — 렌더링 전략은 요청 생명주기에서 서버 계산과 브라우저 실행의 경계를 바꾸는 결정입니다. · AI 생성 이미지

10. 렌더링 전략을 비교하는 실무 표

각 전략의 차이는 “빠르다·느리다”보다 언제 어떤 비용을 지불하는지로 비교해야 합니다.

전략	HTML 생성 시점	초기 콘텐츠	최신 데이터	브라우저 JS 의존도	잘 맞는 화면
정적 HTML	파일 생성 시점	즉시	배포 전까지 고정	낮음	문서, 단순 랜딩
JSP·템플릿 SSR	요청 시점	서버 데이터 포함	높음	선택적	전통적인 웹 앱, 사용자별 문서
SSG	빌드 시점	즉시	재빌드 전까지 고정	선택적	블로그, 문서, 상품 소개
ISR	빌드·재검증 시점	캐시 HTML	재검증 주기에 따라 반영	선택적	자주 바뀌는 공개 콘텐츠
CSR·SPA	브라우저 실행 시점	shell 또는 빈 진입점	API 응답 기준	높음	어드민, 편집기, 복잡한 상호작용
RSC + Client Components	컴포넌트별로 분리	서버 결과 + 상호작용 경계	캐시·요청 정책에 따라 다름	필요한 부분만	콘텐츠와 상호작용이 섞인 현대적 앱

표에서 “초기 콘텐츠”가 즉시라는 말은 서버가 만든 HTML이 브라우저에 먼저 도착한다는 뜻이지, 모든 데이터와 이벤트가 이미 준비됐다는 뜻은 아닙니다. SSR·SSG 모두 Client Component를 포함할 수 있고, CSR도 로딩 shell과 사전 렌더링을 함께 사용할 수 있습니다.

11. 어떤 렌더링 방식을 선택해야 할까?

렌더링 방식은 페이지 단위가 아니라 데이터와 상호작용 경계 단위로 선택하는 것이 안전합니다. 다음 질문을 순서대로 답하면 과한 아키텍처를 피할 수 있습니다.

1) 검색·공유 미리보기에 본문이 필요한가?

그렇다면 정적 HTML, SSG, SSR, RSC 기반 서버 렌더링을 먼저 검토합니다. 특히 글·상품·문서처럼 본문이 핵심인 페이지는 첫 HTML에 주요 텍스트가 포함되는 편이 유리합니다. 검색 엔진 최적화가 중요하지 않은 인증 후 화면이라면 CSR의 비중을 높일 수 있습니다.

2) 요청마다 달라지는 데이터인가?

쿠키, 세션, 권한, 위치, 개인화 결과처럼 사용자 요청에 따라 달라지는 값은 동적 렌더링이 자연스럽습니다. 다만 개인화 영역만 동적으로 두고 나머지 공개 콘텐츠는 캐시하거나 정적으로 제공하는 분할도 가능합니다.

3) 데이터가 얼마나 자주 바뀌는가?

배포 때만 바뀌면 SSG, 몇 분 단위의 지연을 허용할 수 있으면 ISR, 매 요청 최신성이 필요하면 SSR 또는 클라이언트 재요청을 검토합니다. “실시간”이라는 요구도 실제 허용 지연이 1초인지 1분인지 먼저 정해야 합니다.

4) 브라우저에서만 가능한 상호작용인가?

드래그, 입력 상태, 미디어 제어, WebSocket, localStorage, 브라우저 전용 SDK는 Client Component 또는 CSR 경계가 필요합니다. 그렇다고 페이지 전체를 CSR로 만들 필요는 없습니다. 서버에서 본문을 준비하고 버튼·필터·편집 영역만 브라우저로 보내는 방식이 보통 더 작은 비용을 만듭니다.

5) 운영 환경이 무엇을 지원하는가?

정적 호스팅만 가능하면 SSG나 static export가 기준이 됩니다. Node.js 서버와 캐시 인프라를 운영할 수 있다면 SSR, ISR, 스트리밍 같은 선택지가 늘어납니다. ISR은 Next.js 가이드 기준으로 Node.js 런타임에서 지원되고 Static Export에서는 지원되지 않는 제약도 확인해야 합니다.

검색 노출, 서버 비용, 상호작용, 데이터 신선도 기준으로 렌더링 전략을 고르는 의사결정 매트릭스 — 전략 선택은 검색 노출·데이터 신선도·상호작용·운영 비용의 균형 문제입니다. · AI 생성 이미지

12. 흔히 하는 오해와 설계상의 함정

SSR이면 무조건 빠른가요?

아닙니다. SSR은 첫 HTML을 서버에서 만들 수 있게 하지만, 서버 데이터 조회와 템플릿 계산이 오래 걸리면 응답이 늦어질 수 있습니다. 캐시, 병렬 fetch, 스트리밍, 데이터베이스 인덱스가 함께 필요합니다.

CSR이면 SEO가 불가능한가요?

불가능하다고 단정할 수는 없습니다. 크롤러가 JavaScript를 실행할 수 있어도, 초기 콘텐츠 발견과 실행 비용 측면에서 불리할 수 있습니다. 검색이 중요한 페이지라면 본문을 서버에서 제공하고, CSR을 상호작용 영역에 한정하는 편이 설명하기 쉽고 안정적입니다.

SSG면 데이터가 절대 바뀌지 않나요?

아닙니다. SSG 결과는 재빌드나 재검증 정책에 따라 갱신할 수 있습니다. ISR과 on-demand revalidation을 사용하면 정적 캐시를 유지하면서 콘텐츠 변경을 반영할 수 있습니다.

Client Component는 브라우저에서만 렌더링되나요?

Next.js App Router의 Client Component도 초기 페이지 생성 과정에서 서버에 의해 HTML로 렌더링될 수 있습니다. 다만 상태·이벤트·브라우저 API를 위해 클라이언트 JavaScript가 필요합니다. “Client”라는 이름은 상호작용이 브라우저에 있다는 뜻이지, 서버가 초기 HTML을 만들지 않는다는 뜻은 아닙니다.

하이브리드면 복잡도가 사라지나요?

오히려 경계가 늘어나는 만큼 책임을 명확히 해야 합니다. 서버에서 읽을 수 있는 데이터, 브라우저 상태, 캐시 무효화, hydration 일관성, 로딩·오류 UI를 문서화하지 않으면 디버깅 비용이 커질 수 있습니다.

정리: 렌더링은 위치가 아니라 책임 배치다

JSP와 전통적인 서버 템플릿은 서버가 HTML을 완성하는 모델을 대중화했습니다. SPA·CSR은 브라우저에 상태와 화면 전환을 가져와 풍부한 상호작용을 만들었습니다. SSR은 요청 시점의 최신성과 검색 가능한 초기 HTML을 제공했고, SSG와 ISR은 정적 캐시의 속도와 콘텐츠 갱신 사이의 균형을 만들었습니다. RSC와 Streaming은 페이지 전체가 아니라 컴포넌트와 데이터 흐름을 기준으로 경계를 나눌 수 있게 했습니다.

따라서 새로운 프로젝트에서 먼저 결정할 것은 “SSR을 쓸까요, CSR을 쓸까요?”가 아닙니다. 다음 네 가지를 페이지별로 기록하는 것이 출발점입니다.

첫 HTML에 반드시 있어야 하는 콘텐츠는 무엇인가?
사용자별·요청별로 달라지는 값은 무엇인가?
어느 정도의 데이터 지연과 캐시된 결과를 허용할 수 있는가?
브라우저에서만 필요한 상호작용의 경계는 어디인가?

이 네 질문에 답하면 정적 HTML, SSR, CSR, SSG, ISR, RSC를 서로 배타적인 유행어가 아니라 조합 가능한 도구로 볼 수 있습니다. 좋은 렌더링 전략은 가장 최신 기술을 고르는 것이 아니라, 사용자에게 필요한 결과를 가장 작은 책임과 비용으로 전달하는 설계입니다.

자주 묻는 질문

JSP와 SSR은 같은 개념인가요?

같지 않습니다. JSP는 서버에서 HTML을 만드는 템플릿 기술이고, SSR은 요청 시점에 서버가 HTML을 생성한다는 렌더링 전략입니다. JSP를 요청 시점에 실행하면 SSR의 한 구현이 되지만, SSR은 React·Vue·PHP 등 여러 기술로 구현할 수 있습니다.

SPA와 CSR은 같은 말인가요?

밀접하지만 같은 말은 아닙니다. SPA는 여러 경로를 하나의 클라이언트 애플리케이션이 전환하는 애플리케이션 구조이고, CSR은 브라우저에서 UI를 렌더링하는 방식입니다. SPA가 CSR을 주로 사용할 수 있지만, 초기 HTML을 서버에서 받고 이후 이동을 클라이언트에서 처리하는 하이브리드도 가능합니다.

블로그는 SSR과 SSG 중 무엇이 더 적합한가요?

대부분의 블로그 글은 여러 방문자에게 같은 내용을 보여주므로 SSG 또는 ISR이 먼저 검토 대상입니다. 요청마다 개인화해야 하거나 발행 즉시 강한 최신성이 필요하면 SSR·동적 렌더링을 추가로 고려합니다.

ISR은 실시간 렌더링인가요?

아닙니다. ISR은 캐시된 정적 결과를 제공하고 재검증 시점에 새 결과로 교체하는 방식입니다. 허용 가능한 지연이 없는 실시간 화면은 SSR, 클라이언트 폴링, SSE, WebSocket 같은 다른 전략이 필요할 수 있습니다.

React Server Components는 SSR을 대체하나요?

RSC는 서버에서 실행되는 컴포넌트 모델이고, SSR은 HTML을 생성해 초기 응답으로 제공하는 전략입니다. RSC 기반 앱도 SSR·SSG·동적 렌더링·Streaming을 조합할 수 있으므로 서로 대체 관계라기보다 다른 축의 개념으로 이해해야 합니다.

참고 자료

Next.js — Server and Client Components
Next.js — Linking and Navigating: Server Rendering, Prefetching, Streaming
Next.js — Static and Dynamic Rendering
Next.js — Server-side Rendering (Pages Router)
Next.js — Incremental Static Regeneration
Next.js — Cache Components and Partial Prerendering
Next.js — Building Single-Page Applications
React — Server Components
이미지 출처: OpenAI 이미지 생성 도구로 제작한 이미지 3장(2026-07-23), 본문 개념 설명용이며 실제 서비스 화면·측정 결과를 나타내지 않습니다.