모비온 광고 슬롯 누락을 재시도 로직으로 해결

모비온 광고 슬롯이 가끔 안 뜨는 현상을 추적해서 race condition 으로 원인을 확정하고, 6초 retry 로 잡은 작업.

배경: "가끔 안 뜬다"는 말이 제일 무섭다

재현이 일관되지 않은 버그는 팀 입장에서 처리 우선순위를 잡기가 애매하다. "가끔 안 뜬다"는 제보가 들어오면 항상 드는 생각이 두 가지다. 첫째, 얼마나 자주? 둘째, 어떤 조건에서? 이 두 가지가 명확하지 않으면 fix 를 올렸어도 "고쳐진 건지 모르겠다"는 상태로 며칠을 보내게 된다.

이번 모비온 슬롯(MobonSlot.astro) 건도 그랬다. 모비온 광고 스크립트가 DOM 에 마운트되는 타이밍과, HawkEyes 가 해당 슬롯을 감지하려는 타이밍이 충돌하는 상황이었다. 스크립트 로드 순서가 네트워크 상태나 브라우저 캐시 여부에 따라 달라지니 당연히 재현율이 들쑥날쑥했다.

race condition 의 구조

이 류의 문제는 클라이언트 사이드 광고 슬롯에서 꽤 전형적으로 발생한다. 구조를 간단히 정리하면:

"잘 될 때"는 스크립트 로드가 HawkEyes 초기화보다 먼저 끝나는 경우고, "깨질 때"는 그 반대다. 외부 스크립트 로드 완료를 보장할 수 없는 이상, 초기화 시점만 믿고 있으면 이 타이밍 차이는 언제든 발생할 수 있다.

해결: 6초 retry 로 보완

완벽한 해결은 모비온 스크립트 로드 완료 이벤트를 직접 구독해서 그 시점에 HawkEyes 를 실행하는 방식이다. 근데 외부 벤더 스크립트가 항상 깔끔한 콜백이나 이벤트를 제공하지는 않는다. 모비온도 마찬가지였다.

그래서 선택한 패턴이 지연 retry다. 6초라는 숫자는 임의의 숫자가 아니라, 일반적인 광고 스크립트 로드 타임아웃 범위 안에서 "충분히 기다렸다"고 볼 수 있는 경계값을 경험적으로 잡은 것이다.

// MobonSlot.astro 내 개념적 패턴
function initWithRetry(fn, delay = 6000) {
  fn(); // 일단 즉시 시도
  setTimeout(() => {
    if (!isSlotRendered()) {
      fn(); // 6초 후 재시도
    }
  }, delay);
}

즉시 시도 → 슬롯 렌더 확인 → 실패 시 6초 후 재시도. 간단하지만 이 패턴이 실제로 "가끔 안 뜨는" 문제를 커버하는 데는 효과적이다. retry 는 슬롯이 이미 정상 렌더된 경우에는 중복 실행을 방지하는 조건이 필수라 isSlotRendered() 류의 체크가 항상 따라붙어야 한다.

회고

MobonSlot.astro 한 파일 수정이지만 이 작업을 처리하면서 짚고 싶었던 포인트가 있다.

• 외부 스크립트 의존성은 항상 불확실하다. 벤더 SDK, 광고 스크립트, 분석 태그 전부 마찬가지. 로드 완료를 "당연히 됐겠지"로 가정하면 이런 race 가 계속 생긴다.
• retry 의 부작용을 항상 고려해야 한다. 중복 광고 삽입, 중복 이벤트 발화 같은 사이드이펙트를 막는 가드가 없으면 fix 가 새 버그를 만든다.
• 재현 불가 버그일수록 fix 검증 기준을 먼저 잡아야 한다. 이번에는 "일정 기간 동안 슬롯 누락 제보 없음"을 검증 기준으로 삼았다. 코드 변경 자체보다 이 기준을 팀 내에서 공유하는 게 더 중요했다.

광고 슬롯 하나 fix 인데 생각보다 신경 쓸 게 많다. 근데 이런 작은 race 하나가 수익 관련 지표에 조용히 영향을 주고 있었다는 걸 생각하면 우선순위를 올리길 잘했다.

끝.

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

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

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