벤치마크 — 성능 기준선 및 회귀 감지
사용 시점
- PR 전후로 성능 영향을 측정할 때
- 프로젝트의 성능 기준선을 설정할 때
- 사용자가 "느리다"고 보고할 때
- 출시 전 — 성능 목표를 충족하는지 확인할 때
- 현재 스택을 대안과 비교할 때
작동 방식
모드 1: 페이지 성능
브라우저 MCP를 통해 실제 브라우저 지표를 측정합니다:
1. 각 대상 URL로 이동
2. Core Web Vitals 측정:
- LCP (Largest Contentful Paint) — 목표 < 2.5초
- CLS (Cumulative Layout Shift) — 목표 < 0.1
- INP (Interaction to Next Paint) — 목표 < 200ms
- FCP (First Contentful Paint) — 목표 < 1.8초
- TTFB (Time to First Byte) — 목표 < 800ms
3. 리소스 크기 측정:
- 전체 페이지 무게 (목표 < 1MB)
- JS 번들 크기 (목표 < 200KB gzipped)
- 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.2s | 1.4s | +200ms | 경고: 경고 |
| 번들 | 180KB | 175KB | -5KB | ✓ 개선 |
| 빌드 | 12s | 14s | +2s | 경고: 경고 |
출력
기준선을 .ecc/benchmarks/ 디렉토리에 JSON으로 저장합니다. Git으로 추적되어 팀이 기준선을 공유할 수 있습니다.
통합
- CI: 모든 PR에 대해
/benchmark compare실행 - 배포 후 모니터링을 위해
/canary-watch와 함께 사용 - 출시 전 전체 점검 목록을 위해
/browser-qa와 함께 사용