▲

이제 모던 CSS가 SPA를 대체할 때입니다

 (jonoalderson.com)
2P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • View Transitions API 같은 모던 CSS 기능의 등장으로, 이제 매끄러운 페이지 전환을 위해 SPA 구조가 필요 없는 상황임
  • 대부분의 SPA 사이트는 실제로 기대한 만큼의 성능이나 부드러운 경험을 제공하지 못하며, 오히려 무거운 JavaScript 코드가 사용자 경험을 저하시키는 경향임
  • Chromium 기반 브라우저에서 네이티브 페이지 전환과 Speculation Rules를 활용하면, 자바스크립트 없이도 빠르고 자연스러운 내비게이션 구현이 가능함
  • SPA의 복잡한 구조는 브라우저 최적화를 방해하므로, 실제 웹사이트는 HTML과 CSS 중심의 MPA 구조가 더 빠르고 관리가 쉬움
  • 앞으로는 불필요한 SPA 도입을 지양하고, 모던 CSS와 네이티브 기능을 활용해 효율적이고 유지 관리가 쉬운 웹사이트 개발이 필요함

서론: SPA의 종말과 모던 CSS의 출현

  • 최근 View Transitions API와 같은 최신 CSS 기능의 도입으로, 기존 SPA(싱글 페이지 어플리케이션)가 제공하던 주요 장점이 이제는 필요 없게 된 상황을 맞이함
  • 여전히 많은 개발팀이 React, Vue 같은 SPA 프레임워크를 선택하지만, 그 결정의 핵심은 성능이 아니라 인터랙션과 부드러운 네비게이션 경험에 대한 오해임
  • 실제로 매끄러운 네비게이션을 위해 SPA가 필수라고 믿는 관행은 이미 구시대적인 사고방식임

SPA의 허상과 현실

  • SPA는 한때 가장 자연스러운 페이지 전환을 구현하기 위한 유일한 방법이었으나, 이제는 더 이상 그렇지 않음
  • 많은 SPA는 다음과 같은 문제점 발생:
    • 로딩 상태의 페이드 효과만 있을 뿐 진정한 콘텐츠 전환 부드러움이 부족함
    • 스크롤 복원 문제와 비일관적인 포커스 처리
    • 렌더링/하이드레이션 지연으로 인한 내비게이션 지연
    • 레이아웃 시프트와 콘텐츠 팝업, 스켈레톤 로딩 등
    • 성능 대비 효과가 미미한 불필요한 복잡성 및 자바스크립트 과다 사용
  • 대표적 SPA 프레임워크(Next.js, Gatsby, Nuxt 등)는 기본적인 네이티브 브라우저 동작을 모방하기 위해 대량의 JS 코드를 추가하고 있음
  • 결과적으로 네이티브 자연스러움을 희생하고, 속도가 느려지고 SEO도 저하되는 문제 야기함

웹 플랫폼의 발전과 CSS의 역할 변화

  • 최신 크로미움 기반 브라우저(Chrome, Edge 등)에서는 네이티브, 선언적 페이지 전환을 지원함
  • View Transitions API를 통해 자바스크립트 없이도 문서 간 혹은 전체 페이지 간 부드러운 애니메이션 구현 가능
  • 핵심 역량은 다음과 같음:
    • 페이지 간 페이드 효과 (단 3~4줄 CSS로 구현 가능)
    • 썸네일에서 상세 이미지로의 자연스러운 전환 등 공유 요소 애니메이션
    • 헤더, 내브바 등의 영구 요소 유지
    • 실제 URL 및 실 페이지 이동이므로 SEO, 링크 공유, 백/포워드 케시 등 호환성 극대화

CSS와 JS의 시너지를 충분히 누릴 수 있는 방법

  • 필요하다면, JS를 통해 페이지 내부 전환에도 View Transition을 수동 호출 가능
  • 예: 테마 전환, 탭 토글, 다크모드 전환 등에 자바스크립트 최소량만 사용

Speculation Rules와 즉각적 네비게이션

  • Speculation Rules는 브라우저가 페이지를 미리 프리로드/프리렌더하면서 사용자 행동(예: 마우스 오버)을 예측해 즉각적인 내비게이션 제공
  • 선언적으로 <script type="speculationrules">를 통해 설정 가능
  • 전제: 페이지가 가볍고 최적화되어 있을 때 퍼포먼스 극대화 효과, 무거운 페이지라면 오히려 자원 낭비 위험

