OpenAI가 코딩 에이전트 Codex의 수요 폭발에 대응해 월 100달러짜리 중간 요금제를 출시했다. 3개월 만에 주간 활성 사용자 300만 명, 사용량 전월 대비 70% 급증. AI 코딩 도구가 개발자의 일상 깊숙이 파고드는 속도는 이제 수치로도 확인된다. GitHub Copilot, Gemini Code Assist와의 경쟁이 격화되며 AI 코딩 시장은 '누가 더 많은 코드를 더 빠르게 생성하느냐'의 전장이 됐다.
그런데 여기서 프론트엔드 개발자로서 불편한 질문 하나를 꺼내야겠다. AI가 생성한 코드, 번들 사이즈는 누가 책임지나?
dev.to에 올라온 한 에이전시 개발자의 사례가 이 질문을 날카롭게 짚어낸다. 그는 Next.js 기반 클라이언트 사이트를 감사하다가 모바일 Lighthouse 점수가 70점대 초반에 묶여 있다는 걸 발견했다. 번들 분석기를 열자 범인이 바로 드러났다. Framer Motion, 프로젝트 전체에서 가장 큰 단일 의존성. 그런데 실제 사용처는 고작 여섯 개의 애니메이션이었다. 스크롤 페이드인, 모바일 네비게이션 슬라이드, 호버 효과. 40KB 이상의 JavaScript가 매 방문자에게 전송되고 있었다.
결론부터 말하면, 그는 Framer Motion을 프로젝트에서 완전히 걷어냈다. 대체재는 거창하지 않다. CSS 트랜지션과 IntersectionObserver, 두 가지 브라우저 네이티브 API가 전부다. 스크롤 페이드인은 opacity와 transform의 CSS 트랜지션으로, 모바일 네비게이션 슬라이드는 cubic-bezier 커브로, 호버 효과는 당연히 :hover 선택자로. npm 패키지 하나 추가 없이 동일한 시각적 결과를 냈다. 결과는 인상적이었다. 번들 27% 감소, 모바일 Lighthouse 점수 72→89점, Total Blocking Time 약 180ms 단축, Time to Interactive 0.4초 개선. 데스크탑 점수는 100점 유지.
이 사례가 단순한 '라이브러리 교체 팁'으로 끝난다면 기사로 쓸 이유가 없다. 핵심은 이 비대함이 어디서 시작됐는가다. AI 코딩 도구로 빠르게 프로토타이핑하고 컴포넌트를 생성할 때, 도구는 'Framer Motion으로 fade-in 추가해줘'라는 지시에 군말 없이 import 구문을 심는다. 도구는 코드를 완성하는 것이 목표지, 번들 사이즈를 최소화하는 것이 목표가 아니기 때문이다. Codex든 Copilot이든, 현재의 AI 코딩 에이전트는 '작동하는 코드'와 '가벼운 코드' 사이의 트레이드오프를 개발자만큼 예민하게 감지하지 못한다.
이것이 OpenAI의 Codex 요금제 확장과 맞물릴 때 나타나는 역설이다. 더 많은 개발자가 더 많은 코드를 AI로 생성할수록, 검토되지 않은 의존성이 코드베이스에 조용히 쌓인다. Framer Motion은 훌륭한 라이브러리다. 레이아웃 애니메이션, AnimatePresence의 언마운트 트랜지션, 복잡한 드래그 인터랙션에서는 대체 불가다. 하지만 AI가 '일단 동작하는' 코드를 뽑아낼 때 가장 먼저 손에 쥐는 도구가 되면, 정작 그 라이브러리가 필요한 맥락인지 따지는 판단은 사라진다. 스프링 물리 엔진이 필요 없는 페이드인 하나를 위해 40KB짜리 레이싱카 엔진을 싣는 일이 반복된다.
프론트엔드 개발자로서 이 흐름에서 찾아야 할 역할은 명확하다. AI는 생성 속도를 책임지고, 번들 품질은 여전히 개발자가 설계해야 한다. 구체적으로는 세 가지 습관이 중요해진다. 첫째, AI가 생성한 컴포넌트에 새 npm 패키지가 포함됐다면 반드시 '이 라이브러리가 없으면 CSS로 해결 가능한가'를 먼저 물어야 한다. 둘째, @next/bundle-analyzer나 Bundlephobia를 CI 파이프라인에 통합해 의존성 증가를 코드 리뷰 단계에서 가시화해야 한다. 셋째, 팀의 AI 코딩 가이드라인에 '애니메이션 라이브러리 사용 기준'을 명시해야 한다. CSS로 충분한 케이스와 JS 애니메이션 라이브러리가 정당화되는 케이스를 구분하는 기준이 없으면, AI는 항상 더 무거운 쪽을 선택할 것이다.
AI 코딩 도구의 구독 비용이 올라가는 것보다 더 주목해야 할 것은, 그 도구로 생산되는 코드가 실제 사용자에게 어떤 비용을 청구하는가다. 모바일 Lighthouse 70점대 사이트에서 이탈하는 사용자는 요금제 구조를 모른다. 그들은 느린 화면 앞에서 그냥 뒤로 간다. 27%의 번들 감소가 17포인트의 모바일 점수 상승으로 직결된 사례는, Core Web Vitals가 추상적인 지표가 아니라 실제 전환율과 연결된 비즈니스 지표임을 다시 한번 확인시켜 준다.
AI가 코드를 짜는 속도는 계속 빨라질 것이다. Codex의 성장 곡선이 증명하듯, 이 흐름은 되돌릴 수 없다. 하지만 그 코드가 실제로 사용자 경험을 개선하는지, 아니면 번들을 조용히 비대하게 만드는지를 판단하는 안목은 AI가 대체하지 못한다. 'CSS first, JS animation library only when CSS literally can't'라는 원칙은 오래된 규칙이 아니라, AI 코딩 도구 시대에 더욱 유효한 설계 철학이다. 번들 다이어트의 책임은, AI가 아무리 영리해져도 여전히 개발자 몫으로 남는다.