Server-Side Rendering

SPA가 확산되면서 새로운 문제가 드러났습니다. 브라우저가 빈 HTML을 받고 JavaScript를 다운로드하고 실행해서 화면을 그릴 때까지 사용자는 빈 화면이나 로딩 스피너를 봅니다. 네트워크가 느리거나 기기 성능이 낮으면 이 시간이 몇 초까지 늘어납니다. 더 큰 문제는 검색 엔진입니다. 검색 봇이 페이지를 방문했을 때 JavaScript를 실행하지 않으면 빈 HTML만 보게 되고, 콘텐츠가 인덱싱되지 않습니다. 블로그, 뉴스, 상품 페이지처럼 검색을 통해 사용자가 유입되는 서비스에서 이 문제는 트래픽 자체를 잃는 결과로 이어집니다. SNS에 URL을 공유할 때도 미리보기 카드가 비어 있으면 클릭률이 떨어집니다. SSR은 서버에서 HTML을 완성해 보내는 방식으로, 이 두 가지 문제를 근본적으로 해결합니다.

웹 초기에는 모든 페이지가 서버에서 렌더링됐습니다. PHP, JSP, ASP 같은 서버 템플릿 언어가 요청마다 HTML을 만들어 보냈고, 이것이 자연스러운 방식이었습니다. SPA가 등장하면서 렌더링 책임이 브라우저로 옮겨갔고 사용자 경험은 더 풍부해졌지만, 초기 로딩 속도와 SEO라는 오래된 장점을 잃었습니다. 2010년대 중반 이후, 프론트엔드 프레임워크 생태계에서 '서버에서도 같은 컴포넌트를 렌더링할 수 있으면 양쪽 장점을 모두 가져갈 수 있지 않을까'라는 접근이 자리 잡았습니다. 같은 코드를 서버와 브라우저 양쪽에서 실행하는 유니버설(또는 아이소모픽) 렌더링이 가능해지면서, 서버에서 첫 HTML을 완성하고 브라우저에서 이어받아 인터랙션을 처리하는 현대적 SSR이 정착했습니다.

SSR의 동작은 크게 네 단계로 나뉩니다. 첫째, 사용자가 URL을 요청하면 서버가 이를 받습니다. 둘째, 서버는 해당 페이지에 필요한 데이터를 데이터베이스나 API에서 조회합니다. 셋째, 조회한 데이터를 컴포넌트 트리에 넣어 완성된 HTML 문자열을 생성합니다. 이 과정을 서버 사이드 렌더링이라고 합니다. 넷째, 완성된 HTML을 브라우저에 보내면 사용자는 바로 콘텐츠를 볼 수 있습니다. 여기서 끝이 아닙니다. 브라우저가 HTML을 표시한 뒤 JavaScript 번들을 로드하면 Hydration이라는 과정이 시작됩니다. 이미 그려진 HTML 위에 이벤트 핸들러를 연결하고, 이후의 인터랙션은 클라이언트 측 JavaScript가 처리합니다. 사용자 시점에서는 페이지가 즉시 보이고, 잠시 후 버튼 클릭 같은 인터랙션이 활성화되는 순서입니다. 서버에서 HTML을 만드는 시간이 응답 속도에 직접 영향을 주므로, 데이터 조회가 느리면 사용자도 그만큼 기다려야 합니다. 이 때문에 캐싱 전략이나 스트리밍 SSR 같은 기법이 함께 쓰입니다.

SSR과 SSG(Static Site Generation)는 둘 다 서버가 HTML을 완성한다는 점에서 비슷하지만, 언제 만드느냐가 다릅니다. SSR은 사용자가 요청할 때마다 서버에서 HTML을 생성하고, SSG는 빌드 시점에 미리 HTML 파일을 만들어 놓습니다. 이 차이가 적합한 상황을 나눕니다. SSG는 콘텐츠가 자주 바뀌지 않는 블로그, 문서 사이트, 마케팅 페이지에 맞습니다. 미리 만들어진 파일을 CDN에서 바로 전달하니 서버 부하가 거의 없고 응답도 빠릅니다. SSR은 로그인 상태에 따라 다른 화면을 보여주거나, 실시간 데이터가 반영돼야 하는 페이지에 맞습니다. 대신 요청마다 서버가 렌더링을 수행하므로 서버 자원이 필요합니다. SPA와 비교하면, SSR은 첫 화면을 빠르게 보여주고 SEO에 유리하지만 서버 비용이 들고, SPA는 첫 로딩 후의 탐색이 빠르지만 초기 화면과 SEO에서 약합니다. 현대 프레임워크에서는 페이지별로 SSR, SSG, 클라이언트 렌더링을 섞어 쓸 수 있어 이 경계는 점점 유연해지고 있습니다.

SSR은 검색 엔진 유입이 중요한 콘텐츠 페이지, 상품 상세 페이지, 뉴스 사이트에서 가장 분명한 효과를 보입니다. SNS 공유 시 OG 태그가 포함된 완성 HTML이 필요한 페이지도 SSR이 자연스럽습니다. 운영 측면에서 SSR은 요청마다 서버가 렌더링을 수행하므로 트래픽이 많아지면 서버 자원 소모가 커집니다. 캐싱 전략을 세우지 않으면 같은 페이지를 매번 다시 만드는 낭비가 생깁니다. CDN 캐시, 페이지 단위 캐시, 데이터 캐시를 조합해 서버 부하를 관리하는 것이 SSR 운영의 핵심 과제입니다. Hydration 과정도 무시할 수 없습니다. 서버에서 보낸 HTML은 즉시 보이지만, JavaScript가 로드되고 Hydration이 완료되기 전까지는 버튼 클릭이 반응하지 않는 구간이 있습니다. 사용자는 화면은 보이는데 터치가 안 되는 경험을 하게 됩니다. 이 간극을 줄이기 위해 Selective Hydration이나 Server Components 같은 기법이 발전하고 있습니다. 모든 페이지를 SSR로 만들 필요는 없습니다. 공개 페이지는 SSR이나 SSG로, 로그인 후 대시보드는 클라이언트 렌더링으로 구성하는 혼합 전략이 현실적입니다.