웹 Analytics(예: GA4, 자체 수집 스크립트, 태그 매니저)가 갑자기 안 잡히면 보통 “스크립트가 로드가 안 됐나?”부터 의심하지만, 실제로는 보안 정책(CORS/쿠키/HTTPS/CSP)이나 캐시·CDN 설정 때문에 조용히 실패하는 경우가 더 많습니다. 이 글은 Chrome DevTools 기준으로, 보안 중심으로 원인을 좁혀가고(재현→증거 확보→수정), 마지막에 캐시·CDN까지 포함해 성능/안정성 개선 루트로 정리합니다.

Shielded data pipeline representing secure analytics collection

한 번에 다 바꾸기보다, “증상 → 브라우저 증거 → 서버/배포 설정” 순서로 작은 수정부터 적용해보세요.

1) 먼저 확인: 수집이 ‘안 되는 것’인지 ‘지연/누락’인지

Analytics 이슈는 크게 2가지로 나뉩니다. (1) 아예 요청이 나가지 않거나 차단되는 경우, (2) 요청은 나가지만 일부 환경에서만 누락되는 경우입니다. 먼저 증상을 구분하면 이후 단계가 빨라집니다.

  • Network 탭에서 수집 요청 자체가 없다: 스크립트 로드 실패, CSP 차단, 초기화 코드 미실행, 라우팅/SPA 이벤트 미발생 등을 의심합니다.
  • 요청은 있는데 4xx/5xx: CORS, 인증/쿠키, 엔드포인트 경로, CDN 캐시/오리진 문제를 의심합니다.
  • 200인데도 대시보드에 안 보인다: 샘플링/필터, 이벤트 스키마, 서버 수집 파이프라인 지연, adblock/브라우저 정책(특히 3rd-party cookie) 환경별 차이를 의심합니다.

Chrome에서는 DevTools → Network에서 “analytics”, “collect”, “event”, “beacon” 같은 키워드로 필터링하고, Preserve log를 켜서 페이지 이동/리다이렉트까지 보존한 뒤 비교하는 게 좋습니다.

2) HTTPS/혼합 콘텐츠: 가장 먼저 정리할 기본

수집 스크립트나 수집 엔드포인트가 HTTP로 섞이면(혼합 콘텐츠) 브라우저가 차단하거나, 리다이렉트 과정에서 정책이 꼬여 수집이 끊길 수 있습니다. 특히 “메인 사이트는 HTTPS인데 수집 도메인은 HTTP”인 케이스가 은근히 많습니다.

  • 콘솔 경고 확인: “Mixed Content” 경고가 있으면 해당 리소스/요청부터 HTTPS로 통일합니다.
  • 리다이렉트 체인 확인: Network에서 요청 클릭 → Headers의 Request URL/Status Code/Location을 따라가며 HTTP→HTTPS 강제 리다이렉트가 반복되는지 봅니다.
  • HSTS 적용 여부: 가능하면 사이트에 HSTS를 적용해 브라우저가 항상 HTTPS로만 접근하도록 합니다(적용 전 서브도메인/인증서 구성 점검 필요).

실무 팁: 수집용 서브도메인(예: analytics.example.com)을 쓴다면, 인증서/HTTPS를 먼저 안정화한 뒤에 쿠키/보안 헤더로 넘어가는 편이 시행착오가 적습니다.

3) CORS: preflight(OPTIONS)부터 “정확히” 맞추기

브라우저에서 다른 도메인으로 이벤트를 보내는 구조라면 CORS가 가장 흔한 실패 지점입니다. 특히 fetch/XHR로 보내거나 커스텀 헤더를 붙이면 preflight(OPTIONS)가 발생하고, 여기서 막히면 실제 POST/GET이 아예 실행되지 않습니다.

CORS preflight and request flow between two domains

  • Network에서 OPTIONS 요청이 있는지 확인합니다. OPTIONS가 4xx/5xx거나 응답 헤더에 CORS가 없으면 preflight 실패입니다.
  • Access-Control-Allow-Origin은 상황에 맞게 설정합니다. 쿠키/인증을 포함한다면 “*”가 아니라 정확한 Origin을 돌려줘야 합니다.
  • Access-Control-Allow-Credentials: true는 쿠키를 보낼 때 필요합니다(단, 이때 Allow-Origin은 * 불가).
  • Access-Control-Allow-Headers에 실제 요청 헤더(예: Content-Type, Authorization 등)가 포함되어야 합니다.
  • Vary: Origin을 추가해, CDN/프록시 캐시가 다른 Origin 응답을 섞지 않게 합니다.

추적 픽셀(이미지/스크립트) 방식은 CORS 영향이 덜하지만, 요즘은 fetch/beacon을 쓰는 경우가 많아 CORS 설계를 피하기 어렵습니다. “어떤 요청 방식인지(이미지 vs XHR/fetch vs sendBeacon)”부터 명확히 하고 CORS를 맞추는 게 핵심입니다.

4) 쿠키/세션: SameSite, Secure, 3rd-party cookie 정책

