2nd/00_Raw/Single Page Applications (SPA).md

# [[Single Page Applications (SPA)]]

## 📌 Brief Summary
Single Page Applications (SPA)은 브라우저가 완전히 새로운 페이지를 전체 로드하는 기본 방식 대신, 웹 서버에서 새로운 데이터만 받아와 클라이언트 측에서 JavaScript를 통해 현재 웹 페이지를 동적으로 다시 작성하며 사용자와 상호작용하는 웹 애플리케이션 또는 웹사이트를 뜻합니다 [1]. 초기 셸(Shell) 파일이 로드된 후에는 즉각적인 페이지 전환과 원활한 상태 유지가 가능하여 뛰어난 사용자 경험을 제공합니다 [1, 2]. 하지만 기본적으로 클라이언트 측 렌더링(CSR)에 의존하기 때문에 검색 엔진 최적화(SEO) 처리와 초기 로딩 및 상호작용 성능(Core Web Vitals) 측면에서 고유한 기술적 과제들을 동반합니다 [3-5].

## 📖 Core Content
* **SPA의 장점 및 활용:** 초기 웹의 전체 새로고침 방식에서 발전한 SPA는 AJAX를 거쳐 오늘날 React, Vue, Svelte, Angular 등 프레임워크 기반으로 구축됩니다 [1, 2]. 가장 큰 장점은 전환 속도가 빠르고, 페이지 간 이동 시에도 오디오 재생 등과 같은 상태(State Persistence)가 유지된다는 점입니다 [2]. 프론트엔드 UI와 백엔드 API가 명확히 분리되어 개발자 경험도 우수하며, 대표적으로 Gmail, Spotify Web, Figma, Trello 등에 적용되어 있습니다 [2].
* **클라이언트 측 렌더링(CSR)으로 인한 SEO의 한계:** SPA는 처음 로딩 시 비어 있는 HTML 셸(`<div id="root"></div>`)을 전송하고 이후에 JavaScript를 다운로드하여 렌더링하는 CSR을 기본으로 합니다 [4]. 구글봇 등은 빈 HTML을 먼저 색인화한 후 나중에 JS 실행을 위해 대기열에 넣는 2단계 프로세스를 거치므로 색인이 지연되거나 무락될 수 있습니다 [5-7]. 또한 최신 AI 모델(ChatGPT, Perplexity 등)의 훈련을 돕는 에이전트 크롤러들은 비용 문제로 JavaScript 실행을 생략하는 경우가 많아, 순수 SPA 형태라면 AI 검색 엔진 및 요약 기능에서 콘텐츠가 무시될 위험이 매우 큽니다 [8].
* **코어 웹 바이탈(Core Web Vitals) 성능 저하 요인:** 대규모의 JavaScript 번들을 다운로드하고 실행하는 이른바 '하이드레이션 비대화(Hydration Bloat)'는 브라우저의 메인 스레드를 장시간 점유합니다 [9, 10]. 이로 인해 콘텐츠가 빠르게 표시되는 시간인 LCP(Largest Contentful Paint)와 사용자의 첫 상호작용 시 반응 속도를 나타내는 INP(Interaction to Next Paint) 성능이 낮아져 구글의 페이지 경험 평가에서 페널티를 받을 수 있습니다 [9, 10].
* **라우팅(Routing) 및 메타데이터의 구조적 문제:** 라우팅이 클라이언트 단에서 처리되면서 존재하지 않는 페이지 URL에 접속하더라도 서버는 여전히 정상 코드를 반환하는 소프트 404(Soft 404) 문제가 발생해 크롤링 예산을 낭비하게 됩니다 [10, 11]. 더불어 동적 메타데이터 관리가 되지 않으면 여러 페이지가 동일한 `<title>` 태그를 갖게 되고, URL에 해시(#)를 사용하는 해시 라우팅 방식을 고수할 경우 검색 엔진이 고유 페이지로 인식하지 못하는 치명적인 단점이 있습니다 [12-14].
* **최적화 및 모범 사례 (Best Practices):** 이러한 문제를 해결하기 위해서는 렌더링 방식을 클라이언트에서 서버(SSR)나 정적 생성(SSG) 또는 점진적 정적 재생성(ISR)으로 이전하는 것이 권장됩니다 [15, 16]. 기술적으로는 해시가 없는 HTML5 History API 기반의 깨끗한 URL 구조 구현, 모든 내부 네비게이션에 `onClick`이 아닌 전통적인 `<a href>` 링크 태그 사용, 그리고 페이지 전환 시 메타 데이터(<title>, 오픈 그래프 등)가 갱신되도록 동적으로 관리하는 설계가 필수적입니다 [14, 17, 18].

## 🔗 Knowledge Connections
- **Related Topics:** `[[Client-Side Rendering (CSR)]]`, `[[Server-Side Rendering (SSR)]]`, `[[Core Web Vitals]]`, `[[JavaScript SEO]]`
- **Projects/Contexts:** `[[SPA SEO Guide 2026]]`, `[[React SEO Optimization]]`
- **Contradictions/Notes:** 소스에 따르면 모든 SPA가 반드시 SEO 최적화를 거쳐야 하는 것은 아닙니다. 로그인 벽 뒤에 있는 애플리케이션(예: 관리자 대시보드)이나 웹 애플리케이션 편집기 도구 자체(예: Figma 에디터 화면)인 경우에는 100% 클라이언트 렌더링을 유지하고 SEO를 무시해도 무방하며 `<meta name="robots" content="noindex">`를 적용해 크롤링 예산을 아껴야 한다고 조언합니다 [19]. 또한, 봇에게는 정적 HTML을 보여주고 사용자에게는 CSR을 제공하는 '동적 렌더링(Dynamic Rendering)' 기법의 경우 2026년 기준으로는 클로킹(Cloaking) 제재 위험이 있어 더 이상 구글에서 권장하지 않는 우회책(Hack)으로 취급됩니다 [20, 21].

---
*Last updated: 2026-04-26*