쉬운 설명
SPA는 첫 응답이 거의 빈 HTML이고, 자바스크립트가 다 내려와 실행돼야 비로소 글자가 보입니다. 인터넷이 느리거나 기기가 약하면 한참 동안 흰 화면을 봅니다. SSR은 서버가 그 첫 HTML을 미리 그려서 보내 주기 때문에, 사용자가 페이지를 받자마자 글·이미지가 보입니다.
동시에 검색엔진(구글봇 등)도 좋아합니다. SPA가 보내는 빈 HTML은 봇이 내용을 못 읽지만, SSR이 보내는 완성된 HTML은 본문을 즉시 읽어서 색인합니다. 그래서 콘텐츠 사이트·커머스에서는 SEO 때문에 SSR을 자주 씁니다. SNS 공유 미리보기(OG 이미지·제목·요약)도 SSR에서 자연스럽게 동작합니다.
현대 SSR의 흐름은 '서버에서 만든 HTML + 클라이언트의 자바스크립트'를 결합하는 형태입니다. 서버가 첫 화면을 그려서 보내 주고, 그 위에 자바스크립트가 붙어 그 뒤의 상호작용을 담당합니다. 이걸 '하이드레이션(hydration)'이라고 부릅니다. Next.js·Remix·Nuxt·SvelteKit이 이 흐름을 표준 도구로 제공합니다.
SSR과 비슷한 단어가 몇 개 더 있어 헷갈리기 쉽습니다. SSG(정적 생성)는 빌드 타임에 미리 모든 페이지를 HTML로 만들어 두는 방식 — 변하지 않는 콘텐츠(문서·블로그)에 좋습니다. ISR(증분 정적 재생성)은 SSG + 일정 주기로 재생성. SSR은 매 요청마다 서버가 새로 그리는 방식 — 데이터가 자주 바뀌거나 사용자별로 다른 경우에 적합합니다. 세 방식을 한 프로젝트 안에서 페이지별로 섞어 쓰는 게 보통입니다.
SSR의 단점도 있습니다. 매 요청마다 서버가 일을 하니 서버 비용이 늘고, 트래픽이 폭주하면 응답이 느려질 수 있습니다. 그래서 캐싱·CDN을 함께 두는 게 일반적입니다. 또 클라이언트와 서버에서 같은 코드가 실행되는데 환경 차이로 작은 버그가 생기곤 합니다(예: window 객체는 서버에 없음). 이런 디테일을 잘 다뤄야 진짜 SSR의 이점을 누립니다.
비유로 보면
SSR은 식당이 미리 만든 따끈한 한 그릇을 손님에게 바로 내주는 방식이고, SPA는 손님에게 재료와 도구를 한 봉지 주고 식탁에서 직접 조리하게 하는 방식입니다. 식탁에서 만들면 손님 입맛에 더 맞출 수 있지만, 첫 한 입까지 더 오래 걸립니다.
어디에서 만나나
콘텐츠 사이트(뉴스·블로그·매거진), 이커머스(상품 상세 페이지), 마케팅 페이지, SEO가 중요한 모든 사이트. 또 사용자별 대시보드처럼 매 요청마다 다른 데이터를 보여 줘야 하는 경우에도 SSR이 자연스럽습니다. Next.js가 이 영역에서 가장 널리 쓰이는 프레임워크입니다.
작은 예시
뉴스 사이트에서 기사 링크를 페이스북에 공유하면 미리보기가 제목·이미지와 함께 뜹니다. 그게 가능한 이유는 서버가 기사 HTML을 미리 만들어서 응답하기 때문(SSR)이고, 만약 SPA였다면 미리보기 자리에 빈 페이지만 잡힐 가능성이 큽니다.
자주 하는 오해
한 줄 정리
SSR은 '첫 화면을 빠르게, 검색·공유에서 잘 보이게' 만드는 가장 표준적인 방법입니다. SPA의 부드러움과 함께 묶을 때 가장 좋은 결과가 나옵니다.