SSR의 부상, 현대 웹사이트가 바뀌는 이유

1. 개요

최근 웹 개발의 채용시장을 살펴보면, SSR(Server-Side Rendering) 기반의 Next.js와 같은 프레임워크의 사용 케이스가 두드러지게 많아졌습니다.

그렇다면 왜 이러한 변화와 추세가 현재에 와서 특히 두드러지게 됐을까요?

이를 알기 위해서는 웹의 변천사와 함께 CSR(Client-Side Rendering)과 SSR의 특징 및 장단점을 살펴보아야 합니다.

이 글에서는 CSR과 SSR의 개념을 정리하고, 각각의 특징과 장단점을 통해 현재 웹 개발의 트렌드가 왜 SSR 기반으로 변화하고 있는지를 살펴보겠습니다. 이를 통해 웹 개발의 최신 트렌드를 이해하고, 더 나은 기술 선택을 할 수 있는 기준을 제공하고자 합니다.

2. 웹사이트의 역사

우선 시작하기 앞서, 웹의 변천사를 알아봅시다.

2.1 Web1.0

초기 웹사이트, 일명 Web 1.0은 아래와 같은 특징을 가지고 있었습니다.

• 서버에 미리 만들어져있는 정적인 HTML파일을 클라이언트가 받아와 화면에 표현

• 정적인 파일을 그대로 가져와 보여주는 SSG(Static Site Generation) 방식을 사용

• 페이지가 이동할 때마다 HTML 파일을 새로 다운로드하여 화면을 업데이트하는 MPA(Multi Page Application) 방식을 사용

즉, Web 1.0 시대의 웹사이트는 사용자와의 상호작용을 최소화하고, 주로 정보를 제공하는 일방적인 방식으로 운영되었습니다.

따라서 사용자가 버튼을 클릭하거나 다른 페이지로 이동할 때마다 전체 HTML 페이지를 새로 다운로드하여 화면을 업데이트해야하는 문제점이 생긴거죠.

이로 인해 사용자는 매번 전체 페이지를 새로고침해야 하는 번거로움이 있었고, 서버에도 부담이 가중되었습니다.

“사과” , “바나나”와 같이 일부 요소만 다르더라도, 다른 페이지를 보기 위해 전체 HTML파일을 새로 받아와 갱신해야했다

2.2 Web2.0

1.0에서는 정적인 HTML파일만을 받아와야 했다면, 2.0 시대로 넘어가며, JavaScript의 등장과 함께 웹 페이지는 보다 동적이고 사용자 친화적인 형태로 발전하게 되었습니다.

특히, Ajax의 개발로 화면의 일부만을 동적으로 렌더링할 수 있게 되었으며, 이는 CSR(Client-Side Rendering)과 SPA(Single Page Application) 기술의 발전으로 이어졌죠.

• CSR(Client-Side Rendering)과 SPA(Single Page Application) 기술이 주목받기 시작

  • CSR : 클라이언트측에서 JS를 사용해 HTML을 동적으로 생성하고 렌더링하는 방식

  • SPA : 하나의 HTML 페이지 내에서 사용자의 요청에 따라 동적으로 내용을 변경하여, 전체 페이지를 새로 로드할 필요 없이 부분적인 화면 업데이트를 할 수 있는 기술

• Node.js, React등의 등장으로 CSR이 부흥

이렇게 CSR이 부흥하였으나, 초기 로딩 속도 및 검색 엔진 최적화 문제로 SSR이 다시 주목받기 시작하였고 더 나아가 SSR과 CSR을 혼용해서 사용하는 방식도 많이 생기게 되었습니다.

3. CSR

Client-Side Rendering, 줄여서 CSR은 웹페이지의 콘텐츠가 사용자의 브라우저에서 동적으로 생성되어 렌더링되는 방식입니다.

React.js와 같은 라이브러리를 예로 들면, HTML 문서의 body 태그 안에는 root라는 id를 가진 div 태그 하나만 존재하게 되고 실제 콘텐츠는 브라우저에서 JavaScript를 실행하여 동적으로 생성되고 렌더링됩니다.

