렌더링 방식, 왜 알아야 할까?
웹 애플리케이션을 개발할 때, 우리는 "사용자에게 화면을 어떻게 보여줄 것인가" 라는 질문에 마주하게 됩니다. 이는 단순히 UI를 구성하는 문제를 넘어, 성능, 사용자 경험, 유지 보수성, SEO 등 여러 측면에 영향을 주는 중요한 결정입니다.
이와 관련해 프론트엔드에서 가장 핵심적으로 고려해야할 개념이 CSR(Client-Side Rendering)과 SSR(Server-Side Rendering)입니다. 각각의 렌더링 방식은 상황과 목적에 따라 뚜렷한 특성과 차별점을 가지므로, 프로젝트의 요구사항에 따라 신중하게 선택할 필요가 있습니다.
🚀 주요 렌더링 방식
1. CSR(Client-Side Rendering)
"모든 것을 브라우저에서 처리한다."
CSR은 콘텐츠를 클라이언트, 즉 브라우저에서 동적으로 렌더링하는 방식입니다. 사용자가 페이지에 처음 접속하면 기본적인 HTML과 JavaScript 파일만 내려받고, 이후 브라우저가 JavaScript를 실행하면서 필요한 데이터를 API를 통해 받아오고 화면을 구성합니다.
✅ 장점
- 사용자 맞춤 UI 구현이 쉬움
- 페이지 간 전환 속도가 빠름
⚠️ 단점
- 초기 로딩 속도가 느릴 수 있음
- 자바스크립트 실행 전까지 콘텐츠가 보이지 않아 SEO에 불리
2. SSR(Server-Side Rendering)
"페이지를 서버에서 그려서 보내준다."
SSR은 클라이언트의 요청이 들어올 때마다 서버에서 완성된 HTML을 만들어 전달하는 방식입니다. 초기 페이지가 빠르게 로딩되며, 검색 엔진이 HTML 구조를 바로 인식할 수 있어 SEO에도 유리합니다. 또한, 자바스크립트가 꺼진 환경에서도 콘텐츠가 노출됩니다.
✅ 장점
- 첫 화면 로딩 속도 빠름
- SEO에 유리
- JS 비활성 환경에서도 콘텐츠 확인 가능
⚠️ 단점
- 서버에 부하
- 페이지 전환 시 전체 새로고침 가능성
🤔 언제 어떤 방식을 써야 할까?
렌더링 방식은 서비스의 목적, 사용자 흐름, 콘텐츠 특성에 따라 달라져야 합니다. 아래는 대표적인 상황별 선택 예시입니다.
블로그, 문서 페이지
SSR 또는 SSG
- SEO가 중요하고 콘텐츠 변화가 적기 때문에, 미리 렌더링 된 HTML을 제공하는 SSR 또는 SSG가 효과적입니다.
마이페이지, 대시보드
CSR
- 로그인 여부나 사용자 데이터에 따라 콘텐츠가 달라지는 서비스는 CSR이 적합합니다. 클라이언트에서 유동적으로 데이터를 받아 렌더링하는 구조가 효율적입니다.
실시간 이벤트 페이지
SSR
- 뉴스 속보나 실시간 데이터가 필요한 페이지는 SSR이 적합합니다. 서버에서 매 요청마다 최신 데이터를 반영한 HTML을 생성할 수 있어 빠른 콘텐츠 갱신이 가능합니다.
📝 마무리
렌더링 방식은 단순히 프론트엔드 구현 방식을 선택하는 문제가 아니라, 전체 서비스의 방향성과 사용자 경험에 직접적인 영향을 주는 요소입니다. 프로젝트를 통해 CSR과 SSR을 직접 적용하고 비교해보며, 어떤 방식이 어떤 상황에 더 적합한지 실질적인 인사이트를 얻고 싶다는 생각을 했습니다. 나아가, 잘못된 렌더링 방식을 선택했을 때 어떤 문제가 발생하는지도 체감하면서 실전 감각을 키워나가고자 합니다.
