들어가며
Redis를 공부하다 보면 자연스럽게 이런 의문이 생긴다.
"이렇게 빠른데, 그냥 Redis만 쓰면 안 되나?"
결론부터 말하면 — 둘은 경쟁 관계가 아니다. 역할 자체가 근본적으로 다르다.
본 포스팅에서는 왜 두 가지를 함께 쓰는지, 어떤 기준으로 역할을 나누는지를 정리해보겠다.
Redis만으로 안 되는 이유
Redis가 빠른 이유는 단순하다. 모든 데이터를 RAM(메모리)에 올려두기 때문이다.
그런데 그게 동시에 가장 큰 약점이기도 하다.
| 항목 | Redis (In-Memory) | RDBMS (MySQL, PostgreSQL 등) |
|---|---|---|
| 속도 | 서브밀리초 (< 1ms) | 수십 ~ 수백ms |
| 저장 용량 | RAM 크기에 종속 | 사실상 무제한 (디스크) |
| 데이터 영속성 | 기본적으로 휘발성 | 영구 저장 보장 |
| 복잡한 쿼리 | 부적합 (JOIN 없음) | 적합 (SQL 완전 지원) |
| 트랜잭션 | 제한적 | ACID 완전 지원 |
| 비용 | RAM은 상대적으로 비싸다 | 디스크 -> 저렴 |
1. 용량 문제
RAM은 디스크보다 가격이 수십 배 비싸다. 수백 GB, 수 TB에 달하는 비즈니스 데이터를 전부 Redis에 올려두는 건 비용 면에서 현실적이지 않다.
2. 영속성 문제
Redis는 기본적으로 데이터를 메모리에만 보관한다. 서버가 재시작되거나 장애가 발생하면 데이터가 사라질 수 있다. 주문 내역, 회원 정보처럼 절대 잃어서는 안 되는 데이터를 Redis에만 보관하는 건 위험하다.
RDB(Redis Database Backup), AOF(Append-Only File) 같은 영속성 옵션이 존재하긴 하지만, RDBMS의 트랜잭션 보장 수준과는 목적이 다르다. 어디까지나 보조 수단에 가깝다.
3. 복잡한 쿼리 문제
Redis는 Key를 기반으로 데이터를 조회하는 구조다. 여러 테이블을 JOIN하거나, 복잡한 조건으로 필터링하는 SQL 쿼리를 대체하기가 어렵다. 관계형 데이터를 다루는 데는 RDBMS가 압도적으로 유리하다.
두 가지의 역할 분담 원칙
실제 개발 환경에서 가장 보편적으로 통용되는 기준은 다음과 같다.
RDBMS = 진실의 원천 (Source of Truth) → 데이터의 최종 보관소
Redis = 자주 읽히는 데이터의 빠른 접근 레이어 → 성능 최적화 도구한 문장으로 요약하면 이렇다.
"원본 데이터는 DB에, 자주 읽히는 데이터는 Redis에"
실제 요청 흐름 — Cache-Aside 패턴
Redis + RDBMS 조합에서 가장 널리 쓰이는 구조는 Cache-Aside (Lazy Loading) 패턴이다.
[클라이언트 요청]
↓
1. Redis 캐시 확인
↓
┌─────────────────────────────────────────┐
│ Cache Hit → Redis에서 바로 반환 (빠름) │
└─────────────────────────────────────────┘
↓ (데이터가 없을 때 = Cache Miss)
2. RDBMS 조회
↓
3. 조회 결과를 Redis에 저장 (다음 요청을 위해)
↓
4. 클라이언트에 반환- Cache Hit (캐시 적중): Redis에 데이터가 있으면 DB를 거치지 않고 즉시 반환한다.
- Cache Miss (캐시 미스): Redis에 데이터가 없으면 DB에서 가져오고, 이후 요청을 위해 Redis에 저장해둔다.
처음 요청은 DB까지 가지만, 이후 동일한 요청은 Redis가 처리한다. 같은 데이터를 반복적으로 조회하는 서비스일수록 효과가 극적으로 나타난다.
같이 쓰면 얻는 이점
1. DB 부하 감소
인기 상품 목록, 공지사항처럼 자주 조회되는 데이터를 Redis에 캐싱해두면, 수천 번의 동일 요청이 들어와도 DB는 처음 한 번만 처리하면 된다. 실제 개발 환경에서 DB 부하를 70~80% 줄인 사례가 다수 보고될 정도로 효과가 검증된 구조다.
2. 응답 속도 개선
RDBMS 쿼리가 수십~수백ms 걸리는 반면, Redis는 1ms 이하로 응답한다. 트래픽이 집중되는 상황에서 사용자가 체감하는 속도 차이가 크다.
3. 데이터 안전성 유지
영구 저장이 필요한 데이터는 RDBMS가 보관하므로, Redis에 장애가 발생해도 데이터 자체는 잃지 않는다. Redis는 "느려지는 것"을 막아주는 레이어이지, 데이터의 최종 보관소가 아니다.
4. 각 도구의 강점만 조합
Redis의 Sorted Set으로 실시간 랭킹을 처리하고, 해당 유저의 상세 프로필은 RDBMS에서 가져오는 식으로 각 기술의 강점을 상황에 맞게 활용할 수 있다.
직관적인 비유
도서관에 책이 수백만 권 있다고 생각해보자.
사서(RDBMS)한테 매번 같은 책을 꺼내달라고 하면 서고를 왔다갔다 해야 하니 시간이 걸린다. 그래서 인기 있는 책 몇 권은 카운터 바로 앞 진열대(Redis)에 올려두는 것이다.
- 진열대에 있는 책 → 바로 집어간다 (Cache Hit)
- 진열대에 없는 책 → 서고에서 꺼내오고, 다음을 위해 진열대에도 올려둔다 (Cache Miss → Caching)
- 책의 내용이 바뀌면 → 진열대 책도 교체해야 한다 (캐시 무효화, Cache Invalidation)
마지막 포인트인 캐시 무효화(Cache Invalidation) 는 이 구조에서 가장 신경 써야 할 부분이다. DB의 데이터가 변경됐는데 Redis에 오래된 데이터가 남아 있으면 사용자에게 잘못된 정보가 전달될 수 있다. TTL(Time To Live, 데이터 유효 기간)을 적절히 설정하거나, 데이터 변경 시 명시적으로 캐시를 삭제하는 전략이 필요하다.
캐시 무효화(Cache Invalidation)는 컴퓨터 과학에서 가장 어려운 문제 중 하나로 꼽힌다. 이 주제는 이후 캐싱 전략 챕터에서 더 깊이 다루게 된다.
실제 개발 환경에서는..
이론적으로는 깔끔하지만, 실제 개발 환경에는 고려할 점이 더 있다.
레거시 시스템의 현실
많은 기업의 시스템은 처음부터 Redis를 염두에 두고 설계되지 않았다. RDBMS만으로 운영되던 시스템에 Redis를 도입하려면 기존 코드의 조회 로직을 상당 부분 손봐야 한다. 그래서 현장에서는 성능 병목이 실제로 확인된 특정 API나 쿼리부터 Redis를 적용하는 방식으로 점진적으로 도입하는 경우가 많다.
무조건 캐싱이 좋은 건 아니다
실시간으로 정확한 값이 필요한 데이터(예: 재고 수량, 계좌 잔액)는 오히려 캐싱이 독이 될 수 있다. Redis는 "조금 오래된 데이터를 빠르게 보여줘도 괜찮은" 상황에 적합하다. 데이터의 특성을 먼저 파악하고 캐싱 여부를 결정하는 것이 중요하다.
정리
Redis는 RDBMS를 대체하는 것이 아니라, RDBMS의 병목 구간을 앞에서 막아주는 완충재 역할을 한다.
| 질문 | 답 |
|---|---|
| 원본 데이터는 어디에? | RDBMS |
| 자주 읽히는 데이터는? | Redis 캐시 |
| 데이터 변경 시에는? | DB 업데이트 + 캐시 무효화 |
| Redis가 죽으면? | Cache Miss로 DB에서 직접 처리 (서비스 유지됨) |
두 기술을 함께 쓰는 이유는 결국 하나다. 각자 잘하는 것을 맡기는 것. 이 구조를 이해하면, 이후에 배울 캐싱 전략(Cache-Aside, Write-Through, Write-Behind 등)이 훨씬 자연스럽게 읽힌다.
참고 자료
