본문 바로가기
Data/In-Memory DB

[인메모리 DB] Redis를 사용하는 이유

Dmori 2026. 1. 26. 19:46

들어가며

백엔드 개발을 하다 보면 Redis라는 이름을 정말 자주 접하게 됩니다. 캐싱, 세션 관리, 실시간 기능 구현 등 다양한 곳에서 활용되는데요. 이번 글에서는 Redis가 무엇인지, 왜 사용하는지, 그리고 실제로 어떻게 활용되는지 정리해보겠습니다.

 

Redis란?

Redis(Remote Dictionary Server)는 오픈소스 인메모리 데이터 구조 저장소입니다.

쉽게 말해, 데이터를 디스크가 아닌 메모리(RAM)에 저장해서 엄청나게 빠른 읽기/쓰기 성능을 제공하는 저장소입니다. 단순한 Key-Value 저장소를 넘어서 다양한 자료구조를 지원하기 때문에 데이터베이스, 캐시, 메시지 브로커 등 여러 용도로 활용됩니다.

 

Redis를 사용하는 이유

1. 압도적인 속도

Redis의 가장 큰 장점은 속도입니다.

저장소  평균 응답 시간
일반 RDB (MySQL 등) 수 ms ~ 수십 ms
Redis 1ms 미만 (마이크로초 단위)

모든 데이터가 메모리에 있기 때문에 디스크 I/O가 발생하지 않습니다. 일반적으로 MySQL 대비 10배 이상 빠르다고 알려져 있습니다.

 

2. 다양한 자료구조 지원

단순 Key-Value를 넘어서 다양한 자료구조를 네이티브로 지원합니다. 실무에서는 String과 Sorted Set이 가장 많이 사용됩니다.

실무에서 자주 쓰는 자료구조

자료구조 설명 활용 예시
String 가장 기본적이고 많이 쓰이는 타입 캐싱, 세션, 토큰 저장소, 카운터
Sorted Set 점수(score)로 자동 정렬되는 Set 랭킹, 리더보드, 최근 검색어, Rate Limiting

String을 많이 쓰는 이유:

  • 단순하고 직관적 (GET/SET)
  • JSON을 직렬화해서 저장하면 거의 모든 데이터 표현 가능
  • TTL 설정이 간편해서 캐싱에 최적
  • INCR/DECR로 원자적 카운터 구현

Sorted Set을 많이 쓰는 이유:

  • score 기반 정렬이 자동으로 유지됨
  • 범위 조회가 O(log N)으로 효율적
  • 랭킹 시스템 구현이 매우 간단
  • 시간 기반 데이터 관리에 유용 (score에 timestamp 활용)

 

그 외 자료구조

자료구조 설명 활용 예시
Hash 필드-값 쌍의 컬렉션 객체 저장 (메모리 효율적)
List 순서가 있는 문자열 컬렉션 최근 본 목록, 큐
Set 중복 없는 문자열 집합 태그, 좋아요한 유저
Stream 로그 형태의 데이터 구조 이벤트 소싱, 메시지 큐

 

3. 싱글 스레드 기반의 안정성

Redis는 싱글 스레드로 동작합니다. 이게 단점처럼 보일 수 있지만, 오히려 장점이 됩니다.

  • 모든 명령이 원자적(Atomic)으로 실행됨
  • Race Condition 걱정 없음
  • 트랜잭션 처리가 단순하고 안정적
  • 사이드 이펙트 최소화

단순 GET/SET은 초당 10만 건 이상 처리 가능합니다.

 

4. 영속성(Persistence) 옵션

인메모리 DB의 치명적인 단점은 서버가 죽으면 데이터가 날아간다는 것입니다. Redis는 이를 보완하기 위해 두 가지 영속성 옵션을 제공합니다.

방식 설명 특징
RDB (Snapshot) 특정 시점의 데이터를 디스크에 저장 복구 빠름, 일부 데이터 손실 가능
AOF (Append Only File) 모든 쓰기 명령을 로그로 기록 데이터 손실 최소화, 파일 크기 큼

두 방식을 조합해서 사용할 수도 있습니다.

 

Redis 주요 활용 사례

1. 캐싱 (Caching)

가장 대표적인 사용 사례입니다. DB 조회 결과를 Redis에 캐싱해두면 동일한 요청에 대해 DB 부하를 줄이고 응답 속도를 크게 개선할 수 있습니다.

[요청] → Redis 확인 → 있으면 바로 반환 (Cache Hit)
                   → 없으면 DB 조회 후 Redis에 저장 (Cache Miss)

적용하면 좋은 경우:

  • 자주 조회되지만 변경이 적은 데이터
  • 복잡한 연산 결과 (추천, 검색 결과 등)
  • API 응답 캐싱

2. 토큰 저장소 (Refresh Token)

JWT 기반 인증에서 Refresh Token 저장소로 Redis가 많이 사용됩니다.

