크롬이 11월 17일 XSLT를 끈다, 깨지는 사이트와 남은 2주

구글이 크롬에서 XSLT 지원을 끊습니다. 2026년 11월 17일 크롬 158 정식판부터 XSLT 변환이 동작하지 않습니다. XSLT로 화면을 만들던 사이트는 그날 이후 XML 원문이 그대로 보이거나 빈 화면이 됩니다.

XSLT는 1999년 11월 16일 W3C 권고안이 된 XML 변환 언어입니다. 서버가 아니라 브라우저가 XML을 HTML로 바꿔 그리던 방식이라, 관공서 게시판과 RSS 뷰어, 옛 기업 사이트에 아직 남아 있습니다.

영향은 두 갈래입니다. 운영하는 사이트가 XSLT를 쓴다면 남은 기간은 2주입니다. 쓰지 않는다면, 앞으로 옛 사이트가 깨지는 장면을 보게 됩니다.

크롬이 끄는 것은 두 가지다

사라지는 기능은 XSLTProcessor 자바스크립트 API와 xml-stylesheet 처리 명령입니다. 페이지 안에서 자바스크립트로 변환을 돌리던 코드와, XML 파일 머리말에서 스타일시트를 지정하던 방식이 함께 막힙니다.

브라우저가 지원한 XSLT는 처음 나온 1.0뿐이었습니다. 이후 개정판은 브라우저에 들어오지 않았습니다. 27년 된 기능을 지금 정리하는 셈이고, 그래서 남은 사이트도 대부분 오래된 코드입니다.

크롬은 이미 단계적으로 껐습니다. 2025년 12월 2일 카나리·개발·베타판에서 기본 비활성화로 예고했고, 2026년 3월 10일 기업 정책을 열었습니다. 8월 25일에는 오리진 트라이얼, 9월 22일에는 안드로이드 웹뷰까지 같은 상태가 됐습니다.

최종 차단은 11월 17일입니다. 오리진 트라이얼이나 기업 정책에 등록한 사이트만 예외로 남습니다. 예외는 영구가 아닙니다.

크롬만의 결정도 아닙니다. 파이어폭스의 게코와 웹킷도 제거에 동의했습니다. 마이크로소프트 엣지는 159 버전에서 제거 대상으로 올렸고, 147 버전부터 XSLTEnabled 정책으로 미리 꺼보는 시험을 허용했습니다. 세 엔진이 같은 방향으로 움직이면 피할 곳은 없습니다.

브라우저가 남의 페이지 안에 경고를 심는다

제거를 알리려고 만든 사이트 XSLT.RIP은 그 자체가 XSLT로 만들어졌습니다. 지원이 끊기면 안내 사이트도 같이 깨집니다. 운영자 벤자민 더스헬은 이 점을 일부러 남겨뒀다고 밝혔습니다.

그가 문제 삼는 것은 경고 배너의 위치입니다. 배너 문구는 "이 사이트는 XSLT를 사용하며, 이 기능이 곧 이 브라우저에서 제거됩니다. 그때 이 페이지는 제대로 표시되지 않을 수 있습니다"입니다. 이어서 확장 프로그램을 설치하거나 사이트 관리자에게 문의하라고 안내합니다.

브라우저 화면과 웹 콘텐츠 사이의 경계를 업계에서는 죽음의 선이라고 부릅니다. 브라우저가 남의 페이지 안에 자기 메시지를 넣으면, 독자는 그 화면이 사이트 것이지 브라우저가 끼워 넣은 것인지 구분할 수 없습니다. 글은 이 방식을 중간자 공격에 비유합니다.

배너는 xslt-warning-banner 사용자 정의 요소로 보인다고 글은 적습니다. 사이트의 콘텐츠 보안 정책과 부딪히면 렌더링되지 않습니다. 경고가 아예 안 뜨는 사이트도 있다는 뜻입니다.

깨지면 방문자에게는 이렇게 보인다

브라우저가 변환을 못 하면 XML 원문이 트리로 펼쳐집니다. 태그 이름과 값이 그대로 나오고, 머리말의 스타일시트 지시자는 무시됩니다. 방문자에게는 페이지가 고장 난 것으로 보입니다.

