SPA, MPA, CSR, SSR

kimhanna·2020년 12월 23일
1

SPA, MPA, CSR, SSR

예전에도 배운적이 있지만, 다시한번 개념을 확실하게 정리하기 위해 글을 써보기로했다. 다른사람에게 촤르르르르! 설명할 수 있게!!

📌About

CSR , SSR 그리고 SPA는 현대 웹개발에서 반드시 집고 넘어가야 할 개념입니다. SPA는 3세대 웹이 등장하면서 기존에 웹이 제공해 주지 못했던 풍부한 UX를 구현할 수 있게 해준 중요한 키워드 입니다. 이 SPA는 CSR과 SSR 이 두가 방법으로 지원할 수 있습니다.

Web System Architecture History

1. 1세대 웹 - 전통적인 Web System Architecture. 정적 웹.

- 웹 서버가 HTML 페이지 전체를 클라이언트(ex. Web browser)에게 전송 - 초창기 웹사이트/서비스에 적합했던 시스템 - 초창기 웹사이트는 단순한 정보 제공 위주였다. 특별히 기능이 많지 않으며, 무엇보다 User Interaction 이 많이 요구되지 않았다.
  • 1세대 웹이 정적인 이유? HTML, CSS 자체가 정적
    • Hyper Text : 링크로 연결된 문서
    • Markup Language : “이렇게 보여줘라” 에 대한 지시
      - HTML : 웹페이지의 내용을 브라우저에게 어떻게 렌더링(rendering) 해주라고 마크업 해주는 것
  • 어떻게 보여지는가에 대한 것이기 때문에 로직(동적)이 없다. 정적.

2. 2세대 웹 서비스 - User Interaction 증가. 동적 웹 (JavaScript).

  • 웹서비스들이 점점 발전함에 따라 단순한 정적 페이지가 아닌 다이나믹한 요소들이 요구됨.
  • 웹 기반의 언어인 자바스크립트가 출현. 자바스크립트의 역할이 커지기 시작함.
  • 참고) 그 이전의 언어들은 사용할 수 없었을까? 왜 자바스크립트가 필요했을까?
    : 그 이전의 언어는 브라우저에서 동작을 안 함.
  • 이렇게 2세대 웹 서비스가 출현
  • Web server에서 전체 HTML 페이지 뿐만이 아니라 JavaScript를 통해 서버와 필요한 데이터만 주고 받음으로 dynamic한 user interaction을 구현하게 됨.
  • 그러나 아직 JavaScript 는 일부분에서만 사용되었고, 또한 현재 통용되는 API 의 개념이 아직은 널리 사용 되지 않음 → 동일한 서버에서 HTML, Javascript(프론트 영역) 데이터(백엔드 영역) 둘 다 전송.
    • ex. Django Template

3. 3세대 웹 서비스 - SPA. 구별되기 시작하는 Frontend / Backend.

  • 동적인 기능이 주가 되버림. → 자바스크립트가 주가 되고 그 안에 일부 HTML, CSS 가 포함.
  • 이게 바로 SPA(Single Page Application) - 하나의 파일로 전체 사이트를 구현
  • 이름 그대로, 단일의 html 페이지에서 전체 웹 사이트/서비스를 구현.
  • 기존의 방식대로 서버가 페이지 구성에 필요한 모든 요소(HTML, JavaScript, Data)를 매번 전송하는 것이 아니라, 파일은 처음 한 번만 송수신. 그 뒤로는 실시간 데이터만 주고 받음.
    - 제일 처음 전송된 단일 HTML 페이지에 포함되어 있는 JavaScript 에서 필요한 데이터를 API 서버로부터 호출하여 필요한 화면을 dynamic 하게 새롭게 구성해주는 방식.
  • HTML 태그 자체를 자바스크립트가 동적으로 생성
  • “명확히 두 개로 나눌 수 있겠다!” → 프론트엔드와 백엔드가 나뉘게 되는 기점.
  • 즉 HTML/JavaScript 부분과 데이터 부분이 구조적으로 분리 되기 시작
  • → Frontend 개발과 Backend 개발이 독립적으로 분리 (프론트 - UI UX / 백엔드 - Data)
  • 명확히 나뉘어진 두 개의 시스템으로 웹이 동작하게됨.
  • 기술 스택도 각자에 맞는 스택을 시용하기 시작함. (ex. React 의 출현!)
  • 프론트엔드가 개발의 혁신이 빠른 이유도 이 분야 자체의 역사가 짧음.
  • Frontend 와 Backend가 구조적으로 분리가 되면서, Frontend 서버와 Backend API 서버도 분리가 되며 그에 따라 Frontend 개발과 Backend 개발 업무가 분리가 되는 구조로 발전된다.

<html파일 수>