[Access Token] - 짧은 만료 (15분~1시간), 클라이언트 보관
[Refresh Token] - 긴 만료 (7일~30일), Redis에 저장

Redis를 쓰는 이유:

  • Refresh Token은 자주 조회됨 → 빠른 응답 필요
  • TTL 설정으로 만료 시간 관리가 간편
  • 로그아웃 시 즉시 토큰 무효화 가능 (Blacklist)
  • RDB보다 훨씬 빠른 읽기/쓰기
# Refresh Token 저장 (7일 TTL)
SET refresh:user123 "token_value" EX 604800

# 토큰 검증
GET refresh:user123

# 로그아웃 (토큰 삭제)
DEL refresh:user123

3. 세션 저장소 (Session Store)

분산 환경에서 세션을 관리할 때 Redis가 유용합니다.

[서버 A] ←→ [Redis] ←→ [서버 B]
              ↑
         세션 데이터 공유

여러 서버가 동일한 Redis를 바라보면 세션 정보를 공유할 수 있어서, 로드밸런서가 어떤 서버로 요청을 보내도 문제없습니다.

4. 실시간 순위표 (Leaderboard)

Sorted Set을 활용하면 실시간 랭킹 시스템을 쉽게 구현할 수 있습니다.

ZADD leaderboard 1500 "player1"
ZADD leaderboard 2000 "player2"
ZREVRANGE leaderboard 0 9 WITHSCORES  # 상위 10명 조회

점수 업데이트와 순위 조회가 O(log N)으로 매우 효율적입니다.

5. Pub/Sub 메시징

Redis의 Pub/Sub 기능을 활용하면 실시간 메시징 시스템을 구현할 수 있습니다.

[Publisher] → PUBLISH channel message
                        ↓
[Subscriber A] ← 메시지 수신
[Subscriber B] ← 메시지 수신

활용 예시:

  • 실시간 채팅
  • 실시간 알림
  • 이벤트 브로드캐스팅

6. 분산 락 (Distributed Lock)

여러 서버에서 동시에 같은 자원에 접근하는 것을 방지할 때 사용합니다.

SETNX lock:resource "locked"  # 락 획득 시도
EXPIRE lock:resource 30       # 30초 후 자동 해제

 

Redis 사용 시 주의사항

1. 캐시 용도라면 RDB/AOF 비활성화

Redis를 순수 캐시 용도로 사용한다면 RDB/AOF를 끄는 것이 권장됩니다.

# redis.conf
save ""                  # RDB 스냅샷 비활성화
appendonly no            # AOF 비활성화

이유:

  • 캐시 데이터는 원본(DB)에서 다시 가져올 수 있음
  • RDB/AOF 저장 시 fork()가 발생하면서 메모리를 최대 2배까지 사용
  • 디스크 I/O로 인한 순간적인 성능 저하 발생 가능
  • 불필요한 디스크 공간 사용

단, 세션 저장소나 중요한 데이터를 저장하는 경우에는 영속성 설정이 필요합니다.

 

2. 위험한 명령어 비활성화

운영 환경에서는 서비스에 치명적인 영향을 줄 수 있는 명령어들을 반드시 비활성화해야 합니다.

# redis.conf
rename-command KEYS ""
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command SAVE ""
rename-command BGSAVE ""
rename-command DEBUG ""
rename-command CONFIG ""
명령어  위험성
KEYS * O(N) - 전체 키 스캔으로 서비스 블로킹
FLUSHALL/FLUSHDB 전체 데이터 삭제
SAVE 동기 방식 RDB 저장 - 완료될 때까지 블로킹
BGSAVE 비동기지만 fork()로 메모리 급증 가능
DEBUG 디버그 명령어 - 운영 환경에서 불필요
CONFIG 설정 변경 - 보안상 위험

KEYS 대신 SCAN 명령어를 사용하면 커서 기반으로 점진적 조회가 가능합니다.

 

3. 메모리 관리

Redis는 메모리에 데이터를 저장하므로 메모리 용량을 항상 모니터링해야 합니다.

  • maxmemory 설정으로 최대 메모리 제한
  • maxmemory-policy 로 메모리 초과 시 정책 설정 (LRU, LFU 등)

 

4. 인스턴스 분리

큰 메모리 하나보다 작은 메모리 여러 개가 안전합니다.

❌ 24GB Redis 1개
✅ 8GB Redis 3개

fork 시 메모리를 최대 2배까지 사용할 수 있기 때문입니다.

참고 자료

 

마치며

Redis는 단순히 "빠른 캐시"를 넘어서 다양한 기능을 제공하는 강력한 도구입니다. 캐싱, 세션 관리, 실시간 기능 등 적재적소에 활용하면 애플리케이션 성능을 크게 향상시킬 수 있습니다.

다만 인메모리 특성상 메모리 관리와 영속성 설정에 주의가 필요하고, 싱글 스레드 특성을 이해하고 사용해야 합니다.

저작자표시 비영리 변경금지 (새창열림)

티스토리툴바