렌더링 (Rendering)

정의

렌더링(Rendering)은 웹 서버와 브라우저(또는 봇)가 HTML, CSS, JavaScript를 처리해 사용자가 보는 최종 화면을 만드는 과정 전체를 의미한다.

SEO 관점에서 렌더링은 검색엔진 봇이 페이지의 콘텐츠를 인식할 수 있는지를 결정하는 핵심 기술 요소다. 같은 콘텐츠라도 렌더링 방식에 따라 봇에게 보일 수도, 보이지 않을 수도 있다.

요약

렌더링 선택 가이드: 블로그/위키/랜딩 → SSG. 이커머스/뉴스 → SSR 또는 ISR. SaaS 대시보드 → 랜딩은 SSG, 로그인 후 앱은 CSR. 실시간 데이터 → 메타데이터 SSR + 데이터 CSR. AI 봇은 JS 미실행이므로 CSR = AEO 불가.

렌더링 4가지 패턴 상세

[DIAGRAM: CSR → SSR → SSG → ISR 렌더링 위치와 시점 비교]

1. CSR (Client-Side Rendering)

렌더링 위치: 브라우저 (클라이언트)
렌더링 시점: 사용자 접속 시 실시간

작동 흐름:

브라우저 요청
→ 서버: 빈 HTML + JS 번들 전송
→ 브라우저: JS 다운로드 + 실행
→ DOM 생성 → 화면 표시

HTML 소스 예시:

<body>
  <div id="root"><!-- JS가 채움 --></div>
  <script src="main.abc123.js"></script>
</body>

SEO 영향:

Googlebot: 지연 후 렌더링 (2단계 큐)
AI 봇: 대부분 인식 불가
초기 TTFB: 매우 빠름 (HTML 작음)
LCP: 느림 (JS 실행 후 콘텐츠 표시)

적합한 경우: SaaS 대시보드, 실시간 앱, 로그인 후 영역

2. SSR (Server-Side Rendering)

렌더링 위치: 서버
렌더링 시점: 사용자 요청마다 실시간

작동 흐름:

브라우저 요청
→ 서버: 데이터 조회 + HTML 완성
→ 브라우저에 완성된 HTML 전송
→ 화면 즉시 표시 + JS Hydration (인터랙티브화)

SEO 영향:

Googlebot: 즉시 인식
AI 봇: 즉시 인식
TTFB: 서버 처리 시간만큼 증가 가능
LCP: 빠름

적합한 경우: 이커머스, 뉴스 매체, 콘텐츠가 자주 변경되는 사이트

대표 프레임워크: Next.js (App Router 기본), Nuxt.js, Remix, SvelteKit

3. SSG (Static Site Generation)

렌더링 위치: 빌드 서버 (배포 시 1회)
렌더링 시점: 빌드 타임 (사전 생성)

작동 흐름:

빌드 명령 실행
→ 모든 페이지 HTML 사전 생성
→ CDN에 HTML 파일 배포
→
브라우저 요청 → CDN에서 HTML 즉시 서빙

SEO 영향:

Googlebot: 즉시 + 가장 빠른 TTFB
AI 봇: 즉시 인식 (최고)
TTFB: 매우 빠름 (CDN 엣지 서빙)
LCP: 매우 빠름

제약: 콘텐츠 변경 시 재빌드 필요. 수백만 페이지 사이트에서 빌드 시간 문제.

적합한 경우: 블로그, 위키, 문서 사이트, 랜딩 페이지

대표 프레임워크: Astro, Gatsby, Next.js (Static Export), Eleventy

4. ISR (Incremental Static Regeneration)

렌더링 위치: 빌드 + 서버 (주기적)
렌더링 시점: 빌드 시 + 설정된 주기마다 백그라운드 재생성

작동 흐름:

초기: SSG처럼 HTML 사전 생성
→ 설정된 시간 경과 후: 백그라운드에서 새 HTML 생성
→ CDN 캐시 갱신
→ 이후 요청: 새 HTML 서빙

SEO 영향:

SSG 장점 대부분 유지
콘텐츠 변경 반영 시간 = revalidate 설정값

Next.js 구현:

// app/page.js
export const revalidate = 3600 // 1시간마다 재생성

