CSR과 SSR (Client Side Rendering, Server Side Rendering)

CSR(Client Side Rendering)은 서버가 거의 빈 HTML과 자바스크립트(JavaScript) 번들을 내려보내고 브라우저가 화면을 그리는 방식이며, SSR(Server Side Rendering)은 서버가 요청 시점에 완성된 HTML을 만들어 내려보내는 방식이다. 두 방식은 화면을 그리는 주체와 시점이 다르기 때문에 초기 로딩 속도, 검색 엔진 최적화, 서버 부하에서 상반된 특성을 보인다. 최신 프레임워크는 둘 중 하나를 고르기보다 페이지 성격에 따라 혼합해 쓰는 방향으로 발전하고 있다.

CSR의 동작 과정

CSR에서 서버는 뼈대만 있는 HTML과 스크립트 태그를 응답한다. 브라우저는 자바스크립트 번들을 내려받아 실행하고, 이 코드가 API를 호출해 데이터를 받아온 뒤 DOM(Document Object Model)을 생성해 화면을 완성한다. 리액트(React)나 뷰(Vue)로 만든 전형적인 SPA(Single Page Application)가 이 구조다. 최초 진입은 번들 다운로드와 실행, 데이터 요청이 순차로 일어나므로 느리지만, 일단 앱이 뜨고 나면 페이지 이동 시 전체 문서를 다시 받지 않고 필요한 데이터만 가져와 화면 일부를 갈아 끼우므로 상호작용이 매끄럽다. 렌더링 연산이 각 사용자의 브라우저에서 일어나므로 서버 부담도 작다. 다만 첫 응답 HTML에 내용이 없어서, 자바스크립트를 실행하지 않는 크롤러나 링크 미리보기 생성기에는 빈 페이지로 보일 수 있다.

SSR의 동작 과정

SSR에서는 요청이 올 때마다 서버가 데이터를 조회하고 컴포넌트를 실행해 완성된 HTML 문자열을 만들어 응답한다. 브라우저는 받은 즉시 내용을 표시할 수 있으므로 첫 화면이 빨리 보이고, 크롤러도 완전한 문서를 읽을 수 있어 SEO(Search Engine Optimization)에 유리하다. 다만 서버가 그린 HTML은 아직 이벤트 핸들러가 붙지 않은 정적인 그림이다. 이후 브라우저가 자바스크립트를 내려받아 이미 있는 DOM에 상태와 이벤트를 연결하는 과정을 거쳐야 비로소 상호작용이 가능해지는데, 이를 하이드레이션(Hydration)이라 부른다. 그래서 SSR 페이지는 보이는 시점과 조작 가능한 시점 사이에 간격이 생길 수 있고, 렌더링 연산이 서버에 집중되므로 트래픽이 늘면 서버 비용이 함께 늘어난다. 넥스트(Next.js)와 넉스트(Nuxt)가 대표적인 SSR 지원 프레임워크다.

SSG와 ISR, 그리고 혼합 전략

렌더링 시점을 요청 때가 아니라 빌드 때로 앞당긴 것이 SSG(Static Site Generation)다. 빌드 시 모든 페이지를 HTML 파일로 만들어 CDN(Content Delivery Network)에 올려 두면, 요청마다 연산 없이 파일만 내려주므로 가장 빠르고 저렴하다. 대신 내용을 바꾸려면 다시 빌드해야 하므로 블로그나 문서처럼 갱신이 드문 콘텐츠에 맞는다. ISR(Incremental Static Regeneration)은 정적 페이지를 일정 주기나 요청 계기로 백그라운드에서 다시 생성해, 정적의 속도와 준실시간 갱신을 절충한다. 최신 프레임워크는 여기서 더 나아가 서버 컴포넌트(Server Component)처럼 화면의 일부만 서버에서 렌더링하고 상호작용이 필요한 부분만 클라이언트 코드로 보내는 세분화된 전략을 제공한다. 결국 실무의 질문은 CSR이냐 SSR이냐가 아니라, 페이지 단위 혹은 컴포넌트 단위로 어떤 렌더링 시점이 적절한가로 바뀌고 있다.