317. 단일 페이지 애플리케이션 (SPA, Single Page Application) 설계

핵심 인사이트 (3줄 요약)

본질: 단일 페이지 애플리케이션(SPA)은 브라우저가 최초 접속 시 딱 한 장의 HTML 껍데기만 다운로드하고, 이후 메뉴를 클릭할 때마다 화면 이동(페이지 깜빡임) 없이 자바스크립트(JS)가 브라우저 DOM의 내용만 부분적으로 교체하며 앱(Native App)처럼 부드럽게 동작하게 만드는 프론트엔드 아키텍처다.

가치: 모바일 시대에 1초의 지연도 참지 못하는 사용자들에게 '데스크톱 애플리케이션 수준의 부드러운 전환과 풍부한 사용자 경험(UX)'을 제공하며, 서버의 렌더링 비용을 클라이언트의 스마트폰 CPU로 100% 떠넘겨 인프라 비용을 극단적으로 낮춘다.

융합: 앞단은 철저히 화면 그리기(React, Vue)만 담당하고, 뒷단은 오직 데이터(JSON)만 뱉어내는 **REST API 및 마이크로서비스(MSA)**와 구조적으로 융합되어 프론트와 백엔드의 100% 디커플링(분리)을 실현한 클라우드 네이티브의 핵심 UI 뼈대다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: SPA는 브라우저가 렌더링을 독점하는 클라이언트 사이드 렌더링(CSR)의 절대적인 구현체다. 링크를 클릭할 때 서버에 "다음 페이지 HTML 주세요"라고 요청하지 않고, "나 다음 화면 그릴 건데 데이터(JSON)만 줘"라고 요청한 뒤 JS가 화면을 실시간으로 다시 그린다.
필요성: 2000년대 웹사이트(멀티 페이지 애플리케이션, MPA)는 '장바구니' 버튼을 누르면 화면 전체가 하얗게 변했다가(White Screen of Death) 다시 떴다. 서버에서 헤더, 푸터, 메뉴판을 포함한 거대한 HTML을 다시 렌더링해서 네트워크로 보내야 했기 때문이다. 사람들은 아이폰 앱처럼 탭을 누르면 화면이 휙휙 부드럽게 넘어가는 속도에 익숙해졌고, 과거처럼 깜빡이는 웹사이트는 이탈의 원인이 되었다. "왜 매번 똑같은 헤더와 메뉴판을 서버에서 다운받아야 하지? 알맹이(데이터)만 바꿔 끼우자!"라는 발상이 절실했다.
💡 비유: MPA(전통적 웹)는 식당에서 볶음밥을 먹다가 "단무지 좀 더 주세요"라고 하면, 웨이터가 볶음밥과 그릇, 수저를 싹 다 치우고 다시 새로운 볶음밥과 단무지가 담긴 완벽한 새 쟁반을 가져다주는 미친 방식입니다. SPA는 웨이터가 볶음밥(뼈대)은 놔두고, 조그만 종지에 단무지(데이터)만 딱 가져와서 빈칸에 채워주는 효율적이고 우아한 서빙 방식입니다.
등장 배경 및 발전 과정:
1. AJAX (Asynchronous JavaScript and XML): 2005년 구글 맵스(Google Maps)가 화면 새로고침 없이 지도를 이리저리 드래그하는 마법(비동기 통신)을 선보이며 SPA의 시초가 되었다.
2. 프론트엔드 프레임워크의 폭발 (AngularJS, Backbone): 2010년대, 자바스크립트가 너무 복잡해지자 MVC 패턴을 브라우저에 도입하여 화면과 데이터를 묶어주는 1세대 프레임워크들이 등장했다.
3. 가상 돔(Virtual DOM)과 React 시대: 페이스북(Meta)이 "화면이 바뀔 때마다 돔(DOM)을 직접 수정하면 느리다. 메모리에서 가짜 돔을 비교해서 바뀐 곳만 패치(Patch)하자"는 React를 내놓으며 SPA는 전 세계 웹의 90%를 장악했다.
📢 섹션 요약 비유: SPA는 연극 무대와 같습니다. 막이 내리고 장소를 통째로 바꾸는(MPA) 대신, 무대 배경(헤더/푸터)은 그대로 두고 배우(콘텐츠)들만 재빨리 교체하며 관객(사용자)의 몰입이 단 1초도 끊기지 않게 하는 연출 기법입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. SPA 작동 메커니즘과 라우팅 (Routing)

