▲

구글이 오픈 웹을 죽이고 있다, 2부

 (wok.oblomov.eu)
1P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • Chrome의 XSLT 지원 중단은 구글이 오픈 웹의 핵심 기술을 약화시키는 조치로, 보안 문제를 이유로 들었지만 대체 기술 제공 없이 기능을 제거함
  • 구글은 브라우저 내 기본 기능 대신 JavaScript 기반 폴리필(polyfill) 을 제안했으나, 이를 브라우저에 내장하지 않고 개발자에게 구현 부담을 전가함
  • 이러한 결정은 RSS·XML 기반 독립 웹 생태계의 약화로 이어지며, Mozilla와 Apple도 유사한 방향으로 움직이고 있음
  • 글은 WHATWG가 더 이상 오픈 웹의 수호자 역할을 하지 못하고, 대기업의 이익 중심으로 웹 표준을 통제한다고 비판
  • 브라우저 확장성 축소와 DRM 표준화 등으로 사용자 통제권이 약화된 웹 구조가 고착되고 있으며, 이에 맞서 RSS·XSLT·JPEG XL 등 개방 기술의 지속적 사용과 저항을 촉구함

XSLT 지원 중단과 구글의 행보

  • 구글은 Chrome에서 XSLT 지원을 폐기하고, 보안 취약점을 이유로 들었으나 대체 라이브러리나 개선 방안은 제시하지 않음
    • 기존 FLOSS 라이브러리의 보안 문제를 핑계로 삼았다고 비판함
    • 더 안전한 언어로 작성된 최신 XSLT 구현을 도입할 기회조차 활용하지 않았다고 지적
  • 구글이 제시한 JavaScript 폴리필은 브라우저 내장 없이 외부 호출 방식으로만 제공되어, 비표준적이고 비효율적인 대체 수단으로 평가됨
  • 글은 이 조치가 RSS와 XML 기반 독립 웹의 기반을 약화시키려는 의도적 행위라고 주장함
    • 폴리필이 충분하지 않거나, 충분하더라도 구글이 이를 내장하지 않는 이유는 XSLT 사용 자체를 억제하려는 목적이라고 분석

“Do. Not. Comply.” — 저항의 촉구

  • 작성자는 폴리필 설치나 XML 수정에 응하지 말고, 브라우저의 XSLT 지원 복원을 요구하라고 강조
  • XSLT, MathML, SVG, SMIL 등 표준 기술을 계속 사용하며, 브라우저의 비표준적 행태를 사용자에게 알리는 경고 박스(infobox) 를 유지할 계획임
  • 구글의 결정은 기술적 이유가 아닌 정치적·상업적 동기에 따른 것으로, 오픈 웹을 통제하려는 시도의 일환으로 설명됨
  • Mozilla와 Apple도 유사한 방향으로 움직이며, 사용자 에이전트(User Agent) 대신 감시 자본주의 도구로서 브라우저를 설계하고 있다고 비판함

WHATWG와 웹 표준의 왜곡

  • WHATWG는 초기에는 오픈 웹을 위한 협의체였으나, 현재는 대기업 중심의 폐쇄적 조직으로 변질되었다고 평가됨
  • 이 단체는 웹을 지식 저장소가 아닌 ‘애플리케이션 배포 플랫폼’ 으로 전환시키고 있으며, 사용자 통제권보다 기업의 수익 극대화를 우선시함
  • 브라우저는 더 이상 사용자 대리인(User Agent)이 아니라, 기업의 이익을 위한 통제 도구로 기능하고 있음
  • 이러한 변화는 W3C가 추구한 개방적 웹 비전과 정면으로 충돌한다고 지적함

새로운 브라우저 전쟁의 필요성

  • 현재의 브라우저 시장은 Google·Apple·Mozilla 중심의 엔진 종속 구조로, 독립적 대안이 거의 없음
    • Vivaldi, LibreWolf, WaterFox, Pale Moon 등 대안 브라우저들이 언급되지만, 대부분 Blink나 Gecko 엔진에 의존
  • Pale Moon은 RSS와 JPEG XL 지원을 유지하는 몇 안 되는 브라우저로 평가됨
  • 글은 사용자 대 기업의 전쟁, 즉 웹 통제권을 되찾기 위한 새로운 브라우저 전쟁이 필요하다고 주장함

