※ 일본의 한 블로그 글을 번역한 포스트입니다. 오역 몇 직역, 의역이 있을 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다.
개요
SPA, SSR, SSG이라는 기술 용어를 작업 중이나 블로 그 글에서 본 적이 있지만, 지금까지 구체적으로 알아보지 않고 지냈다. 일단 Gatsby.js이나 Next.js를 다루고 있으므로, 이러한 개념을 제대로 이해해두면 안 될 것 같다는 생각이 들어 이번 기회에 정리해봤다.
SPA
SPA의 요지를 간단하게 말하자면, 하나의 페이지에 먼저 호스팅 서버에서 얻은 그 페이지를 기축으로, 표시하고 싶은 것이 있다면 그에 대한 데이터를 매번 API에서 취득하는 아키텍처이다.
이것은 Single Page Application의 약칭으로, 하나의 페이지를 바탕으로 이것 저것 동작한다는 생각이 그 근간으로 존재하기 때문에 이렇게 명명된 것 같다.
이 설명뿐만으로는 이해하기 힘들 것이라고 생각되므로, 먼저 SPA와 대비 관계에 있는 MAP(Mutil Page Application)이라는 아키텍처에 대해서도 살펴보면서 SPA의 메리트는 무엇인지 설명하도록 하겠다.
MPA
MPA는 Ralis등에 대표되는 백엔드의 프레임워크에만 사용되는 형식으로 이전에는 꽤 자주 채용됐다. 브라우저에서 "이러한 페이지를 원해"라고 HTTP 리퀘스트를 받으면 Web 서버는 내부에서 HTML을 만들어, JavaScript나 CSS를 함께 HTTP 리스폰스로 돌려준다. 중요한 것은 이 처리가 페이지를 이동할 때마다 매번 반복된다는 것이다.
그림으로 나타낸다면 다음과 같다.
유저는 버튼을 누를 때마다 페이지가 로드될 때마다 기다려야하고 무거운 페이지의 경우 더욱 시간이 걸린다는 담점이 있다. 일반적인 SPA는 이러한 단점을 해소 혹은 완화할 수 있는 아키텍처이다.
다시, SPA
위에서 설명했듯, SPA는 "하나의 페이지를 먼저 호스팅 서버에서 얻은 다음, 그 페이지를 기축으로 표시하고 싶은 것이 있다면 그에 따른 데이터를 API에서 얻는 아키텍처"이다.
즉, MPA와 달리 페이지를 얻어오는 것은 맨 처음뿐이므로, 두 번째 이후에는 API에서 데이터를 받아 바뀐 부분만을 바꿔서 보여준다.
그림으로 설명하자면 다음과 같다.
위 그림에서 알 수 있듯, 2번째 이후의 페이지 이동을 표시하기 위한 리퀘스트는 처리는 Ajax에서 실현한다.
이 아키텍처의 최대의 메리트는 페이지 이동을 할 때에 시간을 낭비하지 않고, 유저가 가벼운 마음으로 Web 사이트를 사용할 수 있게 된다는 것이다.
그 외에는 이것은 Ajax의 장점일지도 모르겠지만, JavaScript를 이용하여 페이지 내에서의 변화, 처리를 표현할 수 있으므로, 부드러운 UI를 만들 수 있다.
그러나, 이러한 장점이 있지만, 맨 처음에 페이지를 가져 온 후에 JS가 실행되어 API에 컨텐츠를 가지러 갔다가 돌아오는 사이에 어느정도의 시간이 걸린다. 이것이 SPA의 난점이다. 이 문제를 해소하는 것이 다음에 소개할 SSR이 된다.
SSR
SSR을 간단히 얘기하자면, 페이지 이동 때마다 서버에 리퀘스트가 발생해, 그대로 서버쪽에서 API와ㅣ 연계하여 렌더링하여 생성된 HTML을 브라우저에 전달하는 아키텍처이다.
서버쪽에서 렌더링하는 것이 주요한 특징이므로, Server Side Rendering(SSR)이라고 할 수 있다.
SPA에서는 브라우저 쪽에서 실행한 렌더링 처리를 서버쪽에서 하므로, 서버 사이드를 JavaScript로 표현할 수 있는 Node.js를 설치한 서버의 준비가 필요하다.
이와 관련해서 조사하면서 든 생각은 이것은 Rails등의 역할을 Node.js가 대신한 것이고, MPA와 크게 다르지 않은 것 같은데, 왜 새로운 아키텍처라고 하는 것일까라는 것이다.
그래서 더욱 알아 본 결과, 일반적으로 이용되고 있는 MPA에서는 말할 것도 없이 행해지는 것이므로, SSR이라고 하는 키워드는 SPA를 구축할 때의 옵션 기능을 의미하는 듯 하다. 즉, SSR은 그 차제로 이용되는 것보다는 SPA와 함께 사용되는 아키텍처인 것이다.
이미지로 나타낸다면 다음과 같다.
제일 많이 거론되는 것은 렌더링을 서버쪽에서 하므로, 보통의 SPA에 비교해서 처음에 읽어들일 때에 시간이 걸리지 않는다는 것이다. UX가 향상되는 것이다.
또한 성가진 렌더링 처리를 서버쪽에서 하므로, 브라우저의 부담을 줄여, 브라우저의 스펙이 높지 않은 기기에서도 안정된 표시 속도를 유지할 수 있다.
SSG
한편으로 SSR과 자주 비교되는 것은 SSG이다. SSG는 빌드시에 서버쪽에서, API부터의 데이터 획득과 그에 따른 HTML의 구축을 끝내 놓고, 유저에게 리퀘스트를 받았을 때에 사전에 준비해둔 HTML을 건내는 아키텍처이다.
빌드때 마다의 정적 페이지(사이트)를 생성하므로, Static Stie Generation(SSG)이다. 그림으로 나타내면 다음과 같다.
SSG의 최대 장점은 맨 처음의 빌드를 훨씬 전에 하기 때문에, 유저가 "페이지를 보고싶어"라는 요청을 했을 때 부터 꽤 빠른 속도로 페이지를 표시해준다는 것이다.
그러나 SSR과 비교하면, 최신의 데이터가 항시 화면에 반영되어 있다는 보장이 없다는 점이다. 그러므로 블로그와 같인 정보 갱신의 빈도가 적은 서비스에 적합하다.
참고자료
'IT > WEB' 카테고리의 다른 글
| 클린 아키텍처1 (0) | 2023.02.13 |
|---|---|
| 좋지 않은 Repository 패턴(안티패턴) (0) | 2023.02.02 |
| MVC 모델 (0) | 2023.01.22 |
| Node.js를 사용하는 이유 (3) | 2022.10.06 |
| REST API란? (0) | 2022.10.04 |