[Redis] 2. Redis 자료구조 - String, List, Set, Sorted Set, Hash

Redis가 빠르고 유연한 이유는 단순히 인메모리 DB이기 때문만은 아닙니다.
가장 큰 이유는 다양한 자료구조를 최적화된 형태로 제공하기 때문입니다.

이번 글에서는 Redis의 핵심 자료구조 5개를 실무 기준으로 완전히 정리합니다.

✔ Redis 자료구조가 중요한 이유

Redis는 단순 key-value 저장소가 아니라 데이터 타입별 저장 방식이 완전히 다릅니다.
따라서 어떤 자료구조를 선택하느냐에 따라:

• 성능이 10배 이상 차이날 수 있고
• 메모리 사용량이 크게 달라지며
• TTL 처리나 동시성 관리가 달라질 수 있습니다.

그래서 Redis에서는 “자료구조 선택 = 성능 설계” 입니다.

1. String — Redis의 기본이자 가장 많이 쓰는 타입

String은 Redis의 가장 기본 타입이며, 내부적으로는 SDS(Simple Dynamic String) 구조로 관리됩니다.
단순 문자열뿐 아니라 JSON, 숫자, 직렬화된 객체도 저장할 수 있습니다.

📌 주요 명령

SET user:1:name "Autumn"
GET user:1:name
INCR user:count
DECR user:count
STRLEN user:1:name

📌 실무에서 자주 쓰는 패턴

• 로그인 세션 저장
• API Rate Limit 카운팅
• JWT 블랙리스트 저장
• 간단한 캐싱 (JSON 그대로 넣었다 빼는 경우)

⚠ 실무 주의사항

• 대형 JSON을 저장하면 메모리가 급증할 수 있음
• INCR/DECR은 atomic 하므로 동시성 문제 없음
• TTL 설정하지 않으면 캐시로 쓸 때 메모리 누수 발생

2. List — 메시지 큐처럼 사용 가능한 자료구조

Redis List는 양방향 연결 리스트 형태입니다.
실무에서는 큐(Queue)처럼 쓰거나, 최근 기록 저장 같은 용도로 많이 사용합니다.

📌 주요 명령

LPUSH message:queue "Hello"
RPUSH message:queue "World"
LPOP message:queue
RPOP message:queue
LRANGE message:queue 0 10

📌 실무 활용 예

• 실시간 알림 큐
• 로그 최근 N개 저장
• 비동기 작업 처리 큐

⚠ 실무 주의사항

• LRANGE(전체 조회)는 데이터가 많을수록 성능 저하
• 작업 큐 용도이면 Kafka 같은 메시지 브로커가 더 안정적

3. Set — 중복 제거가 필요한 경우 필수

Redis Set은 중복을 허용하지 않는 집합 입니다.
자동 중복 제거 기능 덕분에 실무에서 굉장히 자주 사용됩니다.

📌 주요 명령

SADD online:users 1
SADD online:users 2
SREM online:users 1
SMEMBERS online:users
SCARD online:users

📌 실무 활용 예

• 중복 방지 토큰 저장
• 온라인 유저 리스트
• 좋아요 누른 사용자 목록

⚠ 실무 주의사항

• SMEMBERS는 대량 데이터에서는 위험 (scan 사용 권장)
• Set 연산(SINTER, SUNION)은 데이터 크기 클 때 비용 큼

4. Sorted Set — 랭킹/정렬이 필요한 모든 경우

Sorted Set(ZSet)은 값 + 점수(score) 형태로 저장됩니다.
점수를 기준으로 정렬되기 때문에 랭킹 서비스에서 거의 필수입니다.

📌 주요 명령

ZADD ranking 100 user1
ZADD ranking 250 user2
ZRANGE ranking 0 10 WITHSCORES
ZREVRANGE ranking 0 10 WITHSCORES
ZINCRBY ranking 10 user1

📌 실무 활용 예

• 게임 랭킹
• 인기 검색어
• 게시글 인기 지수
• 가중치 기반 추천 시스템

⚠ 실무 주의사항

• ZSet은 메모리를 많이 사용하므로 TTL 고려 필요
• Top-N 조회는 빠르지만 전체 조회는 비효율적

5. Hash — 객체 저장에 최적화된 타입

Hash는 필드-값으로 구성된 작은 객체 형태입니다.
특히 사용자 정보, 캐싱 데이터 등을 구조적으로 저장할 때 좋습니다.

📌 주요 명령

HSET user:1 name "Autumn"
HSET user:1 age 29
HGET user:1 name
HGETALL user:1

📌 실무 활용 예

• 유저 데이터 캐싱
• 상품 정보 캐싱
• 상태값 저장 (flag, 설정값 등)

⚠ 실무 주의사항

• 필드 수가 매우 많아지면 메모리 급증
• 대규모 객체는 차라리 JSON 문자열로 관리하는 것이 효율적일 때도 있음

6. 언제 어떤 자료구조를 선택할까? (실무 기준)

• 단순 캐시, JSON 저장: String
• 메시지 큐, 최근 N개 로그: List
• 중복 없는 집합: Set
• 랭킹, 정렬, 점수 기반 데이터: Sorted Set
• 유저/상품 객체처럼 필드가 있는 구조: Hash

자료구조 선택은 Redis 활용의 핵심입니다.
잘못 선택하면 성능, 비용, 장애 문제에 직결될 수 있습니다.

📌 이전 글 :
1. Redis란? 캐시 · DB · 메시지 브로커