🔎 Overview

 이전 포스팅을 통해, 캐시에 대한 이해는 어느정도 가닥이 잡혔다.
 이제 본격적으로 스프링에서 캐시를 사용하기 위해 필요한 개념들을 하나하나 자세하게 살펴보자.

1. Spring Cache 추상화 인터페이스

---

• 스프링은 캐시를 동일한 방식으로 다룰 수 있도록 Cache Abstraction을 제공

1️⃣ Cache

• 캐시 한 덩어리
  • 일반적으로 cacheName 하나
• 핵심 메서드

  메서드	설명
  get(Object key)	키로 조회, 값이 없으면 null 반환. 캐시 hit/miss 판정 가능
  get(Object key, Class<T> type)	타입 지정 조회
  get(Object key, Callable<T> valueLoader)	캐시 미스 시 Callable 실행 후 값 저장. 동시성 제어 핵심.
  put(Object key, Object value)	캐시에 값 저장
  putIfAbsent(Object key, Object value)	이미 값이 없을 때만 저장
  evict(Object key)	특정 키 삭제
  clear()	캐시 전체 삭제

  
  

📌 get(Object key, Callable<T> valueLoader 사용 예시

Cache cache = cacheManager.getCache("user");
User user = cache.get(userId, () -> userRepository.findById(userId));

• 캐시에 "user" 값이 존재하면 즉시 반환
• 존재하지 않으면 Callable 실행
  • 결과를 캐시에 저장 후 반환
• 캐시가 없는 키에 대해 여러 스레드가 동시에 Callable 함수를 실행하지 않도록 동시성 제어 가능
  
  

2️⃣ CacheManager

• 여러 개의 Cache를 관리, 생성, 조회하는 역할
• 핵심 메서드

  메서드	설명
  getCache(String name)	이름으로 Cache 인스턴스 반환
  getCacheNames()	등록된 Cache 이름 목록 반환

  
  
• 구현체 예시
  • CaffeineCacheManager -> JVM 메모리 기반 로컬 캐시
  • RedisCacheManager -> 분산 캐시
  • SimpleCacheManager -> 여러 Cache를 직접 등록 가능
    
    

3️⃣ CacheResolver

• 호출에서 어떤 캐시를 쓸지 결정
• 일반적으로 cacheName으로 찾은 후 반환
• 멀티테넌시, 환경별 캐시, 요청별 캐시 선택 시 커스텀 가능
  • 멀티테넌시 -> 하나의 애플리케이션이나 시스템 인스턴스를 여러 독립 고객(tenant)이 공유하면서도, 각 고객의 데이터와 설정은 격리하는 구조
• 핵심 메서드

  메서드	설명
  Collection<? extends Cache> resolveCaches(CacheOperationInvocationContext<?> context)	호출 컨텍스트에서 캐시 결정

  
  

4️⃣ KeyGenerator

• 캐시 키 생성 정책
• 기본적으로는 메서드 파라미터 기반
• 성능 및 정합성 문제로 인해, 정말 간단한 경우가 아니라면 대부분 커스텀 키 사용
• 사용 예시

  @Override
  public Object generate(Object target, Method method, Object... params) {
  	return method.getName() + "#" + Arrays.deepHashCode(params);
  }

• 메서드 이름 + 파라미터 Hash로 키 생성
• 멀티테넌시, 특정 필드만 Key로 하고 싶을 때 커스텀
  
  

5️⃣ CacheErrorHandler

• 캐시 백엔드(Redis 등) 장애 발생 시의 동작 정의
• 기본적으로는 예외를 던짐
• 캐시 장애 시 DB 조회로 폴백하는 방식으로 주로 커스텀

  메서드	설명
  handleCacheGetError(RuntimeException exception, Cache cache, Object key)	get 시 예외 처리
  handleCachePutError(RuntimeException exception, Cache cache, Object key, Object value)	put 시 예외 처리
  handleCacheEvictError(RuntimeException exception, Cache cache, Object key)	evict 시 예외 처리
  handleCacheClearError(RuntimeException exception, Cache cache)	clear 시 예외 처리

  
  
• 사용 예시

  @Override
  public void handleCacheGetError(RuntimeException exception, Cache cache, Object key) {
  	log.error("Redis 에러: DB 폴백", exception);
  	// DB 조회
  }

  
  

2. @EnableCaching

---

• 내부적으로 CachingConfigurationSelector 를 통해 캐시 인프라 구성을 import하여 어노테이션 기반 캐싱 활성화
• 기본적으로 Proxy 기반이므로, 주의할 점 존재
  • Self-Invocation -> 같은 클래스 내부에서 내부 메서드 호출 시, 프록시를 거치지 않으므로 캐시 미동작

    public class CacheMain {
         @Cacheable("user")
         public User getUser(Long id) { ... }
         
         public User getUser2(Long id) {
         	return getUser(id);	// 내부 호출, 프록시를 안 거침 -> 캐시 미적용
         }
    }

  • final/private 메서드 -> 프록시가 가로채지 못하는 경우가 많음
    
    

🌊호출 흐름

• @Cacheable 기준, 호출 흐름

클라이언트 요청
    ↓
Service (프록시)
    ↓ (Advisor / Interceptor 가로채기)
CacheInterceptor
    ├─ CacheOperation 조회 (OperationSource)
    ├─ CacheManager로 Cache 조회
    ├─ Cache Hit → 바로 반환
    └─ Cache Miss → 실제 Service 메서드 실행 → 결과 캐시에 저장 → 반환

• 메서드 호출이 비즈니스 서비스 로직에 도달하기 이전, CacheInterceptor가 먼저 Hit/Miss 체크 수행
  
  

🫘 인프라 빈 관점

• 프록시 기반 캐시는 스프링 내부에서 다음과 같은 구조로 이해 가능

  구성 요소	역할
  Advisor	어떤 메서드에 캐시 어드바이스를 적용할지 결정 ( @Cacheable , @CachePut , @CacheEvict 등 )
  Interceptor (=Advice)	실제 캐시 동작 수행 ( CacheInterceptor )
  OperationSource	@Cacheable 등의 어노테이션을 CacheOperation 객체로 변환 -> 캐시 동작 정의 생성
  CacheManager / KeyGenerator / CacheResolver / ErrorHandler	실제 캐시 조회, 키 생성, 선택, 예외 처리 등을 담당

  
  

1️⃣ Advisor

• AOP에서는 어떤 시점에 어떤 Advice를 적용할지 결정
• 스프링 캐시에서는 CacheOperationSource, CacheInterceptor를 묶어서 Advice로 등록
• 메서드에 @Cacheable 이 있으면 CacheInterceptor 실행을 알려주는 중간 관리자 역할
  
  

2️⃣ OperationSource

• @Cacheable , @CachePut , @CacheEvict 같은 어노테이션을 내부적으로 CacheOperation 객체로 변환
• 다음과 같은 코드를

  @Cacheable(value = "users", key = "#id")
  public User find(Long id)

  다음과 같은 구조로 변환

  CacheOperation:
   - cacheName: users
   - key: #id
   - condition: null
   - unless: null

• 어노테이션을 기계가 이해할 수 있는 메타데이터로 바꿔주는 역할
  
  

3️⃣ Interceptor

• 실제 캐시 로직 수행자
• 동작 흐름

  1. 캐시 키 생성
   2. CacheManager에서 캐시 가져오기
   3. 캐시에 값이 있는지 체크
     → 있으면 바로 반환 (메서드 미실행)
     → 없으면 실제 메서드 실행
   4. 결과를 캐시에 저장
   5. 반환

  
  

3. 스프링 캐시 어노테이션

---

1️⃣ @Cacheable

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@Reflective
public @interface Cacheable {

	// cacheNames: 사용할 캐시 이름들 지정
    String[] cacheNames() default {};
    // value: cacheNames와 동일.cacheNames의 별칭
    String[] value() default {};
    
    // key: 캐시 키를 SpEL로 지정
    String key() default "";
    
    // keyGenerator: KeyGenerator 빈 이름 지정
    String keyGenerator() default "";
    
    // cacheManager: CacheManager 빈 이름 지정(Resolver 대신 직접 지정하는 느낌)
    String cacheManager() default "";
    
    // cacheResolver: CacheResolver 빈 이름 지정(여러 캐시에서 동적 선택 시)
    String cacheResolver() default "";
    
    // condition: 캐시 적용 여부(SpEL). true일 때만 캐시 로직 동작
    String condition() default "";
    
    // unless: 캐시 저장 여부(SpEL). true면 put 스킵
    // 일반적으로 '결과 기반'으로 평가
    String unless() default "";
    
    // sync: stampede 방지용 동기화 모드(같은 key에 대한 동시 로딩 방지)
    boolean sync() default false;
}

• 조회 캐싱의 기본
  • 캐시에 값이 있으면 메서드 실행 없이 캐시 값을 반환하고, 없으면 메서드 실행 후 캐시에 저장
• cacheNames
  • 사실상 데이터 구조 및 정책 단위
  • TTL, size, serializer를 cacheName별로 다르게 주는 게 일반적
• key
  • 키를 SpEL로 직접 만들면 강력하지만, 문자열 키를 남발하게 되어 충돌 가능성과 관리 난이도 증가
  • 일반적으로 '규칙화된 prefix + 식별자' 정도만 SpEL로 사용
    • 복잡해지면 KeyGenerator 구현
• condition
  • 사전 조건
  • 일반적으로 메서드 실행 전 평가
  • true 일 때만 캐시 로직 적용
  • false 면 캐시 무시 후 메서드 호출
• unless
  • 사후 거부 조건(veto)
  • 메서드 실행 후 평가
  • 반환값( #result )을 보고 캐싱하지 않을 결과 결정
  • true 일 시 캐시에 저장하지 않음
• sync=true
  • Stampede 방지에 매우 중요
  • 캐시 구현체가 동시 로딩을 잘 지원해야 좋은 효과 발휘
  • 모든 기능과 조합 시 제약이 생길 수 있어, 핵심 키 몇 개에만 제한적으로 적용하는 경우가 많음
    • unless 와는 같이 사용 불가능
    
    

2️⃣ @CachePut

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@Reflective
public @interface CachePut {
	String[] cacheNames() default {};
    String[] value() default {};
    String key() default "";
    String keyGenerator() default "";
    String cacheManager() default "";
    String cacheResolver() default "";
    String condition() default "";
    String unless() default "";
}

• 항상 메서드 실행 후 캐시 갱신
  • 쓰기 후 캐시 갱신을 메서드와 묶을 때 유용
• DB 트랜잭션과의 순서 및 실패를 조심해야 함
  • 안정성 측면에서 @CacheEvict 가 더 선호되기도 함
    
    

3️⃣ @CacheEvict

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@Reflective
public @interface CacheEvict {
	String[] cacheNames() default {};
    String[] value() default {};
    String key() default "";
    String keyGenerator() default "";
    String cacheManager() default "";
    String cacheResolver() default "";
    String condition() default "";
    
    // allEntries=true 시, 해당 캐시의 모든 엔트리 drop
    boolean allEntries() default false;
    
    // beforeInvocation=true 시 메서드 실행 전에 evict
    // 따라서, 메서드가 예외를 던져도 evict 수행
    boolean beforeInvocation() default false;
}

• 메서드 실행 전/후에 캐시 항목 제거(무효화)
• allEntries=true 는 매우 위험할 수 있으므로, 정말 필요할 때만 사용
• beforeInvocation=true 는 실패하더라도 반드시 캐시를 무효화해야 하는 상황에만 사용
  
  

4️⃣ @Caching

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@Reflective
public @interface Caching {
	Cacheable[] cacheable() default {};
    CachePut[] put() default {};
    CacheEvict[] evict() default {};
}

• 여러 캐시 동작을 한 메서드에 조합
• 1번 업데이트에서
  • A 캐시는 evict
  • B 캐시는 put
  • 둘을 동시에 해야되는 상황 같은 때 사용
    
    

5️⃣ @CacheConfig

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface CacheConfig {
	String[] cacheNames() default {};
	String keyGenerator() default "";
	String cacheManager() default "";
	String cacheResolver() default "";
}

• 클래스 레벨 기본값
  • 클래스에 공통 설정(cacheNames, keyGenerator, cacheManager, cacheResovler ...)을 걸어 중복 제거
• @CacheConfig 만 붙인다고 캐시가 켜지는 게 아니고, 오직 기본값만 제공
• 코드 예시

  @CacheConfig(cacheNames = "user", keyGenerator = "userKeyGenerator")
  public class UserService {
     @Cacheable	// 메서드별 적용
     public User get(long id) { ... }
  }

  
  

4. SpEL과 평가 컨텍스트

---

• 스프링 캐시 어노테이션은 SpEL을 사용해 다음을 제어 가능
  • key: 캐시 키를 어떻게 만들 것인가
  • condition: 캐시 동작을 적용할 것인가 (사전 조건)
  • unless: 결과를 보고, 캐시 저장을 거부할 것인가 (사후 거부 조건)
    
    

🔭 어노테이션별 평가 시점 차이

1️⃣ @Cacheable 평가 순서

• 코드

  @Cacheable(
     cacheNames = "items",
     key = "#id",
     condition = "#id > 0",		// (1) 먼저 평가
     unless = "#result == null"	// (2) 메서드 실행 후 평가
  )
  public Product find(long id) {
  	return productRepository.findById(id).orElse(null);
  }

• Cache Hit인 경우
  • 메서드 비호출
  • 따라서 #result 자체가 없음
  • 즉, unless 는 Cache Hit 판단 조건에서 제외
    
    

2️⃣ @CachePut 평가 순서

• 코드

  @CachePut(
     cacheNames = "products",
     key = "#result.id",				// 생성 후 id 생기는 경우 유용
     condition = "#result != null",	// 결과 기반 condition 가능
     unless = "#result.delete == true"	// 결과에 따라 캐시 put 거부
  )
  public Product updateProduct(ProductUpdateDto response) {
  	return productService.update(response);
  }

• @CachePut 은 메서드가 항상 실행
• condition , unless 모두 사용 및 제어 가능
• @CachePut 에서는 condition 또한 메서드 호출 후 평가되며, 여기서 #result 참조 또한 가능
  
  

3️⃣ @CacheEvict 평가 순서

• 코드 ( beforeInvocation = false )

  @CacheEvict(cacheNames = "products", key = "#id")
  public void deleteProduct(Long id) {
  	productRepository.deleteById(id);	// 성공 후 evict
  }

  • 메서드 성공 후 무효화
  • #result 사용 가능

• 코드 ( beforeInvocation = true )

  @CacheEvict(cacheNames = "products", key = "#id", beforeInvocation = true)
  public void deleteProduct(Long id) {
  	productRepository.deleteById(id);	// 실행 전 evict
  }

  • 메서드 실행 전 무효화
  • 아직 결과가 없기 때문에 #result 사용 불가
    
    

🔖 자주 사용되는 값

1. #root.methodName

• 호출된 메서드 이름

  key = "#root.methodName + ':' + #id"

  
  

2. #root.method

• 호출된 메서드

  key = "#root.method.name + ':' + #id"

  
  

3. #root.target

• 대상 객체 (빈 인스턴스)

  key = "#root.targetClass.simpleName + ':' + #id"

  
  

4. #root.targetClass

• 대상 클래스

  key = "#root.targetClass.name + ':' + #id"

  
  

5. #root.args

• 인자 배열

  key = "#root.args[0]"

  
  

6. #root.caches

• 현재 적용 대상 캐시 컬렉션

  key = "#root.caches[0].name + ':' + #id"

  
  

7. 파라미터 이름 기반 참조 ( #id , #request.userId )

key = "#id"
 key = "#request.userId + ':' + #request.page"

• -parameters 컴파일 옵션 필요
  
  

8. 인덱스 기반 참조 ( #a0 , #p0 , #root.args[0] )

• 파라미터 이름을 못 가져오는 상황에서도 안전한 방식
• 스프링 공식 문서에 따르면, 파라미터 이름이 없을 시 #a0 , #p0 같은 인덱스 접근을 쓰라고 안내
  - Spring Cache 공식 문서

  key = "#a0"		// 첫 번째 인자
   key = "#p1"		// 두 번째 인자

  
  

9. #result

• 메서드 결과값
• @Cacheable : unless 에서 사용 가능
• @CachePut : key , condition , unless 에서 결과 기반으로 사용 가능
• @CacheEvict : beforeInvocation=false 일 때 사용 가능
  
  

📒 코드 예시

1️⃣ 입력 조건 + null 결과 제외

@Service
@RequiredArgsConstructor
public class ProductService {

	private final ProductRepository productRepository;

	/ **
      * id가 0 이하면 캐시 미사용 (condition)
      * 조회 결과가 null이면 캐시에 미저장 (unless)
      */
    @Cacheable(
    	cacheNames = "products",
        key = "#id",
        condition = "#id != null && #id > 0",
        unless = "#result == null"
    )
    public Product findById(Long id) {
    	// 캐시 miss일 때만 실행
        return findByIdFromDb(id);
    }
    
    private Product findByIdFromDb(Long id) {
    	return productRepository.findById(id).orElse(null);
    }
}

2️⃣ 검색 캐시 (문자열 정규화 + 페이지 제한)

@Service
@RequiredArgsConstructor
public class ProductSearchService {

	private final ProductSearchRepository productSearchRepository;

	/**
     * 검색 캐시는 폭발하기 쉬움
     * page가 너무 크면 캐시 제외 (condition)
     * 결과가 비어있으면 캐시 저장 제외 (unless)
     * keyword는 trim과 lowercase로 키 정규화
     */
	@Cacheable(
    	cacheNames = "searchProducts",
        key = "'keyword=' + #keyword.trim().toLowerCase() + ':page=' + #page + ':size=' + #size",
        condition = "#page >= 0 && #page < 20 && #size <= 100",
        unless = "#result == null || #result.isEmpty()"
    )
    public List<Product> searchProduct(String keyword, int page, int size) {
    	return searchProductFromDb(keyword, page, size);
    }
    
    private List<Product> searchProductFromDb(String keyword, int page, int size) {
    	return productSearchRepository.search(keyword, page, size);
    }
}

3️⃣ @CachePut에서 결과 기반 키/조건 사용

@Service
@RequiredArgsConstructor
public class ProudctService {

	private final ProductRepository productRepository;

	/**
     * @CachePut은 항상 메서드 실행
     * 저장/수정 후 반환된 결과(result)를 기준으로 캐시에 저장
     */
	@CachePut(
    	cacheNames = "products",
        key = "#result.id",				// 결과 id 값으로 키 추출
        condition = "#result != null",	// 결과가 있어야만 put
        unless = "#result.notSale"		// notSale 상태면 put 금지
    )
    public Product save(ProductCreateDto request) {
    	return saveProduct(request);
    }
    
    private Product saveProduct(ProductCreateDto request) {
    	return productRepository.save(request.id, request.notSale);
    }
}

4️⃣ @CacheEvict - beforeInvocation 차이

@Service
@RequiredArgsConstructor
public class ProductService {
	
    private final ProductRepository productRepository;
	
    /**
     * 기본값 (beforeInvocation = false)
     * 메서드가 성공해야만 그 후에 캐시 제거
     * 예외 발생 시 캐시가 삭제되지 않음
       - 트랜잭션 롤백 가능성이 존재할 때, 일관성 측면에서 더 안전한 편
     */
    @CacheEvict(cacheNames = "products", key = "#id")
    public void deleteProduct(Long id) {
    	deleteProductFromDb(id);
    }
    
    /**
     * beforeInvocation = false
     * 메서드 호출 전, 미리 캐시 제거
     * 예외가 발생하더라도 그 전에 캐시는 제거된 상태
     */
    @CacheEvict(cacheNames = "products", key = "#id", beforeInvocation = true)
    public void deleteProductForce(Long id) {
    	deleteProductFromDb(id);
    }
    
    private void deleteProductFromDb(Long id) {
    	productRepository.delete(id);
    }
}

5. 키 설계

---

캐시는 "같은 키면 같은 값" 이라는 강한 가정을 전제로 동작

• 키가 잘못되면 아래와 같은 문제 발생 가능

  1. 잘못된 데이터 반환(오염): 서로 다른 요청이 같은 키로 매핑(충돌)
  2. 정보 누출: 권한/테넌트별 결과가 다름에도, 키에 scope가 없어서 남의 데이터 노출 가능
  3. 캐시 무용지물: 동일 요청임에도 키가 계속 달라져 Cache Miss 발생
  4. 운영 통제 불가: 키의 prefix나 버전이 없으면 롤백/배포 때 전체 캐시를 제거해야 함
  
  

📌 키 설계 규칙

1. 짧고 결정적

• 같은 입력이면 항상 같은 키
• 리스트 검색에서, 리스트 파라미터가 있으면 정규화 필수
  • 정렬, 중복 제거, 공백 제거 및 소문자 통일
• 키 정규화 예시:
  • 입력

    [solo, male]
     [male, solo]

  • 정규화

    [male, solo]

  • 정규화된 키

    games:tags=male,solo

    
    

2. 충돌 방지

• 결과를 바꾸는 모든 요소는 키에 포함
  • 아닐 시 오염 발생
• 필드가 결과에 영향을 주는지 항상 체크
  • page, pageSize, orderBy 등
    
    

3. 버전

• 캐시는 스키마나 응답, 직렬화 방식이 바뀌면, 이전 캐시가 틀린 값이 될 가능성 존재
  • 캐시는 원본 DB가 아닌 복제본
  • 버전 업데이트 배포 후, 같은 요청의 응답 구조가 달라질 수 있음
• 버저닝을 통해서 이를 관리 가능
  • playon:v2:partyDetail:{partyId}
• 장점
  • 배포 직후 이전 캐시의 자동 무효화
• 단점
  • 배포 직후 Cold Start 문제 발생
  • 이는 TTL 조절, 워밍업, 스태거 배포 등의 방법으로 완화 가능
    
    

4. 멀티테넌시/권한/사용자별 결과는 Key Scope로 강제

• 캐시는 기본적으로 같은 키는 같은 값으로 반환
• 테넌시/권한/사용자에 따라 달라 결과가 달라짐에도 같은 키를 사용하면, 다른 사람의 데이터를 그대로 재사용하는 심각한 버그 발생
  • 이는 단순한 캐시 버그를 넘어선 데이터 유출 문제
• 다음과 같은 캐시 스코프를 포함
  • 테넌트별 데이터 분리 : tenantId
  • 권한별 노출 필드 차이 : role
  • 사용자별 결과 차이 : userId
    
    

5. 키 길이 제한 관리

📑 Redis 사용 중이라고 가정

• Redis는 긴 키도 저장 가능하지만, 다음과 같은 문제 발생 가능

1. 네트워크 비용 증가

• Redis는 요청 시마다 키 문자열을 그대로 전송
• QPS가 높을수록 네트워크 트래픽 급격히 증가
  • QPS : 초당 처리 요청 수 ( Query Per Second )

2. 메모리 오버헤드

• Redis는 키 자체도 메모리에 저장
• 키가 길어지면, 특히 필터 검색이 많은 API에서 메모리 낭비 급증

3. 필터 폭발 문제 발생 및 운영 난이도 증가

• 필터 수가 많아질수록 키에 포함되는 디멘전 증가
  • 이로 인해 키 길이 및 캐시 엔트리 수 급증
• 이를 해결하기 위해 필터 정규화 후 해시로 압축하는 방식 주로 사용
  • 반드시 정규화 후 해싱
• SHA-256 알고리즘을 사용하면 낮은 충돌 확률, 고정된 길이 보장 가능
  
  

🔑 키 생성 방식 3단계

🎯 키 설계 규칙을 단계적으로 고도화해가며, 캐시 키 설계 규칙을 확장해보자.

1️⃣ 전역 KeyGenerator

​@Bean
public KeyGenerator globalKeyGenerator() {
	return (target, method, params) ->
    	method.getName() + "::" + Arrays.deepToString(params);
}

• 매우 단순한 형태의 KeyGenerator 구현 방식
• 장점
  • 빠른 구현
  • 직관적인 규칙
    
    

🔎 현재 키 설계 원칙 관점에서는 여러 문제 존재

1. 키가 결정적이지 않음

• 필터에 컬렉션이 포함할 경우, 순서가 매번 변경될 수 있음
  • 같은 의미의 요청임에도 서로 다른 키 생성
  • 이로 인해 Cache Miss 발생 가능성 증가
• DTO의 toString() 포맷 등이 바뀌면 키 변경

2. 충돌을 방지하지 못함

• method.getName() 의 경우, 동일한 메서드명(오버로드 등)으로 인한 충돌 위험 존재
• Arrays.deepToString() 의 경우, 서로 다른 파라미터가 동일한 문자열이 나오는 등 충돌 위험 존재

3. 버전별 캐시 무효화 어려움

• 응답 스키마나 정규화 로직이 변경되면, 잘못된 이전 캐시값 사용 가능

4. 캐시 스코프 누락 가능성 존재

• user, tenant, role 등 캐시 스코프 정보가 파라미터에 포함되지 않으면 키에 미반영
• 이로 인해 잘못된 캐시 재사용이나 정보 누출 위험 발생

5. 키 길이가 길어질 수 있음

• 필터가 많아지면 키가 길어져 네트워크 및 메모리 비용 증가
  
  

2️⃣ 전역 정규화 + 해시로 압축

​@Bean
public KeyGenerator hashKeyGenerator() {
	return (target, method, params) -> {
    	String signature = method.getDeclaringClass().getSimpleName() + "#" + method.getName();
        
        String normalized = Canonicalizer.canonicalize(params);		// 컬렉션 정규화
        String digest = sha256Hex(signature + ":" + normalized);
        
        return signature + ":" + digest;
    }
}

static class Canonicalizer {
	static String canonicalize(Object... params) {
    	if (params == null || params.length == 0) {
        	return "[]";
        }
        
        return Arrays.stream(params)
        			 .map(Canonicalizer::normalize)
                     .collect(Collectors.joining(",", "[", "]"));
    }
    
    // 정규화
    static String normalize(Object p) {
    	if (p == null) {
        	return "null";
        }
        
        if (p instanceof CharSequence s) {
        	return s.toString().trim();
        }
        
        if (p instanceof Number || p instanceof Boolean) {
        	return String.valueOf(p);
        }
        
        if (p instanceof Enum<?> e) {
        	return e.name();
        }
        
        // Map -> key 기준으로 정렬
        if (p instanceof Map<?, ?> m) {
        	return m.entrySet().stream()
            		.map(e -> normalize(e.getKey()) + "=" + normalize(e.getValue()))
                    .sorted()
                    .collect(Collectors.joining("&", "{", "}"));
        }
        
        // Set -> 정렬
        if (p instanceof Set<?> s) {
        	return s.stream()
            		.map(Canonicalizer::normalize)
                    .sorted()
                    .collect(Collectors.joining(",", "S[", "]"));
        }
        
        // List -> 값 순서 유지
        if (p instanceof List<?> l) {
        	return l.stream()
            		.map(Canonicalizer::normalize)
                    .collect(Collectors.joining(",", "L[", "]"));
        }
        
        return p.toString().trim();
    }
}

• 전역 KeyGenerator를 유지하되, 결정적 키 생성과 키 길이 제한 문제 해결
  • 같은 의미면 같은 키 생성
  • 컬렉션 정규화 후 SHA-256 알고리즘을 통해 고정 길이 키 생성
    
    

🔎 여전히 남아있는 문제

1. 도메인별 키 정책 차이

• 일부 List 는 순서 유지 필요, 일부는 정렬 후 키 생성이 효율적일 수 있음
• 기본값 필드는 키에서 제외 가능

2. 캐시 스코프 누락 가능성 존재

• 캐시 스코프 존재 시, 여전히 누락 가능성 존재

3. 버전별 캐시 무효화 어려움

• 전역 KeyGenerator만으로는 특정 캐시 버전 관리 불가능

4. DTO 구조 변경에 따른 문제

• 필드 추가나 포맷 변경 등의 구조 변경 시, 키 변경 가능
• 동일한 의미임에도 불필요한 Cache Miss 발생
  
  

3️⃣ 전역 KeyGenerator 최소화 + 키 중앙 집중화

• 간단한 키는 @CacheConfig + KeyGenerator 방식을 사용
• 복잡한 키의 경우, Prefix 는 Redis 설정으로, 정규화 등의 키 정책은 CacheKeys 로 중앙집중화
• 이를 통해 전역 KeyGenerator 방식의 한계를 해결
  
  

1. Prefix는 RedisCacheConfiguration으로 등록

​@Bean
public RedisCacheConfiguration redisCacheConfiguration() {
	return RedisCacheConfiguration.defaultCacheConfig()
    			.computePrefixWith(cacheName -> "playon:" + cacheName + "::");
}

• Prefix 설정을 통해 캐시 그룹 단위로 분석 및 삭제 가능
• 환경 분리가 필요하다면, Environment를 통해 profile을 받아서 prefix에 추가
  
  

2. CacheNames에 캐시 이름 상수화

​@NoArgsConstructor(access = AccessLevel.PRIVATE)
public final class CacheNames {
    public static final String PARTY_LIST = "partyList";
    public static final String PARTY_DETAIL = "partyDetail";
}

• 사용할 cacheNames들을 중앙 집중적으로 관리 가능
  
  

3. CacheKeys로 도메인별 키 정책을 캐시별로 명시

​@NoArgsConstructor(access = AccessLevel.PRIVATE)
public final class CacheKeys {
	private static final String VERSION = "v1";
    
    public static String partyListKey(
    	int page, int pageSize, String orderBy, boolean isMacSupported, String partyAt,
        Long appId, Collection<String> genres, Collection<String> tags
    ) {
    	// 1. 정규화 진행
        Set<String> g = normalize(genres);
        Set<String> t = normalize(tags);
        
        // 2. 필터 및 디멘전 추가
        String payload =
        	"page=" + page +
            "&size=" + pageSize +
            "&orderBy=" + trim(orderBy) +
            "&mac=" + isMacSupported +
            "&partyAt=" + trim(partyAt) +
            "&appId=" + (appId == null ? "" : appId) +
            "&genres=" + String.join(",", g) +
            "&tags=" + String.join(",", t);
        
        // 3. 해시로 압축
        return VERSION + ":" + sha256Hex(payload);
    }
    
    // 컬렉션 -> 정렬을 통한 정규화
    private static Set<String> normalize(Collection<String> c) {
    	TreeSet<String> ts = new TreeSet<>();
        
        if (c == null) {
        	return ts;
        }
        
        for (String v : c) {
        	String trimV = trim(v);
            
            if (!trimV.isEmpty()) {
            	ts.add(trimV);
            }
        }
        
        return ts;
    }
    
    // SHA-256 알고리즘을 통한 해싱
    private static String sha256Hex(String s) {
    	try {
        	byte[] digest = MessageDigest.getInstance("SHA-256")
            				.digest(s.getBytes(StandardCharsets.UTF_8));
                            
            StringBuilder sb = new StringBuilder(digest.length * 2);
            
            for (byte b : digest) {
            	sb.append(String.format("%02x", b));
            }
            
            return sb.toString();
        } catch (Exception e) {
        	throw new IllegalArgumentException(e);
        }
    }
    
    // 빈 값 체크 및 공백 제거 + 대소문자 통일
    private static String trim(String s) {
    	return s == null ? "" : s.trim().toLowerCase(Locale.ROOT);
    }
}

• 결정성 준수
  • 각 캐시에 맞게 정규화 진행
• 충돌 방지
  • 결과를 바꾸는 필드를 반드시 포함
• 버전 관리
  • 버전 변경 시, 이전 캐시 자동 무효화
• 캐시 스코프
  • 현재 코드에는 추가하지 않았지만, 캐시 스코프 존재 시 필요한 캐시에만 포함
• 키 길이 제한 준수
  • payload가 아무리 길어지더라도, SHA-256 해싱을 통해 고정 길이로 제한
    
    

4. @Cacheable에서 CacheKeys 호출

​@Cacheable(
	cacheNames = CacheNames.PARTY_LIST,
    key = "T(패키지명.CacheKeys).partyListKey(#page, #pageSize, #orderBy, #isMacSupported, #partyAt, #request.appId(), #request.genres(), #request.tags())"
)
public PartyListResponse list(int page, int pageSize, String orderBy, boolean isMacSupported, String partyAt, GetAllPartiesRequest request) {
	// 구현 생략
}

• 캐시를 사용할 메서드에서, 어노테이션의 각 필드에 구현 클래스 사용
• 결과적으로 다음과 같은 키 저장
  • playon:partyList::v1:{sha256hex}