프론트엔드 분리 #32
Description
현재 MVC 패턴으로 서버에서 페이지를 내려주고 있는데 프론트엔드 서버 분리
REST 아키텍처 표준을 따르기 위함, UI/UX 에 대해서 집중하기 위함
SSR vs CSR(SPA) 비교
| 비교 항목 | SSR (서버 사이드 렌더링) | CSR/SPA (클라이언트 사이드 렌더링) |
|---|---|---|
| SEO | 매우 좋음 - 크롤러가 완성된 HTML을 바로 읽을 수 있음 | 불리함 - JavaScript 실행 필요 (개선되고 있지만) |
| 초기 로딩 속도 | 빠름 - 서버에서 렌더링된 HTML을 바로 표시 | 느림 - JS 다운로드 및 실행 후 렌더링 |
| 페이지 전환 | 느림 - 매번 서버 요청 및 전체 페이지 새로고침 | 빠름 - 필요한 데이터만 가져와 부분 업데이트 |
| 사용자 경험 | 페이지 전환 시 깜빡임, 상태 유지 어려움 | 부드러운 전환, 앱 같은 느낌 |
| 서버 부하 | 높음 - 매 요청마다 렌더링 작업 수행 | 낮음 - 정적 파일 제공, API만 처리 |
| 서버 요구사항 | 필수 - Node.js 등 렌더링 서버 필요 | 선택적 - 정적 호스팅만으로도 가능 |
| 개발 복잡도 | 높음 - 서버/클라이언트 환경 모두 고려 | 상대적으로 낮음 - 프론트엔드에 집중 |
| 캐싱 전략 | 복잡함 - 동적 콘텐츠 캐싱 어려움 | 쉬움 - 정적 파일은 CDN 캐싱 용이 |
| 소셜 미디어 공유 | 완벽 - 동적 메타태그 생성 가능 | 어려움 - 모든 페이지가 같은 메타태그 |
| JavaScript 의존도 | 낮음 - JS 없이도 기본 콘텐츠 표시 | 높음 - JS 없으면 작동 안 함 |
| 번들 크기 | 작을 수 있음 - 필요한 부분만 전송 가능 | 큼 - 전체 앱 로직을 클라이언트로 전송 |
| Time to Interactive | 빠를 수 있음 - 점진적 향상 가능 | 느림 - JS 로딩 및 실행 대기 |
| 개발 생산성 | 낮음 - 서버/클라이언트 동기화 필요 | 높음 - 단일 코드베이스로 개발 |
| 확장성 | 어려움 - 서버 렌더링 리소스 관리 필요 | 쉬움 - CDN으로 전 세계 배포 용이 |
| 적합한 사례 | 블로그, 뉴스, 쇼핑몰, 포트폴리오 사이트 등 | 대시보드, 어드민, SaaS, 소셜 미디어 등 |