MOBON 광고 슬롯 위치 체계화

MOBON 광고 슬롯 패턴을 새로 정의하고, 레이아웃/페이지 단에서 i-cover, m-cover, content-top, content-bottom-mob 위치를 연결하는 작업을 했다.

왜 이 시점에 MOBON 슬롯 패턴을 새로 팠나

광고 슬롯 구조를 정리하다 보면 늘 비슷한 딜레마가 생긴다. 슬롯 위치를 하드코딩으로 박아두면 빠르긴 한데, 나중에 매체가 추가되거나 슬롯 위치가 변경될 때마다 코드 여러 곳을 손대야 한다. 반대로 지나치게 추상화하면 운영자가 DB에서 슬롯을 관리할 때 어디가 어딘지 파악하기 어렵다.

이번 작업은 그 중간 지점을 찾는 게 목표였다. MOBON이라는 매체 단위로 슬롯 패턴을 명시적으로 정의하고, i-cover(이미지형 커버) / m-cover(모바일 커버) / content-top / content-bottom-mob 이렇게 네 가지 위치 키를 체계화하는 것. 변경 파일이 build-ads.js, SQL 마이그레이션, Layout.astro, salary.astro 네 곳에 걸쳐 있다는 게 이 작업의 성격을 잘 보여준다 — 빌드 파이프라인부터 DB 스키마, 레이아웃, 개별 페이지까지 수직으로 관통하는 변경이었음.

파일별로 뭘 건드렸나

build-ads.js에서 패턴을 정의하면, SQL로 DB에 슬롯을 등록하고, 레이아웃과 페이지가 그 슬롯 키를 참조하는 흐름이다. 빌드 레벨의 패턴 정의가 운영 데이터와 코드 두 곳 모두에 반영되어야 하는 구조라, 어느 한 곳만 바꾸면 불일치가 생긴다. 이 부분이 팀원들한테 항상 헷갈림의 원인이 돼서, 슬롯 추가할 때 반드시 이 네 파일을 함께 건드려야 한다는 걸 리뷰 코멘트에 명시해뒀다.

i-cover / m-cover vs content-top / content-bottom-mob 분리 이유

슬롯 위치를 두 그룹으로 나눈 데는 이유가 있다.

• 커버 계열 (i-cover, m-cover): 레이아웃 레벨에서 전역으로 제어해야 하는 위치. 페이지마다 다른 컴포넌트가 렌더링되더라도 커버 광고는 공통 레이아웃에서 한 번에 처리하는 게 맞다. Layout.astro에 박아둔 이유.
• 콘텐츠 계열 (content-top, content-bottom-mob): 페이지마다 콘텐츠 구조가 다르기 때문에 개별 페이지(salary.astro)에서 직접 제어. 모바일 한정(-mob suffix)인 슬롯은 CSS 미디어쿼리가 아니라 슬롯 키 자체에서 구분해줘야 운영 DB에서도 직관적으로 필터링이 된다.

이걸 하나로 합치자는 의견도 있었는데, 레이아웃과 페이지 경계를 지키는 게 나중에 슬롯 위치를 수정할 때 영향 범위를 예측하기 훨씬 쉽다는 판단으로 분리를 유지했다.

빌드 스크립트에서 슬롯 패턴을 정의하는 방식

// build-ads/build-ads.js (패턴 예시)
const MOBON_SLOT_PATTERNS = {
  'i-cover':          { media: 'all',     position: 'cover' },
  'm-cover':          { media: 'mobile',  position: 'cover' },
  'content-top':      { media: 'all',     position: 'content-top' },
  'content-bottom-mob': { media: 'mobile', position: 'content-bottom' },
};

패턴 객체를 한 곳에서 선언해두면 빌드 시점에 슬롯 키 유효성 검사를 걸 수 있고, 오타로 인한 슬롯 미노출 버그를 사전에 잡을 수 있다. 실제로 이전에 슬롯 키 오타 때문에 광고가 조용히 안 나가는 이슈가 있었는데 — 에러도 없고 콘솔도 조용하니 발견이 늦었다. 그래서 빌드 레벨에서 허용 키 목록을 관리하는 게 팀 입장에서 훨씬 안전하다.

SQL 마이그레이션 파일 이름에 v3가 붙은 이유

admin-db-add-slots-v3-mobon.sql에서 v3는 슬롯 스키마가 세 번째 버전임을 의미한다. 마이그레이션 파일에 버전을 명시하는 게 처음엔 오버엔지니어링처럼 보이지만, 운영 배포 시 "이 SQL이 이미 적용됐나?" 를 체크할 때 파일명만으로 구분할 수 있어서 실수를 줄여준다. 특히 여러 환경(개발 / 스테이징 / 운영)을 오가는 배포에서 마이그레이션 히스토리가 파일명에 녹아 있으면 운영자가 이력 추적할 때도 편하다.

슬롯 DB 등록이 누락되면 빌드는 성공해도 실제 광고가 안 나간다. 이 SQL이 배포 순서에서 앞서야 한다는 점을 팀에 공유했고, 배포 런북에도 명시해뒀다.

salary.astro에 content-top과 content-bottom-mob을 붙인 건, 해당 페이지가 콘텐츠 볼륨이 있고 모바일 체류 시간이 긴 구조라 모바일 하단 슬롯 효율이 기대된다는 판단에서였다. 슬롯을 어디에 달지는 결국 레이아웃 감각 + 운영 데이터의 조합인데, 이번엔 먼저 붙여보고 지표를 보자는 방향으로 결론냈다.

끝.

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

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

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