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

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

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

웹 개발자라면 한 번쯤 경험해본 적 있을 것이다. Chrome에서는 완벽하게 작동하는 사이트가 Safari나 Firefox에서는 이상하게 표시되거나 기능이 깨지는 경우. 이를 "브라우저 버그" 탓으로 돌리지만, 실제로는 브라우저가 우리 몰래 수선을 하고 있는 것일 수 있다.

숨겨진 도메인별 예외 처리

Safari와 Firefox는 특정 도메인에 접속하면 렌더링이나 API 동작을 바꾸는 코드를 내부에 포함하고 있다. TikTok, Netflix, Instagram, 심지어 SeatGuru까지. 이 목록은 공개된 소스 코드에서 직접 확인할 수 있다.

Safari의 WebKit 엔진은 이런 처리를 "quirks"라고 부르며, Quirks.cpp 파일이 GitHub에 공개되어 있다. Firefox는 주소창에 about:compat을 입력하면 사이트별 개입 목록과 토글 스위치를 볼 수 있다. 각 항목은 특정 웹사이트를 위한 맞춤 수정이고, 끄면 사이트가 깨지는 모습을 직접 확인할 수 있다.

최근 몇 달 사이 커밋 기록에만 이런 수정이 들어갔다. Zillow 층별 이미지 중앙 정렬 문제, TikTok 브라우저 업그레이드 요구 메시지, Instagram Reels 재생 중 크기 불규칙 조정, Netflix 에피소드 버튼 팝오버 잘못 닫힘, Twitch 탭 전환 시 PiP 비디오 일시정지, Amazon Prime Video Safari 사용자 시청 차단 등. 모두 도메인별 맞춤 처리로 수백만 사용자에게 배포되었다.

Chrome은 왜 별도 예외가 필요 없는가

Firefox의 WebCompat과 Safari의 Quirks.cpp는 깨진 사이트를 고치는 것에 그치지 않는다. 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";

Safari는 사이트가 거부할 경우 투입할 가짜 Chrome 신분을 미리 준비하고 있는 셈이다. Firefox도 같은 방식으로 동작한다.

피드백 루프가 지배력을 강화한다

개발자는 Chrome 점유율이 높기 때문에 Chrome을 기준으로 사이트를 만든다. 사이트는 Chrome에서 가장 잘 작동한다. 다른 브라우저에서 버그를 만난 사용자는 사이트가 아니라 브라우저를 탓한다. 사용자는 Chrome으로 이동하고, Chrome의 지배력은 더 강화된다.

2000년대 Internet Explorer 시절도 정확히 같은 구조였다. 개발자가 IE에 맞춰 사이트를 만들면서 다른 브라우저에서 사이트가 깨졌고, 표준 준수보다 "IE에서 작동"이 우선이었다. 수십 년이 지난 지금, 같은 구멍이 Chrome을 중심으로 다시 만들어졌을 뿐이다.

이전에는 웹이 표준을 더 잘 지키면 브라우저quirks가 사라질 것으로 기대했지만, 실제로는 quirks가 사라진 것이 아니라 Chrome이 아닌 브라우저로 이동했다.

단순한 시각적 문제가 아니다

이런 처리는 스크롤 동작, 터치 이벤트 처리, 뷰포트 계산, 이미지 MIME 타입 처리까지 포함한다. Amazon 제품 이미지 확대 기능에 관한 주석은 이러하다.

"Amazon 제품 이미지에서 패닝할 때, 우리는 #magnifierLens 요소나 그 이전 형제 요소를 터치하고 있다."

Safari는 Amazon 접속을 감지한 뒤, 제품 확대 기능을 위해 터치 이벤트를 마우스 events로 변환하는 방식을 바꾼다. Amazon 사이트가 Safari 기본 동작과 다른 특정 events 동작을 가정하기 때문이다.

storage access, 스크롤바 렌더링, 자동 교정 동작, 확대 축소 처리에도 도메인별 quirks가 있다. 각 예외는 도메인 검사 뒤에 있으며, 브라우저 실행 파일 안에 컴파일된다.

기다리기보다 직접 고치는 이유

브라우저 벤더가 문제 사이트에 연락해 수정을 요청하는 경우도 있다. 소스 코드에는 outreach 노력이 링크된 필드도 있다. 하지만 인기 사이트가 Chrome에서는 작동하고 자사 브라우저에서는 깨지면, 사용자는 사이트가 아니라 브라우저를 탓한다.

제3자에게 버그를 제출하고 몇 주 또는 몇 달을 기다리는 것보다, 다음 날 다섯 줄짜리 우회 처리를 배포하는 편이 브라우저 입장에서는 더 실용적이다. 누구에게 연락해야 하는지도 분명하지 않을 수 있다. 깨진 코드를 작성한 개발자가 이미 회사를 떠났을 수 있고, 해당 엔드포인트를 소유한 팀이 책임을 인식하지 못할 수 있다.

WebKit 엔지니어가 FlightAware quirk 제거 과정을 다룬 글이 있다. FlightAware는 CSS transform matrix 문자열을 비교하고 있었고, CSS 명세가 값 직렬화 방식을 바꾸면서 브라우저가 명세를 따르자 사이트가 깨졌다. 엔지니어들은 flightaware.com을 검사하는 도메인별 코드를 추가했고, 이후 연락이 성공해 FlightAware가 코드를 고치면서 quirk가 제거되었다. 그 몇 달 동안 Safari 사용자는 브라우저 안의 if문 덕분에 정상적인 경험을 할 수 있었다.

개발자가 확인해야 할 것

자신의 웹사이트가 개발자도 모르게 특별 렌더링 처리를 받고 있을 수 있다. 이런 quirk는 오류 로그에 나타나지 않고, 콘솔에도 "브라우저가 실수를 우회 처리 중"이라는 경고를 띄우지 않는다. 우회 처리는 의도적으로 보이지 않게 동작한다.

Chrome 위주로 테스트하는 사이트는 특히 위험하다. 사이트가 완벽하게 작동하는 이유가 좋은 코드 때문이 아니라, Chrome의 동작이 개발자의 가정과 맞아떨어지기 때문일 수 있다.

Firefox와 Safari에서 사이트를 가끔이 아니라 정기적으로 열어봐야 한다. Quirks 파일은 개발자가 정기적으로 그렇게 하지 않았기 때문에 존재한다. 자신의 도메인이 quirks 파일에 있다면, 브라우저가 우회 처리한 부분을 점검할 필요가 있다.

웹은 개발자 개입 없이도 계속 작동했지만, 사용하지 않는 브라우저의 엔지니어가 개발자가 몰랐던 문제를 대신 해결한 상태일 수 있다.

---

핵심 정리

• Safari와 Firefox는 수천 개 도메인에 대해 렌더링 예외 처리를 포함

• Quirks는 단순한 미관 개선이 아니라 브라우저의 근본 동작을 도메인별로 바꿈

• Chrome이 별도의 quirks 파일을 거의 필요로 하지 않는 이유는 Chrome이 더 잘 설계되어서가 아니라 웹이 이미 Chrome에 맞춰져 있기 때문

• 개발자는 최소한 Safari와 Firefox에서 정기적으로 사이트를 테스트해야 함

• Quirks 파일에 자신의 도메인이 포함되어 있다면 해당 우회 처리가 무엇인지 점검할 것

출처

• 원문: Browsers Treat Big Sites Differently — Den Odell

---

📚 출처

• https://news.hada.io/topic?id=29513