광고 차단 오탐 완화와 애드센스 레거시 설정 제거

광고 관련 컴포넌트에서 오래된 설정을 걷어내고, 광고 차단 감지 로직의 오탐(false positive)을 완화한 작업이다.

왜 이 작업이 필요했나

enable_page_level_ads 는 예전 AdSense 스크립트에서 페이지 레벨 광고를 활성화하던 파라미터다. 예전 방식은 스크립트 src URL에 ?client=ca-pub-xxxxx 를 붙이면서 동시에 이 속성을 data-* 어트리뷰트나 별도 설정 블록으로 선언하는 구조였는데, 구글이 이 방식을 deprecated 처리한 지 꽤 됐다. 최신 AdSense는 자동 광고 설정을 별도 UI에서 관리하고, 스크립트 단에서 이 플래그를 push하는 건 이제 무의미하거나 오히려 콘솔 경고를 유발하기도 한다.

당장 광고가 안 나오거나 수익에 영향을 주는 건 아니라서 우선순위에서 계속 밀렸던 항목인데, 이번에 AntiAdblock.astro 쪽 작업을 건드리면서 같이 정리하기로 했다. 이런 "deprecated 이지만 당장 터지진 않음" 류의 기술 부채는 다른 변경과 묶일 때 처리하는 게 현실적으로 맞다고 생각한다. 팀 작업 흐름에서 별도 티켓으로 올려두면 우선순위 경쟁에서 항상 진다.

AntiAdblock 오탐 문제

이번 작업의 메인은 사실 이쪽이다. 안티애드블록 모달이 광고 차단을 감지하지 못했거나, 반대로 광고 차단을 쓰지 않는 사용자에게 모달이 뜨는 false positive 케이스가 있었다.

광고 차단 감지 로직은 보통 다음 방식들을 혼용한다:

• 특정 이름의 DOM 요소(div.ad, #banner_ad 등)를 렌더링하고, 광고 차단기가 숨기거나 제거하면 이를 감지
• 알려진 애드센스 스크립트 URL 로드 실패 여부 확인
• window.adsbygoogle 같은 전역 객체 존재 여부 체크
• CSS display: none 또는 visibility: hidden 상태 감지

false positive 가 발생하는 전형적인 원인은 아래 정도다:

• 감지용 더미 엘리먼트의 클래스명이 실제 광고 차단 필터 외에도 사이트 자체 CSS에 의해 숨겨지는 경우
• 스크립트 로드 타이밍 문제 — 감지를 너무 빨리 실행하면 광고 스크립트가 아직 평가되기 전
• SSR / 정적 생성 환경(Astro 같은)에서 hydration 전에 DOM 체크가 동작하는 케이스
• 브라우저 확장이 아닌 DNS 수준 차단 시 감지 실패

Astro 기반 프로젝트라 특히 세 번째 케이스가 의심됐다. 정적 빌드된 HTML에서 클라이언트 사이드 스크립트가 붙기 전에 감지 로직이 돌면, 광고가 로드될 여지가 없는 상황에서 차단 감지 신호를 잘못 받을 수 있다.

<!-- AntiAdblock.astro 에서 감지 타이밍을 늦추는 패턴 예시 -->
<script>
  document.addEventListener("DOMContentLoaded", () => {
    // requestIdleCallback 또는 setTimeout으로 여유를 줌
    const check = () => {
      const probe = document.getElementById("ad-probe");
      if (!probe || getComputedStyle(probe).display === "none") {
        // 차단 감지 → 모달 표시
      }
    };
    setTimeout(check, 1000); // 즉시 실행 → 지연 실행으로 완화
  });
</script>

"relax" 라는 표현을 커밋 메시지에 쓴 게 적절하다고 느꼈다. 오탐을 줄이는 방향이지, 감지를 끄는 게 아니니까. 감도를 낮추는 것과 기능을 제거하는 건 완전히 다른 의사결정이다.

Base.astro 를 같이 건드린 이유

Base.astro 는 레이아웃 루트다. deprecated push 코드가 여기 들어있었거나, 애드센스 스크립트 삽입 위치가 여기 있어서 같이 수정이 필요했을 것이다. 레이아웃 파일을 건드릴 땐 항상 신경이 쓰인다. 사이트 전체 페이지에 영향을 주는 파일이라 작은 변경도 파급이 크다.

변경 stat 가 명시되지 않아 정확한 라인 수는 모르지만, 이 두 파일 조합이면 체감상 핀포인트 수정에 가깝다. 큰 리팩터링보다는 "오래된 것 제거 + 동작 튜닝" 수준.

회고

광고 관련 코드는 특성상 로컬 개발 환경에서 제대로 테스트하기 어렵다. 브라우저 확장, 네트워크 환경, 실제 애드센스 승인 상태 등 변수가 많다. 그래서 이런 변경은 "배포해보고 실제 동작 확인" 사이클이 불가피한 면이 있다.

false positive 를 잡는 게 false negative 를 잡는 것보다 UX 관점에서 훨씬 중요하다. 광고 안 쓰는 사람한테 차단 모달이 뜨면 그냥 이탈이다. 감지가 덜 공격적이어도 실제 차단 사용자 대부분은 어차피 모달 보고 닫으니, 감도보다 정확도 쪽으로 무게를 두는 게 맞다고 판단했다.

deprecated API 는 "당장 안 터지면 나중에" 하다가 결국 어느 순간 갑자기 동작 변경으로 뒤통수 맞는 경우가 있다. 이번처럼 다른 작업에 묶어서 처리하는 습관을 들이는 게 장기적으로 낫다.

끝.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.