HTML의 귀환, 자바스크립트 피로가 만든 신호

HTML이 다시 동적 UI의 일부가 됐다

Chris Burnell의 "HTML Can Do That"은 최신 HTML이 예전에는 자바스크립트로 처리하던 기능을 얼마나 많이 흡수했는지 보여준다. 페이지에는 popover, dialog, grouped details, command와 commandfor, loading="lazy", hidden="until-found", datalist 같은 예제가 이어진다. 저자는 2026년 HTML Day에 한 시간 만에 만든 실험에서 출발했지만, 8월 20일 업데이트로 브라우저 구현과 접근성 문제를 함께 경고했다.

이 글이 AI 뉴스로 중요한 이유는 웹 표준 자체보다 개발 방식의 균형 때문이다. AI 코딩 도구는 빠르게 컴포넌트를 만들어내지만, 복잡한 상태 관리와 이벤트 핸들러를 과잉 생산하기 쉽다. 반대로 브라우저가 이미 제공하는 동작을 쓰면 코드가 줄고, 리뷰해야 할 표면도 줄어든다. Kitesurf, 에이전트 브라우저를 다시 쓰다가 실행 환경의 격리를 말한다면, 이 흐름은 애초에 만들어야 할 자바스크립트 양을 줄이는 쪽이다.

네이티브 기능은 에이전트에게 좋은 제약이다

MDN의 popover 문서는 light dismiss와 Esc 닫기 같은 동작을 브라우저가 관리한다고 설명한다. dialog 문서도 모달의 의미와 초점 처리를 별도 요소로 다룬다. 이런 기능은 사람이 직접 개발할 때도 편하지만, 코딩 에이전트에게는 더 큰 의미가 있다. 프레임워크별 모달 구현을 매번 새로 만들지 않아도 되기 때문이다.

에이전트가 잘못 만든 UI 코드는 대개 작은 이벤트 누락에서 시작한다. 닫기 버튼은 있지만 키보드 닫기가 빠지고, 바깥 클릭은 되지만 초점 이동이 깨지고, 스크롤 잠금이 모바일에서 어긋난다. 네이티브 HTML은 이런 문제를 모두 없애지는 못하지만 기본 경로를 제공한다. Bonsai, 에이전트 UI가 배워야 할 상태 기계가 UI 상태의 명시성을 강조했다면, HTML 네이티브 기능은 상태 기계의 일부를 플랫폼에 맡기는 전략이다.

접근성은 줄어든 코드의 면죄부가 아니다

Burnell이 직접 강조했듯이 네이티브 기능도 접근성 요구를 자동으로 끝내지는 않는다. Can I Use의 popover 지원표를 보면 최신 브라우저 지원은 넓어졌지만, 지원 여부와 사용자 경험 품질은 다르다. W3C WCAG 2.2 빠른 참조가 말하는 이름, 역할, 값, 키보드 접근, 텍스트 대체 요구는 여전히 제품 책임이다.

특히 datalist나 date input처럼 브라우저별 UI 편차가 큰 요소는 한국 서비스에서 더 조심해야 한다. 금융, 공공, 커머스처럼 접근성 심사를 받는 조직이라면 "표준 요소라서 괜찮다"가 아니라 "표준 요소를 실제 보조기술에서 테스트했다"가 되어야 한다. AI가 생성한 코드도 마찬가지다. 생성 프롬프트에 "접근성 고려"를 넣는 것보다 플랫폼 기능을 쓰고, Playwright나 axe 같은 검증을 붙이고, 실제 키보드 플로우를 확인하는 편이 낫다.

한국 개발팀이 읽어야 할 운영 신호

이 흐름은 프런트엔드 채용과 아키텍처에도 영향을 준다. 리액트, Vue, Svelte 같은 프레임워크가 사라진다는 뜻이 아니다. 대신 프레임워크 위에 얹는 사내 컴포넌트가 브라우저 기능을 얼마나 존중하느냐가 유지보수 비용을 좌우한다. AI 에이전트가 PR을 더 많이 만들수록, 사내 디자인 시스템은 "멋진 추상화"보다 "표준 기능을 깨지 않는 얇은 래퍼"에 가까워져야 한다.

OpenJDK AI 금지, 오픈소스의 새 방화벽는 생성 코드의 출처와 품질 통제를 다뤘다. 웹 UI에서는 출처보다 더 직접적인 문제가 있다. 코드가 너무 많으면 검증할 수도 없다. HTML의 귀환은 복고가 아니라 AI 코딩 시대의 비용 절감 방법이다.

자주 묻는 질문

Q1: 이제 자바스크립트를 덜 써야 하나요?

A: 무조건 덜 쓰자는 이야기가 아니다. 브라우저가 이미 안정적으로 제공하는 동작은 먼저 검토하고, 제품 고유의 상태와 비즈니스 로직에 자바스크립트를 쓰는 편이 좋다.

Q2: popover와 dialog는 바로 운영에 써도 되나요?

A: 기능 지원은 좋아졌지만 대상 브라우저, 보조기술, 모바일 키보드 흐름을 테스트해야 한다. 접근성 체크 없이 도입하면 커스텀 구현과 다른 종류의 문제가 생긴다.

Q3: AI 코딩 도구와 무슨 관련이 있나요?

A: 에이전트가 생성할 코드 양을 줄이고, 표준 동작을 활용하게 만들면 리뷰와 회귀 테스트 부담이 줄어든다.

Q4: 디자인 시스템에는 어떻게 반영해야 하나요?

A: 사내 Button, Modal, Combobox가 표준 HTML 요소와 속성을 감싸는지, 아니면 모든 동작을 다시 만드는지부터 점검해야 한다.

Q5: 한국 기업의 실무 우선순위는 무엇인가요?

A: 핵심 폼, 모달, 메뉴, 검색 UI에서 네이티브 대안을 실험하고 접근성 테스트 결과를 컴포넌트 문서에 함께 남기는 것이다.