웹 렌더링의 다양한 방식 이해하기: CSR, SSR, SPA, SSG, ISR
개요
안녕하세요! 짐코딩입니다. 이번에 준비 중인 Next.js 완벽 마스터 (v15): Notion 기반 개발자 블로그 만들기 (with Cursor AI) 강의를 위해 웹 렌더링의 기본 개념들을 정리해보았습니다. Next.js를 제대로 이해하고 활용하기 위해서는 이러한 렌더링 방식에 대한 이해가 필수적인데요, 강의에 앞서 블로그 독자 여러분들과 먼저 핵심 개념을 공유합니다.
웹 렌더링이란 무엇일까요?
웹 개발에서 CSR, SSR, SSG, ISR 같은 용어를 이야기할 때 '렌더링'이란 **"웹 페이지의 HTML 콘텐츠를 최종적으로 만들어내는 과정"**을 의미해요.
쉽게 말해, 사용자가 브라우저에서 실제로 보게 될 HTML 콘텐츠를 누가, 어디서, 언제 만들어내느냐에 관한 것입니다.
일상 속 예시로 이해하기
- 배달 음식(SSR): 레스토랑(서버)에서 요리를 완성해서 집(클라이언트)으로 배달해주는 방식
- 밀키트(CSR): 재료와 레시피만 배달해주고 집에서 직접 조리하는 방식
- 냉동식품(SSG): 미리 만들어서 냉동해둔 음식을 데워 먹는 방식
- 주기적으로 교체되는 도시락(ISR): 미리 만들어 두지만 주기적으로 새로운 도시락으로 교체해주는 방식
렌더링의 핵심 질문들
웹 렌더링 방식을 구분할 때 우리가 관심 있는 건 이런 질문들이에요:
- 누가 HTML을 만드나요? - 서버? 클라이언트(브라우저)?
- 언제 HTML이 만들어지나요? - 사용자 요청 시? 빌드 타임에 미리?
- 어디서 데이터가 HTML에 통합되나요? - 서버에서? 브라우저에서?
결국 렌더링이란 사용자에게 보여질 최종 HTML을 준비하는 모든 과정을 말합니다. 각 렌더링 방식은 이 과정을 다른 시점에, 다른 장소에서, 다른 방법으로 처리하는 것이죠.
따라서 Next.js 강의에서 말하는 렌더링은 "최종 HTML 콘텐츠를 언제, 어디서, 어떻게 생성하는가"에 관한 개념입니다!
CSR(Client-Side Rendering)의 개념과 동작 방식
CSR은 Client Side Rendering의 약자로, 말 그대로 클라이언트 측인 브라우저에서 HTML 콘텐츠를 만들어내는 방식이에요.
동작 방식
- 서버는 거의 비어있는 HTML 파일과 JavaScript 번들을 클라이언트에 보내줘요.
- 브라우저는 JavaScript를 다운로드하고 실행해요.
- JavaScript가 API 등에서 필요한 데이터를 가져와요.
- JavaScript가 DOM을 조작해서 화면에 콘텐츠를 그려줘요.
쉬운 비유로 이해하기
CSR은 마치 밀키트를 주문하는 것과 같아요:
- 식당(서버)에서는 재료와 조리법(JavaScript)만 배달해줘요
- 여러분(브라우저)이 집에서 직접 요리(렌더링)를 해야 해요
- 처음 준비하는 데 시간이 걸리지만(초기 로딩), 한번 준비해 놓으면 간단한 변경(페이지 전환)은 빠르게 할 수 있어요
- 모든 재료를 다시 주문할 필요 없이 소스만 바꾸거나 토핑만 추가할 수 있어요(부분 업데이트)
장점
- 한번 로딩된 후에는 페이지 전환이 빠르고 부드러워요(다른 방으로 이동하는 것처럼 자연스러워요)
- 서버에 자주 요청하지 않아도 되니 서버 부담이 적어요
- 클릭, 드래그 같은 다양한 상호작용을 풍부하게 구현할 수 있어요
단점
- 처음 들어갈 때 JavaScript를 모두 받아야 해서 시간이 오래 걸릴 수 있어요(마치 처음 밀키트 조리 준비하는 시간)
- 구글 같은 검색 엔진이 내용을 제대로 읽기 어려워요(검색 결과에 잘 안 뜰 수 있어요)
- JavaScript가 꺼져있는 환경에서는 아무것도 보이지 않아요(마치 가스레인지 없이 밀키트를 받은 것과 같죠)
SSR(Server-Side Rendering)의 개념과 동작 방식
SSR은 Server Side Rendering의 약자로, 서버에서 완성된 HTML을 만들어 브라우저에 보내주는 방식이에요.
동작 방식
- 사용자가 웹사이트 주소를 입력하거나 링크를 클릭해요.
- 서버가 요청을 받아서 필요한 데이터를 DB나 API에서 가져와요.
- 서버에서 모든 HTML 내용을 완성해서 브라우저에 보내줘요.
- 브라우저는 이미 완성된 HTML을 화면에 보여주고, 나중에 JavaScript를 로드해서 버튼 클릭 같은 기능을 추가해요(이걸 하이드레이션이라고 해요).
쉬운 비유로 이해하기
SSR은 배달 음식을 주문하는 것과 같아요:
- 레스토랑(서버)에서 음식을 완전히 조리해서 배달해줘요
- 여러분은 받자마자 바로 먹을 수 있어요(빠른 초기 로딩)
- 다른 메뉴가 먹고 싶으면 다시 주문해야 해요(페이지 이동 시 새로고침)
- 각 요리마다 새로운 주문과 배달 과정이 필요해요(서버 요청 증가)
장점
- 페이지를 처음 볼 때 빨리 볼 수 있어요(음식이 도착하자마자 바로 먹을 수 있는 것처럼)
- 구글 같은 검색 엔진이 내용을 잘 읽을 수 있어서 검색 결과에 잘 노출돼요
- JavaScript가 꺼져 있어도 내용을 볼 수 있어요(마치 전자레인지 없이도 배달 음식은 먹을 수 있는 것처럼)
단점
- 매번 페이지를 바꿀 때마다 서버에 요청해야 해서 서버가 바빠질 수 있어요
- 다른 페이지로 이동할 때마다 화면이 하얗게 깜빡이는 경험을 할 수 있어요(새로운 음식을 주문할 때마다 기다려야 하는 것처럼)
- 서버에서 클라이언트로 보내는 데이터 양이 많아져요(완성된 요리 전체를 배달하는 것이니까요)
SPA(Single Page Application)의 개념과 특징
SPA는 Single Page Application의 약자로, 말 그대로 단 하나의 HTML 페이지로 이루어진 웹 애플리케이션이에요. SPA는 사실 렌더링 방식이라기보다는 애플리케이션 구조에 대한 개념이에요. 그리고 대부분의 SPA는 CSR(Client-Side Rendering) 방식을 사용해서 구현돼요.
특징
- 처음에 하나의 HTML 페이지만 로드하고, 이후에는 JavaScript로 콘텐츠를 변경해요.
- 페이지를 이동할 때 새로고침 없이 필요한 부분만 바꿔요.
- 페이지 주소 변경(라우팅)도 브라우저에서 JavaScript로 처리해요.
- CSR 방식으로 동작하기 때문에 JavaScript가 HTML을 동적으로 만들어요.
장점
- 앱처럼 자연스럽게 화면이 전환되어 사용자 경험이 좋아요(마치 테마파크 내에서 자유롭게 이동하는 느낌)
- 필요한 데이터만 요청해서 서버와 통신량을 줄일 수 있어요
- 프론트엔드 개발자와 백엔드 개발자가 독립적으로 일할 수 있어요
단점
- CSR 방식을 사용하기 때문에 처음 접속할 때 모든 JavaScript를 다운로드해야 해서 시간이 걸릴 수 있어요
- 검색엔진이 JavaScript로 만들어진 콘텐츠를 읽기 어려워요
- 여러 화면 상태를 관리하는 것이 복잡할 수 있어요(테마파크의 많은 시설 관리처럼)
대표적인 SPA 예시로는 Gmail, Facebook, Twitter, Trello 같은 서비스가 있어요. 이런 서비스들은 웹사이트라기보다는 웹 애플리케이션에 가까운 경험을 제공한답니다!
SSG(Static Site Generation)의 개념과 동작 방식
SSG는 Static Site Generation의 약자로, 웹사이트를 배포하기 전에 미리 모든 HTML 페이지를 만들어두는 방식이에요.
동작 방식
- 개발자가 웹사이트를 빌드(build)할 때 모든 페이지의 HTML을 미리 만들어둬요.
- 이렇게 미리 만들어진 HTML 파일들을 CDN 같은 곳에 올려놓아요.
- 사용자가 웹사이트에 접속하면 이미 만들어진 HTML 파일을 바로 보내줘요.
- 브라우저는 HTML을 보여주고 JavaScript를 로드해서 버튼 같은 기능을 활성화해요.
쉬운 비유로 이해하기
SSG는 냉동식품이나 도시락과 같아요:
- 미리 대량으로 음식(HTML)을 만들어서 냉동고(CDN)에 보관해둬요
- 손님이 오면 데워서 바로 제공하기만 하면 돼요(매우 빠른 제공)
- 새로운 메뉴를 추가하려면 전체 생산 라인을 다시 돌려야 해요(재빌드 필요)
- 매일 바뀌는 일일특선 메뉴 같은 건 제공하기 어려워요(동적 콘텐츠 제한)
장점
- 정말 빠르게 페이지를 보여줄 수 있어요(이미 다 만들어져 있으니까요)
- 서버에 특별한 코드가 돌아가지 않아서 해킹 위험이 적어요
- 단순한 HTML 파일만 제공하면 되니 서버 비용이 매우 저렴해요
- 검색엔진이 모든 내용을 완벽하게 읽을 수 있어요
단점
- 사용자마다 다른 내용을 보여주기 어려워요(모든 손님에게 같은 도시락 제공)
- 콘텐츠가 변경될 때마다 전체 사이트를 다시 빌드해야 해요
- 페이지가 많은 대형 사이트는 빌드하는 데 시간이 오래 걸릴 수 있어요(대량 생산에 시간 소요)
ISR(Incremental Static Regeneration)의 개념과 동작 방식
ISR은 Incremental Static Regeneration의 약자로, SSG의 좋은 점은 유지하면서 주기적으로 페이지를 새로 만들어주는 똑똑한 방식이에요. Next.js에서 특별히 개발한 기술이죠!
동작 방식
- 처음에 웹사이트를 빌드할 때 HTML 페이지들을 미리 만들어둬요.
- 개발자가 설정한 시간(예: 1시간마다, 하루마다)이 지나면 페이지를 새로 만들어요.
- 사용자가 페이지를 방문하면 일단 기존에 있던 페이지를 보여주고, 뒤에서는 새 버전을 준비해요.
- 다음 사용자부터는 새로 만든 페이지를 볼 수 있어요.
쉬운 비유로 이해하기
ISR은 정기 구독 잡지와 같아요:
- 잡지사(서버)에서 매달 새로운 잡지(HTML)를 미리 인쇄해서 준비해 둬요
- 구독자(사용자)가 요청하면 현재 발행된 최신호를 바로 배달해줘요(빠른 응답)
- 뒤에서는 다음 달 새 호를 준비하고 있어요(백그라운드 재생성)
- 새 호가 발행되면 그때부터는 새 잡지를 배달해요(주기적 업데이트)
- 모든 잡지를 매번 처음부터 다시 기획할 필요 없이 내용만 업데이트해요(효율적인 재생성)
장점
- SSG처럼 빠른 속도를 유지하면서도 어느 정도 최신 정보를 제공할 수 있어요
- 서버에 갑자기 많은 방문자가 몰려도 잘 버틸 수 있어요
- 변경된 페이지만 다시 만들면 되니까 전체 사이트를 다시 빌드할 필요가 없어요
단점
- 실시간으로 바로바로 정보가 반영되지는 않아요(설정한 시간만큼 정보가 늦을 수 있어요)
- Next.js 같은 특정 프레임워크에서만 사용할 수 있어요
- 설정이나 이해가 다른 방식보다 약간 복잡할 수 있어요
가장 큰 장점은 SSG의 빠른 속도와 SSR의 최신 데이터 제공 사이의 균형을 맞춰준다는 점이에요. 자주 바뀌지만 완전한 실시간일 필요는 없는 콘텐츠에 딱 좋은 방식이죠!
각 렌더링 방식의 차이점과 장단점 비교
| 렌더링 방식 | 렌더링 위치 | 초기 로딩 속도 | SEO 친화성 | 서버 부하 | 실시간 데이터 | 주요 사용 사례 |
|---|---|---|---|---|---|---|
| CSR | 클라이언트 | 느림 | 낮음 | 낮음 | 높음 | 대시보드, 관리자 페이지 |
| SSR | 서버 | 빠름 | 높음 | 높음 | 높음 | 콘텐츠 중심 웹사이트, 이커머스 |
| SPA | 클라이언트 | 중간~느림 | 낮음~중간 | 낮음 | 높음 | 웹 애플리케이션 |
| SSG | 빌드 시 | 매우 빠름 | 매우 높음 | 매우 낮음 | 낮음 | 블로그, 문서, 마케팅 사이트 |
| ISR | 빌드+주기적 | 매우 빠름 | 매우 높음 | 낮음 | 중간 | 콘텐츠가 가끔 업데이트되는 사이트 |
각 방식에 적합한 사용 사례 예시
CSR에 적합한 사례
- 관리자 대시보드: 자주 데이터가 변하는 개인화된 화면이 필요할 때
- 웹 메일 클라이언트: Gmail처럼 사용자마다 다른 내용을 보여줄 때
- SNS 피드: 실시간으로 콘텐츠가 업데이트되는 경우
SSR에 적합한 사례
- 쇼핑몰: 상품 정보가 자주 바뀌고 검색엔진에 잘 노출되어야 할 때
- 뉴스 사이트: 최신 기사를 빠르게 보여주면서 검색도 잘 되어야 할 때
- 기업 웹사이트: 방문자별 맞춤 콘텐츠를 제공하면서 검색 최적화가 필요할 때
SPA에 적합한 사례
- 웹 기반 도구: Trello나 구글 문서처럼 앱 같은 경험이 필요할 때
- 온라인 편집기: 그림 그리기, 문서 편집 등 브라우저에서 많은 작업을 할 때
- 채팅 애플리케이션: 페이지 전환 없이 계속 대화를 이어가야 할 때
SSG에 적합한 사례
- 개인 블로그: 글이 자주 바뀌지 않고 빠른 로딩이 중요할 때
- 회사 소개 페이지: 정보가 거의 변하지 않고 SEO가 중요할 때
- 기술 문서: 내용이 안정적이고 많은 사람이 빠르게 접근해야 할 때
ISR에 적합한 사례
- 제품 카탈로그: 가끔 새 제품이 추가되지만 대부분은 변하지 않을 때
- 인기 블로그: 트래픽이 많고 콘텐츠가 주기적으로 업데이트될 때
- 이벤트 사이트: 행사 정보가 가끔 업데이트되지만 빠른 접속이 필요할 때
웹 렌더링 방식 선택을 위한 간단한 가이드
웹 렌더링 방식을 선택할 때는 다음과 같은 질문을 해보세요:
- 콘텐츠가 자주 변하나요?
- 예 → 실시간 데이터가 필요한가요?
- 예 → SSR 또는 CSR
- 아니오 → ISR
- 아니오 → SSG
- 예 → 실시간 데이터가 필요한가요?
- SEO가 중요한가요?
- 예 → SSR, SSG, 또는 ISR
- 아니오 → CSR 또는 SPA
- 사용자 상호작용이 많은가요?
- 예 → CSR 또는 SPA
- 아니오 → SSR, SSG, 또는 ISR
참고 자료
- Next.js 공식 문서: https://nextjs.org/docs
- MDN 웹 문서: https://developer.mozilla.org/ko/
- React 공식 문서: https://reactjs.org/docs/getting-started.html
- 짐코딩 유튜브 채널: https://youtu.be/BxXo-Unmsz0