네임서버만 옮겼는데 내 사이트에 남의 스크립트가? Cloudflare 자동 삽입 논란

내가 만든 웹페이지의 HTML을 나 아닌 누군가가 조용히 고쳐 놓는다면 어떨까요. Cloudflare에 도메인을 등록하고 네임서버를 바꿨을 뿐인데 사이트 소스에 처음 보는 자바스크립트 한 줄이 들어가 있더라는 이야기가 개발자 커뮤니티에 다시 돕니다. 사소해 보여도 조금만 따라가면 “웹 인프라를 맡긴다는 게 어디까지 위임하는 것이냐"는 꽤 무거운 질문이 나옵니다.

먼저 솔직하게 밝히자면 이번 주제는 최근 30일 내 커뮤니티 데이터가 거의 잡히지 않았습니다. Reddit 쪽에서는 관련 스레드가 안 보였고, 논의 자체도 새로 터진 사건이라기보다 몇 년째 주기적으로 다시 불붙는 쪽에 가깝습니다. 그래서 이 글은 실시간 반응을 중계하기보다 이 논쟁이 왜 자꾸 같은 자리로 돌아오는지를 뜯어봅니다.

무슨 일이 벌어지는 건가

Cloudflare의 무료 플랜에는 Web Analytics라는 기능이 있습니다. 방문자 수, 페이지뷰, 유입 경로 같은 걸 보여주는 도구인데요. 문제는 이게 어떻게 동작하느냐입니다.

보통의 분석 도구는 사용자가 직접 HTML에 스크립트 태그를 붙입니다. Google Analytics를 쓰려면 head 안에 코드를 넣어야 하죠. 그런데 Cloudflare에는 선택지가 하나 더 있습니다. 트래픽이 이미 자기네 서버를 거쳐 가니까 응답 HTML을 지나가는 길에 고쳐서 스크립트를 끼워 넣을 수 있습니다. 이걸 자동 삽입(automatic injection)이라고 부릅니다.

논란의 핵심은 “삽입 기능이 있다"가 아니라 기본값입니다. 도메인을 온보딩하는 과정에서 이 옵션이 켜진 채로 넘어가고 대부분의 사용자는 그 화면을 스쳐 지나갑니다. 몇 주 뒤에 소스 보기를 하다가 “이 스크립트 뭐지?” 하고 발견하는 식이죠. 사업자 입장에서는 “동의를 받았다"이고, 사용자 입장에서는 “몰랐다"입니다.

“조용히"라는 표현이 왜 논쟁적인가

Cloudflare 쪽 반박은 명확합니다. 온보딩 화면에 체크박스가 있었고 대시보드에서 언제든 끌 수 있다는 겁니다. 수집하는 데이터도 쿠키 없이 익명 집계에 가깝고요. 실제로 Cloudflare Web Analytics는 개인 식별자를 저장하지 않는 방식을 마케팅 포인트로 내세워 왔습니다. 프라이버시 관점에서 GA보다 낫다는 주장도 근거가 없진 않습니다.

반대편 논리는 이렇습니다. DNS를 맡긴 것과 페이지 내용 수정을 허락한 것은 층위가 전혀 다른 계약이라는 겁니다. 네임서버를 바꾼 건 “이 도메인의 이름 풀이를 대신 해달라"는 요청이지 “내 HTML에 코드를 추가해도 좋다"는 승낙이 아닙니다. 온보딩 흐름 중간에 끼어 있던 체크 하나로 그 권한까지 넘어갔다면 형식은 동의지만 실질은 아니라는 거죠.

이 구도가 낯익다면 이유가 있습니다. 다크 패턴 논쟁이 그랬고 쿠키 배너 논쟁이 그랬습니다. 앱 깔 때 권한이 기본 켜짐 상태로 넘어가는 것도 뼈대가 똑같습니다. 기술적 사실관계보다 기본값을 누가 정하느냐가 진짜 쟁점입니다.

법적으로는 더 골치 아파집니다

유럽에서 사이트를 운영한다면 이야기가 한 단계 복잡해집니다. GDPR과 ePrivacy 지침 체계에서 개인정보를 처리한 책임은 원칙적으로 사이트 운영자, 즉 컨트롤러가 집니다. Cloudflare는 프로세서 위치에 가깝고요.

