새로운 콜라보 시리즈 12종을 데이터베이스에 한 번에 추가
목차
블라인드박스 플랫폼에서 새로운 콜라보레이션 시리즈(CRYBABY, Labubu 등)를 12개 아이템으로 확장하는 데이터를 SQL 시딩으로 배포했다. 꽤 간단한 작업으로 보이지만, 이 과정에서 데이터 확장 시의 의사결정과 팀 협업 관점에서 배운 게 많다.
왜 SQL 시딩을 선택했나
우리 서비스에서 상품/시리즈를 추가할 때 마다 CLI 도구나 관리자 UI를 거칠 수도 있다. 하지만 한 번에 여러 아이템을 초기 데이터로 적재할 때는 SQL 시딩 파일(seed-blindbox-expansion-3.sql)을 쓰는 게 훨씬 깔끔했다. 특히 개발 환경에서 테스트할 때, 베타 환경을 세팅할 때, 혹은 스테이징에서 실제 상품 데이터를 먼저 확인해야 할 때 이 파일 하나로 일관성 있게 복제할 수 있다.
SQL 시딩 방식의 장점:
- 재현성: 스크립트 한 줄로 같은 상태를 언제든 만들 수 있다.
- 버전 관리: Git에 들어가니 어느 버전에 어떤 상품이 추가됐는지 추적 가능하다.
- 대량 작업: 12개 아이템이면 UI로 하나씩 넣는 것보다 쿼리 템플릿으로 INSERT를 생성하는 게 훨씬 빠르다.
| 방식 | 장점 | 단점 | 언제 쓸까 |
|---|---|---|---|
| 관리자 UI | 직관적, 실시간 검증 | 느림, 휴먼에러 가능 | 1-2개 아이템, 운영팀 일일 관리 |
| SQL 시딩 파일 | 일관성, 재현성, 버전관리 | 스키마 변경에 민감 | 초기 데이터셋, 대량 배치 |
| API + 스크립트 | 자동화, 유연함 | 권한 관리 복잡 | 반복되는 작업, CI/CD 통합 |
이번 추가 분석
CRYBABY 시리즈 7개, Labubu 5개라는 건, 마케팅/상품팀이 어느 정도 수량을 정해두고 개발팀이 데이터베이스에 등록하는 과정이다. Coca-Cola/One Piece 같은 태그는 콜라보레이션 정보일 테고, "Almost Hidden", "Finding Mokoko" 같은 건 테마나 판매 유형을 나타내는 듯하다.
여기서 중요한 건, 단순히 INSERT문을 짜는 게 아니라, 이 데이터가 시스템 어디까지 영향을 미치는지 파악하는 것이었다:
- 상품 카테고리/필터링에 이 태그들이 제대로 검색되나?
- 재고 시스템이 이 신규 상품들을 추적할 준비가 됐나?
- QA팀이 콜라보별로 테스트 케이스를 충분히 짜뒀나?
SQLite/PostgreSQL 등 어떤 DB든 상관없지만, 스키마가 갈려 있으면 시딩 파일이 깨진다. 그래서 데이터베이스 마이그레이션(schema change)과 시딩(data insertion)의 순서를 항상 체크한다.
팀 협업 관점에서의 영향
이런 데이터 확장 작업은 혼자만의 일이 아니다:
- 상품팀: "이 12개 아이템을 언제 라이브로 올릴 건지" 일정 공유
- QA팀: "신규 시리즈가 추가되니 필터/검색/재고 로직 한 번 더 봐주세요"
- 운영팀: 만약 오류 발생 시 빠르게 롤백할 수 있도록 시딩 파일의 역순 DELETE 스크립트도 준비
- API/프론트 팀: 새 콜라보 태그를 UI에서 어떻게 표현할지
한 줄의 커밋 메시지 이면에는 이 모든 체크리스트가 숨어 있다. "한번 add하면 끝" 이 아니라 "배포 전에 누가 뭘 테스트해야 하나" 까지 고려해야 한다.
배운 점 & 주의사항
이제까지 여러 번의 대량 데이터 시딩을 거치며 느낀 점:
- 증분(Expansion) 파일명 규칙:
seed-blindbox-expansion-1.sql,expansion-2.sql,expansion-3.sql이런 식으로 번호를 붙인다. 나중에 특정 시점의 스냅샷을 찾기 쉽다. - 베타 환경부터: 개발 → 베타 → 프로덕션 순서로 배포한다. 베타에서 한 번 충분히 돌려본 후에 프로덕션 시딩을 한다.
- Idempotent 설계: 같은 시딩 파일을 여러 번 실행해도 중복 에러가 안 나도록
INSERT ... ON CONFLICT또는IF NOT EXISTS같은 조건을 붙인다.
실제로 한 번은 시딩 파일을 잘못 푸시했다가, 프로덕션에서 PRIMARY KEY 충돌로 배포가 실패한 적이 있다. 그 이후론 스테이징에서 먼저 "이 시딩이 멱등성(idempotent)이 있는지" 체크하는 게 루틴이 됐다.
이번처럼 명확한 스코프의 데이터 추가는 git history로도 명확하게 남으니, 나중에 "언제부터 CRYBABY가 들어왔지?" 하고 궁금할 때 바로 찾을 수 있다. 작은 작업 같지만, 이게 시스템의 추적 가능성(traceability) 을 높이는 일이다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.