Redis 의 여러 역할

Redis 는 인메모리 키-값 저장소로 시작했지만 오늘날에는 캐시·세션·큐·랭킹·분산 락·pub/sub 같은 여러 자리를 한꺼번에 맡습니다.

1. Redis 에 대한 이야기

Redis (REmote DIctionary Server) 는 Salvatore Sanfilippo 가 2009 년에 처음 공개했습니다. C 로 작성됐고 단일 스레드 이벤트 루프 위에서 명령어를 처리합니다. 간결한 프로토콜 (RESP) 과 풍부한 자료구조가 강점으로 자주 거론됩니다.

Redis Stack 은 검색(RediSearch) · JSON · 시계열 · 그래프 · 확률형 자료구조를 묶은 배포 형태입니다.

사건	시기
Redis 첫 공개	2009
Redis Cluster	3.0 (2015)
Redis Streams	5.0 (2018)
Redis 7.0 (Functions, ACL v2)	2022
라이선스 변경 (RSAL/SSPL)	2024-03
Valkey 포크 (Linux Foundation)	2024-03
Redis 8 — AGPLv3 추가	2025

2. 자료구조

Redis 는 키마다 자료구조 타입을 갖습니다.

타입	메모
String	바이너리 안전 문자열. 카운터로도 (INCR).
Hash	필드-값 맵. 한 객체를 한 키에 (HSET user:1 name Alice age 30).
List	양방향 큐 (LPUSH/RPOP). 큐·로그·간단 메시지.
Set	중복 없는 집합. 교집합·합집합 연산.
Sorted Set (ZSet)	점수로 정렬된 집합. 랭킹·우선순위 큐.
Stream	추가 전용 로그. 컨슈머 그룹 지원. Kafka 와 비슷한 역할.
Bitmap	String 위에 비트 연산. 출석·플래그.
HyperLogLog	카디널리티 근사 추정. 메모리 매우 작음 (약 12KB 로 수십억).
Geo	위경도 + 반경 검색 (Sorted Set 기반).

각 타입에 명령어 군이 따라 붙습니다 (HGETALL · ZADD · XADD 등).

3. 캐시로 쓰기

문자열 키에 직렬화된 값과 TTL 을 박아 둡니다.

SET user:42 '{"id":42,"name":"Alice"}' EX 300

cache-aside 패턴은 three-layer-cache 에서 다룹니다.

4. 세션 스토어

웹 서버 인스턴스가 여럿일 때 세션을 한 곳에 모읍니다. SETEX session:<sid> <ttl> <payload> 또는 Hash. 세션 무효화·강제 로그아웃이 손쉽습니다.

5. JWT 블랙리스트와 토큰 회전

JWT 자체는 무상태이지만 사용자 강제 로그아웃이 필요할 때 Redis 의 짧은 TTL 키를 두는 전략이 자주 쓰입니다 (bl:jwt:<jti>). refresh token rotation 도 Redis 에 현재 유효 토큰을 적어 두고 회전 시 옛 키를 무효화하는 방식이 일반적입니다 (security/01-jwt-rotation 에서 다룹니다).

6. Rate limit · 분산 락 · Pub/Sub

Rate limit — INCR + EXPIRE 또는 sorted set 기반 sliding window. 분산 환경에서도 한 곳을 보면 되는 점이 강점입니다.

분산 락 — SET key value NX EX <ttl> 으로 키가 없을 때만 획득합니다. 한계는 노드 장애 시 동시 보유 가능성이 있다는 점입니다. 이 점을 다루는 알고리즘으로 Redlock 이 제안돼 있고 정확성 논쟁이 이어져 왔습니다 (Martin Kleppmann · antirez 의 공개 토론).

Pub/Sub — SUBSCRIBE · PUBLISH. 단순 fire-and-forget. 메시지 영속·재전송이 필요하면 Streams 를 씁니다.

7. 큐로 쓰기

세 갈래의 패턴이 있습니다.

• 단순: List LPUSH / BRPOP.
• 신뢰성: Streams + 컨슈머 그룹 (XREADGROUP · XACK · XPENDING).
• 우선순위: Sorted Set 의 점수를 처리 시각으로 (ZADD · ZRANGEBYSCORE).

