폴리이엔엠 디지털 미디어 연구

HTML 글로벌 속성 "is"를 아시나요? 44

최신 프론트엔드 프레임워크가 유행하면서 순수 웹 컴포넌트에 대한 관심도 높아지고 있습니다. 그중에서도 기존 HTML 태그의 기능을 쉽게 확장할 수 있는 강력한 글로벌 속성인 is 애트리뷰트에 대해 알아보고자 합니다.

글로벌 속성 'is'란 무엇인가요?

is 속성은 개발자가 직접 정의한 '사용자 정의 내장 요소(Customized Built-in Elements)'를 표준 HTML 요소에 연결할 때 사용하는 글로벌 속성입니다. 완전히 새로운 커스텀 태그(예: <my-button>)를 독자적으로 만드는 것(Autonomous custom elements)과 달리, <button>이나 <input>처럼 이미 존재하는 표준 HTML 요소의 고유한 동작과 접근성을 그대로 유지하면서 원하는 새로운 기능이나 스타일만 덧붙일 수 있게 해줍니다.

코드 예시로 이해하기

예를 들어 클릭하면 특별한 애니메이션이 동작하는 버튼이 필요하다고 가정해 봅시다. 가장 먼저 JavaScript의 클래스 문법을 사용해 HTMLButtonElement를 상속받는 클래스를 정의하고 이를 CustomElementRegistry에 등록합니다.

class CustomButton extends HTMLButtonElement {
	constructor() {
		super();
		this.addEventListener("click", () => {
			alert("커스텀 버튼이 클릭되었습니다!");
		});
	}
}

// "custom-button"이라는 이름으로 등록하며, 
// 기존 button 요소를 확장한다는 옵션을 명시합니다.
customElements.define("custom-button", CustomButton, { extends: "button" });

컴포넌트 등록이 완료되었다면, HTML 파일에서는 일반적인 <button> 태그에 is 속성만 추가하여 손쉽게 사용할 수 있습니다.

<button is="custom-button">나만의 버튼</button>

이 방식의 가장 큰 장점은 스크린 리더 같은 보조 기기가 이 요소를 완벽하게 일반 버튼으로 인식한다는 것입니다. 버튼의 disabled 속성이나 폼(Form) 제출 기능 등, 수십 년간 다듬어진 기존 웹 표준 요소들이 제공하는 혜택을 온전히 누릴 수 있습니다.

사파리(Safari)의 반대와 지원 거부

이렇게 유용하고 강력한 기능이지만, 치명적인 단점이 하나 가로막고 있습니다. 웹 표준을 브라우저에 사실상 구현하고 주도하는 3대 주요 표준 단체 및 벤더(구글 크롬, 모질라 파이어폭스, 애플 사파리) 중 유독 애플의 사파리(WebKit 엔진)만이 'is' 속성의 지원을 단호하게 거부하고 있다는 점입니다.

애플과 WebKit 팀이 'is' 속성을 반대하는 주된 이유는 다음과 같이 3가지로 압축할 수 있습니다. ¹

• 파서 아키텍처의 복잡성 증대: 일반적인 HTML을 파싱하여 DOM을 생성하는 브라우저 엔진 입장에서 볼 때, 특정 요소가 중간에 다른 성질의 클래스로 상속받아 동적으로 업그레이드 되는 과정은 렌더링 파이프라인의 구조를 불필요하게 꼬이게 만들고 브라우저 최적화를 방해합니다.
• 선언적 문법의 모호함: HTML은 태그의 이름만 보더라도 그 요소가 무엇인지 직관적으로 알 수 있어야 한다는 철학을 가집니다. 그러나 <button is="custom-button">처럼 작성될 경우, 태그는 일반 버튼이지만 실제 동작은 'custom-button'에 종속되므로 혼란을 초래한다고 주장합니다.
• 사용자 정의 요소로 대체 가능: WebKit 팀은 굳이 복잡한 is 속성을 도입하지 않더라도, <my-button>과 같은 사용자 정의 요소(Autonomous custom elements)만으로도 개발자가 원하는 컴포넌트 기능을 충분히 구현할 수 있다는 완고한 입장을 고수하고 있습니다.

사파리의 입장에 반대하는 목소리

