fix(perf): boundary perf 예산을 동일 작업량 baseline 대비 비율로 교체 (CI flake)

[hsleedevelop]

문제

tests/perf/boundary-checkpoint.test.mjs의 boundary performance가 GitHub Actions에서 무작위로 실패했다.
문서 전용 diff에서도 발생 → 변경 내용과 무관한 측정 방식의 결함.

깨지던 assertion은 상대 예산 coldMs - spawnFloorMs < 75. 분모가 bare node -e '' 스폰이라
스폰 비용 변동만 상쇄한다. 부하에서는 CLI 본체 작업(20 × 10KiB read+parse + ~20개 모듈 그래프)도
함께 느려지는데 그 작업량 비례 지연을 분모가 흡수하지 못한다.

max-parallel: 1 은 no-op — 측정으로 기각

원 가설은 "matrix 두 job 동시 실행 경합"이었으나 사실이 아니다. 러너 메타데이터로 확인
(로그 blob은 프록시 403이지만 JSON API는 열려 있다):

$ gh api repos/bd-makers/team-harness/actions/runs/32802292903/jobs
test (20)  runner_name="GitHub Actions 1000000304"  failure
test (18)  runner_name="GitHub Actions 1000000305"  success
runner_group_name="GitHub Actions" (hosted)

두 job은 서로 다른 hosted VM에서 돈다 — 하드웨어를 공유하지 않으므로 직렬화는 무의미하다.
실패 job이 18 ↔ 20을 번갈아 오간 것도 VM별 독립 노이즈에 부합한다.
진짜 부하원은 hosted 러너(2 vCPU) 물리 호스트의 noisy neighbour이며 제거 불가다.
→ 측정을 부하 불변으로 만드는 수밖에 없다. 워크플로우는 건드리지 않았다.

수정: 차(ms) → 비(배수)

CPU starvation 하에서 wall time ≈ 작업량 × 감속계수 s:

형태	결과
차 (W_cold − W_base)·s	s가 그대로 남는다
비 (W_cold·s)/(W_base·s)	s가 소거된다

분모는 CLI가 읽는 것과 같은 21개 파일을 같은 방식으로(stat→readFile utf8→JSON.parse,
양쪽 순차·boundary 동시) 읽는 baseline이며 src/를 import 하지 않는다.

부수적으로 모든 스폰 shape에 untimed warmup을 추가했다. 부하 중 첫 cold 샘플이 453–541ms로 튀어
(정상 60–90ms) 500ms 절대 상한 자체가 flake 원인이었다(541.3ms 관측). bare 스폰에 이미
적용돼 있던 논리를 대칭 적용한 것이다.

절대 상한 500/800ms는 값 그대로 유지했다. src/ 변경 없음 — 테스트 파일 1개.

증거 (동일 부하·동일 반복 횟수)

	수정 전	수정 후
부하 16 (12코어) × 10	6 PASS / 4 FAIL	10 / 0
부하 24 × 10	6 PASS / 4 FAIL	10 / 0
부하 36 (3배 초과구독) × 8	—	8 / 0

비율은 부하를 3배까지 올려도 더 나빠지지 않았다(cold 1.20–1.96) — 불변성이 실제로 성립한다.

회귀 탐지력은 오히려 강해졌다

runBoundaryCheck에 정확한 CPU burn을 주입한 mutation test (FAIL = 회귀를 잡음):

주입	신규 가드	구 가드
+30ms	PASS	PASS
+40ms	FAIL ✅	PASS ❌
+50ms	FAIL ✅	PASS ❌
+60ms	FAIL ✅	FAIL ✅

탐지 임계 +58ms → +35ms. "green 될 때까지 경계를 푼" 것이 아니다.

검증

• npm test (node 20): 415 tests, 0 fail
• node 18은 이 머신에서 검증하지 못했다 — 설치 차단(프록시), docker 미설치, 로컬 바이너리 없음.
  node 18에 대해 확보한 것은 CI green 1회뿐이고 부하 특성은 미측정이다. 위 경고가 그대로 적용된다.
• node 24는 통과하지만 checkpoint 비율이 무부하에서도 3.07이다(node 20은 1.68). 원인을 분해했다:
  70ms 전부가 sh + exec 구간이고, 같은 경로를 --version으로 재면 오버헤드가 거의 0 →
  shebang·PATH·sh 스폰 모두 원인이 아니며 파이프 stdin을 sh 경유로 상속받았을 때의 node 24 처리가
  남는 유일한 차이다. (이는 테스트가 아니라 배포되는 hook 자체의 관측이며 후속 후보로 남겼다.)
  CHECKPOINT_BUDGET은 선제적으로 올리지 않았다 — 이상치는 새 버전(24)에서 나타났고
  node 18은 더 오래된 버전이며, 기존 CI 실패 4건은 전부 cold assertion이었다.
  근거 없이 완화하는 것은 이 작업이 피하려던 실패 양식이다.
• 외부 read-only 리뷰(codex) 실행 · 결과와 판별을 artifact ## Reviews에 기록.
  P2 1건(warmup이 cold-cache 회귀 탐지를 지운다)은 검증 결과 부분 타당 —
  지적한 커버리지는 환경 지배적이었고(그 자체가 flake 발생원), 시작 회귀 탐지는
  node가 매 프로세스마다 모듈 그래프를 재컴파일하므로 사라지지 않는다(실측: warmup 이후
  전 샘플에서 ~9ms 초과분 유지). 실행 가능한 절반(steady-state 명세 분리)만 반영했다.

⚠️ CI green은 필요조건일 뿐 충분조건이 아니다. 관측된 flake 빈도에서 green 1회는 증거가
되지 못한다 — 진짜 증거는 위 부하 재현 수치다.

작업 문서: docs/chad/boundary-perf-invariant/

🤖 Generated with Claude Code

https://claude.ai/code/session_01S79BMNyq1gqXXcEQw1vsnx