큐 전용 시스템 (RabbitMQ · Kafka) 과의 비교는 kafka-when 에서 다룹니다.

8. 키 네이밍 관례

<namespace>:<type>:<id> 같은 콜론 구분 패턴이 사실상 관례입니다.

user:42                # Hash
user:42:sessions       # Set
session:abc123         # String (TTL)
bl:jwt:f9...           # 블랙리스트
ratelimit:ip:1.2.3.4   # 카운터
queue:emails           # List

KEYS * 는 운영에서 위험합니다 (O(n) · 블로킹). 대신 SCAN 을 씁니다.

9. 라이선스 변화와 분기

2024 년 3 월 Redis Inc. 는 BSD 3-Clause 에서 RSAL · SSPL 듀얼 라이선스로 전환을 발표했습니다. 클라우드 사업자가 Redis 를 매니지드 서비스로 재판매하는 흐름을 통제하려는 움직임으로 알려져 있습니다. 2025 년 Redis 8 에서 AGPLv3 가 추가되며 일부 사용 시나리오의 부담은 다시 줄었습니다.

같은 시기 Linux Foundation 산하에서 Valkey 가 포크돼 BSD 3-Clause 를 유지합니다. 주요 클라우드 사업자 (AWS · Google Cloud · Oracle 등) 가 참여한다고 알려져 있습니다. KeyDB 는 멀티스레드를 더한 포크 (2019), Dragonfly 는 동일 프로토콜로 멀티스레드 + 새 자료구조를 표방한 별도 구현 (2022) 입니다.

10. 영속화 · 클러스터 · 메모리 정책

영속화 옵션:

• RDB — 주기적 스냅샷. 큰 메모리 인스턴스에서도 디스크 사용량이 작습니다. 마지막 스냅샷 이후 데이터는 잃을 수 있습니다.
• AOF — 명령 단위 추가 로그. appendfsync 에 따라 손실 가능 범위가 달라집니다.
• 두 가지를 함께 쓰는 hybrid 가 흔합니다.

클러스터·복제:

• 마스터-레플리카 비동기 복제 — 읽기 분산·장애 대비.
• Redis Cluster — 16384 개 슬롯을 노드들이 분담. 키 해시로 위치 결정. 다중 키 명령은 같은 슬롯 안일 때만 동작.
• Sentinel — 비클러스터 환경의 자동 장애 조치.

maxmemory 가 차면 maxmemory-policy 에 따라 키가 evict 됩니다. allkeys-lru · volatile-lru · allkeys-lfu 등. 캐시로만 쓴다면 allkeys-lru 가 자주 선택됩니다.

11. 자주 걸리는 자리

단일 스레드 가정 — 한 명령이 오래 걸리면 다른 명령이 줄을 섭니다. KEYS * · 큰 정렬 · 큰 LRANGE 는 운영에 영향을 줍니다.

TTL 누락 — 캐시로 쓰는 키에 TTL 을 안 두면 메모리가 무한 증가합니다.

클러스터의 다중 키 — MGET k1 k2 k3 가 다른 슬롯에 떨어지면 에러입니다. 같은 슬롯을 강제하려면 {tag} 해시 태그를 씁니다.

Pub/Sub 의 무손실 가정 — 구독자가 잠시 끊기면 메시지가 유실됩니다. 영속이 필요하면 Streams 를 씁니다.

분산 락의 정확성 — 공식 문서도 한계와 가정을 명시합니다. 트랜잭션 의미가 큰 자리에서는 DB 레벨 락 또는 fencing token 을 검토합니다.

하고픈 말

Redis 의 강점은 한 도구로 캐시·세션·큐·락을 다 다룬다는 점입니다. 운영 표면이 작아 작은 팀에 잘 맞습니다. 다만 한 인스턴스에 너무 많은 일을 몰면 단일 장애점이 커지므로 분리 시점을 미리 생각해 둡니다.

Next

• data-pipeline
• kafka-when

Redis 공식 문서 · Redis 자료구조 가이드 · Valkey 공식 · Redis Cluster spec · antirez Redlock · Martin Kleppmann 반론 을 참고합니다.