광고 게이트 모달에 표준 레이아웃 적용

광고 게이트 모달에 표준 레이아웃을 입혀야 하는 작업이 들어왔다. 파일 두 개만 건드린 비교적 핀포인트 작업이었지만, 그 배경엔 생각보다 많은 맥락이 있었음.

왜 이 작업이 필요했나

AdGateModal.astro와 Base.astro — 파일만 봐도 영향 범위가 보인다. Base 레이아웃에 손을 댄다는 건 그 레이아웃을 상속받는 모든 페이지에 파급이 간다는 뜻이다. 그래서 이 작업은 단순히 "모달 하나 고친 것"이 아니라, 전체 레이아웃 체계 안에서 광고 게이트를 어떻게 위치시킬 것인지를 정리한 작업이었음.

광고 게이트(ad-gate)는 특정 콘텐츠에 진입하기 전 광고를 경유하게 만드는 장치다. 이 패턴은 수익 모델로서 많이 쓰이는데, 문제는 이런 모달이 서비스마다 제각각으로 구현되면 UX 일관성이 망가진다는 점이다. 어떤 페이지에선 모달이 전체 뷰포트를 덮고, 어떤 페이지에선 애매하게 반쯤만 뜨고. 사용자 입장에선 같은 서비스인데 동작이 달라 보이는 불신감이 생긴다.

이번 작업의 핵심 키워드는 "표준 적용" 이다. 새로 만든 게 아니라 기존에 있던 컴포넌트를 거버넌스(gov) 기준에 맞게 정렬한 작업. 이런 류의 작업이 생각보다 팀에서 우선순위가 낮게 취급받는 경우가 많은데, 나는 반대 입장이다. 표준이 없는 컴포넌트는 결국 나중에 누군가가 복붙해서 변형 버전을 양산하고, 그걸 다시 정리하는 비용이 훨씬 크다.

작업 내용: 두 파일의 역할

AdGateModal.astro 쪽에서는 컴포넌트 내부 구조를 표준 디자인 시스템의 모달 패턴에 맞게 정렬했을 가능성이 높다. Astro 컴포넌트 특성상 서버사이드에서 HTML 골격이 렌더되고, 인터랙션은 클라이언트 스크립트로 처리되는 구조라 — 모달의 열림/닫힘 상태 관리가 어느 레이어에 있느냐가 중요하다.

---
// AdGateModal.astro (표준 적용 후 구조 예시)
export interface Props {
  targetUrl: string;
  adUnit: string;
}
const { targetUrl, adUnit } = Astro.props;
---

<div id="ad-gate-modal" class="modal modal--overlay" role="dialog" aria-modal="true">
  <div class="modal__inner">
    <div class="modal__ad-slot" data-unit={adUnit}>
      <slot />
    </div>
    <a class="modal__cta" href={targetUrl} data-ad-gate-confirm>
      계속하기
    </a>
  </div>
</div>

<script>
  // 게이트 진입 시 모달 활성화
  document.addEventListener('ad-gate:open', () => {
    document.getElementById('ad-gate-modal')?.classList.add('is-active');
  });
</script>

Base.astro 쪽은 모달을 body 최상단 혹은 #app 루트 바깥에 배치하는 패턴으로 정리했을 것이다. 모달을 중첩된 컨테이너 안에 두면 z-index나 overflow 이슈로 꼭 사고가 난다. 이건 레이아웃 설계 초기에 잡아야 하는 문제인데, 표준을 늦게 적용할수록 이미 잘못 박혀 있는 모달들을 하나씩 뜯어내야 해서 손이 많이 간다.

거버넌스(gov) 태그를 붙인 이유

커밋 메시지에 (gov) 태그가 붙어 있다는 게 흥미롭다. 이건 단순 기능 추가가 아니라 거버넌스 정책에 의해 트리거된 작업임을 명시한 것이다. 팀에서 이런 태그 체계를 쓰는 이유는 명확하다.

• 나중에 히스토리 추적할 때 "이 변경이 왜 들어갔지?" 를 빠르게 판단하기 위함
• 기능 커밋과 구조 정렬 커밋을 구분해서 리뷰 맥락을 맞추기 위함
• 거버넌스 기반 변경은 되돌리거나 임의로 수정하면 안 된다는 신호

코드리뷰 할 때도 이 태그 하나로 리뷰어의 시각이 달라진다. "이 코드가 더 나은가?"가 아니라 "이 코드가 표준에 부합하는가?"로 질문이 바뀌는 것. 팀원들한테도 이 차이를 인식시키는 게 중요하다고 생각해서, 커밋 메시지 컨벤션에 이런 태그를 권장하고 있음.

Base 레이아웃을 건드리는 작업은 항상 조심스럽다. 영향을 받는 페이지가 많을수록 사이드이펙트가 어디서 터질지 예측하기 어렵기 때문이다. 이런 작업일수록 변경 범위를 최소화하고, PR에 스크린샷이나 before/after 비교를 꼭 첨부하게 유도한다. 파일 수는 적어도 리뷰 비용은 절대 적지 않다는 걸 팀 전체가 공유하고 있어야 한다.

끝.

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

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

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