Mobon 광고 슬롯을 DB로 제어 가능하게 패턴 통일

광고 슬롯 컴포넌트에 admin_db 패턴을 붙이는 작업을 마무리했다. ssul/money/gov 세 레이아웃에서 이미 검증된 패턴이었고, MobonSlot도 동일하게 맞추는 게 맞다고 판단해서 진행했음.

왜 이 타이밍에 했냐

이미 다른 레이아웃들(ssul, money, gov)엔 admin_db 패턴이 들어가 있는 상황이었다. MobonSlot만 빠져 있으니 운영 중에 슬롯 설정을 DB로 제어하고 싶어도 이 컴포넌트만 예외가 되는 구조였음. 사실 "나중에 하면 되지" 싶을 수 있는 작업인데, 광고 슬롯 설정이 DB 기반으로 움직이는 구조에서 컴포넌트 하나가 계속 하드코딩 방식으로 남아 있으면 나중에 운영 측에서 컨트롤할 수 없는 사각지대가 생긴다. 그게 쌓이면 결국 핫픽스 배포가 반복되고, 팀 전체 피로도로 돌아온다.

패턴 통일이라는 작업은 보기엔 단순 정렬처럼 보이지만, 실제로는 "이 컴포넌트도 운영 가능한 범위 안으로 들어온다" 는 의미다.

변경된 파일들이 하는 일

db.ts에 손이 간 게 핵심이다. 컴포넌트 레벨에서 DB 설정을 직접 읽도록 연결하는 부분인데, 이미 ssul/money/gov에서 같은 방식으로 구현이 되어 있어서 패턴 복붙 수준이 아니라 구조를 그대로 따라가는 형태로 진행했음.

// db.ts - admin_db 패턴 예시 (기존 ssul/money/gov 동일 구조)
export async function getMobonSlotConfig(slotId: string) {
  // admin_db에서 슬롯 활성화 여부 및 옵션 조회
  const config = await db.query(
    `SELECT enabled, options FROM mobon_slot_config WHERE slot_id = $1`,
    [slotId]
  );
  return config.rows[0] ?? null;
}

---
// MobonSlot.astro
import { getMobonSlotConfig } from '../lib/db';

const { slotId } = Astro.props;
const config = await getMobonSlotConfig(slotId);

if (!config?.enabled) return;
---
<!-- 슬롯 렌더링 -->

이런 구조가 되면 운영자가 배포 없이 DB에서 슬롯 on/off를 제어할 수 있고, 옵션 변경도 마찬가지다. 코드 변경 → PR → 배포 사이클 없이 운영이 가능해진다는 게 admin_db 패턴의 핵심 이점이다.

팀 관점 회고

admin_db 패턴이 일부 레이아웃에만 적용된 채로 시간이 흘러가면, 새로 합류한 팀원 입장에서는 "어디는 되고 어디는 안 되는데, 왜 이렇게 됐지?" 라는 질문을 하게 된다. 코드리뷰에서도 이런 불일치가 나타나면 맥락 설명에 시간이 소모됨.

일관성 없는 패턴이 쌓이면 생기는 문제들:

• 신규 컴포넌트 작성 시 어떤 패턴을 따라야 하는지 기준이 흔들림
• 운영자가 어떤 슬롯은 DB로, 어떤 슬롯은 배포로 바꿔야 하는지 혼선
• 버그가 생겼을 때 "이 컴포넌트는 DB 읽는 구조야 아니야?" 를 먼저 확인하는 시간 낭비

결국 이번 작업은 한 컴포넌트에 기능 추가를 한 게 아니라, 팀이 암묵적으로 합의한 패턴을 뒤늦게 하나 완성시킨 것에 가깝다. 작은 작업처럼 보여도 이런 정렬 작업이 쌓여야 나중에 큰 리팩토링 없이 유지보수가 돌아간다.

다음엔 신규 슬롯 컴포넌트가 추가될 때부터 admin_db 패턴을 기본으로 붙이는 걸 컨벤션으로 못 박아 두는 게 맞겠다 싶음. 끝.

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

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

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