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의 성능을 따라갈 수 없다고 생각함
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가 그 필요를 대체할 수 없다고 봄
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의 성능을 따라갈 수 없다고 생각함
이 글 쓴 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 개발자는 보통 이런 곳에 많으니, 무조건 최초 프레임을 완벽히 제공하려는 부담 때문에 불필요한 짐을 가지지 않는 게 중요함
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는 클라이언트 로직을 위한 훌륭한 프레임워크, 관심사 분리(프론트 로직과 백엔드 분리), 개발 경험 개선→빠른 개발 속도 등 다양한 장점이 있음, 이런 글이 많이 보이는 건 내 댓글처럼 논쟁을 부르는 구조 덕분인데 사실 이렇게 주목받을 글은 아니라고 생각함
내 입장에선 SPA의 주된 약속은 부드러운 전환이 아니라 백엔드와 완전히 분리된 데이터 API와 프론트엔드를 만드는 데 있다고 생각함, 그래서 SSR과 클라이언트 렌더링을 섞는 걸 좋아하지 않음, 아예 웹사이트이거나 앱이어야 한다고 봄
“SPA와 MPA 기준이 뭔가?” 라는 의문이 있음, 내 Next.js 기반 개인 사이트는 사실상 거의 모든 걸 서버 사이드 렌더함, technically SPA이지만, JS를 켜면 RSC와 클라이언트 사이드 내비게이션이 동작하고, JS를 꺼도 클라이언트 전용 컴포넌트(예: QR 코드 생성기)는 대체 컨텐츠로 보여지고 나머지는 완전히 SSR로 렌더돼 조금 느린 감은 있으나 잘 동작함, 컴포넌트를 서버에서 렌더하지 않는 쪽이 더 손이 많이 감, Progressive enhancement가 최고임
또 SEO 업계나 코로나 이후 입사한 신입 웹 개발자들이 SPA를 자꾸 오해하고 폄하하는 게 너무 답답함, 2000년대부터 개발해온 입장에서 SPA의 진짜 기원은 원문에 나온 "거짓된 약속" 때문이 아니라 2000년대 말~2010년대 초에 모바일 퍼스트 전략이 퍼지면서 frontend와 backend를 아예 분리해야 했기 때문임, 그전엔 프론트란게 서버에서 템플릿으로 HTML 그리는 수준에 jQuery 조금 씌우는 게 일반적이었지만, 이젠 모바일과 데스크톱 앱 모두 같은 비즈니스 로직/DB를 써야 해서, REST 구조 및 Roy Fielding의 논문을 다시 읽으며 서비스 지향 아키텍처와 API 외부 노출이 대세가 됨, 비용 최적화 차원도 있었음, 이 기간 동안 Ruby on Rails나 Django 같은 풀스택 웹 프레임워크는 잠시 침체기를 겪음, Node.js가 부상하면서 브라우저와 모바일도 점점 파워풀해져서 많은 비즈니스 로직을 “엣지 디바이스” 쪽(즉 클라이언트)에 올릴 수 있게 됨, SPA는 바로 이 점이 핵심임, CSS가 그 필요를 대체할 수 없다고 봄