[Redis] 어디에 어떻게 써야 진짜 효과 있을까?

DA-IT-DA·2025년 6월 18일

BackendFieldnote Springboot redis redisson 백엔드 분산락 세션관리 실전패턴 인메모리DB 캐시

DIGGING | 파고들고, 정리하고, 내 것으로 만들기

목록 보기

4/11

— 실무에서 자주 쓰는 3가지 패턴 정리

실무에서 Redis를 왜 쓰냐고 묻는다면?
대부분은 캐시 때문이라고 말하겠지만,
사실 Redis는 그 이상으로 다양하게 활용된다.

이 글은 내가 Redis를 공부하면서 정리한 내용을 바탕으로,
실무에서 자주 쓰이는 Redis의 3가지 대표 사용 패턴을 정리한 기록이다.

✅ Redis는 왜 쓰일까?

Redis는 인메모리 기반의 NoSQL 데이터 저장소다.
단순히 "빠르다"는 이유만으로 쓰이지는 않는다.

실제로는 다음과 같은 이유로 선택된다:

디스크 I/O가 없어, 읽기·쓰기 속도가 매우 빠르다
Key-Value 구조로 설계가 단순하다
TTL을 활용한 임시 데이터 처리에 적합하다
다양한 자료구조(List, Set, Hash, Sorted Set 등)를 지원한다

🔍 실무에서 자주 쓰는 3가지 Redis 패턴

1. 세션 저장소 (Session Store)

로그인 상태를 유지해야 하는 경우,
세션 데이터를 Redis에 저장해 여러 서버 간 공유한다.

Spring 환경에서는 spring-session-data-redis를 통해
내장 세션 저장소를 Redis로 대체할 수 있다.

# application.yml 예시
spring:
  session:
    store-type: redis
  redis:
    host: localhost
    port: 6379

✅ JWT와는 달리 서버 상태 기반 인증이므로, 세션 만료/폐기도 용이하다.

2. 캐싱 (Cache Layer)

가장 대표적인 사용 사례.
자주 조회되는 데이터를 Redis에 저장하고,
DB 쿼리 횟수를 줄여 성능을 개선한다.

Spring에서는 @Cacheable, @CacheEvict 등의 애노테이션으로 간단히 적용 가능하다.

@Cacheable(value = "product", key = "#id")
public Product getProductById(Long id) {
    return productRepository.findById(id).orElseThrow();
}

⚠️ 캐시 일관성(Cache Inconsistency) 문제

캐시는 빠르지만 DB 값과 불일치할 가능성이 있다.
예를 들어 상품 가격이 변경되었는데 캐시가 그대로인 경우,
사용자에게 오래된 데이터가 노출될 수 있다.

해결 방법: @CachePut 또는 @CacheEvict로 갱신/삭제 처리하거나,
복잡한 경우엔 Cache-Aside, Write-Through 전략으로 설계 필요.

⏳ TTL 전략 설계 팁

너무 짧으면 Redis도 부하 받음, 너무 길면 오래된 데이터 남음
access마다 TTL을 갱신할지(expireAfterAccess),
고정된 TTL을 유지할지(expireAfterWrite) 선택 필요

3. 분산락 (Distributed Lock)

동시성 이슈가 발생하는 상황(예: 재고 차감, 중복 결제)에선
Redis의 락 기능을 활용한 분산 제어가 유용하다.

가장 기본적인 방식은 SETNX를 이용한 락 구현이다.

SET lock_key unique_token NX PX 3000

혹은 Redisson 라이브러리를 활용하면 더 안정적인 락을 쉽게 구현할 수 있다:

RLock lock = redissonClient.getLock("lock:order:" + orderId);
try {
    boolean available = lock.tryLock(3, 5, TimeUnit.SECONDS);
    if (!available) throw new IllegalStateException("Lock 실패");
    
    // 처리 로직
} finally {
    lock.unlock();
}

✅ 락 해제 시 주의할 점

직접 구현한 경우, 락을 잡은 주체만 해제해야 한다.
그렇지 않으면 다른 사용자의 락을 잘못 해제해 데이터 정합성이 깨질 수 있다.

Redisson은 내부적으로 락 소유자 확인 로직이 포함되어 있어 안전하다.

🧭 언제 Redis를 고려해야 할까?

상황	Redis 적합 여부
DB에 부하가 크고 자주 같은 데이터를 조회함	✅ 캐시로 적합
로그인 서버를 여러 개 두고 세션을 공유해야 함	✅ 세션 저장소로 적합
동시에 동일 자원 접근 시 충돌 우려가 있음	✅ 분산락 활용
트랜잭션 정합성이 가장 중요함	❌ 관계형 DB가 우선
실시간 로그 분석, 랭킹, 알림 큐 등이 필요함	✅ Redis 특화 구조 가능