단 하나의 div요소만 존재.

화면에 표현되는 모든 UI는 단 하나의 div내에서 클라이언트가 동적으로 JS를 통해 DOM을 생성해나간다!

즉, 서버에서는 HTML의 기본 구조와 JavaScript 파일의 링크만 전송하며, 나머지 콘텐츠는 클라이언트 측의 JavaScript가 담당하여 그리는 방식이죠.

이러한 CSR을 사용하면 자연스럽게 SPA 형태를 갖게 됩니다.

SPA는 하나의 HTML 페이지에서 사용자의 요청에 따라 동적으로 콘텐츠를 변경하고, 전체 페이지 새로고침 없이 부분적인 화면 업데이트가 가능하다는 특징을 가지고 있습니다.

(+) CSR은 SPA와 동일한 개념은 아니다. React에서 SSR을 구현하면, 여러 페이지에 걸쳐 렌더링이 가능하여 MPA 형태를 가질 수 있음

3.1 CSR의 과정

1. 사용자의 브라우저 방문, 서버에게 HTML 요청

2. 서버는 빈 HTML, CSS, JS리소스를 전달

3. 클라이언트는 HTML을 파싱하고 렌더링

   • 이때까지, 빈 HTML화면이 표현되고 있습니다.

4. HTML을 파싱하는 과정에서 “script” 태그를 만나게 되면 해당 JS 파일을 요청합니다.

   

   

   bundle.js파일을 다운로드 받습니다.

5. 브라우저는 JS를 실행하고 화면에 콘텐츠를 렌더링합니다.

   • 이때 비로소, 빈화면에서 실제 UI가 화면상에 표현됩니다. (이때부터 사용자와의 상호작용이 가능!!)

3.2 장단점

[장점]

1. TTV(Time to View, 콘텐츠를 볼 수 있는 시점)과 TTI(Time to Interact, 사용자가 상호작용할 수 있는 시점) 간의 간격이 짧거나 동일

   • 위의 과정에서 결국 화면상에 표현되는 시점(5번) 은 브라우저 내에서 JS를 실행한 이후 입니다. 즉 상호작용이 가능한 시점이 화면상에 UI가 표현되는 시점이겠죠.

2. 부드러운 사용자 경험 제공

   • 사용자가 페이지를 이동할 때 마다 동적으로 필요한 데이터만 가져와 부분적으로 렌더링하므로 화면전환이 빠릅니다.

3. 서버의 부하 감소

   • 렌더링 과정이 클라리언트에서 처리되므로 서버의 부담이 줄어듭니다.

[단점]

1. SEO취약

   • 초기에 가져오는 “빈 HTML”의 내용에서 색인을 생성할 수 없으므로 검색엔진에서 불리합니다.

   • 크롤러는 JS를 다운로드하고, 화면상에 그리는 과정을 기다리지 않거든요.

2. 초기 로딩 속도

   • 브라우저가 JS를 다운받고 DOM을 생성하는데 걸리는 시간을 더 기다려야하므로 사용자는 빈화면을 더 응시해야합니다.

3. 보안 이슈

   • 쿠키, 로컬스토리지에 저장되는 사용자 정보 도용에 취약합니다.

   • 핵심 기능이 클라리언트에서 수행되므로 로직의 노출가능성이 있습니다.

최근 검색 엔진들은 JavaScript를 실행할 수 있는 크롤러를 도입하고 있어 CSR 방식의 웹페이지도 인덱싱할 수 있습니다.

그러나 JavaScript를 실행하는 크롤러는 여전히 HTML 기반의 크롤러보다 느릴 수 있으며 모든 브라우저에서 호환되는 내용도 아닙니다.

참고 내용

4. SSR

SSR은 서버에서 페이지의 HTML을 렌더링하여 클라이언트로 보내주는 방식을 말합니다.

클라이언트는 서버로부터 받은 HTML을 그대로 렌더링하므로 추가적인 JS 실행 과정 없이 바로 화면에 콘텐츠를 표시할 수 있습니다.

