SPA 이해

MPA(Multi Page Application)와 SPA(Single Page Application)는 다른 URL로 이동할 때 새 문서를 여는지, 실행 중인 문서 안에서 화면을 바꾸는지를 구분하는 탐색 구조입니다.

반면 CSR(Client-Side Rendering), SSR(Server-Side Rendering), SSG(Static Site Generation)는 첫 화면의 HTML을 어디에서 언제 만드는지를 설명합니다. 두 분류는 같은 축이 아니므로 SPA가 반드시 CSR이고 MPA가 반드시 SSR인 것은 아닙니다.

탐색 구조와 렌더링 전략은 서로 다른 축입니다

GET /products/42
→ 서버가 초기 HTML 생성
hydrateRoot → React 앱 시작
내부 Link → 같은 문서에서 탐색

MPA: 이동할 때 새 문서를 여는 구조

MPA에서는 일반적인 링크 이동이나 주소 입력이 브라우저의 문서 탐색(document navigation)을 일으킵니다. 브라우저는 목적 URL을 서버나 CDN에 요청하고 응답받은 HTML을 새 문서로 파싱합니다. 이전 문서의 JavaScript 실행 환경은 일반적으로 끝나지만, 브라우저가 문서를 bfcache에 보관해 뒤로·앞으로 이동에서 복원할 수도 있습니다.

여기서 “여러 페이지”는 URL마다 정적인 HTML 파일이 반드시 하나씩 있다는 뜻이 아닙니다. 서버가 요청 때 HTML을 만들 수도 있고(SSR), 빌드 때 만든 파일을 제공할 수도 있으며(SSG), 응답 문서가 브라우저에서 나머지 UI를 그릴 수도 있습니다(CSR).

MPA의 성질도 구현과 배포에 따라 달라집니다.

• 새 문서 탐색은 브라우저가 제목, 초점, 스크롤과 문서 수명 주기를 기본 동작으로 처리한다는 장점이 있습니다.
• 공통 CSS·JavaScript·이미지는 HTTP 캐시에서 재사용될 수 있으므로 페이지마다 모든 리소스를 항상 다시 내려받는 것은 아닙니다.
• 서버 렌더링 비용은 캐시, CDN, 정적 생성 여부에 따라 달라집니다. “MPA이면 서버 부하가 크다”라고 단정할 수 없습니다.
• 문서 전환 비용은 있지만, 작은 문서와 캐시·프리페치·뒤로-앞으로 캐시(bfcache)를 잘 활용한 사이트가 SPA보다 반드시 느린 것은 아닙니다.

SPA: 실행 중인 문서 안에서 탐색하는 구조

SPA도 최초 진입, 주소창 입력, 새로고침, 외부 링크 이동에서는 URL의 HTML 문서를 요청합니다. 차이는 앱이 실행된 뒤의 클라이언트 내부 탐색에 있습니다.

라우터는 처리 가능한 같은 출처 링크의 기본 문서 이동을 대신하고 History API로 주소 기록을 갱신한 뒤, 현재 URL의 pathname을 라우트 규칙에 맞춥니다. path parameter와 search parameter는 화면의 대상·보기 조건에, hash는 문서 안 위치나 앱이 정한 상태에 사용할 수 있습니다. 이어서 필요한 컴포넌트와 데이터를 준비하고 React가 현재 문서의 UI를 갱신합니다. 뒤로 가기와 앞으로 가기에서도 라우터가 변경된 history 항목을 다시 해석합니다.

이 과정에서 네트워크 요청이 사라지는 것은 아닙니다. 라우트별 코드 분할을 사용하면 아직 받지 않은 JavaScript 청크를 가져올 수 있고, 화면 데이터도 새로 요청할 수 있습니다. 반대로 이미 받은 청크나 데이터는 캐시 정책에 따라 재사용할 수 있습니다.

