성능 최적화 🎮
항해 4챕터 주제이자 마지막 주제입니다.
사실 현업에서 성능 최적화를 나름(?) 경험해봤다고 생각했습니다.
백엔드 시스템 구조 개선, DB 인덱스 최적화, 쿼리 튜닝 등이 주된 영역이었습니다.
하지만 이번 4챕터를 통해 프론트엔드 성능 최적화는 완전히 다른 관점과 접근이 필요하다는 걸 깨달았습니다.
이 코드가 “서버”에서 실행 될 때, “브라우저”에서 실행될 때 어떤 차이가 있는걸까!?
해당 내용은 준일 코치가 이번 과제를 하면서 생각해봤으면 하는 주제입니다.
현업에 종사하면서 한 번도 생각 해보지 못한 주제여서 사실 어떻게 접근해야 할지 막막했습니다....
그리고 업무상 이슈로 인해 9주차도.. 과제 통과 하진 못 했습니다.
끈질기게 붙잡고 있었지만 처음 접해서 그런지 벽이 크게 느껴졌습니다.
이번에는 SSR 과 SSG 의 벽을 넘기 위한 내용을 정리해보겠습니다.
SSR과 SSG, 프론트엔드 성능 최적화의 핵심 ⚙️
프론트엔드 개발을 하다 보면 "빠른 로딩 속도와 좋은 SEO를 동시에 잡을 수 있는 방법이 없을까?"라는 고민에 직면하게 됩니다.
그 해답이 바로 SSR(Server-Side Rendering)과 SSG(Static Site Generation)입니다.
SSR(Server-Side Rendering)이란?
SSR은 서버에서 HTML 문서를 완전히 렌더링한 후 클라이언트에게 전달하는 방식입니다. 마치 식당에서 완성된 요리를 가져다주는 것과 같습니다.
손님(사용자)이 주문하면, 주방(서버)에서 요리(페이지)를 완성해서 서빙해주는 방식이죠.
SSR의 핵심 장점들
🚀 빠른 초기 로딩
CSR이 밀키트처럼 재료를 받아 직접 요리해야 한다면, SSR은 배달음식처럼 완성품을 바로 받아볼 수 있습니다.
서버에서 미리 완성된 HTML을 보내주기 때문에 사용자는 즉시 콘텐츠를 볼 수 있습니다.
🔍 SEO 최적화
검색엔진이 웹사이트를 방문했을 때 완성된 HTML 내용을 바로 읽을 수 있습니다.
특히 SNS 공유 시 보이는 OG(Open Graph) 태그도 페이지별로 적절히 설정할 수 있어 검색엔진 친화적입니다.
SSR이 SEO에 유리한 이유:
- 완성된 HTML 제공: 검색봇이 페이지 내용을 바로 읽을 수 있음
- 빠른 로딩: 검색엔진이 선호하는 핵심 요소
- 메타데이터: 제목, 설명, 이미지 등이 미리 준비됨
Hydration 과정
SSR의 독특한 특징 중 하나가 Hydration입니다. 서버에서 보낸 완성된 HTML에 나중에 도착하는 JavaScript가 결합되어 상호작용이 가능해지는 과정입니다.
사용자는 먼저 정적인 페이지를 보다가, JS 로딩이 완료되면 클릭이나 입력 등의 기능을 사용할 수 있게 됩니다.
SSG(Static Site Generation)란?
SSG는 사용자가 요청하기 전에 미리 모든 웹페이지를 완성해두는 방식입니다.
마치 신문을 새벽에 미리 인쇄해서 배달하는 것처럼, 웹페이지도 빌드 시점에 HTML을 생성해두고 사용자에게는 완성품만 제공합니다.
SSG는 어떻게 동작할까?
간단한 4단계:
1. 개발자가 빌드 실행 → 모든 페이지를 HTML로 변환
2. 데이터 수집 → API, CMS 등에서 필요한 정보를 가져와 페이지에 결합
3. CDN에 배포 → 완성된 파일들을 전 세계 서버에 배치
4. 사용자 요청 → 가장 가까운 서버에서 즉시 완성된 페이지 제공
SSG의 강력한 장점들
⚡ 압도적인 속도
이미 완성된 HTML을 바로 전달하므로 로딩이 매우 빠릅니다.
CDN을 통해 전 세계 어디서나 빠른 접속이 가능하고, 서버는 단순히 파일만 전달하면 되므로 부하가 거의 없습니다.
💰 경제적이고 안전함
정적 파일 호스팅만으로 충분해 비용이 저렴하고, 서버 사이드 코드가 없어 해킹 위험이 낮으며 매우 안정적입니다.
⚠️ 하지만..한계점도 존재함
- 실시간 데이터 처리 어려움: 사용자별 개인화나 실시간 업데이트가 필요한 기능 구현이 복잡
- 빌드 시간 증가: 사이트 규모가 커질수록 전체 빌드 시간이 길어짐
- 즉시 반영 불가: 작은 변경사항도 전체 재빌드 후 배포 필요
SSR vs CSR vs SSG 비교
| 구분 | SSR | CSR | SSG |
|---|---|---|---|
| 초기 로딩 | ⚡ 빠름 (완성된 HTML 제공) | 🐌 느림 (JS 로딩 후 렌더링) | ⚡⚡ 매우 빠름 (사전 생성된 HTML) |
| 페이지 이동 | 🐌 느림 (매번 서버 요청) | ⚡ 빠름 (이미 로드된 JS 활용) | ⚡ 빠름 (정적 파일) |
| SEO | 🏆 우수 | ⚠️ 제한적 | 🏆 우수 |
| 서버 부하 | 📈 높음 | 📉 낮음 | 📉 매우 낮음 |
| 실시간 데이터 | ✅ 가능 | ✅ 가능 | ❌ 어려움 |
언제 어떤 방식을 선택해야 할까?
✅ SSR이 적합한 경우
- 전자상거래 사이트: 실시간 재고, 개인화된 추천
- 뉴스 사이트: 자주 업데이트되는 콘텐츠
- 소셜 미디어: 사용자별 다른 피드
✅ SSG가 적합한 경우
- 블로그, 포트폴리오: 글이나 작품 소개 위주
- 회사 홈페이지: 제품/서비스 소개, 회사 정보
- 문서 사이트: API 문서, 가이드라인
- 마케팅 랜딩 페이지: SEO가 중요한 프로모션 사이트
✅ CSR이 적합한 경우
- 대시보드 앱: 복잡한 사용자 인터랙션
- 게임이나 도구: 높은 상호작용성 필요
- 내부 관리 시스템: SEO가 중요하지 않은 경우
📍 마치면서..
SSR과 SSG는 각각 "동적 콘텐츠 + 빠른 초기 로딩"과 "정적 콘텐츠 + 최고의 성능"이라는 서로 다른 강점을 가지고 있습니다. 프로젝트의 성격과 요구사항을 정확히 파악하고 적절한 렌더링 방식을 선택하는 것이 성공적인 웹 애플리케이션 개발의 핵심입니다.
🔗 공식 문서
Next.js SSR
Next.js SSG
MDN SSR 문서
MDN SSG 문서
🔗 기술 블로그
서버 사이드 렌더링이란?
SPA와 SSG, 그리고 SSR
렌더링 삼형제 CSR, SSR, SSG 이해하기
CSR vs SSR vs SSG
이번 주 6기와의 추억 🌇
어느 날 페어 4팀 코어타임 스크럼에 참여하고 당시의 내용을 잊고 있었는데...
4팀의 유진, 지혜님 과 대화를 하다가 페어 4팀 오프라인 모임 참여 같이 하는 게 어떻겠냐는 제안을 해줘서 너무 기쁜 마음으로 참여했습니다.
영수증과.. 그 날의 흔적들만 사진으로 있습니다.. (하늘 풀 코스)
또.. 마이크...를 들어 버렸습니다.... 정말 왜 저러는지 모르겠습니다.
정신 차리니까 마이크가 손에 쥐어져 있었습니다. 그리고 7팀 용훈이 창훈이 알게 돼서 너무 좋았습니다.
냉짬뽕이라는 것을 처음 먹어봤는데.. 처음엔 느리한테 "그게 뭔데 왜 먹는데" 하다가
다음 날에 생각났습니다... 맛있데요?
그리고 의근형이랑 술도 안 마시고 3시간 대화했습니다... 시간 가는 줄 몰랐습니다..
저의 작은 소망이 항해 끝나기 전에 모든 팀이랑 인사 나누기 였는데 이번 모임을 통해서 100% 는 아니여도 거의 모든 분과 인사를 나눌 수 있게 돼서 좋았습니다.
✅ Keep: 이번주 내가 잘한 것들
- 페어 4팀 오프라인 모임 참여
- 우리 팀 지훈의 강의를 들은 것.
- 지훈이는 크게 될 인물 같다..
❗ Problem: 탈탈 털린 순간
- .... 과제...SSR.. 만만하게 봤다
💡 Try: 노력, 다짐, 실행
- 마지막 10주 마무리 잘 하기.
🧠 이번 주 한 줄 회고:
끝 까지
▶ 허정석님의 추천 코드 : Vo6fpd
