`CacheManager`와 `RedisTemplate` 사이의 키 생성 규칙과 네임스페이스 활용 방식

## `CacheManager`와 `RedisTemplate` 사이의 키 생성 규칙과 네임스페이스 활용 방식

## 1. `CacheManager` (JSR-107 기반 추상화)

스프링 캐시 추상화에서 가장 중요한 것은 네임스페이스(Namespace)를 통한 격리입니다.

- `value` (또는 `cacheNames`): `@Cacheable(value = "grid_schemas")`나 `cacheManager.getCache("grid_schemas")`에서 사용하는 이 값이 바로 네임스페이스가 됩니다.
- 키 생성 규칙 (Redis 기준): 스프링의 `RedisCacheManager`는 관리의 편의를 위해 다음과 같은 규칙으로 최종 키를 만듭니다.
    
    - 최종 키 = `네임스페이스` + `::` + `사용자가 지정한 키`
    - 예: `grid_schemas::user_01`
- 특징:
    - `::`는 스프링이 네임스페이스와 실제 키를 구분하기 위해 사용하는 고유한 구분자(Delimiter)입니다.
    - 개발자가 키 마다 네임스페이스를 일일이 붙이는 수고를 덜어줍니다.

---

## 2. `RedisTemplate` (Low-level 접근)

반면 `RedisTemplate`은 네임스페이스라는 개념을 자동으로 붙여주지 않습니다.

- 키 생성 규칙: 개발자가 문자열로 넘긴 값이 그대로 Redis의 키가 됩니다.
    - 예: `grid:schema:user_01` (개발자가 직접 `:` 를 사용하여 구조화)
- 특징:
    - 스프링 캐시의 규칙(`::`)을 따르지 않기 때문에, `CacheManager` 입장에서는 이 데이터를 자기 식구로 인식하지 못합니다.
    - 세밀한 제어(TTL 각각 부여, 자료구조 직접 선택 등)가 가능하지만, 모든 키 관리 책임이 개발자에게 있습니다.

---

## 3. 왜 문제가 생겼나요?

| 구분 | put / get (Template 방식) | evict (CacheManager 방식) |
| --- | --- | --- |
| 사용한 키 | `grid:schema:DELETE_GRID` | `grid_schemas::DELETE_GRID` |

---

## 4. 요약 및 권장 사항

- JSR-107 표준: `value` 프로퍼티는 캐시의 논리적 그룹(네임스페이스)을 뜻하며, Redis 구현체에서는 이를 `::`와 조합해 물리적 키로 변환합니다. https://docs.spring.io/spring-framework/reference/integration/cache/jsr-107.html
- 일관성 유지:
    - 방법 A: 모든 메서드에서 `RedisTemplate`만 사용한다. (현재 어댑터 구조에 적합)
    - 방법 B: 모든 메서드에 `@Cacheable`, `@CacheEvict` 어노테이션을 사용하여 스프링에게 키 관리를 전적으로 맡긴다.

댓글

이 블로그의 인기 게시물

Session 대신 JWT를 사용하는 이유

스프링 부트 개발자를 위한 유용한 VSCode 설정

5-Step Architecture