# 구글이 오픈 웹을 죽이고 있다, 2부 > Clean Markdown view of GeekNews topic #24434. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24434](https://news.hada.io/topic?id=24434) - GeekNews Markdown: [https://news.hada.io/topic/24434.md](https://news.hada.io/topic/24434.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-18T09:36:26+09:00 - Updated: 2025-11-18T09:36:26+09:00 - Original source: [wok.oblomov.eu](https://wok.oblomov.eu/tecnologia/google-killing-open-web-2/) - Points: 1 - Comments: 3 ## Topic Body - **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와 같은 개방 기술의 지속적 사용이 오픈 웹의 생존을 위한 핵심 전략**임을 재확인함 ## Comments ### Comment 46635 - Author: devsepnine - Created: 2025-11-21T10:31:52+09:00 - Points: 1 왜 내장을 하지 않느냐고 하지만 반대로 굳이 내장해야할 이유도 없어보이는데.. ### Comment 46466 - Author: neo - Created: 2025-11-18T09:36:27+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45954560) - 브라우저에서 **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 이슈 트래커](https://issues.chromium.org/issues/451401343)에 따르면 xml-rs의 표준 준수 문제를 해결하려는 작업이 진행 중임 나는 Chrome 팀에서 일하지만 이번 작업에는 직접 관여하지 않음 - “불편하면 없앤다”는 태도는 웹의 **‘소유자 중심 문화’** 를 강화함 과거 웹은 사이트 운영자가 주체였고, 브라우저는 그들의 **도구(하인)** 역할이었음 지금의 방향은 그 철학에서 멀어지고 있음 - XML 전체를 구현하지 않는 건 합리적임 XML은 **Billion Laughs 공격** 같은 데이터 폭발 취약점을 허용하기 때문임 [관련 설명](https://en.wikipedia.org/wiki/Billion_laughs_attack) - RSS 피드를 브라우저에서 보기 위해 XSLT가 필수라는 주장은 과장임 JavaScript로도 충분히 가능하며, Google의 polyfill도 그렇게 동작함 나는 수천 줄의 XSLT를 작성해봤지만 **JavaScript가 훨씬 낫다고 생각함** XSLT는 이제 보안상 제거되어야 함 관련 발표는 [OffensiveCon 2025](https://www.offensivecon.org/speakers/2025/ivan-fratric.html)에서 다뤄짐 - XSLT는 선언적 언어로, **비개발자도 쉽게 HTML 템플릿을 만들 수 있는 장점**이 있음 JS의 대체 기능은 복잡하고 진입장벽이 높음 단순한 개인 웹페이지 제작이 어려워지면서 **‘열린 웹’의 정신**이 약화됨 RSS가 사라지고 Facebook 같은 플랫폼에 종속되는 현상이 그 결과임 [Web Components 문서](https://developer.mozilla.org/en-US/docs/Web/API/Web_components) 참고 - JS는 계속 진화하지만 XSLT는 **안정된 표준**으로 남아 있음 독립 브라우저들이 빠르게 진화하는 JS 생태계를 따라가지 못해 사라졌던 기억이 있음 예전의 Konqueror가 그리움 - [YouTube 발표 영상](https://www.youtube.com/watch?v=U1kc7fcF5Ao)을 보면 `document()` 함수의 보안 문제를 알 수 있음 이를 보고 XSLT 제거가 타당하다고 느꼈음 - XML 문서에 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](https://www.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 제공은 **복잡성을 브라우저 밖으로 밀어내는 방향**으로 보임 ### Comment 46538 - Author: rtyu1120 - Created: 2025-11-19T12:08:40+09:00 - Points: 2 2025년에 XSLT를 지원해야 한다는 글은 신선하네요... RSS 등 스타일링에서 잠깐 사용되는 건 사실이나 범용적으로 잘 사용된다고 보긴 어렵지 않은지