areumH 님의 상세페이지[1팀 한아름] Chapter 4-1 성능 최적화

과제 체크포인트

배포 링크

기본) https://areumh.github.io/front_6th_chapter4-1/vanilla/

기본과제 (Vanilla SSR & SSG)

Express SSR 서버

  • Express 미들웨어 기반 서버 구현
  • 개발/프로덕션 환경 분기 처리
  • HTML 템플릿 치환 (<!--app-html-->, <!--app-head-->)

서버 사이드 렌더링

  • 서버에서 동작하는 Router 구현
  • 서버 데이터 프리페칭 (상품 목록, 상품 상세)
  • 서버 상태관리 초기화

클라이언트 Hydration

  • window.__INITIAL_DATA__ 스크립트 주입
  • 클라이언트 상태 복원
  • 서버-클라이언트 데이터 일치

Static Site Generation

  • 동적 라우트 SSG (상품 상세 페이지들)
  • 빌드 타임 페이지 생성
  • 파일 시스템 기반 배포

심화과제 (React SSR & SSG)

React SSR

  • renderToString 서버 렌더링
  • TypeScript SSR 모듈 빌드
  • Universal React Router (서버/클라이언트 분기)
  • React 상태관리 서버 초기화

React Hydration

  • Hydration 불일치 방지
  • 클라이언트 상태 복원

Static Site Generation

  • 동적 라우트 SSG (상품 상세 페이지들)
  • 빌드 타임 페이지 생성
  • 파일 시스템 기반 배포

구현 과정 돌아보기

가장 어려웠던 부분과 해결 과정

ssr ssg 환경에서 클라이언트와 서버에서의 라우터를 안전하게 공존시키는 부분이 어려웠다. 과제를 하기 전엔 ssr를 단순히 서버에서 html을 먼저 내려준다 정도의 사전적 정의 정도로만 이해하고 있었기 때문에 사이트의 각 페이지마다 어떻게 서버가 html을 생성해주는건지 잘 상상이 가지 않았다.

구현하면서 새롭게 알게 된 개념

클라이언트와 서버에서 라우트 정보를 일치시켜야 초기 렌더링과 하이드레이션이 가능하다는 것, 서버는 도메인 루트 기준으로 라우팅을 처리하기 때문에 인자로 base_url을 넘겨줄 필요가 없는 것 등을 알게 되었다. 추가로 이번 과제를 통해 renderToString이라는 함수를 처음 접하게 되었다. 처음 들었을 땐 과제로 제공된 유틸 함수인 줄 알았으나 ReactDOMServer 패키지에서 제공하는 함수였다. renderToString 함수는 동기적으로 컴포넌트를 html 문자열로 변환하므로 렌더 전에 서버에서 필요한 비동기 데이터를 반드시 마쳐야 한다는 것을 알게 되었다!

성능 최적화 관점에서의 인사이트

학습 갈무리

Q1. 현재 구현한 SSR/SSG 아키텍처에서 확장성을 고려할 때 어떤 부분을 개선하시겠습니까?

Q2. Express 서버 대신 다른 런타임(Cloudflare Workers, Vercel Edge Functions 등)을 사용한다면 어떤 점을 수정해야 할까요?

Q3. 현재 구현에서 성능 병목이 될 수 있는 지점은 어디이고, 어떻게 개선하시겠습니까?

Q4. 1000개 이상의 상품 페이지를 SSG로 생성할 때 고려해야 할 사항은 무엇입니까?

빌드 시간 최적화, 빌드 실패 시의 복구 전략 등

Q5. Hydration 과정에서 사용자가 느낄 수 있는 UX 이슈는 무엇이고, 어떻게 개선할 수 있을까요?

인터렉티브 전까지 사용자의 액션에 대한 무응답에 대해 스켈레톤 ui나 주요 부분만 즉시 하이드레이트하는 등의 기능으로 개선할 수 있다.

Q6. 이번 과제에서 학습한 내용을 실제 프로덕션 환경에 적용할 때 추가로 고려해야 할 사항은?

페이지 로드 에러에 대한 재시도, 이미지 최적화, 빌드 성능 개선, 모니터링 체계 등

Q7. Next.js 같은 프레임워크 대신 직접 구현한 SSR/SSG의 장단점은 무엇인가요?

커스텀 요구 사항에 대해 유연하게 구현이 가능하고, ssr와 ssg의 동작 원리를 코드를 통해 직접 이해할 수 있다. 하지만 next.js가 제공하는 기능을 직접 구현해야 하며, 유지보수 부담이 크다.

Q8. Next.js 를 이용하여 SSG 방식으로 배포하려면 어떻게 해야 좋을까요?

getStaticProps - 빌드 시점에서 데이터를 불러와 정적 html을 생성 getStaticPaths - 다이나믹 라우트에 대해 사전 생성할 경로를 정의 next build && next export - 정적 html을 생성하여 배포

코드 품질 향상

자랑하고 싶은 구현

개선하고 싶은 부분

리팩토링 계획

학습 연계

다음 학습 목표

실무 적용 계획

리뷰 받고 싶은 내용

과제 피드백

수고했습니다. 이번 과제는 SSR과 SSG를 직접 구현해보면서 렌더링 전략의 차이점과 성능 최적화 방법을 체험하는데 목적이 있었습니다.

클라이언트와 서버에서 라우터를 안전하게 공존시키는 문제를 어려워하신 게 당연해요. 이 부분이 SSR의 핵심 복잡성 중 하나거든요. 과제 전에 "서버에서 html을 먼저 내려준다" 정도로만 이해했다가 실제로 각 페이지마다 어떻게 html을 생성하는지 체험해보신 과정이 의미있었을 거예요.

renderToString을 처음 접하셨다니 새로운 발견이 많았네요. "동기적으로 컴포넌트를 html 문자열로 변환하므로 렌더 전에 서버에서 필요한 비동기 데이터를 반드시 마쳐야 한다"는 핵심을 정확히 파악하셨어요. 이 부분이 SSR의 데이터 프리페칭이 중요한 이유죠.

온전히 과제가 마무리 되지 않았지만 SSR/SSG의 기본 개념과 Next.js와의 연결점을 잘 이해했고 무엇을 배우면 좋은지를 알았기에 기회가 되면 꼭 마무리 한번 해보기를 바래요! 다음 과제도 화이팅입니다!