Google Analytics 도입: 코드보다 처리방침에서 먼저 막힌 이유
Google Analytics를 붙이는 코드를 다 짜고, 배포 직전에 개인정보 처리방침을 열었습니다. 이 문장이 있었습니다.
이 정보는 광고 프로파일링에 사용하거나 외부 분석 서비스에 제공하지 않습니다.
코드가 맞으면 문서가 틀려집니다. 문서를 고치면 되는 일이라고 생각하고 파일을 열었는데, 거기서 한참 더 걸렸습니다.
문서를 고치러 갔다가 더 오래된 불일치를 찾았습니다
처리방침에는 이런 문장도 있었습니다. "회사 웹사이트는 광고·행태정보 분석용 쿠키를 사용하지 않습니다."
그런데 이 사이트의 블로그에는 애드센스가 붙어 있습니다. 확인해 보니 광고 로더가 실제로 나가고 있었습니다.
adsbygoogle 2회
pagead2.googlesyndication.com 4회애드센스는 광고 쿠키를 심습니다. GA와 상관없이 그 문장은 진작부터 사실이 아니었습니다. 오늘 GA를 붙이려다 우연히 마주친 것이지, 오늘 생긴 문제가 아니었습니다.
반년을 못 본 이유는 리포가 갈려 있어서였습니다
이게 왜 눈에 안 띄었는지가 저는 더 중요하다고 봅니다.
블로그는 별도 저장소입니다. 거기에는 처리방침이 없습니다. 푸터에서 회사 사이트의 /privacy를 링크할 뿐입니다. 회사 사이트 저장소에는 처리방침이 있는데, 거기에는 광고 코드가 없습니다.
어느 쪽을 열어도 문제가 보이지 않습니다. 두 저장소를 같은 화면에 놓아야만 보이는 종류의 어긋남이었습니다. 블로그 코드를 아무리 읽어도 "이 문장과 충돌한다"는 생각이 들 수가 없습니다. 그 문장이 그 저장소에 없으니까요.
한 도메인 아래에 세 앱을 조합해 두었고 처리방침은 하나입니다. 그러면 그 하나가 세 앱의 실제를 전부 담아야 하는데, 실제는 세 저장소에 흩어져 있습니다.
광고를 빼려다 멈췄습니다
처음 판단은 애드센스를 걷어내는 것이었습니다. 법을 지키려면 그래야 한다고 생각했습니다.
그런데 그 전제가 틀렸습니다. 광고를 다는 것 자체는 위법이 아닙니다. 국내법에는 EU의 ePrivacy 지침 같은 쿠키 사전 동의 조항이 없습니다. 자동 수집 장치는 설치·운영과 거부 방법을 처리방침에 적으면 됩니다. 개인정보 보호법 제30조가 처리방침의 기재사항을 정하고, 시행령 제31조가 "인터넷 접속정보파일 등 개인정보를 자동으로 수집하는 장치의 설치·운영 및 그 거부에 관한 사항"을 그 항목으로 들고 있습니다.
틀린 것은 광고가 아니라 문서였습니다. 고쳐야 할 대상을 잘못 짚고 있었던 겁니다.
다만 여기서 갈리는 지점이 하나 있습니다. 맞춤형 광고는 다릅니다. 다른 사이트 방문 이력을 모아 개인화하는 경우에는 사전 동의가 필요하다는 것이 개인정보보호위원회의 입장이고, 2022년에 구글과 메타에 부과된 과징금도 그 사유였습니다. 국내 사이트에 쿠키 배너가 보이기 시작한 것도 대개 이 때문입니다.
그러니 질문은 "광고를 뺄 것인가"가 아니라 "맞춤형 광고를 할 것인가"였습니다.
비개인화로 고정했습니다
애드센스에는 개인화를 끄는 방법이 있습니다. 콘솔 설정이 아니라 코드 한 줄입니다. 저는 콘솔에서 토글을 한참 찾다가 없다는 것을 알았습니다.
(adsbygoogle = window.adsbygoogle || []).requestNonPersonalizedAds = 1;이걸 켜면 행태정보 기반 타게팅을 쓰지 않으므로 사전 동의 부담이 사라집니다. 광고와 수익은 남습니다. 클릭 단가는 낮아집니다. 배너를 만들어 동의 상태를 관리하는 비용과 비교하면 이쪽이 쌉니다.
주의할 점은 쿠키가 없어지지는 않는다는 것입니다. 개인화에는 쓰지 않지만 빈도 제한과 집계 리포팅용 쿠키는 그대로 남습니다. 구글 문서에 그렇게 적혀 있습니다. 저는 처음에 "비개인화면 쿠키도 없겠지" 하고 넘어갈 뻔했습니다.
그래서 처리방침에는 광고 쿠키를 쓴다고 적었습니다. 거부 방법도 함께 적었습니다. 브라우저 설정에서 차단할 수 있고 구글 광고 설정에서도 조정할 수 있습니다.
이 파라미터는 상태를 기억하지 않습니다. 설정하지 않은 요청은 개인화로 되돌아가므로 전역에 두어야 합니다. 확인은 개발자도구 네트워크 탭에서 광고 요청에 npa=1이 붙는지로 합니다.
심사 중이라 코드를 뺄 수 없었습니다
일이 겹친 부분이 하나 있었습니다. 애드센스 심사가 진행 중이었습니다.
심사는 사이트에 광고 코드가 살아 있어야 진행됩니다. 코드를 빼면 심사가 거부되고 처음부터 다시 신청해야 합니다. 만약 첫 판단대로 광고를 걷어냈다면 심사와 수익을 둘 다 잃고, 문서는 GA 때문에 어차피 고쳐야 했을 겁니다.
비개인화 전환은 파라미터를 하나 붙이는 것이라 심사에 영향이 없습니다. 결과적으로 급한 것과 급하지 않은 것이 갈렸습니다. 문서를 고치는 것은 오늘 해야 할 일이었고, 광고를 뺄지 말지는 심사 결과를 보고 정해도 되는 일이었습니다.
문서를 어디까지 고쳤나
처리방침에서 손댄 곳은 네 군데입니다.
쿠키 조항에는 블로그에 광고가 게재되며 빈도 제한과 성과 집계를 위한 쿠키가 쓰인다는 사실, 비개인화로 고정되어 있다는 사실, 그리고 거부 방법을 적었습니다.
위탁 조항에는 구글을 두 줄로 넣었습니다. 하나는 이용 통계 분석이고 하나는 블로그 광고 게재입니다. 처리 항목도 각각 다릅니다. 분석 쪽에는 문의 폼으로 받은 이름과 이메일이 전달되지 않는다는 것을 명시했습니다.
국외 이전 고지에는 구글을 더했습니다. 기존 문구가 텔레그램과 클라우드플레어를 "문의 응대에 필요한 처리위탁"으로 묶고 있었는데, 분석과 광고는 목적이 달라서 그 묶음에 그대로 넣을 수 없었습니다. 목적을 나눠 적었습니다.
자동 수집 항목에는 GA가 가져가는 것을 따로 한 줄 넣었습니다. 접속 IP, 브라우저와 기기 정보, 방문 페이지와 유입 경로입니다.
영문판도 같은 내용으로 고쳤습니다. 한쪽만 고치면 다음에 법이 바뀔 때 어느 쪽이 최신인지 알 수 없게 됩니다.
남은 것
시행일을 당일로 적었습니다. 처리방침 변경은 사전 공지가 원칙이니 엄격히 보면 아쉬운 처리입니다. 문서가 틀린 채로 며칠을 더 두는 것보다는 낫다고 판단했는데, 이 판단에 확신은 없습니다. 다음에 비슷한 일이 있으면 방침을 먼저 올리고 코드를 나중에 켜는 순서로 해보려고 합니다.
그리고 이번 일의 교훈은 이겁니다. 추적 코드를 넣는 작업은 코드 작업으로 시작해서 문서 작업으로 끝납니다. 두 저장소에 나뉘어 있으면 그 사실이 잘 안 보입니다. 저는 앞으로 추적이나 광고를 건드리는 커밋에는 처리방침 변경이 같이 있는지를 확인하려고 합니다. 없다면 정말 없어도 되는지 한 번 더 보는 편이 낫습니다.
쿠키를 없앤 이야기는 따로 적었습니다. 그쪽은 구현 이야기고, 이 글은 그 코드가 배포되기 전에 무엇에 막혔는지에 대한 기록입니다.
이 글은 법률 자문이 아닙니다. 저희가 어떤 근거로 어떻게 판단했는지를 적은 것이고, 사업 형태에 따라 결론은 달라질 수 있습니다.
함께 읽기
- 이미지 프록시를 공개했다가 내부 네트워크까지 열어버린 이유외부 이미지 URL을 받아 서버가 대신 내려받아 주는 프록시는 편리합니다. 브라우저의 CORS 제약을 피할 수 있고, 이미지 형식을 통일하거나 변환 결과를 캐시하기도 쉽습니다.
- YouTube Data API OAuth 인증 설정: 로컬 자동 업로더 연결하기YouTube 영상을 코드로 업로드하려면 API 키만으로는 부족합니다. 영상 업로드, 썸네일 지정, 자막 등록처럼 채널 데이터를 바꾸는 작업은 채널 소유자의 동의를 받은 OAuth 2.0 인증이 필요합니다.
- Base64는 암호화가 아니다: 브라우저 Vault의 v2 봉투 암호화모바일 서명 파일이나 환경설정을 백업하다 보면 값 대부분이 Base64처럼 보일 때가 있다. 이때 가장 먼저 구분해야 할 사실이 있다.
- 개발 키가 많아질수록: Bitwarden으로 비밀번호와 시크릿을 나누는 법서비스를 운영하다 보면 GitHub 토큰, 데이터베이스 비밀번호, API 키, 배포 인증서, 백업 암호화 키가 빠르게 늘어납니다. 처음에는 비밀번호 관리 앱의 메모나 여러 .env 파일에 저장해도 괜찮아 보이지만, 키가 많아질수록 “무엇이 최신인지”, “개발용인지 운영용인지”, “어디에서 사용 중인지”를 판단하기 어려워…
- HMAC 입문: 서버는 값이 바뀌었다는 사실을 어떻게 알아낼까?웹 서비스를 만들다 보면 이런 값들을 자주 다룹니다.