오랫동안 프론트엔드 시장을 지배하고 있는 프레임워크들(React, Vue, Angular)은 모두 SPA 기반 프레임워크입니다. 왜 SPA일까? 하는 궁금증이 들어서 이번 포스트는 SPA에 대해 알아볼까합니다.
SPA 개념 및 구조
SPA란 무엇인가?
SPA(Single-Page Application) 는 모든 필요한 코드(HTML, JavaScript 및 CSS)를 최초에 한 번만 브라우저로 로드하고, 이후에는 페이지 간 전환이 발생할 때 필요한 데이터만을 비동기적으로 불러와서 동적으로 페이지를 업데이트하는 웹 애플리케이션 형태입니다.
SPA의 작동 원리
사용자가 SPA에 접속하면, 최초에 하나의 HTML 파일과 관련된 정적 자원(CSS, JavaScript 등)이 브라우저에 다운로드됩니다. 이때 HTML 파일은 기본적인 페이지 구조와 비어있는 컨테이너를 가지고 있습니다.
사용자 상호작용에 따라 필요한 데이터를 서버에 요청하고 받은 데이터로 페이지의 특정 부분을 동적으로 업데이트합니다. 사용자가 애플리케이션 내에서 다른 페이지로 이동하면, 브라우저는 전체 페이지를 다시 로드하는 대신 필요한 데이터와 뷰만 업데이트합니다.
이를 가능하게 하는 것이 SPA의 핵심인 라우팅(Routing)입니다. 라우팅은 URL의 변화를 감지하고 해당하는 뷰를 효과적으로 업데이트합니다. 페이지는 새로고침 되지 않고 빠르고 부드러운 사용자 상호작용을 제공합니다.
그럼 기존의 방식은 어떤 방식일까요?
전통적인 방식, MPA
MPA(Multi-Page Application) 란 여러 개의 페이지로 구성된 웹 애플리케이션을 의미합니다. MPA는 전통적인 웹 애플리케이션 아키텍처로, 각 페이지 간에 전체 HTML을 새로 불러와서 화면을 갱신합니다.
MPA의 작동 원리
사용자가 MPA에 접속하면, 초기에 기본 HTML 파일 및 관련 리소스(CSS, JavaScript 등)가 브라우저로 다운로드됩니다.
사용자가 다른 페이지로 이동하거나 새로고침을 하면, 브라우저는 해당 페이지에 대한 새로운 HTML을 서버에 요청하고 받아옵니다. 이때 전체 페이지가 다시 로딩되기 때문에 새로고침 시간이 소요됩니다.
MPA에서는 서버 측에서 각 페이지의 HTML을 동적으로 생성하는 서버 사이드 렌더링(SSR)이 일반적입니다. 서버는 각 페이지에 대한 요청을 받으면 서버에서 해당 페이지의 HTML을 생성하고 클라이언트에게 전송합니다.
SPA와 MPA 비교
SPA와 MPA의 차이점은 무엇일까요?
로딩 속도
SPA는 초기에 필요한 모든 자원을 다운로드하고 이후 페이지 간 전환이 발생할 때 필요한 데이터만을 비동기적으로 받아와 뷰를 업데이트합니다. 이로써 사용자 경험이 향상되고 빠른 페이지 로딩이 가능합니다.
MPA는 각 페이지 이동 시에 전체 페이지를 다시 로딩하므로 초기 로딩 속도가 느릴 수 있습니다.
사용자 경험
SPA는 페이지 전환이 부드럽고 빠르며, 필요한 부분만 업데이트되므로 사용자 경험이 좋습니다.
MPA는 페이지 간 전환이 발생할 때마다 전체 페이지를 로딩하기 때문에 사용자가 페이지를 이동할 때 마다 화면이 깜빡이는 현상이 발생할 수 있습니다.
서버 요청
SPA는 초기 로딩 이후 서버와의 통신이 필요한 경우에만 필요한 데이터를 요청하므로, 서버 부하가 상대적으로 낮을 수 있습니다.
MPA는 각 페이지 이동 시에 서버로부터 전체 페이지를 요청하므로 서버에 높은 부하를 주게 됩니다.
결론적으로 SPA는 빠른 사용자 경험과 적은 서버 부하를 제공하는 반면, MPA는 전통적인 웹 애플리케이션 방식으로 동작하며 초기 로딩 속도가 느릴 수 있습니다.
SPA의 핵심 구성 요소
Client Side Routing
SPA에서는 페이지 이동이 브라우저 측에서 처리되기 때문에 클라이언트 사이드 라우팅이 필요합니다. 이를 통해 페이지 간 전환이 부드럽게 이루어집니다. 브라우저의 URL이 변경될 때마다 해당하는 뷰로 전환되어야 합니다. 이는 라우팅을 통해 구현됩니다.
페이지를 새로고침하지 않고 필요한 부분만 업데이트하여 사용자에게 빠르고 부드러운 경험을 제공합니다.
View Rendering
SPA에서는 데이터가 업데이트될 때마다 동적으로 뷰를 업데이트합니다. 사용자와의 상호작용에 따라 동적으로 인터페이스를 업데이트할 수 있습니다. 일반적으로 컴포넌트 기반 아키텍처를 사용하여 UI를 구성하며, 이는 재사용성과 유지보수의 용이성을 제공합니다.
상태 관리
SPA에서는 클라이언트 측에서 상태를 효과적으로 관리해야 하며, 상태 관리 라이브러리나 프레임워크를 사용합니다. 상태 관리 라이브러리를 사용하여 어플리케이션 상태를 중앙에서 효과적으로 관리합니다. 상태 관리를 통해 데이터 흐름을 일관성 있게 유지할 수 있습니다.
데이터 통신
SPA에서는 서버와의 비동기 통신을 통해 필요한 데이터를 로드하며, 이를 통해 효율적인 데이터 관리가 가능합니다.
SPA의 장점과 한계
장점 1. 사용자 경험 개선
SPA는 페이지 간의 전환 시에 전체 페이지를 다시 로드하지 않고 필요한 부분만 업데이트하므로, 사용자에게 부드러운 경험을 제공합니다. 클라이언트 측에서 페이지를 동적으로 렌더링하고 필요한 데이터를 비동기적으로 가져와 업데이트하므로, 페이지 전환이 빠르게 이루어집니다. SPA는 동적으로 뷰를 업데이트하므로, 사용자 인터페이스가 부드럽고 화면 갱신이 빠릅니다.
사례: 대화형 웹 애플리케이션 - 대시보드
SPA는 대화형 요소가 많은 웹 애플리케이션, 특히 대시보드와 같이 실시간으로 데이터를 업데이트해야 하는 애플리케이션에서 특히 효과적입니다.
장점 2. 개발 효율성
SPA는 프론트엔드와 백엔드를 분리함으로써 개발자들이 독립적으로 작업할 수 있어 개발 효율성을 향상시킵니다. SPA에서는 프론트엔드와 백엔드가 독립적으로 개발되기 때문에, 서로간의 의존성이 줄어들어 유지보수와 확장성이 향상됩니다. SPA는 컴포넌트 기반 아키텍처를 채택하여, 재사용 가능한 컴포넌트를 쉽게 작성하고 관리할 수 있습니다.
사례: 모듈화된 컴포넌트의 재사용
컴포넌트 기반 아키텍처를 통해 모듈화된 컴포넌트를 개발하고 재사용함으로써 코드의 일관성을 유지하고 유지보수를 용이하게 합니다.
단점 1. 초기 로딩 시간
SPA는 초기에 필요한 모든 자원을 다운로드하기 때문에 초기 로딩 시간이 길어질 수 있습니다.
최적화 전략
- 코드 분할 (Code Splitting): 필요한 모듈을 나누어 로딩하여 초기 로딩 시간을 최소화합니다.
- 레이지 로딩 (Lazy Loading): 필요한 시점에 필요한 모듈을 동적으로 로딩하여 초기 로딩을 최적화합니다.
단점 2. SEO 최적화 문제
검색 엔진은 SPA를 제대로 크롤링하지 못할 수 있어 SEO에 문제가 발생할 수 있습니다.
해결 전략
- 서버 사이드 렌더링(SSR): 서버에서 초기 페이지 렌더링을 수행하여 검색 엔진이 적절한 내용을 수집할 수 있도록 합니다.
- 프리렌더링: 미리 HTML을 생성하여 정적 파일로 제공함으로써 SEO 문제를 완화할 수 있습니다.
단점 3. 브라우저 호환성 문제
모든 브라우저에서 JavaScript의 최신 기능을 지원하지 않을 수 있습니다.
대응 전략
- 폴리필 (Polyfill): 브라우저가 지원하지 않는 기능을 자동으로 제공하여 호환성을 유지합니다.
- Babel과 같은 트랜스파일러 사용: 최신 JavaScript 문법을 이전 버전으로 변환하여 모든 브라우저에서 동작할 수 있도록 합니다.