제 사이트가 뭘 수집하는지 저도 몰랐습니다

8월 18일 낮에 이 사이트의 개인정보처리방침 페이지를 만들어 올렸습니다. 거기에 이렇게 썼습니다.

이 사이트는 쿠키를 사용하지 않습니다. 접속 분석 도구(Google Analytics 등)와 광고도 현재 사용하지 않습니다.

23분 뒤에 저 문장을 지웠습니다. 사실이 아니었기 때문입니다. 이 사이트는 그때 이미 방문자 통계를 수집하고 있었습니다.

없다고 확신한 근거

방침을 쓰기 전에 확인은 했습니다. 세 군데를 봤습니다.

• 저장소 전체 검색 — gtag, analytics, <script> 어디에도 추적 코드가 없었습니다.
• npm run build 결과물 — 생성된 HTML에도 없었습니다.
• curl로 받은 실제 배포본 — 역시 없었습니다.

세 곳 다 깨끗하니 없는 게 맞다고 판단했습니다. 정적 사이트고, 제가 안 붙였고, 산출물에도 없으니까요.

실제로는 돌고 있었습니다

방침을 올리고 나서 사이트를 브라우저로 열어 네트워크 탭을 봤습니다. 제가 넣은 적 없는 요청이 하나 있었습니다. Cloudflare Web Analytics의 비콘 스크립트였습니다.

Cloudflare에는 자동 설정이라는 게 있습니다. 도메인을 Cloudflare에 올려두면, 대시보드에서 스위치 하나로 웹 애널리틱스를 켤 수 있습니다. 이 방식은 사이트 코드를 건드리지 않습니다. 대신 엣지에서 HTML 응답에 비콘을 끼워 넣어 내보냅니다.

그래서 제 세 가지 확인이 전부 통과한 겁니다.

• 저장소에 없는 건 당연합니다. 제 코드가 아니니까요.
• 빌드 결과물에도 없습니다. 주입은 빌드가 아니라 응답 시점에 일어납니다.
• curl도 못 잡았습니다. 제가 받아본 HTML에는 붙어 있지 않았습니다.

오리진이 내보낸 것과 방문자가 받는 것이 달랐고, 저는 계속 오리진만 보고 있었습니다.

언제 켰는지도 기억이 안 납니다. 도메인을 Cloudflare에 올리던 날 대시보드를 훑다가 켰을 겁니다. 켠 기억이 없으니 껐다고 생각한 것도 아니고, 그냥 존재 자체가 인식에서 빠져 있었습니다.

같은 실수를 반대 방향으로 이미 한 번

더 뼈아픈 건 이게 처음이 아니라는 점입니다.

4월에 지금은 접은 서비스에 분석 도구를 붙이다가 알았는데, 그 사이트는 정확히 반대 상태였습니다. 개인정보처리방침에는 분석 도구를 사용한다고 적혀 있는데, 실제로는 아무것도 안 붙어 있었습니다. 배포한 지 몇 달째 방문자 수를 단 한 번도 못 보고 있었고, 그걸 그날 처음 알았습니다.

넉 달 간격으로 같은 버그를 양방향으로 한 번씩 냈습니다.

	문서에 적힌 것	실제 동작
4월, 이전 프로젝트	분석 도구를 쓴다	아무것도 없음
8월, 이 블로그	분석 도구를 안 쓴다	수집 중

같은 원인입니다. 방침을 실제 동작에서 뽑아내지 않고 기억에서 썼습니다. 한 번은 “붙였겠지”였고 한 번은 “안 붙였겠지”였습니다. 둘 다 확인 없이 쓴 문장이었고, 공교롭게 둘 다 틀렸습니다.

왜 이게 사소하지 않은가

개인정보처리방침은 블로그를 꾸미는 페이지가 아닙니다.

법적 고지입니다. 방문자에게 “당신 정보를 이렇게 다룹니다”라고 약속하는 문서고, 그 약속과 실제가 다르면 내용이 방문자에게 유리하든 불리하든 문제입니다. 제 경우는 “수집 안 한다”고 해놓고 수집하고 있었으니 더 나쁜 쪽이었습니다.

광고 승인 심사에서도 봅니다. 이전 프로젝트가 애드센스에서 거절당했을 때 사유는 콘텐츠였지만, 방침과 구현이 어긋난 사이트를 심사자가 좋게 볼 이유는 없습니다.

그리고 이건 신뢰의 문제입니다. 자기 사이트가 뭘 수집하는지 모르는 사람이 쓴 문서를 방문자가 믿을 이유가 없습니다.

배포 플랫폼이 응답을 고친다

이 일에서 남은 진짜 교훈은 개인정보 쪽이 아니라 배포 쪽이었습니다.

내 저장소에 없다고 내 사이트에 없는 게 아닙니다. 요즘 배포 플랫폼은 내가 만든 응답을 그대로 내보내지 않습니다. 엣지에서 고쳐서 내보냅니다.

같은 사이트에서 비슷한 일을 하나 더 겪었습니다. 영어로 쓴 글 하나를 비공개로 돌리고 배포했는데, 그 주소가 계속 200을 반환했습니다. Cloudflare의 Always Online이 웨이백 머신에 저장된 옛날 사본을 대신 내주고 있었습니다. 삭제한 페이지가 살아 있는 것처럼 보인 겁니다. 다행히 그 응답에는 검색엔진에 색인하지 말라는 헤더가 붙어 나가고 있어서 실질적인 문제는 없었지만, 빌드 결과물만 보고 있었으면 영영 몰랐을 일입니다.

정리하면 이렇습니다.

• 오리진과 엣지는 다른 것을 내보낼 수 있다. 자동 최적화, 스크립트 주입, 캐시 대체 응답 전부 여기서 일어납니다.
• curl은 방문자가 아니다. 브라우저 요청에만 적용되는 기능이 있습니다. 최종 확인은 브라우저로 열어서 네트워크 요청을 봐야 합니다.
• 대시보드에서 켠 것은 코드 리뷰로 안 잡힌다. 스위치 하나로 켜지는 기능은 커밋 로그에도 없고 코드 검색에도 안 걸립니다.

고친 것

방침 페이지를 실제 동작에 맞춰 다시 썼습니다. Cloudflare Web Analytics를 쓴다는 것, 쿠키를 쓰지 않고 개인을 식별하지 않는다는 것, 제가 볼 수 있는 게 페이지 조회수와 국가 수준 통계까지라는 것을 적었습니다. 지금 페이지에서 볼 수 있습니다.

그리고 저장소의 작업 지침 파일에 한 줄을 넣었습니다. 개인정보처리방침은 실제 동작과 반드시 일치시킬 것, 그리고 측정 도구가 붙어 있는지는 코드 검색이 아니라 브라우저로 확인할 것.

지침에 적어두는 게 과해 보일 수 있는데, 이미 두 번 틀렸습니다. 세 번째는 기억력으로 막을 수 있는 게 아니라고 봤습니다.