2025년 기준, 평균 웹 페이지는 1.7MB의 JavaScript를 로드한다. 그런데 실제로 실행되는 코드는 그 중 35%에 불과하다. 100개 사이트를 직접 감사한 데이터가 이를 확인해준다. 나머지 65%는 그냥 네트워크를 타고 사용자 기기에 도착해 조용히 LCP와 TTI를 갉아먹는다. 이건 프레임워크의 문제도, 라이브러리의 문제도 아니다. 설계 결정의 부재가 만들어낸 결과다.
여기에 AI 코드 생성 도구를 얹으면 상황이 더 흥미로워진다. Claude Code나 Copilot이 컴포넌트를 뚝딱 만들어낼 때, 그 코드는 번들 크기를 고려하지 않는다. moment.js 전체를 import해도 작동은 한다. lodash 풀 패키지를 끌어와도 타입 에러는 없다. AI는 '작동하는 코드'를 만들지만, '가벼운 코드'를 만드는 것은 여전히 설계자의 몫이다. 그리고 AI가 코드를 생성하는 속도가 빨라질수록, 이 설계 공백은 더 빠르게 쌓인다.
번들 크기 감사 데이터는 구체적인 수치로 말한다. Tree Shaking만으로 평균 15~25% 감소. Route-Based Code Splitting을 적용한 12개 라우트 React 앱에서 초기 번들이 28% 줄었고, LCP는 4.2초에서 2.8초로 단축됐다. 의존성 감사에서는 더 극적인 차이가 난다. moment.js(67KB) 대신 date-fns(13KB, tree-shaken), lodash 전체(71KB) 대신 lodash-es 개별 import, dayjs(2KB)로 날짜 포맷팅 90%를 커버할 수 있다. 단 하나의 의존성 교체로 50~150KB의 gzip 절감이 가능하다는 것이 200개 이상 프로젝트 감사의 결론이다. Brotli 압축까지 더하면 500KB짜리 파일이 118KB가 된다. 이 숫자들은 추상적인 권고가 아니라 측정 가능한 설계 결과다.
이 맥락에서 이번 주 Next.js의 업데이트는 작지 않은 신호다. prefetch가 공개 API로 정식 안정화됐다. 그동안 내부 구현에 손을 대야 했던 navigation-heavy 앱 개발자들에게는 실질적인 API 안정성 확보다. force-runtime이 allow-runtime으로 이름을 바꾼 것도 단순한 리네이밍이 아니다. '런타임을 강제한다'에서 '런타임을 허용한다'로의 의미 전환—이것은 프레임워크가 번들 전략에서 개발자의 의도를 더 명확하게 요구하겠다는 시그널이다. Stream Cache Components의 캐시 미스 시 개발 서버 재시작 제거는 반복 개발 루프의 마찰을 줄여준다. 이 세 가지 변경은 모두 같은 방향을 가리킨다. 더 예측 가능하고, 더 의도적인 번들 전략을 프레임워크 레벨에서 지원하겠다는 것.
MCP(Model Context Protocol) 논의가 여기서 연결된다. MCP는 AI 모델이 외부 도구와 데이터에 연결하는 방식을 표준화한다. 프로덕트 팀의 언어로 번역하면, AI가 접근할 수 있는 것의 범위가 설계 결정의 대상이 된다는 뜻이다. Claude Code가 실제 DynamoDB 테이블 구조 없이 쿼리를 생성했다가 50만 행짜리 테이블에 풀 스캔을 날린 사례—72시간 동안 4,700만 RCU를 소모한 그 사고—는 이 문제의 번들 버전이기도 하다. AI는 컨텍스트 없이 '작동하는 것처럼 보이는 코드'를 만들고, 그 결과는 운영 환경에서 터진다. 번들도 마찬가지다. AI가 생성한 컴포넌트가 어떤 의존성을 끌어오는지, 어떤 라우트에서 어떤 청크가 로드되는지는 AI가 아니라 개발자가 설계해야 할 영역이다.
실무에서 번들 전략을 설계한다는 것은 거창한 일이 아니다. package.json에 "sideEffects": false 한 줄을 추가해 번들러가 적극적으로 dead code를 제거하도록 하는 것, npx bundle-phobia로 새로운 의존성을 추가하기 전에 크기를 먼저 확인하는 습관, webpack-bundle-analyzer나 vite-plugin-visualizer로 배포 전 번들 구성을 시각화하는 것. 이 세 가지를 루틴으로 만드는 것만으로도 AI가 생성한 코드가 번들에 쌓이는 속도를 상당히 늦출 수 있다. Tree Shaking, Code Splitting, 의존성 감사를 한 스프린트 안에 적용하면 JavaScript 페이로드가 50~70% 줄어든다는 것이 감사 데이터의 결론이다.
AI가 코드를 더 빠르게 만들수록, 개발자의 역할은 '무엇을 만드느냐'에서 '무엇이 번들에 들어가야 하는가'를 결정하는 쪽으로 이동한다. 프레임워크는 더 예측 가능한 API를 제공하고, MCP는 AI에게 더 많은 컨텍스트를 주고, 번들 분석 도구는 결과를 측정한다. 하지만 그 사이에서 '어떤 코드가 사용자에게 전달되어야 하는가'를 판단하는 것은 여전히 사람의 설계다. Core Web Vitals 점수는 알고리즘이 매기지만, 그 점수를 만드는 번들 구조는 개발자가 의도적으로 짜야 한다. AI 시대의 프론트엔드 성능 최적화는 도구의 문제가 아니라 설계 의도의 문제다.