[전문가를 위한 리액트] 6. 서버 사이드 리액트 - 클라이언트 사이드 렌더링의 한계

클라이언트 사이드 렌더링(CSR)의 한계

CSR은 HTML, CSS, JS 등의 최소 리소스만 서버에서 받아오고, 실제 콘텐츠는 브라우저가 자바스크립트로 렌더링하는 방식으로 HTML 파싱부터 JS를 읽는 것까지 모두 수행합니다.

1. 브라우저가 HTML 문서를 서버에게 요청합니다.
2. 서버는 빈 HTML 뼈대와 JavaScript 파일 링크를 보내줍니다.
3. 브라우저가 JavaScript 파일을 다운로드하고 실행합니다. 이때 React 앱이 초기화되며 React는 가상DOM트리를 만들어 실제 브라우저의 DOM으로 변환해서 삽입합니다.
4. CSS 파일을 만나면 파싱하여 CSSOM을 생성합니다.
5. DOM과 CSSOM을 합쳐 렌더트리를 만듭니다.
6. 렌더트리를 바탕으로 화면에 어떻게 배치할 지 결정하는 레이아웃과정을 진행합니다.
7. 마지막으로 픽셀단위로 화면에 페인팅합니다.

 

이러한 CSR 접근 방식은 몇 가지 한계가 나타나기 시작했습니다.

1.1 검색 엔진 최적화(SEO)의 한계

CSR에서의 검색 엔진 최적화의 한계를 설명하기에 앞서, 검색 엔진 최적화(SEO)의 기본 개념부터 살펴보겠습니다.

 

1. 검색 엔진 최적화(SEO, Search Engine Optimization)란?

웹사이트가 검색 결과 상위에 노출되도록 콘텐츠와 구조를 조정하는 작업입니다. 이를 통해 사용자의 검색어에 관련된 정보를 더 잘 노출시키고, 사이트 방문을 유도할 수 있습니다. 

 

2. 검색 엔진의 작동 방식

1. 크롤링 - 검색 엔진의 크롤러(bot)가 웹페이지를 방문하여 HTML을 수집합니다.

2. 인덱싱 - 수집한 HTML 콘텐츠를 분석하여 색인(index)에 등록합니다.

3. 랭킹 - 사용자의 검색어와 관련된 콘텐츠를 찾아, 알고리즘을 통해 순위로 정렬해 결과를 노출합니다.

 

3. CSR 방식의 한계

CSR은 클라이언트 측 브라우저에서 자바스크립트를 통해 콘텐츠를 렌더링하는 방식입니다. 이 경우 검색 엔진 크롤러가 자바스크립트를 실행하지 않으면 콘텐츠를 제대로 인식하지 못하는 문제가 생깁니다.

 

3.1 문제점

- 자바스크립트를 실행하지 않는 일부 검색 엔진은 콘텐츠를 아예 인식하지 못합니다.

- 자바스크립트를 실행하는 크롤러의 경우에도 크롤링 시점에 자바스크립트 실행이 완료되지 않으면 빈 HTML로 인식되어 콘텐츠 누락 가능성이 있습니다.

- 특정 웹사이트나 애플리케이션이 크롤링 허용 범위나 로봇 설정 등에 의해 콘텐츠가 수집되지 않기도 합니다.

 

4. 실험 및 확인된 사실

2015년부터 Google과 Bing 등 주요 검색 엔진은 자바스크립트를 해석하고 CSR 콘텐츠 일부 렌더링 할 수 있도록 발전해왔습니다. 실제로 다양한 구현 방식을 통해 자바스크립트를 실행하고 동적으로 생성된 DOM까지 읽어내어 콘텐츠를 색인할 수 있음이 확인되었습니다.

 

하지만 여전히 서버 기반 애플리케이션이 아닌 CSR만으로 구성된 사이트에서는 검색 엔진의 지원이 완벽하지 않거나, 렌더링 타이밍의 오차로 인해 제대로 색인되지 않을 가능성이 존재합니다.

1.2 성능의 한계

1. 성능 문제를 겪는 경우

CSR은 페이지를 렌더링하기 위해 사용자의 브라우저에서 자바스크립트를 다운로드하고 실행해야 합니다. 이로 인해 다음과 같은 성능 문제가 발생할 수 있습니다.

 

1) 느린 네트워크 환경에서 취약

   - 자바스크립트 파일이 크고, 다운로드/실행까지 시간이 오래 걸림

2) 저성능 기기에서 느린 처리 속도

   - CPU가 약한 모바일이나 저가형 디바이스에서 실행 속도가 느림

3) 렌더링 지연

   - 사용자에게 콘텐츠가 보이기까지 시간이 길어짐 (TTI 증가)

4) 사용자 경험 저하

   - 초기 로딩이 느려 페이지 이탈률 증가

   - SEO에도 부정적 영향 (검색 엔진은 콘텐츠가 늦게 렌더링되면 인식하지 못함)

 

중요한 성능 지표

- First Contentful Paint(FCP) : 첫 콘텐츠가 브라우저에 표시되는 시간

CSR에서는 두 지표가 느리게 나타날 가능성이 높습니다.

- Time To Interactive(TTI) : 사용자가 페이지와 상호작용 할 수 있게 되는 시점까지 걸리는 시간으로, 페이지가 처음 로드되기 시작한 순간부터 사용자와 완전히 상호작용할 수 있는 상태가 될 때까지의 시간

 

• HTML + CSS + JS 로딩
• 초기 화면 콘텐츠가 브라우저에 그려지는 시점 (First Paint, First Contentful Paint)
• 필요한 자바스크립트가 모두 실행되어 사용자가 클릭, 스크롤, 입력 등 모든 상호작용에 지연 없이 반응할 수 있는 상태가 되는 시점

 

 

