브라우저는 대형 사이트를 다르게 취급한다

16 hours ago 1

Safari와 Firefox는 TikTok, Netflix, Instagram 같은 특정 도메인에서 렌더링과 API 동작을 바꾸는 코드를 배포함
Firefox의 about:compat는 사이트별 개입과 토글을 보여주며, 맞춤 CSS·JavaScript 주입과 사용자 에이전트 위장을 수행함
Safari의 WebKit은 이를 quirks로 관리하며, PiP 비디오·이미지 정렬·팝오버·스트리밍 접근 문제를 도메인별로 우회함
Chrome은 별도 예외 파일이 거의 필요 없는데, 웹이 이미 Chrome 중심으로 만들어져 다른 브라우저가 차이를 보정하기 때문
이런 예외는 로그나 콘솔에 잘 드러나지 않으므로, 개발자는 Firefox와 Safari에서 정기적으로 테스트하고 quirks 파일 포함 여부를 점검해야 함

브라우저 안의 도메인별 예외 처리

Safari와 Firefox는 사용자가 방문한 도메인에 따라 렌더링이나 API 동작을 바꾸는 코드를 배포함
TikTok, Netflix, Instagram, SeatGuru 같은 사이트가 이런 사이트별 처리의 대상이 됨
관련 소스는 WebKit의 Quirks.cpp와 Firefox의 WebCompat interventions에서 공개적으로 확인 가능함
이 코드는 “특정 도메인이면 다르게 렌더링”하거나 “특정 도메인이면 API 호출을 다르게 처리”하는 방식으로 브라우저 렌더링 엔진에 들어가 있음
Chrome은 같은 방식의 예외 파일이 사실상 필요 없으며, 웹이 이미 Chrome 중심으로 만들어진 비대칭이 드러남

Firefox의 about:compat

Firefox 주소창에 about:compat을 입력하면 사이트별 개입 목록과 토글 스위치를 볼 수 있음
각 항목은 특정 웹사이트를 위한 맞춤 수정이며, 끄면 사이트가 깨지는 모습을 확인할 수 있음
Firefox의 WebCompat system은 특정 도메인에 맞춤 CSS와 JavaScript를 주입함
브라우저를 잘못 감지하는 사이트에는 사용자 에이전트 문자열을 바꿔 전달함
이런 개입은 웹이 고장난 것처럼 보이지 않도록 버그를 덮으며, Mozilla Bugzilla에는 버그 리포트와 사이트 연락 시도까지 추적되어 있음

Safari의 quirks

Safari의 WebKit 엔진은 이런 처리를 quirks라고 부르며, Quirks.cpp가 GitHub에 공개되어 있음
WebKit 코드에는 Facebook, X, Reddit이 화면 밖으로 스크롤된 <video>를 PiP 모드 여부와 상관없이 일시정지한다는 주석이 있음
Safari는 facebook.com, x.com, reddit.com을 감지해 Picture-in-Picture 비디오 처리를 바꿈
사이트의 비디오 코드가 깨져 있어도 해당 회사들이 고치기를 기다리지 않고, 브라우저가 모든 사용자에게 우회 처리를 배포함
SeatGuru 관련 주석에는 FIXME: Remove this quirk if seatguru decides to adjust their site.라고 되어 있어, 사이트가 수정되면 예외를 제거할 수 있음을 보여줌
커밋 기록에는 최근 몇 달 사이 여러 사이트별 수정이 들어감
- Zillow의 floorplan 이미지가 가운데 정렬되지 않는 문제
- TikTok의 “please upgrade your browser” 메시지 표시 문제
- Instagram Reels가 재생 중 불규칙하게 크기 조정되는 문제
- Netflix의 “Episodes and Info” 버튼이 팝오버를 잘못 닫는 문제
- Twitch가 탭 전환 시 PiP 비디오를 일시정지하는 문제
- Amazon Prime Video가 Safari 사용자에게 시청을 허용하지 않는 문제

Chrome 중심 웹과 비대칭

WebKit의 quirks와 Firefox의 WebCompat은 깨진 사이트를 고치는 데 그치지 않고, Chrome이 “작동한다”의 기준을 좌우하는 상황도 보정함
일반적으로 Chrome이 기능을 배포하면, 시장 지배력 때문에 개발자가 그 기능을 쓰고, 다른 브라우저가 해당 기능을 구현하거나 사이트별 예외로 차이를 덮게 됨
Safari와 Firefox가 따라잡을 때쯤에는 이미 예외 처리가 수백만 사용자에게 배포된 상태가 됨
WebKit에는 Amazon 비디오 페이지와 여러 스트리밍 서비스에서 Safari가 Chrome인 것처럼 보이게 하는 사용자 에이전트 오버라이드가 포함되어 있음
이런 사이트들은 Chrome 여부를 탐지해 다른 브라우저에 저하된 경험을 제공하므로, WebKit은 Safari 사용자를 보호하기 위해 브라우저 정체성을 속임
현재 Quirks.cpp에는 다음과 같은 가짜 Chrome 사용자 에이전트 문자열이 들어 있음

auto chromeUserAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"_s;

