React 빌드와 배포

정적 호스팅 배포 전 점검

정적 호스팅은 파일을 올리는 작업처럼 보이지만 라우팅과 캐시 정책이 사용자 경험을 결정합니다. fallback과 asset 갱신 기준을 함께 확인합니다.

01

정적 호스팅 선택 기준

SPA fallback, cache header, asset fingerprint, base path 항목을 빌드 산출물 관점에서 나누고, 화면 상태와 사용자 조작이 어느 컴포넌트에서 바뀌는지 표시합니다.

빌드 산출물
02

rewrite, cache, publish 경로 경계

배포 설정은 hosting 설정, rewrite rule, CDN cache, 빌드 산출물 업로드 경로를 호스팅 환경 기준으로 확인합니다. 경로 가정이 흩어지면 새로고침과 직접 진입에서 다른 오류가 납니다.

호스팅 경로
03

정적 호스팅 배포의 실패 조건

새로고침 때 404가 나거나 오래된 asset 캐시가 새 배포와 섞이면 호스팅 설정 문제입니다. 배포 URL과 하위 라우트 직접 진입을 같은 커밋에서 확인합니다.

릴리스 확인
04

배포 URL과 캐시 헤더 증거

마지막에는 rewrite 테스트, 캐시 헤더, 배포 URL, 새로고침 시나리오를 남겨 CDN이 어떤 파일과 fallback 규칙을 제공하는지 다시 확인합니다.

close
호스팅 역할
정적 호스팅은 빌드된 HTML, JS, CSS, asset을 CDN에서 서빙하는 배포 방식입니다 서버 렌더링 로직은 없지만 SPA 라우팅 fallback, 캐시 헤더, asset fingerprint가 실제 사용자 화면을 좌우합니다.
CDN + files
Netlify 설정
GitHub 연동 뒤에는 build command, publish directory, 환경 변수를 같은 배포 로그에서 확인합니다 main 브랜치 push가 Netlify build를 시작하고, dist가 publish되며, VITE_ 환경 변수가 production 값으로 치환되는지 봅니다.
build log
배포 회귀
배포 전에는 새로고침 라우트, 404 fallback, 오래된 asset 캐시를 따로 검증합니다 직접 URL 진입과 새로고침에서 index.html rewrite가 동작하고, hashed asset이 새 배포로 바뀌는지 확인합니다.
redirects

정적 호스팅 배포 검증 지점

배포 URL 통과 Netlify URL에서 초기 로드, 라우트 이동, 새로고침, 직접 URL 진입이 모두 같은 React 앱으로 이어지는지 확인합니다.
라우트 404 SPA fallback이 없으면 하위 경로 새로고침에서 404가 나고, 캐시 정책이 맞지 않으면 이전 JS와 새 HTML이 섞일 수 있습니다.
배포 로그 Netlify deploy log, published commit, response header, redirect rule 확인 결과를 남겨 이후 장애 시 같은 배포를 추적합니다.

빌드 배포 점검

질문: Netlify가 어떤 branch, build command, publish directory로 dist를 배포하는가
순서: 정적 asset, CDN, SPA fallback 구분하기 -> Netlify Git 연동과 build 설정 맞추기 -> 라우트 새로고침과 캐시 헤더 검증하기
위험: rewrite와 캐시 헤더를 확인하지 않으면 하위 경로 새로고침 404나 이전 JS 파일 혼용이 배포 후에 발견됩니다.