히어로 영역에 970x250 광고 슬롯 추가와 두 도메인 적용

base.html 한 파일에 광고 슬롯을 새로 박아 넣는 작업 — 단순해 보이지만 결정까지 꽤 많은 맥락이 붙어 있었다.

배경: 왜 hero inline 위치였나

광고 유닛을 페이지에 추가할 때 가장 먼저 논의되는 건 "어디에 넣을 것인가"다. 970x250 사이즈는 빌보드 혹은 슈퍼 리더보드라고 불리는 포맷으로, 일반적인 배너(728x90)보다 세로 높이가 훨씬 커서 시선을 확실히 잡는다. 그만큼 위치 선정이 잘못되면 UX 타격이 크다.

이번에 선택한 건 hero inline — 즉 페이지 상단 히어로 영역 안쪽, 콘텐츠 흐름에 자연스럽게 녹아드는 위치다. 상단 고정(sticky) 방식이 아니라 스크롤과 함께 흘러가는 인라인 삽입이기 때문에, 독자가 콘텐츠를 읽다가 자연스럽게 마주치는 구조다. 뷰어빌리티(viewability) 지표가 상대적으로 잘 나오는 위치이기도 하다.

두 도메인(blog.slecs.net, slecs.net)의 base 템플릿에 동시에 적용한 것도 포인트다. 별도 템플릿을 쓰는 두 서비스가 같은 베이스를 공유하거나, 베이스 파일 하나에서 도메인 분기를 타는 구조일 텐데 — 이 경우 한 파일 수정으로 두 도메인에 광고가 뜨는 만큼, QA 체크리스트를 두 도메인 기준으로 별도로 돌려야 한다는 걸 팀에 명시적으로 공유했다.

작업 내용: 모비온 유닛 + 두 가지 HawkEyes 클래스

<!-- 970x250 hero inline — 모비온 -->
<div class="HawkEyesMaker">
  <!-- 광고 스크립트 삽입 위치 -->
</div>

<div class="HawkEyes">
  <!-- new HawkEyes 인스턴스 -->
</div>

커밋 메시지에 HawkEyesMaker와 new HawkEyes 두 가지가 함께 언급된 게 눈에 띈다. 광고 SDK나 래퍼 라이브러리를 쓸 때 흔히 보이는 패턴인데, 보통 팩토리(maker) 역할의 컨테이너와 실제 슬롯 인스턴스를 분리해서 관리한다. 하나는 설정을 물고 있는 래퍼, 다른 하나는 실제 렌더링 타깃이라는 느낌이다.

이런 구조가 생기는 이유는 광고 SDK가 DOM이 준비된 시점에 슬롯을 탐색해서 렌더링하기 때문이다. 초기화 순서가 틀리거나, 컨테이너 클래스명이 맞지 않으면 광고가 아예 뜨지 않는다. 스크립트 로드 타이밍 문제로 슬롯이 비어 있는 채로 공간만 차지하는 경우도 자주 있어서, 이런 작업 후에는 네트워크 탭에서 광고 요청이 실제로 발생하는지 확인하는 게 기본 루틴이다.

특히 970x250 같은 대형 유닛은 광고가 로드되기 전과 후의 레이아웃 변화(CLS) 가 문제가 되는 경우가 많다. 컨테이너에 미리 min-height를 잡아두지 않으면 광고가 뜨는 순간 콘텐츠가 확 밀리면서 사용자 경험이 나빠진다. 이 부분은 CSS 쪽에도 손이 가야 하는 작업이라, 템플릿 수정만으로 끝나지 않는 경우가 많다.

회고

base.html 하나 건드리는 커밋이지만, 영향 범위는 해당 도메인의 모든 페이지다. 광고 관련 작업은 특히 이런 특성 때문에 조심스럽다 — 잘못 넣으면 전체 페이지 레이아웃이 망가지고, SDK 에러 하나가 JavaScript 실행 자체를 막기도 한다.

그래서 이런 작업은 내가 직접 머지하기 전에 반드시 스테이징에서 두 도메인 모두 육안으로 확인하는 루틴을 밟는다. 자동화 테스트가 잡기 어려운 영역이고, 광고 SDK는 외부 의존성이라 항상 예외 상황이 튀어나온다.

팀 입장에서도 광고 슬롯 추가는 단순 feature가 아니라 수익 지표와 직결되는 작업이다. 슬롯이 제대로 뜨는지, 뷰어빌리티가 기대치에 맞는지는 배포 후 며칠간 모니터링이 필요하다. 커밋 하나로 끝나는 작업이 아니라는 걸 항상 염두에 두는 편이다.

끝.

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

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

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