SPA의 가장 큰 마법은 **"페이지는 1장이지만, 주소창의 URL은 바뀐다"**는 점이다. 브라우저의 HTML5 History API를 조작하여 서버 통신 없이 주소만 바꾸고 화면을 전환한다.

  ┌─────────────────────────────────────────────────────────────┐
  │                 전통적 MPA vs 모던 SPA 동작 흐름 비교            │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │  [MPA (Multi-Page Application)]                             │
  │  클라이언트 ──── (1. /home 클릭) ───▶ 서버 (home.html 생성)   │
  │            ◀── (2. 브라우저가 화면을 통째로 새로고침하며 렌더링)    │
  │                                                             │
  │  클라이언트 ──── (3. /cart 클릭) ───▶ 서버 (cart.html 생성)   │
  │            ◀── (4. 또다시 화면을 통째로 새로고침하며 렌더링)      │
  │                                                             │
  │  ─────────────────────────────────────────────────────────  │
  │                                                             │
  │  [SPA (Single Page Application)]                            │
  │  클라이언트 ──── (1. 사이트 최초 접속) ─▶ 서버 (index.html 1개만 줌)│
  │            ◀── (2. 거대한 JS (React/Vue 코드 덩어리) 다운)     │
  │                                                             │
  │  클라이언트 ──── (3. /cart 클릭) ───▶ (서버에 안 가고 JS가 가로챔)│
  │                                                             │
  │            ──── (4. 장바구니 JSON 요청) ─▶ [ API 서버 ]      │
  │            ◀── (5. {item:"사과"} 반환) ──                  │
  │                                                             │
  │  (6. JS가 브라우저 DOM 중 알맹이 부분만 0.01초 만에 갈아 끼움. 깜빡임 0!)│
  └─────────────────────────────────────────────────────────────┘

Client-side Routing (클라이언트 라우팅)

사용자가 /cart 링크를 누르면, 브라우저는 보통 서버에 /cart 문서를 달라고 요청(Request)한다.
SPA의 핵심인 라우터 라이브러리(react-router-dom)는 이 요청을 가로챈다(Intercept). 서버로 못 가게 막고, 주소창의 텍스트만 /cart로 바꾼 뒤, 메모리에 올려둔 자바스크립트 컴포넌트(CartComponent)를 끄집어내어 빈 화면에 그린다. (이것이 SPA가 빠르고 앱처럼 부드러운 진짜 이유다.)

2. 가상 돔 (Virtual DOM)의 렌더링 최적화

JS로 화면을 바꾸는 것은 좋지만, 브라우저의 실제 뼈대(DOM)를 만지작거리는 것은 컴퓨터 CPU 입장에서 매우 비싼 연산(Reflow/Repaint)이다.

SPA 라이브러리(React, Vue)는 메모리 속에 실제 화면과 똑같이 생긴 **'가짜 도화지(Virtual DOM)'**를 들고 있다.
데이터가 바뀌면 가짜 도화지에 먼저 그림을 쫙 그려본다.
그리고 실제 화면(Real DOM)과 가짜 도화지를 비교(Diffing)해서, "아, 헤더는 똑같고 버튼 색깔 딱 1개만 파란색으로 변했네?"라고 파악한 뒤, 실제 화면의 그 버튼 딱 1개만 콕 집어서(Patch) 0.001초 만에 업데이트한다. 이것이 SPA가 미친 듯이 부드러운 성능을 내는 비밀이다.
📢 섹션 요약 비유: 가상 돔은 성형수술을 할 때 환자 얼굴(Real DOM)에 바로 칼을 대는 것이 아니라, 컴퓨터 3D 모델(Virtual DOM)로 먼저 깎아보고 달라진 부분(차이)만 환자 얼굴에 살짝 시술하여 붓기와 회복 시간(성능 지연)을 없애는 최첨단 수술법입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. SPA vs MPA의 트레이드오프

