[Web] CSR과 SSR

웹 애플리케이션의 유형과 개념에 대한 정리. 각 애플리케이션의 구조, 페이지 전환 방식, 데이터 관리 방식, 사용자 경험 등에 따른 분류와 각각의 장단점에 대해 알아보자

 

 

1. 웹 애플리케이션의 기본 구조 : SPA & MPA

2. 웹 렌더링 방식 : CSR & SSR

3. 정적 렌더링 : SSG & ISR

4. 최신 웹 아키텍쳐

 

 

아래 다뤄볼 개념에 대한 미리보기로 개념에 대한 연관관계는 다음과 같이 볼 수 있다. 

MPA (전통적인 방식)
 ├── SSR (서버에서 렌더링하여 SEO 최적화)
 ├── CSR (클라이언트에서 렌더링, 인터랙티브한 UI)
 └── SSG (정적 페이지 미리 생성하여 배포)
      ├── ISR (정적 사이트 + 부분적 실시간 업데이트)
      └── JAMstack (SSG + API 기반 개발)
          └── PWA (웹을 네이티브 앱처럼 활용)
SPA (단일 페이지 애플리케이션)
 ├── CSR (클라이언트 렌더링, 빠른 UX)
 ├── SSR (SEO 고려한 동적 페이지)
 └── PWA (오프라인 및 설치형 웹앱)

 

웹 애플리케이션의 기본 구조 : SPA & MPA

SPA (Single Page Application)

 

하나의 HTML 페이지로 구성된 애플리케이션으로, 페이지 전환이 발생할때 마다 전체 페이지를 다시 로드하지 않고, 필요한 부분만 동적으로 업데이트 합니다. 

 

특징

• 페이지 전환 시, 전체 페이지를 새로고침하지 않고 필요한 데이터만 서버에서 가져온다
• 클라이언트 측의 Javascript가 대부분의 렌더링을 수행한다
• 웹앱과 같은 상호작용이 많은 사이트에 적합하다

장점

• 빠른 페이지 전환으로 부드러운 사용자 경험 제공 
• 서버의 부하가 낮다

단점 

• 초기 로드 시간이 길 수 있다
• SEO (검색 엔진 최적화) 가 어려움 : 이유는 SPA는 초기 HTML 문서에서는 기본적인 구조만 제공되며, 사용자의 요청에 따라 클라이언트측에서 필요한 정보가 Javascript 실행 후 나타나기 때문에 크롤러가 이 콘텐츠를 제대로 인덱싱 하지 못할 수 있다

예시 : Gmail, Google Maps, Facebook 

 

MPA (Multi Page Application)

 

여러개의 HTML 페이지로 구성된 애플리케이션으로 사용자가 새로운 페이지를 요청할 때 마다 전체 페이지를 새로 로드한다. 

 

특징

• 각 페이지가 독립적으로 서버에서 렌더링되어 사용자가 페이지 전환할 때 마다 서버 요청이 발생하고 전체 페이지가 새로고침 된다. 가장 중요한 특징으로 요청이 발생할때 Flickering 현상이 발생한다

장점 

• HTML에 모든 정보가 한번에 로드되기에 SEO 최적화가 용이하다
• 페이지 단위로 독립적으로 작동함으로 복잡한 사이트 구조를 관리하기에 적합하다

예시 : 전자상거래 웹사이트 , 구글 검색

 

웹 렌더링 방식 : CSR & SSR 

클라이언트 사이드 렌더링 (CSR)

 

사용자의 요청에 따라 필요한 부분만 응답받아 렌더링 

 

특징 

• 클라이언트에서 초기화면을 로드하기 위해 서버에 요청을 보낸다
• 서버는 화면을 구성하기 위한 최소한의 HTML을 응답한다
• 추가 Javascript 요청이 발생하면, 요청한 내용에 대해서만 서버가 응답한다

장점은 빠른 속도와 서버의 부하가 감소하지만, 단점으로는 클라이언트 요청에 따라 필요한 부분만 응답하기 때문에 요청이 발생하지 않은 부분은 응답이 없어 검색 엔진 최적화에는 불리하다. 

 

서버 사이드 렌더링 (SSR)

 

서버에서 완전한 HTML을 렌더링하여 클라이언트에게 전달한다. 

 

특징

• 초기 로딩 시간이 빠르며 검색 엔전 최적화에 유리하다

여기서 의문점이 들 수 있다. 서버에서 완전한 HTML을 로드해서 보내주는거면 초기 로딩이 더 길어야 하는것 아닌가? 처음부터 완전한 정보를 다 받아오는 시간이 더 길지 않을까?

 

이 부분은 관점에 따라 참일 수도 거짓일 수도 있다. 만약 10개의 데이터만 초기 로딩 화면에서 보여지면 된다면, SSR이 CSR 보다 초기 로딩 시간이 더 빠를 것이다. 서버에서는 완성된 데이터를 바로 HTML에 넣어서 보여주는 반면, CSR 방식에서는 자바스크립트가 다운로드되고 실행될 때 까지 사용자는 " 빈 화면 " 을 보고있을 가능성이 높기 때문이다. 

 

