Accept-Language 간소화의 맹점

date
Apr 11, 2025
slug
reduce-accept-language-risks
status
Published
tags
Korean
Web
summary
Google의 Privacy Sandbox에서 제안하고 있는 Accept-Language 간략화의 문제점에 대한 간단한 정리.
type
Post
주: 아래 내용은 저자의 고용주의 공식적인 입장이 아니며, 개인적인 의견입니다. 보다 흥미로운 논쟁은 여기에.
Google의 Privacy Sandbox 프로젝트에서, 웹 브라우징 시 발생하는 의도치 않게 정밀하게 사용자 식별이 가능한 엔트로피 원(entropy source)을 줄이려는 노력의 일환으로, Accept-Language의 극단적인 간소화를 하려는 제안이 올라왔다. 대부분의 사용자는 뭐가 바뀌었는지 모르고 지나갈 수도 있는 변화지만 상대적으로 사용 인구가 적은 언어를 사용하거나, 다국어 구사자의 경우 하루 아침에 평소에 방문하던 선량한 웹사이트들이 익숙하지 않은 언어로 나오는 부작용이 있을 수 있어, 이에 대한 우려점을 몇 가지 사례를 예로 정리해보았다. 조금 더 심도있는 배경은 하기 내용을 참고.

이 문제를 발견하게 된 배경

회사에서 업무용으로 사용하는 컴퓨터에 설치된 Chrome에, 이상한 버그로 언어 우선 순위 설정을 무시하고 스웨덴어가 최상위 언어로 올라가는 문제가 있다. 현재 회사 컴퓨터의 언어 설정은 아래와 같은데,
  • ko-KR
  • ja-JP
  • sv-SE
  • en-US
4위인 스웨덴어가 어째서인지 Accept-Language에서는 최상위로 올라가는 희한한 버그가 있어, 상당수의 사이트가 스웨덴어로 표시되는 난처한 상황이다. 업무상 약간의 불편함이 있지만, 원인이 밝혀지기 전까지 설정을 손댔다가 진단이 불가능해질 것 같아 울며 겨자먹기로 방치한 상태다. 결과적으로, 버그와 상기 제안이 합쳐지면 웹사이트에는 다음과 같이 선호 언어가 전달된다.
  • sv-SE
  • ko-KR
  • ja-JP
  • en-US
다행히도, Google Workspace를 제외한, 내가 방문하는 웹사이트의 대부분은 스웨덴어를 지원하지 않는다. 덕분에 대부분 사이트를 한국어로 표시된다. 여기까지는 좋은데, 상기 기능의 실험군에 들어가면서 (Chrome의 대부분 신규 기능은 Finch라는 실험 프레임워크를 이용하여, 일부 사용자에게만 제공 되고 해당 실험 결과에 따라 데이터를 기반으로 출시 여부를 결정한다. 자세한 내용은 여기에) 한국어로 나오던 사이트가 갑자기 영어로 나오는 이상한 현상을 목격하게 되어서 들여다보게 되었다. (가장 먼저 이상한 점을 알아차린 곳은 네이버 인증.)
이는, 다름 아닌 네이버에 전달된 선호 언어가 다음과 같았기 때문이다.
  • sv-SE
당연한 이야기지만, 네이버는 스웨덴어를 지원하지 않고, 덕분에 스웨덴어 실패후 나와야할 한국어가 없으니, 대체 언어로 영어가 올라오게 된 것으로 보인다. 실제로 이 기능을 실험군에 들어가지 않고 확인해보고 싶다면, 개인정보 보호 브라우징을 (Ctrl+Shift+N / Cmd+Shift+N) 이용해서 개발자 툴 또는 echo.opera.com으로 헤더를 확인해볼 수 있다.

지역 언어 입장에서의 불편함

현 직장 팀의 과반수가 어쩌다 보니 대만(중화민국)에 있어, 쉬운 사례로 중국어 번체를 (國과 国 중 전자가 번체) 사용하는 대만의 사례가 떠올랐다. 예를 들면, 영어를 아예 읽지 못하는 사용자가 아래와 같이 언어 선호 설정이 되어있다고 가정을 해보자.
  • zh-TW (중국어 번체)
  • zh-CN (중국어 간체)
  • ja-JP
이 경우, 사이트에서 번체를 지원할 경우, 번체를 제공하고, 그게 실패할 경우 간체를 제공하게 된다. 그 마저도 없는 경우라면 글의 일부라도 한자로 나오는 일본어로 웹페이지를 볼 수 있게 된다. 다소 불편한 역사적인 이유로, 일본어를 구사할 수 있는 장년층도 있으니, 그냥 지어낸 사례는 아니다. 이 설정을 가지고 해당 제안이 모든 사용자에게 적용되기 시작한다면 어떻게 될까? 아래와 같이 웹사이트에 전달되게 된다.
  • zh-TW (중국어 번체)
이 경우, 사이트에서는 zh-TW를 지원하지 않으면 적당한 기본 설정 언어 또는 언어군으로 zh만 따서 내보내는 방법 중 택해야한다. 여기서 문제점은, 사이트 입장에서는 “사용자 아마 중국어밖에 읽지 못할테니 간체로 내보내자” 와 “사용자가 간체를 보면 정치적인 이유로 불편할 거니 영어로 내보내자” 중에서 하나를 택해야한다는 점이다. 이를 여러 언어로 확장하게 되면, 사이트 입장에서 다국어 지원을 하는게 머리가 아파지고, 이로 인해 사용자의 일부는 분명히 선호 언어를 설정에 명백하게 넣었음에도 불구하고 불편함을 감수해야하는 문제가 발생한다.
확장해서 보면, 유사한 사례로 중남미에서의 스페인어 (es-LA, es-ES), 브라질에서의 포르투갈어 (pt-BR → pt-PT), 마다가스카르에서의 프랑스어 (mg → fr-MG → fr-FR) 같은 경우도 생각해볼 수 있다. 보다 극단적인 사례로 아랍어는 ar-* 가 16개나 있다.

개인정보 보호와 사용자 선호도 존중, 무엇이 중요할까?

위에 링크된 깃헙 논쟁을 보면 의견이 꽤 극명하게 양분화 되어있다.
  • 사용자가 언어 설정으로 인해 발생할 수 있는 위험성을 모르니, 이를 브라우저가 보호해줄 필요가 있다
  • 사용자의 언어 설정은 근거가 있고, 그를 고려해서 다국어 지원을 사이트에서 할 수 있게 해줘야 한다
지극히 개인적인 입장으로, 후자쪽에 손을 들어주고 싶다. 다국어를 구사할 수 있는 사람 입장에서 현 제안은 인터넷상에서 무분별한 사용자 식별이라는 문제를 해결하기 위해 비교적 소수를 (3개 국어를 구사할 수 있는 사람은 인류의 13% 밖에 되지 않는다는 통계가 있다) 희생시키는 건 위험하다는 의견이다.
추신: 네이버 로그인 페이지의 영어가 자연스러웠다면 눈치를 못챘을지도. “shooting a QR code”가 눈에 밟힌 게 문제.
notion image

© Sangwhan Moon 2014 - 2025