SPA가 모든 것을 압도하는 완벽한 은탄환(Silver Bullet)은 아니다.

비교 척도	SPA (Single Page Application)	MPA (Multi-Page Application)
초기 로딩 속도 (FCP)	느림 (JS 파일을 통째로 다운로드해야 화면이 뜸)	빠름 (서버가 그린 뼈대 HTML을 즉시 보여줌)
이후 전환 속도	매우 빠름 (JSON 데이터만 받아서 부분 교체)	느림 (매번 서버 왕복 및 화면 전체 깜빡임)
SEO (구글 검색 노출)	취약함 (초기 HTML이 비어있어 검색 봇이 긁어가지 못함)	완벽함 (각 페이지가 고유의 HTML을 100% 가짐)
프론트-백 분리도	100% 분리됨 (백엔드는 API만 제공)	강결합됨 (서버 템플릿-JSP/Thymeleaf-에 묶임)

이 딜레마를 해결하기 위해 Next.js나 Nuxt.js 같은 프레임워크가 등장하여 "첫 페이지는 MPA(SSR)처럼 빠르게 그리고, 다음 클릭부터는 SPA(CSR)처럼 부드럽게 넘어가자"는 하이브리드 아키텍처로 웹 생태계를 평정했다.

과목 융합 관점

아키텍처 (Architecture) / MSA: SPA의 등장은 백엔드 시스템을 '화면을 그리는 노역'에서 완벽하게 해방시켰다. 이 분리 덕분에 백엔드는 온전히 JSON API만 뱉는 순수한 MSA(마이크로서비스)로 진화할 수 있었고, 하나의 API를 만들어 놓으면 Web SPA, iOS 앱, Android 앱이 모두 가져다 쓰는 다중 플랫폼(Omni-channel) 전략이 완성되었다.
보안 (Security): SPA는 모든 소스 코드와 API 주소가 클라이언트(브라우저) 메모리에 노출되므로 XSS(크로스 사이트 스크립팅) 공격에 매우 취약하다. 아키텍트는 JWT 토큰을 보관할 때 로컬 스토리지 대신 HttpOnly 쿠키를 사용하여 자바스크립트로 탈취되는 것을 구조적으로 방어해야 한다.
📢 섹션 요약 비유: SPA는 뷔페에서 빈 접시를 들고 요리(데이터)만 집어 먹는 효율적인 구조이고, MPA는 한정식집에서 다 먹을 때마다 빈 상을 통째로 치우고 새 상을 내어오는 무거운 구조입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 거대한 번들(Bundle.js) 크기로 인한 초기 로딩 지옥: 프론트엔드 개발자들이 신나게 SPA로 코드를 짜며, 수십 개의 라이브러리(차트, 달력, 에디터 등)를 무지성으로 npm install 했다. 사이트 접속 시 텅 빈 하얀 화면(White Screen)이 5초 동안 떴다가 한 번에 확 켜진다. JS 파일 용량이 15MB나 되었기 때문이다. 고객 이탈률(Bounce Rate)이 70%로 치솟았다.
- 아키텍트의 해결책: 전형적인 SPA의 '초기 로딩 지연(Fat Bundle)' 참사다. 아키텍트는 무조건 **코드 스플리팅(Code Splitting)**과 지연 로딩(Lazy Loading) 전술을 강제해야 한다. 사용자가 아직 클릭하지 않은 '결제 화면'이나 '마이페이지'의 JS 코드까지 첫 접속 시에 다운로드할 필요가 없다. Webpack을 통해 라우터 단위로 JS 덩어리를 잘게(Chunk) 쪼개고, 사용자가 그 메뉴를 클릭하는 순간 0.1초 만에 다운받아 그리도록 프론트엔드 파이프라인을 튜닝해야 생존할 수 있다.
시나리오 — 브라우저 새로고침(F5) 시 발생하는 404 에러의 공포: SPA로 잘 만든 사이트에서 사용자가 게시판을 누르니 주소가 company.com/board로 바뀌고 부드럽게 화면이 떴다. 그런데 사용자가 여기서 **'새로고침(F5)'**을 누르는 순간 끔찍한 "404 Not Found" 에러 페이지가 떴다.
- 아키텍트의 해결책: Client-side Routing과 Server-side Routing의 충돌을 인지하지 못한 인프라 설계 오류다. SPA에서 /board 주소는 자바스크립트가 브라우저 안에서 만들어낸 '가짜 주소'다. 새로고침을 누르면 브라우저는 진짜 백엔드 서버(Nginx 등)에 가서 "board.html 내놔라"고 요청한다. 서버에는 index.html 1장밖에 없으므로 404 에러가 나는 것이다. 아키텍트는 반드시 Nginx나 S3+CloudFront 설정에서 **"무슨 주소(404 에러)로 요청이 들어오든 간에 무조건 index.html 1장만 반환해라 (Fallback Routing)"**라고 규칙을 박아두어야 한다.

