보이지 않는 패치: 브라우저가 도메인별 퀴르크를 사용해 웹을 구하는 방법

현대 웹은 종종 표준화의 성공 사례로 제시됩니다. 우리는 HTML5의 "생명 사양"이 브라우저 전쟁을 끝내고, Safari, Firefox, Chrome 중 어느 것을 사용하든 웹사이트가 동일하게 보이고 동작하도록 하는 보편적인 언어를 만들었다고 듣습니다.

하지만 브라우저 엔진의 내부를 들여다보면 전혀 다른 현실이 드러납니다. 세계에서 가장 인기 있는 웹사이트들의 경우, "표준"은 종종 완전히 무시되고 하드코딩된 도메인별 개입으로 대체됩니다. TikTok, Netflix, Instagram, 심지어 SeatGuru까지, 우리가 매일 방문하는 많은 사이트는 일반 규칙에 따라 렌더링되는 것이 아니라, 브라우저 소스 코드에 직접 삽입된 일련의 "퀴르크"—깨진 사이트 로직을 고치기 위한 수동 오버라이드—에 의해 동작합니다.

브라우저 퀴르크의 메커니즘

주요 웹사이트가 웹 표준을 위반하거나 특정 브라우저의 비표준 동작에 의존하는 코드를 배포하면, 다른 브라우저에서는 종종 깨집니다. 사이트 소유자가 버그를 수정하기를 기다리는 대신(수개월이 걸리거나 전혀 이루어지지 않을 수도 있음), 브라우저 공급업체가 직접 문제를 해결하기도 합니다.

Firefox의 WebCompat

Firefox는 WebCompat라는 시스템을 활용합니다. Firefox 브라우저에서 about:compat에 접속하면 사이트별 개입 목록을 실제로 확인할 수 있습니다. 이 시스템을 통해 Mozilla는 특정 도메인에 맞춤 CSS와 JavaScript를 주입하거나, 브라우저를 잘못 "스니핑"하는 사이트를 위해 사용자 에이전트 문자열을 변경할 수 있습니다. 이러한 개입은 Bugzilla를 통해 추적되며, 브라우저 팀이 사이트 소유자에게 연락을 시도했지만 실패한 경우가 문서화됩니다.

Safari의 Quirks.cpp

Safari를 구동하는 WebKit 엔진에서는 이러한 수정이 Quirks.cpp라는 파일에 보관됩니다. 이 파일은 웹 취약성의 흥미로운 아카이브입니다. 여기에는 본질적으로 다음과 같은 로직이 들어 있습니다: "사용자가 facebook.com, x.com, reddit.com에 있을 경우, Picture-in-Picture 비디오를 다르게 처리한다. 왜냐하면 이 사이트들은 비디오가 화면 밖으로 스크롤될 때 영상을 무작정 일시 정지하기 때문이다."

최근 커밋 기록을 보면 이러한 패치가 끊임없이 추가되고 있음을 알 수 있습니다: Zillow의 평면도 이미지를 중앙에 배치, TikTok의 "브라우저를 업그레이드하세요" 메시지 수정, Instagram Reels의 재생 크기 조정 문제 해결 등. 눈에 띄는 사례로는 SeatGuru에 대한 퀴르크가 추가된 경우가 있는데, 사이트가 코드를 조정하기를 거부해 소스 코드에 FIXME 주석이 남겨졌습니다: "SeatGuru가 사이트를 조정하면 이 퀴르크를 제거하세요."

Chrome의 비대칭성

가장 눈에 띄는 관찰 중 하나는 Chrome이 유사하고 방대한 도메인별 퀴르크 목록을 유지하지 않는다는 점입니다. 이는 반드시 Chrome이 더 잘 설계되었기 때문은 아니며, 압도적인 시장 점유율 때문입니다.

Chromium 기반 브라우저가 시장을 장악하고 있기 때문에 개발자들은 먼저 Chrome용으로 개발합니다. 사이트가 Chrome에서 동작하면 "완료"된 것으로 간주됩니다. 이는 위험한 피드백 루프를 만들죠:

Chrome이 기능이나 특정 구현 세부 사항을 제공한다.
개발자들이 이를 채택한다(지배적인 브라우저에서 동작하기 때문에).
다른 브라우저는 동일한 세부 사항을 구현하거나 차이를 메우기 위해 "퀴르크"를 추가해야 한다.

이 비대칭성 때문에 Chrome의 웹 표준 해석이 사실상의 사양이 됩니다. Safari나 Firefox 사용자가 버그를 만나면 웹사이트가 아니라 브라우저를 비난하게 됩니다. 사용자가 Chrome으로 전환하는 것을 방지하기 위해 Safari와 Firefox 엔지니어는 오버라이드를 작성합니다. 경우에 따라 Safari는 가짜 Chrome 사용자 에이전트 문자열을 전송해 웹사이트가 기능적인 페이지를 제공하도록 속이기도 합니다.

보이지 않는 수정의 경제학

개발자에게 코드를 고치라고 요청하지는 왜 안 될까요? 브라우저 공급업체 입장에서는 경제성이 간단합니다: 내일 배포되는 5줄짜리 우회 코드가 제3자에게 버그 리포트를 보내는 것보다 낫습니다(그 리포트가 읽히지 않을 수도 있기 때문).

예를 들어, WebKit 엔지니어가 FlightAware에 대한 퀴르크를 상세히 설명한 사례가 있습니다. 해당 사이트는 CSS 변환 매트릭스 문자열을 특정 방식으로 직렬화하던데, 브라우저가 새로운 사양에 맞게 준수하게 되면서 FlightAware가 깨졌습니다. Safari 엔지니어는 사용자가 사이트를 계속 이용할 수 있도록 도메인별 수정을 추가했습니다. 결국 FlightAware가 코드를 고쳐 퀴르크가 제거되었지만, 몇 달 동안 사용자 경험은 브라우저 소스 코드의 if 문 하나에 의해 유지되었습니다.

개발자에게 주는 위험

평균적인 웹 개발자에게 이러한 퀴르크는 조용한 함정입니다. 사이트를 주로 Chrome에서 테스트한다면 완벽히 동작하는 것처럼 보일 수 있습니다. 하지만 실제로는 Safari나 Firefox에 존재하는 퀴르크 덕분일 수도 있습니다. 여러분의 사이트가 "작동"하는 이유는 깔끔한 코드 때문이 아니라, 브라우저 엔지니어가 여러분이 몰랐던 문제를 해결했기 때문입니다.

이는 특히 새로운 플랫폼에 위험합니다. 일부 관찰자들은 claude.ai와 같은 신규 사이트조차 퀴르크 파일에 등장했다고 지적했으며, 이는 협업보다 패치를 선호하는 경향이 가속화되고 있음을 시사합니다.

결론: 지도와 지형

웹 사양은 지도이지만, 퀴르크 목록은 뒤섞인 지형입니다. 우리는 "Internet Explorer 호환성" 시대에서 비지배 브라우저가 호환성 부담을 짊어지는 시대로 이동했습니다.

Quirks.cpp 파일에 한 줄이라도 남지 않으려면, 개발자는 Chrome 중심 테스트를 넘어야 합니다. Safari와 Firefox에서 정기적으로 사이트를 감사하는 것이, 여러분의 사이트가 실제로 웹 표준을 준수하고 있는지, 아니면 단지 실행을 유지하기 위해 누군가가 패치한 것인지 확인하는 유일한 방법입니다.