재생 시스템 설계에서 sessionId 기반 로그 구조를 선택한 이유

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

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

 

문제 상황

재생 기능을 설계하면서 "단순히 음악을 재생한다"를 넘어
재생 기록을 어떻게 저장할 것인지에 대해 고민이 필요했다.
 
특히 다음과 같은 상황을 고려해야 했다.

• 같은 곡을 여러 번 재생했을 때 기록을 어떻게 저장할 것인가
• 재생 / 일시정지 / 건너뛰기 이벤트를 어떻게 관리할 것인가
• 자동 재생 흐름을 하나의 감상 흐름으로 볼 수 있는가

즉, 단순 로그 저장이 아닌 "사용자의 재생 흐름을 어떻게 모델링할 것인가"가 핵심 문제였다.

---

고민한 이유

1. 재생 기록 저장 방식

재생 기록을 저장하는 방식에는 두 가지 선택지가 있었다.

• 누적 방식 : 하나의 데이터에 재생 횟수를 증가시키는 방식
• 로그 방식 : 재생할 때마다 개별 이력을 저장하는 방식 

2. 재생 흐름 분석 필요성

단순히 "몇 번 들었는지"보다

• 어떤 곡을 연속으로 들었는지
• 자동 재생 흐름인지
• 중간에 끊겼는지

와 같은 "사용자 행동 흐름 분석"이 더 중요하다고 판단했다.

3. 인기 차트와의 연결

인기 차트는 재생 수 기반으로 집계되기 때문에
재생 데이터를 어떤 형태로 저장하느냐에 따라

• 집계 방식
• 데이터 활용 방식

이 모두 달라질 수 있다.

---

해결 방향

1. 재생 기록은 로그 형태로 저장

재생 기록은 중복 허용 로그 방식으로 저장하도록 설계했다.

• 동일 트랙 반복 재생 시 각각 개별 데이터로 저장
• 재생 이력을 시간 기준으로 추적 가능

단순 count가 아닌 "행동 데이터"로 활용 가능

2. sessionId 도입

재생 흐름을 하나의 단위로 묶기 위해
`sessionId`를 도입했다.

• 하나의 음악 감상 흐름을 하나의 session으로 정의
• 자동 재생(A → B → C)은 동일 session으로 묶임
• 사용자가 직접 곡을 선택하면 새로운 session 시작

이벤트 단위가 아닌 “흐름 단위”로 분석 가능

3. PopularChart와의 연결

• 로그 데이터를 기반으로 재생 수 집계 가능
• snapshotDate 기준으로 차트 생성
• 특정 기간(주간) 단위로 순위 계산

별도 집계 테이블을 통해 조회 성능 최적화

---

정리

이번 설계에서 가장 중요한 포인트는 재생 기록을 단순 저장 데이터가 아니라 "사용자 행동 데이터로 바라본 것"이다.

• 로그 방식 → 데이터 활용 가능성 확보
• sessionId → 흐름 단위 분석 가능
• 차트 → 데이터 집계 구조 연결

결과적으로 "데이터를 어떻게 쌓을 것인가"가 서비스 확장성을 결정한다는 것을 느낄 수 있었다.

---

느낀 점

초기에는 단순히 재생 기능 구현에만 집중했지만, 데이터를 어떤 방식으로 저장할지에 따라 인기 차트, 추천 시스템, 사용자 분석과 같은 기능까지 영향을 준다는 점을 깨달았다. 이번 경험을 통해 기능 구현 이전에 데이터 설계를 먼저 고민하는 것이 얼마나 중요한지 느낄 수 있었다.