Prerendering vs SSR, 공개 페이지는 언제 HTML로 만들까요?
Prerendering는 빌드나 배포 전에 HTML을 미리 생성해 제공하는 방식이고, SSR은 각 요청 또는 캐시 갱신 시점에 서버가 HTML을 생성하는 방식입니다.
세 줄 요약
Prerendering는 변경이 드문 공개 페이지를 빠르게 제공하기 좋고 SSR은 요청 시점의 데이터와 조건을 HTML에 반영하기 쉽습니다.
둘의 선택 기준은 SEO 이름이 아니라 데이터 갱신 주기, URL 수, 개인화와 오류 복구 책임입니다.
기존 사이트에서 템플릿별로 섞어 쓸 수 있으므로 모든 페이지를 한 방식으로 다시 만들 필요가 없습니다.
Prerendering와 SSR은 무엇이 다른가요?
Prerendering는 빌드나 배포 전에 HTML을 미리 생성해 제공하는 방식이고, SSR은 각 요청 또는 캐시 갱신 시점에 서버가 HTML을 생성하는 방식입니다. 이름이 함께 거론돼도 목적과 처리 단계가 다르므로 한 설정이나 지표로 바꾸어 쓸 수 없습니다.
먼저 페이지별 데이터가 얼마나 자주 바뀌고 변경을 늦게 반영했을 때 어떤 손해가 생기는지 적습니다. 뉴스와 재고를 하루 한 번 빌드하는 문제와 회사 소개를 요청마다 만드는 낭비는 다릅니다.
비교 기준 | Prerendering | SSR |
|---|---|---|
생성 시점 | 빌드·배포 전 또는 예약 재생성 | 요청·캐시 갱신 시 |
신선도 | 재빌드 주기에 의존 | 데이터 원본과 요청 시점 반영 |
응답 비용 | 미리 만든 파일을 빠르게 제공 | 서버 계산·캐시 설계 필요 |
규모 병목 | URL 수가 많으면 빌드 증가 | 트래픽 증가 시 서버 부하 |
적합 장면 | 가이드·정적 랜딩·문서 | 재고·지역·실시간 조건 페이지 |
Prerendering와 SSR의 차이
현재 HTML에 내용이 없다는 이유만으로 SSR을 고르지 않습니다. 정적 생성, 증분 재생성, edge 캐시 등 현재 스택에서 가능한 방법과 운영 실패 지점을 비교합니다.
Prerendering와 SSR의 설정 화면보다 사용자가 실제로 만나는 결과를 먼저 봅니다. 대표 URL 한두 개에서 신선도와 응답 비용을 대조하고, 운영 기록과 공개값이 어긋난 지점을 찾아야 엉뚱한 팀에 수정 요청을 보내지 않습니다.
실제 운영에서는 어떻게 나눌까요?
Prerendering는 데이터 원본 변경이 빌드 큐와 연결되고 실패 시 이전 정상본을 유지하게 합니다. 생성 URL 목록, stale 시간과 삭제·리디렉션 규칙을 둡니다.
SSR은 timeout, API 장애와 사용자별 차이를 관리합니다. 크롤러와 비로그인 사용자가 같은 핵심 정보와 canonical을 받도록 하고 개인화는 보조 층에 둡니다.
비교 기준 | Prerendering | SSR |
|---|---|---|
회사·정책 소개 | 변경 시 재생성하기 적합 | 요청마다 만들 필요 적음 |
대규모 상품 | 선택적·증분 생성 필요 | 캐시와 재고 신선도 조절 |
지역별 재고 | stale 위험을 검토 | 요청·지역 조건 반영 가능 |
문서 버전 | 버전별 정적 생성에 적합 | 권한·실시간 상태만 서버 처리 |
잘못 적용했을 때 생기는 문제
Prerendering의 생성 목록이 sitemap과 다르면 새 URL이 HTML 없이 남을 수 있습니다. SSR은 API 하나의 지연이 전체 페이지 실패로 이어질 수 있습니다.
dynamic rendering처럼 봇에게만 별도 결과를 주는 우회는 장기 해법이 아닙니다. Google도 이를 권장 해법이 아닌 workaround로 설명합니다.
기존 웹사이트에서는 무엇부터 바꿀까요?
핵심 템플릿을 변경 빈도와 요청 의존성으로 나눕니다. 같은 URL의 원시 HTML, 데이터 시각과 캐시 헤더를 저장해 오래된 내용과 빈 응답을 찾습니다.
기존 프레임워크와 URL을 유지한 채 템플릿 단위로 출력 방식을 바꿉니다. 전면 이전 전 10~20개 URL cohort에서 배포 시간, 오류와 사용자 성능을 비교합니다.
Prerendering와 SSR의 적용 여부는 배포 로그만으로 끝내지 않습니다. 같은 URL에서 응답 비용과 규모 병목을 읽고 상태 코드, canonical과 내부 링크를 대조해야 공개는 됐지만 발견되지 않는 문제를 분리할 수 있습니다.
성과 확인 기준
Prerendering는 빌드 성공률, 생성 지연, stale 페이지와 누락 URL을 봅니다. SSR은 TTFB, cache hit, 서버 오류와 upstream 지연을 봅니다.
공통으로 공개 HTML의 본문·링크·canonical, 검색 크롤링과 사용자 Core Web Vitals를 확인합니다. 한 지표가 좋아졌다고 다른 단계까지 개선됐다고 쓰지 않습니다.
Prerendering와 SSR의 결과는 월간 평균 하나로 합치지 않습니다. 신선도와 응답 비용의 조건을 고정하고 같은 표본을 다시 확인해야 변화가 작업 때문인지 수요와 외부 환경 때문인지 구분할 수 있습니다.
공개 전후에는 무엇을 기록할까요?
공개 전 기록에는 Prerendering와 SSR의 판단 근거뿐 아니라 규모 병목과 적합 장면, 적용 URL과 책임자가 들어가야 합니다. 그래야 발행 뒤 값이 달라졌을 때 콘텐츠와 시스템 중 어느 쪽을 다시 볼지 알 수 있습니다.
Prerendering와 SSR 페이지의 HTTP 200과 sitemap 포함은 공개·발견 가능 상태를 뜻할 뿐 실제 검색 포함을 확정하지 않습니다. 적합 장면과 생성 시점의 변화를 후속 일정에서 따로 확인하고 이상이 있으면 원문, 템플릿, 외부 처리 중 시작점을 기록합니다.
Prerendering와 SSR 병행 운영의 실제 판단
판단 회의에서는 Prerendering와 SSR의 기능 목록보다 생성 시점·신선도 항목이 어디에서 끊기는지를 봅니다. 공개 HTML, 링크, 원문 데이터가 다른 값을 내보내면 검색과 AI 답변도 서로 다른 정보를 집을 수 있습니다. 응답 비용 항목이 달라진 URL을 표본으로 입력부터 공개 결과까지 따라갑니다.
Prerendering와 SSR의 규모 병목 항목은 발행 직후와 후속 관찰 시점을 나눠 기록합니다. 당일에는 공개 응답을 확인하고 검색 노출·클릭과 AI 언급·인용은 같은 질문 묶음으로 다시 측정합니다. 결과가 실제 고객 행동과 연결되지 않으면 작업 범위를 줄입니다.
참고 자료
크롤링과 렌더링을 함께 보면
이 운영 방식으로는 어떻게 이어서 운영할까요?
이 비교를 SEO 관점에서는 신선도와 검색 클릭의 문제로, GEO 관점에서는 규모 병목과 AI 답변 근거의 문제로 읽습니다. Prerendering와 SSR 가운데 무엇이 영향을 줬는지는 같은 질문과 URL을 다시 확인해 판단합니다.
이 운영 방식은 Prerendering와 SSR을 위해 웹사이트를 새로 만드는 도구가 아닙니다. 기존 도메인과 CMS를 유지한 채 생성 시점과 신선도를 검색 결과·AI 답변·인용 URL과 연결해 보고, 실제 병목이 확인된 부분만 고칩니다.
수정 효과는 Prerendering와 SSR에 사용한 동일한 표본에서 확인합니다. 신선도와 응답 비용이 함께 나아졌는지 보고, 기존 CMS의 제약이 반복해서 재현될 때만 이전이나 별도 구축을 판단합니다.
Prerendering와 SSR 비교 이후의 Search OS 운영
Search OS 적용의 출발점은 사이트 교체가 아닙니다. Prerendering와 SSR 비교에서 확인할 신선도, 응답 비용 항목을 현재 웹사이트 위에서 측정하고 콘텐츠·기술·외부 정보 가운데 막힌 부분만 손봅니다.
내부 성과 집계 기준으로 Search OS 적용 고객사는 SEO와 AI 검색 노출이 평균 88% 이상 증가했습니다. 이후에는 Prerendering와 SSR 비교에 사용한 검색과 AI 답변을 같은 주기로 다시 읽습니다. 좋아진 상태를 기준선으로 삼고 이탈이 생긴 URL을 먼저 고쳐 최상의 노출 상태가 이어지도록 관리합니다.