MPA이란?(Multi Page Application)

  • 일견 당연해보이기도 한다

    ⇒ 우리는 이미 여러 페이지를 넘나들며 사용하는 것처럼 보이기 때문

  • 정적 웹사이트로 구성된 html 파일이 여러 개.

  • 정적 웹사이트?

    • 한번 만들어 놓으면 거의 안 바뀌는 페이지
    • html 자체가 만들어져서 날아오고 그걸 그대로 브라우저에 보여주는 방식
  • 페이지 이동 시 화면 깜빡임 O

SPA이란?(Single Page Application)

  • html 파일이 한 개.
  • npm run build ⇒ html 파일 하나 생김 (ex. AWS 배포할 때)
  • 페이지를 이동하려고 하면 자바스크립트 내의 특정 함수를 타서 <div id="root" /> 의 내용을 싹 교체하는 것.
  • 서버로부터 html 자체를 받아서 페이지를 바꾸는게 아니다.
  • 페이지 이동 시 화면 깜빡임 X
  • 즉, 우리가 지금 얘기해볼 SSR은 SSR for SPA다.
    • 또한, SPA(결과물) = CSR, SSR (렌더링 방법)로 나누어 이해하면 좋다.

CSR이란?(Clinet Side Rendering)

Clinet Side Rendering의 약자로써 최초에 1번 서버에서 전체 페이지를 로딩하여 보여주고 이후에는 사용자의 요청이 올 때 마다, 리소스를 서버에서 제공한 후 클라이언트가 해석하고 렌더링을 하는 방식입니다.

  • 웹 페이지의 렌더링이 클라이언트(브라우저) 측에서 일어나는 것을 의미.
  • 브라우저는 최초 요청에서 html, js, css 확장자의 파일을 차례로 다운로드.
  • 최초로 불러온 html의 내용은 비어있음. (html, body 태그만 존재)
  • js 파일의 다운로드가 완료된 다음, 해당 js 파일이 dom을 빈 html 위에 그리기 시작.
  • 백엔드 호출을 최소화 할 수 있음
    • 최초 호출 때만 html, js, css를 요청
    • 이후에는 화면에서 변화가 일어나야 하는 만큼의 데이터만 요청 (ex. JSON)
  • 라우팅(새로운 페이지로 이동)을 하더라도 html 자체가 바뀌는 것이 아니라 JavaScript 차원에서 새로운 화면을 그려내는 것!

1. Create React App (CRA) ← Only CSR

  • 아무런 초기 설정 없이도 CRA를 통해 React 기반의 SPA 사이트를 구현할 수 있게 됨.
    • (과장 조금 보태서) 터미널에 npx create-react-app my-app, npm run build 명령어 만으로 사이트 하나를 만드는 것이 가능.
    • webpack, babel 등 복잡한 세팅을 거치지 않아 React 기반 웹 프로젝트 확산에 큰 기여.
  • 그런데 얼마 간 시간이 지나면서 조금씩 이상한 점이 드러나기 시작.
    • 🤔: "우리 사이트가 검색에 너무 안 걸리는걸?"
    • 원인) CRA로 build한 프로젝트는 Only CSR(Client Side Render)로 실행되기 때문.

SSR이란?(Server Side Rendering)

Server Side Rendering의 약자로써 단어 그대로!! 서버에서 렌더링을 작업합니다. 기존에 존재하던 방식으로 사용자가 웹페이지에 접근할 때, 서버에 페이지에 대한 요청을 하며 서버에서는 html,view와 같은 리소스들을 어떻게 보여질지 해석하고 렌더링하여 사용자에게 반환합니다.

웹에서 제공하는 정보량이 많아지고 데스크탑보다 성능이 다소 떨어지는 스마트폰의 웹에 대한 요구가 커지면서 새로운 기법이 탄생했습니다.

CSR과 SSR의 차이점

1. 초기 렌더링 속도

:CSR의 경우, 사용자의 행동에 따라 필요한 부분만 다시 읽어들이기 때문에 서버 측에서 렌더링하여 전체 페이지를 다시 읽어들이는 것보다 빠른 반응속도를 기대할 수 있습니다.클라이언트 측에서 렌더링을 하게 되면 서버 사이드 렌더링이 따로 필요하지 않기 때문에 일관성 있는 코드를 작성할 수 있습니다.
CSR은 페이지를 읽어들이는 시간, 자바스크립트를 읽어들이는 시간, 그리고 자바스크립트가 화면을 그리는 시간까지 모두 마쳐야 콘텐츠가 사용자에게 보여집니다. 여기서 웹서버에서 콘텐츠 데이터라도 가져와야 한다면 그 시간은 더욱 길어집니다. 즉,
초기 구동속도가 느려집니다. 초기 구동속도를 제외하고는 빠른 반응을 보여줍니다.**

이와 반대로 SSR의 경우 서버에서 view를 렌더링하여 가져오기 때문에 view를 보기까지 초기 구동속도가 빠릅니다. 물론 JS파일을 전부 다운로드 받기 전까지는 제대로 동작하지 않지만 사용자 측면에서는 빠르다 느낄 수 있습니다.

2.SEO

