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

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

문 덕분에 정상적인 경험을 할 수 있었음

개발자가 확인해야 할 것

웹사이트가 자신도 모르게
특별 렌더링 처리를 받고 있을 수 있음
이런 quirk는 오류 로그에 나타나지 않고, 콘솔에도 “브라우저가 실수를 우회 처리 중”이라는 경고를 띄우지 않음
우회 처리는 의도적으로 보이지 않게 동작함
Chrome 위주로 테스트하는 사이트는 특히 위험함
사이트가 완벽하게 작동하는 이유가 좋은 코드 때문이 아니라, Chrome의 동작이 개발자의 가정과 맞아떨어지기 때문일 수 있음
다른 브라우저는 사이트를 사용자에게 깨진 채로 보여줄지, 아니면 quirks 파일에 추가할지 선택해야 하는 상황이 됨
Firefox와 Safari에서 사이트를 가끔이 아니라 정기적으로 열어봐야 함
quirks 파일은 개발자가 정기적으로 그렇게 하지 않았기 때문에 존재함
자신의 도메인이 quirks 파일에 있다면, 브라우저가 우회 처리한 부분을 점검할 필요가 있음
웹은 개발자 개입 없이도 계속 작동했지만, 사용하지 않는 브라우저의 엔지니어가 개발자가 몰랐던 문제를 대신 해결한 상태일 수 있음