페이지가 보이는 시점(FCP)과 사용할 수 있는 시점(TTI) 사이에 격차가 클수록 사용자 경험은 나빠집니다.

 

2. SSR vs CSR : 네트워크 폭포 효과

 

CSR 방식의 네트워크 폭포 문제

CSR의 경우, 페이지 로딩 순서는 다음과 같습니다.

HTML 로딩 (빈 페이지)
   -> 자바스크립트 로딩
      -> 초기 UI 렌더링
         -> 데이터 가져오기(API 호출)
            -> UI 업데이트

위와 같은 구조는 모든 작업이 순차적으로 실행되기 때문에, "네트워크 폭포(Network Waterfall)"현상이 발생합니다. 각 단계가 다음 단계로 이어지기 전까지 완료되어야하므로 전체 로딩 시간이 길어지고 성능이 저하됩니다.

*네트워크 폭포란? 컴포넌트가 순차적으로 데이터를 페칭하는 과정에서 각각의 데이터 요청이 완료될 때까지 기다린 후에야 다음 데이터 요청을 시작하는 상황

 

SSR의 장점과 흐름

HTML 로딩(전체 UI, 서버에서 가져온 데이터 포함)

- 초기 HTML에 콘텐츠가 포함되어 있어 SEO 최적화에 유리합니다.

- 사용자는 즉시 콘텐츠를 볼 수 있어 TTI/FCP 모두 빠릅니다.

- 네트워크 폭포 없이, 브라우저는 첫 요청에서 모든 것을 받아볼 수 있습니다.

1.3 보안의 한계

CSR은 민감한 데이터를 처리할 때 보안이 문제될 수 있습니다. 특히 CSRF같은 공격에 취약할 수 있습니다.

 

1. CSRF란 무엇인가?

크로스 사이트 요청 위조(CSFR, cross-site request forgery)는 사용자가 로그인된 상태라는 점을 악용해, 사용자가 원하지 않은 요청을 서버에 대신 보내게 만드는 공격입니다.

"이벤트 당첨! 여기서 확인하세요 👉 http://evil.com"

예를 들어, 어떤 웹사이트에 로그인해 있는 상태에서 위와 같은 메세지를 클릭하고 저 악성 웹사이트에 접속하면, 그 악성 사이트가 로그인한 상태를 이용해서 서버에 요청을 보내는 것입니다. 

 

그래서 사용자가 금융 사이트에 로그인 중인데, 다른 악성 사이트를 방문하면 자동으로 출금 요청이 전송될 수 있습니다.

 

2. CSRF 공격이 가능한 이유

브라우저가 요청을 보낼 때 쿠키를 자동으로 같이 보내기 때문에

- 사용자가 어떤 사이트에 로그인하면, 서버는 사용자의 브라우저에 세션 쿠키를 저장합니다. 브라우저는 해당 사이트에 요청할 때마다 저 세션 쿠키를 자동으로 같이 보냅니다. (서버는 해당 세션 쿠키를 보고 로그인한 상태라고 인지합니다)

- 이 동작은 사이트가 다르더라도 무조건 수행되게 되는데요, CSFR 방어를 하지 않는 서버는 요청이 어디에서 왔는지 확인하지 않고 처리하기 때문에 악성 사이트에서 보내는 요청도 수행합니다.

 

3. CSR이 CSRF에 취약한 이유

CSR 애플리케이션은 서버에 API 요청을 보낼 때 쿠키를 자동 포함시켜 전송합니다. 이때 CSRF가 자동으로 쿠키를 전송하는 것을 악용하게 됩니다. 그리고 CSR은 브라우저에서 직접 API 요청을 보내기 때문에 브라우저 보안 정책(자동 쿠키 포함 등)의 영향을 직접적으로 받습니다. 따라서 다른 사이트에서 만들어진 요청이어도, 쿠키가 같이 전송되면 요청이 받아들여질 수 있습니다. 마지막으로, 서버가 CSRF 방어를 구현하지 않았을 때 CSRF에 취약할 수 있습니다. 서버 측에서 CSRF 방어를 누락하면 공격에 그대로 노출합니다.

---

<책에 나왔던 표현>

서버에 접근할 수 없고 프런트엔드 클라이언트 전용 코드만 있는 팀에서 git push를 통해 마법처럼 어딘가에 배포되는 상황이라면, CSRF 위험 가능성이 있습니다.

-> 백엔드 개발이나 API 서버는 외부에서 관리되며, 프론트엔드 코드만 작업할 수 있는 상황

-> 서버에 CSRF 방어 로직을 넣을 수 없음

-> 서버 코드에 접근하지 않고, 프론트 코드만 배포

 

서버에 접근할 수 있고 웹사이트 또는 웹 앱이 클라이언트 전용이라면 CSRF 위협을 상당히 잘 방어할 수 있고 관련된 보안 위험 요소도 사라질 것입니다.

-> 서버에 접근 가능해서 CSRF 방어 로직을 직접 구현할 수 있음

 

서버에 접근할 수 있고 웹사이트나 웹 앱이 클라이언트 전용이라면, 서버 사이드 렌더링을 진지하게 고민할 필요가 있습니다. 서버에도 접근할 수 있고, 서버 사이드 렌더링을 통해 앞서 다룬 SEO 또는 성능과 관련한 이점이 크기 때문입니다.

-> SSR은 SEO와 초기 로딩 속도 측면에서 이점을 주기 때문에 SSR을 고려해보는 것이 좋음

 

---

이렇듯 CSR은 SEO, 성능, 보안 측면에서 한계가 존재합니다. 따라서 서버 사이드 렌더링을 통해 위 한계점을 극복할 수 있습니다.