기능 구현에서 설계까지 음악 플랫폼 도메인 설계 경험 정리

들어가며

이번 프로젝트에서는 음악 플랫폼의 핵심 기능인 Playlist, PlaylistTrack, Playback, PopularChart 도메인을 구현했다. 구현 이후, 서비스 관점에서 기존 구조를 다시 검토하며 설계를 개선하는 과정을 거쳤다.

 

이 글에서는 문제를 어떻게 정의했고, 어떤 기준으로 설계를 개선했는지 전체 흐름 중심으로 정리하고자 한다.

---

구현한 기능

• Playlist
  플레이리스트 생성 / 조회 / 수정 / 삭제 (soft delete)
• PlaylistTrack
  트랙 추가 / 조회 / 순서 변경 / 삭제
• Playback
  play / pause / stop / skip 기반 재생 상태 관리
• PopularChart
  Playback 데이터를 기반으로 주간 Top100 차트 생성 및 조회

---

주요 설계 방향

이번 구현에서는 기능 자체보다 “어떤 기준으로 동작해야 하는가”를 먼저 정의하는 데 집중했다.

• Playback → 상태 전이 중심 설계
• PopularChart → 주간 스냅샷 기반 집계
• Playlist / PlaylistTrack → DB 무결성과 동시성 고려

단순히 기능 구현이 아닌, 데이터와 흐름을 기준으로 설계를 구성했다.

---

문제 정의

1. Playlist - soft delete와 유니크 제약 충돌

soft delete 구조에서는 삭제된 데이터가 DB에 남는다.

이로 인해 동일한 제목으로 재생성 시 유니크 제약에 걸리는 문제가 발생했다.

2. PlaylistTrack - 순서 변경과 동시성 문제

서비스 레벨 검증만으로는 동시 요청 상황에서 무결성을 보장할 수 없었다.

또한 트랙 하나만 이동해도 전체 재정렬이 발생하여 불필요한 DB 업데이트가 증가하는 문제가 있었다.

3. Playback - 상태 정의의 모호함

초기 설계에서는 상태가 불명확했고, 재생 시간 누적 기준도 정의되어 있지 않았다.

결과적으로 재생 흐름을 명확하게 표현하기 어려운 구조였다.

4. PopularChart - 데이터 신뢰도 문제

단순 count 기반 집계에서는

• 짧은 재생도 동일하게 반영되고
• 반복 재생도 그대로 누적되어

차트 데이터의 신뢰도가 떨어지는 문제가 있었다.

---

해결 과정

Playlist

• deleted 필드를 분리하여 활성 데이터 기준으로 중복 검사
• (user_id, title, deleted) 기준 DB 유니크 제약 적용
• cleanup 스케줄러로 soft delete 데이터 정리

서비스 검증 + DB 제약조건을 함께 적용한 이중 방어 구조로 개선

PlaylistTrack

• (playlist_id, track_id), (playlist_id, position) 유니크 제약 적용
• 예외를 트랙 중복 / 순서 충돌로 분리
• 전체 재정렬 → 부분 재정렬 방식으로 개선

동시성 문제 해결 및 불필요한 DB 업데이트 감소

Playback

• 상태를 명확하게 정의
  (PLAYING, PAUSED, STOPPED, SKIPPED, COMPLETED)
• 상태 전이 규칙 정리
• 재생 시간 누적 기준 정의
• sessionId 기반 재생 흐름 관리

단순 CRUD 구조에서 상태 기반 도메인으로 전환

PopularChart

• 주간 스냅샷 기반 집계 구조 적용
• 기준 시점 고정으로 조회 안정성 확보
• 유효 재생 기준을 반영할 수 있도록 확장 가능하게 설계

조회 안정성과 데이터 신뢰도를 함께 고려한 구조

---

기술 선택과 트레이드오프

PlaylistTrack position 기반 정렬

• 장점 : 단순한 구현
• 단점 : 순서 변경 시 position 업데이트 발생 → 대규모 데이터 성능 부담
• LexoRank 등 간격 기반 정렬 확장 고려

상태 기반 Playback

• 장점 : 재생 흐름 표현 명확
• 단점 : 상세 분석에는 한계
• 이벤트 로그 구조로 확장 고려

스냅샷 기반 차트

• 장점 : 기준 시점이 고정 → 조회 안정성 확보
• 단점 : 실시간 반영 어려움
• Redis 기반 실시간 랭킹으로 확장 고려

---

관련 글

각 도메인에서의 설계 고민과 개선 과정은 아래 글에서 더 자세히 확인할 수 있다.

Playlist (데이터 무결성)

2026.04.22 - [Fivefy 프로젝트/트러블슈팅] - Soft Delete 구조에서 DB 유니크 제약을 통한 데이터 무결성 보완

Soft Delete 구조에서 DB 유니크 제약을 통한 데이터 무결성 보완

---

PlaylistTrack (순서 / 동시성)

2026.04.23 - [Fivefy 프로젝트/트러블슈팅] - PlaylistTrack 순서 변경 최적화 전체 재정렬을 부분 재정렬로 개선

PlaylistTrack 순서 변경 최적화 : 전체 재정렬에서 부분 재정렬로 개선한 과정

---

Playback (상태 흐름)

2026.04.15 - [Fivefy 프로젝트/설계] - Playback 도메인 설계 고도화 (행동 중심 enum을 상태 중심으로 재정의한 이유)

Playback 도메인 설계 고도화 (행동 중심 enum을 상태 중심으로 재정의한 이유)

---

PopularChart (집계 구조)

2026.04.21 - [Fivefy 프로젝트/트러블슈팅] - 유효 재생 기준 적용과 Projection 기반 집계 구조 개선 과정

유효 재생 기준 적용과 Projection 기반 집계 구조 개선 과정

---

회고 및 배운 점

재생 상태와 흐름을 명확히 정의하고 이를 플로우차트로 구조화한 뒤 구현해보니, 복잡했던 재생 로직도 훨씬 수월하게 다룰 수 있었습니다.

 

또 설계 측면에서는 서비스 레벨 검증만으로는 한계가 있어 DB 제약조건까지 포함한 이중 방어 설계의 필요함을 체감했습니다. 또한 스냅샷 기반 차트와 같은 시간 의존 로직은 테스트 전략까지 함께 설계해야 검증 가능한 구조를 만들 수 있음을 이해했습니다. 결과적으로 기능 구현을 넘어서, 기준을 먼저 정의하는 설계의 중요성을 체감했습니다.