Firefox도 같은 방식으로 동작하며, about:compat의 많은 개입은 사이트에 “나는 Chrome”이라고 알리는 사용자 에이전트 위장임
Mozilla wiki는 일부 사이트가 브라우저 감지 결과에 따라 “접근을 완전히 차단하거나, 다른 디자인을 표시하거나, 다른 기능을 제공한다”고 밝힘
이런 구조는 피드백 루프를 만듦
- 개발자는 Chrome 점유율이 높기 때문에 Chrome을 기준으로 만듦
- 사이트는 Chrome에서 가장 잘 작동함
- 다른 브라우저에서 버그를 만난 사용자는 사이트가 아니라 브라우저를 탓함
- 사용자는 Chrome으로 이동하고, Chrome의 지배력은 더 강화됨
Chrome이 별도의 quirks 파일을 거의 필요로 하지 않는 이유는 Chrome이 더 잘 설계되어서라기보다, 웹이 이미 Chrome에 맞춰져 있기 때문
Chromium 기반 브라우저 사용자가 80%를 넘는 상황에서는 개발자가 Chrome을 먼저 대상으로 삼음
사이트가 Chrome에서 작동하면 배포되고, Safari나 Firefox에서 깨지면 그 문제의 우선순위가 낮아짐
Chrome은 예외를 추가하기보다 의제를 설정함
Chrome이 어떤 동작을 바꾸면 사이트가 그에 맞춰 업데이트되고, 다른 브라우저는 따라가거나 깨짐

명세와 실제 웹 사이의 간극

브라우저 엔지니어들은 현재 명세가 잘 정의되어 있으며, HTML5의 “living specification” 접근이 IE/Netscape 시대의 혼란을 줄였다고 볼 수 있음
문제는 개발자들이 명세에 없는 구현 세부사항에 의존하고, 그 세부사항이 다른 브라우저에서 다르면 비준수 브라우저를 탓한다는 데 있음
Chrome의 구현이 모두가 대상으로 삼는 기준이 되면, Chrome의 명세 밖 세부 동작이 사실상의 명세가 됨
2000년대 Internet Explorer 때도 개발자가 IE에 맞춰 사이트를 만들면서 다른 브라우저에서 사이트가 깨졌고, 표준 준수보다 “IE에서 작동”이 우선이 됨
과거에는 웹이 표준을 더 잘 지키면 브라우저 quirks가 사라질 것으로 기대했지만, 실제로는 quirks가 사라진 것이 아니라 Chrome이 아닌 브라우저로 이동한 셈
표준은 브라우저별 코드를 없애기 위해 존재했지만, IE 시대를 빠져나온 뒤 다른 브라우저를 중심으로 같은 구멍이 다시 만들어짐
이제 브라우저별 코드는 지배적인 브라우저가 아니라, 지배적인 브라우저에 맞춰진 웹을 보정하는 비지배 브라우저 안에 들어가 있음

예외 처리는 생각보다 깊다

이런 처리는 단순한 시각적 조정에 그치지 않고, 도메인에 따라 브라우저의 기본 동작을 바꿈
WebKit의 목록만 해도 수천 줄에 달하며, 스크롤 동작, 터치 이벤트 처리, 뷰포트 계산, 이미지 MIME 타입 처리까지 포함함
Amazon 제품 이미지 확대 기능을 위한 주석에는 다음과 같은 내용이 있음

When panning on an Amazon product image, we’re either touching on the #magnifierLens element or its previous sibling.

Safari는 Amazon에 접속했는지 확인한 뒤, 제품 확대 기능을 위해 터치 이벤트를 마우스 이벤트로 변환하는 방식을 바꿈
Amazon 사이트가 Safari 기본 동작과 다른 특정 이벤트 동작을 가정하기 때문에, Safari가 Amazon에 대해서만 그 동작을 제공함
storage access, 스크롤바 렌더링, 자동 교정 동작, 확대/축소 처리에도 도메인별 quirks가 있음
각 예외는 도메인 검사 뒤에 있으며, 브라우저 실행 파일 안에 컴파일됨

기다리기보다 브라우저가 직접 고치는 이유

브라우저 벤더가 문제 사이트에 연락해 수정을 요청하는 경우도 있으며, 소스 코드에는 outreach 노력이 링크된 필드도 있음
하지만 인기 사이트가 Chrome에서는 작동하고 자사 브라우저에서는 깨지면 사용자는 사이트가 아니라 브라우저를 탓함
제3자에게 버그를 제출하고 몇 주 또는 몇 달을 기다리는 것보다, 다음 날 5줄짜리 우회 처리를 배포하는 편이 브라우저 입장에서는 더 실용적임
누구에게 연락해야 하는지도 분명하지 않을 수 있음
- 깨진 코드를 작성한 개발자가 이미 회사를 떠났을 수 있음
- 해당 엔드포인트를 소유한 팀이 책임을 인식하지 못할 수 있음
- 사이트가 보안 패치만 받는 유지보수 모드일 수 있음
브라우저 입장에서는 즉시, 보이지 않게 고쳐 사용자 문제를 줄이는 선택이 단순함
WebKit 엔지니어가 FlightAware quirk 제거 과정을 다룬 글도 있음
FlightAware는 CSS transform matrix 문자열을 비교하고 있었고, CSS 명세가 값 직렬화 방식을 바꾸면서 브라우저가 명세를 따르자 사이트가 깨짐
엔지니어들은 flightaware.com을 검사하는 도메인별 코드를 추가했고, 이후 연락이 성공해 FlightAware가 코드를 고치면서 quirk가 제거됨
그 몇 달 동안 Safari 사용자는 브라우저 안의 if문 덕분에 정상적인 경험을 할 수 있었음