"이제 그만 좀 합시다" - SPA 만능주의에 던지는 어느 개발자의 직설적인 질문

또 React로 시작하시려고요?

새 웹 프로젝트 만든다고 하면 거의 자동반사처럼 npx create-next-app 치거나 Vite로 React 셋업하잖아요. 그런데 한 개발자가 본인 블로그에 "SPA의 폭정(The tyranny of single page apps)"이라는 좀 도발적인 제목으로 글을 올렸어요. 요지는 간단해요. "우리가 그냥 관성으로 SPA를 쓰고 있는 거 아닌가? 진짜 모든 웹사이트에 SPA가 필요한 거 맞아?" 평소엔 그냥 당연하게 넘겼던 부분을 다시 생각하게 만드는 글이거든요.

SPA가 뭔지 다시 짚어보면

SPA(Single Page Application)가 뭐냐면, 처음 페이지 열 때 커다란 JavaScript 번들을 통째로 받아두고, 그 다음부터는 페이지 이동할 때마다 서버에 HTML 새로 요청하지 않고 JS가 알아서 화면 내용을 바꿔주는 방식이에요. 클릭해도 새로고침 없이 부드럽게 전환되니까 사용자 입장에선 앱처럼 느껴지죠. Gmail이나 Figma처럼 정말 "앱"에 가까운 서비스에선 이게 진가를 발휘해요.

문제는 블로그, 회사 소개 페이지, 단순한 쇼핑몰 같은 "그냥 문서를 보여주는" 사이트까지 다 SPA로 만들고 있다는 거예요. 글쓴이는 이게 망치 하나 가졌다고 모든 걸 못으로 보는 거랑 비슷하다고 봐요.

무엇이 문제인가

첫 번째는 초기 로딩 시간이에요. SPA는 화면에 뭐라도 그리려면 JS 번들이 다 다운로드되고 파싱되고 실행돼야 하거든요. 사용자는 그 시간 동안 빈 화면이나 스피너만 보고 있어야 해요. 반면 전통적인 서버 렌더링 페이지는 HTML이 도착하는 순간 바로 글자가 보이죠.

두 번째는 접근성과 SEO예요. JS가 실행돼야 콘텐츠가 보이는 구조라서, 검색 엔진 크롤러나 스크린리더가 제대로 읽지 못하는 경우가 종종 생겨요. Next.js 같은 SSR(Server Side Rendering) 프레임워크가 이 문제를 많이 해결해주긴 했는데, 그렇게 SSR을 끼우는 순간 "순수 SPA의 장점"이 어디까지 남는 거냐는 질문이 나오게 되거든요.

세 번째는 개발 복잡도예요. 클라이언트 상태 관리(Redux, Zustand 같은 라이브러리)와 서버 상태(React Query, SWR)를 따로 관리해야 하고, 라우팅도 직접 만들고, 폼 처리도 직접 만들고... 그런데 이 모든 게 서버 렌더링에서는 그냥 <form action="/submit"> 한 줄로 끝나는 일이거든요. 단순한 일을 복잡하게 만드는 셈이에요.

흐름의 변화

재밌는 건 업계도 이미 이 방향으로 움직이고 있다는 거예요. Next.js의 App Router에서 등장한 React Server Components는 "필요한 것만 클라이언트로 보내고 나머지는 서버에서 처리하자"는 발상이에요. Remix는 처음부터 "웹의 기본을 존중하자(Use the platform)"라는 철학을 내세웠고요. Astro는 아예 "기본은 정적 HTML, 인터랙티브한 부분만 JS로"라는 아일랜드 아키텍처를 들고 나왔어요. HTMX 같은 라이브러리는 SPA 없이도 부분 갱신이 충분히 가능하다는 걸 보여주고 있고요.

한국 개발자에게는

실무에서 당장 적용할 수 있는 교훈이 있어요. 새 프로젝트 시작할 때 "이거 진짜 SPA여야 하나?"를 한 번만 묻고 가는 거예요. 사내 어드민 도구, 로그인 후에만 쓰는 대시보드라면 SPA가 맞아요. 근데 누구나 보는 마케팅 페이지, 콘텐츠 위주의 블로그, SEO가 중요한 커머스 카탈로그라면 Astro나 Next.js의 정적 생성, 혹은 그냥 Rails/Django의 서버 렌더링이 훨씬 빠르고 단순하거든요. 도구는 문제에 맞춰 골라 쓰는 거지, 도구가 문제를 정의하면 안 되니까요.

한 줄 정리

SPA는 강력한 도구지만 만능 해법은 아니에요. "왜 이걸 쓰는가"라는 질문 없이 기본값으로 선택하는 순간 우리는 도구의 폭정 아래 놓이게 돼요. 여러분은 최근 프로젝트에서 SPA가 정말 필요했다고 느끼셨나요, 아니면 그냥 익숙해서 쓰셨나요?