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> 링크 태그 사용, 그리고 페이지 전환 시 메타 데이터(