블로그에 MOBON 광고 슬롯 연동

광고 슬롯 컴포넌트에 새 ad provider 분기를 얹고, 실제 포스트 레이아웃에 slotKey를 박아 넣었다.

왜 이 작업이 필요했나

블로그에 광고를 붙이는 방식은 생각보다 관리 포인트가 많다. 단순히 스크립트 한 줄 넣는 게 전부가 아니라 — 어느 페이지에, 어떤 공급사(provider)로, 어떤 슬롯 ID를 내보낼지가 모두 조합된다. 이번에 MOBON provider를 새로 연동하면서, 기존 AdSlot 컴포넌트가 단일 provider 기준으로만 동작하던 구조를 먼저 손봐야 했다.

솔직히 처음부터 provider 분기를 고려하고 설계했으면 좋았을 텐데, 초기엔 "일단 하나만 붙이자"는 의사결정이 있었다. 흔한 패턴이다. 문제는 두 번째 provider가 붙는 순간 그 기술 부채가 바로 청구된다는 것. 이번 커밋이 정확히 그 시점이었다.

작업 내용 요약

변경이 들어간 파일은 세 개다.

파일	역할	이번 변경 포인트
`AdSlot.astro`	광고 슬롯 렌더링 컴포넌트	MOBON provider 분기 로직 추가
`BaseHead.astro`	공통 `<head>` 태그 구성	MOBON 스크립트 로드 처리 추가로 추정
`BlogPost.astro`	블로그 포스트 레이아웃	`AdSlot` 호출 시 `mobonslot-` slotKey 주입

AdSlot.astro 쪽 변경이 핵심이다. provider 값에 따라 렌더링 분기를 태우는 구조로 바꿨고, 대략 이런 패턴이다.

---
const { provider = 'default', slotKey } = Astro.props;
---

{provider === 'mobon' && (
  <div class="ad-slot">
    <ins class="mobon-ad" data-slot={slotKey}></ins>
  </div>
)}

{provider === 'default' && (
  <div class="ad-slot">
    <!-- 기존 provider 렌더 -->
  </div>
)}

BlogPost.astro에서는 이 컴포넌트를 호출할 때 slotKey="mobonslot-xxxxx" 형태로 키를 직접 박았다. 레이아웃 레벨에서 고정하는 방식이라 포스트 개별 frontmatter를 건드리지 않아도 된다는 게 장점이다. 블로그 포스트 전체에 일괄 적용이 목적이었으니 이 판단은 맞았다고 본다.

BaseHead.astro는 공통 <head>를 담당하는 파일이라, 여기에 MOBON 관련 외부 스크립트를 로드하는 코드가 들어갔을 가능성이 높다. 광고 SDK 특성상 페이지 전체에서 초기화가 필요한 경우가 많기 때문에 <head> 레벨에서 처리하는 게 일반적이다. 다만 이렇게 하면 광고가 노출되지 않는 페이지에서도 스크립트가 로드된다는 트레이드오프가 있다.

회고: provider 분기를 어디에 두는 게 맞는가

이번 작업을 하면서 가장 많이 고민한 건 "provider 분기를 컴포넌트 내부에 둬야 하나, 아니면 호출처에서 다른 컴포넌트를 쓰게 해야 하나"였다.

두 가지 선택지를 비교하면 이렇다.

방식	장점	단점
`AdSlot` 내부에서 provider 분기	호출처 변경 최소화, 일관된 인터페이스	컴포넌트가 뚱뚱해짐, provider 늘수록 if-else 증가
`MobonAdSlot`, `DefaultAdSlot` 분리	단일 책임, 각각 독립 테스트 가능	레이아웃마다 import 분기 필요, 호출처 수정 범위 커짐

지금 규모에서는 전자를 택했다. provider가 두 개 정도인 상황에서 컴포넌트를 쪼개는 건 오버엔지니어링이라는 판단이었다. 만약 provider가 세 개 이상으로 늘어나거나, 각 provider별로 렌더 로직 차이가 커진다면 그때 분리를 고려할 것이다.

slotKey를 BlogPost.astro에 하드코딩한 것도 비슷한 맥락이다. 포스트 단위로 slotKey를 다르게 쓸 필요가 없는 한, frontmatter에 필드를 추가하고 모든 마크다운 파일을 수정하는 건 비용 대비 효과가 없다. "지금 필요한 것"에 맞게 결정한다.

광고 연동은 항상 "넣기는 쉬운데 정리하기는 어려운" 작업이다. provider 계약이 끝나거나 교체될 때 코드 어디에 어떤 흔적이 남아 있는지 파악하기 힘든 경우가 많다. 이번처럼 provider 이름을 prop으로 명시하고, slotKey 네이밍에도 mobonslot- prefix를 붙여두면 나중에 grep 한 번으로 관련 코드를 다 찾을 수 있다. 작은 습관인데 몇 달 후에 꽤 도움이 된다.

다음 작업은 BaseHead에서 스크립트 로드를 조건부로 처리하는 것. 광고가 없는 페이지에까지 SDK를 내리는 건 손봐야 할 부분이다.

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

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