Redis 캐싱과 Spring Boot 연동, 2026년 바뀐 점 직접 경험한 이야기

Redis 캐싱을 Spring Boot 프로젝트에 직접 연동해보면서 꽤 삽질을 했는데요. 특히 2026년 들어서 적용 방법이나 설정에 변화가 있어서 작년과 다른 부분을 따로 챙기지 않으면 당황하기 딱 좋더라고요.

이 글에서는 제가 직접 경험한 Redis와 Spring Boot 연동 과정과 쿼리 최적화, 그리고 2026년 기준 최신 변경점까지 전부 다뤄볼게요. 실제 코드와 실행 결과까지 있으니, 이 글만 보면 Redis 캐싱으로 데이터베이스 부하 줄이는 데 큰 도움이 될 거예요.

개발 환경 / 버전 정보

이번 프로젝트에서 사용한 주요 버전은 Java 17, Spring Boot 3.2, 그리고 Redis 서버는 Redis 7.0을 사용했어요. Redis 클라이언트 라이브러리는 Lettuce 6.2.0 버전으로 맞췄습니다.

Redis 캐싱 Spring Boot 연동 직접 구현해보니 관련 정보

Spring Boot와 Redis 캐싱 이렇게 연동하면 됩니다

사실 이 부분이 가장 간단하면서도, 2026년에 달라진 점이 숨어 있어서 헷갈릴 수 있는데요. Spring Boot 3부터 Redis 캐싱 설정이 기본적으로 spring.cache.type=redis 로 맞춰져서 설정하는 게 좀 달라졌어요. 아래처럼 의존성을 추가하고 간단한 설정만 해주면 바로 캐시를 쓸 수 있거든요.

// build.gradle 예시
implementation 'org.springframework.boot:spring-boot-starter-data-redis'
implementation 'io.lettuce:lettuce-core:6.2.0.RELEASE'

// application.yml
spring:
  cache:
    type: redis
  redis:
    host: localhost
    port: 6379
    timeout: 2000

이렇게 해놓고, 서비스 메서드에 @Cacheable 어노테이션만 붙이면 끝이에요. 제가 테스트했던 예시를 보면, 데이터베이스 쿼리 실행 전에 Redis에서 캐시를 찾는 과정을 거쳐서 DB 부하가 확 줄었어요.

실제 쿼리와 캐싱 동작 예시

여기서 많이 틀리는 게, 캐시 키를 어떻게 관리하느냐인데요. 저는 아래처럼 userId를 키로 잡고 캐시를 적용해봤어요. 덕분에 동일한 userId 요청이 오면 DB 쿼리를 거의 안 하게 되더라고요.

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Cacheable(value = "userCache", key = "#userId")
    public User getUserById(Long userId) {
        System.out.println("DB 쿼리 실행 - userId: " + userId);
        return userRepository.findById(userId).orElse(null);
    }
}

실제 실행해보면, 첫 호출에만 콘솔에 "DB 쿼리 실행" 로그가 뜨고 그다음 호출부터는 캐시에서 바로 결과가 나오는 걸 확인할 수 있어요.

Redis 캐싱 Spring Boot 연동 직접 구현해보니 관련 정보

2026년 바뀐 부분, 꼭 주의해야 해요

작년과 비교해서 가장 달라진 게 Redis 클라이언트 기본 선택과 캐시 TTL 정책이에요. Spring Boot 3부터 Lettuce가 기본으로 선택되고, TTL(Time To Live)을 별도로 지정 안 하면 자동 만료가 안 되는 경우가 있어서, 캐시가 무한정 쌓이는 상황이 발생할 수 있더라고요.

그래서 저는 RedisCacheConfiguration Bean을 직접 만들어 TTL을 지정하는 방식을 썼는데, 이렇게 하지 않으면 캐시가 갱신되지 않아 오래된 데이터가 계속 나올 수 있으니 주의하세요.

@Configuration
public class RedisConfig {

    @Bean
    public RedisCacheConfiguration cacheConfiguration() {
        return RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofMinutes(30)) // 캐시 유효기간 30분
                .disableCachingNullValues();
    }
}

이걸 적용하고 나니 캐시도 주기적으로 갱신되고, 오래된 데이터 걱정이 확 줄었어요.

여기서 삽질했던 부분들

실제로 막혔던 건 Redis 연결 문제였는데요, 2026년 Redis 서버 버전 업그레이드하면서 기본 보안 설정이 강화돼서 인증 없이는 접속이 거부되는 상황이었어요. 에러 메시지가 NOAUTH Authentication required. 이렇게 나오는데 한참 원인을 못 찾았죠.

Caused by: io.lettuce.core.RedisCommandExecutionException: NOAUTH Authentication required.

결국 application.yml에 비밀번호 설정을 추가하니 바로 해결됐는데, 이 부분을 빼먹으면 아무리 코드가 정확해도 Redis 연결 자체가 안 돼서 캐싱이 무용지물이더라고요.

Redis 캐싱 Spring Boot 연동 직접 구현해보니 관련 정보

심화: Redis 캐시 최적화를 위한 팁

캐시 키 네이밍은 일관성 있게, 그리고 너무 복잡하게 만들지 않는 걸 추천해요. 저는 "user::" + userId 형태로 prefix를 붙여 관리하니까 나중에 Redis CLI로 직접 캐시 상태를 점검할 때 훨씬 편하더라고요.

그리고, 중요한 데이터는 캐시 무효화 전략도 신경 써야 하는데, 예를 들어 사용자 정보가 변경될 때 @CacheEvict 어노테이션으로 캐시를 지워줘야 캐시 데이터와 DB 데이터가 어긋나지 않아요.

@CacheEvict(value = "userCache", key = "#user.id")
public void updateUser(User user) {
    userRepository.save(user);
}

이렇게 해줘야 캐시 데이터가 자동으로 삭제되고, 다음 접근 때 최신 DB 데이터를 가져올 수 있어요.

자주 물어보시는 것들

Q. 기존에 Redis 설정한 것과 2026년 버전 차이는 무엇인가요?

A. Redis 클라이언트가 Lettuce로 바뀌면서 기본 연결과 인증 방식, 그리고 캐시 만료 정책 설정이 조금 달라졌어요. 가장 큰 변화는 TTL을 설정하지 않으면 캐시가 무한정 남는 경우가 생긴다는 점인데, 꼭 RedisCacheConfiguration에서 TTL을 지정해주셔야 합니다.

Q. 캐시가 잘 안 먹히는 것 같아요. 어떻게 체크하나요?

A. 일단 콘솔 로그에 @Cacheable이 붙은 메서드에서 DB 쿼리가 몇 번 실행되는지 확인하세요. 캐시가 제대로 먹히면 재호출 시 DB 쿼리가 안 찍힙니다. 그리고 Redis CLI로 직접 키 존재 여부를 확인하는 것도 도움이 돼요.

이렇게 Redis 캐시와 Spring Boot 연동하는 과정과 2026년 최신 변경점들을 담았는데, 직접 코드를 짜보고 실행해보니 확실히 DB 부하가 줄고 응답 속도도 빨라져서 만족스러웠어요. 특히 바뀐 부분을 몰라서 한참 헤맸던 만큼, 이 글이 비슷한 문제로 고민하는 분들께 꽤 현실적인 도움이 될 거라고 생각합니다.

📌 함께 보면 좋은 글

• MySQL 트랜잭션 격리수준 선택하며 겪은 실수와 비교 사례
• MySQL 슬로우 쿼리 잡으면서 알게 된 원인들과 해결 절차