서비스 설계 과정에서의 주요 의사결정과 개선 과정

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

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

 

들어가며

이번 프로젝트에서는 단순 기능 구현을 넘어

데이터 흐름과 설계 관점에서 문제를 바라보는 경험을 했다.

 

특히 음악 플랫폼이라는 특성상 다음과 같은 요소를 고민하게 되었다.

• 사용자 행동 흐름 (재생, 자동 재생)
• 데이터 정렬 (플레이리스트 순서)
• 데이터 관리 전략 (삭제 방식)
• 집계 데이터 (인기 차트)

각 문제 상황에서 어떤 고민을 했고,

어떤 기준으로 설계를 결정했는지 정리해보려고 한다.

---

1. 플레이리스트 삭제 — Soft Delete 적용

문제 상황

플레이리스트를 삭제 시

데이터를 실제로 제거할지 고민했다.

 

초기에는 DELETE로 row를 제거하는 방식이 자연스럽다고 생각했지만,

• 복구 불가능
• 이력 관리 불가

라는 문제가 있었다.

---

해결 방향

deletedAt 컬럼을 활용한 Soft Delete 방식 적용

삭제 전: deletedAt = null
삭제 후: deletedAt = 삭제 시각

 

조회 시

WHERE deleted_at IS NULL

---

정리

삭제는 단순 제거가 아니라 논리적 비활성화로 처리

---

2. 플레이리스트 곡 순서 — index 컬럼 설계

문제 상황

플레이리스트는 단순 곡 목록이 아니라 사용자가 설정한 순서 자체가 중요한 데이터이다.

하지만 playlistId, trackId만으로는 순서를 보장할 수 없었다.

---

해결 방향

PlayListTrack에 index 컬럼 추가

track A → index = 1
track B → index = 2
track C → index = 3

 

조회 시

ORDER BY index ASC

---

정리

index는 사용자가 설정한 곡 순서를 유지하기 위한 기준 값

---

3. Playback 설계 — sessionId 도입

문제 상황

재생 기록을 저장할 때 trackId, playedAt만으로 충분해 보였다.

 

하지만

• 재생 → 일시정지 → 다시 재생
• 자동 재생 흐름

이런 이벤트들을 하나의 흐름으로 묶을 기준이 필요했다.

---

해결 방향

sessionId를 하나의 감상 흐름을 묶는 식별자로 정의

• 같은 세션 → 하나의 감상 흐름
• 자동 재생 → 동일 세션 유지
• 사용자 직접 선택 → 새로운 세션

---

정리

sessionId는 단순 ID가 아니라 사용자 행동 흐름을 모델링하기 위한 핵심 값

---

4. 자동 재생 흐름 설계

문제 상황

자동 재생에서는 여러 곡이 이어지는데 이를 어떻게 저장할지 기준이 필요했다.

---

해결 방향

자동 재생 흐름 기준 정의

sessionId = 동일
trackId = 곡마다 변경
playedAt = 각 곡 시작 시점
playDuration = 실제 재생 시간

 

예시

sessionId = 001

A곡 / 10:00 / 200초  
B곡 / 10:03 / 180초  
C곡 / 10:06 / 30초

---

정리

• 세션 = 재생 흐름
• row = 개별 곡 기록

하나의 흐름 안에서 사용자 행동을 분석할 수 있도록 설계

---

5. 인기 차트 — snapshotDate 설계

문제 상황

Top100 차트를 조회할 때 “언제 기준 차트인지”가 명확하지 않았다.

---

해결 방향

snapshotDate를 차트 기준 시점을 나타내는 컬럼으로 정의

snapshotDate = 2026-04-07 (해당 주차)

---

설계 기준

1. 주간 단위 선택

• 일간 → 변동성 큼
• 월간 → 반응 느림

주간 = 안정성과 반응성 균형

2. 기준일 : 월요일

• 주차 구분 명확
• 비교 용이

---

정리

snapshotDate는 단순 날짜가 아니라 차트의 기준 시점을 정의하는 핵심 값

---

핵심 설계 포인트

• Soft Delete → 데이터 보존 전략
• index → 사용자 의도 반영
• sessionId → 사용자 행동 흐름 모델링
• 자동 재생 → 이벤트 흐름 설계
• snapshotDate → 시간 기반 데이터 관리

---

마무리

이번 경험을 통해 단순 CRUD를 넘어서 데이터 흐름 중심으로 설계하는 사고 방식을 익힐 수 있었다.

 

특히, "이 데이터는 왜 필요한가?", "이 구조는 어떤 확장을 고려한 것인가?"를 고민하면서 단순 구현이 아니라 설계 중심의 사고를 할 수 있게 되었다. 앞으로도 기능 구현에 그치지 않고 데이터와 흐름을 이해하는 개발자로 성장하고 싶다.