SPA 는 죽어가는가

최근? 이라고 하기도 그렇고, 1~2년 전 부터 SinglePageApp (SPA) 에
대한 비난이 커지고 있다.

C# 을 이용한 웹개발에서 angular.js 를 시작으로 fe 프레임워크를 접한 나에게
좋은 얘기는 아닌 것 같다.

도데체 SPA가 뭘 잘못했길래 이렇게 비난을 받고 있는가?
과연 SPA는 잘못된 방향으로 가고 있고, MPA가 웹 서비스와 관련된 올바른 방향일까?

MPA의 장점은 뭘까

전통적인 방식

브라우저와 웹의 역사를 되돌아보면 전통적으로
MPA 방식이 웹페이지의 시초 이며
데이터가 이미 입력된, 미리 만들어진 html 파일을
서버에서 받아 브라우저는 단순히 html 을 파싱하여 보여주는 방식이었다.

지금처럼 사용자와의 상호작용을 위한 거대한 js 파일을 다운로드 할 필요가 없었다.
ajax 가 나오기 전에는 새로운 데이터를 받거나, 보낼때도 모든 부분을 서버에서
처리하기 때문에 브라우저는 그냥 단순히 폼데이터를 보내거나, 새로운 페이지를 요청하는 등의 단순한 행동만이 필요했다.

단순한 행동만을 한다, 그리고 추가 리소스가 매우 적다는 건 일단 속도가
당연히 빠를 것이다.

빠른속도, SEO

MPA 의 가장 큰 장점인 초기 페이지 로딩 속도와 SEO.
지금도 SSR 방식의 장점 중 하나가 초기 페이지 로딩이 빠르다는 점은 빠지지 않고
나오고 있다.

그래, SPA 보다 속도가 빠르다는 건 알았다.(과연?)
추가로 나오는 장점 중 SEO 에 좋다는 부분?

알다싶이 SPA는 모든 것을 Javascript 로 처리하기 때문에
html 파일에는 대부분 해당 웹을 작동시키기 위한 js 파일만 포함되고
나머지 컨텐츠는 텅 비어 있다.

반대로 MPA 방식은 모든 컨텐츠가 꽉꽉 채워져 있기 때문에
당연히 SPA 보다 검색엔진에 더 노출되기 쉽다.

내가 사용자에게 많은 서비스를 제공하는 쇼핑몰, SNS 서비스는
이런 장점이 크게 다가온다.
쇼핑몰의 특정 상품링크를 받아 페이지를 오픈할때
텅빈 화면과 함께 오랜 로딩 시간이 지속되면 사용자가 떠날 확률이 높다.

이제 장점보다는 SPA 가 비난 받는 이유를 보자.

SPA는 왜 그래?

윗 글에 적은대로 초기페이지 속도가 느리다는 점.
SEO 에 최적화 되지 않았다는 점.
라우팅을 처리 할때 너무 많은 wrapper 가 있다는 점.

Route 에선?

SPA 는 브라우저의 라우팅 방식을 해킹?하여 사용한다.
뒤로가기, 또는 앞으로 가기, 특정 주소에 다이렉트로 접근 등
기본적으로 브라우저는 해당 URL 이 들어왔을때 해당 URL의 서버에 접근해서
내가 파싱할 document 를 달라고 요청한다.
전통적으로 그렇다.

하지만 SPA 는 이 모든 걸 wrapping 하여 javascript 로 처리하게 된다.
SPA 의 시작점은 index.html 이고, 빌드한 파일을 서버에 올렸을때,
해당 도메인의 뒷 부분이 어떻게 되든 모든 시작점은 index.html 로 들어가게 된다.
아니, 정확히는 그렇게 하도록 설정을 해둔다.

특정 URL 의 document 가 아닌, index.html 과 index.html 에 포함된
거대한 js 파일을 다운로드 하면, 이제부터 라우팅 해킹이 시작된다.

모든건 js 에서 처리한다.
browser histroy 를 가져와서 입맛대로 변경시키고, url 이 변경될때
단순히 history 에 push 만 하고, url이 변경만 될뿐, 서버에 요청하지 않는다.
그리고 변경된 url 을 감지하여 우리가 원하는 컨텐츠를 렌더링 하도록 만들게 된다.
vanila js 가 아니라면
대부분 router 와 관련된 라이브러리에서 이를 처리하게 될 것이다.

말그대로 single page app 이다.
이러한 방식의 문제점은 seo 가 힘들다는 점으로 이어진다.
어떤 url 을 가도 무조건 시작점인 index.html 로 이어지기 때문.

할게 많다, 지친다.

