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

문제 상황

캐시를 적용한 후 조회 API의 성능을 테스트해보았다.

 

캐시를 사용하면 조회 성능이 개선될 것이라고 기대했지만,

첫 번째 요청에서는 여전히 응답 속도가 느린 것을 확인할 수 있었다.

 

즉, 캐시를 적용했음에도 불구하고

초기 요청에서는 성능 개선 효과가 크게 체감되지 않았다.

 

이 문제의 원인을 이해하기 위해 캐시의 동작 방식에 대해 다시 고민해보게 되었다.

---

원인 분석

캐시는 데이터를 미리 저장해두는 공간이다.

 

이를 쉽게 이해하기 위해 냉장고에 비유해보면 다음과 같다.
처음 요청이 들어왔을 때는 냉장고(캐시)에 음식이 없기 때문에
마트(DB)에 직접 가서 데이터를 가져와야 한다.
이 과정에서 DB 접근이 발생하고, 그만큼 시간이 오래 걸리기 때문에
첫 조회는 느릴 수밖에 없다.

하지만 한 번 가져온 데이터는 냉장고(캐시)에 저장되기 때문에
그 이후 요청부터는 DB를 거치지 않고 빠르게 응답할 수 있다.

즉, 첫 조회가 느린 이유는 단순하다.

캐시에 데이터가 없기 때문에 DB를 한 번은 반드시 조회해야 하기 때문이다.

---

해결 방향

첫 조회가 느린 문제를 완전히 제거할 수는 없지만,

다음과 같은 방법을 통해 완화할 수 있다.

 

• 사람들이 자주 조회하는 데이터는 미리 캐시에 넣어두기 (캐시 워밍업)
• 캐시가 사라지기 전에 다시 미리 채워두기 (TTL 기반 갱신)
• 기본적으로는 캐시에 없으면 한 번은 DB를 조회하는 방식 유지 (Cache Aside)

다만, 모든 데이터를 미리 캐시에 넣는 것은 메모리 낭비로 이어질 수 있다.

 

따라서 자주 조회되는 데이터 (핫 데이터) 위주로만 캐시를 적용하는 것이

더 효율적인 전략이라고 판단하였다.

 

결국 캐시는

• 모든 데이터를 빠르게 만드는 것이 아니라
• 자주 조회되는 데이터를 빠르게 만드는 데 목적이 있다.

---

추가로 고민한 점

캐시를 사용할 때는 성능뿐만 아니라 데이터 정합성도 중요하다.

 

예를 들어, 리뷰가 수정되거나 삭제되었는데

기존 캐시가 그대로 유지된다면 사용자에게 오래된 데이터가 노출될 수 있다.

 

이를 방지하기 위해서는

• 데이터 변경 시 캐시 삭제 (Cache Evict)
• 일정 시간이 지나면 캐시 자동 삭제 (TTL)

와 같은 전략을 함께 사용해야 한다.

---

정리

캐시는 모든 요청을 빠르게 만드는 기술이 아니다.

 

한번 조회된 데이터를 이후 빠르게 제공하기 위한 전략이다.

 

따라서 첫 조회가 느린 것은 자연스러운 현상이며,

중요한 것은 반복 조회에서 성능을 개선하는 것이다.

 

캐시를 적용할 때는 단순히 속도 향상만을 기대하기보다

어떤 데이터를 캐싱할지, 언제 갱신할지까지 함께 고민하는 것이 필요하다.