참고: https://choorai.com/map/spa-routing/
SPA 라우팅 기초
클라이언트 라우팅과 새로고침 404 문제의 원리
choorai.com
https://jeongola.tistory.com/entry/React-SPA-%EC%99%80-%EB%9D%BC%EC%9A%B0%ED%8C%85
[React] SPA 와 라우팅
1. SPA 와 라우팅 -Single Page Application • SPA(Single Page Application)은 하나의 페이지 요청으로 전체 웹앱을 사용하는 방식. • 유저는 웹페이지를 사용하며 모바일 앱 같은 경험을 느낌. -Multi Page Applicati
jeongola.tistory.com
https://tech.socar.kr/fe/2026/06/24/spa-cache-fallback-strategy-with-s3-cloudfront
S3 + CloudFront 기반 SPA 배포에서 캐시와 fallback 전략 설계하기
index.html, hashed assets, route-only rewrite를 분리해 배포 안정성 높이기
tech.socar.kr
https://hellosonic.tistory.com/267
[JavaScript] SPA와 History API
🚀 들어가며 프론트엔드 데브코스 강의를 듣는데 history API 파트가 나왔다. 마음이 너무 급했던 탓일까, 빠르게 이해하려고 보니 이해가 되지 않았다. 나에게 SPA는 생소한 개념이었고, SPA를 모르
hellosonic.tistory.com
진행 중인 캡스톤 디자인 프로젝트에서, 백엔드인 FastAPI 코드에서 spa 관련 함수 및 처리를 보았다. 프론트엔드로 SPA 방식인 React를 사용함에 따라 발생한 것으로 보인다. 이에 spa와 mpa, client-side routing, server-side routing에 대해 정리한다.
1. MPA(Multi Page Application)
서버에 전체 페이지를 빌드해 두고, 유저가 네비게이션 시 요청에 적합한 페이지를 브라우저에 전달하는 방식이다.
라우팅을 처리하는 기능이 서버에 있어(Server-side Routing), 서버에서 여러 페이지를 관리한다.
단점
- 페이지 요청마다 모든 리소스를 다시 받아오기에, 페이지 간 데이터를 재활용하기 힘들다.
2. SPA(Single Page Applicaton)
하나의 페이지 요청으로 전체 웹 애플리케이션을 사용하는 단일 페이지 앱이다.
라우팅을 처리하는 기능이 브라우저에 있어(Client-side Routing), javascript 라우터가 경로를 바꿔서 화면을 전환한다.
AJAX 기술을 활용해, 페이지 이동 시 서버에 데이터만 요청하고 페이지는 자바스크립트로 만든다.
브라우저에서 새로고침을 하면, 서버에 현재 경로를 직접 요청한다.
이때 서버가 해당 파일을 모르면, 404를 반환한다.
따라서 서버가 알 수 없는 경로는 index.html로 반환해서 javascript 라우터가 화면을 전환하도록 해야 하는데, 이를 Fallback이라 한다.
이때 Fallback이 너무 넓게 적용되면 백엔드 API 엔드포인트나 정적 파일의 요청까지 index.html로 바뀔 수 있다.
따라서 API 엔드포인트, 정적 파일을 먼저 매핑한 뒤에 Fallback을 적용해야 한다.
장점
- 페이지 진입 시 리로드없이 라우팅이 가능하다(유저는 웹페이지를 사용하면서 모바일 앱과 같은 경험을 할 수 있다).
- 서버에서 새로운 페이지를 만들 필요가 없으므로, 정적 파일을 CDN(분산 배치된 초고속 임시 저장소)에 미리 영구적으로 저장(캐싱)해 둘 수 있다(이때 index.html은 진입점이므로, 브라우저가 캐싱하지 않도록 설정해야 한다).
- 매번 페이지 요청을 할 필요가 없어 네트워크 요청이 줄어든다. 데이터 요청도 캐싱하여 재사용할 수 있어, 네트워크 부담을 줄이고 화면 로딩 속도를 높일 수 있다.
- 웹사이트를 하나의 앱으로 보아, 객체지향적이고 모듈화된 설계 기법들을 프론트엔드 화면 단에도 적용할 수 있다.
단점
- MPA 방식에 비해 검색 엔진 최적화(Search Engine Optimization)에 불리하다. 처음에 서버로부터 내용이 없는 텅 빈 HTML 뼈대와 javascript 파일만 받아오고 이후에 웹 브라우저가 javascript를 실행해 화면을 그리는데, 검색엔진 로봇은 javascript를 원활히 실행하지 못하거나 javascript 렌더링 큐에 지연 배치되어, 마치 아무 내용 없는 빈 껍데기처럼 인식하기 때문이다.
- 하나의 javascript 앱이 지속되는 것이므로, 메모리 관리와 성능, 데이터 활용 등이 중요하다.
- 하나의 거대한 javascript 앱을 전송받는 것이므로, 코드가 많아질수록 로드 속도가 느려진다(이를 해결하기 위해, 필요한 시점에 동적으로 청크를 받아오는 코드 스플리팅을 적용)
3. History API
SPA는 처음에 페이지 전체를 렌더링하고, 이후에는 특정한 부분만 AJAX를 통해 데이터를 받아서 렌더링을 한다.
화면 리로드 없이 URL을 변경하기 위해, History API를 사용한다.
페이지 이동 시 history.pushState()를 통해 화면 리로드 없이 브라우저 주소창의 URL과 History 스택을 직접 변경한다. 사용자가 브라우저의 뒤로 가기/앞으로 가기를 누르면 발생하는 popstate 이벤트를 감지하여 이전 상태의 컴포넌트를 렌더링한다.
4. 클라이언트 사이드 렌더링 VS 서버 사이드 렌더링
앞서 다룬 라우팅이 URL 변경 및 페이지 전환을 누가 처리하는지에 대한 얘기였다면,
렌더링(Rendering)은 화면 HTML을 어디서 그리는지에 대한 얘기다.
클라이언트 사이드 렌더링은 서버에서는 빈 HTML 뼈대와 javascript 파일만 받고, 웹 브라우저가 javascript를 실행해 화면을 그린다. 필요한 데이터는 비동기 API로 서버에 요청한다.
서버 사이드 렌더링은 서버가 완성된 HTML을 만들어서 브라우저에 보낸다.