HTML, CSS, JS리소스를 서버에서 렌더링하고 브라우저로 전달한다

위의 HTML정보를 서버에서 직접 렌더링하고 브라우저는 해당 내용을 보여줌

SSR의 대표적인 예로는 MPA(Multi Page Application) 형태의 웹사이트가 있습니다. MPA는 사용자가 다른 페이지로 이동할 때마다 새로운 HTML 문서를 서버로부터 받아오는 방식으로 동작합니다.

4.1 SSR의 과정

1. 사용자의 브라우저 방문, 서버에게 HTML 요청

2. 서버는 렌더링 준비가 된 HTML을 전달

3. 클라이언트는 HTML을 파싱하고 렌더링

   • 이 시점에서 화면상에 콘텐츠가 표현됩니다 (서버에서 생성해줌)

4. HTML을 파싱하는 과정에서 “script” 태그를 만나게 되면 해당 JS 파일을 요청합니다.

   • bundle.js파일을 다운로드 받습니다.

5. 브라우저는 JS를 실행하고 구성요소를 하이드레이션 합니다

   • 하이드레이션은 서버에서 렌더링된 정적 HTML에 클라이언트 사이드의 동적인 기능을 연결하는 과정

   • 이때부터 사용자와의 상호작용이 가능

즉 사용자에게 빠른 초기 로딩과 JS를 실행하고나서 원활한 상호작용을 제공합니다.

4.2 장단점

[장점]

1. SEO 최적화

   • 완성된 페이지 정보를 검색엔진이 쉽게 크롤링할 수 있어 SEO에 유리합니다.

2. 빠른 페이지 렌더링

   • 화면구성에 필요한 HTML 파일을 서버에서 바로 전달해주기 때문에 초기 페이지 로드 시간이 빠릅니다.

   • 상호작용이 별로 없거나, 콘텐츠 도달 시간이 중요한 앱에서 사용자 경험이 향상됩니다.

   • 서버에서 렌더링하므로 기기 및 브라우저 성능이 좋지 않아도 페이지 로딩이 빠르고 일관적입니다.

3. 보안

   • 서버에서 렌더링할 때 escaping과 같은 조치를 취할 수 있어 안정적입니다.
   • XSS 공격에 대한 위험이 낮으며, CSRF 공격의 노출 가능성도 CSR에 비해 적습니다.

[단점]

1. 화면 깜빡임 현상

   • 페이지 이동이나 변경사항에 대해 매번 새롭게 서버로부터 HTML을 다시 받아와야 하므로 깜빡임이 발생할 수 있습니다.

2. 서버의 부하 증가

   • 서버에서 렌더링 작업을 처리하기 때문에 사용자가 몰렸을 때 비용과 과부하의 위험성이 있습니다.

3. 사용자가 볼 수 있는 시점과 상호작용이 가능한 시점의 차이 발생

   • HTML과 JS 로드 시점이 다르기 때문에 상호작용을 위한 JS 다운로드 시간만큼 TTI 차이가 발생합니다.

5. 정리

위의 장단점을 표로 정리하면 아래와 같이 나타낼 수 있습니다.

	CSR	SSR
SEO	취약	유리함
초기 로딩 속도	느림	빠름
사용자 경험	부드러운 페이지 전환	화면 깜빡임 가능성
보안	취약	대응 가능
서버 부하	낮음	높음
상호작용 가능 시점	TTI 길 수 있음	TTI 짧음
개발 복잡도	상대적으로 낮음	상대적으로 높음

그럼 어떤 상황에 어떤 렌더링 방식을 선택하는게 좋을까요?

[CSR(Client-Side Rendering)을 선택해야 할 상황]

• 동적 컨텐츠가 주를 이루는 웹사이트

  • 예: 소셜 미디어, 대화형 웹 애플리케이션 등
  • 사용자와의 상호작용이 많고, 실시간으로 정보가 업데이트 되어야 하는 경우 CSR이 유리합니다.

