플레이리스트 설계에서 트랙 중복을 허용하지 않은 이유

2026.04.08 - [Spring 2기 과제] - fivefy 프로젝트 - 데이터 흐름을 고려한 음악 서비스 설계 (도메인 · ERD · API · 비즈니스 규칙)

데이터 흐름을 고려한 음악 서비스 설계 (도메인 · ERD · API)

 

문제 상황

플레이리스트에 트랙을 추가하는 기능을 설계하면서 동일한 트랙을 여러 번 추가할 수 있도록 허용할지에 대한 고민이 생겼다.

 

단순히 기능적으로는 중복 추가가 가능하지만,

이 방식이 데이터 구조와 이후 기능에 어떤 영향을 줄지에 대한 검토가 필요했다.

---

고민한 이유

• 동일 트랙이 여러 번 저장될 경우 데이터가 불필요하게 증가할 수 있다.
• 플레이리스트 내 트랙 순서를 'index'로 관리하는 구조에서 중복 데이터가 많아질수록 정렬 및 순서 변경 로직이 복잡해질 수 있다.
• 인기 차트, 재생 흐름 등 다른 기능과 연결될 경우 중복 데이터가 집계 결과에 영향을 줄 수 있다.

---

해결 방향

동일 트랙의 중복 추가를 허용하지 않는 방식으로 설계했다.

 

또한 단순히 서비스 로직에서만 처리하는 것이 아니라,

• 서비스 레벨에서 `exists` 체크를 통해 중복 여부를 사전 검증하고
• DB 레벨에서 Unique 제약 (`playlist_id`, `track_id`)을 적용하여

이중으로 데이터 무결성을 보장하도록 했다.

---

선택한 이유

1. 데이터 정합성 보장

동일 트랙이 중복 저장되는 것을 원천적으로 방지

2. 순서(index) 관리 단순화

중복 데이터가 없을 경우 정렬 및 순서 변경 로직이 단순해짐

3. 방어적인 설계

서비스 로직 + DB 제약을 함께 적용하여

동시성 상황에서도 안정적인 데이터 관리 가능

---

정리

동일 트랙 중복 추가 방지는 단순 UX 정책이 아니라,
데이터 정합성과 이후 로직 복잡도를 줄이기 위한 설계 선택이다.

서비스 로직과 DB 제약을 함께 사용하는 것이 안정적인 데이터 관리에 효과적이라고 판단했다.

---

느낀 점

이번 경험을 통해 "중복을 허용할 것인가"와 같은 적은 선택도 데이터 구조와 서비스 전체 설계에 영향을 준다는 것을 느꼈다.

앞으로는 기능 구현에 앞서 데이터를 어떻게 저장하고 관리할 것인지 먼저 고민하는 개발자가 되고자 한다.