size-limit 게이트가 실제 번들 크기를 못 재고 있었다 — 47배 오차

디자인시스템 패키지에 Tooltip·Popover를 만들면서 외부 라이브러리(Floating UI) 도입을 검토했다. 번들이 얼마나 늘어나는지 확인하려고 CI의 size-limit 게이트 수치를 봤는데, 라이브러리를 넣어도 숫자가 거의 안 움직였다.

수치가 이상했다. 라이브러리 하나가 통째로 들어왔는데 몇 바이트만 늘어난다는 건 말이 안 됐다.

원인 추적: 진입점 하나만 재고 있었다

@size-limit/file 플러그인은 지정한 진입점 파일 하나의 디스크 크기만 잰다. 우리 빌드(tsup)는 공통 코드를 별도 chunk로 분리하는 구조였다. 그래서 진입점 파일은 껍데기만 남고, import로 딸려오는 chunk는 측정에서 전부 빠지고 있었다.

게이트 7개가 전부 초록이었지만, 실제 소비 앱이 받는 코드량과는 무관한 숫자였다.

왜 그동안 안 드러났나

지금까지는 순수 구현 컴포넌트만 추가해서 용량이 크게 늘 일이 없었다. 게이트는 항상 통과했고, 아무도 의심하지 않았다. 외부 라이브러리를 처음 도입하려던 시점에서야 숫자가 안 늘어나는 게 이상해서 발견했다.

해결: preset-small-lib으로 교체

@size-limit/preset-small-lib으로 교체했다. 이건 esbuild로 실제 번들링한 뒤 brotli 압축해서 잰다. 진입점만 재는 게 아니라 딸려오는 chunk를 전부 포함한다. 임계값 8개를 실측 기준으로 재설정했다.

결과

• 게이트가 실제 소비량을 측정하게 됐다 (index 10.78 kB · Button 8.46 kB, brotli)
• Tooltip·Popover를 도입하면 index가 17.86 kB로 늘어나 게이트에 걸린다 — 의도한 동작이다. 이제 용량 증가를 의식적으로 승인하게 된다.
• 팀에 공유했던 기존 패키지 용량 수치가 전부 틀렸다는 것도 함께 알렸다.

정정한 것도 기록에 남긴다

MR 본문에 처음엔 "게이트가 실제 변화를 잡아냈다"고 썼다. styles.css가 6.56 → 6.38 kB로 줄어든 걸 보고 다른 커밋의 영향이라고 판단했기 때문이다.

근거 없는 주장이었다. 해당 커밋은 그 시점에 develop에 없었다. 실제 원인은 측정 방식 차이(minify 유무)였다. MR에서 스스로 철회하고 정정 기록을 남겼다.

같은 날 다른 두 가지 문제도 함께 발견했다.

• 배포된 토큰의 알파값이 사라져 있었다
• 재현 안 되는 버그를 쫓다가 CI 게이트 부재를 발견했다