SPA가 주는 대표적인 이점은 공통 레이아웃과 일부 메모리 상태를 유지하면서 전환할 수 있다는 점입니다. 그러나 초기 JavaScript, hydration, 데이터 waterfall, 지나치게 큰 번들로 인한 비용이 생길 수 있으므로 “SPA이면 항상 더 빠르다”는 보장은 없습니다.

CSR·SSR·SSG와 hydration

렌더링 전략은 탐색 구조와 별도로 선택하며, 프레임워크는 라우트마다 전략을 섞기도 합니다.

• CSR: 서버가 앱 진입 문서와 리소스를 보내고, 브라우저의 JavaScript가 초기 UI를 만듭니다. 이미 렌더된 React 마크업이 없다면 일반적으로 createRoot로 시작합니다.
• SSR: 서버가 요청 시점에 URL의 초기 HTML을 만듭니다. 응답을 캐시하거나 스트리밍할 수도 있으므로 “요청마다 항상 같은 비용으로 전체 HTML을 동기 생성한다”는 뜻은 아닙니다.
• SSG: 빌드 시점에 경로의 HTML을 만들어 정적 호스팅이나 CDN에서 제공합니다. 콘텐츠 갱신 시점과 재생성 정책은 배포 시스템이 정합니다.
• hydration: SSR·SSG 등으로 미리 생성한 React HTML을 상호작용 가능한 앱으로 이어 붙이는 과정입니다. hydrateRoot에 전달한 첫 클라이언트 결과는 서버가 만든 마크업과 일치해야 합니다. 정적인 문서나 순수 CSR에는 hydration이 반드시 필요한 것은 아닙니다.

검색 엔진 최적화도 MPA·SPA 이름만으로 결정되지 않습니다. URL별 고유 제목·메타데이터와 링크, 실제 콘텐츠가 담긴 초기 HTML, 올바른 HTTP 상태 코드, 크롤러가 필요한 리소스에 접근할 수 있는지까지 함께 확인해야 합니다. CSR 콘텐츠를 처리하는 검색 엔진도 있지만 모든 크롤러가 같은 수준으로 JavaScript를 실행하는 것은 아니므로, 검색 노출과 빠른 초기 콘텐츠가 중요하면 SSR·SSG 같은 사전 렌더링을 검토합니다.

첫 진입·내부 이동·직접 링크의 책임

SPA의 런타임을 이해하려면 “어떤 URL인가?”보다 먼저 “현재 앱이 이미 실행 중인가?”를 물어야 합니다.

주소창 / 새로고침 → GET /products/42
앱 내부 링크 → history · pathname 매칭
앱이 준비된 뒤 → chunk / CSS / data → UI

주소창 / 새로고침 → GET /products/42
앱 내부 링크 → history · pathname 매칭
앱이 준비된 뒤 → chunk / CSS / data → UI

직접 링크와 새로고침

사용자가 /products/42를 주소창에 입력하거나 그 주소에서 새로고침하면 브라우저는 서버에 /products/42 문서를 요청합니다. 배포 계층은 다음 중 하나를 수행해야 합니다.

• SSR·SSG 경로라면 해당 URL의 문서를 반환합니다.
• 하나의 진입 문서를 쓰는 client-routed SPA라면 유효한 앱 경로를 진입 HTML로 연결합니다. 이 fallback이 없으면 내부 이동은 되지만 직접 링크에서 404가 날 수 있습니다.
• 정확한 HTTP 상태가 필요한 배포에서는 존재하지 않는 경로에 실제 404를 반환할 정책을 둡니다. client-only 정적 catch-all이 진입 문서를 200으로 보내는 경우도 있으므로 화면의 찾을 수 없음 UI와 응답 상태를 따로 확인합니다. API·정적 자산·잘못된 URL까지 무조건 진입 HTML과 200으로 바꾸면 오류 처리와 검색 색인이 왜곡됩니다.

React, 라우터, 서버가 맡는 범위

