Hacker News 의견

• 브라우저에서 XSLT 제거는 오래전부터 필요했던 일임
  나는 libxslt의 전 유지보수자로서 이 결정이 촉발된 배경을 어느 정도 알고 있음
  더 흥미로운 점은 Chromium이 Rust 기반 XML 파서로 전환하려는 계획임
  현재는 xml-rs를 선호하는데, 이는 XML의 일부만 구현함
  즉, Google이 표준을 완전히 준수하지 않는 XML 지원을 택하려는 듯 보임

  • Google이 표준을 무시하는 행보를 보이는 게 흥미로움
    예전 Internet Explorer 5.1 시절처럼 시장 점유율로 표준을 무시하던 때가 떠오름
  • 브라우저가 XML 처리를 위한 좋은 플랫폼이 아니라고 생각함
    XHTML이 HTML5에 밀려난 이후로 XML 관련 복잡한 코드들은 자연스럽게 사라지는 중임
    Rust로 옮겨 보안 공격면을 줄이는 것은 합리적인 선택임
    남은 XML 파싱은 JS에서 polyfill이나 wasm으로 대체 가능함
  • Chromium 이슈 트래커에 따르면 xml-rs의 표준 준수 문제를 해결하려는 작업이 진행 중임
    나는 Chrome 팀에서 일하지만 이번 작업에는 직접 관여하지 않음
  • “불편하면 없앤다”는 태도는 웹의 ‘소유자 중심 문화’ 를 강화함
    과거 웹은 사이트 운영자가 주체였고, 브라우저는 그들의 도구(하인) 역할이었음
    지금의 방향은 그 철학에서 멀어지고 있음
  • XML 전체를 구현하지 않는 건 합리적임
    XML은 Billion Laughs 공격 같은 데이터 폭발 취약점을 허용하기 때문임
    관련 설명

• RSS 피드를 브라우저에서 보기 위해 XSLT가 필수라는 주장은 과장임
  JavaScript로도 충분히 가능하며, Google의 polyfill도 그렇게 동작함
  나는 수천 줄의 XSLT를 작성해봤지만 JavaScript가 훨씬 낫다고 생각함
  XSLT는 이제 보안상 제거되어야 함
  관련 발표는 OffensiveCon 2025에서 다뤄짐

  • XSLT는 선언적 언어로, 비개발자도 쉽게 HTML 템플릿을 만들 수 있는 장점이 있음
    JS의 대체 기능은 복잡하고 진입장벽이 높음
    단순한 개인 웹페이지 제작이 어려워지면서 ‘열린 웹’의 정신이 약화됨
    RSS가 사라지고 Facebook 같은 플랫폼에 종속되는 현상이 그 결과임
    Web Components 문서 참고
  • JS는 계속 진화하지만 XSLT는 안정된 표준으로 남아 있음
    독립 브라우저들이 빠르게 진화하는 JS 생태계를 따라가지 못해 사라졌던 기억이 있음
    예전의 Konqueror가 그리움
  • YouTube 발표 영상을 보면 document() 함수의 보안 문제를 알 수 있음
    이를 보고 XSLT 제거가 타당하다고 느꼈음
  • XML 문서에 JS를 적용하려면
    <?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?>;
    같은 형태를 지원해야 함
    하지만 현재 구현으로는 XSLT 수준의 경험을 JS로 완전히 대체하기 어려움
  • XSLT 제거로 영향을 받을 사람은 극소수일 것 같음

• Google이 열린 웹을 죽이고 있다는 주장에는 동의하지만, XSLT는 약한 근거임
  거의 사용되지 않는 복잡한 기능이라 유지보수 리소스를 줄이려는 결정으로 보임
  RSS/Atom 피드 표시를 위해선 브라우저에 직접 지원 기능을 넣는 게 더 나음

  • 하지만 영향받는 사이트는 공공기관·대학 등 중요도 높은 곳이 많음
    사용 빈도만으로 판단하면 안 됨
    중요한 사용자들과 협력해 점진적으로 폐기해야 함
  • RSS 내장 지원이 더 낫지만, 그럴 가능성은 낮음

• “열린 웹”과 XSLT는 별 상관이 없음
  열린 웹은 누구나 서버를 운영하고, 사이트를 만들고, 브라우저를 개발할 수 있는 환경을 뜻함
  XSLT는 이미 오래전에 죽은 기술이며, 제거로 인해 깨지는 사이트는 거의 없음
  오히려 보안 취약점 제거 효과가 있음

  • WHATWG가 브라우저 기능의 유용성을 결정하는 건 위험함
    XSLT 자체가 아니라 libxslt 구현에 취약점이 있었던 것임
    대체 구현을 만들 수도 있었는데, Google이 기능을 ‘죽이기로’ 선택한 게 문제임
  • RSS는 여전히 팟캐스트 분야에서 활발히 사용됨
    다만 사람들은 이제 개별 사이트 구독보다 소셜 피드 기반 소비를 선호함
    이는 기술 문제가 아니라 사용자 행동의 변화임

