싱글 페이지 앱이 웹을 너무 비싸게 만들었다는 불평

• 글쓴이의 출발점은 꽤 도발적임. 이제 ‘프론트엔드 엔지니어’라는 말보다 ‘싱글 페이지 앱(SPA) 개발자’가 더 현실에 가깝다는 얘기임

  • 특히 React를 모르면 SPA 개발자라고 불릴 수 있냐는 분위기가 생겼고, 글쓴이는 10년 넘게 비React 프레임워크를 써온 입장에서 이 흐름을 별로 반기지 않음
  • 단순히 기술 취향 문제가 아니라, 웹 생태계가 대형 플랫폼과 기술 독점의 방향으로 쏠렸다는 정치적·경제적 비판도 깔려 있음

• SPA와 전통적인 멀티 페이지 웹(MPA)의 차이는 사용자가 체감하는 ‘페이지 이동’ 방식에 있음

  • 이 블로그 같은 전통적인 웹페이지는 링크를 누르면 브라우저가 새 요청을 보내고, 새 HTML·CSS·자바스크립트를 받아 전체 페이지를 다시 그림
  • 반면 페이스북에서 게시물을 누르면 실제로 완전히 다른 페이지로 이동한 게 아니라, 복잡한 자바스크립트가 클릭을 가로채고 URL과 화면 일부를 바꿔서 이동한 것처럼 보이게 만듦
  • Gmail, Reddit, Facebook, GitHub 같은 대형 웹 앱이 글쓴이가 말하는 ‘앱’의 전형적인 예시임

• 성능 얘기에서 글쓴이는 숫자로 꽤 세게 찌름

  • 페이스북 로그인 페이지만 해도 CSS가 3.8MB 로드된다고 하고, 크롬 개발자 도구에서 직접 확인할 수 있다고 말함
  • 레딧에서 몇 개 게시물을 클릭하며 돌아다니면 총 33MB 정도를 다운로드하게 된다고 지적함
  • 반대로 Bearblog 같은 가벼운 블로그에서는 상당히 많은 글을 읽어도 1MB에 근접하기 어렵다는 비교를 듦

• 글쓴이가 불편해하는 지점은 ‘느린 웹’만이 아님. SPA가 사용자를 붙잡아두는 방식도 문제라고 봄

  • 성능은 기능이고, 100ms 수준의 개선만으로도 사용자가 앱을 더 쓰게 된다는 연구들이 있다는 점을 언급함
  • 페이스북 안에서 게시물 몇 개를 더 스크롤하는 비용은 낮지만, 레딧으로 앱을 갈아타는 비용은 상대적으로 커짐
  • 즉 SPA는 단순히 기술 구현 방식이 아니라, 사용자를 플랫폼 안에 계속 머물게 만드는 제품 전략과도 맞물려 있다는 주장임

복잡도는 누가 감당하나

• 요즘 SPA 하나 만들려면 기본 세팅부터 이미 작은 프로젝트 수준이 아님

  • React를 고르는 건 거의 안전한 기본값처럼 됐고, “React 골라서 잘린 사람은 없다”는 식의 분위기가 있음
  • 스타일링 쪽에서는 Tailwind CSS, SASS, LESS, CSS 후처리 도구가 따라붙고, 컴포넌트를 직접 다 만들기 싫으면 UI 라이브러리도 골라야 함
  • 여기에 TypeScript, 개발 서버, minifier, Vite나 Parcel·Webpack 같은 번들러까지 들어감

• 문제는 이 모든 게 “명령어 하나면 끝”이라는 말로 포장된다는 점임

  • 처음 생성은 쉬워 보여도, 나중에 Vite를 Parcel로 바꾸고 싶다거나 설정을 깊게 건드리고 싶어지는 순간 난이도가 확 올라감
  • 복잡도를 관리하려고 새 도구가 나오고, 그 도구를 관리하려고 또 다른 도구가 필요해지는 순환이 생김
  • 글쓴이는 이 흐름이 개발자를 자유롭게 하기보다, 특정 기업과 생태계가 승인한 도구 조합 안에 가두는 쪽에 가깝다고 봄

