SPA란?
SPA란 쉽게 말해 1개의 페이지만 있는 애플리케이션이다. 하나의 페이지에서 내용만 바뀌는 것이다. 서버로부터 새 페이지(html)를 불러오지 않고 현재 페이지를 동적으로 다시 작성하는 웹앱 혹은 그런 웹앱을 작성하는 패러다임, 디자인 패턴이다. 최초로 한 번 페이지 전체를 로드한 후에는 데이터만 변경해서 쓸 수 있다. 서버로부터 정적 파일을 한 번이나 여러 번에 걸쳐 다운로드 받고 사용자와 상호작용 중 필요한 데이터만 서버에서 동적으로 받는다.
SPA 결과물은 하나의 웹 문서가 아니라 응용 프로그램 같은 것이다. 보통 Amazon S3 버킷의 정적 호스팅을 통해 소스나 파일을 전송한다. 여기서 html 파일 전송은 하지 않고 XML이나 JSON만 서버에서 요청되거나 서버로 전송되는데, 이 정적 파일들은 Apache, Nginx, S3이나 Firebase 호스팅 같은 정적 콘텐츠 서버에 업로드할 수 있다. SPA 방식은 Netlify, Vercel 같은 서비스와 Jekyll, Gatsby처럼 정적 사이트 생성기와 찰떡궁합이다.
SPA 구현 방식들
SPA 구현 방식은 여러 가지가 있는데 대표적인 게 Ajax를 통한 콘텐츠 로드이다. 페이지 새로고침 없이 데이터가 교환되고 업데이트되는 것이다.
전통적인 방식에서 클라이언트가 최초 요청을 보내면 서버는 html 파일을 응답으로 보내고, 클라이언트가 다시 form 데이터를 전송하면 서버가 다른 html 파일을 응답으로 보내 페이지가 리로드되는 방식이었다. 그러나 SPA 방식은 form 작성 시 ajax를 이용해서 form 데이터의 일부를 전송하는데, 그럼 서버는 JSON 데이터를 응답으로 보내주는 식이다. 이렇듯 SPA는 화면 이동 시 필요한 데이터를 서버로부터 JSON 데이터로 전달받아 동적으로 렌더링한다.
SPA는 컴포넌트 개념으로 작성된 페이지에 특히 적합한데, React를 사용해서 페이지가 컴포넌트 조각들로 이뤄진 페이지일 경우 컴포넌트의 내용 혹은 컴포넌트 자체를 교체하면 되기 때문에 SPA가 특히 좋다. (컴포넌트 개념이란 컴포넌트들이 모여 한 페이지를 작성하고 특정 부분만 데이터를 바인딩하는 개념)
SPA의 히스토리 관리
기본적인 SPA는 CSR(Client Side Rendering, 클라이언트 사이드 렌더링) 방식을 채택한다. 필요한 부분만 렌더링하며 새로고침이 없고 변하는 부분만 새로 그리는 것인데, URL이 바뀌지 않기에 히스토리 관리가 어려워질 수 있다. 특히 ajax 같은 경우 히스토리가 없어서 사용자가 폼 데이터를 전송한 페이지를 북마크해도 다음에 재접속했을 때 그 페이지가 아니라 초기 페이지를 보게 된다.
SPA를 구현하는 다른 방식인 Hash 방식의 경우 URL는 똑같고 URI의 차이가 생겨서 히스토리 관리가 가능해진다. 해시는 변경돼도 서버에 페이지가 갱신되지 않는다. 해시는 URI에서 #로 시작하는 문자열이다. (문서 내의 참조이기 때문이다. 문서의 특정 부분에 id를 줘서 a 링크를 거기 거는 방식과 똑같음)
URI(Uniform Resources Identifier)는 자원을 식별할 수 있는 문자열이며 가장 큰 개념이다. URI는 URL(Uniform Resource Locator)를 포함하는 큰 개념이다. 순수 자원(html, 이미지 파일, css 등)을 가리키는 것만 URL이면서 URI이다.
가령 내가 구글에 'uri'라고 검색했더니 주소창에 http://www.google.co.kr/search?q=uri 라고 나온다고 가정해보자. 이 때 URL은 google.co.kr/search 까지이다. 물음표(?) 뒤의 q=uri는 쿼리문 식별자이다. 그래서 이 부분은 URI이긴 하지만 URL은 아니다(쿼리문 자체가 자원은 아니기에). URL과 URI의 차이에 대한 더 자세한 설명은 여기서 볼 수 있다.
현재 많은 SPA들은 해시 방식을 쓰거나 SPA 라우터와 함께 history API를 사용해 페이지를 분리해 히스토리를 관리하고 있다.
기존의 MPA 방식
기존 웹은 요청 시마다 새로고침이 발생해서 서버로부터 리소스들을 받아 렌더링하는 방식이었다. 서버가 해당하는 html을 주는 방식을 SSR(Server Side Rendering, 서버 사이드 렌더링)이라고 한다. 대체로 헤더나 푸터는 그대로인데 전체를 다 렌더링하면 비효율적이다. 불변하는 정보도 다 받기 때문이다.
SPA와 반대로 MPA에서는 서버로 form 데이터를 전달해서 새로운 페이지 렌더링을 요청하게 된다.
기존에는 SPA와 반대하는 MPA(Multi Page Application) 디자인 패턴으로 많이 개발했는데, 예를 들면 다른 페이지로 넘어갈 때 URL도 바뀌고 서버로 들어가는 요청에 응답으로 html 파일을 건네서 완전히 새로운 페이지로 넘어가는 것이다. 그런데 보통 웹사이트를 보면 헤더나 푸터, 내비게이션이나 사이드바 등은 그대로 있되 내용만 바뀌는 경우가 많다. html 파일을 건네면 굳이 다시 그리지 않아도 되는 헤더 푸터 등까지 다 같이 전달하게 돼서 트래픽이 늘어나기 때문에 부담이 생기고 느려진다.
하지만 쇼핑몰 사이트를 운영하거나 콘텐츠 배포 등 여러 카테고리가 필요하다면 MPA 방식이 적합하다. SPA가 무조건적인 정답은 아니다. 각자 장단점과 차이가 있을 뿐이다.
Ajax의 역할은?
SPA가 Ajax를 쓰기도 하지만 MPA에서도 ajax를 쓸 수 있다. SPA와 ajax는 서로 포함하는 관계는 아니지만 SPA를 구현하는 하나의 방법으로서 ajax가 존재한다.
SPA는 어느 경로로 접속하든 똑같은 html 문서와 js 파일을 받는다. js가 실행되면서 API로 데이터를 불러오고 마크업으로 화면을 보여주고 사용자의 이동에 맞춰 push state로 히스토리를 바꿔주며 페이지를 보여준다. 실제로는 모두 프론트엔드단에서 처리되는 것들이다.
SPA의 장단점
SPA의 장점
네이티브 앱을 쓰는 것 같은 좋은 사용자 경험(User Experience)
속도 향상
배포가 간단함
서버 요청 적음
트래픽 총량 줄어듦
SPA의 단점
초기 구동 속도가 느림
SEO 최적화에 약함(처음에 전해지는 웹페이지의 소스 코드 내부가 거의 비어 있어서) -> 검색이 잘 안 될 수 있음
IE 8 이하는 지원하지 않음
정리하자면 SPA는 jsp 파일 같은 서버사이드 스크립트 없이 초기 html 파일 내에서 CSS, JS 등 리소스 파일과 모듈들을 로드해 페이지 이동 없이 특정 영역만 새로 모듈을 호출해 데이터를 바인딩하는 애플리케이션이다.
SPA 많이 익히신것같나요? ㅎㅎ