K-pop 도메인을 별도 서비스로 분리, 스키마 구축
목차
새로운 도메인(K-pop)을 위해 12개 테이블의 스키마를 설계하고, kpop.hedvion.com 에서 독립된 서버로 이전하기로 결정했다.
스키마 설계의 실제 의사결정
코드베이스 규모가 커지면서 도메인 간 경계가 모호해지는 문제가 생긴다. 이 작업은 단순히 DB 테이블 몇 개를 추가하는 것 이상의 의미를 지닌다. 12개 테이블이라는 규모는 그것이 하나의 완전한 서비스 도메인임을 뜻한다.
처음엔 이 기능들을 기존 메인 스키마에 넣을지, 아니면 별도 스키마로 분리할지를 놓고 팀 내에서 논의가 있었다. 이전에 비슷한 시도에서 "일단 한곳에 다" 하다가 나중에 마이그레이션 비용이 훨씬 커진 경험이 있었기에, 이번엔 초기 단계부터 도메인 경계를 명확히 하기로 결정했다.
스키마 설계 단계에서 신경 쓴 부분:
- 테이블 간 관계 설정 (외래키, 조인 패턴)
- 각 테이블의 인덱싱 전략
- 마이그레이션 경로 (기존 데이터 → 신규 스키마)
- 도메인 간 데이터 동기화 필요 여부 (예: 사용자 정보 참조 등)
도메인 이전 결정의 배경
kpop.hedvion.com 에서 별도 서버로 이전한다는 결정은 기술적, 조직적으로 중요한 전환점이다.
기술 관점에서:
- 각 도메인이 독립적으로 스케일링 가능 → 트래픽 특성이 다르면 별도 리소스 할당 가능
- 배포 주기 독립화 → 한쪽 서비스 점검이 다른 쪽에 영향 없음
- DB 부하 분산 → 쿼리 패턴이 다르면 복제 및 캐싱 전략을 다르게 적용
운영 관점에서:
- 모니터링과 로깅을 도메인별로 분리 → 장애 추적이 명확해짐
- 데이터 백업/복구 정책을 별도로 수립 → 도메인의 중요도에 따라 다른 RPO/RTO 설정 가능
- 팀 책임 구분 → 각 팀이 자신의 도메인 스키마를 소유하는 모델로 전환
다만 이 선택은 데이터 일관성 관리가 복잡해진다는 트레이드오프를 안고 있다. 기존 메인 서버와 신규 서버 간에 공유하는 데이터(예: 사용자, 권한 등)가 있다면, 동기화 메커니즘을 별도로 구축해야 한다.
CLAUDE.md 업데이트의 의미
변경 파일 목록에 CLAUDE.md 가 포함된 것은 단순 문서 개정이 아니라 팀 규칙 확정을 의미한다.
새로운 도메인이 추가되면서:
- 스키마 네이밍 컨벤션 (예: kpop_* 접두사 사용)
- 마이그레이션 및 배포 체크리스트
- 도메인 간 데이터 참조 시 주의사항
- 모니터링/로깅 표준
이런 항목들을 CLAUDE.md에 문서화하는 것이 중요한 이유는, 팀원들이 같은 스키마를 건드릴 때 일관된 의사결정을 하도록 돕기 때문이다. 이전에 규칙 없이 각자 다르게 작업한 경험이 있다면, 나중에 스키마 리뷰나 마이그레이션 단계에서 불필요한 왕복이 생긴다.
마이그레이션과 일정에 대한 생각
이 커밋이 "마이그레이션 완료"가 아니라 "스키마 설계 + 도메인 이전 결정"인 점이 중요하다. 실제 데이터 이전은 여러 단계를 거친다:
- 스키마 검증 — 신규 스키마가 실제 요구사항을 모두 반영하는지 팀과 리뷰
- Dry-run 마이그레이션 — 프로덕션 데이터를 신규 스키마로 옮겨 보고 검증
- 서버 준비 — 신규 서버 인프라 구성, 네트워킹 설정
- Dual-write 기간 — 두 시스템에 동시 쓰기하면서 데이터 동기화 확인
- 점진적 트래픽 전환 — 일부 사용자 또는 기능부터 신규 서버로 라우팅
- 레거시 서버 완전 종료 — 모든 트래픽 전환 확인 후 기존 시스템 정리
각 단계마다 롤백 계획이 필요하고, 데이터 불일치 감지 로직도 함께 준비해야 한다. 이번 커밋은 그 여정의 기초 설계 단계인 셈이다.
처음에는 "스키마 정의하고 바로 이전하면 되지 않을까" 생각할 수 있지만, 실무에서는 기존 데이터와의 호환성, 장애 시나리오, 팀 역량 등이 모두 마이그레이션 일정에 영향을 미친다. 그래서 설계 단계에서부터 "어떻게 이전할 것인가"를 함께 고민해야 한다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.