Spring Cache 심화: Caffeine + Redis 하이브리드 캐시로 API 10배 최적화하는 실전 전략
많은 Spring Boot 애플리케이션은 API 성능을 올리기 위해 Redis 캐시를 도입합니다. 하지만 실제 운영 환경에서는 Redis만으로는 충분하지 않은 경우가 많습니다. 특히 다음과 같은 상황에서는 Redis 캐시가 병목이 되기도 합니다.
■ 초당 수천 건의 읽기 트래픽이 몰릴 때
■ Redis 네트워크 지연으로 API 응답이 느려질 때
■ CPU가 높은 메서드 호출을 캐시해야 할 때
■ 서버 내부에서만 빠르게 캐싱하고 싶을 때
이 문제를 해결하기 위한 최적의 구조가 바로 “로컬 캐시(Caffeine) + 분산 캐시(Redis)” 하이브리드 패턴입니다.
이 글에서는 Spring Cache 기반으로 Caffeine과 Redis를 함께 사용하여 “API 성능을 최대 10배 이상 개선하는 방법”을 실전 중심으로 정리했습니다.

1. 왜 하이브리드 캐시를 사용하는가?
애플리케이션 규모가 커질수록 캐시는 단순히 “Redis를 쓰면 된다” 수준이 아닙니다. 캐시 계층을 나누지 않으면 오히려 다음과 같은 문제가 발생합니다.
■ Redis 지연 = API 전체 지연
■ Redis 비용 증가(트래픽 집중) ■ 모든 서버가 Redis만 바라보며 생성되는 스파이크 로드
■ 서버 로컬에서 가능한 빠른 캐시를 못 쓰는 비효율
즉, 자주 호출되는 데이터는 로컬 캐시에 넣고, 서버 간 일관성이 필요한 데이터는 Redis에 캐시하는 것이 이상적입니다.
이 구조는 아래 그림처럼 동작합니다.
로컬 요청 → Caffeine 캐시 → (미스일 경우) Redis → DB
네트워크 병목을 줄이고 전체 성능을 안정적으로 유지할 수 있습니다.
2. Caffeine 캐시 기본 설정 (로컬)
Caffeine은 Java 생태계에서 가장 성능이 뛰어난 로컬 캐시입니다. Guava Cache의 후계자라고 볼 수 있습니다.
다음은 가장 일반적인 설정입니다.
@Configuration
@EnableCaching
public class CacheConfig {
@Bean
public Caffeine<Object, Object> caffeineSpec() {
return Caffeine.newBuilder()
.maximumSize(10_000)
.expireAfterWrite(10, TimeUnit.MINUTES)
.recordStats();
}
@Bean
public CacheManager caffeineCacheManager(Caffeine<Object, Object> caffeine) {
CaffeineCacheManager cacheManager = new CaffeineCacheManager();
cacheManager.setCaffeine(caffeine);
return cacheManager;
}
}
로컬 메모리를 기반으로 하기 때문에 조회 속도는 Redis보다 압도적으로 빠릅니다.
보통 **수 나노초(ns) 단위**에서 조회가 가능합니다.
3. Redis 캐시 설정 (분산 캐시)
여러 서버에서 동일한 캐시값을 공유하려면 Redis가 필수입니다. Spring Boot에서는 RedisCacheManager로 쉽게 구성할 수 있습니다.
@Bean
public RedisCacheManager redisCacheManager(RedisConnectionFactory cf) {
RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
.entryTtl(Duration.ofMinutes(30));
return RedisCacheManager.builder(cf)
.cacheDefaults(config)
.build();
}
Redis는 네트워크 IO가 필요하기 때문에 조회 속도는 Caffeine보다 느리지만, 서버 간 일관성을 유지하는 데 필수입니다.