Analytics가 쿠키(식별자/세션)를 쓰는 구조라면, 브라우저 정책 변화의 영향을 바로 받습니다. 특히 Chrome은 3rd-party cookie 제한 흐름이 강해지고 있어 “서드파티 도메인에 쿠키를 심고 읽는” 방식은 환경에 따라 쉽게 흔들립니다.

  • SameSite: 크로스사이트 맥락에서 쿠키가 필요하면 보통 SameSite=None; Secure가 필요합니다(HTTPS 필수).
  • Secure: HTTPS에서만 쿠키가 전송됩니다. 수집 도메인/호스트가 HTTPS가 아니면 쿠키 기반 식별이 깨집니다.
  • 도메인/경로: 쿠키 Domain, Path가 실제 요청과 일치하는지 확인합니다(서브도메인/루트 도메인 간 착각이 흔함).
  • 3rd-party cookie 차단: 서드파티 수집 도메인을 쓰는 경우, 일부 환경(시크릿/정책/확장 프로그램/미래 기본값)에서 쿠키가 아예 저장되지 않을 수 있습니다.

Chrome에서는 Application → Cookies에서 저장 여부를 확인하고, Network 요청의 Request Headers에 Cookie가 실리는지까지 같이 봐야 합니다. “쿠키가 저장은 되는데 전송이 안 된다”면 SameSite/Secure/도메인 조건을 우선 의심하세요.

5) CSP(콘텐츠 보안 정책): 스크립트/연결 차단을 놓치지 않기

보안 강화를 위해 CSP를 적용한 사이트에서 Analytics가 누락되는 경우가 많습니다. 스크립트 로드(script-src)뿐 아니라 전송(connect-src), 비콘, 이미지(img-src)까지 정책에 걸릴 수 있습니다.

Content security policy filtering scripts and connections

  • 콘솔의 CSP 에러를 먼저 봅니다. 차단된 지시어(script-src, connect-src 등)와 대상 도메인이 그대로 나옵니다.
  • SPA/동적 로딩을 쓴다면 nonce/hash 기반 CSP를 쓰는지, inline 스크립트가 막히는지 확인합니다.
  • connect-src 누락이 흔합니다. 스크립트는 로드되지만 이벤트 전송이 막혀 “조용히 안 잡히는” 형태로 나타납니다.

CSP는 “허용 리스트를 최소화”하는 게 목적이라, 필요한 도메인을 정확히 추가하되 광범위하게 풀어버리는 방향(예: unsafe-inline 남발)은 피하는 편이 안전합니다.

6) 캐시/CDN 포함 성능 개선 루트: ‘수집 안정성’까지 같이 챙기기

Analytics 스크립트/태그는 사용자 경험에 직접 영향을 주기도 하고, 캐시/CDN 구성에 따라 특정 버전이 오래 남아 장애가 길어지기도 합니다. 성능 개선은 “빠르게 로드”뿐 아니라 “배포 변경이 빠르게 반영”되도록 설계하는 게 중요합니다.

  • 스크립트 캐시 전략: 파일명에 해시를 붙여(예: app.abc123.js) Cache-Control: max-age=31536000, immutable처럼 길게 캐시하고, HTML은 짧게 캐시해 배포 반영을 빠르게 합니다.
  • CDN 캐시와 CORS/CSP 상호작용: CORS 응답은 Origin에 따라 달라질 수 있으니 Vary: Origin을 설정하고, CDN이 헤더를 누락/변경하지 않는지 확인합니다.
  • 프리플라이트 캐시: 서버가 OPTIONS를 제대로 처리하더라도, CDN/프록시가 OPTIONS를 막거나 캐시 정책이 이상하면 불안정해질 수 있습니다. OPTIONS가 오리진까지 도달하는지 추적합니다.
  • sendBeacon 우선 고려: 페이지 이탈 직전 이벤트는 fetch보다 sendBeacon이 유리한 경우가 많습니다(단, 서버 수신/CORS 구성 필요).
  • 관측 가능성: 장애 때 바로 확인할 수 있도록 수집 엔드포인트에 대한 4xx/5xx 비율, OPTIONS 실패율, 응답 시간 같은 지표를 서버/로그에서 따로 봅니다.

마지막으로, adblock/추적 방지 환경에서 “의도치 않은 누락”은 완전히 0으로 만들기 어렵습니다. 대신 누락률을 측정할 수 있게(예: 서버 로그 기반 보조 카운트, 실패 원인 코드 로깅) 설계를 보완하면 운영이 훨씬 편해집니다.

마무리

Analytics 문제는 대개 보안 정책(CORS/쿠키/HTTPS/CSP)에서 먼저 터지고, 캐시·CDN 구성 때문에 “고쳐도 안 고쳐진 것처럼 보이는” 상황이 뒤따릅니다. Chrome DevTools로 증거를 잡고, 가장 영향이 큰 기본(HTTPS→CORS→쿠키→CSP)부터 순서대로 정리해보세요.

수집이 다시 살아난 뒤에는 캐시 전략과 CDN 헤더(Vary, CORS 관련)를 점검해 재발 가능성을 줄이는 게 다음 단계입니다.