• 데이터의 양이 많고 복잡한 웹사이트

  • 예: 대규모 쇼핑몰, 복잡한 대시보드 등
  • 클라이언트에서 데이터를 처리하여 화면에 표현함으로써 서버의 부담을 줄일 수 있습니다.

• SEO의 중요도가 낮은 웹사이트

  • 검색 엔진 최적화가 큰 영향을 미치지 않는 경우 CSR을 선택할 수 있습니다.

[SSR(Server-Side Rendering)을 선택해야 할 상황]

• 정적 컨텐츠가 주를 이루는 웹사이트

  • 예: 뉴스 사이트, 블로그 등
  • 사용자와의 상호작용이 적고, 정보가 정적인 경우 SSR이 유리합니다.

• 검색 엔진 노출이 중요한 웹사이트

  • SEO가 중요한 경우, 서버에서 렌더링하여 검색 엔진의 크롤링을 용이하게 함으로써 노출도를 높일 수 있습니다.

• 큰 규모의 온라인 쇼핑몰 등

  • 메인 스크립트가 무거운 경우, 서버에서 렌더링함으로써 초기 로딩 시간을 줄일 수 있습니다.

즉 사이트의 특징에 따라 적절한 렌더링 방식을 사용하거나, 다른 렌더링 방식을 사용할 수도 있습니다.

+) 초기 단계에서는 빠른 개발속도와 서버 부하가 적은 CSR을 사용하는게 좋습니다.

(간단한 데이터 처리가 클라이언트에서 이루어지면 서버 의존성이 적어 리소스를 줄일 수 있기때문)

Q. 그런데 SEO가 뭐길래 그렇게 중요한걸까요??

SEO는 웹사이트의 콘텐츠를 최적화하여 검색 엔진의 크롤러가 쉽게 인식할 수 있도록 합니다.

즉, 검색 결과에서의 노출을 향상시키고 가시성을 높여 운영에 대한 리소스를 절감시킬 수 있는 중요수단입니다.

(= 결국은 돈이다..!)

Google에 의하면 변경을 시작해서 성과가 나타날 때까지 보통 4개월에서 1년 정도 소요된다고 합니다. (단기간 마케팅이라면 굳이?)출처

6. 그 밖의 다른 방식

6.1 SSG

SSG(Static Site Generation)는 “빌드 시점에 HTML을 생성하는 방식”으로, 모든 URL에 대한 HTML을 생성하여 사용자 요청이 있을 때 서버에서는 정적인 페이지를 반환합니다.

이 정적 페이지들은 CDN에 저장되고 캐싱 서버를 통해 즉각적으로 전달됩니다.

이러한 방식은 서버가 동적으로 매번 페이지를 만들지 않아 성능이 빠르다는 장점이 있습니다. 또한, 미리 생성된 정적 페이지를 보여주기 때문에 지연이 적고 일관적이며, SEO에도 유리합니다.

6.2 ISR

ISR(Incremental Static Regeneration)는 “점진적으로 정적 페이지를 다시 생성하는 방식”으로, SSG의 방식에 “페이지 단위”로 정적 생성하는 차이점이 있습니다.

변경된 데이터를 기반으로 해당 페이지만 다시 로드하고 생성할 수 있으며, SSR과 같은 실시간 동적 데이터 반영이 가능합니다.

이 방식은 뉴스나 전자 상거래 사이트에 적합합니다.

ISR은 변경 사항이 있어도 SSG와 같이 전체 페이지를 다시 빌드하지 않아도 되며, 마치 SSG와 SSR의 장점을 결합한 하이브리드 방식이라 할 수 있습니다.

참고자료

프론트엔드 개발자가 알아야 할 브라우저 렌더링의 모든 것

https://nextjs.org/learn-pages-router/foundations/how-nextjs-works/rendering

https://nextjs.org/docs/pages/building-your-application/rendering/server-side-rendering

https://javascriptpatterns.vercel.app/patterns/rendering-patterns/client-side-rendering

https://javascriptpatterns.vercel.app/patterns/rendering-patterns/server-side-rendering

https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics?hl=ko