▲

HTML 스펙에서 XSLT 언급 제거 제안

 (github.com/whatwg)
2P by GN⁺ 6일전 | ★ favorite | 댓글 1개
  • HTML 표준 문서에서 XSLT 관련 언급을 삭제하려는 Pull Request가 제안된 상황
  • 제안자는 크롬, 파이어폭스, 사파리 등 주요 브라우저에 관련 구현 버그가 보고되었고, 테스트 및 문서화 이슈도 진행 중이라고 설명
  • 반대 의견에서는 기존 웹사이트 호환성 문제와 <?xml-stylesheet?> 제거 시 XML 문서가 깨지는 가독성 문제를 지적
  • 일부 개발자는 XSLT가 여전히 정부 문서, RSS, 임베디드 환경 등에서 사용된다고 강조
  • 대형 브라우저 벤더 중심의 결정이 웹의 개방성과 역사적 다양성 축소로 이어질 수 있다는 우려 제기

Pull Request 개요

  • PR 제목: Remove mentions of XSLT from the html spec
  • 제안자: mfreed7
  • 대상: whatwg/html:main
  • 관련 이슈: #11523
  • Chromium, Gecko, WebKit 모두에 관련 구현 버그 리포트 존재
  • MDN 문서 및 HTML AAM 등 관련 자료 업데이트 예정

주요 반대 의견

gucci-on-fleek (2025-08-15)

  • 사용 통계와 웹사이트 규모를 고려해야 한다는 주장
    • 대형 사이트는 업데이트 가능하지만, 소규모/개인 사이트는 수십 년째 유지되지 않아 영구적 호환성 깨짐 우려
  • XSLTProcessor() 제거는 JS 기능만 제한되지만, <?xml-stylesheet?> 제거 시 XML 문서가 전혀 표시되지 않는 문제 발생
  • 이전 HTML 구식 기능(<font>, <align>, <xmp>)은 여전히 동작하지만, 이번은 문서 자체를 깨뜨리는 전례 없는 변화라는 지적
  • 오래된 아카이브, 대학 사이트 등 중요한 자료 접근이 차단될 수 있는 위험성 강조

nomis (2025-08-18)

  • XSLT의 구체적 사용 예시 제시
  • 개인적 사용 사례
    • 복잡한 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 제거는 브라우저 단순화 및 최신화 노력의 일환으로 제안된 변화
  • 그러나 반대 측은 기존 문서 호환성, 정부/학술 데이터 접근성, 오픈웹 다양성 훼손을 우려
  • 이번 논의는 단순한 기술적 선택을 넘어, 웹 표준 결정 권한이 누구에게 있는지라는 철학적 논쟁까지 이어지는 상황
