# HTML 스펙에서 XSLT 언급 제거 제안
> Clean Markdown view of GeekNews topic #22617. Use the original source for factual precision when an external source URL is present.
## Metadata
- GeekNews HTML: [https://news.hada.io/topic?id=22617](https://news.hada.io/topic?id=22617)
- GeekNews Markdown: [https://news.hada.io/topic/22617.md](https://news.hada.io/topic/22617.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-08-20T10:03:26+09:00
- Updated: 2025-08-20T10:03:26+09:00
- Original source: [github.com/whatwg](https://github.com/whatwg/html/pull/11563)
- Points: 2
- Comments: 1
## Topic Body
- HTML 표준 문서에서 **XSLT 관련 언급을 삭제**하려는 Pull Request가 제안된 상황
- 제안자는 크롬, 파이어폭스, 사파리 등 주요 브라우저에 관련 **구현 버그가 보고**되었고, 테스트 및 문서화 이슈도 진행 중이라고 설명
- 반대 의견에서는 **기존 웹사이트 호환성 문제**와 `` 제거 시 XML 문서가 깨지는 **가독성 문제**를 지적
- 일부 개발자는 XSLT가 여전히 **정부 문서, RSS, 임베디드 환경** 등에서 사용된다고 강조
- 대형 브라우저 벤더 중심의 결정이 **웹의 개방성과 역사적 다양성 축소**로 이어질 수 있다는 우려 제기
---
### Pull Request 개요
- PR 제목: **Remove mentions of XSLT from the html spec**
- 제안자: [mfreed7](https://github.com/mfreed7)
- 대상: [whatwg/html:main](https://github.com/whatwg/html/tree/main)
- 관련 이슈: [#11523](https://github.com/whatwg/html/issues/11523)
- Chromium, Gecko, WebKit 모두에 관련 **구현 버그 리포트 존재**
- [MDN 문서](https://developer.mozilla.org/en-US/docs/Web/XML/XSLT) 및 [HTML AAM](https://w3c.github.io/html-aam/) 등 관련 자료 업데이트 예정
### 주요 반대 의견
#### gucci-on-fleek (2025-08-15)
- **사용 통계와 웹사이트 규모**를 고려해야 한다는 주장
- 대형 사이트는 업데이트 가능하지만, **소규모/개인 사이트**는 수십 년째 유지되지 않아 영구적 **호환성 깨짐** 우려
- `XSLTProcessor()` 제거는 JS 기능만 제한되지만, `` 제거 시 **XML 문서가 전혀 표시되지 않는 문제** 발생
- 이전 HTML 구식 기능(`<font>`, `<align>`, `<xmp>`)은 여전히 동작하지만, 이번은 문서 자체를 깨뜨리는 **전례 없는 변화**라는 지적
- **오래된 아카이브, 대학 사이트** 등 중요한 자료 접근이 차단될 수 있는 위험성 강조
#### nomis (2025-08-18)
- XSLT의 **구체적 사용 예시** 제시
- [미국 의회 법안 XML](https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.xml)
- [govinfo.gov 법안 데이터](https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BILLS-119hr400ih.xml)
- [XMPP 확장 스펙 문서](https://xmpp.org/extensions/xep-0182.xml)
- 개인적 사용 사례
- **복잡한 XML 데이터를 HTML 테이블로 변환**
- **메모리 제약이 있는 마이크로컨트롤러**에서 동적 XML을 정적 XSLT로 변환
- **libxml2를 통째로 포함하는 JS polyfill은 비현실적**이며, 브라우저 지원 제거는 사실상 재구현 강제라는 비판
#### jonsterling (2025-08-18)
- 브라우저 벤더가 웹 플랫폼을 독점적으로 정의하는 현실을 비판
- XSLT는 여전히 **다양하고 창의적인 웹 활용**에 기여 중이며, 제거는 **Open Web 약화**로 이어질 것이라는 우려
- "웹은 우리 모두의 것"이라는 원칙을 강조하며, 역사와 다양성을 존중할 필요 주장
### 찬성 및 후속 조치
- **domenic (2025-08-19)**: 긍정적 반응과 함께 DOM 스펙의 XSLT 언급도 업데이트 필요성을 지적
- **mfreed7 (2025-08-19)**: DOM 스펙에도 별도 PR을 제출하겠다고 답변
### 정리
- XSLT 제거는 **브라우저 단순화 및 최신화 노력**의 일환으로 제안된 변화
- 그러나 반대 측은 **기존 문서 호환성, 정부/학술 데이터 접근성, 오픈웹 다양성** 훼손을 우려
- 이번 논의는 단순한 기술적 선택을 넘어, **웹 표준 결정 권한이 누구에게 있는지**라는 철학적 논쟁까지 이어지는 상황
## Comments
### Comment 42681
- Author: neo
- Created: 2025-08-20T10:03:26+09:00
- Points: 1
###### [Hacker News 의견](https://news.ycombinator.com/item?id=44952185)
- 몇 가지 주목할 점이 있음
- 이번 결정은 Chrome만의 단독 행동이 아니며, [이슈 트래킹](https://github.com/whatwg/html/issues/11523)과 관련 표준 회의 기록에서 모든 주요 브라우저의 대표자들이 지지 의사를 보임을 확인할 수 있음
- 최근 안건 역시 Mozilla 엔지니어가 제안함
- PR 제출이 바로 머지된다는 의미는 아니며, 체크되지 않은 과제들도 꽤 남아 있음
- 하지만 여러 브라우저 벤더가 동의하는 상황에서 머지될 가능성이 높음
- [XSLT를 웹 플랫폼에서 제거할지 고민하는 이슈](https://github.com/whatwg/html/issues/11523)는 커뮤니티 의견 수렴을 위한 게 아닌 HTML 스펙 유지보수자들을 위한 논의 이슈임
- 이 이슈는 Chrome 엔지니어가 올렸지만, Mozilla 엔지니어들이 여러 차례 이 주제를 회의에서 제기했고 이미 벤더 합의가 있었다는 점이 큼
- 심각한 보안 취약점이 [발견된 바](https://www.offensivecon.org/speakers/2025/ivan-fratric.html) 있음
- libxslt의 메인테이너도 [직접 사임](https://gitlab.gnome.org/GNOME/libxml2/-/issues/913)했음
- Chrome이라는 단어를 제목에서 빼줬음
- 원래 제출된 제목은 "Chrome intends to remove XSLT from the HTML spec"였음
- Chrome의 텔레메트리 데이터에 따르면 실제로 XSLT를 사용하는 웹사이트가 거의 없음
- 제안으로 인해 전체 웹에 큰 영향이 있는 건 아니란 점을 최소한 데이터로 확인 가능함
- 과거 Mozilla와 Google(Chrome팀)에서 근무했던 개발자임
- Chrome/Blink, Safari/Webkit, Firefox/Gecko 모두 XSLT 제거를 지지하는 건 알겠지만, 두 프로젝트는 자원이 부족하고, 한 곳은 새로운 기능을 무리하게 밀어넣는 경향이 강함
- 사파리와 파이어폭스 개발자가 이런 변화를 반길 이유도 있음
- 중요한 건 '권위 있는 사람들이 좋은 생각이라 생각하는가'가 아니라, '이 아이디어가 웹 플랫폼과 수십억 사용자에게 부정적인 영향을 줄 것인가'임
- 수십억 명 중 0.1%만 의존해도 상당한 규모임
- 아무도 쓰지 않으면 polyfill이 존재할 이유도 없음
- 만약 새로운 기능을 추가하려면 반드시 기존 기능을 없애야 하는 제로섬 게임으로 몰고 가는 것은 바람직하지 않음
- 구글은 충분한 자본과 인력이 있음에도 XSLT 지원을 일부러 안 하기로 선택하는 것임
- 여러 벤더가 동의한다고 해서 즉시 추진되는 사례가 종종 있었음
- confirm/prompt 제거도 그랬으나 결국 무기한 보류됨
- 구글에서 공식적으로 제휴된 기능 제거 프로세스 문서가 있음
[Google feature removal doc](https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?usp=drivesdk)
- "벤더 단독 지지"가 실제 사용 현황을 제대로 검토하지 않았음
- 내가 읽은 두 스레드를 보면 구글이 피드백을 요청했는데, 피드백은 거의 다 "하지 말라"였음
- 하지만 구글은 "의견 고마워, 그래도 할게!"라는 반응을 보였음
- 만약 이슈가 보안 때문이라면, 오픈소스에 지원을 하거나, 더 안전한 라이브러리로 교체하거나, JS 샌드박스 내에서 유지 등 다양한 대안이 있었지만 대부분 무시당함
- XSLT 3.0 같은 최신 버전 지원 요청도 꾸준히 있었으나 반영되지 않았음
- XSLT는 오픈 웹을 지지하는 기술임에도, 구글은 10년 전부터 지원을 줄이고 방치하며 점유율 하락을 이유로 제거 시도를 지속해왔음
- 최근 XSLT가 다시 인기를 얻고 있는 시점에, 오픈 경쟁자 등장 전에 죽이려는 의도가 느껴짐
- [관련 이슈](https://github.com/whatwg/html/issues/11523)
- 많은 피드백이 "하지 마라"였다는 주장에 대해, 해당 스레드는 악의적 댓글, 비방 등으로 일찍 잠겼음
- "이건 좋은 생각"이라는 의견은 평소 잘 달리지 않아서 반대 의견만 많은 것처럼 보일 수 있음
- 모두가 극단적인 언행을 해서 토론이 정리된 것이고, 스스로 자초한 일임
- 만약 "하지 마세요"라는 의견들이 실사용자거나 꼭 필요한 이유를 설명할 수 없다면, 개발팀이 무시하는 것은 합리적임
- 피드백 요청은 단순 찬반투표가 아님
- XSLT 3.0을 JS/wasm 샌드박스로 옮겨 지원할 수만 있다면 좋겠음
- 약간의 성능 저하는 있겠지만, 양쪽 장점을 모두 취할 수 있음
- XML에는 버전 관리 스키마, 네임스페이스 등 특성상 통합이 비교적 수월함
- Angular 같은 js 프레임워크와 달리 신뢰성 높은 데이터 계약이 가능함
- XML 패밀리의 성숙함 덕분에 전문 툴이 많아, 실제로는 XML/XSD를 텍스트로 직접 다루지 않아도 됨
- 구글은 "질문 형"으로 웹에 무슨 일이 벌어질지 미리 알려주는 식임
- 이전 관련 스레드 소개
- [XSLT 제거 주제 스레드](https://news.ycombinator.com/item?id=44909599)
- [XSLT - 웹을 위한 네이티브, 제로 설정 빌드 시스템](https://news.ycombinator.com/item?id=44393817)
- 관련 이슈로 플래그 처리된 다른 스레드도 있음
- [Google is killing the open web, today](https://news.ycombinator.com/item?id=44949857)
- 브라우저가 특정 템플릿 엔진(XSLT)에 내장 지원을 할 필요가 있는지 의문임
- Jinja 같은 텍스트 엔진이 아닌데, JS/wasm으로 재구현도 가능함
- 지금 브라우저들은 너무 무겁고, 신규 엔진 개발이 힘듦
- "미니멀 브라우저"를 위한 더 간단한 표준(기본 태그, 레이아웃 등)만 있었으면 함
- WebAudio, Canvas 등도 wasm 모듈로 구현 가능함(그리고 이렇게 하면 핑거프린팅도 방지할 수 있음)
- XSLT는 (특정 엔진이 아닌) 템플릿 엔진에 대한 "스펙"임, 다양한 구현체가 존재함
- Mozilla는 libxslt 대신 [transformiix](https://web.mit.edu/ghudson/dev/nokrb/third/firefox/extensions/transformiix/docs/readme.html) 사용
- Jinja는 단순 텍스트 작업이고, XSLT는 노드 레벨에 작동해서 훨씬 우수함
- JS 변환은 XSLT 네이티브 변환보다 훨씬 느리고, 결과 캐싱도 어려움
- XSLT를 구식 취급하는 시각을 나도 이해는 하지만, 지난 20년간 성능 면에서 비밀 병기로 잘 써왔음
- 구글은 결국 AMP 같은 대안으로 문제를 덮으려 들 가능성 높음
- 브라우저가 무거운 건 구글 탓임
- XSLT는 언어(spec)이지 엔진이 아님
- JS/wasm으로의 구현 변경은 내부 구현 문제이지, 언어를 웹 플랫폼에서 없앨 때 일어나는 일은 아님
- 오디오나 캔버스는 브라우저의 근본적인 I/O 기능임, wasm으로 옮기면 성능과 호환에 심각한 문제 발생
- 오디오의 일부는 wasm blob으로 옮길 수 있겠지만, 전체를 이전하는 건 힘듦
- 캔버스 컨텍스트나 WebGL 등은 GPU와의 직접 통합이 핵심이라 wasm으로 실현 불가임
- 결국 이런 기능들은 사실상 이미 기본 원시 API라서, 양보할 수 없는 영역임
- 낡은 XSLT 코드를 wasm으로 패키징해서 구버전 사이트 깨짐 없이 호환할 아이디어도 논의됨
- 실제로도 내부적으로 검토했지만 하지 않기로 결정함
- 아주 소수만 사용하는 웹과 거리가 먼 기능은 제거 대상이 될 수 있다고 생각함
- 하지만 보안 취약점을 명분으로 삼는 것은 찬성하지 않음
- 메모리 세이프 패키지 유무조차 확인하지 않은 상태에선 설득력이 떨어짐
- 실제 사용률이 0.001% 수준이라는 주장 있음
- HTML 스펙의 기본 약속을 깨는 일은 굉장히 중대한 사안임
- 논의가 이 점을 깊이 다루지 않는 게 오히려 놀라움
- HTML은 "이건 HTML이야. 신뢰해도 돼"라는 약속이었지만, 이제는 "지금만 HTML일 뿐, 앞으로도 그렇다는 보장은 없어"가 됨
- XSLT 제거 논리라면 다른 오래된 기술들도 계속 잘릴 수 있음
- 결국 웹의 '롱테일'을 끊어내겠다는 제안임
- 향후 추가된 각종 웹 기술이 또 롱테일이 되어 더 많은 제거 대상이 생길 것이란 점도 고민 필요함
- 오래된 미디어와 소프트웨어 지원 관련해선 언젠가는 이식, 에뮬레이션, 아카이브 등으로 해결할 시기가 온다고 봄
- 변화에 대비할 충분한 시간과 도구 제공과 점진적 복잡성 누적을 피하는 균형이 필요함
- 실제 PR에서 삭제된 부분을 보면 HTML에 XSLT 지원을 요구하는 명시적 규정은 없어 보임
- 단순히 브라우저 지원 문제에 대한 반응이 크다는 점 정도임
- PR 자체는 의외로 짧음
- WHATWG가 HTML을 "Living Standard"(살아있는 표준)로 규정하면서, 실질적으론 더 이상 구현 표준이 아니라 브라우저 벤더들이 현재 작업 중인 상태를 공유하는 역할임
- 그래서 HTML5 같은 버전 표기도 없애고, 오로지 "HTML"만 쓰게 됨
- [Living Standard FAQ](https://whatwg.org/faq#living-standard)
- [HTML standard FAQ](https://github.com/whatwg/html/blob/main/FAQ.md#html-standard-faq)
- 아이러니하게도 HTML/CSS/브라우저 스펙에 엄청난 양의 기능을 밀어넣은 대표적인 것도 바로 Google임
- 만약 구글이 "브라우저는 가벼워야 하며 이상한 것들은 JS 라이브러리에 맡기는 게 맞다"를 일관되게 옹호했다면 이번 조치도 이해할 만했겠지만, 전혀 그렇지 않음
- FTP 지원 제거 이후부터 XSL의 운명은 이미 예견됨
- 브라우저들은 공격 표면 축소를 최우선으로 삼는 경향이 있음
- 다음 제거 후보는 SVG SMIL 애니메이션 속성, MathML 등 XML 관련 기능이 될 것 같단 생각임
- [관련 스레드](https://news.ycombinator.com/item?id=43880391)
- SMIL은 특정 애니메이션 시작/종료 타이밍을 기반으로 순차적 애니메이션 제어를 할 수 있는데, CSS 애니메이션은 아직 이 부분이 부족함
- CSS는 계산을 이용한 타이밍 외엔 방법이 없음
- Chromium도 한때 SMIL 제거 의지를 밝힌 적 있으나, CSS가 충분하지 않았기 때문에 너무 성급했었음
- 그 여파로 SMIL 관련 각종 안내문 등이 업데이트 없이 방치됨
- 공격 표면을 줄이는 것이 과연 좋은 것인지 나쁜 것인지 질문하고 싶음
- 기술자들과 일반 사용자가 우선순위가 다르긴 함
- FTP 기능 제거가 언제 이루어진 것인지 궁금함
- 아직 주소창에서 ftp://로 접속이 되는 것으로 알고 있음
- Blink와 WebKit의 XSLT 구현은 매우 비효율적임
- 전체 문서를 문자열로 바꿨다 다시 파싱하는 형태라서, 사용자 공간 라이브러리도 충분히 비슷한 성능을 낼 수 있을 듯함
- [Chromium XSLT 구현 예시1](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/xml/xslt_processor_libxslt.cc;l=312;drc=b8271edbc28fc426d4af05f5878c00c11bc6020f)
- [Chromium XSLT 구현 예시2](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/xml/xslt_processor.cc;l=131;drc=936810fb4d0e0b979b156d5325a52e5b6c40b088)
- [Webkit XSLTProcessor 구현](https://github.com/WebKit/WebKit/blob/65b2fb1c3c4d0e85ca39026e6d25a24638340f3c/Source/WebCore/xml/XSLTProcessorLibxslt.cpp#L266)
- Mozilla는 자체 구현([xslt 엔진](https://github.com/mozilla-firefox/firefox/tree/5f99d536df020fc1e909179d06a9bac1e6900ae1/dom/xslt/xslt))을 씀
- 호환성 문제는 MathML처럼 외부 개발자가 각 브라우저별 구현을 기여하는 접근이 대안일 듯함
- 이번 결정이 아쉽지만, 더 현대적인 XSLT 통합에 노력을 쏟지 않은 게 더 안타까움
- 사용은 불편했지만 브라우저에서 조금만 더 진화했다면 React 같은 프레임워크에 필적할 경쟁자가 될 수도 있었음
- XML은 대기업의 복잡성만 없었다면 표준 자체는 매우 강력하고, 멋진 기술이었음
- XSLT를 활용해 작고 간단한 xml/데이터를 html로 바로 변환하는 게 정말 좋았음
- 선택된 항목만 다르게 표시하는 작은 기능만 추가됐다면 정적 문서까지 다양한 활용이 가능했을 것으로 아쉬움
- @whatwg가 토론이 "과열됐다"며 해당 이슈를 협업자 한정으로 잠갔다고 함
- 보기엔 꽤 합리적이고 차분했는데, 특정 벤더에 우호적이냐에 따라 ‘과열’의 기준이 달라지는 건 아닐까 싶음
- "과열됐다"는 표현은 종종 반대 의견을 다루기 싫다는 뜻으로 해석됨
- Reddit 등 다른 커뮤니티도 마찬가지임
- 실제로 그 아래 남아있는 1개의 댓글은 Google Chrome 소속 개발자가 "좋은 일 하셨다"고 남긴 것
- 약간 보기 민망한 느낌임
- 이슈 트래커에 문제 제기성 욕설, 음모론, 정치적 메시지 등 쏟아진 사례를 언급함
- 이런 식이면 생산적 논의 자체가 불가능해지며, 저장소 관리자들이 신속하게 토론을 막을 수밖에 없음
- 해당 저장소의 토론 잠금 조치는 실은 Apple 직원이 내린 것이라고 들었음
- 하지만 사람들은 이 이슈를 제기한 Google 직원의 책임으로 돌린다 함
- 구글이 최근 커뮤니티 의견 수렴을 내세워 열린 토론을 했지만, 그 후 모든 의견을 무시하고 관철시키려 하고 있음
- [관련 이슈](https://github.com/whatwg/html/issues/11523)
- 구식 웹 요소에 관한 전반적 고민이 필요함
- 내 경우 예전 웹페이지도 계속 제대로 작동해서 얻는 가치가 큼
- HTML/JS가 호환성 지켜온 덕분에 수십 년 된 페이지조차 TLS 인증서만 붙이면 여전히 정상임
- 하지만 모든 유산 기술을 영원히 지원할 수는 없는 일이기도 함
- Flash도 결국 에뮬레이터(Ruffle)를 통해 추억의 게임이나 사이트를 경험하는 식으로 넘어갔음
- 장기적으로는 구형 렌더링에 특화된 전용 브라우저나 에뮬레이터 사용도 대안이 될 수 있음
- 이미 이를 위한 [XSLT polyfill 확장](https://chromewebstore.google.com/detail/xslt-polyfill/hlahhpnhgficldhfioiafojgdhcppklm?authuser=0&hl=en&pli=1)이 생겼음
- Chrome은 이를 공식 배송하거나 유지보수하기를 원하지 않음
- Ruffle과 매우 유사한 상황임