2026년 기준, 모바일 페이지의 JavaScript 중앙값은 646KB다. 이건 무거운 쪽 얘기가 아니다. 딱 중간이다. dev.to에 올라온 'HTML-First Websites Are Quietly Winning Again in 2026'은 이 숫자를 개발자 취향의 문제가 아니라 비즈니스 문제로 정의한다. 모바일 사이트의 절반 이상이 Core Web Vitals를 통과하지 못하고, 모바일 블로킹 타임은 전년 대비 50% 이상 증가했다. 그런데 여기서 불편한 질문 하나가 따라온다. 이 무게의 상당 부분을, 지금 우리는 AI에게 맡기고 있다는 것.
AI는 왜 항상 프레임워크부터 꺼내드는가
AI 코딩 에이전트의 근본적인 문제는 '틀린 코드'가 아니다. 컴파일되고, 실행되고, 심지어 잘 동작하는—그러나 구조적으로 과잉인 코드를 생성한다는 것이다. Flutter Agent Skills를 소개한 글에서 Dart·Flutter 팀이 직접 인정한 표현이 있다. '지식 격차(knowledge gap)'. LLM은 방대한 코드 데이터로 학습됐지만, 그 데이터의 상당수는 이미 deprecated된 패턴들이다. 모델은 '통계적으로 가장 흔한 답'을 돌려준다. 최신의 정답이 아니라.
프론트엔드 맥락으로 옮기면 이 문제는 더 선명해진다. AI에게 인터랙티브한 UI 컴포넌트를 만들어 달라고 하면, 가장 흔하게 돌아오는 것은 React 기반의 클라이언트 컴포넌트다. 아코디언이 필요한가? useState와 조건부 렌더링. 모달이 필요한가? 커스텀 훅과 포털. 폼 검증이 필요한가? 서드파티 라이브러리. 하지만 2026년 브라우저는 이미 <details>, <dialog>, 그리고 Constraint Validation API를 네이티브로 지원한다. AI가 불러온 번들은, 브라우저가 이미 탑재하고 있는 기능의 복사본인 경우가 많다.
'기본값의 저주'—AI는 가장 흔한 패턴을 학습한다
HTML-first 접근이 다시 주목받는 이유는 노스탤지어가 아니다. 단순한 브로셔 사이트, 랜딩 페이지, 블로그, 이커머스 카탈로그—이 범주의 사이트들이 SPA처럼 만들어지고 있기 때문이다. 그리고 그 관성을 AI가 가장 충실하게 재현한다. AI는 '이 프로젝트에 프레임워크가 필요한가?'를 묻지 않는다. 학습 데이터에서 가장 자주 등장한 패턴을 꺼낼 뿐이다.
AWS Agent Toolkit 소개 글이 정확히 같은 구조의 문제를 다룬다. AI 에이전트에게 S3 버킷 설정을 맡기면, 모델은 '기억에서' 정책을 작성한다. 그 기억은 오래됐다. 파라미터 이름이 바뀌었을 수 있고, 보안 기본값이 달라졌을 수 있다. 코드는 그럴싸해 보이고, 배포 단계에서야 실패한다. AWS 팀이 Agent Toolkit으로 해결하려 한 것—에이전트에게 '살아있는 문서'와 '검증된 절차'를 주는 것—은 프론트엔드 AI 워크플로우에도 동일하게 적용되어야 할 원칙이다.
Agent Skills가 가리키는 방향
Flutter 팀이 내놓은 Agent Skills의 핵심 메커니즘은 '프로그레시브 디스클로저'다. 에이전트가 모든 지식을 컨텍스트에 올리는 게 아니라, 작업이 매칭될 때 해당 플레이북만 로드한다. 이 발상은 HTML-first의 철학과 구조적으로 같다. 처음부터 전부 내려받지 말고, 필요할 때 필요한 것만. 번들도, 컨텍스트도, 같은 원리로 최적화된다.
문제는 이런 스킬셋이 아직 프론트엔드 성능 영역에서는 체계화되지 않았다는 점이다. Flutter와 AWS에는 팀이 직접 관리하는 공식 Agent Skills 레포가 있다. 하지만 '이 UI는 네이티브 HTML로 충분하다', '이 페이지는 서버 렌더링이 기본이어야 한다', '이 인터랙션에는 번들이 필요 없다'는 판단을 AI에게 가르치는 표준화된 플레이북은 아직 없다. 그 공백이 지금 AI 생성 프론트엔드 코드의 기본값을 무겁게 만드는 구조적 원인이다.
그래서 무엇을 해야 하는가
단기적으로는 AI에게 맥락을 강제하는 것이 현실적인 접근이다. AGENTS.md 또는 rules 파일에 렌더링 전략, JavaScript 사용 기준, 네이티브 HTML 우선 원칙을 명시적으로 정의해야 한다. '이 프로젝트는 콘텐츠 사이트다. 클라이언트 컴포넌트는 상태 관리가 명확히 필요한 경우에만 사용한다. 폼, 아코디언, 모달은 네이티브 HTML을 먼저 검토한다.' 이런 문장 하나가, AI가 꺼내드는 기본값을 바꾼다.
중기적으로는 프론트엔드 성능 중심의 Agent Skills 생태계가 필요하다. HTML-first 판단 기준, Core Web Vitals 영향 평가, 서버 컴포넌트 vs 클라이언트 컴포넌트 분기 로직—이것들이 검증된 플레이북 형태로 에이전트에게 주입될 수 있다면, AI 생성 코드의 기본 무게는 지금과 달라질 수 있다.
전망: AI는 배울 수 있지만, 가르쳐야 배운다
HTML-first가 2026년에 다시 주목받는 것은 트렌드의 역주행이 아니다. 브라우저의 네이티브 기능이 충분히 성숙했고, 과잉 번들의 비용이 측정되기 시작했고, AI라는 새로운 변수가 그 과잉을 자동화하기 시작했다는 신호다. AI 코딩 도구는 빠르게 좋아지고 있지만, '이 맥락에서 JS는 필요 없다'는 판단은 여전히 사람이 설계해서 넘겨줘야 한다. 그 설계를 생략하면, AI는 오늘도 646KB짜리 중간값 페이지를 성실하게 만들어낼 것이다.