MPA와 SPA 그리고 SSR과 CSR을 알아보자

MPA (Multi Page Application)란?

MPA는 전통적인 웹 애플리케이션 형태로, 여러 개의 HTML 페이지로 구성된다.

각 페이지는 독립적인 HTML 파일로 존재하며 사용자가 페이지를 이동할 때마다 서버에서 해당 HTML 파일을 받아와 브라우저에서 렌더링합니다. 이러한 방식은 웹 개발 초창기부터 사용되어 왔으며 간단한 웹사이트나 콘텐츠 중심의 웹 서비스에 적합하다.

 

MPA의 장점

• 검색 엔진 최적화(SEO)에 용이: 각 페이지가 독립적인 URL과 콘텐츠를 가지므로 검색 엔진이 페이지를 쉽게 크롤링하고 색인할 수 있다.
• 브라우저 호환성 문제가 적다: MPA는 오래된 브라우저에서도 잘 작동하며, 특별한 기술이나 라이브러리가 필요하지 않다.
• 서버 측 렌더링으로 인해 서버에서 추가적인 보안 제어가 가능하다: 민감한 데이터나 로직을 서버 측에서 처리하고 클라이언트에게는 필요한 정보만 전달하여 보안을 강화할 수 있다.

MPA의 단점

• 페이지 이동마다 로딩 시간이 소요된다: 새로운 페이지를 로드할 때마다 서버에 요청을 보내고 HTML, CSS, JavaScript 등의 리소스를 다시 다운로드해야 하므로 페이지 이동 속도가 느려질 수 있다.
• 페이지 이동마다 서버에 요청을 하므로 서버 부하가 높을 수 있다: 사용자의 모든 요청을 서버가 처리해야 하므로 트래픽이 많은 경우 서버에 부담이 될 수 있다.
• 사용자 경험(UX) 측면에서 페이지 전환이 abrupt 하다: 페이지 이동 시 화면 전체가 깜빡이며 다시 로딩되므로 사용자 경험이 매끄럽지 못할 수 있다.

SPA (Single Page Application)란?

SPA는 최신 웹 개발 트렌드를 반영한 웹 애플리케이션 형태로 단일 페이지로 구성된다. 초기 로딩 시 하나의 HTML 파일과 JavaScript 번들을 다운로드하고 이후에는 페이지 이동 없이 JavaScript를 사용하여 필요한 콘텐츠만 서버에서 가져와 동적으로 업데이트한다. 이러한 방식은 React, Angular, Vue.js와 같은 JavaScript 프레임워크나 라이브러리를 사용하는 개발 환경에서 주로 사용되며 인터랙티브하고 동적인 웹 애플리케이션 개발에 적합하다.

 

SPA의 장점:

• 페이지 이동이 부드럽고 빠르다: 페이지 전체를 다시 로드하지 않고 필요한 부분만 업데이트하므로 페이지 이동 속도가 빠르고 사용자 경험이 매끄럽다.
• 모듈화 또는 컴포넌트 개발이 편리해진다: UI를 재사용 가능한 컴포넌트 단위로 개발하여 코드의 유지 보수성과 확장성을 높일 수 있다.
• 필요한 데이터만 서버에서 가져오므로 서버 부하가 낮아진다: 페이지 이동 시 전체 페이지를 다시 로드하는 대신 필요한 데이터만 AJAX 요청을 통해 가져오므로 서버 부하를 줄일 수 있다.

SPA의 단점:

• 초기 페이지 로딩 시간이 길어질 수 있다: 초기 로딩 시 모든 JavaScript 번들을 다운로드해야 하므로 초기 로딩 시간이 길어질 수 있다.
• 검색 엔진 최적화(SEO)에 불리할 수 있다: JavaScript를 사용하여 동적으로 콘텐츠를 생성하므로 검색 엔진이 페이지를 크롤링하고 색인하는 데 어려움을 겪을 수 있다. 이를 해결하기 위해 서버 사이드 렌더링(SSR)이나 Pre-rendering 등의 기술을 적용해야 한다.
• 일부 오래된 브라우저 지원이 부족할 수 있다: SPA는 최신 JavaScript 기능을 사용하므로 오래된 브라우저에서는 제대로 작동하지 않을 수 있다.

SPA와 MPA의 차이점

Lifecycle 참고 이미지

 

