[Database] 캐싱(Caching)

TECHNICAL NOTE

캐싱(Caching) 정리

📋 목차

• 1. 캐싱이란 무엇인가?
• 2. 핵심 용어 정리
• 3. 캐싱 전략과 Spring Boot 적용
• 4. 로컬 캐시 vs 분산 캐시 / 주의사항
• 5. 핵심 요약 (Conclusion)

01. 캐싱이란 무엇인가?

"자주 쓰는 데이터를 빠른 저장소에 미리 올려두는 것"

매일 아침 같은 뉴스를 DB에서 조회한다고 가정해보면, 요청마다 DB까지 왕복하면 응답 시간이 늘어나고 DB에 부하가 쌓인다. 첫 조회 결과를 어딘가 가까운 곳에 저장해두고, 다음 요청부터는 거기서 꺼내 쓰는 것이 바로 캐싱이다.

• 반복적인 DB 조회를 줄여 응답 속도를 높인다.
• DB 서버에 걸리는 부하를 감소시킨다.

REST API를 개발하다 보면 아래와 같은 흐름이 반복된다.

클라이언트 → Controller → Service → Repository → DB (느림 ⚠)

데이터가 자주 바뀌지 않는다면 매번 DB까지 갈 필요가 없다. 캐시를 중간에 끼우면 흐름이 달라진다.

클라이언트 → Controller → Service → [ 캐시 HIT ✅ ] → 바로 반환
                                    [ 캐시 MISS ❌ ] → DB 조회 → 캐시 저장 → 반환

---

02. 핵심 용어 정리

용어	설명
Cache Hit	캐시에 데이터가 존재하여 DB 접근 없이 바로 반환하는 상황
Cache Miss	캐시에 데이터가 없어서 DB까지 조회해야 하는 상황
TTL (Time To Live)	캐시 데이터의 유효 기간. 만료되면 자동으로 삭제된다.
Eviction	캐시 공간이 가득 찼을 때 오래되거나 덜 사용된 데이터를 제거하는 정책 (예: LRU)
Cache Invalidation	원본 데이터가 변경되었을 때 캐시를 무효화(삭제)하는 것. 일관성 유지의 핵심이다.

---

03. 캐싱 전략과 Spring Boot 적용

캐싱 전략 3가지

가장 일반적

Look-Aside

애플리케이션이 직접 캐시를 확인하고, 없으면 DB에서 가져와 저장하는 방식. Spring의 @Cacheable이 이 방식을 따른다.

읽기: 캐시 확인 → Miss면 DB 조회 → 캐시 저장
쓰기: DB 저장 (캐시는 TTL/Evict)

일관성 우선

Write-Through

데이터를 쓸 때 DB와 캐시를 동시에 업데이트한다. 일관성이 높지만 쓰기 성능이 다소 저하된다.

쓰기: DB + 캐시 동시 업데이트
읽기: 캐시에서 항상 최신 데이터

쓰기 성능 우선

Write-Behind

캐시에만 먼저 쓰고 DB 반영은 나중에 비동기로 처리한다. 쓰기는 빠르지만 장애 시 데이터 유실 위험이 있다.

쓰기: 캐시에만 즉시 저장
DB: 나중에 비동기 반영 ⚠

Spring Boot에서 캐싱 적용하기

Step 1. 의존성 추가 (build.gradle)

// Spring Cache 추상화
implementation 'org.springframework.boot:spring-boot-starter-cache'

// 로컬 캐시 → Caffeine
implementation 'com.github.ben-manes.caffeine:caffeine'

Step 2. 캐시 활성화

@SpringBootApplication
@EnableCaching  // 반드시 추가해야 캐시가 동작한다!
public class Application { ... }

Step 3. 서비스 레이어 적용

@Cacheable(value = "posts", key = "#postId")
public PostResponse getPost(Long postId) { ... }

@CacheEvict(value = "posts", key = "#postId")
public void updatePost(Long postId, PostRequest request) { ... }

---

04. 로컬 캐시 vs 분산 캐시 / 주의사항

특징	로컬 캐시 (Caffeine)	분산 캐시 (Redis)
속도	매우 빠름 (JVM 내)	상대적 느림 (네트워크)
확장성	서버별 별도 (불일치 위험)	공유 캐시 (데이터 일치)
영속성	재시작 시 초기화	디스크 저장 가능

⚠ 캐싱 시 주의해야 할 것들

캐시 일관성(Cache Consistency) 문제가 가장 중요하다. DB는 업데이트됐는데 캐시가 이전 데이터를 갖고 있으면 클라이언트가 잘못된 응답을 받게 된다.

✅ 캐싱하기 좋은 데이터
자주 읽히고 잘 변하지 않으며 연산 비용이 큰 것 (공지사항, 통계 등)

❌ 캐싱을 피해야 할 데이터
실시간성이 중요하거나 개인화된 정보 (장바구니, 실시간 재고 등)

⚠️ 무분별한 캐싱 금지
캐시 메모리는 유한하다. TTL과 Eviction 정책을 반드시 설계해야 한다.

---

05. 핵심 요약

"캐싱은 응답 성능을 극대화하는 핵심 기술이다.
Spring Boot의 선언적 어노테이션을 활용하면 코드 수정 없이 효율적으로 적용 가능하며,
서비스 확장 시에는 Redis 기반 분산 캐시를 고려하자."

Last Sync: 2026-04-30 | Cloud.log