광고 슬롯 데이터 접근을 전체 카테고리와 같은 패턴으로 통일

MobonSlot 컴포넌트를 admin_db 패턴으로 전환한 작업이다. gov, money 카테고리에서 먼저 정착된 패턴을 ads 쪽에도 맞춰 통일시킨 것.

왜 이 타이밍에

사실 이 작업 자체는 기능 변경이 아니다. 동작은 똑같은데 데이터 접근 방식을 다른 카테고리와 맞추는 일종의 정합성 작업이다. gov랑 money 쪽 작업을 먼저 진행하면서 admin_db 패턴이 꽤 안정적이라는 걸 확인했고, ads 쪽만 예전 방식으로 남아있는 게 계속 눈에 걸렸다.

이런 류의 작업을 팀 내에서 어떻게 우선순위 매기냐는 항상 고민이다. "지금 당장 터지는 버그도 아니고, 기능이 빠지는 것도 아닌데 굳이?"라는 시각도 있다. 근데 패턴이 분기된 상태로 오래 두면 나중에 더 큰 비용이 생긴다. 특히 새로운 팀원이 투입됐을 때 "왜 여기만 다르게 되어 있어요?"라는 질문이 반드시 나온다. 그 질문에 답하는 데 쓰는 에너지가 쌓이면 결국 팀 전체 속도에 영향을 준다.

변경된 파일들 역할

package.json까지 변경됐다는 게 단순 리팩터링은 아니라는 걸 보여준다. 의존성 레벨의 변화가 있었다는 뜻이고, 그만큼 이번 전환이 단순 코드 정리 이상의 작업이었음을 알 수 있다.

패턴 통일이 가져오는 실질적인 효과

gov, money, ads 세 카테고리가 같은 admin_db 패턴을 쓰게 되면서 생기는 이점을 정리하면 이렇다.

• 코드 리뷰 부담 감소: 패턴이 다르면 리뷰어가 컨텍스트를 두 배로 파악해야 한다. 통일되면 "이게 기존 패턴대로 잘 쓰인 건지"만 보면 된다.
• 버그 재현 범위 좁히기: 나중에 데이터 접근 관련 이슈가 생겼을 때, 모든 카테고리가 같은 경로를 타면 원인 추적이 훨씬 빠르다.
• 신규 카테고리 추가 시 기준점 명확: 다음에 카테고리가 하나 더 생겨도 "기존 패턴 그대로 따르면 됩니다"라는 말 한 마디로 온보딩이 끝난다.

// 기존 방식 (ads만 다르게 갔던 흔적)
const data = await legacyFetch(slotId);

// admin_db 패턴 전환 후 (gov/money와 동일)
const data = await adminDb.getSlot(slotId);

실제 코드 그대로는 아니지만, 이런 수준의 분기가 남아있으면 legacyFetch 쪽 유지보수가 따로 필요해진다. 결국 두 경로를 모두 챙겨야 하는 상황이 생기는데, 이걸 방치하는 것 자체가 기술 부채다.

돌아보면

이 커밋 하나로 뭔가 극적인 변화가 생기는 건 아니다. 근데 팀 리딩을 하면서 느끼는 건, 이런 "조용한 정합성 작업"을 꾸준히 챙기는 게 시스템 건강의 척도라는 점이다. 화려한 신기능보다 기존 코드베이스를 일관성 있게 유지하는 PR이 장기적으로 팀 생산성을 더 많이 올려준다. gov/money에서 먼저 검증하고, 안정적이다 싶으면 나머지에도 적용하는 방식은 앞으로도 유효한 접근이라고 생각한다.

끝.