캐시 적용 후 데이터 정합성 문제 해결 (CacheEvict 적용)

2026.03.18 - [트러블슈팅] - 캐시를 적용했는데 왜 첫 조회는 느릴까?

캐시를 적용했는데 왜 첫 조회는 느릴까?

 

문제 상황

조회 API 성능 개선을 위해 캐시를 적용하였다.

캐시를 적용한 이후, 조회 성능은 개선되었지만,

데이터 변경 이후에도 기존 캐시 데이터가 그대로 반환되는 문제가 발생하였다.

 

예를 들어,

• 리뷰를 수정하거나 삭제했음에도
• 이전에 캐싱된 데이터가 그대로 조회되는 상황이 발생하였다.

이로 인해 사용자에게 최신 데이터가 아닌

오래된 데이터가 노출되는 문제가 발생하였다.

---

원인 분석

캐시는 한 번 조회된 데이터를 저장해두기 때문에
데이터가 변경되더라도 캐시의 값은 자동으로 갱신되지 않는다.

이를 쉽게 비유하면,
냉장고(캐시)에 예전에 만들어둔 음식이 있는데
실제 음식(DB)은 이미 바뀌었음에도
냉장고에 있는 옛날 음식을 계속 꺼내 먹는 상황과 같다.

즉,

• DB 데이터는 변경되었지만 캐시는 그대로 유지되면서
• 두 데이터 간 불일치(정합성 문제)가 발생한 것이다.

---

해결 방향

1. 문제 해결 방향 설정

데이터 변경이 발생하는 시점에

캐시를 제거하여 최신 데이터에 다시 조회하도록 설계하였다.

2. CacheEvict 적용

@CacheEvict(value = "storeReviews", allEntries = true)
public ReviewResponse createReview(...) {
    ...
}

• @CacheEvict를 사용하여 캐시를 삭제
• allEntries = true를 통해 해당 캐시의 모든 데이터 제거
• 이후 조회 시 DB에서 최신 데이터를 가져와 다시 캐시에 저장

---

고민 및 개선 방향

현재는 allEntries = true를 사용하여 캐시 전체를 삭제하고 있다.

 

하지만 특정 식당의 리뷰만 변경되었는데
전체 캐시를 삭제하는 것은 비효율적일 수 있다.

예를 들어,

• 특정 storeId의 리뷰만 변경되었음에도
• 다른 식당의 캐시까지 모두 삭제됨

→ 불필요한 캐시 미스 발생
→ 다시 DB 조회 증가
→ 성능 저하 가능성

 

따라서 향후에는

• 캐시를 storeId 단위로 관리하고
• 변경된 데이터에 해당하는 캐시만 선택적으로 삭제하는 방식으로

개선할 수 있다고 판단하였다.

---

결과 및 정리

• 캐시 적용 후 발생한 데이터 정합성 문제를 확인
• CacheEvict를 통해 데이터 변경 시 캐시를 삭제하도록 개선
• 이후 조회 시 최신 데이터가 정상적으로 반영되는 것을 확인

---

느낀 점

캐시는 단순히 성능을 개선하는 기술이 아니라
데이터 정합성과 함께 고려해야 하는 기술이라는 것을 알게 되었다.

 

특히,

캐시를 어떻게 삭제하고, 언제 갱신할 것인가가

캐시 설계에서 매우 중요한 요소라는 것을 깨달았다.