캐시 적용 후 DTO 직렬화 문제 해결 및 대용량 데이터 성능 검증

2026.03.17 - [Spring 2기 과제] - 조회 API 응답 속도가 느린 이유 분석 (Postman 테스트 기반)

조회 API 응답 속도가 느린 이유 분석 (Postman 테스트 기반)

2026.03.17 - [Spring 2기 과제] - 조회 성능 개선 1단계 - Pageable 적용

조회 성능 개선 1단계 - Pageable 적용

2026.03.17 - [Spring 2기 과제] - 조회 성능 개선 2단계 - 캐시(Cache) 적용

조회 성능 개선 2단계 - 캐시(Cache) 적용

 

문제 상황

이전 단계에서 캐시(Cache)를 적용한 결과
조회 API 응답 시간이 약 121ms → 7ms로 크게 개선되었다.

하지만 해당 결과는 비교적 적은 양의 더미데이터 환경에서 측정된 것이었기 때문에

👉 실제 서비스 환경에서도 동일한 성능이 유지될지에 대한 확신이 부족했다.

또한 캐시를 적용하는 과정에서
다음과 같은 예외가 발생하였다.

👉 NotSerializableException

즉,

- 캐시 성능은 개선되었지만
- 캐시 저장 과정에서 오류가 발생하는 상황이었다.

---

원인 분석

Spring Cache는 데이터를 캐시에 저장할 때

👉 객체를 직렬화(Serializable)하여 저장한다.

하지만 Response DTO에는 `Serializable`이 적용되어 있지 않았기 때문에
직렬화 과정에서 예외가 발생한 것이었다.

또한 기존 테스트 환경은 데이터 양이 적어

- 캐시 적용 전/후 차이가 명확하게 드러나지 않을 수 있고
- 실제 서비스 상황을 충분히 반영하지 못하는 한계가 있었다.

---

해결 과정

1️⃣ DTO 직렬화 적용

캐시에 저장되는 Response DTO에
Serializable 인터페이스를 적용하였다.

public class StoreResponse implements Serializable {
    ...
}

 

동일하게

• MenuResponse
• ReviewResponse

에도 적용하였다.

 

👉 이를 통해 캐시 저장 시 발생하던 예외를 해결하였다.

 

2️⃣ 대용량 더미데이터 생성

기존 테스트 환경의 한계를 보완하기 위해

• 리뷰 약 500만 건
• 주문 / 메뉴 / 가게 데이터 포함

👉 대용량 더미데이터를 생성하여 테스트 환경을 구성하였다.

---

테스트 결과

대용량 데이터 환경에서 테스트를 진행한 결과

• 캐시 미적용 → 요청마다 DB 조회 발생 → 응답 시간 증가
• 캐시 적용 → 캐시에서 데이터 반환 → 빠른 응답 유지

특히 데이터 양이 증가할수록

👉 캐시 적용 여부에 따른 성능 차이가 더욱 크게 나타났다.

---

결론

• 캐시는 반복 조회 상황에서 매우 효과적인 성능 개선 방법이다
• 데이터 규모가 커질수록 캐시의 효과는 더욱 명확해진다

또한

👉 캐시를 적용할 때는 반드시 객체 직렬화 여부를 함께 고려해야 한다

---

회고

이번 작업을 통해

단순히 캐시를 적용하는 것에서 끝나는 것이 아니라

• 캐시 저장 구조 (직렬화)
• 실제 서비스 환경을 고려한 테스트 (대용량 데이터)

까지 함께 고려해야 한다는 점을 느낄 수 있었다.

특히

👉 “작은 데이터에서의 성능 테스트는 실제 성능을 보장하지 않는다”

는 점을 직접 경험할 수 있었고,

성능 개선은 단순한 기능 추가가 아니라
👉 검증 과정까지 포함되어야 한다는 것을 깨닫게 되었다.

---

전체 성능 개선 과정

 

1. 조회 API 응답 속도 문제 인식
2. Pageable 적용 (조회량 감소)
3. Cache 적용 (반복 조회 제거)
4. DTO 직렬화 + 대용량 검증

👉 단계적으로 성능을 개선한 경험이었다 !!