프론트엔드 성능 예산을 릴리즈 게이트로 운영하는 법
성능 최적화는 보통 Lighthouse 점수를 올리는 일로 시작하지만, 실무에서는 그보다 더 중요한 질문이 있습니다.
이 변경을 배포해도 되는지 누가, 어떤 기준으로 판단할 것인가?
이번 글은 성능 예산을 문서가 아니라 릴리즈 게이트로 운영하는 방법을 정리합니다. CDN/전송 계층 관점은 CloudFront의 숨은 힘, 배포 전 체크 흐름은 릴리즈 준비도 체크리스트와 함께 보면 연결이 좋습니다.
성능 예산을 숫자로만 두면 실패한다
성능 예산이 실패하는 가장 흔한 이유는 기준이 너무 추상적이기 때문입니다.
- “빠르게 만든다”
- “번들 크기를 줄인다”
- “이미지를 최적화한다”
이런 문장은 리뷰에서 거의 힘을 쓰지 못합니다. PR 작성자는 통과 기준을 모르고, 리뷰어는 취향으로 지적하게 됩니다.
운영 가능한 성능 예산은 아래처럼 판단 기준이 명확해야 합니다.
| 항목 | 기본 기준 | 차단 조건 |
|---|---|---|
| LCP | 2.5초 이하 | 주요 랜딩/상세 화면에서 3초 초과 |
| INP | 200ms 이하 | 입력 지연 재현 가능 |
| CLS | 0.1 이하 | 이미지/폰트 로딩 후 레이아웃 흔들림 |
| JS budget | route 단위 증가량 추적 | 이유 없는 30KB 이상 증가 |
| image policy | 크기/format 지정 | 원본 대형 이미지 직접 사용 |
핵심은 절대값 하나가 아니라 변경량입니다. 기존 화면이 이미 느리다면 이번 PR이 더 악화시키는지부터 봐야 합니다.
PR에서 확인할 최소 체크리스트
성능 리뷰는 다음 네 가지 질문으로 시작하면 충분합니다.
1) 이 변경은 클라이언트 JavaScript를 늘리는가
Next.js App Router에서는 서버 컴포넌트로 남겨도 되는 UI가 클라이언트 컴포넌트로 이동하면서 비용이 커지는 경우가 많습니다.
- 이벤트가 필요한 컴포넌트만
use client경계 안에 있는가 - fetch/cache 책임이 화면 컴포넌트에 섞이지 않았는가
- 대형 라이브러리를 route 단위로 분리했는가
서버/클라이언트 판단 기준은 Next.js Server vs Client Components 실무 가이드를 기준선으로 두면 안정적입니다.
2) 이미지는 화면 크기와 로딩 우선순위를 알고 있는가
이미지 최적화는 format보다 정책이 먼저입니다.
- above-the-fold 이미지는 우선순위가 명확한가
- 썸네일과 본문 이미지를 같은 원본으로 쓰지 않는가
- width/height 또는 안정적인 aspect ratio가 있는가
- decorative 이미지는 접근성 tree에서 제외되는가
이미지는 LCP와 CLS를 동시에 망가뜨리기 때문에, 성능과 접근성 체크를 분리하지 않는 편이 좋습니다.
3) 인터랙션 비용을 측정했는가
INP는 “렌더가 됐다”가 아니라 “사용자 입력에 반응했다”를 봅니다.
- 검색/필터/탭 전환에서 blocking work가 있는가
- 입력 이벤트마다 무거운 파싱이나 정렬이 도는가
- list virtualization 또는 deferred update가 필요한가
React 동시성 관점은 React Concurrent Rendering을 참고하면 실전 판단에 도움이 됩니다.
4) 실패 기준이 자동화되어 있는가
리뷰어가 매번 수동으로 성능을 떠올리면 오래 못 갑니다. 최소한 PR 템플릿에 아래 항목을 넣으세요.
## Performance Gate
- [ ] route bundle 증가량 확인
- [ ] LCP 후보 이미지/텍스트 확인
- [ ] 입력 지연이 있는 상호작용 확인
- [ ] CLS를 만들 수 있는 이미지/폰트/광고 영역 확인
- [ ] 예산 초과 시 이유와 후속 작업 링크 작성AI workflow에 붙이는 방법
AI 에이전트에게 “성능 최적화해줘”라고 요청하면 대개 피상적인 코드가 나옵니다. 대신 성능 예산을 컨텍스트로 고정하세요.
이 PR은 성능 예산을 지켜야 한다.
- 새 dependency 추가 전 대체안을 제시한다.
- client component 전환이 필요하면 이유를 적는다.
- 이미지에는 크기와 loading 정책을 명시한다.
- 검색/필터 로직은 입력 지연 가능성을 설명한다.
- 마지막에 성능 리스크 체크리스트를 작성한다.이 방식은 AI 코드리뷰 실무 적용 플레이북과 잘 맞습니다. 에이전트가 코드를 만드는 역할에 머물지 않고, 리뷰 가능한 근거까지 남기게 됩니다.
면접에서 설명할 때의 포인트
성능 경험을 면접에서 말할 때는 “Lighthouse 점수를 올렸다”보다 아래 구조가 더 강합니다.
- 화면별 성능 예산을 정했다.
- PR에서 변경량을 보게 했다.
- 예산 초과 시 차단/예외/후속 작업 기준을 만들었다.
- AI 산출물도 같은 기준으로 검증했다.
이 흐름은 구현 실력뿐 아니라 운영 품질을 보여줍니다. 프론트엔드 포트폴리오에서는 이 차이가 큽니다.