Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Chrome과 Edge가 XSLT 기능을 제거하는 것에 대한 논쟁을 다루며, 웹 표준의 변화와 기술적 대안 마련의 중요성을 강조합니다. 이 기능은 과거 RSS/Atom 피드 처리 등에서 사용되어 왔으며, 대체 방안으로는 서버 측 변환이나 JSON 전환 등이 제시되었습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기RSS와 Atom은 Google 권고대로 HTML에 <link rel='alternate' type='application/rss+xml'> 같은 피드 발견용 링크를 제공하면 됨
독자와 피드 클라이언트가 원본 XML을 직접 열지 않고 피드를 발견할 수 있음
애플리케이션 핵심 기능이 XSLT에 의존한다면 즉시 이전을 시작해야 함
문서화된 대안은 서버 측 변환, 엔드포인트의 JSON 전환, 클라이언트 측 라이브러리임
Google은 Saxonica의 JavaScript 구현과 WebAssembly 폴리필을 예로 듦
기업 정책과 오리진 트라이얼은 영구 대안이 아니라 종료 기한이 있는 유예 수단임
사용률만으로 웹 기능을 제거해도 되는가
제거 찬성 측은 낮은 사용률과 보안 비용의 차이가 크다고 봄
페이지 로드의 0.02%를 위해 공격에 많이 노출되는 브라우저에 유지보수가 부족한 C 파서를 남길 수 없다고 봄
모든 엔진이 제거에 동의하며, 어떤 기능도 제거할 수 없는 플랫폼은 결국 안전하게 만들 수 없다고 봄
반대 측은 페이지 로드 수가 기능 중단의 피해를 측정하지 못한다고 봄
사용량이 적더라도 장애 비용이 큰 곳에 집중돼 있을 수 있으며, 사용 빈도가 낮은 다수 사이트에 대한 조사가 부족하다고 비판함
WHATWG 이슈 11582는 congress.gov, govinfo.gov, weather.gov, europarl.europa.eu, tga.gov.au, European Pollutant Release and Transfer Register 등을 영향 사례로 제시함
제거 제안이 Chrome 사용량 통계 밖의 기존 활용 사례와 실제로 깨질 사이트 수를 충분히 조사하지 않았다고 비판함
영향받는 사이트 수는 어느 쪽도 공개하지 않음
Google은 페이지 로드 비율을, 반대 측은 개별 사례 목록을 공개했으며 두 단위는 서로 환산할 수 없음
공개된 근거만으로는 보안 위험과 기존 사이트의 피해를 비교해 이 논쟁을 결론내릴 수 없음
우선순위와 남은 불확실성
일반 사이트 관리에서는 약 30분의 의존성 목록 점검 후 대부분 그대로 두는 선택으로 충분할 수 있지만, 비용 부담은 균등하지 않음
SEO 팀보다 기계 판독용 데이터를 저렴하게 사람이 읽을 수 있도록 제공해 온 공공기관에 부담이 집중됨
사이트맵 외형보다 이 비대칭이 중요하며, 통제할 수 없는 렌더링에 의존하는 문제는 기술 SEO에서도 살펴볼 사안임
아직 확정되지 않은 사항이 남아 있음
Edge가 Chrome과 같은 일정으로 제거할지, 자체 일정을 따를지 공개되지 않음
Firefox와 Safari는 엔진 차원에서 찬성 입장이지만 실제 적용 일정이 없음
실제로 깨지는 사이트 수는 집계되지 않음
오리진 트라이얼이 Chrome 176 이후까지 연장될지는 알 수 없음
플러그인 업체가 11월 전에 사이트맵 화면의 대체 기능을 제공할지, 기존 스타일시트를 비활성 상태로 남길지도 미정임
적어도 Firefox에는 남겠지만, 요즘 Mozilla를 보면 뒤따라 없애도 놀랍지 않을 듯함. Flash 지원 종료 때와 마찬가지로 더 나은 기술로 넘어가는 건 좋지만, 마땅한 대안이 없다면 소용없음.
아이들이 쉽게 가지고 놀 웹 게임을 만드는 기본 도구는 Flash였는데 이제는 빈자리임. RSS 피드를 원시 XML 대신 읽기 좋게 표시하려면 어떻게 해야 할까? 브라우저의 RSS 처리 기능이 사라져 XSLT로 우회했는데, 이제 그 우회로마저 사라지고 좋은 대안도 보이지 않음.
청소년들이 멀티플레이어 웹 게임을 만들고 공유하는 공간인 Easel을 4년째 개발 중임. 아직 갈 길이 멀지만 바로 그 목표를 추구함. https://easel.games.
꼭 웹 기반이어야 할까? 쉽게 발견할 수 있어서일까? Minecraft와 Lego도 있고, 나는 어릴 때 MS-DOS 명령줄을 발견해 탐험하는 재미를 느꼈음.
예전에는 Shockwave 기반 온라인 그림 맞히기 게임인 iSketch도 있었고, 지금도 대안은 있을 법함. 다만 낯선 이들과 어울리면 부적절한 그림을 그리는 이들처럼 최악의 행동을 마주하게 됨. 지역에서 아는 아이들끼리 게임하게 하면 문제가 생겨도 적어도 부모끼리 연락할 수 있음.
Pico-8, Picotron, Tic-80, GameMaker, Godot 모두 간단한 웹 내보내기 기능을 갖추고 있음.
현실적으로 지금은 Roblox임. 하지만 Chris Hansen과 동료들이 밝혔듯 아동 성범죄자들의 온상이기도 해서 내 아이들에게는 쓰게 하지 않겠음.
XHTML 시절 XSLT로 웹사이트를 모듈화했다면 훨씬 깔끔했을 텐데 아쉬움. JavaScript를 jQuery 없이 쓰기 어려웠던 때, 별도 구성 요소를 XSLT로 합치는 초기 웹사이트 제작 도구를 만들었고 상당히 강력했음.
하지만 XHTML 대신 HTML5가 채택되면서 XSLT는 사실상 쓸모를 잃었음. 지금까지 살아남은 것도 대단하며, 주로 XML 파일의 스타일을 지정하려고 유지된 듯함.
HTML5가 표준 XML 또는 XML 호환 DOM 표현 형식을 정의하거나 적어도 권장할 수도 있었지만, 당시 반XML 정서는 노골적이고 적대적이었음. 주요 XSLT 처리기는 HTML5 입출력을 지원하지만, 지원 범위나 표준 근거가 얼마나 확실한지는 모르겠음.
WDDX와 XML-RPC를 겪고 XML에 대한 열정은 식었지만, HTML의 기반으로는 가장 좋은 선택이었고 도구 체계를 넘나드는 경쟁자가 없는 지금도 그럴 수 있음. 코드와 데이터의 표현 형식을 같게 만든 문법 선택을 제외하면 XSLT도 여전히 좋은 도구임. 막다른 길이라는 게 분명해진 뒤에도 다시 사용했으며, 방치 속에서도 유용하다는 사실이 그 가치를 입증함.
XHTML은 웹 개발자들이 받아들일 준비가 되기 전에 등장한 듯함. 구성 요소 기반 아키텍처도 내 예상보다 늦게 보편화됨. 여러 구성 요소를 유효한 문서로 취급할 수 있다면, 지금 다시 도입해도 통할 수 있음.
클라이언트 측 XSLT는 원래 별로 쓸모가 없었는데 HTML5와 무슨 관계인지 모르겠음. 실질적인 용도는 CSS가 널리 지원되기 전의 스타일과 배치 처리였고, CSS 지원 개선으로 불필요해진 것임.
기억하기로 XSLT 1.0 명세는 글이 상당히 불명확해서 이해하기 어려웠음.
당시에는 렌더링도 매우 느렸음.
XSLT를 26년째 사용 중임. 백엔드에서 XML 문서를 생성하고 HTML로 변환해 여러 보고서를 만듦. 최신 템플릿 언어에는 없는 기능과 강점이 많은데, 갈아탈 만한 언어가 있을까?
반쯤 진지하게 제안하자면, 파일을 (X)HTML 페이지로 감싸고 JavaScript에서 WebAssembly로 컴파일한 XML 파서를 불러와 브라우저에서 변환하면 됨. 주변 구조만 잘 잡으면 기존 템플릿이나 생성 로직을 거의 바꾸지 않아도 됨.
물론 브라우저 DOM 안에 DOM 변환 라이브러리 전체를 올리는 황당함은 감수해야 함.
갈아탈 필요 없이 서버 측에서 XSLT를 계속 쓰면 됨.
Chrome과 Edge에서 XSLT가 더는 작동하지 않게 되므로 바꿀 이유가 있음.
없어지는 것은 브라우저 내 XSLT 지원뿐임. 만족하며 쓰고 있다면 버릴 필요 없이 변환을 백엔드에서 수행하면 됨.
사용자가 지금까지 틀렸다고 믿게 만드는 방법은 간단함. 브라우저 시장을 독점하고, 가짜 보안 공포를 조성한 뒤, Flash처럼 완전히 없애는 것만이 해결책이라고 몰아가면 됨.
UI/UX 실험에 자원을 전부 써버렸으니 버그를 고칠 인력도 없다고 덧붙이면 됨.
아직도 여기에 관심을 갖는 게 이해되지 않음. RSS 애호가들이 좋아하는 것은 사용자가 원하는 방식으로 표시하는 소프트웨어에서 RSS를 읽는 것임. XSLT는 표시용 언어이고, 결과 페이지는 일반 웹페이지처럼 동작할 뿐 프로그램으로 소비하는 대상이 아님. 필요한 것은 위에 덧붙인 잡다한 꾸밈이 아니라 원본 XML/RSS임.
Cloudflare 인증을 통과한 뒤에도 403 오류로 페이지를 열지 못하는 사람이 또 있을까?
지금까지도 양쪽 어디에도 동적 처리를 넣지 않고 머리글·탐색 메뉴·바닥글 같은 공통 HTML을 불러오는 방법 중 널리 지원되는 것이 이것뿐이었다니 황당함. 이렇게 기본적이고 흔한 용도가 제대로 지원되지 않는 셈임.
프레임셋도 가능함. 다만 사용자 인터페이스는 좋지 않음.
예전에 XSLT를 직접 작성해 서버에서 서비스 출력을 HTML로 미리 렌더링하던 시절이 떠오름. 프런트엔드는 ASP.NET의 어느 버전이었고, Microsoft의 XSLT 구현에는 특이한 동작이 많았음.
라틴어 오디오북의 장별 텍스트, 현지화, 출처, 교육용 정보, 음성과 텍스트의 강제 정렬 데이터를 모두 TEI-XML로 저장함. BaseX에서 문서를 가져올 때 XQM 모듈이 XML 처리 명령을 붙이며, 그중 하나가 읽기 화면용 XSLT 1.0 스타일시트를 가리켜 HTML 렌더링을 전부 클라이언트에서 처리함.
꽤 멋진 시스템이라 서버로 옮겨야 하면 아쉬울 듯함. Firefox 콘솔에서도 곧 XSLT 지원을 중단한다는 경고가 뜨니 Chrome만의 일이 아님. https://fabulae.orbilii.com.
처리 과정을 WebAssembly로 구현해 서버의 Wasmtime에서 실행하는 방법을 고려해 볼 만함. 그러면 같은 모듈로 클라이언트에도 옮길 수 있음. LLVM 기반 컴파일러는 거의 모두 WebAssembly로 컴파일 가능함.
10여 년 전 동료가 iOS 스토리보드에서 Swift 코드를 생성하는 도구를 만들었음. 화면 전환을 통해 데이터를 전달하고 식별자에 타입이 보장된 방식으로 접근하게 해줬으며, 첫 버전은 XSLT로 스토리보드 XML을 변환했음. 용도가 제한적이지만 강력한 기술임.