Blog

서론#

웹에서 렌더링을 이야기하다 보면
자주 등장하는 용어가 있다.

• 서버 사이드 렌더링(SSR)
• 클라이언트 사이드 렌더링(CSR)

이 중 SSR은
종종 이렇게 받아들여진다.

• SEO를 위한 렌더링 방식
• Next.js를 쓰면 자동으로 되는 것
• CSR보다 항상 빠른 방식

하지만 서버 사이드 렌더링은
CSR보다 항상 더 좋은 방식은 아니다.

이 글은
서버 사이드 렌더링이 무엇인지,
그리고 정확히 무엇을 해주고 무엇을 해주지 않는지를 정리한다.

렌더링이란 무엇인가#

먼저 렌더링부터 정리해야 한다.

렌더링은
데이터를 기반으로
사용자에게 보여줄 HTML을 만들어내는 과정이다.

이 HTML을
어디에서 만드느냐에 따라
렌더링 방식이 나뉜다.

서버 사이드 렌더링이란#

서버 사이드 렌더링은
HTML을 서버에서 생성해서 클라이언트로 전달하는 방식이다.

요청 흐름을 단순화하면 이렇다.

1. 브라우저가 페이지를 요청한다
2. 서버가 데이터를 가져온다
3. 서버가 HTML을 완성한다
4. 완성된 HTML을 브라우저에 내려준다

브라우저는
이미 내용이 채워진 HTML을 받기 때문에
즉시 화면을 그릴 수 있다.

이게 서버 사이드 렌더링이다.

클라이언트 사이드 렌더링과의 차이#

CSR에서는
초기 요청 시 HTML에 거의 내용이 없다.

대신,

1. 빈 HTML을 내려받고
2. JavaScript를 로드한 뒤
3. 브라우저에서 데이터를 요청하고
4. 그 결과로 화면을 만든다

즉,

• SSR: HTML 생성 책임이 서버에 있음
• CSR: HTML 생성 책임이 브라우저에 있음

이 차이가
렌더링 타이밍과 사용자 경험을 결정한다.

서버 사이드 렌더링의 장점#

서버 사이드 렌더링의 장점은 명확하다.

• 초기 화면이 빠르게 보인다
• JavaScript 실행 이전에도 콘텐츠가 존재한다
• 검색 엔진이 내용을 바로 수집할 수 있다

그래서 SSR은
콘텐츠 중심 페이지나
초기 진입 경험이 중요한 화면에서 강점을 가진다.

서버 사이드 렌더링의 한계#

하지만 SSR이 모든 문제를 해결해주지는 않는다.

• 매 요청마다 서버에서 렌더링 비용이 발생한다
• 서버 부하가 커질 수 있다
• 사용자 인터랙션은 여전히 클라이언트 JavaScript가 필요하다

즉, SSR은
"렌더링을 대신해줄 뿐",
클라이언트 로직을 제거해주지는 않는다.

서버 사이드 렌더링의 본질#

서버 사이드 렌더링의 핵심은
속도나 SEO 이전에 이거다.

HTML을 언제, 어디서 만들 것인가

SSR은
HTML 생성 시점을 요청 시점으로 옮기고,
그 책임을 서버가 지는 선택이다.

그래서 SSR은
성능 최적화 기법이라기보다,
아키텍처 선택에 가깝다.

정리#

서버 사이드 렌더링은

• 서버에서 HTML을 만들고
• 완성된 화면을 브라우저에 전달하는 방식이다

하지만

• 모든 화면을 빠르게 만들어주지도 않고
• JavaScript를 대체하지도 않으며
• 무조건 더 좋은 선택도 아니다

SSR은
CSR, SSG와 함께
화면 특성에 따라 선택되는 렌더링 방식 중 하나다.