[BE] SPA와 MPA 아키텍처 이해

서론

현대의 웹 애플리케이션은 사용자에게 더욱 풍부하고 인터랙티브한 경험을 제공하기 위해 다양한 아키텍처 패턴을 발전시켜 왔습니다. 그중에서도 Single-Page Application (SPA)과 Multi-Page Application (MPA)은 웹 개발의 두 가지 주요 접근 방식이며, 각각의 장단점이 명확합니다. 실무에서 프로젝트를 기획하거나 기술 스택을 결정할 때 이 두 가지 아키텍처의 특성을 이해하는 것은 매우 중요합니다. 본 포스트에서는 SPA와 MPA의 개념을 살펴보고, 각각의 특징과 실무 적용 시 고려사항에 대해 다루겠습니다.

본론

1. Multi-Page Application (MPA)

MPA는 전통적인 웹 애플리케이션 구조로, 여러 개의 페이지로 구성됩니다. 사용자가 다른 페이지로 이동할 때마다 서버로부터 새로운 HTML 문서를 전송받아 페이지 전체를 새로 로드합니다.

작동 방식:

1. 사용자가 웹 페이지 요청 (예: /products).
2. 서버는 요청에 해당하는 HTML, CSS, JavaScript 파일을 생성하여 응답.
3. 브라우저는 페이지 전체를 새로 렌더링.
4. 다른 페이지로 이동 (예: /about) 시, 위 과정 반복.

장점:

• SEO (검색 엔진 최적화): 각 페이지가 독립적인 HTML 파일을 가지므로, 검색 엔진 크롤러가 사이트의 모든 콘텐츠를 쉽게 탐색하고 색인화할 수 있습니다.
• 개발 용이성 (초기 단계): 간단한 웹사이트의 경우, 각 페이지를 독립적으로 구성하는 방식이 직관적이고 개발 시작이 빠를 수 있습니다.
• 접근성: 브라우저의 뒤로 가기/앞으로 가기 버튼이나 북마크 기능이 자연스럽게 작동합니다.
• 초기 로딩 속도 (부분적으로): 첫 페이지 로딩 시 필요한 리소스만 로드하므로, 전체 애플리케이션이 매우 클 경우 SPA보다 초기 로딩이 빠를 수 있습니다.

단점:

• 사용자 경험 저하: 페이지 이동 시마다 전체 페이지가 새로고침되므로 깜빡임 현상이 발생하고, SPA에 비해 매끄럽지 못한 사용자 경험을 제공할 수 있습니다.
• 서버 부하 증가: 매번 새로운 HTML 파일을 서버에서 생성하여 전송해야 하므로 서버에 부담이 갈 수 있습니다.
• 프런트엔드와 백엔드의 강한 결합: 뷰 로직이 백엔드에 강하게 의존하는 경향이 있어, 프런트엔드 개발의 독립성이 떨어질 수 있습니다.

2. Single-Page Application (SPA)

SPA는 단일 HTML 파일만을 로드하고, 페이지 이동 시 필요한 데이터만 서버로부터 받아와 동적으로 DOM을 업데이트하는 방식입니다. 초기 로딩 이후에는 전체 페이지 새로고침 없이 사용자에게 연속적인 경험을 제공합니다.

작동 방식:

1. 사용자가 웹 페이지 요청 (예: /).
2. 서버는 단일 HTML 파일 (기본 껍데기)과 애플리케이션에 필요한 JavaScript 파일을 응답.
3. 브라우저는 JavaScript를 실행하여 페이지 내용을 렌더링.
4. 사용자가 다른 기능/페이지로 이동 (예: /products) 시, 서버에 필요한 데이터만 요청 (AJAX/Fetch API).
5. 받아온 데이터로 JavaScript가 현재 페이지의 일부만 동적으로 업데이트. 전체 페이지 새로고침 없음.

장점:

• 매끄러운 사용자 경험: 전체 페이지 새로고침 없이 화면의 일부만 업데이트되므로, 데스크톱 애플리케이션과 같은 부드러운 전환과 인터랙션을 제공합니다.
• 성능 향상 (초기 로딩 후): 한 번 리소스를 로드하면 이후에는 데이터만 주고받으므로, 불필요한 리소스 요청이 줄어들어 반응 속도가 빠릅니다.
• 프런트엔드와 백엔드의 분리: API를 통해 데이터만 주고받으므로, 백엔드와 프런트엔드의 독립적인 개발이 용이합니다. (예: RESTful API)
• 모바일 앱 개발 용이: 웹과 모바일 앱 간에 백엔드 API를 공유할 수 있어 개발 효율성이 높아집니다.

단점:

• SEO 불리: 초기 로딩 시 빈 HTML 껍데기만 제공되는 경우가 많아, 검색 엔진 크롤러가 콘텐츠를 파악하기 어렵습니다. (서버 사이드 렌더링(SSR) 또는 정적 사이트 생성(SSG)으로 보완 가능)
• 초기 로딩 시간: 애플리케이션에 필요한 모든 JavaScript 리소스를 처음 한 번에 로드하므로, MPA에 비해 초기 로딩 시간이 길 수 있습니다.
• 보안 문제: 클라이언트에 중요한 정보를 노출할 위험이 있고, XSS(크로스 사이트 스크립팅) 공격에 취약할 수 있습니다.
• 브라우저 히스토리 관리: 자체적인 라우팅 및 히스토리 관리가 필요합니다.

3. 실무 관점에서 선택 가이드

• MPA가 적합한 경우:
  • 콘텐츠 양이 방대하고 SEO가 매우 중요한 블로그, 뉴스 사이트, 쇼핑몰 등.
  • 매우 간단하여 동적인 상호작용이 거의 필요 없는 웹사이트.
  • 초기 개발 속도가 중요한 소규모 프로젝트.
  • 구형 브라우저 지원이 필요한 경우.
• SPA가 적합한 경우:
  • 풍부한 인터랙션과 실시간 업데이트가 필요한 대시보드, 관리자 페이지, 협업 도구.
  • 높은 수준의 사용자 경험을 제공해야 하는 서비스 (Gmail, Trello, Facebook 등).
  • 모바일 앱과의 연동성이 중요한 서비스.
  • 프런트엔드와 백엔드의 명확한 분리가 필요한 대규모 프로젝트.
  • React, Angular, Vue.js와 같은 현대적인 프레임워크/라이브러리 사용이 가능한 환경.

정리

SPA와 MPA는 웹 애플리케이션의 사용자 경험, 성능, 개발 편의성, SEO 등 다양한 측면에서 뚜렷한 차이를 보입니다. MPA는 전통적인 접근 방식으로 SEO와 단순한 구조에 강점을 가지지만, 사용자 경험 측면에서는 SPA에 비해 제약이 있습니다. 반면 SPA는 부드러운 사용자 경험과 높은 상호작용성에 강점을 보이지만, SEO와 초기 로딩 시간이라는 도전 과제를 안고 있습니다.

따라서 어떤 아키텍처를 선택할지는 프로젝트의 목표, 주요 기능, 사용자 요구사항, 개발 팀의 역량 등을 종합적으로 고려하여 결정해야 합니다. 최근에는 SPA의 단점을 보완하기 위해 SSR(Server-Side Rendering)이나 SSG(Static Site Generation) 같은 기술들이 발전하면서 SPA의 활용 범위가 더욱 넓어지고 있습니다.

Reference

• SPA vs MPA: Which Architecture is Better?