싱글 페이지 애플리케이션의 세상
싱글 페이지 애플리케이션(SPA)이란?
싱글 페이지 애플리케이션(Single Page Application: SPA)이란 렌더링과 라우팅에 필요한 대부분의 기능을 서버가 아닌 자바스크립트에 의존하는 방식을 의미한다.
최초에 첫 페이지에서 데이터를 모두 불러온 이후에는 서버에서 HTML을 내려받지 않고 하나의 페이지에서 모든 작업을 처리한다.
페이지 전환 시에도 새로운 HTML 페이지를 요청하는 게 아니라 자바스크립트에서 다음 페이지의 렌더링에 필요한 정보만 HTTP 요청 등으로 가져온 다음, 그 결과를 바탕으로 DOM을 추가, 수정, 삭제하는 방법으로 페이지가 전환된다.
이러한 작동 방식은 최초에 로딩해야 할 자바스크립트 리소스가 커지는 단점이 있지만 한번 로딩된 이후에는 서버를 거쳐 필요한 리소스를 받아올 일이 적어지기 때문에 사용자에게 훌륭한 UI/UX를 제공한다는 장점이 있다.
출처: https://lvivity.com/single-page-app-vs-multi-page-app
전통적인 방식의 애플리케이션과 싱글 페이지 애플리케이션의 작동 비교
과거 서버 사이드에서 작동하던 전통적인 방식은 페이지 전환이 발생할 때마다 새롭게 페이지를 요청하고, HTML 페이지를 다운로드해 파싱하는 작업을 거친다. 이 과정은 페이지를 처음부터 새로 그려야 해서 일부 사용자는 페이지가 전환될 때 부자연스러운 모습을 보게 된다.
그러나 이러한 페이지 전환을 모두 자바스크립트로 한다면 최초에 한번 모든 리소스를 다운로드 한 후 페이지 전환에 필요한 일부 영역만 다시 그릴 수 있으므로 훨씬 더 매끄러운 UI를 보여줄 수 있게 된다.
싱글 페이지 렌더링 방식의 유행과 JAM 스택의 등장
싱글 페이지 애플리케이션의 유행으로 인해 새롭게 생겨난 용어는 바로 JAM 스택이다.
기존의 웹 개발은 LAMP 스택, 즉 Linux(운영체제), Apache(서버), MySQL(데이터베이스), PHP/Python(웹 프레임워크)으로 구성되어 있었다.
과거에는 대부분의 처리를 서버에서 해야만 했기 때문이다.
그러나 싱글 페이지 렌더링 방식이 인기를 끌면서 JAM(JavaScript, API, Markup) 스택이 등장했다. 자바스크립트와 마크업(HTML, CSS)을 미리 빌드해 두고 정적으로 사용자에게 제공하면 이후 작동은 모두 사용자의 클라이언트에서 실행되므로 서버 확장성 문제에서 좀 더 자유로워질 수 있게 된 것이다.
새로운 패러다임의 웹서비스를 향한 요구
많은 양의 리소스가 자바스크립트로 넘어오기 시작하던 때, 자바스크립트 코드의 규모도 점차 커지면서 이에 대해 우려의 목소리도 조금씩 나오기 시작했다. 하지만 폭발적인 기술의 발전으로 이러한 문제가 자연스럽게 해결될 것이라 기대했다.
하지만 자바스크립트 파싱을 위해 CPU를 소비하는 시간이 눈에 띄게 증가했고, 그만큼 자바스크립트에서 처리해야 하는 코드의 절대적인 양도 증가했다. 이로 인해 웹사이트 방문자들은 생각보다 많은 시간을 웹사이트 로딩에 소비해야 했다.
현재 사용자의 기기와 인터넷 속도 등 웹 전반을 이루는 환경이 크게 개선됐음에도 실제 사용자들이 느끼는 웹 애플리케이션의 로딩 속도는 과거나 지금이나 크게 차이가 없거나 오히려 더 느려졌다는 것이다.
서버 사이드 렌더링이란❓
서버 사이드 렌더링은 최초에 사용자에게 보여줄 페이지를 서버에서 렌더링해 빠르게 사용자에게 화면을 제공하는 방식을 의미한다.
웹페이지가 점점 느려지는 상황에 대한 문제의식을 싱글 페이지 애플리케이션의 태생적인 한계에서 찾고, 이를 개선하고자 서버에서 페이지를 렌더링해 제공하는 기존 방식의 웹 개발이 다시금 떠오르고 있다.
싱글 페이지 애플리케이션(SPA)과 서버 사이드 렌더링(SSR)의 차이는 웹페이지 렌더링의 책임을 어디에 두느냐다.
SPA는 사용자에게 제공되는 자바스크립트 번들에서 렌더링을 담당하지만,
SSR은 렌더링에 필요한 작업을 모두 서버에서 수행한다.
출처: https://lvivity.com/single-page-app-vs-multi-page-app
서버 사이드 렌더링의 장점
1️⃣ 최초 페이지 진입이 비교적 빠르다.
일반적으로 서버에서 HTTP 요청을 수행하는 것이 더 빠르고, 또 HTML을 그리는 작업도 서버에서 해당 HTML을 문자열로 미리 그려서 내려주는 것이 클라이언트에서 기존 HTML에 삽입하는 것보다 더 빠르다.
모든 경우에 서버 사이드 렌더링이 이점을 가진다고는 볼 수 없지만 화면 렌더링이 HTTP 요청에 의존적이거나 렌더링해야 할 HTML의 크기가 커진다면 상대적으로 서버 사이드 렌더링이 더 빠를 수 있다.
2️⃣ 검색 엔진과 SNS 공유 등 메타데이터 제공이 쉽다.
서버 사이드 렌더링은 검색 엔진 최적화에 유용하다.
📌 검색 엔진이 사이트에서 필요한 정보를 가져가는 과정
1. 검색 엔진 로봇이 페이지에 진입한다.
2. 페이지가 HTML 정보를 제공해 로봇이 이 HTML을 다운로드 한다.
단, 자바스크립트 코드는 실행하지 않는다.
3. 다운로드한 HTML 페이지 내부의 오픈 그래프나 메타 태그 정보를 기반으로 페이지의 검색 정보를 가져오고 이를 바탕으로 검색 엔진에 저장한다.
로봇은 페이지를 보는 것이 아닌 페이지의 정적인 정보를 가져오는 것이 목적이므로 자바스크립트를 다운로드하거나 실행할 필요가 없다.
하지만 싱글 페이지 애플리케이션은 메타 정보를 포함한 대부분의 작동이 자바스크립트에 의존적이다.
반면, 서버 사이드 렌더링은 검색 엔진에 제공할 정보를 서버에서 가공해 HTML 응답으로 제공할 수 있으므로 검색 엔진 최적화에 대응하기가 매우 용이하다.
3️⃣ 누적 레이아웃 이동이 적다.
누적 레이아웃 이동이란 사용자에게 페이지를 보여준 후에 뒤늦게 어떤 HTML 정보가 추가되거나 삭제되어 마치 화면이 덜컥거리는 것과 같은 부정적인 사용자 경험을 말한다. 즉, 사용자가 예상하지 못한 시점에서 페이지가 변경되어 불편을 초래하는 것을 말한다.
싱글 페이지 애플리케이션에서는 페이지 콘텐츠가 API 요청에 의존하고, API 요청 속도가 제각각이며, 이를 적절히 처리하지 않는다면 누적 레이아웃 이동 문제가 발생할 수 있다.
반면, 서버 사이드 렌더링의 경우에는 이러한 요청이 완전히 완료된 이후에 완성된 페이지를 제공하므로 이러한 문제에서 비교적 자유롭다.
4️⃣ 사용자의 디바이스 성능에 비교적 자유롭다.
자바스크립트 리소스 실행은 사용자의 디바이스에서만 실행되므로 절대적으로 사용자 디바이스 성능에 의존적이다.
그러나 서버 사이드 렌더링을 수행하면 이러한 부담을 서버에 나눌 수 있으므로 사용자의 디바이스 성능으로부터 조금 더 자유로워질 수 있다.
5️⃣ 보안에 좀 더 안전하다.
JAM 스택을 채택한 프로젝트의 문제점음 애플리케이션의 모든 활동이 브라우저에 노출된다는 것이다. API 호출과 인증 같이 사용자에게 노출되면 안 되는 민감한 작업도 포함되므로 정상적인 비즈니스 로직을 거치지 않은 상황에서 인증이나 API가 호출되는 것을 항상 방지할 준비가 돼 있어야 한다.
서버 사이드 렌더링의 경우 인증 혹은 민감한 작업을 서버에서 수행하고 그 결과만 브라우저에 제공해 이러한 보안 위협을 피할 수 있다는 장점이 있다.
서버 사이드 렌더링의 단점
1️⃣ 소스코드를 작성할 때 항상 서버를 고려해야 한다.
서버 사이드 렌더링을 적용하기로 했다면 소스코드 전반에 걸쳐 서버 환경에 대한 고려가 필요하다. 작성한 코드 뿐만 아니라 외부에서 의존하고 있는 라이브러리도 마찬가지다.
해당 라이브러리가 마찬가지로 서버에 대한 고려가 돼 있지 않다면 다른 대안을 찾거나 클라이언트에서만 실행될 수 있도록 처리해야 한다. 하지만 클라이언트에서만 실행되는 코드가 많아질수록 서버 사이드 렌더링의 장점을 잃는 셈이다.
2️⃣ 적절한 서버가 구축돼 있어야 한다.
서버 사이드 렌더링은 말 그대로 사용자의 요청을 받아 렌더링을 수행할 서버가 필요하다. 사용자의 요청에 따라 적절하게 대응할 수 있는 물리적인 가용량을 확보해야 하고, 예기치 않은 장애 상황에 대응할 수 있도록 복구 전략도 필요하다.
또한, 요청을 분산시키고, 프로세스가 예기치 못하게 다운될 때를 대비하여 프로세스 매니저의 도움도 필요하다.
3️⃣ 서비스 지연에 따른 문제
싱글 페이지 애플리케이션에서 무언가 느린 작업이 있다면, 최초에 어떤 화면이라도 보여준 상태에서 무언가 느린 작업이 수행되기 때문에 '로딩 중'과 같이 작업이 진행 중임을 적절히 안내한다면 충분히 사용자가 기다릴 여지가 있다.
반면 서버 사이드 렌더링에서 지연이 일어나면, 사용자에게 보여줄 페이지에 대한 렌더링 작업이 끝나기까지는 사용자에게 그 어떤 정보도 제공할 수 없다.
애플리케이션의 규모가 커지고 작업이 복잡해지고, 이에 따라 다양한 요청에 얽혀있어 병목 현상이 심해진다면 때로는 서버 사이드 렌더링이 더 안 좋은 사용자 경험을 제공할 수 도 있다.
SPA와 SSR을 모두 알아야 하는 이유
서버 사이드 렌더링 역시 만능이 아니다.
모든 무거운 작업을 서버에 미루고, 작업이 모두 서버에서 이뤄진다고 해서 모든 성능 문제가 해결되는 것은 아니다. 잘못된 웹페이지 설계는 오히려 성능을 해칠 뿐만 아니라 눈에 띄는 성능 개선도 얻지 못하고 서버와 클라이언트 두 군데로 관리 포인트만 늘어나기만 하는 역효과를 낳을 수도 있다.
웹페이지의 설계와 목적, 그리고 우선순위에 따라 싱글 페이지 애플리케이션이 더 효율적일 수도 있다.
현대의 서버 사이드 렌더링
기존 LAMP 스택은 모든 페이지 빌드를 서버에서 렌더링해 초기 페이지 진입이 빠르다는 장점이 있고, 싱글 페이지 렌더링 방식은 라우팅이 빠르다는 장점이 있다. 그래서 요즘의 서버 사이드 렌더링은 이 두 가지 장점을 모두 취한 방식으로 작동한다.
먼저, 최초 웹사이트 진입 시에는 서버 사이드 렌더링으로 서버에서 완성된 HTML을 제공받고, 이후 라우팅에서는 서버에서 내려받은 자바스크립트를 바탕으로 마치 싱글 페이지 애플리케이션처럼 작동한다.
요즘 각광받는 Next.js, Remix는 서버 사이드 렌더링 프레임워크로 모두 이러한 방식으로 작동해 사용자에게 더 나은 웹사이트 경험을 알려준다.