// 또는 특정 경로만
export async function generateStaticParams() {
  // 주요 페이지만 사전 생성
}

적합한 경우: 이커머스(가격 변동), 뉴스(자주 업데이트), 콘텐츠 사이트

Googlebot의 2단계 렌더링

구글이 공식 발표한 Googlebot의 페이지 처리 방식:

1단계 (즉시): 크롤 → HTML 다운로드 → 링크 추출 → 색인 큐 등록
2단계 (지연): 렌더링 큐 → JavaScript 실행 → 렌더링된 DOM 색인

핵심: CSR 페이지의 JS 콘텐츠는 2단계에서 처리되므로 색인 지연이 발생한다. 작은 사이트는 수시간, 큰 사이트는 수일이 걸릴 수 있다.

자세히는 크롤링 vs 인덱싱 항목 참조.

AI 봇의 렌더링

대부분의 AI 봇은 JavaScript를 실행하지 않는다. 이는 2026년 기준 사실이며 가까운 미래에도 크게 바뀌지 않을 것으로 예상된다.

이유:

수억 페이지를 크롤하는 봇에게 JS 실행은 엄청난 컴퓨팅 비용
Googlebot도 2단계 렌더링 큐를 사용할 만큼 비용이 높음
AI 봇은 크롤 주기가 Googlebot보다 낮아 비용 최소화 경향

CSR 사이트의 AEO 문제:

AI 봇 요청 → 빈 HTML만 수신 → 콘텐츠 없음 인식
→ ChatGPT/Perplexity 답변에서 해당 사이트 미인용
→ AEO 효과 없음

SSR/SSG는 AI 시대 필수 기술이다. 자세히는 JavaScript SEO 항목 참조.

렌더링 선택 가이드 (사이트 유형별)

[COMPARISON_TABLE: 사이트 유형별 권장 렌더링 방식]

정적 콘텐츠 사이트 (블로그, 위키, 문서)

권장: SSG
이유: 콘텐츠 변경 빈도 낮음 + 최고의 SEO/AEO 친화 + 낮은 서버 비용
사례: alleo.wiki (Next.js SSG)

이커머스

권장: SSR + ISR
이유: 재고·가격이 자주 변경 + 수많은 상품 페이지
사례: Shopify(SSR), Next.js Commerce

뉴스·미디어

권장: ISR (최신 기사 SSR, 아카이브 SSG)
이유: 최신 기사는 즉시 반영, 구기사는 캐시
사례: Vercel 플랫폼의 많은 미디어 사이트

SaaS 마케팅 사이트

권장: SSG (랜딩 페이지, 블로그)
이유: 마케팅 콘텐츠는 변경 빈도 낮음, 최고의 Lighthouse 점수

SaaS 애플리케이션 (로그인 후)

권장: CSR (로그인 후 대시보드)
이유: 실시간 데이터, 복잡한 인터랙션, SEO 불필요 (로그인 후 영역)

하이브리드 권장 패턴

example.com (랜딩 페이지) → SSG
example.com/blog/ → SSG
example.com/app/ (로그인 후) → CSR
example.com/api/ → API 라우트

렌더링 성능과 Core Web Vitals

렌더링 방식은 Core Web Vitals 지표에 직접 영향을 준다:

지표	CSR	SSR	SSG
TTFB	빠름 (작은 HTML)	중간 (서버 처리)	매우 빠름 (CDN)
LCP	느림 (JS 실행 후)	빠름	매우 빠름
INP	중간	중간	빠름 (JS 적음)
CLS	위험 (JS 동적 삽입)	낮음	매우 낮음

자세히는 TTFB, Core Web Vitals 항목 참조.

Edge Rendering (2024-2026 트렌드)

기존 SSR의 단점(서버 부하, 특정 리전에 집중)을 CDN 엣지에서 SSR을 실행하는 방식으로 해결하는 새로운 접근법이다.

대표 서비스:

Vercel Edge Functions (Next.js)
Cloudflare Workers (Remix, SvelteKit)
Netlify Edge Functions

장점:

SSG에 가까운 TTFB (엣지 노드 서빙)
SSR의 동적 콘텐츠 지원
한국 사용자에게도 빠른 응답 (서울 엣지 노드)

자세히는 TTFB 항목 참조.

한국 시장 적용