SEO(Search Engine Optimization(최적화))
대부분의 웹 크롤러, 봇들이 자바스크립트 파일을 실행시키지 못하고 HTML에서만 컨텐츠를 수집합니다. 때문에 CSR 방식으로 개발된 페이지를 빈 페이지로 인식하게 됩니다. 검색엔진에 제대로 노출이 되지 않는 다면 웹페이지의 유입이 줄어든다.

그렇다면....그 웹사이트는.....

  • 🤔 : "SPA의 장점을 살리면서 SEO도 같이 챙길 수는 없을까?"

    ⇒ SSR (Server Side Rendering)

SSR은 view를 서버에서 전부 렌더링하여 내려주므로 HTML에 모든 컨텐츠가 저장되어 있기 때문에 SEO 적용에 큰 문제가 없습니다.

3.보안

기존에 SSR에서는 사용자에 대한 정보를 서버 측에서 세션으로 관리를 하지만 CSR방식은 클라이언트 측의 쿠키말고는 사용자에 대한 정보를 저장할 공간이 없습니다.

CSR + SSR? ⇒ Next.js (like CRA)

  • 그렇다면 SSR과 CSR을 섞어 쓸 수는 없나요?
  • 사용할 수 있다! ⇒ 생산성을 위해 Next.js가 주로 채택됨
  • SSR의 CRA, 간단히 구성 가능
  • 원티드, 토스, 배민, 카카오커머스 등 사용 중

Next.js는 간단하게 말하면 리액트에서 SSR을 쉽게 적용할 수 있게 해주는 라이브러리이다.
첫 번째, 사용자가 처음 페이지를 접속을 요청 했을때 Next.js 서버는 사용자에게 랜더링될 HTML을 응답 값으로 보내줍니다 ( SSR 방식 ).
두 번째, 그 후 브라우저는 추가적인 자바스크립트 번들을 다운로드 받아 실행합니다.
세 번째, 사용자가 해당 페이지에서 다른 페이지로 이동할때는 Next.js에 서버가 아닌 브라우저에서 처리하여 이동하게 합니다. ( CSR 방식 )

>:: 원리 & 구조

  • SSR은 다음과 같은 요소로 구성된다
    • node.js로 구성된 FE 서버
    • pyhton, django로 되어 있는 BE 서버
  • 다음과 같은 과정을 거쳐 SSR이 진행된다
    1. 유저가 브라우저에 /index를 입력.
    2. 미리 실행되고 있는 FE 서버가 요청을 받고 서버사이드 렌더링.
    3. 만들어진 html 을 브라우저에게 보냄.
    4. 브라우저가 응답받은 html 을 그림.
    5. html 에 기능을 부여할 main.js파일을 다운로드 받음. (hydration)
    6. 다운로드가 완료된 이후, go to second 링크를 클릭.
    7. /second로 라우팅하고 second 페이지 코드를 생성.

용어


hydration

  • 서버에서 전송한 정적 문서를 데이터 변경에 반응할 수 있는 동적 형태로 변환하는 클라이언트 측 프로세스를 말한다.
  • render와 동일하지만, dom은 이미 그려져 있는 상태이기 때문에 event listener만 부착하는 식으로 작동.

정리
웹서비스들이 점점 발전하고 User Interaction이 증가함에 따라 단순한 정적 페이지가 아닌 다이나믹한 user interaction을 구현한 동적인 웹으로 발전했다.이에 따라 MPA(Multi Page Application)에서 SPA(Single Page Application)으로 발전되고 SPA의 CSR, SSR 렌더링 방법이 나오게 되었다. CSR은 (Client Side Rendering) 최초에 1번 서버에서 전체페이지를 로딩하여 보여주고 이후에는 사용자의 요청이 오면 클라이언트가 해석하고 렌더링 하는 방식이다. 아무런 초기 설정 없이도 CRA(라이브러리)를 통해 React 기반의 SPA 사이트를 구현할 수 있게 되었다.하지만 CSR 방식으로 개발된 페이지를 빈 페이지로 인식하게되어 검색엔진에 제대로 노출되지 않는 SEO(Search Engine Optimizaion)문제가 발생하게 되었다. SPA의 장점을 살리면서 SEO도 같이 챙길 수는 없을까?"라는 고민끝에 SSR이 나왔다. SSR은 (Server Side Rendering)은 서버에서 렌더링을 작업하는 것을 말한다. SSR은 view를 서버에서 전부 렌더링 하여 내려주므로 HTML에 모든 컨텐츠가 저장되어 있기 때문에 SEO 적용에 큰 문제 가 없다. CSR과 SSR의 장점과 생산성을 위해 사용할 수 있는 Next.js(라이브러리/:프론트 서버에서 백엔드 서버에게 직접 요청 가능함)있는데 SSR의 CRA 으로 간단히 구성이 가능하다.

profile
한 줄의 코드가 유저의 일상을 변화시키는 매력에 반해 프론트엔드 개발자가 되었습니다. 늘 배움의 자세로 유저를 위한 기술을 구현하겠습니다. 저는 함께 이뤄내는 결과의 가치를 믿습니다.

0개의 댓글