블로그에서 AdSense 플레이스홀더를 전면 제거한 이유

블로그에 붙여두었던 AdSense 플레이스홀더를 전부 걷어냈다.

승인이 떨어지기 전에 미리 컴포넌트를 심어두는 방식이 꽤 흔한데, 이번에도 그 패턴을 따랐다가 정리 커밋을 따로 날리게 됐다. 작은 chore 커밋이지만 건드린 파일이 세 개고, 각 파일이 하는 역할이 서로 달라서 나름 의사결정 포인트가 있었음.

세 파일이 각각 담당하던 것

Base.astro가 루트 레이아웃이라는 게 포인트였다. 여기서 슬롯을 걷어내면 사이트 전체 모든 페이지에서 광고 관련 DOM이 사라지는 구조. 반대로 말하면 플레이스홀더가 살아있는 동안은 모든 페이지 렌더링에 그 흔적이 따라다니고 있었다는 얘기다.

AntiAdblock.astro는 좀 고민했다. 광고차단 감지 로직 자체는 나중에 재사용할 수 있으니 파일을 아예 날릴지, 내용만 비울지. 결국 AdSense 승인 전 상태에서 감지 로직이 돌아도 의미가 없고 오히려 방문자 입장에서 불필요한 스크립트가 실행되는 게 낫지 않다고 판단해서 제거 쪽으로 결론 냈다.

"미리 짜두기" 의 양날

광고 슬롯이나 서드파티 연동을 승인/계약 전에 미리 컴포넌트로 만들어두는 건 나쁜 전략이 아니다. 승인 나는 순간 바로 붙이면 되니까. 문제는 그 플레이스홀더가 실제 프로덕션에 올라가 있을 때다.

• 빈 <div> 나 <ins> 태그가 레이아웃에 영향을 줄 수 있음
• 불필요한 JS 번들이 포함될 수 있음
• 나중에 "이게 왜 있지?" 하는 컨텍스트 손실 발생
• 협업 상황이라면 팀원이 이 플레이스홀더를 보고 "이미 연동된 거 아닌가?" 착각할 수 있음

개인 블로그라 팀원 혼선은 해당 없지만, 마지막 배포된 소스와 실제 동작 의도가 어긋나는 상태가 불편했다. 커밋 히스토리를 나중에 다시 볼 때도 "왜 AntiAdblock이 Base에 있지?" 라는 의문이 생길 수 있으니까.

승인 대기 중 플레이스홀더 관리 패턴

---
// AdSlot.astro - 승인 전 안전하게 관리하는 방식
const { slot } = Astro.props;
const ADSENSE_APPROVED = import.meta.env.ADSENSE_APPROVED === 'true';
---

{ADSENSE_APPROVED && (
  <ins class="adsbygoogle" data-ad-slot={slot} />
)}

이런 식으로 환경 변수 플래그로 껐다 켤 수 있게 짜두는 방법도 있다. 플레이스홀더를 통째로 걷어냈다 다시 짜는 것보다 훨씬 낫긴 한데, 이번엔 그냥 깔끔하게 제거하는 게 맞다고 봤음. 승인 구조가 어떻게 날지도 모르는 상태에서 컴포넌트 인터페이스가 바뀔 가능성이 있었기 때문.

결국 "승인 후에 다시 짠다"는 결정이고, 그게 현재 상태에선 더 솔직한 코드라고 생각한다. 플레이스홀더가 남아있으면 코드가 "된 척"을 하게 된다.

승인 나면 그때 다시 설계해서 붙인다. 끝.

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

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

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