• 이 복잡도는 페이스북 같은 회사에는 큰 문제가 아닐 수 있음

  • 대기업은 개발자 도구만 전담하는 빌딩 단위의 팀을 둘 수 있음
  • 하지만 스타트업, 개인 개발자, 오픈소스 프로젝트에는 프론트엔드 기본 세팅 자체가 꽤 무거운 비용이 됨
  • 글쓴이가 작업 중인 CSS 프로젝트에서도 여러 도구 문서는 Vite, Webpack, Parcel을 전제로 설명하고, 단순 CLI 사용법은 아래쪽에 묻혀 있는 경우가 많았다고 함

그래도 대안은 있음

• 글쓴이는 새 기술 자체를 반대하지 않음. 오히려 더 나은 새 기술이 필요하다고 말함

  • 원하는 건 사용자가 기대하는 인터랙션을 주면서도, 번들 비대화와 도구 복잡도를 줄이는 프론트엔드 프레임워크임
  • 즉 ‘SPA냐 옛날 웹이냐’의 이분법이 아니라, 필요한 만큼만 자바스크립트를 쓰는 방향을 찾자는 얘기임

• CSS 쪽에서는 PostCSS와 Lightning CSS 같은 후처리 도구를 긍정적으로 봄

  • 최신 CSS 기능을 제대로 쓸 수 있게 해주면 CSS 자체가 생각보다 나쁜 언어가 아니라는 입장임
  • Tailwind CSS나 SASS가 제공하던 편의 기능 중 일부는 최신 CSS와 가벼운 후처리만으로도 덜 필요해지고 있다고 봄

• 프레임워크 쪽에서는 Preact와 Astro를 좋은 신호로 언급함

  • Preact는 빌드 도구 없이도 시작할 수 있는 가벼운 웹 프레임워크로 소개됨
  • Astro는 Preact 창시자가 설명했던 ‘아일랜드’ 접근을 활용해, 전체 웹페이지를 풀 자바스크립트 앱으로 만들 필요를 줄임
  • 필요한 부분만 인터랙티브하게 만들고 나머지는 정적인 HTML로 두는 방식이라, SPA의 과한 비용을 피하는 대안으로 읽힘

• 글의 진짜 질문은 “왜 이 웹사이트가 앱이어야 하지?”에 가까움

  • 모든 페이지가 Gmail이나 GitHub처럼 복잡한 상태와 상호작용을 갖는 건 아님
  • 글 목록, 문서, 블로그, 마케팅 페이지, 간단한 도구까지 모두 SPA 기본값으로 시작하면 사용자도 개발자도 비용을 냄
  • 한국 개발팀 입장에서도 새 프로젝트를 시작할 때 “React + Vite + Tailwind가 기본”이라고 박기 전에, 실제 제품의 인터랙션 밀도와 유지보수 비용을 먼저 봐야 한다는 얘기로 받아들일 만함

---

기술 맥락

• SPA를 고르는 이유는 보통 화면 전환을 빠르게 만들고 앱 같은 상태 관리를 하기 위해서예요. 그런데 이 글은 그 선택이 항상 공짜가 아니라고 짚어요. 첫 진입 때 큰 자바스크립트와 CSS를 내려받아야 하고, 사용자가 실제로 필요한 인터랙션보다 훨씬 큰 런타임을 싣는 경우가 많거든요.

• React, Vite, TypeScript, Tailwind CSS 같은 조합은 팀 단위 개발에서는 분명 장점이 있어요. 채용도 쉽고, 레퍼런스도 많고, 큰 코드베이스를 나누어 관리하기 좋거든요. 다만 작은 사이트나 문서 중심 서비스에서는 이 장점보다 설정과 번들 비용이 먼저 튀어나올 수 있어요.

• Astro의 아일랜드 아키텍처나 Preact 같은 대안이 의미 있는 이유는 전체 페이지를 하나의 거대한 앱으로 보지 않기 때문이에요. 서버나 빌드 타임에 HTML을 먼저 만들고, 진짜로 클릭과 상태가 필요한 컴포넌트에만 자바스크립트를 붙이면 초기 로딩 비용을 줄일 수 있어요.

• 실무에서는 “SPA가 나쁘다”보다 “이 화면이 정말 SPA여야 하나”를 먼저 물어보는 게 좋아요. 관리자 콘솔처럼 상태 전환이 많은 화면은 SPA가 맞을 수 있지만, 뉴스·문서·블로그·상품 소개 페이지라면 MPA나 부분 하이드레이션 방식이 더 단순하고 빠를 수 있거든요.