먼저 결론입니다. 공유 전에 빼는 것은, 물음표 뒤에 「어디서 눌렀는지」를 적어 둔 쿼리입니다. 확인 방법은 링크가 짧아졌다는 느낌이 아닙니다. 제거된 파라미터 목록을 읽고, pathname과 id=, q=가 남았는지 봅니다. 정리한 URL은 시크릿 방문이 아니며, 랜딩 페이지에 측정 스크립트가 없다는 증명도 아닙니다.
검색 의도를 한 문장으로 먼저 답하기
링크를 공유하기 전에 추적 파라미터를 빼는 이유는, 쿼리스트링이 HTTP 요청 대상의 일부이기 때문입니다. 브라우저가 문서를 가져갈 때 물음표 뒤의 utm_source, fbclid, gclid는 요청 줄에 쓰입니다. 호스팅, 리버스 프록시, 접속 로그는 설계상 그것을 봅니다. 이 문자열 전체를 카카오톡이나 티켓에 붙이면, 유입원과 클릭 표시까지 다음에 여는 사람에게 넘긴 것입니다.
이 글은 운영, 고객지원, 그리고 자료를 밖으로 보내기 전에 「주소에 이미 무엇이 적혀 있는지」와 「연 뒤에 무엇이 일어나는지」를 나누고 싶은 사람을 위한 것입니다. 링크 정리 사용 설명을 대신하지 않으며, 「어느 버튼을 눌러 깨끗한 주소를 얻는가」도 반복하지 않습니다. 가져가야 할 것은 UTM과 클릭 ID가 각각 무엇을 쓰는지, 공유할 때 누가 그것을 이어받는지, 빼고 나서 아직 증명할 수 있는 것, 제거 목록과 Network로 그 자리에서 대조하는 방법입니다.
물음표 뒤 글자는 HTTP에 들어갑니다. 나만 보는 칸이 아닙니다
RFC 3986 §3.4는 query를 첫 번째 ? 뒤, 프래그먼트 앞까지의 구간으로 정의합니다. RFC 9110은 이어서, 요청의 대상 URI가 경로와 쿼리를 포함하고 프래그먼트는 포함하지 않는다고 정합니다. 주소창이 긴 것은 보기 문제가 아닙니다. 이번 문서 요청이 물음표 뒤의 키와 값을 상대에게 넘깁니다.
해시 뒤 프래그먼트는 기본적으로 지금 연 탭에 남습니다. 그 대조 방법은 다른 노트에 적어 두었습니다. 이 글은 물음표만 봅니다. 두 규칙을 나란히 두면, 「서버는 # 뒤의 키를 보지 못한다」를 「서버는 ? 뒤의 유입원도 보지 못한다」로 읽지 않습니다.
브라우저의 URLSearchParams는 쿼리를 키와 값으로 나눈 뒤, 이름으로 지우고 주소를 다시 맞출 수 있습니다. 정리 도구가 움직이는 층이 바로 여기입니다. 문자열을 고치는 것이지, 랜딩 페이지의 스크립트를 끄지 않습니다. utm_campaign을 지워도 상대 사이트의 측정 픽셀은 꺼지지 않습니다.
UTM이 쓰는 것은 유입원이지, 장식용 접미사가 아닙니다
Google Analytics는 수동 태그를 utm_* 쿼리 한 세트로 설명합니다. 도움말의 흔한 대응은 이렇습니다. utm_source는 유입원, utm_medium은 매체, utm_campaign은 캠페인 이름이고, 이외에 utm_term, utm_content, utm_id, 비교적 새로운 utm_source_platform 등이 있습니다. 공식 예는 http://www.example.com/?utm_source=google&utm_medium=cpc&utm_campaign=summersale입니다. 추측이 아니라 Analytics 트래픽 소스 설명의 표기입니다.
집행하는 쪽에는 쓸모가 있습니다. 같은 글을 메일, 영상 설명, 단체 공지에서 나눠 셀 수 있습니다. 다음에 링크를 여는 사람에게는 평문 메모입니다. 티켓에 utm_source=vip_kakao&utm_campaign=refund_202609가 있으면, 당번, 나중에 티켓을 검색하는 사람, 표로 내보내는 사람 모두 「어느 비공개 캠페인에서 눌렀는지」를 읽습니다.
UTM 자체에는 보통 주민등록번호나 비밀번호가 들어가지 않습니다. 새는 것은 맥락입니다. 어느 메일을 열었는지, 어느 광고를 눌렀는지, 고객지원 전용 링크로 들어왔는지. 그 맥락이 전달 가능한 URL에 들어가는 순간, 자기 탭에만 머무르지 않습니다.
클릭 ID가 가리키는 것은 그 한 번이지, 캠페인 이름이 아닙니다
클릭 ID는 캠페인 이름보다 「이번 클릭」에 가까운 번호입니다. Google 광고의 자동 태그는 랜딩 URL 뒤에 gclid(Google Click Identifier)를 붙입니다. 공식 형태는 www.example.com/?gclid=123xyz입니다. 자동 태그가 켜져 있고 사이트에 Analytics가 있으면, 이 값은 사이트 도메인의 쿠키에도 쓰여 이후 전환을 그 클릭으로 되돌릴 수 있습니다. 근거는 Google 광고 자동 태그 설명입니다.
iOS 14 이후의 일부 장면에서는, 동의가 없으면 gclid를 쓰지 않습니다. Google은 따로 gbraid(웹에서 앱 쪽)와 wbraid(앱에서 웹 쪽)를 넣어, 플랫폼 제한 아래에서도 광고 측정을 이어 갑니다. 이는 Analytics의 iOS 14+ 캠페인 측정 설명이며, 정리 도구가 만든 분류가 아닙니다.
Meta 쪽에서 자주 보는 이름은 fbclid입니다. 개발자 문서는, 페이지 URL에 이 쿼리가 있으면 Conversions API가 그것으로 fbc를 만들 수 있다고 적습니다. 사이트에 Meta Pixel이 있으면 클릭 번호는 _fbc라는 퍼스트파티 쿠키에도 들어가며, 형태는 version.subdomainIndex.creationTime.fbclid입니다. 근거는 Meta의 fbp / fbc 파라미터 설명입니다. fbclid가 붙은 주소를 동료에게 넘기면, 동료가 열 때 상대 사이트는 「이번 클릭」 표시를 자기 쿠키와 이후 보고에 넣을 수 있습니다.
같은 계열 이름은 msclkid, ttclid, twclid, li_fat_id로도 나옵니다. 각각 자기 광고 계정을 위해 쓰입니다. 공통점은 단순합니다. 쿼리에 쓰면 요청 줄과 함께 가고, 공유하는 문자열에 쓰면 다음에 여는 사람이 이어받습니다.
실제 집행 링크, 고객 전화번호가 들어 있는 단축 URL, 마스킹하지 않은 티켓으로 실험하지 마세요. 공개해도 되는 예시를 준비하고, 값에는 한 번만 쓰는 표시를 넣으세요. 대조하는 것은 쿼리와 요청 줄이지, 업무 유입을 한 번 더 퍼뜨리는 일이 아닙니다.
공유하면 다음 사람이 쿼리 전체를 이어받습니다
공유 버튼, 브라우저의 「주소 복사」, 채팅 기록을 길게 눌러 복사하는 동작은, 사이트가 바깥에 보여주고 싶은 짧은 경로가 아니라 지금 주소창의 전체 URL을 잡는 경우가 많습니다. 카카오톡, 메일, 광고 미리보기에서 특히 분명합니다. 눈에 보이는 것은 글이나 상품인데, 클립보드에는 pathname 뒤에 어트리뷰션 칸이 붙은 긴 열이 들어갑니다.
이 칸은 세 곳으로 갑니다. 첫째, 채팅과 티켓 본문입니다. 스레드의 전원과 나중에 검색하는 사람이 읽습니다. 둘째, 상대의 주소창과, 거기서 동기화되는 기록입니다. 셋째, 상대가 열 때 보내는 문서 요청입니다. 서버 로그에는 완전한 쿼리가 남습니다. 자기 채팅에서 그 한 줄을 지워도, 이미 연 사람과 이미 쓰인 로그는 바뀌지 않습니다.
집행 측정 링크를 대외 공지에 그대로 붙이는 일, 이용자가 복사해 온 긴 URL을 티켓에 그대로 되돌리는 일, gclid가 붙은 재현 주소를 이슈에 붙이는 일. 모두 같은 동작입니다. 자기 주소창에 있던 클릭 맥락을, 「이 글자를 본 사람이면 다시 쓸 수 있는 표시」로 바꿉니다.
빼고 나서 증명할 수 있는 것과, 주소에 남는 것
정리한 URL이 받쳐 줄 수 있는 주장은 좁습니다. 좁게 써야 오독이 한 번 줄어듭니다. 받쳐 줄 수 있는 것은, 사용한 목록과 이번 실행에서 알려진 utm_*, 클릭 ID, (더 넓은 모드라면) 일부 어트리뷰션 칸이 쿼리에서 사라졌다는 점입니다. pathname은 남습니다. id=, q= 같은 업무 파라미터는 설계대로 남깁니다. 링크는 같은 글을 열어야 합니다.
받쳐 줄 수 없는 것은, 랜딩 페이지에 픽셀이 없다는 것, 상대 사이트에 퍼스트파티 쿠키가 없다는 것, 단축 URL이 뛴 뒤에 새 파라미터를 붙이지 않는다는 것, 경로 자체에 추적 토큰이 없다는 것, 확장 프로그램이 클립보드를 바꾸지 않았다는 것입니다. 「연 뒤에 아무도 당신이 누구인지 모른다」도 말할 수 없습니다. 고친 것은 이제 보내려는 문자열입니다. 다음 브라우징 세션이 아닙니다.
가장 흔한 겉보기 합격은 단축 URL입니다. 단축 서비스는 진짜 목적지를 자기 리디렉션 뒤에 숨깁니다. https://short.example/abc를 정리하면 쿼리가 비어 있는 경우가 많아, 도구는 「뺄 파라미터가 없다」고 보고합니다. 추적은 302 뒤의 긴 URL에 있습니다. 대조하려면 시크릿 창에서 단축 URL을 연 뒤 주소창의 최종 URL을 복사하세요. 실제 개인정보가 들어 있는 단축 URL로는 이 단계를 밟지 마세요.
| 보이는 변화 | 받쳐 줄 수 있는 결론 | 받쳐 줄 수 없는 결론 |
|---|---|---|
| 링크가 짧아졌다 | 쿼리 글자가 줄었다 | 이미 익명, 이미 안전하다 |
제거 목록에 utm_*, fbclid가 있다 |
이 키가 이 URL에서 지워졌다 | 랜딩 페이지가 _fbc나 Analytics 쿠키를 쓰지 않는다 |
id=, q=가 남아 있다 |
업무 위치 지정은 설계대로 남았다 | 남은 키가 모두 업무에 필요하다 |
| 단축 URL이 「뺄 것이 없다」고 한다 | 이 짧은 주소 자체는 목록에 맞지 않았다 | 리디렉션 뒤의 긴 URL도 깨끗하다 |
| Network에 원본 링크가 없다 | 이번 정리 요청이 원문을 업무 데이터로 보내지 않았다 | 확장 프로그램과 채팅 클라이언트도 저장하지 않았다 |
그 자리에서 대조하기: 제거 목록과 Network
구호는 증거가 되지 않습니다. 이 기기에서 끝낼 수 있는 확인은 두 층입니다. 하나는 정리 결과, 다른 하나는 나가는 통신입니다. 버려도 되는 예시를 준비하세요. 예는 다음과 같습니다.
https://example.com/article/42?id=42&q=aes&utm_source=kakao&utm_medium=social&utm_campaign=share_20260903&fbclid=IwAR0canaryfp&spm=demo.share.0
카나리아는 utm_campaign과 fbclid 값에 둡니다. 정리한 뒤, 깨끗한 주소에 share_20260903이나 IwAR0canaryfp는 나오면 안 됩니다. id=42와 q=aes는 남아 있어야 합니다.
- 먼저 제거된 파라미터 목록을 읽으세요.
utm_source,utm_medium,utm_campaign,fbclid가 보여야 합니다. 더 넓은 모드라면spm같은 쇼핑몰 어트리뷰션 이름도 나옵니다. 목록이 비었는데 「깨끗해졌다」고 느껴지면, 단축 URL이거나 경로에 쓴 표시를 의심하세요. - 다음으로 깨끗한 주소의 pathname과 남은 쿼리를 읽으세요. 글 번호나 검색어가 사라졌다면 오삭제입니다. 그 결과는 보내지 마세요.
- 개발자 도구의 Network를 열고 Preserve log를 켠 뒤, 필터는 All로 두세요. 카나리아를 검색창에 붙이세요. 요청 줄, 본문, 분석 보고에 그 더러운 링크는 나오면 안 됩니다.
FastPwd의 링크 정리는 이 경계에서 동작합니다. 파싱은 지금 연 탭에서 이뤄집니다. 개별 주소가 8 KB를 넘으면 거부하고, 한 번에 처리할 수 있는 줄은 최대 100개이며, 받는 것은 http / https뿐입니다. 보수 모드가 빼는 것은 utm_*와 클릭 ID(fbclid, gclid, gbraid, wbraid, msclkid 등)입니다. 표준 모드는 여기에 _ga / _gl, 메일의 mc_eid / mc_cid, 쇼핑몰의 spm / scm, _x_* 같은 접두사, share_token 같은 공유 토큰, 그리고 남기도록 켜지 않았을 때의 ref / referrer를 뺍니다. pathname과 id= / q=는 남깁니다. 도구는 열어 바로 쓰며 계정이 없습니다. 접속 분석이 기록하는 것은 「정리를 실행함」 같은 이벤트 이름이지, 원문이 아닙니다. 약속은 약속으로 남습니다. 믿을 것은 이번 목록과 Network에서 본 내용입니다.
어떤 키가 업무 파라미터인지 확신이 없으면 보수 모드로 바꾸세요. 먼저 UTM과 클릭 ID를 공유 문자열에서 빼고, spm이나 ref를 남길지는 눈으로 정하세요. 목록이 건드리지 않는 키는 눈으로 지웁니다. 「짧아졌다」에 전부를 맡기지 마세요.
깨끗해 보이지만 실제로 빠지지 않은 세 가지
첫째, 추적이 경로에 있습니다. 어떤 공유 페이지는 /s/xxxx나 유입 접두사를 path에 쓰고, 쿼리는 비어 있습니다. 이름으로 쿼리를 지워도 주소는 거의 변하지 않습니다. 대조할 것은 뛴 뒤의 정규 주소이지, 공유 버튼이 방금 내보낸 리디렉션 껍데기가 아닙니다.
둘째, 정리 도구는 searchParams만 움직이고 hash는 건드리지 않습니다. 추적이 해시 뒤에 쓰여 있으면 쿼리 정리는 합격으로 보고합니다. 확인은 주소창 전체와 결과 전체를 나란히 보는 것입니다. 물음표 앞에서 멈추지 마세요.
셋째, 보내려던 문자열은 정리했는데, 채팅 클라이언트가 보낼 때 파라미터를 붙입니다. 바깥으로 나가는 링크에 자기 클릭 표시를 찍는 클라이언트가 있습니다. 보낸 뒤 다른 창에서 방금 보낸 메시지를 열고 주소창을 한 번 더 보세요. 정리는 붙이기 전에 일어납니다. 보낸 뒤에도 표본 확인이 필요합니다.
자주 묻는 질문
UTM을 뺀 뒤에도 링크를 연 사람은 추적되나요?
됩니다. 뺀 것은 이제 보내려는 그 문자열의 쿼리입니다. 랜딩 페이지에는 픽셀, 퍼스트파티 쿠키, 로그인 상태가 남을 수 있습니다. Meta 문서도, URL에 잠시 fbclid가 없더라도 사이트가 이미 _fbc를 써 두었다면 이후 이벤트에 붙일 수 있다고 적습니다. 빼고 나서 증명할 수 있는 것은, 이 URL에서 알려진 추적 파라미터가 사라졌다는 점뿐입니다. 다음 방문이 익명이라는 뜻은 아닙니다.
링크 정리가 글 id나 검색어까지 지우나요?
이름 목록으로 정리할 때 pathname과 id=, q= 같은 업무 쿼리는 남깁니다. 확신이 없으면 보수 모드를 써서 utm_*와 클릭 ID만 빼세요. 정리한 뒤에는 제거된 파라미터 목록을 대조하고, 링크가 짧아진 것만 근거로 삼지 마세요. 필요한 키가 그 목록에 나왔다면 이번 결과는 쓰지 마세요.
단축 URL도 먼저 파라미터를 빼야 하나요?
단축 URL 자체에는 UTM이 없는 경우가 많습니다. 추적은 리디렉션 뒤의 긴 주소에 있습니다. 짧은 형태만 정리하면 대개 아무것도 빠지지 않습니다. 시크릿 창에서 연 뒤 주소창의 최종 URL을 복사해 빼세요. 실제 개인정보가 들어 있는 단축 URL로 실험하지 마세요. 공개해도 되는 예시로 충분합니다.
FastPwd에서 정리할 때 원본 링크가 업로드되나요?
제품 설명대로 파싱과 제거는 지금 연 탭에서 끝납니다. 원문은 HTTP 업무 데이터로 나가지 않고, 접속 분석에도 쓰지 않습니다. 접속 분석이 기록하는 것은 「정리를 실행함」 같은 이벤트 이름입니다. 이번을 대조하려면 카나리아를 Network에서 검색하세요. 요청 줄, 본문, 분석 보고에 그 더러운 링크는 나오면 안 됩니다. localhost는 기본적으로 접속 분석을 보내지 않습니다. 실제 사용에 가깝게 보려면 공개 도메인에서 한 번 더 보세요.
같은 링크를, 열어 바로 쓰는 도구로 대조하기
제거 목록을 화면에 적어 둔 페이지에서 연습하려면 FastPwd의 링크 정리를 여세요. 가입은 필요 없습니다. 위의 예시를 붙인 뒤 먼저 보수 모드, 이어서 표준 모드를 실행하고 두 「제거」 칩을 비교하세요. 두 모드 모두 UTM과 fbclid를 빼고, 표준 모드만 spm을 건드려야 합니다. 깨끗한 결과에는 id와 q가 남아 있어야 합니다.
같은 페이지는 티켓 본문의 휴대폰 번호와 이메일을 가리는 민감정보 마스킹으로도 전환할 수 있습니다. 그것은 다른 글의 주제입니다. 비밀 묶음을 동료에게 넘겨야 하면 열람 후 파기를 쓰세요. 이 기기에서 AES-256-GCM으로 암호화하고, 서버가 잠시 보관하는 것은 암호문뿐입니다. 키는 링크의 해시 뒤에 남습니다. 방금 정리한 업무 링크와 열람 후 파기 전체 주소를 같은 스레드에 나란히 붙이지 마세요.
다음에 보내기 전에 셋을 기억하세요. 첫째, 물음표는 HTTP에 들어가며 유입원과 클릭 ID는 거기에 있습니다. 둘째, 빼는 작업이 바꾸는 것은 이제 보내려는 문자열이지, 랜딩 페이지의 측정이 멈추지 않습니다. 셋째, 단축 URL, 경로의 표시, 보낸 뒤에 붙는 파라미터는 각각 따로 대조해야 합니다. 반복할 수 있는 관찰만 자기들의 발송 안내에 쓸 가치가 있습니다.
더 읽을거리
물음표와 해시를 섞지 마세요. 키를 # 뒤에 둘 수 있는 이유와, 전체 링크를 채팅에 붙일 때 사라지는 층은 URL 해시 뒤에 키를 두는 이유, 그리고 그 보호가 깨질 때에 있습니다. 티켓 본문의 휴대폰 번호, 주민등록번호, API Key를 이 기기를 떠나기 전에 대조하는 방법은 티켓과 로그를 AI에 붙이기 전에, 어떤 항목이 이 기기를 떠나는지 먼저 확인하는 방법입니다. 정리 과정 자체가 원본 링크를 업무 데이터로 보내지 않았는지를 보려면 브라우저 로컬 암호화에서 원문이 이 기기를 떠나지 않았는지 확인하는 방법의 카나리아 절차로 충분합니다.