한국 CMS의 렌더링 현황

워드프레스: PHP SSR (기본적으로 SEO 친화)
카페24/고도몰: PHP SSR (기본적으로 SEO 친화)
아임웹: PHP/Node.js SSR (SEO 친화)
자체 개발 React SPA: CSR 가능성 높음 → SEO/AEO 위험

한국 스타트업의 공통 패턴

많은 한국 스타트업이 React 또는 Vue로 빠르게 개발하면서 순수 CSR을 채택한다. SEO를 나중에 고려해 마이그레이션 비용이 커지는 경우가 많다. 초기부터 Next.js(SSG/SSR)를 사용하는 것이 장기적으로 비용이 낮다.

네이버 Yeti와 렌더링

네이버 Yeti는 부분적으로 JavaScript를 실행하는 것으로 알려져 있다. 그러나 완전한 CSR 페이지에서는 여전히 색인 문제가 발생할 수 있다. SSR/SSG는 구글과 네이버 모두에서 유리하다.

자주 묻는 질문

Q. SSG 방식은 콘텐츠를 자주 업데이트하는 사이트에 맞지 않나요?
A. ISR을 사용하면 해결된다. revalidate 값을 1–60분으로 설정하면 콘텐츠 변경이 빠르게 반영된다. 또는 On-Demand ISR(특정 이벤트 시 캐시 무효화)을 사용하면 즉각적인 반영도 가능하다.

Q. CSR에서 SSR로 마이그레이션하면 SEO가 바로 개선되나요?
A. 개선되지만 즉각적이지는 않다. 구글봇이 새로운 SSR HTML을 크롤하고 색인을 업데이트하는 데 수 주에서 수 개월이 걸린다. AI 봇은 다음 크롤 시 바로 인식한다. 마이그레이션 후 GSC에서 색인 상태를 모니터링한다.

Q. Gatsby와 Next.js SSG 중 어느 것이 SEO에 더 좋나요?
A. SEO 결과에서 의미 있는 차이는 없다. 둘 다 빌드 시 HTML을 생성하고 CDN에 배포하는 방식이다. Next.js는 SSG, SSR, ISR을 하나의 프레임워크에서 선택할 수 있어 유연성이 높다. Gatsby는 콘텐츠 중심(블로그, 문서) 사이트에 특화된 생태계를 가지고 있다.

Q. SPA를 운영 중인데 마이그레이션 없이 SEO를 개선할 수 있나요?
A. 완전한 해결책은 아니지만 부분 개선이 가능하다: ①HTML에 주요 메타 태그 직접 삽입 ②내부 링크를 <a href> 태그로 교체 ③prerender.io 같은 서비스로 봇에게 사전 렌더된 HTML 제공. 그러나 AI 봇 미인식 문제는 해결되지 않으므로 SSR/SSG 마이그레이션이 장기 목표가 되어야 한다.

Q. 서버리스(Serverless)와 SSR은 호환되나요?
A. 그렇다. Vercel, AWS Lambda, Cloudflare Workers 같은 서버리스 환경에서 SSR이 매우 잘 작동한다. 서버리스 SSR은 트래픽 급증에 자동 확장되고, 항상 켜진 서버 없이 SSR 이점을 얻을 수 있다. Next.js가 Vercel 서버리스 환경과 기본으로 통합된다.

렌더링 (Rendering)

정의

요약

렌더링 4가지 패턴 상세

1. CSR (Client-Side Rendering)

2. SSR (Server-Side Rendering)

3. SSG (Static Site Generation)

4. ISR (Incremental Static Regeneration)

Googlebot의 2단계 렌더링

AI 봇의 렌더링

렌더링 선택 가이드 (사이트 유형별)

정적 콘텐츠 사이트 (블로그, 위키, 문서)

이커머스

뉴스·미디어

SaaS 마케팅 사이트

SaaS 애플리케이션 (로그인 후)

하이브리드 권장 패턴

렌더링 성능과 Core Web Vitals

Edge Rendering (2024-2026 트렌드)

한국 시장 적용

한국 CMS의 렌더링 현황

한국 스타트업의 공통 패턴

네이버 Yeti와 렌더링

자주 묻는 질문

관련 출처

이 페이지를 참조하는 항목

관련 항목

이런 항목도 있어요