같은 화면을 두고도 팀마다 CSR로 갈지 SSR로 갈지, 혹은 SSG나 ISR, RSC로 갈지 결론이 다르다. "더 빠른 게 뭐냐"는 질문 자체가 틀렸다는 걸 실무에서 몇 번 겪고 나서야 인정하게 됐다. 정답은 기술 선호가 아니라 콘텐츠 성격에 있었다.
SSR과 CSR, 뭘 기준으로 나눠야 하나?
결론부터 말하면 렌더링 방식은 취향이 아니라 콘텐츠 변경 빈도, 개인화 정도, SEO 필요성 세 가지로 먼저 가른다. 이 세 축을 정하고 나면 CSR·SSR·SSG·ISR·RSC 중 어느 조합이 맞는지가 상당 부분 자동으로 좁혀진다. 세부 튜닝(캐시, 스트리밍, 번들 분할)은 그다음 문제다.
- 갱신 주기가 길고 SEO가 중요하면 SSG가 우선, 자주는 아니지만 완전 정적도 아니면 ISR을 얹는다.
- 개인화가 강하고 첫 화면 품질이 중요하면 SSR이나 RSC 중심으로 간다.
- 인터랙션이 핵심이고 SEO 요구가 약하면 CSR도 여전히 적합하다.
- 페이지 일부만 동적이면 정적 shell + 동적 island 패턴이 가장 실용적이다.
- "서버에서 렌더한다"와 "빠르다"는 별개다. 실측 체감은 렌더링 이름보다 데이터 패칭 위치와 캐싱 전략이 더 크게 좌우한다.
문제 상황은 이렇다. 초기에 CSR로만 짠 대시보드를 SEO 요구가 생겼다고 그대로 SSR로 바꾼 팀을 본 적 있다. 결과는 서버 CPU 사용량만 늘고 체감 속도 개선은 미미했다. 원인은 렌더링 방식 자체가 아니라 데이터 패칭 구조를 손대지 않았기 때문이었다. 이 글은 그 판단 순서를 원리 수준에서 짚는다.
브라우저가 그리는 CSR은 왜 초기 화면이 늦게 뜨나?
CSR은 서버가 거의 빈 HTML만 내려주고, 브라우저가 JS 번들을 내려받아 실행한 뒤에야 실제 콘텐츠를 그리기 때문이다. 요청 → HTML 파싱 → JS 다운로드 → 실행 → API 호출 → 렌더링 순서를 거치므로, 각 단계가 순차적으로 쌓인다. 번들이 크고 API 응답이 느릴수록 첫 화면(First Contentful Paint)까지의 지연이 그대로 누적된다.
이 구조는 상호작용이 많은 화면, 예를 들어 실시간 편집기나 필터가 복잡한 내부 도구에는 잘 맞는다. 페이지 전환마다 서버 왕복 없이 클라이언트에서 상태를 관리할 수 있어서다. 반면 검색엔진 크롤러가 JS 실행 없이 HTML만 훑는 경우가 여전히 있어, SEO가 중요한 공개 페이지에서는 불리해질 수 있다. web.dev 렌더링 패턴 가이드에서도 CSR이 상호작용성과 초기 로딩 속도 사이에서 트레이드오프를 갖는다는 점을 렌더링 전략 비교의 기본 축으로 다룬다.
서버가 먼저 그리는 SSR은 무엇을 대가로 얻나?
SSR은 요청이 들어올 때마다 서버가 HTML을 완성해서 보내므로 첫 화면 노출과 SEO에는 유리하지만, 그 대가로 요청마다 서버 연산 비용이 든다. 트래픽이 늘어날수록 이 비용은 선형에 가깝게 증가하고, TTFB(Time To First Byte) 관리가 중요한 운영 포인트가 된다. 데이터베이스 조회나 외부 API 호출이 렌더링 경로에 끼어 있으면 TTFB가 그대로 늘어난다.
그래서 SSR을 쓸 때는 캐시 계층(엣지 캐시, CDN, 서버 메모리 캐시)과 스트리밍·Suspense 경계 설정이 사실상 필수에 가깝다. 같은 SSR이라도 데이터 패칭을 렌더링 트리 상단에서 한 번에 몰아서 하느냐, 컴포넌트별로 분산해서 스트리밍하느냐에 따라 체감 속도가 크게 갈린다. 이 부분은 Next.js 공식 렌더링 문서에서도 렌더링 전략과 별개로 데이터 패칭 위치를 강조하는 이유다. 개인화가 강한 화면, 즉 로그인한 사용자별로 다른 데이터를 붙여야 하는 화면은 CSR로 두면 로딩 스피너가 먼저 뜨고 나서 콘텐츠가 뒤늦게 채워지는 깜빡임이 생기기 쉬운데, SSR이나 RSC는 서버에서 사용자 데이터를 붙여 완성된 화면을 바로 내려줄 수 있어 이 지점에서 유리한 경우가 많다.
SSG·ISR·RSC는 이 스펙트럼에서 어디에 있나?
이 셋은 SSR·CSR 사이의 극단이 아니라, "언제 렌더링을 하느냐"와 "무엇을 클라이언트로 보내느냐"를 각각 다르게 조정한 변형이다. SSG는 빌드 시점에 HTML을 미리 만들어 두는 방식이라 요청마다 서버 연산이 필요 없고, 변경이 적은 콘텐츠·마케팅·문서 페이지에서 가장 단순하고 안정적인 선택지다. 트래픽이 커질수록 서버 비용 이점도 커진다.
ISR은 SSG의 정적 이점에 재생성 주기를 더한 형태다. "자주 바뀌진 않지만 완전 정적도 아닌" 콘텐츠, 예를 들어 하루 몇 번 갱신되는 상품 목록 페이지 같은 데 맞는다. RSC(Server Components)는 이 스펙트럼과는 조금 다른 축인데, "서버에서 렌더하고 클라이언트로는 인터랙션이 필요한 부분만 보낸다"는 방향이라 번들 축소와 데이터 패칭 분리에 강점이 있다. 대시보드나 어드민처럼 복잡한 화면에서 RSC와 서버 컴포넌트 분리를 함께 쓰는 경험담이 최근 자료에서 자주 확인된다.
서버 컴포넌트로 옮기면 무조건 빨라진다는 말, 맞나?
아니다. 2025년에 나온 한 실측 후기에서는 App Router로 구조만 옮기고 데이터 패칭 방식을 그대로 둔 경우 성능 이득이 거의 없었고, 데이터 패칭 구조를 함께 바꿔야 개선이 나타났다고 정리했다. 렌더링 방식을 바꾸는 것과 데이터를 가져오는 위치·순서를 바꾸는 것은 별개의 작업이라는 뜻이다.
실제로 성능 개선 폭이 큰 사례들을 보면 보통 "SSR로 바꿨다"는 단일 조치가 아니라 번들 분할, 서버 컴포넌트화, 캐시 전략, 스트리밍, 데이터 로딩 구조 변경이 함께 들어간다. 렌더링 이름만 바꾸고 나머지를 손대지 않으면 서버 연산 비용만 늘고 체감 속도는 그대로인 상황이 생길 수 있다. 이 오해 때문에 "RSC로 전환했는데 왜 안 빨라지냐"는 질문이 반복되는데, 답은 대체로 데이터 패칭 위치를 함께 바꿨는지 여부에 있었다.
실무에서는 언제 SSR을 쓰고 언제 CSR로 남겨두나?
적합·부적합 조건을 나눠보면 판단이 한결 쉬워진다.
| 조건 | 적합한 방향 |
|---|---|
| 콘텐츠 변경 거의 없음 + SEO 중요 | SSG |
| 하루 몇 번 갱신 + SEO 중요 | ISR |
| 로그인 개인화 + 첫 화면 품질 중요 | SSR 또는 RSC |
| 인터랙션 위주 + SEO 약함 (내부 도구, 에디터) | CSR |
| 페이지 일부만 동적 (배너, 위젯) | 정적 shell + island |
| 서버 비용에 민감, 트래픽 큼 | SSR 남발보다 SSG/ISR/RSC로 서버 렌더 범위 축소 |
로그인 후 개인화 화면은 SSR + 캐시 + 일부 CSR 조합이 자주 쓰이는데, 첫 화면은 서버에서 개인화 데이터까지 붙여 내려주고 이후 상호작용(필터, 정렬, 실시간 갱신)만 클라이언트에서 처리하는 식이다. 반대로 내부 관리 도구처럼 SEO가 아예 필요 없고 사용자가 로그인 후 오래 머무는 화면이라면 CSR로 두고 초기 로딩 한 번의 비용을 감수하는 편이 서버 비용 관리에는 더 낫다. 어느 쪽이든 "무조건 이 방식이 낫다"는 판단보다, 트래픽 규모와 개인화 정도, 갱신 주기를 먼저 표로 정리해보는 쪽이 실수를 줄인다.
핵심 정리
- 렌더링 방식은 기술 취향이 아니라 콘텐츠 변경 빈도, 개인화 정도, SEO 필요성으로 먼저 고른다.
- SSR은 빠른 초기 표시, CSR은 강한 상호작용, SSG/ISR은 낮은 서버 비용과 안정적 캐시, RSC는 서버 중심 분리와 번들 절감에 강점이 있다.
- 실측 체감은 렌더링 이름보다 데이터 패칭 위치와 캐싱 전략이 더 크게 좌우한다.
- 2026년 기준으로도 "서버 컴포넌트로 옮기면 빨라진다"는 단정은 성립하지 않으며, 데이터 패칭 구조 변경이 병행돼야 개선이 나타난다.
- 페이지 일부만 동적인 경우 정적 shell + 동적 island 패턴이 가장 실용적인 절충안이다.