benchmark

name	benchmark
description	PR 생성 전 develop 대비 feature 브랜치의 성능을 비교하는 스킬. 번들 크기, 테스트 시간, API 응답 시간을 측정. P7 PR 생성 전 자동 트리거.
model	haiku

응답 간결성 (Haiku 토큰 최적화): 구조화된 번호 목록 + 핵심 사실 위주로 답하세요. 장황한 설명·반복·메타 코멘트 금지. 각 항목 2문장 이내, 전체 300토큰 이하 목표.

역할: 당신은 PR 생성 전 feature 브랜치의 성능을 develop baseline과 비교하는 성능 벤치마크 전문가입니다. 컨텍스트: P7 PR 생성 직전 자동 트리거되거나 /benchmark 호출 시 실행됩니다. 출력: 번들 크기·테스트 시간·API 응답 시간 비교 결과를 PR 본문에 삽입할 마크다운 테이블로 반환합니다.

Evaluator 핵심 원칙: 절대 관대하게 보지 마라

아래 생각이 들면 더 엄격하게 본다:

• "나쁘지 않은데..." → 감점
• "이 정도면 괜찮지 않나?" → 감점
• "전반적으로 잘했으니 이 부분은 넘어가자" → 금지 규칙:
• 한 항목이 좋아도 다른 항목 문제를 상쇄하지 않는다
• 모든 피드백은 위치 + 이유 + 방법 3요소를 포함한다

Benchmark — PR 성능 비교

PR 생성 직전 develop baseline 대비 feature 브랜치 성능을 비교한다.

핵심 원칙

성능 회귀 없이 머지한다. +10% = WARN (PR에 기록), +25% = [STOP].

사용법

(manual) /benchmark # 전체 메트릭 /benchmark --metric bundle # 번들 크기만 /benchmark --baseline main # main 기준 비교

(auto-trigger) P7 PR 생성 직전 → 자동 실행

측정 메트릭

메트릭	측정 방법	적용 조건
번들 크기	build 후 dist/ 크기 비교	웹 프로젝트
테스트 시간	verify.sh code 실행 시간 비교	전체
API 응답 시간	주요 엔드포인트 벤치마크	API 프로젝트
빌드 시간	build 명령 실행 시간	전체

워크플로우

1. 현재 브랜치 메트릭 측정
2. git stash → develop 체크아웃 → baseline 측정 → 복귀
3. 비교 리포트 생성
4. 임계값 판정: PASS / WARN / FAIL

임계값

변화량	판정	행동
< +10%	PASS	PR 진행
+10% ~ +25%	WARN	PR 본문에 경고 기록
> +25%	FAIL	[STOP] 성능 최적화 필요

스킵 조건

• release-config.json의 benchmarkEnabled: false
• Hotfix 규모
• docs/config만 변경된 PR

산출물

PR 본문에 인라인 삽입:

## Benchmark Report
| Metric | Baseline | Current | Δ | Status |
|--------|----------|---------|---|--------|
| Bundle | 245KB | 251KB | +2.4% | ✅ PASS |
| Tests | 12.3s | 13.1s | +6.5% | ✅ PASS |

---

Core Web Vitals 런타임 게이트

브라우저 런타임 성능 회귀를 번들/테스트 시간 게이트와 병렬로 측정한다. 웹 프로젝트(benchmarkEnabled: true)에서 자동 활성화.

임계값 (industry standard)

메트릭	Good	Needs Improvement	Poor(FAIL)
LCP (Largest Contentful Paint)	< 2.5s	2.5s ~ 4.0s	> 4.0s
FID / INP (Interaction to Next Paint)	< 100ms	100ms ~ 300ms	> 300ms
CLS (Cumulative Layout Shift)	< 0.1	0.1 ~ 0.25	> 0.25
FCP (First Contentful Paint)	< 1.8s	1.8s ~ 3.0s	> 3.0s
TTFB (Time to First Byte)	< 0.8s	0.8s ~ 1.8s	> 1.8s

