광고 슬롯 JSON과 DB 사이의 드리프트를 수동 동기화로 해소

ad-units.json 파일 하나를 admin_db 기준으로 다시 맞췄다. 파일 stat 이 미지정이라 라인 수는 모르지만, 이런 동기화 작업은 숫자보다 "왜 이게 필요했는가"가 핵심이다.

배경: JSON 파일과 DB 사이에서 생기는 슬롯 불일치

광고 슬롯 목록을 관리하는 방식은 팀마다 다르다. 어떤 팀은 DB 한 곳에만 두고, 어떤 팀은 빌드 타임에 정적 JSON 으로 박아 쓴다. 우리 쪽은 후자 방식에 가까운데, ad-units.json 이 프론트나 서버 코드 내에서 슬롯 ID 와 메타 정보를 참조하는 정적 소스 역할을 한다.

문제는 admin_db 에서 슬롯이 추가/변경될 때 이 JSON 이 자동으로 따라가지 않는다는 점이다. 누군가 운영 화면에서 새 광고 유닛을 등록하거나 슬롯 속성을 수정하면, 코드 베이스 안의 JSON 은 이미 낡은 스냅샷이 된다. 이게 쌓이면 슬롯 ID 매핑 오류, 잘못된 fallback 노출, 혹은 신규 슬롯이 코드에서 아예 인식이 안 되는 상황으로 이어진다.

이번 커밋은 그 드리프트를 해소한 것이다. "모비온 광고 슬롯 최신 반영" 이라는 메시지가 나왔다는 건, admin_db 에서 변경이 있었고 그걸 소스 코드 쪽으로 수동으로 풀어준 작업이라는 뜻이다.

이런 동기화 작업이 왜 커밋으로 남아야 하는가

chore 로 분류하긴 했지만, 이 작업을 대충 여기고 PR 없이 직접 머지하거나 로컬에서 슬쩍 올리면 나중에 꽤 골치 아파진다.

몇 가지 이유를 짚으면:

• 추적 가능성: 어떤 슬롯이 언제 추가됐는지 git log 로 역추적할 수 있어야 광고 이슈 발생 시 디버깅이 빠르다
• 리뷰 포인트: 슬롯 메타 정보(슬롯 ID, 사이즈, 위치 등)가 올바르게 들어왔는지 눈으로 확인하는 과정이 PR 리뷰다
• 배포 단위 보장: DB 변경과 코드 변경이 같은 배포 사이클에 묶여야 슬롯 불일치 윈도우가 최소화된다

단순 데이터 파일 하나라도 이 흐름을 지키는 게 팀 전체 신뢰도를 유지하는 방법이다. "데이터 파일이니까 그냥 올려도 되지 않나"는 생각이 나중에 "이게 언제 바뀐 거지?" 를 만든다.

수동 동기화의 한계와 앞으로의 방향

솔직히 이 작업은 이상적으로는 수동이 아니어야 한다. admin_db 에서 슬롯이 변경될 때 JSON 이 자동으로 생성/갱신되거나, 아니면 아예 런타임에 DB 를 직접 읽는 구조가 맞다.

현재 방식이 틀렸다기보다는, 팀 규모와 운영 빈도에 맞게 골라 쓰는 거다. 지금은 슬롯 변경 빈도가 그렇게 잦지 않다면 수동 동기화 + 커밋 추적으로도 충분히 관리된다. 다만 광고 유닛이 자주 바뀌는 시기가 오면 CI 자동화로 전환을 검토해야 한다.

이번 작업 자체는 작지만, 이런 동기화 타이밍을 놓치지 않고 커밋으로 남기는 습관이 결국 팀 코드베이스의 신뢰도를 유지하는 거라고 생각한다.

끝.

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

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

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