2026.03.17 - [Spring 2기 과제] - 조회 API 응답 속도가 느린 이유 분석 (Postman 테스트 기반)
조회 API 응답 속도가 느린 이유 분석 (Postman 테스트 기반)
문제 상황 식당 / 메뉴 / 리뷰 조회 API를 구현한 뒤 더미데이터를 `data.sql`로 넣고 Postman을 통해 테스트를 진행하였다.처음에는 단순히 정상 조회 여부만 확인하려 했지만 여러 번 호출하는 과정
sudaruuu.tistory.com
문제 상황
조회 API의 응답 시간이
최대 121ms까지 증가하는 것을 확인하였다.
특히 목록 조회의 경우
한 번에 많은 데이터를 가져오면서 성능 저하가 발생하고 있었다.
원인 분석
문제의 원인은
👉 한 번에 조회되는 데이터 양이 많다는 점
이었다.
데이터가 많아질수록
- 조회 시간 증가
- 응답 속도 저하
가 발생할 수밖에 없는 구조였다.
해결 과정
조회 데이터 양을 줄이기 위해
Spring Data JPA의 `Pageable`을 적용하였다.
@Transactional(readOnly = true)
public Page<StoreResponse> getStores(String keyword, Pageable pageable) {
...
}
결과
Pageable 적용 후 테스트 결과
- 기존: 약 121ms
- 적용 후: 약 77ms
👉 조회 성능이 일부 개선된 것을 확인할 수 있었다.
한계
하지만 여전히
- 반복 조회 시 DB 접근 발생
- 성능 개선 폭 제한
이라는 문제가 남아 있었다.
다음 단계
다음 단계에서는
👉 캐시(Cache)를 적용하여 반복 조회 성능을 개선하기로 하였다.
'트러블슈팅' 카테고리의 다른 글
| 캐시 적용 후 DTO 직렬화 문제 해결 및 대용량 데이터 성능 검증 (0) | 2026.03.17 |
|---|---|
| 조회 성능 개선 2단계 - 캐시(Cache) 적용 (0) | 2026.03.17 |
| 조회 API 응답 속도가 느린 이유 분석 (Postman 테스트 기반) (0) | 2026.03.17 |
| @Transactional(readOnly = true)를 조회 로직에서 사용하는 이유 (0) | 2026.03.11 |
| Spring JPA에서 findById() 예외 처리는 Service에서 해야 할까? Repository에서 해야 할까? (0) | 2026.03.11 |