상품 추출 API 속도 개선

테스트 환경

• 백엔드: Spring Boot (JPA 기반)
• 프론트엔드: React (Vite + Axios)
• DB: MySQL
• 상품 목록 API: /api/store?sortby=newest
• 측정 도구
  • Postman (1초 간격 반복)
  • 크롬 개발자 도구 Network 탭

---

1. 문제점

React로 만든 쇼핑몰 서비스에서 상품 리스트 페이지 진입 시, 데이터가 늦게 표시되며 체감상 4~5초의 지연...

Postman으로 API를 직접 호출해보니 평균 응답 시간은 약 250ms.
그런데 브라우저에서는 최대 700ms까지 응답 지연 된 부분이 이상하다고 느껴졌다.

• 데이터 크기는 많지 않음에도 응답 시간이 들쑥날쑥
• Entity → DTO 변환 로직에 stream().map() 사용 중
• 상품 조회 쿼리에서 복합 조건 WHERE is_delete = false AND id DESC 사용

 

 

 

2. 개선한점

2- 1) stream -> for문 변경

stream은 람다식이 포함돼 있어 객체를 더 생성하거나 내부적으로 과정을 더 거칠 수 있다는 생각이 들어서 for문으로 변경하였다.

또한, stream은 복잡한 작업 반복에 더 효율적인 방법이라고 알고 있기에 DTO 객체 변환이라는 단순 작업 반복에서는 for문에 더 효율적이라고 생각했다.

 

기존 코드

List<ProductDto> dtoList = products.stream()
    .map(product -> new ProductDto(product))
    .collect(Collectors.toList());

 

변경 코드

List<ProductDto> dtoList = new ArrayList<>();
for (Product product : products) {
    dtoList.add(new ProductDto(product));
}

 

 

2-2) DB 복합 인덱스 추가

상품 목록 조회 시, 해당 쿼리문을 사용한다. 정렬(id DESC) + 조건(is_delete) 쿼리를 효율적으로 처리하기 위해 isdelete와 id 복합 인덱스를 추가하면 DB에서 데이터를 가져오는 속도가 빨라지지 않을까 예상했다.

SELECT * FROM product
WHERE is_delete = false
ORDER BY id DESC
LIMIT ?, ?

 

복합 인덱스

CREATE INDEX idx_product_isdelete_id ON product (is_delete, id);

 

 

 

3. 성능 테스트

2번의 2가지 개선방법에 따른 성능 테스트를 진행해봤다.

 

3-1) Postman (1초 간격 반복)

Postman을 활용하여 1초 간격으로 5번 API를 호출하였다.

 

복합 인덱스 없이 stream 활용한 api의 평균시간: 223.2ms

복합 인덱스와 for문을 활용한 api의 평균시간: 149.2ms

223.2ms에서 149.2ms로 약 33% 감소했다.

 

 

3-2) 크롬 개발자 도구 Network 탭

Postman은 순수하게 api속도를 측정하는 것인데, 실제로 사용자가 느끼기에 느린 것이기 때문에 개발자 도구에서도 속도를 비교해보았다.

 

2차 시도 기준으로 506ms에서 271ms로 약 46% 성능 개선하였다.

 

조건별 API 속도 정리 엑셀보러가기

stream

 

for문

 

 

 

4. 느낀점

 

의문이 드는 부분은 직접 실험해보자!

• stream이 느릴 것 같다는 '감'이 있었지만, 수치로 확인하고 나서야 개선이 명확해짐
• 단순 반복 작업은 명시적인 for문이 더 빠름

DB 인덱스

• 인덱스는 API 속도에도 직접적인 영향 미침
• 쿼리 성능이 나쁘면 아무리 로직을 최적화해도 의미없음
• JPA를 사용하더라도 결국 쿼리 성능은 인덱스에 의존하므로, 조건을 고려한 인덱스 설계의 중요성

사용자 체감 속도

• 사용자 체감 속도 = 백엔드 응답 속도 + 프론트 렌더링 + 네트워크 처리까지 고려