개발 slecs

광고 파트너 스크립트 로딩 경쟁 조건을 재시도 로직으로 해결

목차

외부 파트너 스크립트 로딩 타이밍 버그를 잡았다.


배경: 써드파티 스크립트와 race condition의 고전적 함정

광고 빌드 쪽 작업을 하다 보면 결국 한 번은 만나게 되는 문제가 있다. 외부에서 비동기로 로드되는 파트너 스크립트가, 우리 코드가 해당 전역 객체를 참조하는 시점보다 늦게 도착하는 상황이다.

이번엔 g.js 안에서 PartnersCoupang 객체를 참조하는 코드가 문제였다. 해당 파트너 스크립트가 완전히 초기화되기 전에 우리 코드가 먼저 실행되어버리면서 undefined 참조 에러 혹은 그냥 조용히 아무것도 안 되는 상황이 간헐적으로 발생했다. 전형적인 race condition.

간헐적이라는 게 핵심이다. 로컬에서 재현이 잘 안 되고, 특정 네트워크 환경이나 CDN 응답 속도에 따라 달라지기 때문에 처음엔 "이게 진짜 버그인가?" 싶어서 시간을 잡아먹는 경우가 많다.


어떻게 고쳤나: 5초 retry + console.warn

수정 방향은 심플하게 잡았다. PartnersCoupang이 아직 없을 경우 5초 후 재시도하고, 그 시점에 console.warn으로 시그널을 남기는 것.

// build-ads/build-ads.js (패턴 예시)
function initPartnersCoupang() {
  if (typeof PartnersCoupang === 'undefined') {
    console.warn('[build-ads] PartnersCoupang not loaded yet, retrying in 5s...');
    setTimeout(initPartnersCoupang, 5000);
    return;
  }
  // 실제 초기화 로직
}

initPartnersCoupang();

5초라는 숫자는 임의적으로 보일 수 있지만, 파트너 스크립트가 CDN 레이턴시 포함해서 통상 2-3초 안에 도착하는 걸 감안했을 때 충분히 여유 있는 수치다. 1초면 너무 촉박하고, 10초면 사용자 경험상 너무 늦다.

console.warn을 붙인 이유가 중요하다. 이런 retry 로직은 조용히 동작하면 나중에 반드시 문제가 된다. 모니터링이나 QA 단계에서 "왜 이 광고가 가끔 늦게 뜨는 거야?" 라는 질문이 나왔을 때, warn 로그가 있으면 즉시 원인 파악이 된다. 없으면 다시 처음부터 디버깅해야 한다. 팀 내에서도 이런 류의 defensive 코드에는 반드시 로그를 남기자는 컨벤션을 가져가고 있다.


회고: 이 류의 버그에서 놓치기 쉬운 것들

항목 간과하기 쉬운 이유 이번에 챙긴 것
재현 조건 로컬 환경에선 캐시/속도로 재현 안 됨 네트워크 쓰로틀링으로 검증
실패 모드 에러 없이 그냥 광고 미노출로 끝남 console.warn으로 흔적 남김
retry 횟수 제한 무한 retry 가능성 열어둠 현재는 1회 retry (추후 max count 검토)
변경 파일 범위 build-ads.js 단일 파일 수정 영향 범위 최소화

한 가지 더 얘기하자면 — build-ads/build-ads.js 파일은 광고 빌드 전반에 관여하는 파일이라 작은 수정이라도 신중하게 접근해야 한다. 이번 변경은 retry와 warn 추가라 사이드이펙트가 제한적이지만, 코드리뷰 때도 "retry 중에 다른 로직이 중복 실행될 가능성은 없나?" 를 같이 짚었다.

써드파티 스크립트 의존성이 있는 광고/트래킹 코드는 항상 이런 방어 로직을 처음부터 깔고 가는 게 맞다. 버그가 터진 다음에 넣는 게 아니라. 이번 건은 사후 처리였지만, 앞으로 새 파트너 스크립트 연동 시에는 초기 설계 단계에서 로드 타이밍 시나리오를 스펙에 포함시키기로 팀과 얘기했다.

끝.


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

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

댓글 0

첫 댓글 달아줘.