프론트엔드 성능 예산(performance budget)을 초기 JS 킬로바이트, LCP·INP·CLS, 이미지·폰트, 서드파티 스크립트 상한과 Lighthouse CI 게이트로 정리한다. 라우트별 번들 표, PR 체크리스트, 2주 도입 순서, web.dev·LHCI 출처와 Core Web Vitals·Vite·Next.js 내부링크. 개발자·React·번들러·API 연동 화면 성능 실무 가이드.
PR 본문에 “성능 개선했습니다”만 있으면 리뷰어는 승인 기준이 없다. 성능 예산(performance budget)은 초기 JS 킬로바이트, LCP·INP·CLS 임계값, 이미지·서드파티 스크립트 상한을 숫자로 고정해, 넘기면 CI가 빨갛게 만드는 규칙이다. 한 번 팀 문서에 박아 두면 “이 기능 넣어도 돼요?” 질문이 측정 가능한 체크리스트로 바뀐다.
지표 해석은 Core Web Vitals 2026과 LCP·INP·CLS 실전을, 번들러 선택은 Vite vs Webpack을, 출시 전 공통 점검은 App Router 프로덕션 체크리스트·프로덕션 배포 체크리스트를 같이 보면 빈칸이 줄어든다.
예산은 마케팅 문구가 아니다. 제품 목표 네트워크·기기에서 허용할 자원의 상한이다. 모바일 3G·중저가 안드로이드를 기준으로 잡을수록 숫자가 빡세지고, 사내 와이파이·맥북만 보면 예산이 헐거워진다. 먼저 “누구의 기기에서 성공인가”를 한 줄로 적는다.
| 예산 종류 | 예시 단위 | 언제 쓰나 |
|---|---|---|
| 수량(Quantity) | JS 170KB gzip, 요청 수 50 | 번들·이미지·폰트 상한, PR 단위 회귀 차단 |
| 시간(Timing) | LCP ≤2.5s, TTFB ≤0.8s | 필드·랩 지표, 릴리스 게이트 |
| 규칙(Rule) | Lighthouse Performance ≥90 | CI 스모크, 회귀 경보 |
| 마일스톤 | FCP·LCP·TTI 구간 목표 | 랜딩·결제 등 핵심 경로 설계 |
web.dev의 성능 예산 가이드는 “작은 예산부터 시작하고, 실사용자 데이터로 보정하라”고 말한다. 첫 주부터 완벽 숫자보다, 홈·로그인·결제 3개 URL에 임시 상한을 걸고 CI에 붙이는 편이 실무에 가깝다.
한 줄 판정 — “이 PR이 예산을 넘는가?”에 예/아니요로 답할 수 없으면 아직 예산이 아니다. 주관적 체감만 남은 상태다.
필드 지표만 보면 배포 직후 데이터가 부족하고, 랩(Lighthouse)만 보면 실기기 분산을 놓친다. 둘을 짝으로 둔다. Core Web Vitals 목표는 구글 공개 기준을 출발점으로 쓰고, 팀 제품에 맞게 조금 더 빡세게 조여도 된다.
점수 90을 목표로 적기만 하고 JS 킬로바이트를 비우면, 라이브러리 하나 추가할 때마다 “일단 머지하고 나중에 최적화”가 반복된다. 시간 지표 + 수량 지표를 한 표에 나란히 두는 이유가 여기 있다.
모노리식 “전체 번들 300KB” 한 줄은 거의 바로 깨진다. 홈·검색·에디터·관리자처럼 진입 경로마다 예산을 나눈다. 코드 스플리팅이 있는 Vite·Webpack·Next.js 환경에서는 라우트 청크 + 공유 vendor를 구분해 측정한다.
| 경로 예시 | 초기 JS 상한(압축) | 비고 |
|---|---|---|
| 마케팅 랜딩 / | 120~170KB | 인터랙션 적음. 히어로 이미지가 LCP 주인인 경우 많음 |
| 로그인·회원가입 | 150~200KB | 폼·검증 라이브러리 비대화 주의 |
| 대시보드 홈 | 200~280KB | 차트·테이블은 동적 import 기본 |
| 리치 에디터·지도 | 별도 청크, 초기 로드 제외 | 첫 페인트 후 로드. 진입 시 스켈레톤 |
숫자는 예시일 뿐이다. 팀 베이스라인을 Lighthouse·번들 분석기로 한 번 찍고, 현재 값 + 10~15%를 임시 상한으로 걸면 “지금보다 나빠지지 않게” 게이트가 생긴다. 이후 스프린트마다 상한을 조금씩 내린다.
JS를 줄였는데도 LCP가 안 떨어지면 거의 항상 이미지·폰트·서버 응답이다. 미디어 예산은 디자이너·마케터와 공유해야 한다. 개발자만 알면 캠페인 배너 한 장이 예산을 깨뜨린다.
분석·광고·채팅·A/B·히트맵 스크립트는 “마케팅이 넣었다”로 끝나면 프론트 예산이 무너진다. 각 태그에 소유 팀, 로드 시점, 실패 시 제품 동작, 제거 조건을 붙인다. 예산 표에 행이 없는 스크립트는 프로덕션 금지에 가깝다.
보안 헤더·환경변수 쪽 배포 점검은 프로덕션 배포 체크리스트와 겹친다. 성능 예산 문서에 CSP·동의 배너 링크를 걸어 두면, 태그 추가 PR이 보안·성능 두 리뷰를 한 번에 탄다.
문서만 있고 파이프라인이 침묵하면 예산은 곧 무시된다. 최소 구성은 세 갈래다. (1) 번들 크기 비교 (2) Lighthouse CI 점수·메트릭 (3) 필요 시 size-limit·bundlesize 같은 패키지 단위 상한.
Lighthouse CI는 assert 설정으로 성능 점수, LCP, CLS 등을 실패 처리할 수 있다. 로컬과 CI URL(프리뷰 배포)을 같게 맞추고, CPU 스로틀·네트워크 프리셋을 문서에 고정한다. “내 노트북에선 녹색” 논쟁을 줄이는 유일한 방법이다.
아래 목록을 PR 템플릿 체크박스로 붙여도 된다. 전부 필수는 아니다. 해당 없음이면 이유를 한 줄 쓴다.
초과가 나왔을 때 — “나중에 최적화” 한 줄로 머지하지 않는다. (1) 같은 PR에서 상쇄 (2) 기능 플래그로 기본 off (3) 예산 상향은 제품·디자인 합의 + 만료일 있는 예외 티켓. 세 가지 중 하나가 없으면 보류가 기본이다.
하루 만에 완벽한 예산을 만들 필요는 없다. 아래 순서를 캘린더에 박으면 된다.
프레임워크가 Next.js라면 라우팅·캐싱·SEO와 성능이 한 묶음이다. App Router 프로덕션 체크리스트의 성능 항목을 이 예산 표의 “구현 체크” 열로 옮기면 문서가 하나로 모인다.
임계값·도구 옵션은 버전에 따라 달라질 수 있다. 배포 게이트에 넣기 전에 공식 문서의 최신 assert 키와 필드 지표 정의를 확인한다.
다릅니다. Core Web Vitals는 사용자 경험 지표(LCP·INP·CLS)의 표준 집합이고, 성능 예산은 그 지표와 자원 상한(JS kB, 이미지, 서드파티 등)을 팀 규칙으로 묶은 운영 장치입니다. Vitals만 보면 “왜 나빠졌는지” 자원 쪽 설명이 빠지기 쉽습니다.
이상적인 교과서 숫자보다 현재 프로덕션 측정값 스냅샷을 기준으로 잡습니다. 지금 값에서 10~15% 여유를 둔 상한을 걸고, 회귀를 막은 뒤 스프린트마다 조금씩 내립니다. web.dev도 작은 예산부터 시작하라고 안내합니다.
랩 점수는 환경에 민감합니다. CI에서는 CPU·네트워크 프리셋, URL, 로그인 상태를 고정하고, 허용 회귀 폭(점수·ms)을 문서화하세요. 최종 사용자 경험은 RUM 75퍼센타일로 별도 추적하는 편이 안전합니다.
TTFB·API 지연은 LCP·INP에 영향을 줍니다. 프론트 예산 문서에 “서버 p95 응답 목표” 한 줄을 넣고, 백엔드 SLO와 링크하세요. 프론트만 조이면 원인 규명이 늦어집니다.
규모가 작으면 Lighthouse CI 전체보다 “초기 JS 상한 하나 + 이미지 히어로 용량 하나”만 있어도 충분합니다. 의존성을 자주 추가하는 단계일수록 작은 게이트가 나중에 큰 리팩터를 줄입니다.
스킵 라벨과 만료일을 의무화하세요. 이슈에 초과량, 영향 URL, 상쇄 계획, 담당자를 남기고, 다음 스프린트 백로그에 상환 작업을 넣습니다. 무기한 예외는 예산 폐지와 같습니다.
