문제 상황
인기 차트 생성 로직을 구현한 이후, 차트가 정상적으로 생성되고 조회까지 되는지 확인하는 과정에서 구조적인 아쉬움을 느꼈다.
generateWeeklyChart 메서드 내부에서
- 집계
- 차트 생성
- 저장
모든 로직이 한 곳에 몰려 있었고,
특히 Top100 차트 생성 로직까지 함께 포함되어 있어 코드의 흐름이 길어지고 가독성이 떨어지는 문제가 있었다.
원인 분석
기존 구조에서는 하나의 메 서드가 다음 역할을 모두 담당하고 있었다.
- 주간 집계 흐름 제어
- Playback 데이터 조회
- Top100 차트 생성
- DB 저장
이로 인해
- 메서드의 책임이 과도하게 커졌고
- "차트 생성"이라는 하나의 의미 있는 로직이 묻히는 문제가 있었다
해결 과정
차트 생성 로직을 별도의 메서드로 분리했다.
Before
List<PopularChart> charts = new ArrayList<>();
int rank = 1;
for (TrackPlayCountProjection result : results.stream().limit(100).toList()) {
charts.add(
PopularChart.create(
result.getTrackId(),
rank++,
result.getPlayCount(),
snapshotDateTime
)
);
}
popularChartRepository.saveAllAndFlush(charts);
After
List<PopularChart> charts = createTopCharts(results, snapshotDateTime);
popularChartRepository.saveAllAndFlush(charts);
private List<PopularChart> createTopCharts(
List<TrackPlayCountProjection> results,
LocalDateTime snapshotDateTime
) {
List<PopularChart> charts = new ArrayList<>();
int rank = 1;
for (TrackPlayCountProjection result : results.stream().limit(TOP_CHART_LIMIT).toList()) {
charts.add(
PopularChart.create(
result.getTrackId(),
rank++,
result.getPlayCount(),
snapshotDateTime
)
);
}
return charts;
}
결과
차트 생성 로직을 분리하면서
- generateWeeklyChart는 전체 흐름 제어에 집중하고
- createTopCharts는 차트 생성만 담당하도록 구조를 개선할 수 있었다
또한 코드의 의도가 더 명확해졌고,
각 로직을 개별적으로 이해하기 쉬운 구조로 변경되었다.
조회 흐름 검증
차트 생성 이후, 실제 API를 통해 조회까지 정상적으로 동작하는지 확인했다.
GET /api/popular-charts/top100

이로 인해
- Playback 데이터 기반 집계
- snapshot 생성
- 인기 차트 조회
전체 흐름이 정상적으로 동작함을 확인할 수 있었다.
느낀 점
단순히 기능을 구현하는 것을 넘어서, 로직을 의미 단위로 분리하는 것이 코드의 가독성과 유지보수성에 큰 영향을 준다는 것을 느꼈다. 이번 리팩토링을 통해 서비스 메서드의 역할을 명확히 나누는 기준을 다시 정리할 수 있었다.
'Fivefy 프로젝트 > 트러블슈팅' 카테고리의 다른 글
| AWS EC2 + RDS 환경에서 Spring Boot 배포 (0) | 2026.05.08 |
|---|---|
| Top N 제한을 DB로 이동하며 조회 성능 개선한 경험 (0) | 2026.04.28 |
| PlaylistTrack 순서 변경 최적화 전체 재정렬을 부분 재정렬로 개선 (0) | 2026.04.23 |
| Soft Delete 구조에서 DB 유니크 제약을 통한 데이터 무결성 보완 (0) | 2026.04.22 |
| Soft Delete 기반 플레이리스트 정책 개선 (1) | 2026.04.22 |