브라우저 고유 기능 존중과 bfcache

  • bfcache(Back/Forward Cache) 는 사용자가 뒤로/앞으로 이동 시 전체 페이지를 스냅샷 형태로 즉각 복원함
  • 전제 조건: 순수 HTML과 CSS 기반, 클린 아키텍처여야 하며, SPA처럼 라우팅을 가로채는 구조에서는 적용 불가
  • 결론적으로, 모던 브라우저는 단순하고 견고한 웹사이트에 보상을 제공하는 방향으로 진화 중임

SPA와 MPA 퍼포먼스 비교

  • 평균적인 SPA(Next.js 기준):
    • JS 번들 크기: 1~3MB
    • TTI(사용가능 시점): 3.5~5초
    • 라우트 전환: 가짜/시뮬레이션
    • SEO: 복잡, 유지 어려움
    • 스크롤/앵커 동작: 불안정함
  • 모던 MPA(CSS 전환 및 Speculation Rules 적용):
    • JS 번들: 0KB (선택적 보강만)
    • TTI: 1초 내외
    • 라우트 전환: 진짜 네이티브 동작
    • SEO: 매우 용이
    • 스마트 스크롤, 포커스, 히스토리: 브라우저 기본 동작 및 완벽 지원

웹사이트와 앱의 구분, 적합성 재고 필요

  • 대다수 웹사이트는 실제 "앱"이 아니며, 공유 상태, 클라이언트 라우팅, 복잡한 인터랙션이 필요하지 않음
  • 마케팅 페이지, 문서 포털, 이커머스, 블로그 등엔 HTML 중심, 빠른 로딩, 심플한 구조가 더 적합함
  • 모든 프로젝트에서 SPA 스택을 도입하면, 과도한 복잡성 및 성능 저하 유발 가능
    1. "앱처럼 보여라"라는 요구
    2. 프레임워크 도입
    3. 클라이언트 라우팅 및 복잡성 증가
    4. 성능 하락 및 추가 최적화 필요
    5. 여전히 네이티브 링크 전환 + CSS 애니메이션 구조보다 느린 현실

결론 및 권고

  • SPA는 과거 플랫폼 한계에 대한 임시 방편에 가깝지만, 현재는 더 이상 존재하지 않는 제약임
  • 이제는 다음과 같은 네이티브 기능의 적극 활용이 가능함:
    • 진짜 페이지 간 전환
    • Speculation Rules 통한 즉각적 사전 렌더링
    • 점진적 기능 저하에 강한 구조
    • 깔끔한 마크업, 빠른 로딩, 실 URL 활용
    • 플랫폼의 도움을 최대로 받을 수 있는 구조
  • "부드러움"만을 이유로 SPA를 고수하면, 복잡성, 성능, 유지보수성 모두의 대가를 치르게 됨
  • 서버 렌더링, 실 페이지, CSS 기반 애니메이션, 의도적 사전 로딩, 최소한의 JS 도입으로 현 시대에 맞는 빠르고 행복한 웹사이트 제작 가능
  • 2025년 현재의 기술을 활용해, 더 빠르고 더 간편하며 누구나 환영할 수 있는 웹 경험을 지향해야 함
▲
howudoin 1시간전  [-]

