XSLT 사망 — Google이 XSLT 지원을 중단한다

 (xslt.rip)
1P by GN⁺ | ★ favorite | 댓글 2개
  • Google이 2027년까지 XSLT 지원을 완전히 종료할 계획을 공식 발표
  • XSLT는 XML 문서를 다른 XML 형태로 변환하는 언어로, 여러 정부 웹사이트에서도 사용 중
  • Google은 과거 2013년에도 XSLT 지원 중단을 시도했으며, 이번이 두 번째 시도
  • Mozilla와 Apple도 XSLT 제거에 동참 의사를 밝혔으며, Google과의 금전적 관계가 언급됨
  • 웹 표준과 콘텐츠 접근성에 영향을 미칠 수 있는 중요한 기술 변화로 평가됨

Google의 XSLT 지원 종료 발표

  • 2025년 10월 24일, Google은 Chromium 개발자 포럼에 “Intent to Deprecate and Remove: Deprecate and remove XSLT” 문서를 게시
    • 이에 따라 2027년까지 XSLT 기능이 완전히 제거될 예정
  • Google은 이미 2013년 7월에도 XSLT 제거를 시도한 바 있음
    • 당시 시도는 중단되었으나, 이번 발표로 12년 만에 재개됨

Google의 기술 폐기 이력

  • 지금까지 Google은 약 300개의 기술을 종료한 것으로 알려짐
    • 대표적으로 Google Reader가 2013년 3월 13일 종료 발표
  • XSLT는 곧 ‘Killed by Google’ 목록에 추가될 예정
  • 글에서는 “Google이 XML과 RSS를 싫어한다”는 표현을 사용하며, RSS와 XSLT의 연관성을 강조

XML 및 RSS 관련 주장

  • RSS는 뉴스 배포에 사용되는 기술로, 글에서는 Google이 이를 제거함으로써 뉴스 통제 가능성을 언급
  • XSLT는 여러 정부 웹사이트에서 사용되는 기술로, Google의 조치가 입법 관련 웹 기술에도 영향을 줄 수 있다고 지적
  • “Google이 XML과 RSS를 제거함으로써 웹 통제력을 강화한다”는 비판적 시각 제시

다른 브라우저들의 입장

  • Mozilla는 XSLT 제거가 “기존 웹 콘텐츠를 깨뜨릴 수 있다(break existing web content)”고 언급
  • Apple은 Google의 2027년 일정보다 더 빠르게 참여하고 싶다(participate sooner) 는 입장 표명
  • 글에서는 Google이 Mozilla에 연간 약 4억 2천만 달러, Apple에 1년간 200억 달러를 지급했다고 인용
    • 지난 10년간 두 회사에 총 약 2,442억 달러가 지급된 것으로 계산 제시

XSLT 보존 촉구

  • 작성자는 “Google이 XSLT를 죽이지 못하도록 막자”는 메시지를 강조
  • “XSLT를 웹사이트와 블로그에 추가하라”는 행동 촉구 포함
  • “Keep XSLT alive! ”라는 구호로 마무리하며, 사용자 참여와 기술 보존을 호소

함께 보면 좋은 글 β

t7vonn   [-]

그만 보내줍시다.

