벤치마크 — 성능 기준선 및 회귀 탐지은(는) 무엇을 하나요?
사용 시기
- PR 전후에 성능 영향을 측정할 때
- 프로젝트의 성능 기준선을 설정할 때
- 사용자가 "느리다"고 보고할 때
- 출시 전 — 성능 목표를 달성했는지 확인할 때
- 현재 스택을 대안과 비교할 때
작동 방식
모드 1: 페이지 성능
브라우저 MCP를 통해 실제 브라우저 지표를 측정합니다.
1. 각 대상 URL로 이동
2. 핵심 웹 바이탈 측정:
- LCP (최대 콘텐츠풀 페인트) — 목표 2.5초 미만
- CLS (누적 레이아웃 이동) — 목표 0.1 미만
- INP (상호작용에서 다음 페인트까지) — 목표 200ms 미만
- FCP (첫 번째 콘텐츠풀 페인트) — 목표 1.8초 미만
- TTFB (첫 바이트까지의 시간) — 목표 800ms 미만
3. 리소스 크기 측정:
- 전체 페이지 무게 (목표 1MB 미만)
- JS 번들 크기 (목표 200KB gzip 미만)
- CSS 크기
- 이미지 무게
- 서드파티 스크립트 무게
4. 네트워크 요청 수 계산
5. 렌더링 차단 리소스 확인
모드 2: API 성능
API 엔드포인트를 벤치마킹합니다.
1. 각 엔드포인트를 100번 호출
2. 측정: p50, p95, p99 지연 시간
3. 추적: 응답 크기, 상태 코드
4. 부하 테스트: 10개의 동시 요청
5. SLA 목표와 비교
모드 3: 빌드 성능
개발 피드백 루프를 측정합니다.
1. 콜드 빌드 시간
2. 핫 리로드 시간 (HMR)
3. 테스트 스위트 실행 시간
4. TypeScript 검사 시간
5. 린트 시간
6. Docker 빌드 시간
모드 4: 전후 비교
변경 전후에 실행하여 영향을 측정합니다.
/benchmark baseline # 현재 지표를 저장
# ... 변경 수행 ...
/benchmark compare # 기준선과 비교
출력 예시:
| 지표 | 변경 전 | 변경 후 | 변화 | 판정 |
|---------|---------|---------|-------|--------|
| LCP | 1.2초 | 1.4초 | +200ms| ⚠ 경고 |
| 번들 | 180KB | 175KB | -5KB | ✓ 개선 |
| 빌드 | 12초 | 14초 | +2초 | ⚠ 경고 |
출력
기준선은 .ecc/benchmarks/ 디렉토리에 JSON으로 저장됩니다. Git으로 추적되므로 팀이 기준선을 공유할 수 있습니다.
통합
- CI: 모든 PR에서
/benchmark compare실행 /canary-watch와 함께 사용하여 배포 후 모니터링/browser-qa와 함께 사용하여 출시 전 전체 점검 목록 작성