특징	MPA	SPA
페이지 구성	여러 개의 HTML 페이지	단일 HTML 페이지
페이지 이동	페이지 이동 시 전체 페이지 다시 로드	페이지 이동 없이 콘텐츠 동적 업데이트
렌더링 방식	주로 서버 사이드 렌더링(SSR)	주로 클라이언트 사이드 렌더링(CSR), 필요에 따라 SSR 적용 가능
초기 로딩 속도	빠름	느릴 수 있음
페이지 이동 속도	느림	빠름
SEO	유리	불리할 수 있음 (SSR 또는 Pre-rendering 필요)
브라우저 호환성	높음	낮을 수 있음
개발 복잡성	낮음	높음
사용자 경험	페이지 전환 시 깜빡임 발생	페이지 전환이 부드러움
적합한 웹 서비스 유형	콘텐츠 중심 웹 서비스, 간단한 웹사이트	인터랙티브 웹 애플리케이션, 복잡한 웹 서비스

 

SSR (Server-Side Rendering)

사용자 요청 시 서버는 필요한 데이터를 가져와 해당 데이터를 기반으로 HTML을 생성한다.

생성된 HTML은 클라이언트에게 전송되고, 브라우저는 이를 렌더링하여 사용자에게 보여준다.

주로 콘텐츠 중심의 웹사이트나 초기 로딩 속도 및 SEO가 중요한 애플리케이션에 적합하다. (브라우저 로봇의 크롤링 용이)

• 특징:
  • 서버에서 페이지의 HTML을 생성하여 클라이언트에게 전달한다.
  • 초기 로딩 속도가 빠르며, 사용자는 즉시 콘텐츠를 볼 수 있다.
  • 검색 엔진 최적화(SEO)에 유리합니다. 검색 엔진 크롤러는 JavaScript 실행 없이도 서버에서 렌더링된 HTML 콘텐츠를 읽을 수 있다.
  • 서버 부하가 높아질 수 있다. 모든 요청마다 서버에서 HTML을 생성해야 하므로 많은 트래픽을 처리해야 하는 경우 서버 성능에 영향을 줄 수 있다.

CSR (Client-Side Rendering)

사용자 요청 시 서버는 빈 HTML 템플릿과 JavaScript 번들을 클라이언트에게 전달한다.

클라이언트는 JavaScript를 실행하여 필요한 데이터를 서버에 요청하고 받아온 데이터를 기반으로 HTML을 생성하여 페이지를 렌더링한다. 빈 HTML 템플릿을 전달주기 때문에 SEO에 불리한 경우가 있다.

• 특징:
  • 클라이언트(브라우저)에서 JavaScript를 사용하여 페이지의 HTML을 생성한다.
  • 초기 로딩 속도가 느릴 수 있습니다. 초기에는 빈 HTML 페이지만 로드되고 JavaScript 번들이 다운로드 및 실행된 후에 콘텐츠가 렌더링된다.
  • 페이지 이동 속도가 빠르고 사용자 경험이 매끄럽다. 페이지 이동 시 전체 페이지를 다시 로드하지 않고 필요한 부분만 업데이트한다.
  • 동적인 사용자 인터랙션 구현에 유리하다. JavaScript를 통해 사용자 입력에 실시간으로 반응하고 UI를 업데이트할 수 있다.
  • SEO에 불리할 수 있다. 검색 엔진 크롤러가 JavaScript 실행 결과를 완전히 이해하지 못할 수 있으므로, SSR 또는 Pre-rendering 등의 기술을 함께 사용해야 한다.

Hydration

서버에서 생성된 HTML에는 이미 콘텐츠가 포함되어 있으므로, 사용자는 빠르게 페이지를 볼 수 있다.

클라이언트 측 JavaScript가 로드되면 Hydration 과정을 통해 서버에서 렌더링된 HTML에 이벤트 핸들러를 연결하고 필요한 경우 추가적인 데이터를 가져와 동적으로 업데이트한다.

Hydration을 통해 사용자는 초기 로딩 후 즉시 페이지와 상호 작용할 수 있으며 검색 엔진은 서버에서 렌더링된 콘텐츠를 크롤링할 수 있다.

• 특징:
  • SSR로 생성된 정적인 HTML에 클라이언트 측 JavaScript를 연결하여 동적인 기능을 추가하는 과정이다.
  • SSR의 장점(빠른 초기 로딩, SEO)과 CSR의 장점(동적인 사용자 경험)을 모두 얻을 수 있다.
  • 사용자 인터랙션(이벤트 핸들러 등)을 활성화하고 필요한 경우 추가적인 데이터를 가져와 업데이트한다.

SSR with Hydration의 활용 예시

• Next.js: React 기반 프레임워크로, SSR, CSR, Hydration을 쉽게 구현할 수 있도록 지원힌다.
• Nuxt.js: Vue.js 기반 프레임워크로, SSR, CSR, Hydration을 쉽게 구현할 수 있도록 지원한다.

 

참고자료

• Next.js 공식 문서: https://nextjs.org/
• Nuxt.js 공식 문서: https://nuxtjs.org/
• ASP.NET - Single-Page Applications: Build