그러면 이런 그림이 나옵니다. 사이트 운영자는 개인정보 처리방침에 “우리는 제3자 분석 도구를 쓰지 않습니다"라고 써 놓았는데 실제 페이지에서는 제3자 도메인의 스크립트가 불려 옵니다. 규제 당국이 문을 두드리면 해명할 쪽은 Cloudflare가 아니라 운영자입니다. 내가 넣은 적 없는 코드 때문에 내가 책임을 집니다.

물론 쿠키를 쓰지 않고 개인 식별도 하지 않는다면 동의 요건에서 상당 부분 비껴갈 여지는 있습니다. 다만 “우리가 보기엔 익명이니까 괜찮다"는 판단은 사업자가 대신 내리고 그 법적 리스크는 고객이 지는 비대칭이 그대로 남습니다.

개발자들이 진짜 불편해하는 지점

커뮤니티에서 반복해서 나오는 불만은 개인정보 그 자체보다 예측 가능성 쪽에 가깝습니다.

내가 배포한 HTML과 브라우저가 받는 HTML이 다르면 디버깅하는 사람은 꽤 피곤해집니다. Content Security Policy를 빡빡하게 걸어 뒀는데 정체 모를 스크립트가 차단되면서 콘솔에 에러가 뜹니다. Lighthouse 점수를 올리려고 리소스를 하나씩 줄이고 있었는데 요청이 하나 늘어 있습니다. 원인을 찾느라 몇 시간을 쓴 뒤에야 “아, 이거 CDN이 넣은 거였네” 소리가 나오죠. 유쾌할 리가 없습니다.

같은 계열의 기능이 하나 더 있습니다. 이메일 주소를 봇에게서 지킨다며 mailto 링크를 난독화하는 Email Obfuscation인데요. 취지는 좋지만 자바스크립트가 꺼진 환경이나 특정 파서에서는 이메일이 깨져 보입니다. 이것도 기본 켜짐입니다. 하나하나는 다 선의로 만든 기능인데 합쳐 놓고 보면 “내 출력물을 내가 최종 결정하지 못한다"는 감각이 남습니다.

그래서 어떻게 하면 되나

당장 확인할 방법은 간단합니다. 브라우저에서 소스 보기를 하거나 개발자 도구 네트워크 탭을 열어 Cloudflare 도메인으로 나가는 요청이 있는지 보면 됩니다. 특히 beacon 계열 스크립트가 눈에 띈다면 자동 삽입이 켜져 있을 가능성이 큽니다.

끄는 것도 어렵지 않습니다. 대시보드의 Analytics 영역에서 Web Analytics 설정을 찾아 자동 삽입을 해제하면 됩니다. Email Obfuscation 같은 항목은 Scrape Shield 쪽에 모여 있습니다. 새 도메인을 붙였다면 배포 직후 한 번은 실제 응답 HTML을 확인하는 습관, 이게 제일 확실한 방어입니다.

더 근본적인 대응은 관점을 바꾸는 겁니다. CDN이나 리버스 프록시를 쓴다는 건 그 사업자에게 응답을 다시 쓸 물리적 능력을 넘긴다는 뜻입니다. 이건 Cloudflare만의 특성이 아니라 중간자 구조 자체의 성질입니다. 그래서 계약할 때 봐야 할 건 “이 회사가 착한가"가 아니라 “기본값이 무엇이고, 변경 시 나에게 알려주는가”입니다.

누가 기본값을 정하는가

이 논쟁이 몇 년째 사그라들지 않는 건 어느 한쪽이 명백히 틀렸기 때문이 아닙니다. 무료로 좋은 도구를 주려는 쪽과 내 사이트를 온전히 통제하고 싶은 쪽이 각자 나름대로 합리적이라 그렇습니다. 다만 힘의 크기가 다를 때는 기본값을 정하는 쪽이 사실상 규칙을 정합니다.

지금 운영 중인 사이트의 소스를 한번 열어보시죠. 내가 넣지 않은 코드가 몇 줄이나 들어 있는지, 그걸 넣어도 된다고 언제 허락했는지 기억이 나는지. 인프라를 남에게 맡긴다는 건 그런 걸 가끔 한 번씩 확인하며 가는 일입니다.