SSR vs CSR

SSR과 CSR 개념 정리

SSR(서버사이드 렌더링)

• 사용 시기:

  • SEO(검색 엔진 최적화)가 중요한 경우: 검색 엔진이 페이지 콘텐츠를 빠르게 크롤링해야 할 때 (예: 블로그, 전자상거래 사이트, 신문사)
  • 초기 로딩 속도가 중요한 경우: 서버에서 완성된 HTML을 제공해 첫 페이지 렌더링이 빠름.
  • 자바스크립트 실행 환경이 제한적인 사용자(예: 오래된 브라우저, JS 비활성화).

• 장점: SEO 친화적, 초기 렌더링 빠름, 안정적인 첫 화면 제공.

• 단점: 서버 부하 증가, 클라이언트와 서버 간 동기화 복잡성.

CSR(클라이언트 사이드 렌더링):

• 사용 시기:

  • 인터랙티브한 UI가 필요한 경우: 단일 페이지 애플리케이션(SPA)처럼 동적이고 빠른 상태 변화가 중요한 앱 (예: 대시보드, 소셜 미디어 피드).
  • SEO가 덜 중요한 경우: 내부용 웹 앱, 로그인 후 접근 가능한 서비스.
  • 개발 생산성을 높이고 싶을 때: 프론트엔드 프레임워크(리액트, 뷰)로 빠르게 개발 가능.

• 장점: 클라이언트에서 빠른 상태 전환, 서버 부하 감소, 개발 경험 우수.

• 단점: 초기 로딩 느릴 수 있음, SEO 최적화 추가 작업 필요.

하이브리드 방식:

• 현대 웹 앱은 Next.js(리액트), Nuxt.js(뷰) 같은 프레임워크로 SSR과 CSR을 혼합 사용.
• 예: 첫 페이지는 SSR로 빠르게 제공하고, 이후 상호작용은 CSR로 처리.

기업 기준 분류해서 생태계 파악해보기

대기업/테크 기업 (예: 네이버, 카카오, 배달의민족)

• SSR + CSR 혼합: SEO가 중요한 페이지(홈, 상품 목록)는 SSR, 사용자 대시보드나 내부 앱은 CSR.
  프레임워크: Next.js, Nuxt.js, Remix 등으로 SSR과 CSR 조합.
• 팀 분리: 프론트엔드(FE)와 백엔드(BE) 개발자가 명확히 나뉘며, FE가 렌더링 방식 결정에 관여.

중소기업/스타트업

• 리소스 제약으로 CSR 중심(리액트, 뷰) 사용 빈도 높음. -> 개발 속도면에서 차이도 존재할 것이고, CSR은 렌더링이 클라이언트(사용자 브라우저)에서 이루어지기 때문에 서버 부하가 적음. 정적 파일만 호스팅하면 되므로, Netlify, Vercel, 또는 AWS S3 같은 저렴한 정적 호스팅 서비스를 사용할 수 있음.
• 필요 시 Next.js로 SSR 도입, 하지만 초기엔 SPA로 빠르게 개발.

레거시 시스템 (은행, 공공기관)

• JSP, Thymeleaf 같은 템플릿 엔진으로 SSR 위주.
• CSR 도입은 점진적으로 (예: 리액트로 일부 컴포넌트만 전환).

JSP 사용하는 곳은 서버 개발자가 JSP까지 다 작성할까?

상황에 따라 다르지만 레거시 시스템에서는 서버 개발자가 JSP 작성하고
프론트엔드 개발자가 돕는다면 CSS랑 JS쪽 돕고 서버 개발자는 JSP로 데이터 바인딩만 처리.