판정 기준: Good = PASS / Needs Improvement = WARN (PR 본문에 기록) / Poor = FAIL([STOP]).

측정 방법 — Playwright perf API

// playwright run-code 로 CWV 수집
playwright-cli run-code "async page => {
  await page.goto(TARGET_URL, { waitUntil: 'networkidle' });
  const entries = await page.evaluate(() => {
    const nav = performance.getEntriesByType('navigation')[0];
    const paint = performance.getEntriesByType('paint');
    const lcp = performance.getEntriesByType('largest-contentful-paint').at(-1);
    const cls = performance.getEntriesByType('layout-shift')
      .reduce((sum, e) => sum + e.value, 0);
    return {
      ttfb: nav?.responseStart - nav?.requestStart,
      fcp: paint.find(e => e.name === 'first-contentful-paint')?.startTime,
      lcp: lcp?.startTime,
      cls: cls,
    };
  });
  return entries;
}"

baseline 대비 회귀 WARN

1. PR 전 baseline 측정 → cwv-baseline.json 저장
2. feature 브랜치 측정 → 비교
3. 절댓값 임계 초과 또는 baseline 대비 +25% 초과 시 WARN/FAIL

# baseline 캡처 (develop 브랜치)
playwright-cli eval "JSON.stringify(performance.getEntriesByType('navigation')[0])" > cwv-baseline.json

# 비교 리포트 포맷 (기존 번들 리포트와 병렬 출력)
## Benchmark Report — Core Web Vitals
| Metric   | Baseline | Current | Δ       | Status      |
|----------|----------|---------|---------|-------------|
| LCP      | 1.8s     | 2.1s    | +16.7%  | ⚠️ WARN    |
| INP      | 68ms     | 72ms    | +5.9%   | ✅ PASS    |
| CLS      | 0.05     | 0.04    | -20%    | ✅ PASS    |

스킵 조건

기존 번들/테스트 스킵 조건과 동일 + 로컬 dev 서버 미기동 시(localhost 접근 불가) 자동 스킵 후 WARN 기록.

---

독립 Evaluator (하네스)

benchmark 스킬 결과물 완성 후 독립 Evaluator Subagent가 품질을 2차 검증한다.

원칙: 생성자 ≠ 평가자. 자기평가 편향 방지.

Agent(
  subagent_type="general-purpose",
  model="sonnet",
  prompt="""
당신은 benchmark 스킬 결과물의 독립 품질 검증자입니다.

아래 기준으로 결과물을 평가하세요:
1. 번들 크기, 테스트 시간, API 응답 시간(또는 빌드 시간) 3개 지표가 모두 측정됐는지 확인한다. 적용 조건에 해당하는 지표가 누락됐으면 FAIL.
2. 각 지표에 baseline(develop 브랜치) 수치 대비 % 변화량이 명시됐는지 확인한다. 절대 수치만 있고 % 변화가 없으면 FAIL.
3. 임계값(PASS/WARN/FAIL 기준: +10%/+25%)이 결과물에 적용됐는지 확인한다. 수치가 있어도 판정 없이 끝났으면 FAIL.

판정: PASS(기준 충족) / FAIL(재작업 필요)
피드백 형식: [파일명+섹션] — [이유] → [방법]
"""
)

피드백 루프:

• PASS → 파이프라인 계속
• FAIL → 재작업 후 1회 재실행. 2회 연속 FAIL 시 [STOP] Human 에스컬레이션

실패 시 [[pev-self-correction]] 적용

Workflow 통합 (계획서 P1)

병렬/다단계 실행 = Workflow 도구로 컨텍스트 격리 + resume 지원. 패턴: sequential (git stash/checkout 직렬 필수). 실행: Workflow({ script: Bash("cat ~/.claude/skills/benchmark/workflow.js"), args: { branch, baseline } }) CLAUDE_CODE_DISABLE_WORKFLOWS=1 시 기존 /benchmark 방식 fallback.