또 다른 웹의 가능성 — Gemini와 개방 프로토콜

  • HTTP·HTML 중심의 웹 외에도 Gemini 프로토콜 등 새로운 인터넷 공간이 존재함
    • Gemini는 단순한 구조와 보안·인증 내장 기능을 갖춘 경량 프로토콜로, 구글의 영향권 밖에서 운영됨
  • 그러나 문제는 기술이 아니라 사회적 구조이며, 기술 자체는 여전히 유효하다고 강조
  • 브라우저는 프로토콜이나 포맷에 따라 차별하지 말아야 하며, Markdown·AsciiDoc·Gemtext 같은 경량 마크업 포맷의 통합 지원이 바람직하다고 제시함

플러그인 제거와 웹 통제 강화

  • 과거 NPAPI 플러그인 인터페이스는 다양한 포맷과 프로토콜을 지원했으나, 구글이 2013년부터 단계적으로 제거함
    • 이로 인해 웹 확장성과 실험적 기술 도입 경로가 차단됨
  • 플러그인 제거 후 등장한 Encrypted Media Extensions(EME) 는 DRM을 표준화하며, W3C의 개방 원칙을 훼손했다고 비판
  • 브라우저 확장은 보안 명분 아래 기능이 제한된 대체물로, 특히 Manifest V3는 광고 차단 기능을 약화시킴
  • 이러한 변화는 사용자 제어권 축소와 기업 통제 강화로 이어졌다고 분석함

“A mesh of building blocks” — 이상적 웹 구조

  • 이상적인 웹은 플러그인 기반의 모듈형 구조로, 새로운 프로토콜·포맷·스크립트 언어를 자유롭게 추가할 수 있어야 함
  • 이런 구조였다면 RSS·SMIL·XSLT·XQuery·XHTML2 등이 지속적으로 발전했을 것이라고 언급
  • 그러나 현실은 Google이 웹의 진화 방향을 독점적으로 결정하는 구조로 변했고, 이를 되돌리기 위한 사용자 주도의 저항이 필요하다고 결론지음

Resist — 저항의 선언

  • “Do not comply. Resist. ”라는 구호 아래, 다음과 같은 행동을 촉구함
    • RSS 사용 유지
    • XSLT 지속 활용
    • JPEG XL 기본 이미지 포맷 채택
    • 브라우저의 비표준적 동작을 ‘사이트 오류’가 아닌 ‘브라우저 결함’으로 보고
  • 이는 단순한 기술 선택이 아니라, 오픈 웹을 지키기 위한 실천적 저항으로 제시됨

Post Scriptum 및 반응

  • XSLT 관련 프로젝트로 xslt.rip과 작성자의 개인 사이트를 소개하며, XSLT로 SVG를 생성하는 시도를 언급
  • Hacker News와 Lobste.rs 등에서 논의가 이어졌으나, 많은 댓글이 XSLT의 중요성을 과소평가했다고 지적
  • 작성자는 XSLT가 서버 렌더링보다 효율적이며, 특히 소규모·자체 호스팅 환경에서 유리하다고 강조함
  • 결론적으로, XSLT와 같은 개방 기술의 지속적 사용이 오픈 웹의 생존을 위한 핵심 전략임을 재확인함
▲
rtyu1120 7시간전  [-]

2025년에 XSLT를 지원해야 한다는 글은 신선하네요... RSS 등 스타일링에서 잠깐 사용되는 건 사실이나 범용적으로 잘 사용된다고 보긴 어렵지 않은지

답변달기
▲
GN⁺ 1일전  [-]
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 제공은 복잡성을 브라우저 밖으로 밀어내는 방향으로 보임

답변달기