크게 동의함
단적인 예로 리액트 자체도 프론트의 스프링임
무겁고 복잡한데 업무가 편리해진 것 같지만 실제는 가벼운 일을 하기 위해 더 복잡한 과정을 설정해놓고 굳이 복잡해진 과정을 편리하게 해주는 이상한 편리함임

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • SPA는 사용자가 한 앱에서 긴 세션을 보내는 경우에 의미가 있음, 즉 한 번에 큰 번들을 로드하고 그 후 작은 네트워크 요청만으로 앱을 사용할 수 있게 되는 구조임, 부드러운 전환 효과는 덤일 뿐이고 SPAs가 해결하는 본질적인 문제는 아니라고 생각함, 클라이언트 사이드 라우팅이 페이지 전환을 위한 것이라는 주장은 SPAs의 목적을 잘못 이해한 것임, 만약 그런 잘못된 전제로 SPA를 사용했다면 이 글이 맞긴 하지만 SPA는 jQuery 시절 복잡한 앱을 위해 등장했음, 거대한 jQuery 코드뭉치로 각 div가 미니 앱처럼 동작하고 많은 작은 네트워크 요청으로 동기화됨, 구식 브라우저와 느린 인터넷 환경에서 매번 전체 코드를 재로딩하지 않고 효율적으로 사용할 수 있었음, 이후 React 등의 프레임워크가 구조적인 앱 개발을 쉽게 만들며 발전했고, SPA의 핵심 장점은 오랜 세션을 가진 사용자를 위해 한 번에 큰 번들을 캐시하고 이후 네트워크 트래픽을 최소화하는 것임

    • (위 의견의 인용문: "...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.") 완전히 공감함, 글쓴이는 SEO 컨설턴트인데 마케팅 웹사이트 쪽에만 집중하는 듯함, 실제 앱들(마케팅 웹사이트가 아닌)은 SPA로 큰 이점을 누릴 수 있음, 예를 들어 Google Maps를 SPA 없이 만든다고 상상해보면 페이지 전환 애니메이션만 추가해도 UX는 심각하게 나빠질 것임

    • “jQuery 스파게티만 쌓았다”는 표현이 있는데, 실제로 나는 IIFE 같은 이른 JS 디자인 패턴을 적용해 코드 구조화와 모듈 지연 로딩, 코드 난독화 등을 했었음, 그리고 내 경험상 AngularJS가 프론트엔드 구조화 시도 중 가장 컸고 Java 개발자들에게 매력적이었던 이유도 모듈화, DI, 테스트 용이성 때문이었음, 처음엔 Backbone으로 앱을 만들 땐 기능 대부분이 백엔드에 있을 거라 테스트를 별로 신경쓰지 않았는데, 나중에 AngularJS로 리빌드하면서 훨씬 프론트엔드 테스트가 많아짐, 물론 요즘의 Angular 코드나 Java 코드의 장황함과 복잡함, 간접성에는 거부감이 생김

    • 느린 네트워크 연결과 적극적 캐싱 환경이 SPA가 필요한 강력한 이유 중 하나라고 생각함(웹사이트가 아니라 어플리케이션에 더욱 해당), 괜찮은 연결이 있을 때 전체 프론트엔드를 한번에 받아 캐싱해두면, 이후 사용은 최소한의 대역폭으로 가능함

    • 근대적 CI/CD 파이프라인을 사용하는 곳에 다닌다면, 하루에도 여러 번 배포할 때마다 그 큰 JS 번들이 재구축되며 캐시가 무효화될 가능성이 큼, HTTP2가 이미 브라우저에 10년째 기본인데, 멀티플렉싱 덕분에 JS 번들을 크게 묶을 이유가 사라짐, 큰 번들을 만드는 SPA 방식은 브라우저와 서버의 현대 기능을 활용하지 못함

    • 로딩 후 네트워크 요청이 정말 작아진 사례가 실제로 얼마나 있는지 궁금함, 내가 경험한 대부분의 SPA는 로딩 이후에도 대형 호출이 많고, 그냥 HTML을 바로 보내는 것보다 훨씬 느렸음, JSON이 magically하게 HTML보다 더 잘 압축된다는 주장도 성립하지 않음, HTML도 충분히 압축이 잘 됨, 실제로는 네트워크 이슈 때문에 SPA가 더 낫다는 논거는 거의 선전이나 미신에 가까움

  • SPA의 가치는 부드러운 전환뿐 아니라, 사용자 여정 대부분을 클라이언트 쪽에서 처리해 서버를 거의 신경쓰지 않을 수 있다는 점에 있다고 생각함, 예시로 2025년에도 대부분의 온라인 쇼핑몰이 필터 변경이나 카테고리 진입 때마다 전체 페이지를 리로드하고 다시 데이터를 받아와야 하는 게 불만임, 사용자가 카테고리를 오가며 여러 번 요청하는 상황에서는 전체 카탈로그를 한번 클라이언트에 내려받고 이후 서버와의 통신 없이 필터링이 가능하면 UX가 훨씬 좋아짐, 물론 데이터가 많을 거라는 반론이 있겠지만 대부분의 쇼핑몰 카테고리는 몇 KB면 충분하고 제품 사진 한 장보다도 작음, 2005년부터 이런 앱을 만들어오면서 왜 이런 UX가 더 널리 쓰이지 않는지 아직도 이해가 안 됨

    • 내 생각에 페이지를 풀 리로드해야 가장 불편한 점은 데이터 크기가 아니라 사이트 효율성임, 실제 데이터는 몇 KB지만, 페이지 자체가 100MB를 다운로드하고 브라우저가 1GB RAM을 소모함, 예를 들어 Hacker News는 대부분 네비게이션이 리로드이고 옛 노트북에서도 잘 작동함, 반면 DoorDash 같은 SPA는 같은 기기에서 30초나 걸리고, 실제 음식 주문까지 3분 넘게 걸렸음, 인터페이스가 뜨기까지 2.5분은 기다려야 했고, 그마저도 거의 전부가 풀리로드는 아님

    • HTMX 같은 도구가 이런 문제를 많이 해결해줌, SPA 방식은 결국 프론트엔드와 백엔드라는 두 개의 앱을 각각 만드는 결과라 생각함, 나는 서버 사이드에서 대부분을 처리하고 클라이언트쪽에서는 단순한 인터랙티브 효과(보이기/숨기기, 펼치기/접기, 이펙트 등)만 추가하는 쪽이 더 낫다고 느낌, 물론 SPA가 유용한 곳도 존재함

    • 비슷한 경험으로, 몇몇 개인 프로젝트는 정적 웹서버에 호스팅함, 수만 개의 개별 페이지를 렌더링하는 대신 JSON 파일 하나로 SPA에서 클라이언트에서 렌더링함, Github Pages도 활용했음, 최근엔 sqlite 데이터베이스 wasm 빌드를 활용해 HTTP Range Requests로 필요한 페이지만 받아오는 구조도 실험 중임, sqlite의 Full Text Search도 동작하긴 하지만, 짧은 검색엔 전체 테이블을 받아야 하니 아쉬움, 전체 DB를 받아서 로컬에서 FTS 테이블을 만드는 게 더 나을 수도 있음

    • 반론 예시도 있는데, 예를 들어 “sci-fi” 카테고리를 Shift-클릭해 새 탭에서 열 때, MPA에선 별 노력 없이 되지만 SPA는 이걸 따로 관리해야 해 번거로움, 만약 카테고리 링크가 없고 Select Box로만 접근하면 UX가 별로임

    • 일반적으로 기업들은 전체 카탈로그를 사용자가 다운로드하길 원치 않음, 경쟁사가 쉽게 분석할 수 있으니까, 또 책 판매 같은 경우엔 수십만 권이어서 그걸 다 한 번에 옮기는 건 사용자 경험 측면에서나 대역폭/메모리 측면에서 비효율적임

  • SPA의 목적은 절대 페이지 전환이 아님, 좋은 페이지 전환을 제대로 구현한 SPA는 거의 없음, 예를 들어 Next.js에서는 루트 로딩 방식 때문에 페이지 트랜지션 구현이 거의 불가능에 가까움, 내가 실제로 Next.js에 적절한 페이지 전환 기능을 추가해봤는데 완전 악몽이었음, SPA의 명확한 장점은 다음 두 가지로 보임, 첫째, 대부분의 앱은 어느 정도의 상호작용성을 원하기 때문에(HTML/CSS만으론 불충분), React와 순수 HTML을 혼용하는 건 큰 고통임(특히 글로벌 상태 관리 필요할 때), 둘째, 페이지 구조 전체를 미리 로드해놓으면 이후 데이터 로딩이 빨라지고, 클릭 후 즉각적인 반응과 로딩 화면을 띄우는 게 500ms 뒤에야 반응하는 것보다 UX가 더 좋음(불과 100ms 이하면 얘기가 다르긴 하지만), 전체 페이지를 다시 그리지 않아도 되니 프론트엔드 퍼포먼스가 HTML만으로는 따라오지 못함, Basecamp처럼 복잡한 웹앱을 SPA 없이 잘 만든 사례도 있지만 30초만 이리저리 클릭해봐도 SPA 성능을 따라오지 못함, 웹의 본연답게 웹이 돌아가길 바라지만, Next.js와 SPA가 추가하는 복잡성이 앱을 더 빠르고 반응성 있게는 개선했으나 동시에 개발이 번거로워지고 대형 번들이 만들어지는 폐해도 있음, 그래도 HTML만으론 아직 SPA의 성능을 따라갈 수 없다고 생각함

      1. API 관점도 있음, 이미 iOS/Android 앱이나 개발자용 API가 있다면, SPA는 그 백엔드에 또 하나의 앱을 추가하는 셈이라 연동이 쉬움

  • 이 글 쓴 SEO 컨설턴트가 사는 우주가 어딘지 모르겠음, Next와 Nuxt를 SPA에 반대되는 대표 프레임워크로 예시 드는 건 완전 틀림, 1. Next가 미국/서구권에서 거의 완전 장악했고, 새로운 React 앱 얘기할 때는 대부분 Next를 지칭함, Vue 진영에서는 Nuxt가 거의 표준이고 Nuxt = Vue계의 Next임, 즉 사람들은 무의식적으로 Next와 MPA 전략을 고르고 있음, 펜듈럼이 너무 MPA로 흔들렸으니 오히려 SPA를 시도해보라고 권장해야 한다고 봄, 지난 8년은 MPA로의 열풍기였고, 이제 Facebook도 공식적으로 Create React App 대신 Next를 문서에 권장함, 2. Next 복잡함에 대한 불평은 최신 MPA 전략의 난이도에 대한 것으로, SPA 진영은 거의 10년간 멈춰있는 이야기임, 3. MPA 개발이 SPA보다 훨씬 어려움, 서버와 클라이언트 구분을 더 철저히 지켜야 하니까, 4. SPA로 MPA 방식 데이터를 불러오고 싶으면 그건 개발자의 선택이고 장단점은 본인이 감수해야 함, 미리 데이터를 불러 SPA 내비게이션을 즉각적으로 할 수도 있음, 5. 정말 SEO가 중요한 메인 프론트 이외에도 내부 대시보드나 앱이 더 많이 존재함, React 개발자는 보통 이런 곳에 많으니, 무조건 최초 프레임을 완벽히 제공하려는 부담 때문에 불필요한 짐을 가지지 않는 게 중요함

    • “정말 그런 전쟁이 있었나?”라는 의문이 듬, Next가 이겼다는 건 React가 이겼다는 말과 비슷, 아무도 승리한 건 없고 그냥 대세에 편승하는 것뿐임, Angular나 미니멀 혹은 프레임워크 없는 개발 스타일을 고수한 사람은 진짜 “다들 도대체 무슨 소리야”라고 생각 중임, 그리고 스타트업계와 실리콘밸리는 서로 홍보하면서 합종연횡하는 방식이라 실제로 대단치는 않음, Next가 별로일 수도 있지만 이미 많은 사람들의 경력과 정체성이 그것과 얽혀있으니 쉽게 사라지지 않을 뿐임

  • SPA를 폄하하는 논조가 불공정하다고 생각함, SPA는 분명 더 많은 노력이 필요하지만, 분명 장점이 더 많음, 앱처럼 느껴지는 UX를 만드는 유일한 방법이 오랫동안 SPA였음, 글쓴이가 앱 피로감을 언급하지만, 정말 ‘어플리케이션’ 경험을 제공하려면 SPA가 거의 유일함, 무거운 SPA와 가벼운 웹사이트(정적 사이트)를 비교하는 건 부적절함, 누군가 가벼운 웹사이트를 만들 수 있다면 SPA도 마찬가지로 만들 수 있음, SPA든 웹사이트든 비효율적으로 만들면 느리고 무거운 건 똑같음, SPA에 많이 투자해 본 입장으로서 더 적은 노력으로 동일 경험을 낼 수 있는 방법에 관심이 많았으나, 이 글은 약간의 시각적 치장에 가까움, 폴리시는 가치 있으나 SPA냐 아니냐를 결정할 만큼 영향력 있진 않다고 봄

    • “하지만 더 낫다”는 그 주장의 근거가 궁금함

  • “SPA 프레임워크 없이 linear.app을 만들어보라”는 건 무리라고 봄, “Native CSS transitions로 SPA의 가장 큰 장점(클라이언트 라우팅)이 죽었다”는 명제는 말이 안 됨

    • Linear는 SPA 중에서도 굉장히 특별한 케이스라 생각함, SPA를 금지하거나 JS를 브라우저에서 완전히 제거하자는 이야기가 아님, Linear가 빠른 이유는 “오프라인 퍼스트” 설계지만, 그렇게 하는 서비스가 거의 없음, 티켓 예매나 포럼, 뉴스, 블로그, 정보성 사이트는 SSR 기반 개발이 훨씬 낫다고 생각함, SPA가 꼭 필요한 곳에만 SPA를 쓰고 나머지는 SSR로 빠르게 개발하고, CSS로 SPA처럼 보이게 만드는 게 훨씬 효율적임

    • SPA의 자리가 없는 건 아니지만, 나머지 99%의 사이트는 SPA일 필요가 없음

  • SPA는 뷰 트랜지션(페이지 전환)이 목적이 아님, 원문(TFA)은 페이지간 화려한 전환이 중요하다고 암시하는데(잘못된 생각), “CMO”나 “브랜드 매니저” 탓을 하는 대신 SPA의 본질적인 가치를 조명해야 함, SPA는 클라이언트 로직을 위한 훌륭한 프레임워크, 관심사 분리(프론트 로직과 백엔드 분리), 개발 경험 개선→빠른 개발 속도 등 다양한 장점이 있음, 이런 글이 많이 보이는 건 내 댓글처럼 논쟁을 부르는 구조 덕분인데 사실 이렇게 주목받을 글은 아니라고 생각함

    • 이런 주제가 유행과 반복성이 있기에 확산되는 듯, 원문 저자가 SEO에 집중한 거랑도 딱 맞아떨어짐, 실제로 페이지 전환이 전혀 없는 SPA도 많이 만들었고, 최근엔 뷰 트랜지션 덕분에 전환 효과를 넣긴 했지만, 필수 사항은 아니었음

  • 내 입장에선 SPA의 주된 약속은 부드러운 전환이 아니라 백엔드와 완전히 분리된 데이터 API와 프론트엔드를 만드는 데 있다고 생각함, 그래서 SSR과 클라이언트 렌더링을 섞는 걸 좋아하지 않음, 아예 웹사이트이거나 앱이어야 한다고 봄

  • “SPA와 MPA 기준이 뭔가?” 라는 의문이 있음, 내 Next.js 기반 개인 사이트는 사실상 거의 모든 걸 서버 사이드 렌더함, technically SPA이지만, JS를 켜면 RSC와 클라이언트 사이드 내비게이션이 동작하고, JS를 꺼도 클라이언트 전용 컴포넌트(예: QR 코드 생성기)는 대체 컨텐츠로 보여지고 나머지는 완전히 SSR로 렌더돼 조금 느린 감은 있으나 잘 동작함, 컴포넌트를 서버에서 렌더하지 않는 쪽이 더 손이 많이 감, Progressive enhancement가 최고임

    • “SPA와 MPA의 기준”은 app의 Window load 이벤트가 몇 번이나 발생하는가로 판단할 수 있음

  • 또 SEO 업계나 코로나 이후 입사한 신입 웹 개발자들이 SPA를 자꾸 오해하고 폄하하는 게 너무 답답함, 2000년대부터 개발해온 입장에서 SPA의 진짜 기원은 원문에 나온 "거짓된 약속" 때문이 아니라 2000년대 말~2010년대 초에 모바일 퍼스트 전략이 퍼지면서 frontend와 backend를 아예 분리해야 했기 때문임, 그전엔 프론트란게 서버에서 템플릿으로 HTML 그리는 수준에 jQuery 조금 씌우는 게 일반적이었지만, 이젠 모바일과 데스크톱 앱 모두 같은 비즈니스 로직/DB를 써야 해서, REST 구조 및 Roy Fielding의 논문을 다시 읽으며 서비스 지향 아키텍처와 API 외부 노출이 대세가 됨, 비용 최적화 차원도 있었음, 이 기간 동안 Ruby on Rails나 Django 같은 풀스택 웹 프레임워크는 잠시 침체기를 겪음, Node.js가 부상하면서 브라우저와 모바일도 점점 파워풀해져서 많은 비즈니스 로직을 “엣지 디바이스” 쪽(즉 클라이언트)에 올릴 수 있게 됨, SPA는 바로 이 점이 핵심임, CSS가 그 필요를 대체할 수 없다고 봄

답변달기