더 조용한 사고도 있습니다. 자바스크립트에서 XSLTProcessor를 호출하던 화면은 오류를 내고 빈 영역을 남깁니다. 오류 문구가 나오지 않으면 운영자는 한참 뒤에야 알게 됩니다.

영향 범위는 대개 세 곳입니다. 사내 게시판과 오래된 CMS의 목록 화면, XML을 그대로 받아 보여주던 문서 뷰어, 브라우저에서 피드를 변환해 그리던 리더입니다. 서버에서 이미 HTML을 만들어 보내는 사이트는 영향이 없습니다.

댓글에서는 "구글 탓만 하기 어렵다"가 나온다

GeekNews에 소개된 로브스티즈 댓글은 비판이 한쪽으로 쏠린다고 봅니다. 모질라와 애플도 수년 전부터 XSLT 제거를 원했고, 구글은 2013년에도 시도했다가 접은 기록이 있다는 것입니다. 구글이 재시도하자 다른 업체가 따라 나선 쪽에 가깝다는 설명입니다.

보안을 주된 이유로 든 점은 의심합니다. "지원 중단을 선언하기도 전에 보안 문제가 거의 없는 대체 확장 프로그램을 만들었다"는 지적입니다. 그럴 거면 그 확장을 브라우저에 넣고 코드를 동결해 유지보수를 없애는 편이 쉬웠을 것이라고 덧붙입니다.

다만 제거 발표 뒤에 브라우저의 XSLT 구현에서 보안 버그가 여러 건 발견된 점은 사실로 인정합니다. 구글이 나서지 않았어도 다른 회사가 몇 년 안에 같은 결정을 했을 것이라는 전망도 붙습니다.

지금 할 일은 세 가지

첫째, 우리 사이트가 XSLT를 쓰는지 확인합니다. 페이지 소스에서 xml-stylesheet 지시자를 찾고, 자바스크립트에서 XSLTProcessor를 호출하는 곳을 검색하면 됩니다.

둘째, 변환을 서버나 빌드 단계로 옮깁니다. 같은 스타일시트를 빌드할 때 돌려 정적 HTML을 만들어 두면 브라우저 기능에 기대지 않습니다. RSS 뷰어처럼 원문 XML을 그대로 받아 그리던 화면은 목록 페이지로 바꾸는 편이 낫습니다.

정적 사이트라면 빌드 스크립트에 변환 단계를 하나 넣는 것으로 끝납니다. 반대로 게시판처럼 요청마다 서버가 XML을 내보내는 구조라면 템플릿 엔진으로 옮기는 작업이 필요합니다. 화면 수가 적은 사이트는 하루 안에 정리되는 경우가 많습니다. 남은 2주 안에 목록화와 이전 계획을 함께 세우는 게 현실적입니다.

셋째, 기업 사이트는 예외 수단을 확인합니다. 기업 정책과 오리진 트라이얼로 시간을 벌 수 있지만 영구 지원은 아닙니다. 브라우저 일정에 맞춰 마이그레이션 날짜를 먼저 잡아야 합니다.

확인은 미리 할 수 있습니다. 엣지 147 이상이나 크롬 기업 정책에서 XSLTEnabled를 꺼 두면 11월 17일 화면을 지금 볼 수 있습니다. 업무용 사내 시스템이라면 이 방법으로 영향 범위를 먼저 목록화하는 게 빠릅니다.

크롬은 XML 파서도 libxml2에서 러스트로 옮길 계획을 함께 예고했습니다. XML을 다루는 코드를 가진 팀이라면 이번에 파싱 경로까지 같이 보는 편이 좋습니다.

XSLT.RIP이 11월 17일 이후 실제로 깨지는지 보는 것도 이번 변경의 크기를 가늠하는 방법입니다. 브라우저가 표준을 접을 때 남는 흔적은 대개 이런 작은 안내 페이지에서 먼저 보입니다.

브라우저가 대신 해주던 변환은 이제 서버가 해야 합니다. 11월 17일은 준비하지 않은 사이트에 통보 없이 오는 마감입니다.

원문 보기 - The coming death of XSLT