• 브라우저: 문서 탐색, URL과 history, HTTP 캐시와 문서 수명 주기를 담당합니다.
• 서버·CDN: URL에 맞는 문서·fallback·404, 캐시 헤더, 보안 헤더를 결정합니다.
• 라우터: 실행 중인 앱에서 URL을 라우트에 맞추고, 링크 탐색·params·search·라우트 데이터·코드 분할을 연결합니다.
• React: 선택된 컴포넌트 트리를 렌더링하고 상태 변화에 맞춰 DOM을 갱신하며, 미리 렌더된 React HTML에는 hydration으로 연결됩니다.
• API·서버: 입력 검증과 인증·인가를 매 요청에서 강제합니다. 클라이언트 라우트 가드나 숨긴 버튼은 사용자 경험을 위한 보조 수단일 뿐 보안 경계가 아닙니다.

React 자체는 라우터도, SSR·SSG 배포 시스템도 아닙니다. 작은 기존 문서의 일부에 React를 추가할 수도 있고, MPA의 각 문서에 독립적인 React 루트를 둘 수도 있으며, 프레임워크로 서버 렌더링한 SPA를 만들 수도 있습니다.

성능·보안·접근성 확인표

구조 이름보다 실제 사용자 흐름을 측정하고 검증합니다.

• 성능: 초기 HTML의 유용한 콘텐츠, JavaScript와 라우트 청크 크기, hydration 비용, 데이터 요청 waterfall, 캐시 적중과 재방문 전환을 각각 확인합니다.
• 보안: MPA와 SPA 모두 XSS가 생길 수 있습니다. 신뢰하지 않은 HTML 삽입을 피하고 CSP 같은 방어를 적용하며, 비밀 값과 최종 권한 판정은 클라이언트 번들에 맡기지 않습니다.
• 접근성: 실제 href가 있는 링크와 의미 있는 문서 구조를 유지합니다. 클라이언트 탐색은 새 문서를 열지 않으므로 라우트 변경 뒤 문서 제목, 주 콘텐츠 초점, 로딩·완료 알림과 스크롤 복원을 앱과 라우터가 명시적으로 설계해야 합니다.
• 오류 처리: 최초 진입과 내부 이동 모두에서 로딩, 네트워크 실패, 권한 부족, 찾을 수 없는 라우트가 올바른 상태와 복구 동작을 보여야 합니다.

다음 절에서는 React Router를 사용해 URL과 컴포넌트를 연결하는 방법을 배웁니다. 이때도 라우터가 React의 렌더링 책임이나 서버의 보안·배포 책임을 대신하지 않는다는 경계를 유지하세요. 한 URL을 두 가지 진입 방식으로 읽기

같은 /products/42?tab=spec#buy라도 이미 열린 앱의 링크를 누르는 경우와 새 탭 주소창에 붙여 넣는 경우의 첫 책임은 다릅니다. 전자는 실행 중인 라우터가 pathname을 읽고 화면을 바꿀 수 있습니다. 후자는 먼저 호스트가 /products/42?tab=spec의 문서 요청에 응답해야 합니다. fragment인 #buy는 그 HTTP 요청에 포함되지 않습니다. 앱 문서를 받은 뒤에야 라우터와 React가 실행됩니다.

진입 조건을 바꾸어 판단하기

클라이언트 전용 앱의 홈은 이미 열리지만 호스트에는 깊은 경로 fallback이 없다고 가정합니다. 다음 세 결과를 구별해 보세요.

1. 홈의 앱 링크로 /products/42에 이동합니다.
2. 그 화면에서 브라우저 새로고침을 누릅니다.
3. 호스트가 /unknown에도 진입 HTML을 200 OK로 보낸 뒤 앱의 찾을 수 없음 화면이 나옵니다.

각 경우에 먼저 고칠 곳이 라우터의 경로 규칙인지, 호스트의 문서 응답인지 적습니다. 세 번째 화면에 404라는 글자를 쓰면 HTTP 응답도 바뀌는지 함께 설명합니다.