도입 체크리스트

비즈니스적: 이 사이트가 **검색 엔진(구글, 네이버) 노출이 기업의 생명(매출)**과 직결되는가? 그렇다면 순수 SPA(React)로 짜면 망한다. 검색 봇은 자바스크립트를 잘 파싱하지 못해 빈 화면으로 인식한다. SEO가 필수라면 순수 SPA를 버리고 Next.js(SSR)나 정적 사이트 생성(SSG)으로 선회해야 한다.
기술적: API 통신 중에 네트워크가 지연될 때 사용자를 위한 상태 처리가 되어 있는가? SPA는 서버가 뼈대(HTML)를 주지 않으므로, 데이터가 오기 전까지는 빈 화면이다. 반드시 스켈레톤(Skeleton) UI나 로딩 스피너(Spinner)를 띄워 "지금 데이터를 가져오는 중입니다"라는 런타임 피드백(사용성 품질)을 보장해야 한다.

안티패턴

프론트엔드 상태(State) 비대화 안티패턴: 백엔드를 부르기 귀찮다고, 프론트엔드의 Redux/Vuex 스토어(전역 변수)에 상품 목록 1만 개, 장바구니, 유저 정보를 몽땅 다 때려 넣고 캐시로 쓰는 행위. 메모리 오버플로우로 모바일 브라우저가 버벅거리고 터진다. 프론트의 메모리(상태)는 깃털처럼 가볍게 유지하고, 무거운 건 그때그때 백엔드 API에 페이징(Paging)을 걸어 가져와야 한다.
📢 섹션 요약 비유: 코드 스플리팅(Code Splitting)은 100권짜리 백과사전을 한 번에 가방에 넣어 학교에 가는 게 아니라, 오늘 배울 1권만 딱 잘라서 가져가는 지혜입니다. 가방(초기 로딩)이 깃털처럼 가벼워져서 지각(이탈률)을 면하게 해줍니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	레거시 멀티 페이지(MPA) 환경 (AS-IS)	SPA 기반 프론트엔드 아키텍처 (TO-BE)	개선 효과
정량	메뉴 클릭 시마다 전체 HTML 재로드 (2MB 전송)	데이터 JSON(10KB)만 교환하며 부분 렌더링	사용자 네트워크 트래픽 95% 극적 감축
정량	백엔드 서버가 화면 렌더링(JSP)하느라 CPU 80% 소모	서버는 순수 API만 제공, 렌더링은 클라이언트 위임	백엔드 서버 컴퓨팅 인프라 비용 절반 이상 삭감
정성	화면 깜빡임과 느린 응답으로 구시대 웹사이트 느낌	네이티브 모바일 앱과 구별할 수 없는 부드러운 전환	최상의 체감 성능 획득을 통한 사용자 잔존율(Retention) 극대화

미래 전망

SPA의 복잡성에 대한 반작용 (하이드레이션의 종말): React와 SPA 생태계가 수백 개의 라이브러리로 얽히면서 "과연 이것이 가벼운가?"라는 근원적인 회의론이 터져 나왔다. 번들(JS) 크기가 수 MB를 찍자, 렌더링을 다시 서버로 가져가면서도 SPA의 부드러움만 취하는 HTMX, Qwik(아일랜드 아키텍처), React Server Components (RSC) 같은 차세대 기술들이 순수 SPA 시대를 서서히 무너뜨리며 새로운 하이브리드 표준을 세우고 있다.
마이크로 프론트엔드 (Micro Frontends): 1개의 거대한 SPA 저장소에 프론트 개발자 100명이 달라붙으면 깃허브(GitHub) 충돌 지옥이 펼쳐진다. SPA 자체를 로그인, 검색, 결제 영역별로 물리적으로 찢어(여러 개의 독립된 소형 SPA 조립) 배포 파이프라인을 나누는 '마이크로 프론트엔드' 아키텍처가 엔터프라이즈의 종착지가 되고 있다.