또 다른 단점으로는 클라이언트에서 처리해야 할 문제가 굉장히 많아진다.
점점 많아지고 있다.
웹이 점점 발전함에 따라 브라우저에서 할 수 있는 일들이 너무 많이 생겼다.
수많은 style 작성과 ui 를 위한 state 관리, 사용자와 상호작용을 위한
코드, 추가로 서버와 통신하여 데이터를 요청하고,
그 데이터를 또 관리하고..

MPA 는 그런 측면에서 클라이언트의 부담을 많이 줄여준다.
클라이언트의 고통을 나눠가진다는 것.

그래서 이제 SPA 보다 MPA 를 선호해야 하나?

그전에 왜 SPA 가 나타나고, 더욱 발전하게 되었는지 생각해 보았다.
아마도 모바일 사용자의 엄청난 증가가 시발점이 된게 아닐까?

모든 웹 페이지는 이제 모바일 퍼스트로 제작되고, 모바일 용 레이아웃이 없는
사이트는 사용자가 더 이상 찾지 않을 것이다.

MPA가 모바일 사용자에게 적합할까?
모바일은 데스크톱과 다르게 앱으로 서비스를 제공하는 것에 특화되어 있다.
사용자는 앱사용에 익숙해져 있다.
앱과 같은 사용성과 상호작용을 원한다.

SPA 의 가장 큰 장점인 부드러운 상호작용과 끊김없는 컨텐츠 이동이
아마도 모바일에서 사용하기에 어울리지 않을까?

pwa 와 service worker 의 사용으로 웹을 앱처럼 설치하고
오프라인에서도 이용하며, push 까지 받을 수 있게 되었다.

점진적으로 발전하는 웹

웹 api 는 모바일에서 할수 있는 native api 를 점점 따라가고 있다.
결국 웹이 가고자 하는 방향은 웹이 아닌 응용프로그램이 되는 것이다.

SPA 의 특징인 라우팅을 wrapping 하여 url 변경으로 인한 서버의 요청을
막는다는 건 웹 페이지가 새로운 document 로 인해 refresh 되지 않는다는 점이고,
이는 웹을 앱처럼 사용할 수 있도록 하는 가장 중요한 부분이다.

SPA 는 웹에서 앱처럼 여러 작업을 끊김없이 할 수 있는 최상의 UX,UI 를 만들 수 있다.
MPA 에서 비디오를 켜고, 음악을 들으며 다른 페이지로 이동할 수 있을까? 불가능하다.
(iframe 을 사용하면 가능하긴 하다. 그런데 쓰고 싶은가?)
수많은 MPA 에서 수많은 ui state 를 유지하며, 페이지를 이동 할 수 있을까?
쉽지 않다.

또 하나의 SPA를 위한 방어룰 해보자면 code spliting, lazy load, preload,
tree shaking 등
SPA 의 단점?인 속도를 커버 할 수 있는 기술이 상당히 많다.
이들은 이미 우리가 익숙한 webpack, parcel 등의 번들러에 포함되어 있다.

통신속도는 점점 빨라지고, pc 와 모바일의 성능도 점점 좋아지고 있다.
지금은 90년대가 아니다.
사용자들이 1mb, 2mb 의 컨텐츠를 다운로드 받기위해 수초가 걸리는 그런 시대는
이미 지나갔다.

결론은

위에 적었듯이 MPA 는 클라이언트의 부담을 줄여준다.
대신에 서버에 부담을 늘린다. 결국 그 부담의 양은 줄어들지 않는다.

나는 점점 더 클라이언트와 서버의 역할이 확실하게 나뉘는 방향으로
가는게 옳다고 생각한다.

클라이언트에서 해야할, 해줘야 할 일들이 너무 많이 늘어났다.
웹은 예전의 신문처럼 보는 그런 웹이 더이상 아니다.
이제는 빠르고 쉽게 접속이 가능한 instant app 수준까지 도달했다.
특정 사이트는 그를 뛰어 넘었고.

그렇다고 MPA 가 안좋다는 말은 또 아니다.
SPA로 할수밖에 없는 사이트들, figma, google map 또는 채팅 앱 등,
사용자들과 끊임없이 상호작용을 하는 사이트 들이 있다.

readonly 사이트들, 뉴스, 블로그, 상호작용이 거의 없는 페이지,
그리고 seo 에 민감한 서비스들은 여전히 MPA 로 가져가는 이득이
SPA 보다 더 크다고 생각한다.

무조건 이걸로 해야한다는 정답은 없다.
결국 서비스와 엔지니어들의 역량에 따라 SPA를 선택할지, MPA를 선택할지
갈리게 된다.

SPA 는 죽어가는게 아니다. 오히려 웹이 더욱 응용프로그램에
가깝도록 발전을 촉진시키는 역할을 하고 있다.