▲
GN⁺ 6일전  [-]
Hacker News 의견

  • 몇 가지 주목할 점이 있음

    • 이번 결정은 Chrome만의 단독 행동이 아니며, 이슈 트래킹과 관련 표준 회의 기록에서 모든 주요 브라우저의 대표자들이 지지 의사를 보임을 확인할 수 있음

    • 최근 안건 역시 Mozilla 엔지니어가 제안함

    • PR 제출이 바로 머지된다는 의미는 아니며, 체크되지 않은 과제들도 꽤 남아 있음

    • 하지만 여러 브라우저 벤더가 동의하는 상황에서 머지될 가능성이 높음

    • XSLT를 웹 플랫폼에서 제거할지 고민하는 이슈는 커뮤니티 의견 수렴을 위한 게 아닌 HTML 스펙 유지보수자들을 위한 논의 이슈임

    • 이 이슈는 Chrome 엔지니어가 올렸지만, Mozilla 엔지니어들이 여러 차례 이 주제를 회의에서 제기했고 이미 벤더 합의가 있었다는 점이 큼

    • 심각한 보안 취약점이 발견된 바 있음

    • libxslt의 메인테이너도 직접 사임했음

    • 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

    • "벤더 단독 지지"가 실제 사용 현황을 제대로 검토하지 않았음

  • 내가 읽은 두 스레드를 보면 구글이 피드백을 요청했는데, 피드백은 거의 다 "하지 말라"였음

    • 하지만 구글은 "의견 고마워, 그래도 할게!"라는 반응을 보였음

    • 만약 이슈가 보안 때문이라면, 오픈소스에 지원을 하거나, 더 안전한 라이브러리로 교체하거나, JS 샌드박스 내에서 유지 등 다양한 대안이 있었지만 대부분 무시당함

    • XSLT 3.0 같은 최신 버전 지원 요청도 꾸준히 있었으나 반영되지 않았음

    • XSLT는 오픈 웹을 지지하는 기술임에도, 구글은 10년 전부터 지원을 줄이고 방치하며 점유율 하락을 이유로 제거 시도를 지속해왔음

    • 최근 XSLT가 다시 인기를 얻고 있는 시점에, 오픈 경쟁자 등장 전에 죽이려는 의도가 느껴짐

    • 관련 이슈

    • 많은 피드백이 "하지 마라"였다는 주장에 대해, 해당 스레드는 악의적 댓글, 비방 등으로 일찍 잠겼음

    • "이건 좋은 생각"이라는 의견은 평소 잘 달리지 않아서 반대 의견만 많은 것처럼 보일 수 있음

    • 모두가 극단적인 언행을 해서 토론이 정리된 것이고, 스스로 자초한 일임

    • 만약 "하지 마세요"라는 의견들이 실사용자거나 꼭 필요한 이유를 설명할 수 없다면, 개발팀이 무시하는 것은 합리적임

    • 피드백 요청은 단순 찬반투표가 아님

    • XSLT 3.0을 JS/wasm 샌드박스로 옮겨 지원할 수만 있다면 좋겠음

    • 약간의 성능 저하는 있겠지만, 양쪽 장점을 모두 취할 수 있음

    • XML에는 버전 관리 스키마, 네임스페이스 등 특성상 통합이 비교적 수월함

    • Angular 같은 js 프레임워크와 달리 신뢰성 높은 데이터 계약이 가능함

    • XML 패밀리의 성숙함 덕분에 전문 툴이 많아, 실제로는 XML/XSD를 텍스트로 직접 다루지 않아도 됨

    • 구글은 "질문 형"으로 웹에 무슨 일이 벌어질지 미리 알려주는 식임

  • 이전 관련 스레드 소개

  • 브라우저가 특정 템플릿 엔진(XSLT)에 내장 지원을 할 필요가 있는지 의문임

    • Jinja 같은 텍스트 엔진이 아닌데, JS/wasm으로 재구현도 가능함

    • 지금 브라우저들은 너무 무겁고, 신규 엔진 개발이 힘듦

    • "미니멀 브라우저"를 위한 더 간단한 표준(기본 태그, 레이아웃 등)만 있었으면 함

    • WebAudio, Canvas 등도 wasm 모듈로 구현 가능함(그리고 이렇게 하면 핑거프린팅도 방지할 수 있음)

    • XSLT는 (특정 엔진이 아닌) 템플릿 엔진에 대한 "스펙"임, 다양한 구현체가 존재함

    • Mozilla는 libxslt 대신 transformiix 사용

    • 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

    • HTML standard FAQ

    • 아이러니하게도 HTML/CSS/브라우저 스펙에 엄청난 양의 기능을 밀어넣은 대표적인 것도 바로 Google임

    • 만약 구글이 "브라우저는 가벼워야 하며 이상한 것들은 JS 라이브러리에 맡기는 게 맞다"를 일관되게 옹호했다면 이번 조치도 이해할 만했겠지만, 전혀 그렇지 않음

  • FTP 지원 제거 이후부터 XSL의 운명은 이미 예견됨

    • 브라우저들은 공격 표면 축소를 최우선으로 삼는 경향이 있음

    • 다음 제거 후보는 SVG SMIL 애니메이션 속성, MathML 등 XML 관련 기능이 될 것 같단 생각임

    • 관련 스레드

    • SMIL은 특정 애니메이션 시작/종료 타이밍을 기반으로 순차적 애니메이션 제어를 할 수 있는데, CSS 애니메이션은 아직 이 부분이 부족함

    • CSS는 계산을 이용한 타이밍 외엔 방법이 없음

    • Chromium도 한때 SMIL 제거 의지를 밝힌 적 있으나, CSS가 충분하지 않았기 때문에 너무 성급했었음

    • 그 여파로 SMIL 관련 각종 안내문 등이 업데이트 없이 방치됨

    • 공격 표면을 줄이는 것이 과연 좋은 것인지 나쁜 것인지 질문하고 싶음

    • 기술자들과 일반 사용자가 우선순위가 다르긴 함

    • FTP 기능 제거가 언제 이루어진 것인지 궁금함

    • 아직 주소창에서 ftp://로 접속이 되는 것으로 알고 있음

  • Blink와 WebKit의 XSLT 구현은 매우 비효율적임

  • 이번 결정이 아쉽지만, 더 현대적인 XSLT 통합에 노력을 쏟지 않은 게 더 안타까움

    • 사용은 불편했지만 브라우저에서 조금만 더 진화했다면 React 같은 프레임워크에 필적할 경쟁자가 될 수도 있었음

    • XML은 대기업의 복잡성만 없었다면 표준 자체는 매우 강력하고, 멋진 기술이었음

    • XSLT를 활용해 작고 간단한 xml/데이터를 html로 바로 변환하는 게 정말 좋았음

    • 선택된 항목만 다르게 표시하는 작은 기능만 추가됐다면 정적 문서까지 다양한 활용이 가능했을 것으로 아쉬움

  • @whatwg가 토론이 "과열됐다"며 해당 이슈를 협업자 한정으로 잠갔다고 함

    • 보기엔 꽤 합리적이고 차분했는데, 특정 벤더에 우호적이냐에 따라 ‘과열’의 기준이 달라지는 건 아닐까 싶음

    • "과열됐다"는 표현은 종종 반대 의견을 다루기 싫다는 뜻으로 해석됨

    • Reddit 등 다른 커뮤니티도 마찬가지임

    • 실제로 그 아래 남아있는 1개의 댓글은 Google Chrome 소속 개발자가 "좋은 일 하셨다"고 남긴 것

    • 약간 보기 민망한 느낌임

    • 이슈 트래커에 문제 제기성 욕설, 음모론, 정치적 메시지 등 쏟아진 사례를 언급함

    • 이런 식이면 생산적 논의 자체가 불가능해지며, 저장소 관리자들이 신속하게 토론을 막을 수밖에 없음

    • 해당 저장소의 토론 잠금 조치는 실은 Apple 직원이 내린 것이라고 들었음

    • 하지만 사람들은 이 이슈를 제기한 Google 직원의 책임으로 돌린다 함

    • 구글이 최근 커뮤니티 의견 수렴을 내세워 열린 토론을 했지만, 그 후 모든 의견을 무시하고 관철시키려 하고 있음

    • 관련 이슈

  • 구식 웹 요소에 관한 전반적 고민이 필요함

    • 내 경우 예전 웹페이지도 계속 제대로 작동해서 얻는 가치가 큼

    • HTML/JS가 호환성 지켜온 덕분에 수십 년 된 페이지조차 TLS 인증서만 붙이면 여전히 정상임

    • 하지만 모든 유산 기술을 영원히 지원할 수는 없는 일이기도 함

    • Flash도 결국 에뮬레이터(Ruffle)를 통해 추억의 게임이나 사이트를 경험하는 식으로 넘어갔음

    • 장기적으로는 구형 렌더링에 특화된 전용 브라우저나 에뮬레이터 사용도 대안이 될 수 있음

    • 이미 이를 위한 XSLT polyfill 확장이 생겼음

    • Chrome은 이를 공식 배송하거나 유지보수하기를 원하지 않음

    • Ruffle과 매우 유사한 상황임

답변달기