UTM이 붙은 전체 링크를 채팅에 붙이면 어떤 추적 정보가 함께 나갑니다

주소창의 전체 링크는 그대로 보내도 되는 주소가 아닙니다

운영이 랜딩 페이지를 슬랙에 넣고, 고객지원이 민원 URL을 지라에 붙이고, 개발이 재현 절차를 카카오워크 스레드에 씁니다. 세 장면 모두 가장 싼 동작은 같습니다. 주소창을 전체 선택하고, 복사하고, 붙여넣습니다. 주소창이 보여주는 것은 현재 문서의 전체 URL입니다. WHATWG URL 기준으로는 적어도 스킴, 호스트, 경로, 쿼리(? 뒤), 프래그먼트(# 뒤)가 있습니다. 프래그먼트는 기본으로 HTTP에 들어가지 않습니다. 앞 글에서 이미 썼습니다. 쿼리는 요청 줄에 타고, 클립보드에도 탑니다.

문제는 쿼리가 페이지를 여는 데 꼭 필요하지 않은 경우가 많다는 점입니다. 추적 태그가 붙은 메일, 유료 클릭, 소셜 카드가 클릭 토큰을 덧붙인 경로로 들어왔을 수 있습니다. 페이지 자체는 /product/42만 있으면 됩니다. 주소창은 /product/42?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale&fbclid=…가 됩니다. 분석 시스템에는 귀속할 수 있는 한 번의 방문입니다. 다음으로 이 문자열을 읽는 사람에게는 티켓에 있으면 안 되는 옆모습입니다. 어느 캠페인에서 왔는지, 방금 광고를 눌렀는지, 메일 업체가 이 수신자를 번호로 매겼는지.

HTTPS가 지키는 것은 전송 구간의 도청입니다. 주소창, 브라우저 기록, 채팅 저장소, 스크린샷, 액세스 로그는 지우지 않습니다. OWASP의 쿼리 문자열 정보 노출 설명은 단정합니다. 암호화 채널을 써도 쿼리는 Referer, 웹 로그, 공유 시스템, 브라우저 기록, 캐시, 어깨너머 보기에 남습니다. 보내기 전에 물을 것은 「이 사이트가 안전한가」가 아닙니다. 「이 물음표 뒤에, 이 탭을 떠나면 안 되는 태그가 있는가」입니다.

UTM은 캠페인을 쓰고, 클릭 ID는 이번 클릭을 씁니다

두 종류가 한 URL에 같이 붙는 일이 많습니다. 하는 일이 다르고, 새는 내용도 다릅니다. 첫 번째는 여러분(또는 광고 플랫폼)이 일부러 쓴 캠페인 태그입니다. Google 애널리틱스 고객센터는 이를 campaign parameters라고 부르고, 표준 예로 https://www.example.com/?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale를 줍니다. 문서는 파라미터를 넣을 거면 utm_source, utm_medium, utm_campaign을 함께 쓰라고 합니다. 확장 항목에는 utm_id, utm_term, utm_content, utm_source_platform이 있습니다. 값은 대소문자를 구분합니다. utm_source=google과 utm_source=Google은 보고서에서 두 줄로 갈라집니다.

이런 태그는 보통 한 사람을 부호화하지 않습니다. 채널과 캠페인을 설명합니다. 어느 뉴스레터인지, 어느 여름 세일인지, 위 링크인지 아래 링크인지. 그래도 회사 밖 채팅에 붙이면 내부 매체 구조가 새어 나갑니다. 수신자는 어떤 캠페인을 밀고 있는지, 메일이었는지 유료 클릭이었는지 읽고, 유입 경로를 짐작할 수 있습니다. 경쟁사나 무관한 제삼자에게는 「이 페이지를 연다」에 필요한 양을 넘습니다.

두 번째는 광고나 메일 플랫폼이 스스로 붙이는 클릭 토큰입니다. 흔한 이름은 Google Ads의 gclid, Display & Video 360의 dclid, iOS 구간의 gbraid / wbraid, Meta의 fbclid, Microsoft Advertising의 msclkid, X의 twclid, 그리고 메일 업체가 쓰는 mc_eid입니다. 목적은 「이번 클릭」을 플랫폼 기록에 다시 꿰매는 것이지, 사람이 읽을 문장을 주는 것이 아닙니다. 값은 수신자에게는 불투명하고 플랫폼에는 읽힙니다. fbclid나 gclid가 남은 문자열을 넘기면, 이어 붙일 수 있는 클릭 증표를 넘기는 것입니다. mc_eid 같은 토큰은 「이 메일이 이 구독자 행으로 갔다」에 더 가깝습니다.

세 번째 층은 사이트 자체의 귀속이나 공유 파라미터입니다. 쇼핑몰과 콘텐츠 사이트는 spm, scm, pvid, share_token, refer_share_id를 자주 붙입니다. Google의 UTM 규격은 아니지만, 「그냥 상품 페이지」처럼 보이는 링크에 누가 어디서 공유했는지 자국을 남깁니다. utm_*만 지우는 정책은 이 층을 그대로 둡니다.

쿼리는 어디에 남습니까

CWE-598의 현재 제목은 Use of HTTP Request With Sensitive Query String입니다. 결함은 민감한 데이터를 쿼리에 넣었다는 것입니다. 그 값은 브라우저 기록에 남고, Referer로 다른 사이트에 가고, 웹 로그에 쓰이거나 다른 기록에 복사됩니다. 항목은 2026년 4월 4.20판에서 이름이 바뀌었습니다. GET만 쿼리를 싣는 것이 아니라 POST, PUT, DELETE도 실을 수 있다는 점을 강조합니다. 완화는 구체적입니다. 민감한 데이터는 쿼리가 아니라 요청 본문이나 헤더에 두세요.

마케팅 파라미터 대부분은 비밀번호나 세션 토큰이 아닙니다. 노출면은 같습니다. 전체 URL을 메신저에 붙이면 적어도 이런 사본이 생깁니다. 채팅 업체의 메시지 저장소, 수신자의 로컬 기록, 그리고 다시 전달되면 다음 홉의 저장소. 상대가 열면 목적지 액세스 로그는 파라미터가 남은 요청 줄을 적습니다. 그 페이지가 제삼자 스크립트나 이미지를 불러오면, 전체 URL이 Referer를 타고 광고·분석 호스트로 갈 수도 있습니다. OWASP가 말하는 「공유 시스템」은 회사 안에서 흔합니다. 티켓, 문서, 오류 모니터, 세션 리플레이. 재현용으로만 쓰려던 링크가 그 시스템에서 평문 검색으로 나옵니다.

그래서 「우리 사이트는 HTTPS를 씁니다」는 발송 질문에 답이 되지 않습니다. HTTPS는 경로상 관찰자가 평문을 읽기 어렵게 만듭니다. 여러분이 그 평문을 다음 시스템에 붙이는 것은 막지 않습니다. CWE-598의 실제 결함에는 비밀번호를 쿼리에 넣은 카메라, GET에 액세스 토큰을 넣은 통신 제품이 있습니다. 같은 종류의 실수이고, 더 무겁습니다. UTM과 클릭 ID는 보통 더 가볍습니다. 메커니즘은 같습니다. 물음표 뒤에 있는 것이 사람이 복사하고 시스템이 기록하는 것입니다.

Referer는 물음표 뒤를 제삼자에게 넘길 수 있습니다

복사해 붙이기는 능동적인 발송입니다. 수동적인 발송도 있습니다. 수신자가 페이지를 연 뒤, 브라우저는 기본 정책으로 이후 요청에 「내가 어디서 왔는지」를 알립니다. 헤더의 표준 이름은 Referer입니다. r이 하나 빠집니다. MDN의 Referer 개인정보 설명은 익숙한 예를 씁니다. 비밀번호 재설정 페이지 바닥에 소셜 링크가 있으면, 밖으로 클릭하는 순간 토큰이 붙은 주소를 소셜 사이트에 넘길 수 있습니다. 페이지의 제삼자 이미지도 같은 방식으로 현재 전체 URL을 이미지 호스트에 보냅니다.

브라우저가 얼마나 보낼지는 Referrer-Policy가 정합니다. Chrome 계열의 기본값은 strict-origin-when-cross-origin입니다. 동일 출처 요청은 전체 URL(경로와 쿼리)을 실을 수 있고, 다운그레이드가 아닌 교차 출처는 출처(스킴 + 호스트 + 포트)만 보내며, HTTPS에서 HTTP로는 보내지 않습니다. web.dev의 Referrer 안내는 이 기본값을 개인정보와 사용성의 타협으로 봅니다. 「전체 쿼리를 다른 호스트에 보낸다」의 일부는 막습니다. 동일 출처 분석 요청은 막지 않고, 사이트가 unsafe-url을 쓰거나 정책을 비워 둔 옛 클라이언트가 전체 URL을 보내는 경우에도 도움이 되지 않습니다.

「동료에게만 보냈을 뿐」에도 Referer는 의미가 있습니다. 상대가 클릭하는 순간, 붙인 utm_*와 클릭 ID가 한 홉 더 갈 수 있습니다. 랜딩에 제삼자 픽셀, 상담 위젯, CDN 폰트가 있고 정책이 전체 URL을 허용하면, 그 파라미터가 그 호스트 로그에 나타납니다. 보내기 전에 쿼리에서 추적 항목을 빼면 두 홉이 함께 줄어듭니다. 채팅 기록의 평문, 그리고 연 뒤에 나갈 수 있는 Referer.

프래그먼트와의 대비를 한 문장 더 씁니다. # 뒤의 키는 요청 줄에 들어가지 않도록 설계되어, 일반적인 Referer 구현에도 남지 않습니다. 쿼리에는 그런 층이 없습니다. 캠페인 태그와 클릭 ID를 ? 뒤에 두는 이유는 서버와 스크립트가 읽게 하려는 것이고, 바로 그 이유 때문에 로그에 남습니다. 「물음표는 요청에 들어가고, 해시는 기본으로 들어가지 않는다」를 대조하려면 URL의 # 뒤에 키를 두기 좋은 이유, 그리고 이 보호가 깨지는 순간의 단계를 보세요.

운영체제가 일부를 떼어 주지만, 그걸 발송 정책으로 쓰면 안 됩니다

Apple은 내장된 자르기를 문서화합니다. Privacy Features 페이지에서 링크 추적 보호는 이렇게 적힙니다. 메시지에서 링크를 공유할 때, 일부 사이트가 URL에 덧붙인 추가 정보를 제거해 그 사이트가 여러분이나 상대를 추적하지 못하게 합니다. Safari 비공개 브라우징은 따로 적힙니다. 탐색하는 동안 URL에 붙은 추적을 제거합니다. Apple이 공개하는 것은 기능이지, 파라미터 명단이 아닙니다.

공식 전체 제거 목록은 없습니다. 커뮤니티 대조(PrivacyTests.org 등)는 gclid, fbclid, mc_eid, twclid, dclid를 자주 언급합니다. utm_source 같은 캠페인 태그는 보통 남습니다. 범위에도 가장자리가 있습니다. 일반 Safari, 제삼자 브라우저, 앱 안 WebView는 메시지 공유나 비공개 브라우징과 같은 경로가 아닙니다. 상대가 안드로이드이거나, 데스크톱 Chrome이거나, 카카오톡·슬랙·팀즈에서 열면 대신 벗겨 주지 않습니다.

따라서 「휴대폰이 이미 추적 파라미터를 지운다」는 말은 이렇게만 쓸 수 있습니다. 특정 시스템, 특정 앱에서, 일부 클릭 ID가 열리기 전에 지워질 수 있다. 지라에 붙인 그 문자열이 이미 정제되었다는 뜻은 아닙니다. 발송은 복사하는 순간에, 운영체제가 아직 개입하지 않은 곳에서 일어납니다. 여러분이 통제하는 것은 클립보드의 글자이지, 상대 기기가 다시 벗겨 줄지가 아닙니다.

무엇을 빼고, 무엇을 남깁니까

실행할 수 있는 규칙은 이렇습니다. 먼저 이 키가 없어도 페이지가 열리는지 묻습니다. 상품 id, 검색 q, 페이지 번호 page, 언어 lang, 문서 자체가 필요로 하는 쿼리는 지우면 자원이 바뀝니다. 캠페인 태그, 클릭 ID, 메일 수신자 번호, 공유 토큰은 보통 귀속만 바꾸고 페이지는 바꾸지 않습니다.

두 번째 질문은 이 링크가 무엇을 위한가입니다. 동료가 버그를 재현하려면 안정된 자원 주소가 필요하지, utm_campaign=summer-sale이 필요하지 않습니다. 고객이 「이 상품을 여세요」라면 sku가 필요하지, 여러분이 방금 누른 gclid가 필요하지 않습니다. UTM을 남기는 경우는 작업이 「이 태그가 붙은 캠페인으로 들어와 이번 전달을 세게 해 주세요」일 때뿐입니다. 그때도 자기 클릭 ID는 붙이지 마세요.

손으로 지우면 키가 빠집니다. 실제 유료 URL에는 utm_* 다섯여섯 개, 클릭 ID 하나, 사이트 안 토큰 두세 개가 같이 있을 수 있습니다. 오른쪽에서 왼쪽으로 훑으면 id를 지우고 fbclid를 남기는 일이 잦습니다. 더 안정적인 패스는 키 이름입니다. utm_ 접두사는 전부 빼고, 알려진 클릭 ID 표를 빼고, 작업이 허용하면 흔한 분석 키(_ga, _gl, mc_eid, mkt_tok)와 흔한 쇼핑몰 귀속도 뺍니다. 경로, 호스트, 업무 쿼리는 남깁니다. 끝난 뒤에는 「짧아 보이는지」가 아니라 「제거된 키」 목록을 봅니다.

보수와 표준은 익명화의 등급이 아니라 위험 선호입니다. 보수: UTM과 클릭 ID만 건드리고, 모르는 사용자 정의 키는 남겨 아직 본 적 없는 업무 파라미터를 지우지 않습니다. 표준: 흔한 분석과 쇼핑몰 귀속도 빼며, 회사 밖으로 나가거나 공개 공간에 떨어지는 링크에 맞습니다. 어느 쪽도 「이제 익명이다」라고 말할 수 없습니다. 경로에 사용자 이름이 있을 수 있습니다. 쿼리의 email=은 UTM 표에 없습니다. 규칙 정제가 다루는 것은 알려진 추적 키이지, 모든 민감 필드가 아닙니다. 본문의 전화번호, 주민등록번호, 키는 별도 마스킹이 필요합니다. URL 파라미터 제거가 그 일까지 끝낸다고 기대하지 마세요.

바로 확인하기: 제거 목록을 보고, Network를 검색합니다

「로컬 정제, 업로드 없음」은 스스로 증명되지 않습니다. 그 자리에서 볼 수 있는 것은 세 가지입니다. 어떤 키가 빠졌는지, 어떤 키가 남았는지, 원본 URL이 업무 데이터로 나갔는지.

먼저 카나리아를 만듭니다. 실제 고객이 없는 공개 페이지를 열고, 뒤에 ?utm_source=canary-share&utm_medium=email&utm_campaign=canary-2026&fbclid=canaryclid&id=42를 붙입니다. 문자열 전체를 정제 입력에 넣습니다. 실행 후 추적 키 네 개는 없어야 하고 id=42는 남아 있어야 합니다. 도구가 제거한 이름을 나열하면 이름을 하나씩 봅니다. 「URL이 짧아졌다」에서 멈추지 마세요.

그다음 개발자 도구 Network를 열고 Preserve log를 켠 뒤, 필터에 canary-share나 카나리아 쿼리 전체를 넣습니다. XHR / Fetch의 요청 줄, 쿼리, 본문에 나오면 안 되고, 분석 전송의 query와 body에도 나오면 안 됩니다. 정적 자원, 스타일, 스크립트는 나와도 됩니다. 페이지 자신의 파일입니다. 실패는 원문이 업무 필드로 나가는 것입니다. 제목이나 경로에 「개인정보」「정제」가 있는 것은 예상입니다. 입력칸 전문이 나가는 것은 아닙니다.

1. utm_*, fbclid, 업무 id가 있는 카나리아 URL을 만듭니다. 실제 고객이나 진행 중인 캠페인 이름은 쓰지 마세요.
2. 정제 후 표를 봅니다. 추적 키는 「제거됨」 쪽, id는 결과 URL에 있어야 합니다.
3. Network에서 카나리아 문자열을 검색합니다. 업무 요청에 한 번이라도 걸리면 원문이 이 탭을 떠난 것입니다.

증명의 범위는 좁습니다. 이번 실행에서 알려진 추적 키가 규칙대로 사라지고, 업무 키는 남고, 원문이 관찰한 HTTP 필드로 이 탭을 떠나지 않았다는 것입니다. 확장 프로그램이 입력을 읽지 않았다는 증명은 아니며, 규칙 표 밖의 사용자 정의 추적이 처리되었다는 증명도 아닙니다. 브라우저나 규칙표를 바꾼 뒤에는 카나리아를 다시 돌리세요.

계정 없이 열리는 정제 페이지에서 규칙을 익히세요

제거 목록을 페이지에 적어 주는 도구로 연습하고 싶다면 MakePwd의 UTM 제거·개인정보 마스킹부터 시작하면 됩니다. 가입과 계정이 필요 없고, 열자마자 씁니다. URL 해석과 파라미터 제거는 현재 탭에서 일어납니다. 제품 설명대로 원문은 요청으로 나가지 않고 analytics에도 쓰지 않습니다. 표준 모드는 utm_*, 광고 클릭 ID, 흔한 분석 파라미터, 쇼핑몰에서 자주 보는 귀속 키를 뺍니다. 보수 모드는 UTM과 클릭 ID만 뺍니다. 경로와 id, q 같은 업무 파라미터는 남습니다. 한 번에 최대 100줄, 한 줄이 8 KB를 넘으면 거부하며, http 또는 https만 받습니다.

연습은 위의 카나리아로 하고, 진행 중인 캠페인의 실제 클릭 ID는 쓰지 마세요. 실행 후 두 곳을 동시에 봅니다. 결과 영역의 제거 목록, 그리고 Network에 원문이 있는지. 목록은 「옳은 키를 지웠는가」용입니다. Network는 「올렸는가」용입니다. 둘 다 지나야 동료에게 말할 수 있습니다. 내가 뺀 키는 이것들이고, 카나리아를 검색해 나가지 않았다.

정제가 다루는 것은 링크 형태뿐입니다. 채팅이나 티켓 본문의 전화번호, 주민등록번호, 이메일, API 키는 같은 페이지의 개인정보 마스킹으로 가서 패턴으로 가린 뒤, 사람이 다시 봐야 합니다. MakePwd는 개인정보 보호법이나 GDPR 인증을 주장하지 않습니다. 정제 결과가 여전히 오래 남으면 안 되는 비밀이라면 일회용 링크로 한 번 보내고, 키는 URL의 # 프래그먼트에 둡니다. 파일 전체는 파일 암호화에서 이 기기로 .lock / .enc를 만든 뒤 드라이브나 메일로 보냅니다. 이 단계에는 로그인이 필요 없습니다.

자주 묻는 질문

UTM을 빼면 수신자가 페이지를 못 엽니까?

아닙니다. 업무 파라미터와 경로가 남아 있으면 엽니다. UTM과 클릭 ID는 귀속용이지 라우팅용이 아닙니다. utm_campaign이나 fbclid를 지워도 랜딩은 경로와 id로 열려야 합니다. 404이거나 결과가 바뀌면 업무 키를 다친 것입니다. 보수 모드로 돌아가 키를 하나씩 대조하세요.

HTTPS가 이미 이 파라미터를 지킵니까?

보내는 그 순간은 지키지 않습니다. HTTPS는 경로상 도청 위험을 낮춥니다. 주소창, 기록, 채팅, 로그는 지우지 않습니다. OWASP는 암호화 채널에서도 쿼리가 Referer, 웹 로그, 공유 시스템, 브라우저 기록에 남는다고 적습니다. 전체 URL을 붙여도 되는지는 사이트에 인증서가 있는지와 다른 질문입니다.

Apple이 추적을 떼어 주는데, 그래도 직접 빼야 합니까?

빼야 합니다. 시스템 기능은 메시지 공유, Safari 비공개 브라우징처럼 문서화된 경로에 작용하고, Apple은 전체 키 목록을 공개하지 않습니다. UTM은 보통 남습니다. 티켓이나 안드로이드 채팅에 붙일 때는 그 보호가 대신 실행되지 않습니다. 발송 정책이 보는 것은 클립보드이지, 상대 OS가 다시 벗겨 줄지가 아닙니다.

클린 링크가 상품 id도 지웁니까?

이름 기준으로 동작하면 지우면 안 됩니다. id, q, sku는 utm_ 접두사가 아니고, 흔한 클릭 ID 표에도 없습니다. 확인 방법은 추적 키와 업무 키를 함께 넣은 카나리아에서 전자만 사라졌는지 보는 것입니다. 사이트가 추적을 사용자 정의 키에 쓰면 규칙 표는 모릅니다. 손으로 지우거나 목록을 늘리세요.

다음에 보내기 전에 기억할 세 가지

첫째, 주소창 전체 선택은 「보내도 된다」가 아닙니다. 쿼리를 캠페인 태그, 클릭 ID, 사이트 안 귀속, 업무 파라미터로 나눕니다. 기본으로 남을 것은 마지막뿐입니다. 둘째, HTTPS와 OS 자동 제거는 클립보드 확인을 대신하지 않습니다. 쿼리는 기록, 티켓, 로그에 남고, Referer로 한 번 더 갈 수 있습니다. 셋째, 확인할 곳은 두 곳입니다. 제거된 키 목록, 그리고 카나리아로 Network를 검색하는 것.

다음 질문이 「평문이 업무 데이터로 이 탭을 떠났는가」라면 브라우저에서 암호화할 때, 평문이 나가지 않았는지 직접 확인하는 법을 읽으세요. 이 글은 「전체 링크를 보낼 때 어떤 쿼리가 따라가면 안 되는지」만 결론에 쓸 수 있는 범위로 줄입니다.