우리는 왜 감시를 기본값으로 받아들였을까, 개발자가 매일 찍는 코드의 무게

어느 순간 익숙해져 버린 추적의 세계

Vivian Voss라는 개발자가 쓴 "We accepted surveillance as default"라는 에세이가 있어요. 제목을 직역하면 "우리는 감시를 기본값으로 받아들였다"쯤 되는데요, 글의 요지는 간단해요. 우리가 만들고 쓰는 웹과 앱의 거의 모든 것이 기본적으로 사용자를 추적하는 방향으로 설계되어 있고, 어느 시점부터 이걸 이상하게 여기지 않게 됐다는 거예요. 쿠키 배너를 건성으로 닫고, 앱을 설치하자마자 뜨는 "광고 식별자를 허용하시겠습니까?"를 반사적으로 눌러버리고, 로그인도 안 했는데 사이트가 "다시 방문해주셔서 감사합니다"라고 인사하는 게 그냥 일상이 됐죠.

구체적으로 뭐가 문제인가

글에서는 몇 가지 층위를 짚어요. 첫 번째는 서드파티 트래킹 스크립트예요. Google Analytics, Facebook Pixel, Hotjar, Mixpanel, Segment 같은 도구들이 한 사이트에 동시에 붙는 경우가 흔하거든요. 각각이 IP, User-Agent, 스크롤 패턴, 마우스 이동, 폼 입력 중단 시점까지 수집해요. 개별로는 익명이라지만 여러 소스를 합치면 디바이스 핑거프린팅으로 개인 식별이 가능해지는 건 이미 여러 연구에서 밝혀진 사실이에요.

두 번째는 모바일 SDK. 광고 네트워크나 분석 SDK를 하나 넣으면 그 안에 뭐가 딸려들어오는지 앱 개발자 본인도 모르는 경우가 많아요. iOS의 App Tracking Transparency(ATT)나 Android의 Privacy Sandbox가 이걸 제약하려고 하지만, 여전히 서버 사이드 이벤트 전송, 광고 ID, 기기 특성 조합으로 우회하는 게 일반적이고요.

세 번째는 "다크 패턴"에 가까운 동의 설계예요. GDPR이 도입된 이후 쿠키 배너는 의무가 됐지만, 대부분의 사이트에서 "모두 수락"은 초록색 큰 버튼, "거부"는 3단계 메뉴 속에 숨어있어요. 실제 연구에 따르면 유럽 상위 사이트의 절반 이상이 GDPR/ePrivacy 지침에 기술적으로 위반되는 배너를 쓰고 있다고 해요.

왜 이렇게 됐을까

글쓴이는 이걸 "인프라의 관성"으로 설명해요. 2000년대 중반 웹이 광고 기반 비즈니스 모델을 선택한 순간부터, "측정할 수 없으면 최적화할 수 없다"는 논리가 업계 표준이 됐거든요. 그러다 보니 프론트엔드 템플릿에도, CMS 기본 설정에도, SaaS 기본 프리셋에도 트래킹 코드가 내장돼요. 개발자가 의식적으로 빼지 않으면 끼워져 있는 거죠.

또 하나는 빅테크의 수직 통합이에요. Google은 브라우저(Chrome), 광고 네트워크(AdSense), 분석(GA4), 태그 매니저(GTM)를 모두 가지고 있어요. 이 생태계 안에서 기본 설정을 따라가면 자연스럽게 여러 층위의 데이터가 Google에게 흘러들어가도록 설계돼 있거든요. Meta, Amazon, TikTok도 구조는 비슷해요.

업계의 반작용

흐름을 거스르려는 시도도 없진 않아요. Plausible, Fathom, Umami 같은 프라이버시 중심 분석 도구는 쿠키 없이 집계만 하고, 개인 식별을 아예 불가능하게 설계돼 있어요. 브라우저 쪽에서는 Safari의 ITP, Firefox의 Total Cookie Protection, Brave의 기본 차단 같은 기능이 기본값으로 들어왔고요. Apple의 Private Relay나 Mozilla의 Relay 서비스는 IP 주소 수준에서 익명화를 제공해요.

법 제도 쪽도 움직여요. 유럽의 GDPR, 미국 캘리포니아의 CCPA/CPRA, 한국의 개인정보보호법 2023년 개정안(이용자 개인정보 처리 방침 고지 강화, 자동화 결정 설명 요구권 등)이 모두 이 맥락에 있어요. 특히 한국은 2024년 시행된 가이드라인에서 광고식별자(ADID/IDFA)도 개인정보로 본다는 해석이 명확해졌어요. 이건 실무에 꽤 영향을 주는 변화예요.

한국 개발자가 내일 출근해서 할 수 있는 것

이게 멀리 있는 얘기 같지만, 실무에서 체크할 포인트가 생각보다 많아요. 프론트엔드 팀이라면 자사 사이트에 붙은 서드파티 도메인을 Request Map이나 webbkoll.dataskydd.net 같은 도구로 한 번 스캔해보세요. 본인도 몰랐던 추적 픽셀이 붙어있는 경우가 꽤 있거든요. 백엔드/인프라 팀이라면 로그에서 불필요한 개인 식별 정보(전체 IP, User-Agent 풀 스트링 등)를 수집 단계에서 해시하거나 절사하는 정책을 검토해볼 만해요. 데이터 엔지니어라면 데이터 웨어하우스에 들어가는 이벤트 스트림에서 PII 필드를 기본 마스킹하는 파이프라인을 설계해두면, 나중에 컴플라이언스 감사 때 훨씬 수월합니다.

제품 기획 단계부터 Privacy by Design을 반영하는 것도 중요해요. "일단 다 수집해두고 나중에 필요하면 쓰자"가 오랜 관행이었는데, 이제는 "꼭 필요한 것만 수집하고 나머지는 애초에 저장하지 않는다"가 법적으로도 실무적으로도 더 안전한 선택지가 됐어요. 특히 AI 학습용 데이터를 모을 때 이 원칙을 지키지 않으면 나중에 더 큰 리스크로 돌아올 수 있고요.