참고 표준

HTML5 History API (pushState, replaceState): 웹 브라우저의 화면 새로고침 없이 주소창의 URL만 살짝 바꿔주어 SPA의 마법 같은 라우팅(Client-side Routing)을 가능하게 해 준 W3C 표준 스펙.
RESTful / GraphQL API: SPA가 백엔드와 오직 데이터(JSON)만을 주고받기 위해 지켜야 하는 사실상의 인터페이스 표준 규약.

단일 페이지 애플리케이션(SPA)은 낡은 웹 브라우저를 **'어플리케이션(App)'**의 반열로 끌어올린 혁명이다. 프론트엔드는 더 이상 백엔드가 던져주는 뷰(View) 템플릿의 노예가 아니다. 스스로 라우팅을 통제하고, 상태를 관리하며, 가상 돔(Virtual DOM)으로 렌더링을 지휘하는 거대한 독립 아키텍처가 되었다. 기술사는 이 분리(Decoupling)가 가져온 개발 생산성의 축복과, 거대해진 JS 번들이 초래하는 성능 저하라는 저주(Trade-off)를 명확히 계산하여, 어떤 기술을 어디에 자를지 정밀한 지휘봉을 휘두르는 마에스트로가 되어야 한다.

📢 섹션 요약 비유: SPA는 1막, 2막마다 극장의 커튼을 내리고 세트장을 바꾸는 고전 연극(MPA)이 아닙니다. 커튼을 절대 내리지 않고(새로고침 없이), 관객이 눈치채지 못할 속도로 암전 속에 조명과 소품만 휙휙 바꿔치기하며 극의 몰입감을 끝까지 끌고 가는 가장 진보된 무대 연출입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
SSR / CSR	SPA는 CSR(클라이언트 사이드 렌더링)의 결정체다. 하지만 SEO 약점을 극복하기 위해 초기 화면만 SSR로 굽는 Next.js 등으로 진화(융합)한다.
REST API / MSA	SPA가 등장하여 백엔드에서 렌더링의 의무를 박탈했기 때문에, 비로소 백엔드가 순수하게 JSON만 뱉는 아름다운 MSA/REST로 독립할 수 있었다.
마이크로 프론트엔드 (Micro Frontends)	거대해진 1개의 SPA 프로젝트(모놀리식)를 수십 개의 작은 SPA로 조각내어 조립하는 조직적/아키텍처적 진화.
가상 돔 (Virtual DOM)	데이터가 수시로 바뀌는 SPA 환경에서, 브라우저가 화면을 그리는 속도가 느려지지 않도록 차이점(Diff)만 살짝 업데이트하는 React의 심장 기술.
크로스 사이트 스크립팅 (XSS)	SPA 구조상 해커가 악성 자바스크립트를 주입하면 클라이언트 메모리의 토큰(JWT) 등을 다 훔쳐 갈 수 있는 치명적 보안 위협.

👶 어린이를 위한 3줄 비유 설명

옛날 책은 그림을 보려면 매번 책장을 스르륵 넘기느라 시간이 걸렸어요. (새로고침, MPA)
그런데 새로 나온 태블릿(SPA)은 책장을 안 넘겨도, 손가락으로 톡 누르면 바탕은 그대로 있고 내가 보고 싶은 동물 그림만 눈 깜짝할 새에 샤샤샥 바뀌어요!
이렇게 화면 전체를 새로 그리지 않고, 꼭 필요한 내용(데이터)만 재빨리 바꿔 끼워서 앱처럼 엄청 빠르고 부드럽게 만들어주는 똑똑한 기술을 **'단일 페이지 애플리케이션(SPA)'**이라고 부른답니다!