광고 코드 누락 임시 매핑으로 노출 오류 해소

사내 광고 연동 관련 임시 매핑 작업을 SQL 한 파일로 처리했다.

왜 이 작업이 필요했나

광고 매체 연동 구조를 보면, 외부 DSP나 미디어 플랫폼과 연결할 때 내부 코드 체계와 외부 코드 체계가 맞지 않는 경우가 꽤 빈번하다. 이번 작업도 그 맥락이었다. job 6 unit이라는 특정 광고 단위에서 scriptCode와 frameCode가 money 측 값으로 매핑되어야 하는데, 정식 연동 작업이 완료되기 전까지 운영 중인 데이터가 빈 채로 돌아가고 있었다.

비어 있으면 단순히 데이터 공백으로 끝나는 게 아니라, 해당 코드를 참조해서 스크립트를 렌더링하거나 프레임을 구성하는 로직 전체가 기대와 다르게 동작한다. 결국 광고가 노출이 안 되거나, 잘못된 포맷으로 나가는 문제로 이어진다. 이런 상황에서 "정식 구현 전까지 임시 매핑"이라는 판단은 오히려 리스크 관리 측면에서 맞는 선택이었다.

작업 내용

파일은 deploy/admin-db-mobon-temp-from-money.sql 하나다. 파일 네이밍에서 의도가 이미 드러난다. mobon-temp라는 prefix, from-money라는 suffix — 이 값들이 money 쪽에서 가져온 임시 데이터임을 명확히 선언하고 있다.

이런 임시 매핑 SQL은 보통 아래 패턴으로 구성된다.

-- job 6 unit 대상 scriptCode / frameCode 임시 매핑
UPDATE ad_unit
SET    script_code = '[money측 scriptCode]',
       frame_code  = '[money측 frameCode]'
WHERE  job_id = 6
  AND  unit_type = '[대상 unit]';

단순 UPDATE지만, 어느 조건으로 어떤 값을 밀어 넣느냐가 핵심이다. 조건이 느슨하면 엉뚱한 unit에 값이 덮어써지고, 값이 틀리면 광고 렌더링이 깨진다. 파일 이름에 temp가 붙어 있어도 실 운영 DB에 올라가는 스크립트이기 때문에 검토 기준은 동일하게 가져갔다.

임시 매핑이라는 선택의 트레이드오프

"임시"라는 딱지가 붙은 작업은 팀 전체가 조심해야 한다. 임시 매핑이 정식 연동보다 훨씬 오래 살아남는 사례를 한두 번 본 게 아니다.

그래서 이런 작업을 승인할 때는 몇 가지를 확인한다.

• 만료 조건이 명확한가 — "정식 연동 완료 시 이 SQL은 어떻게 정리되는가"
• 사이드이펙트 범위가 한정적인가 — job 6 unit 외의 다른 unit에 영향을 주지 않는가
• 파일명/커밋 메시지에 임시임을 충분히 표기했는가 — 나중에 코드베이스를 보는 사람이 context를 잃지 않도록
• 리버트 플랜이 있는가 — 값이 잘못됐을 때 빠르게 롤백할 수 있는가

이번 작업은 파일명과 커밋 메시지 모두 temp와 from-money 출처를 명시했고, 대상 범위도 job 6 unit으로 좁게 잡았다. 구조 자체는 깔끔했다.

다만 팀 차원에서 이런 임시 SQL 파일들이 deploy 폴더에 누적될수록 추후 정리 비용이 올라간다. 정식 연동 티켓에 "이 temp SQL 제거"를 명시적으로 연결해 두는 습관이 필요하다고 다시 한번 느꼈다. 기술 부채는 코드가 아니라 이런 작은 누락에서 쌓인다.

끝.

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

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

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