Chrome이 또 google.com만 남겼다 — 버그인가 구조인가
Chrome이 또 google.com만 남겼다 — 버그인가 구조인가
브라우저가 자기 회사 사이트만 데이터 삭제 설정에서 빠뜨렸다. 이것은 QA의 실패인가, 아니면 QA가 볼 이유가 없는 구조의 산물인가?
도입
2026년 9월 5일, 개발자 제프 존슨(Jeff Johnson)이 짧은 글 하나를 올렸다. 제목은 「Chrome이 또 사용자 사이트 데이터 설정에서 Google을 예외 처리한다」였다. 해커뉴스에서 618점을 받았다.
내용 자체는 복잡하지 않다. Chrome에는 chrome://settings/content/siteData에서 켤 수 있는 설정이 있다. 「모든 창을 닫으면 사이트가 기기에 저장한 데이터를 삭제」하는 옵션이다. 존슨은 이 설정을 기본 동작으로 켜 두고, Chrome에 로그인하지 않았으며, 로그인 자체를 금지해 두었다. 혼선을 없애려고 기본 검색 엔진도 Google에서 DuckDuckGo로 바꿨다. 그런 상태에서 Google 검색을 한 번 하고, 유일한 창을 닫고, 다시 설정 화면을 열었다.
google.com의 사이트 데이터가 남아 있었다. 쿠키와 로컬 스토리지, 세션 스토리지였다. Chrome을 완전히 종료했다 재실행해도 남았다. 지우고 같은 절차를 반복하면 다시 생겼다. 존슨이 확인한 범위에서 예외 처리된 사이트는 www.google.com 하나뿐이었다.
이 글이 618점을 받은 이유는 발견 자체의 기술적 난도 때문이 아니다. 존슨은 6년 전에 사실상 같은 글을 썼고, 그때 Google은 버그를 고쳤다. 고쳐진 것이 돌아왔다는 사실이 핵심이다.
재현된 것과 재현되지 않은 것
먼저 사실 관계를 정리해 두자. 존슨이 실제로 확인했다고 적은 것은 다음과 같다.
Chrome 버전은 152.0.7977.83이고, 서로 다른 두 대의 Mac에서 재현했다. 설정 화면 chrome://settings/content/all에서 사전에 저장된 사이트 데이터가 없음을 확인했고, 사후에 google.com 항목이 생긴 것을 확인했다. 저장 위치는 ~/Library/Application Support/Google/Chrome/Default 폴더이며, 남은 데이터의 종류는 쿠키·로컬 스토리지·세션 스토리지였다.
반대로 존슨이 확인하지 않았다고 스스로 밝힌 것도 있다. 이 문제가 언제 유입되었는지는 모른다고 적었다. 그의 기본 브라우저는 Safari이고 Chrome은 테스트 용도로만 자주 쓰기 때문이다. 그리고 의도성에 대해서도 단정하지 않았다. 「나는 음모론을 펴기보다 핸런의 면도날을 인용하는 쪽에 가깝다」고 명시했다. 악의로 설명되는 것을 무능으로 충분히 설명할 수 있다면 무능 쪽을 택한다는 원칙이다.
6년 전 사건과의 대조도 원문에 적혀 있다. 존슨은 당시 「Chrome이 사용자 사이트 데이터 설정에서 Google 사이트를 예외 처리한다」는 글을 썼고, 그 글이 상당한 주목을 받았다고 밝힌다. 그가 직접 나열한 반향은 Michael Tsai, 해커뉴스, The Register, The Verge, Gizmodo였다. 그리고 그 보고에 자극을 받아 결국 Google이 버그를 고쳤다고 적었다. 즉 이번 글의 제목에 붙은 「또」는 수사가 아니라 기록이다. 같은 사람이, 같은 설정에서, 같은 방향의 예외를 두 번 발견했다.
차이도 있다. 6년 전에는 Google 소유 사이트들이 묶여서 예외 처리되었지만, 이번에 존슨이 확인한 범위에서는 www.google.com 단 하나였다. 범위가 좁아진 것이 수정의 잔재인지 새로운 경로의 부작용인지는 외부에서 판별할 수 없다. 다만 좁아졌다는 사실 자체가 이 현상이 무작위가 아님을 시사한다. 무작위 결함이 6년 간격으로 두 번 모두 같은 도메인 계열에만 들어맞을 확률은 높지 않다.
이 구분은 중요하다. 이런 종류의 발견은 곧바로 「Google이 몰래 추적한다」는 결론으로 번역되기 쉽지만, 원문 저자 본인이 그 번역을 거부했기 때문이다. 대신 그는 다른 지점을 찔렀다. 이 회사와 이 회사 엔지니어들이 버는 돈의 규모를 생각하면 무능도 변명이 되지 않는다는 것이다. 그가 제안한 대응책은 음모론적이지 않다. 이 기능에 대한 유닛 테스트를 좀 붙이라는 것, 그리고 「빠르게 움직이고 무언가를 부수지」 말고 천천히 움직이고 부수지 말라는 것이었다.
해커뉴스 토론에서는 기술적 반론도 나왔다. 한 이용자는 모든 Chrome 프로세스가 테스트 사이에 실제로 종료되었는지부터 확인해야 한다고 지적했다. 좀비 프로세스가 남아 있으면 데이터가 살아남는 것은 당연하다는 것이다(@mgiampapa). 합리적인 의심이다. 다만 이에 대한 반박도 즉시 나왔다. 그렇다면 왜 하필 Google의 데이터만 세션을 넘어 보존되느냐는 것이다. 어딘가에서 Google이 자사 데이터를 특권화하고 있으며, 브라우저가 전부 지우도록 설정된 상태에서 그것만 삭제되지 않고 있다는 반론이다(@freeAgent).
또 하나 짚을 만한 지적은 Chrome과 Chromium의 분리다. Chrome은 Chromium과 달리 Google의 비공개 소스 소프트웨어라는 것이다(@thinker34). 즉 이 예외 처리가 오픈소스 쪽 코드에 있는지 여부를 외부에서 읽어 확인할 방법이 없다. 재현은 되지만 원인 코드는 감사되지 않는다.
왜 하필 이 버그가 반복되는가
핵심 질문으로 가자. 무능이라고 치자. 그런데 왜 무능은 매번 같은 방향으로 기울어지는가.
소프트웨어에는 버그가 있다. 그 자체는 뉴스가 아니다. 뉴스가 되는 것은 버그의 분포다. 만약 사이트 데이터 삭제 기능에 무작위한 결함이 있다면, 예외로 남는 사이트는 무작위여야 한다. 어느 날은 위키백과가 남고 어느 날은 어떤 블로그가 남아야 한다. 그런데 존슨이 확인한 범위에서 남은 것은 www.google.com 하나였고, 6년 전 같은 계열의 버그에서도 남은 것은 Google 소유 사이트들이었다.
여기서 필요한 것은 의도에 대한 추측이 아니라 구조에 대한 관찰이다. 대형 브라우저 코드베이스에는 자사 서비스를 위한 특수 처리 경로가 실제로 존재한다. 로그인 상태 동기화, 동의 관리, 검색 기능 통합, 안전 브라우징 같은 기능들은 특정 오리진을 다르게 다뤄야 하는 정당한 이유를 가진다. 문제는 이런 경로가 늘어날수록, 「모든 사이트 데이터를 지운다」는 단순한 사용자 약속과 충돌할 표면적도 함께 늘어난다는 점이다. 그리고 그 충돌은 한쪽으로만 기운다. 특수 처리는 언제나 자사 오리진에 붙지, 제3자 오리진에 붙지 않기 때문이다.
테스트 관점에서도 비대칭이 생긴다. 이런 결함을 잡으려면 「설정을 켠 뒤 Google에 로그인하지 않은 상태로 검색하고 창을 닫았을 때 잔류 데이터가 0이어야 한다」는 형태의 검사가 필요하다. 그런데 이 검사를 작성하려면 먼저 그 시나리오를 의심해야 한다. 사내 개발자 대부분은 로그인한 상태로, Google을 기본 검색 엔진으로 두고 쓴다. 존슨이 굳이 기본 검색 엔진을 DuckDuckGo로 바꾸고 로그인을 금지해 가며 테스트한 조건은, 사내에서는 아무도 매일 밟지 않는 경로다. 검사되지 않는 경로는 결함이 축적되는 경로가 된다.
그래서 핸런의 면도날을 받아들여도 결론은 크게 달라지지 않는다. 의도가 없어도 결과는 편향된다. 이해가 걸린 쪽의 코드 경로가 더 많고, 그 경로를 밟는 테스트는 더 적기 때문이다. 이것을 개인의 악의로 설명할 필요는 없다. 다만 「그러니 괜찮다」는 결론도 따라 나오지 않는다. 사용자가 받은 약속은 「우리는 악의가 없습니다」가 아니라 「모든 창을 닫으면 데이터를 삭제합니다」였다.
해커뉴스 토론의 상당 부분이 미국 정치 진영 논쟁으로 흘러간 것도 이 구조를 보여 준다. 한 이용자는 판결과 규제의 한계를 짚으며, 어느 쪽이 집권하든 대형 사업자의 이해가 대표된다는 점이 문제라고 적었다(@shevy-java). 또 다른 이용자는 감시 자본주의를 규탄하는 사람들이 정작 그 기반을 만들고 유지하는 것은 이 게시판을 읽는 엔지니어들이라고 지적했다(@usr1106). 규제가 느리게 움직이는 동안 실제 기본값을 정하는 것은 코드를 쓰는 사람들이라는 이야기다.
검증 가능성이 남은 유일한 방어선이다
이 사건에서 실무자가 가져갈 것은 「Chrome을 쓰지 말라」는 권고가 아니다. 더 이전 단계의 교훈이다.
첫째, 설정 UI는 동작의 증거가 아니다. 존슨의 절차에서 결정적이었던 것은 설정 화면이 「삭제함」이라고 표시했다는 사실이 아니라, 디스크의 프로필 폴더와 chrome://settings/content/all 목록을 직접 열어 잔류물을 셌다는 사실이다. 프라이버시 설정을 다루는 제품을 만들거나 도입 심사를 한다면, 토글의 존재가 아니라 토글을 켠 뒤 남는 바이트를 검사 대상으로 삼아야 한다. 켜 두었다는 진술과 지워졌다는 관측은 다른 종류의 증거다.
둘째, 이런 검사는 음성 대조를 동반해야 의미가 있다. 「잔류 데이터가 0건이다」라는 검사는 검사 자체가 고장 나도 통과한다. 목록을 읽지 못하는 스크립트는 언제나 0건을 보고한다. 반드시 남아야 하는 조건, 예컨대 삭제 설정을 끈 상태에서 같은 절차를 돌려 실제로 데이터가 검출되는지 먼저 확인해야, 0건이라는 결과가 의미를 얻는다. 존슨이 데이터를 지우고 절차를 반복해 재발을 확인한 것이 사실상 이 역할을 했다.
셋째, 감사 가능성의 격차를 기록해 둘 필요가 있다. Chromium은 읽을 수 있고 Chrome은 읽을 수 없다는 지적은 이 사안의 한계를 정확히 짚는다. 외부 관찰자가 할 수 있는 것은 블랙박스 재현뿐이다. 그래서 존슨 같은 개인 개발자의 재현 보고가 실질적인 감사 기능을 대신하고 있다. 6년 전 그의 글이 수정으로 이어졌다는 사실은 이 경로가 작동한다는 증거인 동시에, 이 경로 말고는 별게 없다는 증거이기도 하다.
넷째, 이 사안을 「프라이버시 뉴스」가 아니라 「계약 위반 여부」로 읽는 편이 실무에 가깝다. 기업 환경에서 브라우저 설정은 종종 정책으로 강제되고, 그 정책은 감사 대상이 된다. 「세션 종료 시 사이트 데이터 삭제」를 조직 정책으로 배포해 두었는데 특정 오리진이 예외라면, 그것은 취향의 문제가 아니라 준수 항목의 실패다. 그리고 그 실패는 설정 화면을 아무리 들여다봐도 드러나지 않는다. 정책 배포 후 실제 프로필 디렉터리를 표본 검사하는 절차가 없다면, 조직은 켜 두었다는 사실만 알고 지워졌는지는 모르는 상태로 운영된다.
전망은 낙관과 비관이 갈린다. 낙관적으로 보면 이번에도 보도가 확산되었으니 수정될 가능성이 높다. 비관적으로 보면 6년 만에 같은 결함이 돌아왔다는 것은 수정이 회귀 테스트로 굳어지지 않았다는 뜻이다. 현실적인 시나리오는 이 둘의 조합이다. 이번 건은 고쳐지고, 몇 년 뒤 비슷한 것이 다시 나타난다. 수정은 개별 결함에 들어가고 구조는 그대로이기 때문이다.
결론
이 사건에서 가장 중요한 문장은 발견자 본인이 쓴 것이다. 그는 음모론 대신 핸런의 면도날을 택했고, 동시에 이 회사에는 무능이라는 변명도 허용되지 않는다고 적었다. 두 문장은 모순이 아니다. 의도를 묻는 대신 결과에 책임을 묻는 방식이다.
브라우저는 사용자를 대신해 웹과 협상하는 대리인이다. 그 대리인이 특정 사이트의 소유자와 같은 회사일 때, 이해 충돌은 예외적 사건이 아니라 상시 조건이 된다. 상시 조건을 개별 버그 수정으로 관리하는 데는 한계가 있다. 필요한 것은 「이번에는 고쳤다」가 아니라 「다음에도 검출된다」를 보장하는 회귀 검사이며, 그것이 공개되지 않는다면 최소한 외부에서 재현 가능한 절차라도 남아야 한다.
당신이 쓰는 브라우저에서 같은 절차를 밟으면 무엇이 남는가. 설정을 켜고, 로그인하지 않고, 검색을 한 번 하고, 창을 닫은 뒤 프로필 폴더를 열어 보라. 확인해 보지 않은 설정은 켜져 있다는 진술일 뿐 지워졌다는 증거가 아니다.
출처: