Cloudflare Workers 및 Transform Rules로 트래킹 파라미터 제거하기

왜 트래킹 파라미터가 캐시 적중률을 파괴하는가

utm_source, gclid, fbclid와 같은 트래킹 파라미터는 마케터가 캠페인 성과를 측정하는 데 도움을 줍니다. 하지만 Core Web Vitals 측면에서 이는 캐싱을 깨뜨리기 때문에 악몽과 같습니다. 모든 고유한 URL은 별도의 캐시 항목을 생성합니다. Facebook에서 공유된 단일 페이지는 클릭할 때마다 고유한 fbclid를 갖게 되며, 이는 Facebook에서 오는 모든 방문자가 캐시 미스와 느린 Time to First Byte를 경험하게 됨을 의미합니다.

Cloudflare는 이러한 파라미터가 캐시를 오염시키기 전에 엣지에서 이를 제거하는 3가지 방법을 제공합니다: Transform Rules(코드 없음), Workers(완전한 제어), Cache Key 사용자 지정(엔터프라이즈). 3가지 모두 다루겠습니다.

최종 검토자 Arjen Karel (2026년 3월)

트래킹 파라미터에 따른 캐싱 문제

캐싱 시스템은 전체 URL을 캐시 키로 사용합니다. URL에 ?utm_source=google 또는 ?fbclid=abc123이 포함되어 있다면, 콘텐츠가 동일하더라도 캐시는 이를 다른 페이지로 취급합니다. 이것이 바로 캐시 미스입니다. 서버는 단지 쿼리 문자열 값이 다르다는 이유만으로 이미 캐시된 페이지를 다시 빌드합니다.

이 문제의 규모는 대부분의 사람들이 생각하는 것보다 훨씬 큽니다. 마케팅 생태계 전반에 걸쳐 알려진 트래킹 파라미터가 129개나 있습니다. 그중 fbclid 파라미터는 Facebook이 유료 광고뿐만 아니라 모든 아웃바운드 링크 클릭에 이를 추가하기 때문에 가장 파괴적입니다. 모든 오가닉 공유, 댓글의 링크, 사이트로 연결되는 모든 게시물에는 고유한 fbclid 값이 생성됩니다.

2025 Web Almanac에 따르면 모바일 오리진의 44%만이 양호한 TTFB를 보입니다. Cloudflare는 쿼리 문자열 캐싱 동작을 수정하면 평균적으로 캐시 적중률이 3% 향상되고 오리진 바이트가 5% 감소한다고 보고했습니다. 이는 방문자의 Largest Contentful Paint 향상으로 직접 이어집니다.

모든 쿼리 파라미터가 쓸모없는 트래킹 용도는 아닙니다. ?q=laptops나 ?color=blue와 같은 파라미터는 페이지 콘텐츠를 변경합니다. 목표는 콘텐츠에 영향을 주는 파라미터는 유지하면서 영향을 주지 않는 파라미터만 제거하는 것입니다.

어떤 트래킹 파라미터를 제거해야 할까요?

플랫폼별로 그룹화된 가장 일반적인 트래킹 파라미터는 다음과 같습니다. 이들은 페이지 콘텐츠를 변경하지 않고 고유하며 캐시할 수 없는 URL을 생성합니다:

이것이 전체 목록은 아닙니다. 트래킹 쿼리 파라미터 레지스트리에는 알려진 129개의 모든 파라미터가 문서화되어 있습니다. 대부분의 사이트에서는 Google, Meta 및 Microsoft 파라미터를 처리하는 것만으로 문제의 95%를 해결할 수 있습니다.

옵션 1: Transform Rules (코드 불필요)

Cloudflare에는 요청이 캐시에 도달하기 전에 URL에서 특정 쿼리 파라미터를 제거하는 remove_query_args()라는 내장 함수가 있습니다. 이는 Transform Rule로 실행되며 코드가 필요 없고 무료 계층을 포함한 모든 플랜에서 사용할 수 있습니다.

설정 방법:

1. Cloudflare 대시보드에서 Rules, Transform Rules, URL Rewrite로 이동합니다.
2. 새 규칙을 생성합니다.
3. 필터를 도메인과 일치하도록 설정합니다. 예: (http.host eq "example.com")
4. Query의 경우 Rewrite to를 선택한 다음 Dynamic을 선택합니다.
5. 다음 표현식을 입력합니다:
   remove_query_args(http.request.uri.query, "utm_source", "utm_medium", "utm_campaign", "utm_term", "utm_content", "utm_id", "gclid", "gclsrc", "wbraid", "gbraid", "dclid", "gad_source", "fbclid", "msclkid", "ttclid", "twclid", "li_fat_id", "epik", "srsltid", "_ga", "_gl")
6. Path의 경우 Preserve를 선택합니다.

이것이 전부입니다. Worker나 코드 배포가 필요하지 않습니다. 무료 플랜은 10개의 Transform Rules를 허용하고, Pro는 25개를 허용합니다. 대부분의 사이트에는 이것이 가장 좋은 옵션입니다.

옵션 2: Cloudflare Workers

Cloudflare에는 쿼리 문자열을 무시하는 기본 옵션이 있지만, 이러한 보수적인 설정은 Cloudflare 플랜을 최대한 활용하기에 충분하지 않습니다. Transform Rules가 제공하는 것보다 더 많은 제어(예: 정규식 일치, 조건부 논리 또는 로깅)가 필요한 경우 Cloudflare Worker가 완전한 유연성을 제공합니다.

Workers는 엣지에서 요청을 가로채서 요청이 캐시나 오리진에 도달하기 전에 코드를 실행합니다. Cloudflare는 TLS 핸드셰이크 중에 Workers를 로드하므로 실제 오버헤드는 1밀리초 미만입니다.

코드

다음은 현재 ES 모듈 구문을 사용하는 전체 Worker 스크립트입니다:

export default {
  async fetch(request) {
    const url = new URL(request.url)

    const trackingParams = /^(utm_|gad_|gclid|gclsrc|wbraid|gbraid|dclid|fbclid|fb_action_|srsltid|msclkid|ttclid|twclid|li_fat_id|epik|igshid|_ga$|_gl$|mc_[ce]id|_hs[em])/

    // Collect matching keys first (do not delete during iteration)
    const keysToDelete = [...url.searchParams.keys()].filter(
      key => trackingParams.test(key)
    )

    keysToDelete.forEach(key => url.searchParams.delete(key))

    return fetch(url.toString(), request)
  }
}

Worker는 URL을 구문 분석하고, 각 쿼리 파라미터를 정규식에 대해 테스트한 다음, 일치하는 항목을 제거합니다. 그런 다음 깔끔한 URL이 캐시와 오리진으로 이동합니다. 여기서 두 가지 세부 사항이 중요합니다: URLSearchParams 반복 중에 삭제하면 항목을 건너뛸 수 있으므로(이는 라이브 반복기에서 알려진 사양 문제임), 코드는 삭제하기 전에 키를 배열로 수집합니다. 또한 Cloudflare가 이전 addEventListener 구문을 더 이상 사용하지 않으므로 스크립트는 ES 모듈 형식(export default)을 사용합니다.

배포

1. Cloudflare에 로그인합니다. Cloudflare 대시보드에 로그인합니다.
2. Worker를 생성합니다. 아직 사이트로 이동하지 마세요. Workers 섹션으로 이동하여 새 Worker를 생성합니다.
   
3. worker의 이름을 지정하고 배포합니다. 이 단계는 약간 직관적이지 않게 보일 수 있지만 걱정하지 마세요. 비어 있는 'hello world' worker의 이름을 지정하고 배포를 클릭하기만 하면 됩니다.
   
4. worker를 편집합니다. 다음 페이지에서 Edit Code를 클릭합니다.
   
5. 스크립트를 붙여넣습니다. 위 스크립트를 복사하여 편집기에 붙여넣습니다. 그런 다음 배포를 클릭합니다.
   
6. Worker를 라우트에 바인딩합니다. 이제 돌아가서 Cloudflare의 사이트로 이동합니다. worker routes를 클릭한 다음 'Add Route'를 클릭합니다. 새로 생성한 worker를 선택하고 사이트에 적용합니다.
   

사용자 지정

정규식을 수정하여 특정 파라미터를 포함하거나 제외할 수 있습니다. 서버 측 처리를 위해 특정 utm_ 파라미터를 유지하려면 정규식에서 제거하세요. 기본 정규식에서 다루지 않는 마케팅 플랫폼을 사용하는 경우 해당 파라미터를 추가하세요.

옵션 3: Cache Key 사용자 지정 (엔터프라이즈)

Cloudflare Enterprise 플랜을 사용하는 경우 URL에서 파라미터를 전혀 제거하지 않고도 특정 쿼리 파라미터를 제외하도록 사용자 지정 캐시 키를 구성할 수 있습니다. 캐시는 키를 계산할 때 단순히 이를 무시합니다. URL이 변경되지 않은 상태로 유지되므로 이것이 가장 깔끔한 접근 방식이지만 엔터프라이즈가 필요합니다.

비엔터프라이즈 플랜의 경우 Transform Rule 또는 Worker 접근 방식으로 동일한 캐시 이점을 얻을 수 있습니다.

어떤 접근 방식을 사용해야 할까요?

대부분의 사이트는 Transform Rules로 시작하세요. 규칙 제한에 도달하거나 더 많은 유연성이 필요한 경우 Workers로 이동하세요.

Cloudflare APO와 함께 WordPress를 사용하는 경우 이 중 어느 것도 필요하지 않을 수 있습니다. APO는 캐시 키를 계산할 때 무시하는 25개 이상의 마케팅 파라미터 허용 목록을 유지 관리합니다. Worker 또는 Transform Rule을 추가하기 전에 특정 파라미터가 포함되어 있는지 확인하세요.

파라미터를 제거하면 애널리틱스가 중단되나요?

아니요. 제거는 CDN과 오리진 서버 사이의 엣지에서 발생합니다. 브라우저 URL에는 원래 트래킹 파라미터가 여전히 포함되어 있습니다. Google 애널리틱스, Google 광고 전환 추적 및 Facebook 픽셀은 모두 클라이언트 측의 document.location에서 읽으며, 여기에는 모든 파라미터가 그대로 포함된 전체 URL이 여전히 있습니다.

이로 인해 문제가 발생할 수 있는 유일한 시나리오는 서버 측 코드가 URL에서 트래킹 파라미터를 읽는 경우입니다(예: 서버 측 애널리틱스 구현). 이 경우 해당 파라미터를 제거 대상에서 제외하거나 Worker가 제거하기 전에 요청 헤더에서 캡처하세요.

트래킹 및 애널리틱스 스크립트가 캐싱을 넘어 성능에 어떤 영향을 미치는지에 대한 자세한 내용은 애널리틱스 및 트래킹 스크립트 제한의 필요성을 참조하세요.

어떤 URL 파라미터를 제거해야 하는지 찾는 방법

올바른 도구를 사용하면 제거해야 할 URL 파라미터를 찾는 것은 쉽습니다. CoreDash와 같은 RUM 도구는 연중무휴로 사이트를 모니터링하고 성능에 미치는 영향과 함께 모든 쿼리 문자열을 기록합니다. CoreDash에서 Largest Contentful Paint로 이동하여 쿼리 문자열별 결과를 확인하세요.

CoreDash가 모니터링하는 사이트 전체에서 트래킹 파라미터가 제거된 페이지는 대략 8~15% 더 나은 캐시 적중률을 보여줍니다. 그렇지 않았다면 캐시 미스를 겪었을 방문자의 경우 이는 200~500ms 더 빠른 TTFB로 이어집니다.

Cloudflare를 사용 중이고 캐시 지속 시간 TTFB 하위 부분이 높다면, 트래킹 파라미터 오염이 가장 먼저 확인해야 할 사항 중 하나입니다. 파라미터 제거와 올바른 Cloudflare 구성을 결합하면 필드 데이터가 눈에 띄게 개선되는 것을 볼 수 있습니다.