4. 하이브리드 캐시 매니저 구성
핵심은 Spring Boot가 지원하는 CompositeCacheManager입니다. 이 매니저는 여러 캐시 매니저를 순서대로 조회하는 기능을 제공합니다.
즉, 다음 순서로 캐시를 조회할 수 있습니다.
1) Caffeine 캐시 먼저 확인 2) 없다면 Redis 조회 3) 그래도 없다면 DB 조회 후 캐시에 저장
아래는 실제 운영에서 가장 많이 사용하는 설정입니다.
@Bean
public CacheManager cacheManager(CaffeineCacheManager caffeine,
RedisCacheManager redis) {
CompositeCacheManager cacheManager =
new CompositeCacheManager(caffeine, redis);
cacheManager.setFallbackToNoOpCache(false);
return cacheManager;
}
이제 @Cacheable을 사용하는 모든 메서드는
“Caffeine → Redis → DB” 순서로 조회하게 됩니다.
이는 트래픽이 많은 서비스에서 매우 큰 장점입니다.
■ Redis 부하 감소 → 비용 절감 ■ API 응답 속도 개선 ■ 네트워크 장애에도 안정적
5. 실전 API 적용 예제 (@Cacheable)
Spring Cache의 기본 예제는 매우 단순합니다. 아래 코드는 하이브리드 캐싱의 효과를 가장 쉽게 테스트할 수 있는 구조입니다.
@Cacheable(cacheNames = "article", key = "#id")
public Article getArticle(Long id) {
// DB 조회 (가정)
return articleRepository.findById(id)
.orElseThrow();
}
동일 API가 1초에 수천 회 호출된다고 해도 Caffeine이 대부분 처리하기 때문에 Redis로 요청이 몰리지 않습니다.
6. 캐시 무효화(@CacheEvict) 전략
캐시가 빠르면 빨라질수록 “무효화 전략”이 중요해집니다.
■ 데이터 변경 시 어떤 캐시를 지울 것인가?
■ 게시글 업데이트 시 Caffeine + Redis 둘 다 삭제되는가?
정답은 Spring Cache가 이미 해결해두었습니다.
@CacheEvict(cacheNames = "article", key = "#id")
public void updateArticle(Long id, ArticleUpdateRequest req) {
// update logic
}
무효화가 실행되면 Caffeine과 Redis 모두 삭제됩니다. 즉, 일관성 문제가 자연스럽게 해결됩니다.
7. 캐시 성능 모니터링 (필수)
Caffeine은 캐시 히트율을 모니터링할 수 있습니다.
caffeine.stats();
Prometheus + Grafana로 캐시 미스율을 시각화하면 DB 부하 감소 효과를 수치로 파악할 수 있습니다.

8. 언제 로컬 + Redis 하이브리드를 선택해야 하나?
다음 조건에 하나라도 해당하면 하이브리드 구조를 강력히 권장합니다.
✔ API 호출이 초당 수백~수천 건
✔ Redis 지연이 서비스 전체에 영향을 준다
✔ 단일 Redis 장애가 서비스 장애로 이어진다
✔ DB 조회 비용이 매우 높다
✔ 서버당 로컬 캐시를 충분히 둘 수 있다
이 조건을 충족하는 대부분의 서비스는 Caffeine + Redis 조합으로 큰 성능 향상을 경험합니다.
실제로 많은 대형 서비스들이 이 구조를 사용합니다.
■ 쿠팡 ■ 배달의민족 ■ 넷플릭스(Spring Cloud 기반) ■ 쇼핑몰/커머스 API
9. 결론: 하이브리드 캐시가 Spring Boot 성능의 핵심이다
Spring Boot 성능 최적화에서 가장 투자 대비 효과가 큰 전략은 바로 캐싱입니다. 그리고 그중에서도 가장 강력한 조합은 Caffeine + Redis 하이브리드 캐시입니다.
이번 글에서 소개한 원칙만 지켜도 API 성능은
평균적으로 3배~10배까지 향상되는 경우가 많습니다.
로컬 캐시(Caffeine)의 빠른 속도 + 분산 캐시(Redis)의 일관성
두 가지 장점을 결합한 구조는 트래픽, 지연, 스파이크 로드에 매우 강한 안정성을 제공합니다.
당신의 서비스가 점점 성장하고 있다면, 지금이 바로 하이브리드 캐시를 도입할 최고의 타이밍입니다.
'Java & Spring' 카테고리의 다른 글
| Spring Cache 고급편: Caffeine + Redis 하이브리드 캐시 아키텍처 실전 가이드 (0) | 2025.12.11 |
|---|---|
| 성능 최적화: @Transactional(readOnly)와 JDBC Fetch 튜닝으로 DB 부하 60% 줄이는 실전 전략 (0) | 2025.12.07 |
| REST API 에러 코드 규격: RFC 7807 Problem Details로 한 번에 정리(Spring Boot 실전) (0) | 2025.10.25 |
| REST API 에러 코드 규격: 문제 상세(Problem Details)로 정리 (0) | 2025.10.18 |
| 리소스 서버 분리 & API Gateway 연동(Spring Cloud Gateway) (0) | 2025.10.15 |