최신 snapshot 조회 로직 개선과 DB 정렬 기반 조회

문제 상황

인기 차트 조회 기능에서 최신 snapshotDate를 기준으로 데이터를 가져와야 했다.

초기에는 다음과 같이 구현되어 있었다.

return popularChartRepository.findAll().stream()
        .map(PopularChart::getSnapshotDate)
        .max(LocalDateTime::compareTo)

 

전체 데이터를 조회한 뒤, 서비스 로직에서 최신 날짜를 찾는 방식이었다.

기능적으로는 문제가 없었지만, 최신 값 하나를 찾기 위해 모든 데이터를 조회하는 구조였다.

---

원인 분석

기존 방식에는 다음과 같은 비효율이 있었다.

• 전체 데이터를 DB에서 조회한 뒤 처리
• 최신 날짜 비교를 서비스 로직에서 수행
• 데이터가 많아질수록 조회 시간과 메모리 사용 증가 가능

특히 최신 snapshot 하나만 필요함에도 모든 데이터를 조회하는 방식은 불필요한 조회 범위를 발생시키는 구조였다.

따라서 데이터가 많아질수록 이러한 비효율이 더 크게 나타날 수 있었다.

---

해결 방향

최신 snapshotDate 조회를 DB 정렬 기반으로 처리하도록 변경하였다.

 

Repository에 다음 메서드를 추가하였다.

Optional<PopularChart> findFirstByOrderBySnapshotDateDesc();

 

이를 통해 DB에서 정렬 후 가장 최신 데이터 1건만 조회하도록 변경하였다.

 

서비스 로직도 다음과 같이 수정하였다.

private LocalDateTime findLatestSnapshotDate() {
    return popularChartRepository.findFirstByOrderBySnapshotDateDesc()
            .map(PopularChart::getSnapshotDate)
            .orElseThrow(() -> new BusinessException(PopularChartErrorCode.CHART_NOT_FOUND));
}

---

결과

• 최신 snapshotDate 조회를 DB 정렬 기반으로 처리
• 불필요한 전체 데이터 조회 제거
• 조회 범위 축소로 성능 개선

---

정리

단순히 동작하는 코드에서 끝나는 것이 아니라, 필요한 데이터만 조회하도록 설계하는 것이 중요하다. 특히 정렬이나 최신값 조회처럼 DB에서 더 효율적으로 처리할 수 있는 작업은 DB 정렬 기반으로 처리하도록 구성하는 것이 적절하다.

---

느낀 점

처음에는 기능이 정상 동작하는 것에 집중했지만, 구현 이후 다시 살펴보니 불필요한 조회가 포함된 구조라는 것을 알게 되었다.

이번 리팩토링을 통해 단순히 결과를 얻는 것이 아니라, 어떻게 가져오는지까지 함께 고려하는 것이 중요하다는 것을 느꼈다.