SPA(Single Page Application)는 과연 웹의 미래일까?

나는 SPA가 모던웹의 새로운 정의라고 떠받들여지고 있는 이 시점에서 단호히 아니라고 대답할 수 있다. 이유가 뭐냐. 단순하다. 그냥 불편하다.

SPA는 불편하다. 기존 수많은 get값으로 정의된 a태그들을 이용하여 만들어진 사이트들과 SPA로 만들어진 사이트들을 비교해보면 알 것이다. 기존의 방식대로 이뤄진 사이트들은 각 링크마다 a태그와 주소가 함께 달려있고 브라우저는 이를 링크로 인식하여 오른쪽 클릭으로 해당 요소를 누르면 새 탭에서 열기 등의 부가적인 작업이 가능하다. 그리고 해당 페이지에 들어가면 이러저러한 get값과 texonomy를 통해 페이지가 구성돼있을텐데 이를 그냥 북마크에 저장해놓으면 언제든 다시 와서 해당 페이지를 조회할 수 있다.

하지만 SPA철학을 너무 철저하게 지켜 각 링크가 라우팅이 아닌 Vdom의 생성과 파괴로 전부 이뤄진 페이지라면 주소를 통한 reqeust가 페이지 변화의 주체가 아니라 페이지 내에서 일어나는 상호작용이 페이지를 변경시켜버리기 때문에 부가적인 작업을 하지 않으면 주소를 통한 북마크 저장, 혹은 브라우저에서 제공하는 새 탭에서 열기 기능등을 사용할 수 없다. 만약에 a태그를 통해 해당 부분을 해결하였다면 역시 금방 언급했던 것처럼 a tag가 페이지를 새로고침하지 않게끔 하는 부가적인 작업이 필요하다. 이것이 SPA니까 말이다.

어떻게 보면 잘못만들어진 SPA에 대한 단상으로 느껴질 수도 있겠지만 단순히 예를 들어 이렇게 생각해볼 수 있다.

 페이스북에서는 채팅창을 킨 채로 북마크에 저장해도 해당 북마크에는 채팅창을 켜놨다는 정보가 포함돼있지 않다. (물론 #태그를 통해 구현할 수는 있지만) 그래서 페이스북에 들어갔을 때 항상 채팅창이 켜져있게 할 수가 없다.

 채팅창이라는 예제가 조금 억지스러울 수 있다. 하지만 이걸 SPA형태로 만들어진 위키 웹 어플리케이션이라고 생각해보자. 당신이 자주 조회하는 문서가 있다. 업무상 자주 참고하고 변경하고 확인해야 한다. 하지만 항상 켜놓고 있을 정도까진 아니다. 이럴 때 가장 쉽게 생각할 수 있는 방법이 뭐가 있을까?

 보통의 경우엔 북마크라는 해결책이 있지만 SPA에서는 주소를 통한 라우팅이 아닌, vDOM안에서의 상호작용으로 데이터를 교환하기 때문에 북마크라는 해결책이 존재하지 않는다. 이런 상황에서는 여러 방법이 있다. 서비스를 제공하는 측에서 각 문서에 대한 고유주소를 만들어 제공하든가 혹은 플랫폼 내에서의 북마크 기능을 제공하든가. 어떻게든 서비스 제공 측의 공수가 들어가는 해결책이다. 이것이 SPA의 단점이다.

SPA가 과연 웹의 미래라고 할 수 있을까? 나는 아니라고 생각한다. SPA는 그냥 "다른" 웹 구현 형태이다. vDOM을 이용하는 대표적인 라이브러리 중 하나인 리액트를 만든 페이스북조차 모든 페이지가 SPA로 구현돼있지 않고 적재적소에 필요한 만큼만 적용돼있다. 뿐더러 각 피드에 대한 고유주소도 전부 제공한다. 과연 페이스북이 이걸 전부 SPA로 구현하는 게 어려워서 안했을까? 아니다. 이것은 분명 사용성을 위한 선택이었을 것이다.

SPA가 새로운 웹의 정의이며 나아가야할 방향이라는 말에 현혹되어 맹목적으로 따르지 않길 바라는 마음에 작성하였다. 그리고 위에서 언급했던 SPA로 작성된 불편한 플랫폼은 내 실제 경험이다. 모든 페이지의 주소가 똑같아 브라우저에서 제공하는 북마크가 기능하지 않는데 플랫폼에 북마크 기능도 없고 각 페이지 라우팅 주소도 없는 완전하면서도 불편한 SPA형태의 웹. 실제로 있다.

결국엔 중용이다. vDOM을 사용하는 라이브러리들의 등장과 성장배경을 보면 알 수 있듯이 이들은 사용성을 저해하지 않으면서 유지보수를 쉽게, 때로는 고성능을 내기 위해 채택되고 발전하였다. 이것이 이상한 집착으로 발전하여 모든 것들을 SPA형태로 구현하여 이상한 곳에서 공수가 많이 발생하게 하거나 사용자의 사용성을 저해하게 되는 상황은 피했으면 하는 마음에 적어본다.