사파리의 이런 완고한 태도에 대해 프론트엔드 커뮤니티와 크롬, 파이어폭스 등 다른 브라우저 벤더들은 강하게 반발했습니다. 주요 반대 논리는 다음과 같습니다.

• 우아한 성능 저하(Graceful Degradation): <button is="custom-btn"> 방식은 구형 브라우저에서 스크립트 에러가 나더라도 최소한 평범한 '버튼'으로는 정상 동작합니다. 반면 독립적인 커스텀 태그 방식은 자바스크립트가 실패하면 브라우저가 인식하지 못하는 빈 태그로 전락해 접근성과 호환성이 훼손됩니다. ²
• 접근성의 막대한 손실: 기존 <button>이나 <input> 등 네이티브 요소는 브라우저 내장 접근성 트리를 자동 상속받습니다. 이를 포기하고 <my-button>을 직접 구축하면 개발자가 ARIA 속성과 키보드 이벤트를 수동으로 일일이 다시 구현해야만 합니다.
• 개발자 커뮤니티의 압도적 요구: 이러한 실용성 때문에 Interop 2025/2026 등 주요 웹 플랫폼 설문조사에서 '사용자 정의 내장 요소 지원'은 항상 개발자들이 가장 필요로 하는 기능 최상위권에 랭크됩니다. ³

사파리의 입장이 충분히 일리가 있는 이유

하지만 브라우저 엔진을 직접 개발하는 엔지니어들의 시각에서 보면, 사파리 측의 거부 명분 역시 아키텍처의 근본을 지키기 위한 일리 있는 주장입니다.

• 비동기적 파싱과 FOUC 현상 유발: 파서는 태그 이름을 보고 즉시 DOM 객체를 생성해야 하는데, is 속성을 사용하면 파싱 후 비동기적으로 스크립트가 로드되면서 커스텀 클래스로 '업그레이드'되는 기형적인 형태가 됩니다. 이는 렌더링 파이프라인에 레이스 컨디션을 유발하고, 스타일이 없는 콘텐츠가 번쩍이는 현상(FOUC)을 일으킵니다. ²
• 쉐도우 DOM 캡슐화 불가: 웹 컴포넌트의 핵심은 캡슐화이지만, 기존 요소의 확장은 태생적으로 쉐도우 루트를 부착할 수 없습니다. 캡슐화조차 불가능한 기술은 사실상 '이등 시민(Second-class)' 커스텀 요소에 불과하다는 것이 이들의 입장입니다. ²
• 구성적(Compositional) 폴백 철학 위배: 단일 요소의 속성을 변이시키는 방식 대신, <picture> 태그 내부에 <img>를 폴백으로 배치하는 것과 같이 자식 요소를 활용하는 구성적 접근이 올바른 HTML 아키텍처라고 강조합니다.

결론: 웹 생태계를 위한 새로운 대안의 모색

구글 크롬과 애플 사파리의 팽팽한 의견 대립 속에서, 웹 표준 커뮤니티는 is 속성의 논란을 우회하면서도 필요한 기능을 완벽히 구현할 수 있는 혁신적인 대안들을 도입하고 있습니다.

대표적으로 ElementInternals API와 FACE(Form-Associated Custom Elements) 스펙이 있습니다. 이를 통해 개발자는 is 속성을 사용하지 않는 순수 자율 컴포넌트 내부에서 attachInternals()를 호출함으로써, 브라우저의 접근성 객체 모델(AOM)에 직접 개입하고 웹 폼 전송 파이프라인 및 유효성 검증 로직에 네이티브 요소처럼 유기적으로 동화될 수 있게 되었습니다. ⁴

더 나아가 근본적인 네이티브 요소만의 '암묵적 내장 동작'까지 상속받기 위해, 최근 WHATWG에서는 ElementInternals.type = 'submit'과 같이 내부 타입을 명시하는 확장 제안이나 has="" 속성을 활용하여 기능(Behaviors)을 믹스인(Mix-in) 형태로 유연하게 조립하는 진보적인 상향식 구조가 논의되고 있습니다. ⁵⁶ 즉, 수많은 갈등을 딛고 웹 생태계는 브라우저 파서를 교란시키지 않으면서도 개발자에게 강력한 네이티브 권한을 부여하는 새로운 아키텍처의 시대로 우아하게 진화하고 있는 것입니다.