답변달기
GN⁺   [-]
Hacker News 의견

  • 사이트가 실제로 XML 문서로 되어 있기를 바랐는데, 다행히도 정말 XML 문서였음
    curl https://xslt.rip/ 명령으로 확인해보면 <html> 태그 안에 “If you're reading this, XSLT was killed by Google.”이라는 문장이 들어 있음

    • 이건 브라우저가 XSLT를 지원하는지 구분하는 영리한 방법임
      실제 콘텐츠는 index.xsl에 있고, 제작자는 프론트엔드 디자이너로 dbushell.com이라는 멋진 개인 사이트도 운영 중임
      두 사이트 모두 개인적인 감성이 살아 있음
    • 나에게 XSLT는 웹 복잡성을 폭발적으로 늘려서 결국 두 개의 브라우저만 남게 만든 기술처럼 느껴짐
      사이트 디자인이 90년대 웹 시절을 떠올리게 해서 묘하게 웃김
    • 텍스트 브라우저(Lynx 등)로 접속하면 그 문장만 보이는데, <noscript>로 “이 사이트는 JavaScript가 필요합니다”라고 뜨는 것과 비슷한 느낌임
      이제는 Google이 아닌 브라우저 중 XSLT를 구현한 곳이 남아 있는지 궁금해짐

  • 나는 브라우저에서 XSLT 지원을 없애는 것에 강하게 반대함
    개인 사이트에서 JavaScript의 XSLTProcessor와 <?xml-stylesheet …?>를 모두 사용하고 있고, 관련 GitHub 스레드에 의견도 남겼음
    하지만 이 사이트는 다소 과장된 표현을 쓰는 것 같음. Google의 보안·유지보수 이유는 진심이라고 생각하지만 방향은 잘못되었다고 봄
    이런 페이지는 의사결정자들을 설득하기보다는 오히려 짜증나게 만들 위험이 있음

    • 그런 기능을 쓰는 사람이라면 정말 아주 소수의 엘리트 팀일 것 같음
    • XSLT 변환을 서버 측에서 하면 최신 도구를 쓸 수 있고, 모든 브라우저에서 동작함
    • 사이트의 과장은 의도된 유머로 보임
    • 웹페이지 하나로 의사결정자를 설득할 수는 없음. 이 페이지의 목적은 단순히 이슈 인식 제고임
    • libxslt가 거의 유지보수되지 않고 보안 취약점이 많다는 점에서 제거가 타당하다고 봄
      만약 XSLT를 살리고 싶다면 Rust로 새 구현체를 만드는 게 최선이었을 것임

  • 나는 소수 의견일지 모르지만, XSLT가 멈춰버린 현실이 안타까움
    25년 전 XML+XPath+XSLT 생태계를 대체하려고 수많은 불완전한 라이브러리를 만든 건 인재 낭비였음
    SOAP나 XML Schema의 과도함은 인정하지만, JSON의 초기 eval() 방식도 좋은 공학은 아니었음
    결국 더 나은 XML 시스템을 만들 수도 있었는데, 새로움에 취해 기존의 장점을 버린 게 아쉬움

    • 좋은 XML 파서는 여전히 거의 없지만, JSON 파서는 많음
      Ruby, Python, Java 등에서 XML 파싱은 늘 고통이었고, JSON은 훨씬 단순하고 안정적이었음
    • JSON 명세는 두 페이지로 끝나지만, XML 명세는 책 한 권임. 이 차이에서 이미 무게감이 다름
    • 예전에 XSLT를 써봤는데 정말 극도로 싫어했음
      전담 전문가가 필요할 정도로 복잡했고, 그 자체가 낭비처럼 느껴졌음
    • 그래도 RSS 파일을 브라우저에서 바로 렌더링할 수 있는 등 멋진 활용이 있었음
      2010년대의 시맨틱 웹 아이디어가 사라지는 건 아쉬움

  • 나는 XSLT를 거의 쓰지 않지만, Google이 “웹 그 자체”인 양 행동하는 게 짜증남
    uBlock Origin을 없애려는 시도도 그렇고, AI 브라우저들이 현실을 왜곡된 형태로 보여주는 것도 싫음
    정부나 기업이 중간자 역할을 하며 정보를 통제하는 세상은 원치 않음
    Google 검색 품질도 이미 5년 전부터 의도적으로 나빠졌다고 생각함

    • 나도 같은 생각임. XSLT에는 관심 없지만, Google이 HTML을 없애겠다고 하면 누가 막을 수 있을까 하는 피로감이 큼
    • 지금 브라우저 엔진이 사실상 세 개뿐이라는 점이 걱정스러움
    • Google은 Search, Android, Chrome, AdSense를 분리해야 함
      광고 독점, adblock 제거, 앱 설치 제한 등으로 웹 생태계를 장악했음
      그래도 이 사이트 디자인은 정말 아름답고, 레트로 감성이 살아 있음
    • 그렇다면 대안 모델은 무엇일까?
      Google 내부에서도 “이건 우리가 맡고 싶지 않지만, 다른 누가 할 수 있겠는가”라는 식의 결정이 많았음
      OpenGL이 협의체 모델로 실패하고 DirectX에 밀린 사례처럼, 표준의 개방성만으로는 시장을 지키기 어렵다는 교훈이 있음
      브라우저 표준도 비슷한 위험을 안고 있음. 결국 누가 목소리를 낼 수 있는가가 중요함

  • 브라우저가 워낙 복잡하니 XSLT 제거 결정에 부분적으로 동의함
    개인적으로 XSLT를 써본 적도 없고, RSS와의 연관성도 크지 않다고 느낌

    • 하지만 혹시 모르게 이미 XSLT를 사용하고 있을 수도 있음. 예를 들어 유럽의회 사이트 같은 곳이 그 예임
    • 예전에는 RSS 피드를 열면 브라우저가 자동으로 스타일을 적용했지만, 지금은 단순 XML만 보임
      예시 / 과거 스타일링 설명 / 수동 스타일 적용 예시
    • RSS 피드에 XSLT를 적용하면 브라우저에서 사람이 읽기 쉬운 형태로 보여줄 수 있음
      lepture.com의 예시처럼, RSS 리더를 모르는 사용자에게도 도움이 됨

  • 만약 Google이 내일 암을 치료해도 누군가는 “Google이 암을 죽였다”고 할 것 같음
    소규모 브라우저 업체가 오래된 XSLT 코드를 유지보수하고 싶어 할 리 없고, 새 브라우저도 추가할 계획이 없을 것임
    잘 정리된 결정이라고 생각함

    • 하지만 작은 브라우저들은 원래 필요한 기능만 선택적으로 구현함.
      그렇다면 이 결정에 찬성하는 회사가 구체적으로 어디인지 궁금함
    • “작은 브라우저”라면 대체로 어떤 곳을 말하는지 묻고 싶음

  • 이 사이트는 일종의 로르샤흐 테스트 같음
    “Google이 XSLT를 죽였다”는 비판과 “2025년에 XSLT를 밀어붙이는 건 우스꽝스럽다”는 풍자를 동시에 담고 있음
    “친구와 가족에게 XSLT를 알려라! 늦기 전에 웹사이트에 추가하라!”는 문구가 그걸 잘 보여줌

    • 명백히 과장을 풍자하는 의도임
    • 하지만 나는 실제로 Atom 피드 때문에 XSLT를 쓰고 있음
      정적 사이트에서 RSS를 보기 좋게 렌더링하려면 XSLT가 유일한 방법임
      이런 변화는 개인 웹의 자율성을 더 빼앗고, 대형 웹앱 중심으로 몰아가는 흐름임

  • 한 시대의 끝 같음
    예전에 XSLT 튜토리얼을 공부하며 XML 문서를 ‘살아 움직이게’ 만드는 게 신기했음
    지금도 내 RSS 피드에 스타일을 입히는 데 사용 중임
    관련 공지 링크는 Chromium 포럼 글과 Chrome 개발자 문서임
    유지보수 부담이 크다는 건 이해하지만, 웹의 작은 즐거움이 또 하나 사라지는 느낌임

  • Google은 이미 거의 모든 영역을 독점하고 있음
    Android 사례(관련 링크)처럼, 이제는 무엇이 허용되고 금지되는지도 Google이 정함
    그래서 keepandroidopen.org처럼 keepXSLTAlive.tld 같은 캠페인 사이트를 만들면 좋겠음
    혹은 xslt.rip의 UI를 조금 다듬어 저항의 분위기를 살리는 것도 괜찮을 듯함

    • 하지만 Google 비판이 맞다고 해도, 그게 XSLT를 계속 유지해야 할 이유는 아님
      기술은 자체의 가치로 평가되어야 함

  • 이 웹페이지 정말 멋짐
    갑자기 <iframe>, <blink>, <marquee>, <table> 태그로 90년대식 HTML 페이지를 만들고 싶어짐

    • 농담이지만, blink와 marquee는 이제 Canvas로 렌더링해야 함
      아니, Canvas도 구식이니 WebGPU로 해야겠지
    • “공사 중” 배너가 꼭 필요함
    • 최근에 테이블로만 구성된 페이지에서 데이터를 추출해야 했는데, 중첩 테이블 지옥이었음
답변달기