적정기술 딜레마
한줄요약 : 아무리 최신기술, 사람들이 많이 쓴다고 해서 좋은 기술이 아니라, 회사의 서비스 요구사항에 적합한 기술을 사용해야 하며, 이에 대한 선택은 당신의 가치관에 따라 달라짐요

이 글을 읽다가

SPA, MPA, CSR, SSR, SEP, 캐싱(Cache)이게 다 뭔 소리야?

라는 생각이 들었다.

React.js를 콕 찍어 맛만 봐왔기에 웹 개념을 제대로 모르는 나 자신을 위해 여러 블로그들을 참고하여 정리해놓는다. 그동안 난 이런 개념을 모르고 그냥 이것저것 조립만 하던 사람이었구나.

혹시 틀리면 알려주세요 살려주세요.

순서는 SEO → MPA → SPA → SSR → CSR → 언제 어떤 방식을 사용하는 것이 좋을 지 순으로 정리할 것이다.

SEO(Search Engine Optimization)

• 홈페이지 혹은 콘텐츠를 검색 결과의 상단에 위치시키는 작업

• 검색 엔진은 크롤링(Crawling, 웹 크롤러로 웹사이트 관련 데이터를 가져오는 과정)과 인덱싱(Indexing, 크롤링을 통해 얻은 정보를 검색 색인에 저장하는 과정)을 통해 정보를 카테고리화한다.

MPA(Multi Page Application)

• 여러 페이지로 구성된 웹 어플리케이션이다.

• MPA는 ❗SSR(Server Side Application) 방식으로 렌더링한다.

• 새로운 페이지를 요청할 때마다 서버에서 렌더링된 정적 리소스(HTML, CSS, JavaScript)가 다운로드된다.

• [클라이언트 관점] : 사용자의 클릭과 같이 인터렉션이 발생할 때마다 서버로부터 새로운 html을 받아와서 해당 링크로 이동하여 페이지 전체를 새로 렌더링하는 전통적인 웹 페이지 구성 방식이다.
  

MPA장점

1. SEO 관점에서 유리하다.
   → MPA는 완성된 형태의 HTML 파일을 서버로부터 전달받는다. 따라서 검색엔진이 페이지를 크롤링하기에 적합하다.

2. 첫 로딩 매우 짧다.
   → 서버에서 이미 렌더링해서 가져오기 때문이다.
   그러나 클라이언트가 JS파일을 모두 다운로드하고 적용하기 전까지는 각각의 기능은 동작하지 않는다.

MPA단점

1. (UX) 새로운 페이지를 이동할 때마다 렌더링
   → 매 페이지마다 리로딩 발생, 깜빡인다

2. (성능) 페이지 이동시 불필요한 템플릿도 중복해서 로딩

3. 서버 렌더링에 따른 부하

4. (생산성) 모바일 앱 개발시 추가적인 백엔드 작업 필요, 개발 복잡해짐

SPA(Single Page Application)

• 하나의 페이지로 구성된 웹 어플리케이션이다.

• SPA는 ❗CSR(Client Side Rendering) 방식으로 렌더링한다.

• 브라우저에 최초에 한 번 페이지 리소스(HTML, CSS, JavaScript)를 로딩하고, 이후부터는 특정 부분만 Ajax를 통해 서버와 통신하여 데이터를 바인딩하는 방식이다.

• [클라이언트 관점] : 최초 페이지를 로딩한 시점부터는 페이지 리로딩 없이 필요한 부분만 서버로부터 받아서 화면을 갱신, 자연스러운 페이지 이동 및 사용자 경험 제공 가능
  

SPA 장점

1. (UX) 전체 페이지 업데이트X, 깜빡거림 없다.

2. (성능) 필요한 리소스만 부분적으로 로딩
   → SPA의 Application은 서버에게 정적리소스를 한 번만 요청, 받은 데이터는 전부 저장해놓는다.(Cache)

캐시(Cache)란 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. 캐시에 데이터를 미리 복사해 놓으면 계산이나 별도의 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있다.

3. (성능) 서버의 템플릿 연산을 클라이언트로 분산

4. (생산성) 컴포넌트별 개발 용이

5. (생산성) 모바일 앱 개발을 염두에 둔다면 동일한 API를 사용하도록 설계 가능

SPA 단점

1. JavaScript 파일을 번들링해서 한 번에 받기 때문에 초기 구동 속도가 느리다.
   → Webpack의 code splitting으로 해결 가능

2. 검색엔진최적화(SEO)가 어려움
   → SSR로 해결 가능

3. 보안 이슈
   SSR에서는 사용자에 대한 정보를 서버측에서 세션으로 관리를 하지만 CSR방식에서는 클라이언트측의 쿠키 말고는 사용자에 대한 정보를 저장할 공간이 마땅치 않다.
   → 프론트엔드에 비즈니스 로직 최소화

SSR(Server Side Rendering)

• 말 그대로 서버에서 렌더링을 작업한다.

• 서버에서 메인페이지를 요청하면, 모든 템플린은 서버 연산을 통해 렌더링하고 완성된 html을 응답하는 형태

• 서버 사이드 렌더링의 장점은 SEO, 전통적인 MPA의 경우 브라우저에서 JavaScript 코드가 동작하기 전에도 완성된 형태의 템플릿(HTML에 데이터가 삽입된 상태)을 서버로부터 전달 받는데, 이 때문에 JavaScript를 구동하지 않는 검색 엔진이 페이지를 크롤링하기 매우 적합.

• JS파일을 전부 다운로드 받기 전까지는 제대로 동작하지 않지만 사용자 측명에서는 서버에서 view를 렌더링하여 가져오기 때문에 초기 구동 속도가 빠르다.

CSR(Client Side Rendering)

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

• 동적으로 만들어지는 곳이 Client side인 형태

• 웹은 전부 HTTP 통신인데, 프론트에서 요청을 하면 서버(백엔드)의 응답을 받아 프론트로 넘겨주는데, JSON의 형태로 받는 게 보통이지만, 어떠한 형식의 파일을 받을 수 있다.

• 먼저 static한 파일들을 받아오고, 데이터가 없는 빈 html을 받아온 뒤, 이후에 요청해서 받아오는 방식

• 페이지를 읽어들이는 시간, JavaScript를 읽어들이는 시간, 그리고 화면을 그리는 시간까지 모두 마쳐야 콘텐츠가 사용자에게 보여지고 초기 구동 속도가 느림

SPA를 SSR 방식으로 렌더링

• React는 Next.js, Vue는 Nuxt.js, Angular는 Angular 유니버셜

• SSR 기반의 웹 애플리케이션은 컴포넌트 단위로 개발할 수 있게 해주는 프레임워크를 사용한다.

• 정통 SSR(MPA)방식의 장점을 완벽하게 커버하기란 불가능, SSR(MPA)방식에서의 SPA의 장점 중 일부라도 누려보기 위해 나온 프레임 워크들을 사용

렌더링 방식 선택기준

그렇다면, 어떤 방식을 쓰는게 좋을까?
→ 서비스, 프로젝트, 콘텐츠의 성격에 따라 달라진다.

SSR(MPA) 선택

1. 상위 노출이 필요함

2. 누구에게나 동일한 내용을 노출해야함

3. 페이지마다 데이터가 자주 바뀜

CSR(SPA) 선택

1. 개인정보 데이터를 기준으로 구성됨

2. 보다 나은 사용자 경험을 제공하고 싶음

3. 상위 노출보다 고객의 데이터 보호가 더 중요함.

참고 블로그
아하 프론트 개발기
SSR과 CSR
Nuxt.js란