사이트 전역 AdSense 광고 로더 추가

Base.astro 레이아웃 파일의 head 영역에 AdSense 로더 스니펫을 삽입했다. 이제 사이트의 모든 페이지에서 광고가 로드되고 노출될 준비가 됐다는 뜻이다.

왜 레이아웃 파일에서 시작했나

처음엔 당연해 보이지만, 생각할 게 좀 있었다. Astro 프로젝트에서 광고 스크립트를 어디 집어넣을지는 선택의 문제다.

• 페이지마다 하나씩 추가: 각 페이지 파일에 직접 스니펫을 붙이기
• 레이아웃 파일: Base.astro처럼 모든 페이지의 부모 역할하는 파일에 한 번만 추가
• 컴포넌트화: 별도의 AdSense 컴포넌트를 만들고 필요한 곳에서 import

우린 레이아웃 파일을 택했다. 이유는 간단한데, 한 번의 변경으로 전역 적용이 가능하고, 나중에 광고 로직을 수정해야 할 때도 한 곳에서만 건드리면 되기 때문이다. 페이지 수가 10개든 100개든 상관없다. 이건 유지보수 관점에서 굉장히 중요한데, 나중에 "모든 페이지에 이 스니펫을 적용해야 해" 하는 순간 후회하는 경우가 많다.

다만 이 방식의 트레이드오프는, 필요 없는 페이지(예: 관리자 패널)에서도 광고 스크립트가 로드된다는 점이다. 훗날 "이 페이지는 제외하고 싶은데" 하는 요청이 나오면 조건부 렌더링을 추가해야 한다.

head 영역에 넣는 게 맞나

AdSense 로더는 보통 head에 들어간다. 스크립트 로딩 순서가 중요한데, head에 있으면:
- 페이지가 렌더링되기 전에 광고 스크립트가 먼저 로드된다
- 광고가 더 빨리 준비돼서 콘텐츠와 함께 표시될 수 있다
- 하지만 페이지 로딩이 약간 지연될 수도 있다

반대로 body 끝에 넣으면 페이지는 빨리 보이지만 광고가 나중에 로드된다. 사용자는 공백을 봤다가 광고가 갑자기 나타나는 경험을 한다. AdSense 공식 가이드도 head 삽입을 권장하니까 우린 그대로 따랐다.

개발/프로덕션 계정을 왜 분리했나

commit 메시지에 "[email protected] 별도계정"이라는 주석이 있다. 이건 실제로 중요한 결정이었다.

AdSense 로더에 들어가는 publisher ID(ca-pub-...)를 하나만 쓸 수도 있지만, 개발 환경에서는 별도 계정을 사용한다. 왜냐하면:

1. 테스트 클릭 추적: 개발할 때 광고를 의도적으로 클릭해서 테스트하는데, 프로덕션 계정에 적립되면 안 된다. AdSense는 무효 클릭으로 간주할 수 있다.
2. 계정 위험: 무효 클릭이 많으면 AdSense 계정이 정지될 수 있다. 프로덕션 수익을 위험에 빠뜨릴 수 없다.
3. 분석 데이터: 개발/테스트 트래픽과 실제 사용자 트래픽을 분리해야 통계가 정확하다.

Astro는 환경 변수를 쉽게 다룰 수 있으니, 나중에 build time이나 runtime에 어떤 publisher ID를 쓸지 동적으로 결정할 수 있다. 예를 들어:

---
const publisherId = import.meta.env.DEV 
  ? 'ca-pub-dev-account'
  : 'ca-pub-prod-account'
---

<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client={publisherId}">
</script>

이렇게 하면 로컬에선 dev 계정, 배포할 땐 prod 계정이 자동으로 적용된다.

너무 일찍 성능을 걱정하지는 말자

광고 스크립트를 추가할 때 팀에서 나온 우려 중 하나는 "이게 페이지 로딩을 느리게 하지 않을까"였다. 맞는 지적이다. AdSense 스크립트는 외부에서 로드되고 약간의 JavaScript 실행이 필요하다.

하지만 지금은 너무 일찍 최적화를 생각할 시점이 아니다. 먼저 광고를 켜고, 실제 성능 데이터를 본 다음에 "Largest Contentful Paint가 300ms 늘었다"라는 문제가 생기면 그때 대응하자. 예를 들어:

• 광고 스크립트를 defer 로 로드
• lazy loading 활용
• Web Worker에서 비동기 로드

등등 여러 방법이 있다.

회고

결국 이건 단순한 "광고 스니펫 추가" 작업이 아니었다.

어디에 넣을지 (레이아웃), 어떻게 로드할지 (head vs body), 어느 환경일 땐 어떻게 할지 (dev/prod 분리) 같은 여러 선택이 깔려 있었다. 각각은 나중의 유지보수성, 안정성, 성능에 영향을 준다.

팀과 함께 일할 때는 이런 "작은 결정"들이 쌓여서 결국 시스템의 모양을 만든다는 걸 자주 느낀다. 누군가는 "그냥 스니펫만 추가하면 되지 않나" 할 수 있지만, 실제로는 환경 분리, 성능 고려, 확장성 같은 질문들이 있다. 그리고 좋은 결정은 지금은 작아 보이지만 6개월 뒤 누군가가 코드를 건드릴 때 "아, 이렇게 구조를 잡아놨구나"하며 감사하게 만든다.

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

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

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