MPA
MPA는 Multiple Page Application의 약자로, 말그대로 여러개의 페이지로 구성된 애플리케이션입니다.
MPA는 사용자가 애플리케이션 내에서 페이지를 이동할 때마다 페이지의 전체 컨텐츠와 기능을 매번 서버에서 받아와서 매번 전체 페이지를 다시 렌더링해주는 웹개발 방식입니다.
MPA는 전통적인 웹 어플리케이션 구조로, 웹 초기 시절에는 대부분의 웹사이트가 MPA구조로 개발이 되었습니다. MPA방식으로 개발을 하게 되면, 구조가 간단하고 각 페이지가 독립적이기 때문에 개발자가 이해하고 유지보수하는데 큰 비용이 들지 않습니다.
SPA
SPA는 Single Page Application의 약자로, 하나의 페이지로 구성되어 있어 MPA와는 반대되는 개념입니다.
하나의 페이지에서 웹 어플리케이션의 모든 콘텐츠와 기능을 로드하는 방식으로 사용자가 어플리케이션 내에서 페이지를 이동하더라도 전체페이지를 다시 로드하지 않고 필요한 데이터와 컴포넌트만 비동기적으로 불러오게됩니다.
주로 Angular, React, Vue.js와 같은 자바스크립트 프레임워크를 사용한 비교적인 현대적인 웹어플리케이션 개발방식입니다.
CSR
SPA는 기본적으로 CSR 방식으로 렌더링을 처리하게 되는데요. CSR은 Client Side Rendering의 약자로, 클라이언트에서 모든 렌더링을 처리하는 방식입니다. 앞서 SPA가 CSR방식을 사용해서 렌더링을 한다고 했는데요, CSR의 동작 방식을 알아보겠습니다.
동작방식
- 사용자가 웹페이지에 접속
- 서버는 해당 웹페이지의 <div id="root"></div> 라는 빈 html과 <script>번들을 클라이언트로 넘겨줌
- 클라이언트에서 React를 실행시키고, renactDOM.render()을 통해 html을 렌더링한 후 <script>번들을 html에 연결
- 웹어플리케이션 완성
장점
클라이언트 쪽의 웹 브라우저에서 렌더링을 하는 CSR 방식에는 장단점이 있습니다. 장점으로는 매번 페이지를 이동할 때마다 서버에 요청을 할 필요가 없으므로, 부드러운 페이지 전환 및 상호작용으로 사용자 경험이 개선됩니다. 그리고 클라이언트에서 렌더링을 하기 때문에 서버는 API요청에 집중할 수 있게 되어 비교적 서버에 부담이 덜합니다.
단점
단점으로는 최초 페이지 로드시 모든 소스를 불러오기 때문에 초기 로딩속도가 비교적 느립니다. 또한 javascript를 사용하여 렌더링 작업을 수행하므로, 오래된 브라우저에서는 호환성 문제가 발생할 수 있습니다. 그리고 마지막으로 컨텐츠가 클라이언트 사이드에서 동적으로 생성되기 때문에, 검색엔진 크롤러가 인덱싱하기 어려워, 검색엔진 최적화가 힘들다는 단점이 있습니다.
SEO (검색엔진최적화)
여기서 검색엔진 최적화란, SEO라고도 불리는데, 구글이나 네이버 같은 검색엔진에 최적화된 요소를 고려하여 구현하는 방식입니다. 검색엔진을 최적화하게 되면, 검색엔진을 통한 키워드 노출 빈도를 높일 수 있어 마케팅방식의 중요한 방식으로 활용됩니다.
SSR
이렇게 CSR이 검색엔진 최적화가 어렵다는 단점을 해결하기 위해 나온것이 바로 SSR 방식인데요.
SSR이란 Server Side Rendering의 약자로, 서버쪽에서 렌더링을 하고 완성된 DOM을 서버로부터 받는 방식입니다. 대표적으로는 React의 프레임워크인 Next.js를 통해 SSR 방식을 사용할 수 있으며, 서버에서 DOM을 받아온다는 관점에서, 앞서말한 MPA도 SSR방식으로 볼 수 있습니다. 여기서는 Next.js로 만든 SSR의 동작방식을 알아보겠습니다.
동작방식
- 사용자가 웹페이지에서 접속
- 요청 수신
- 데이터 페칭
- 컴포넌트 렌더링
- HTML + <script>번들 전송
- 클라이언트사이드 하이드레이션
- 웹어플리케이션 완성
장점
우선 SSR의 등장 이유이기도 한, 검색엔진 최적화에 유리합니다. SSR이 검색엔진 최적화에 좋은 이유는 다음과 같습니다.
우선 서버에서 HTML을 렌더링하면, 검색엔진 크롤러가 페이지의 컨텐츠를 쉽게 파싱하고 이해할 수 있게됩니다. 그리고 사용자 경험을 향상시키는 것 또한 SEO에 유리하다고 간주되는데요. SSR로 서버에서 렌더링된 페이지의 컨텐츠를 빠르게 볼 수 있기 때문에, 빠른 페이지 로딩 시간은 사용자 경험을 향상시키므로, 검색엔진에서 웹사이트 순위에 영향을 미치게 됩니다.
또한 SSR은 완전한 메타 태그 정보를 포함한 완전한 html을 제공하므로, 소셜 미디어 플랫폼에서 웹페이지를 공유할 때 미리보기 및 메타데이터가 올바르게 표시됩니다. 이 또한 사용자 경험을 향상시키므로 검색엔진의 웹사이트 순위에 영향을 미치게 됩니다.
그리고 다른 장점으로는 CSR의 단점이었던 초기 로딩속도와 호환성 문제도 자연스럽게 해결됩니다.
단점
단점으로는 페이지 전환시 매번 서버에서 웹페이지를 생성해야 하므로, 서버의 자원소모가 클 수 있습니다. 때문에 TTFB라고하는, Time To First Byte, 즉 사용자가 첫번째 바이트를 받는데까지 더 오랜 시간이 걸릴 수 있습니다.
그리고 완성된 html을 뿌려주고, 같이 받아온 script를 연결하는 과정에서 시간차이가 발생해, Time To View, 즉, html은 멀쩡히 잘 뿌려졌는데, 사용자와의 인터랙션, Time to interactive를 할 수 없는 시간이 발생하게 되는데, 이 또한 사용자의 경험을 저하시키게 됩니다.
SSG
그리고 CSR,SSR 말고 SSG라는 개념도 있는데요. SSG는 Static Stie Generation의 약자이며, static rendering이라고도 불립니다. SSG는 서버에서 렌더링을 한다는 점에서는 SSR과 유사하지만, 서버에서 요청하면 그 때 렌더링을 시작하는 SSR과 는 달리 SSG는 빌드할 때 미리 다 렌더링을 해서 만들어 논다는 점이 다릅니다.
장점
SSG는 미리 렌더링해논 html 파일을 제공하기 떄문에, 서버에 도달하는 시간이 줄어들고 페이지 로딩 시간이 빨라집니다. 또한 SSR과 마찬가지로 서버에서 렌더링하기 때문에, 검색엔진 최적화에 좋습니다.
단점
하지만 빌드 시 렌더링을 하기 때문에 사이트 규모가 커질수록 빌드시간이 길어질 수 있고, 그때그때 달라지는 데이터에 반응할 수 없기 때문에 데이터가 변경될 때마다 다시 빌드를 해줘야 합니다.
지금까지 MPA와 SPA, 그리고 CSR, SSR, SSG에 대해서 알아봤습니다.
각각이 모두 장단점을 가지고 있기 때문에, 무조건 무엇을 써야한다는 것보다는, 만들고 싶은 서비스가 무엇인지에 따라서 개발방식을 선택해야 합니다.
서비스에 따른 개발방식 선택
CSR
- 웹어플리케이션, 대화형 앱, 실시간 업데이트가 필요한 어플리케이션
- 사용자와의 상호작용이 많은 서비스(ex. 대시보드, 게시판 등)
- 내부에서만 사용하는 사이트이거나 사이트를 노출시킬 필요가 없는 경우
- 초기 로딩 속도보다 사용자 경험에 더 중점을 둔 경우
SSR
- 동적 컨텐츠를 주로 제공하는 어플리케이션
- 검색엔진최적화가 중요한 경우 (ex. 블로그, 뉴스, 컨텐츠 중심의 사이트 등)
- 소셜 미디어 공유 및 미리보기가 중요한 경우 (ex. 상품페이지, 기사 등)
- 초기 페이지 로딩 속도가 빨라야 하는 경우
SSG
- 정적 컨텐츠를 주로 제공하는 어플리케이션
- 사용자와의 상호작용이 적은 경우
- 검색엔진 최적화가 중요한경우 (ex. 블로그, 뉴스, 마케팅페이지 등)
- 높은 트래픽을 다루는 경우 (정적 파일로 서빙하기 떄문에 서버 부하가 낮음)
- CDN을 이용해 전 세계 사용자에게 빠르게 컨텐츠를 제공해야 하는 경우
댓글