• XSLT 폐지에 대해 불만을 제기하는 사람 중 실제 사용 이유를 명확히 설명한 경우를 거의 못 봤음
  대부분은 단순한 저항의 상징으로 언급함

  • 이번 논란은 브라우저가 주요 기능을 처음으로 제거한 사례라서 생긴 반발임
    20년 넘게 “웹페이지는 영원히 보일 것”이라는 기대가 있었기 때문임
    libxslt 유지보수자가 보안 리포트 부담으로 사임하면서,
    브라우저 벤더들이 비용을 지불하기보단 기능을 제거하는 쪽을 택한 것임
  • XSLT는 처음부터 불편하고 비효율적인 기술이었음
    이를 반항의 상징으로 쓰는 건 스스로를 괴롭히는 일임
  • XSLT는 기업용 백엔드에서만 썼고, 브라우저 지원이 있는지도 몰랐음
    필요한 경우 polyfill이나 서버 측 변환으로 충분히 대체 가능함
  • 나는 XSLT를 써봤는데, XML을 다른 XML로 바꾸는 추상적 함수형 언어임
    RSS/Atom 피드를 보기 좋게 변환하는 데 썼었음
  • RSS/Atom 피드를 일반 사용자 친화적으로 만드는 데 XSLT가 유용함
    내가 만든 rss.style 사이트에서 그 차이를 볼 수 있음

• Mozilla가 RSS를 제거한 건 Google의 압박 때문이 아니라,
  사용자들이 RSS를 원하지 않았기 때문임
  Google은 오히려 열린 웹 발전에 가장 많이 투자한 기업 중 하나임
  WHATWG가 웹을 애플리케이션 플랫폼으로 바꾸려는 건 개발자와 사용자 수요의 결과임
  Blink는 오픈소스라 포크 유지도 가능함

  • “시장 수요”라는 표현은 부정확함
    RSS는 대중에게 너무 기술적이었고, Google이 Reader를 없애면서
    소셜미디어가 그 자리를 차지하게 됨
  • Microsoft도 과거 Office로 열린 생태계를 확장한 척하며
    결국 독점 구조를 강화했음
    Blink의 오픈소스성만으로는 진정한 개방성을 보장하지 않음
  • 웹앱 중심으로 가는 건 개발자보다 고객의 기대 때문임
  • 대부분의 사용자가 쓰지 않는 기능이라도,
    존재 자체로 해가 없다면 굳이 제거할 필요는 없음

• 글쓴이의 주장은 일부 공감되지만,
  브라우저가 Gopher까지 지원해야 한다는 건 복잡성 과잉임
  Chrome 프로젝트 입장에서는 단순화를 위한 결정으로 보임

  • XSLT는 사실상 죽은 포맷이며, 유지보수 부담과 보안 위험이 큼
    제거는 합리적이며, 웹 업계 종사자 대부분이 동의함
  • JPEG XL은 XSLT보다 훨씬 설득력 있는 사례임
    C 언어 기반 XML 파싱은 항상 보안상 두려움을 줌
  • 단순화를 원한다면 기능을 완전히 없애기보다
    확장 기능(extension) 형태로 분리하는 게 더 나음
  • “Web Bluetooth” 같은 복잡한 기능을 만든 회사가
    단순화를 이유로 오래된 기능을 없앤다는 건 모순적임
  • 기능을 유지하든 제거하든 정치적 결정임
    어느 쪽이든 누군가는 손해를 보게 됨

• 내 블로그를 XML/XSLT로 바꿀 생각임
  아무도 안 읽으니 이제 트래픽 부진을 Chrome 탓으로 돌릴 수 있음

• Google 팬은 아니지만, XSLT 제거는 웹 API 복잡도를 줄일 기회임
  Ladybird 같은 독립 브라우저에게는 부담을 덜어줄 수 있음
  결과적으로 Google의 독점력을 약화시킬 수도 있음

  • 하지만 실제로는 많은 논쟁이 일어나고 있어
    “큰 반발 없이” 진행된다고 보긴 어려움

• 지난 10~15년간 웹 표준은 특정 니치 요구사항을 브라우저에 넣으려는 흐름이었음
  XSLT 제거와 polyfill 제공은 복잡성을 브라우저 밖으로 밀어내는 방향으로 보임