문제 상황
식당 / 메뉴 / 리뷰 조회 API를 구현한 뒤
더미데이터를 `data.sql`로 넣고 Postman을 통해 테스트를 진행하였다.
처음에는 단순히 정상 조회 여부만 확인하려 했지만
여러 번 호출하는 과정에서 응답 시간이 일정하지 않다는 점을 발견하였다.
일부 요청은 수십 ms 수준으로 빠르게 응답했지만
특정 요청에서는 48ms, 121ms까지 증가하는 경우도 있었다.
데이터 양이 많지 않은 상황에서도 이런 차이가 발생하는 것을 보며
단순히 기능 구현이 아니라
👉 조회 성능도 함께 고려해야 한다는 문제를 인식하게 되었다.
원인 분석
비슷한 조회 API임에도 응답 시간이 달라지는 이유를 분석해보니
다음과 같은 요소들이 영향을 줄 수 있다고 판단하였다.
- 조회 데이터 양
- 정렬 여부
- 필터 조건
- 연관 엔티티 조회 방식
특히 목록 조회의 경우
한 번에 많은 데이터를 조회하는 구조라면
응답 시간이 증가할 수밖에 없었다.
개선 방향
현재 상태는
- 기능적으로는 정상 동작
- 하지만 성능은 일정하지 않음
즉,
👉 조회는 되지만 효율적이지 않은 상태였다.
따라서 바로 캐시를 적용하기보다는
먼저 조회 자체를 개선하는 것이 필요하다고 판단하였다.
캐시는 결과를 재사용하는 방식이기 때문에
근본적인 조회 비효율을 해결하지는 못하기 때문이다.
다음 단계
다음 단계에서는
- Pageable을 적용하여 조회 데이터 양을 줄이고
- 성능 변화를 확인
하는 방향으로 개선을 진행하기로 하였다.
'트러블슈팅' 카테고리의 다른 글
| 조회 성능 개선 2단계 - 캐시(Cache) 적용 (0) | 2026.03.17 |
|---|---|
| 조회 성능 개선 1단계 - Pageable 적용 (0) | 2026.03.17 |
| @Transactional(readOnly = true)를 조회 로직에서 사용하는 이유 (0) | 2026.03.11 |
| Spring JPA에서 findById() 예외 처리는 Service에서 해야 할까? Repository에서 해야 할까? (0) | 2026.03.11 |
| JPA 연관관계 설계 트러블슈팅 (0) | 2026.03.06 |