하지만 초기 로딩 화면에서 1억개의 데이터를 한 번에 로딩해야 하는 경우, SSR은 1억개의 데이터를 초기 화면에 로딩해야 하며, 페이지 전환이 될 때마다 많은 데이터를 다시 전달해야 하기에 서버에 부담이 높아질 것이다. 하지만 CSR 방식에서는 초기 화면에서 1억개의 데이터를 전부 받아오지 않고 사용자의 요청에 따른 데이터만 보여주면 되기에 더 빠르다고 느껴질 것이다. 

 

결국 어떤 데이터를 어떻게 얼만큼 보여줄 것인지에 따라서 각 방식의 장단점이 명확해 질 것이다. 

 

정적 렌더링 : SSG & ISR 

다음은 SSR 방식에서 서버에서는 어떻게 HTML을 미리 생성하는지에 따라 방식이 나뉜다. 

 

SSG (Static Site Generation)

 

빌드(배포) 시점에 미리 HTML을 생성하여 정적 파일로 저장하는 방식으로 사용자가 요청할 때 서버가 아닌 CDN(Content Delivery Network)에서 HTML을 제공한다. 

 

장점

• 가장 빠른 로딩 속도
• 서버 부하 없으며 트래픽이 많아도 비용이 저렴하다 (서버에서 동적 처리가 필요 없고 CDN에서 제공되어 서버 부담이 없다) 

단점

• 실시간 데이터를 반영하려면 빌드로 새로운 HTML 파일을 추가해야 한다
• 자주 업데이트가 필요한 데이터에는 부적합하다 (예. 뉴스, 주식 정보)

ISR (Incremental Static Regeneration)

 

기본적으로는 SSG 처럼 동작하지만 특정 주기로 다시 빌드 가능하다

 

동작 방식

• 초기 빌드 시 SSG 처럼 정적 HTML을 생성하여 CDN에 배포한다
• 사용자가 첫 요청을 하면 CDN에서 기존 정적 HTML을 제공한다
• 특정 시간이 지나거나 트리거 발생 시 서버가 백그라운드에서 새로운 HTML을 생성한다
• 이후 요청되는 데이터부터 최신 HTML을 제공한다

단점

• 최신 데이터가 반영될 때까지 지연 시간 존재
• 캐싱 이슈 발생 가능 (새로운 HTML이 생성되기 전까지는 구버전 노출) 

최신 웹 아키텍쳐

JAMstack = Javascript + API + Markup

정적 사이트와 API를 활용하는 아키텍쳐 패턴으로, 아래 조합으로 동작하는 방식이다. 

* JAMstack 은 SSG와 밀접한 관계로 CDN을 활용해 빠른 배포가 가능하다

 

Javascript : 동적 인터페이스를 담당 (React, Vue) 

API : 백엔드와 데이터를 주고 받음 (REST, GraphQL 등) 

Markup : HTML을 정적으로 생성 (SSG 기반)

 

왜 이런 방식이 등장했을까?

 

기존 방식의 문제점

1. 페이지 로딩 속도 문제 : 서버에서 매번 동적으로 HTML을 생성하면 느려지고 대량 트래픽이 발생하면 서버 부하가 증가한다
2. 서버 부담이 크다 : 모든 요청을 서버에서 처리해야 하므로, 비용이 증가하고 확장성이 떨어진다
3. 보안 문제 : 백엔드가 직접 데이터를 제공하여 보안 취약점이 발생할 가능성이 높고, ** 서버 다운 시 모든 서비스 중단 **

연결성과 확장성이 중요한 현대사회에서 기존의 방식은 한계가 있었다.

 

CDN은 다양한 방면에서 이점을 준다. 

1. HTML을 CDN에서 응답하여 빠른 속도를 제공한다
2. CDN에서 API로 응답하기에 서버 해킹 위험이 낮고 서버의 부하를 줄일 수 있다

기업의 마케팅 페이지 등, HTML로만 구성이 가능한 페이지는 서버리스로도 운영이 가능해진다. 

 

PWA (Progressive Web App)

 

웹을 네이티브 앱처럼 동작하게 만드는 기술로, 서비스 워커를 사용해 오프라인에서도 동작 가능하다. 이 기술의 핵심은 웹과 네이티브 앱이 분리되어있던 것을 결합해주는데 있다. 

 

기존 방식의 문제점

 

웹사이트는 오프라인에서 접속이 어렵고, 모바일 환경에서는 앱처럼 홈 화면에 추가하는 기능을 지원하지 않는다. 

반면 네이티브 앱은 iOS, Android 각각 개발해야 함으로 개발 비용이 높으며 앱스토어 심사를 거쳐야 배포가 가능하다. 

웹과 앱을 결합하여 오프라인에서도 실행 가능함과 동시에 앱의 배포 프로세스 없이 바로 사용 가능하게 하는 기술이다. 

 

PWA는 SPA + CSR 과 조합되는 경우가 많으며 오프라인 기능이 필요한 웹앱에 적합하다 (예. Spotify Web, Twitter Lite)