백엔드 데이터 인프라 48편 — Redis 데이터 타입 13종 한 번에 정리

이 글은 백엔드 데이터 인프라 시리즈 130편 중 48편이에요. 47편 에서 Redis 가 인메모리 키-값 저장소이고 자료구조가 13가지나 풍부하다는 큰 그림을 잡았다면, 이번 편에서는 그 13가지가 정확히 무엇이고 어떤 문제에 쓰는지 한 번에 매핑해요.

Redis 데이터 타입이 헷갈리는 이유

13가지나 된다는 사실 자체가 부담스럽게 들리지만, 실제 학습 부담은 두 가지에 압축돼요.

첫째, 이름이 일반 프로그래밍 언어와 비슷한데 미묘하게 다릅니다. Java의 List 와 Redis의 List 는 이름은 같은데 동작이 살짝 달라요. Java List 는 인덱스 접근(list.get(i)) 이 빠른 반면, Redis List 는 링크드 리스트 라 양 끝(LPUSH·RPUSH) 이 빠르고 중간 접근(LINDEX) 은 O(n)이에요. 같은 이름인데 성능 모델이 다르니 Java처럼 쓰면 안 됩니다.

둘째, 이 중에 몇 개는 자주 안 써요. Vector(임베딩 벡터)·Bitfield(비트 단위 정수)·Probabilistic(근사 알고리즘) 같은 타입은 특수 영역(AI·게임·통계) 외에는 거의 안 만질 거예요. 13개를 한꺼번에 외우려면 답이 없지만, 자주 쓰는 6종 + 가끔 쓰는 7종 으로 나눠 보면 학습 부담이 절반 이하로 떨어집니다.

이 글에서는 우선 13종을 한 줄씩 매핑하고, 그다음 자주 6종 과 가끔 7종 으로 묶어요. 자주 쓰는 6종은 49~54편에서 하나씩 깊이 풀어 가니, 여기선 "이 자료구조가 어떤 문제 풀려고 만들어졌나" 까지만 잡으면 충분.

Redis 데이터 타입 13종 — 한 줄씩 매핑

각 타입을 "이건 어떤 문제 푸는 도구인가" 한 줄로 풀어요. 모든 타입은 키 하나 → 값 하나 의 키-값 구조 안에서, 값 자리에 들어가는 자료구조라고 보면 됩니다.

1. String — 가장 기본 타입

값 자리에 단순 문자열(또는 숫자) 하나. 캐시·카운터·세션 같은 가장 흔한 용도가 다 String이에요.

SET user:42:name "Alice"
INCR pv:2026-05-17
SET session:abc123 "{\"uid\":42}" EX 3600

"Redis 처음 시작은 String" 이라고 외워도 됩니다.

2. List — 양 끝이 빠른 큐·스택

양 끝(head·tail) 에 O(1) 으로 넣고 빼는 자료구조. 메시지 큐·최근 활동 기록·작업 대기열에 잘 어울려요.

LPUSH queue:jobs "job-1"
RPOP queue:jobs
LRANGE activity:user42 0 9

Java LinkedList 와 모델이 같은데, Java에서는 잘 안 쓰는 List 가 Redis에서는 핵심 자료구조라는 점이 차이.

3. Hash — 객체 한 개를 통째로

키 하나 안에 field-value 쌍 여러 개. Java HashMap·Python dict 와 같은 모델이에요.

HSET user:42 name "Alice" age 30 email "alice@example.com"
HGET user:42 name
HGETALL user:42

"객체 하나 통째로 캐시" 할 때 String JSON으로 박아도 되지만, Hash로 박으면 필드 한 개만 업데이트 하는 부분 갱신(partial update) 이 됩니다.

4. Set — 중복 없는 컬렉션

값 자리에 중복 없는 문자열 모음. Java HashSet 과 동일 모델. 멤버십 체크·합집합·교집합·차집합이 빠릅니다.

SADD tags:article99 "java" "spring" "tutorial"
SISMEMBER tags:article99 "java"
SINTER tags:article99 tags:user42

"중복 제거" 가 핵심 — 좋아요·태그·읽음 표시 같은 곳에 매번 등장해요.

5. Sorted Set — 점수로 정렬되는 Set

Set 인데 각 멤버에 점수(score) 가 붙어 있어요. 점수 기준으로 자동 정렬. 랭킹·실시간 인기 의 표준 도구.

ZADD leaderboard 1500 "user42"
ZADD leaderboard 2300 "user99"
ZREVRANGE leaderboard 0 9 WITHSCORES   # Top 10

"Top N 뽑기" 가 한 줄로 끝나는 게 Sorted Set의 강점이에요. 직접 구현하려면 꽤 까다로워요.

6. Stream — 추가 전용 로그

이벤트를 시간 순서대로 추가만 하는 로그 구조(Kafka 토픽과 유사). 컨슈머 그룹(Consumer Group, 여러 구독자가 메시지를 분할 소비) 까지 지원해서 경량 메시지 큐 로 쓸 수 있어요.

XADD orders:stream * order_id 1001 amount 50000
XREAD COUNT 10 STREAMS orders:stream 0
XGROUP CREATE orders:stream consumers $

Pub/Sub(발행-구독 메시징) 와 헷갈리는데, Stream은 과거 메시지가 남아 있어 재처리 가능, Pub/Sub은 지금 듣고 있는 사람한테만 전달이라는 차이.

여기까지가 자주 쓰는 6종. 49~54편에서 각각 깊이 풀어 가요.

7. Bitmap — 비트 단위 플래그

String 위에 비트 연산을 얹은 구조. 출석 체크·daily active 같은 사용자 단위 boolean 추적 에 효율적.

SETBIT active:2026-05-17 42 1     # user 42 오늘 접속
BITCOUNT active:2026-05-17        # 오늘 접속자 수

1억 명 사용자도 12.5MB 메모리로 표현 가능. 메모리 절약이 절실한 곳에 등장.

8. Bitfield — 비트 단위 카운터·시계

String 위에 작은 단위 정수 여러 개 를 비트 단위로 묶어 저장(packing). 게임 시계·작은 상태 머신 같은 곳에서 메모리 극도로 절약할 때.

BITFIELD player:42 SET u8 0 10  INCRBY u8 8 1

실무에서 직접 만질 일이 자주 없지만, Redis 가 비트 단위까지 다룬다 는 점은 알아 둘 가치.

9. Geospatial — 위경도 좌표

위치(위도·경도) 를 저장하고 반경 N km 안의 사용자 같은 쿼리. 배달·차량 호출·근처 매장 검색에 적합.

GEOADD locations 127.0276 37.4979 "user42"
GEOSEARCH locations FROMLONLAT 127.03 37.50 BYRADIUS 1 km

PostGIS(PostgreSQL 의 공간 데이터 확장) 같은 정식 GIS DB 정도의 풍부함은 없지만, "근처 N미터" 정도 단순 케이스에는 충분.

10. JSON — Redis 안에서 JSON 1급 처리

RedisJSON(JSON 문서를 다루는 Redis 모듈). 문서를 통째로 저장하고 JSON 경로 로 필드 단위 접근.

JSON.SET doc:42 $ '{"name":"Alice","tags":["java","spring"]}'
JSON.GET doc:42 $.tags
JSON.ARRAPPEND doc:42 $.tags '"redis"'

PostgreSQL JSONB 와 비슷한 영역인데, Redis JSON은 읽기 속도 + 부분 업데이트 가 강점. 74편에서 깊이.

11. Vector — 임베딩 유사도 검색

Redis 8+ 에서 1급 데이터 타입으로. AI 임베딩(예: OpenAI text-embedding-3) 을 저장하고 코사인 유사도 기반으로 가장 유사한 K개 검색.

VADD embeddings:articles "[0.1, 0.3, ...]" VALUES article99
VSEARCH embeddings:articles "[0.12, 0.28, ...]" K 5

RAG(검색 보강 생성) 같은 LLM 응용에서 한창 활발한 영역. 77편에서 풀어요.

12. Time Series — 시간 단위 측정값

타임스탬프 + 숫자 값 쌍을 자연스럽게 다루는 구조. 모니터링·IoT 센서 데이터·주가 같은 시계열에 적합.

TS.ADD temperature:room1 * 23.5
TS.RANGE temperature:room1 - +

InfluxDB·TimescaleDB 같은 정식 시계열 DB 영역인데, 작은 규모 시계열은 Redis Time Series 모듈로 충분. 76편에서 깊이.

13. Probabilistic — 메모리 적게 쓰는 근사 통계

HyperLogLog(고유 개수 추정)·Bloom Filter(존재 여부 추정)·Top-K·Count-Min Sketch 같은 근사 알고리즘 집합. "정확한 답은 아니지만 메모리가 작아도 되는" 경우.

PFADD visitors:2026-05-17 "user42" "user99"
PFCOUNT visitors:2026-05-17     # 고유 방문자 근사
BF.ADD seen:emails "alice@example.com"
BF.EXISTS seen:emails "bob@example.com"

수백만 고유 방문자를 12KB 안에 표현하는 구조. 데이터가 커질수록 차이가 벌어져요.

학습 우선순위 — 자주 6종 + 가끔 7종

여기서 시험 함정이 하나 있어요. "13개를 다 외워야 하나?" — NO. 실제 백엔드 작업에서 90% 이상은 다음 6종에 들어와요.

자주 쓰는 6종 (49~54편)

가끔 쓰는 7종 (74~77편 일부, 나머지는 필요할 때 검색)

처음 Redis를 만지는 사람이라면 String·Hash·Sorted Set 세 가지만 먼저 손에 익혀도 캐시·객체 캐싱·랭킹의 가장 자주 마주치는 세 가지 문제는 풀려요. 나머지는 "필요할 때" 한 번씩 펼쳐 보면 충분.

여기까지 따라오셨다면 한 가지 의문이 들 거예요 — "같은 자료구조처럼 보이는 것들이 있는데?". 정답은 맞아요 — String 으로도 카운터를 만들 수 있고(INCR), Hash 로도 작은 카운터를 박을 수 있고(HINCRBY), Sorted Set 도 점수 자리에 카운터를 박을 수 있어요. 어느 걸 고르냐는 "읽기·쓰기 패턴이 어떤가" 에 달렸어요.

자료구조 선택 — 의사결정 흐름

처음 "내 문제는 어떤 타입에 어울리나" 가 안 잡힐 때, 다음 세 가지 질문을 순서대로 던지면 거의 답이 나와요.

1. 값이 하나인가, 컬렉션인가?
2. 값 하나 → String
3. 컬렉션 → 다음 질문
4. 중복 허용? 순서 의미?
5. 중복 허용 + 순서 의미 (앞·뒤 push) → List
6. 중복 X + 순서 의미 없음 → Set
7. 중복 X + 순서 의미 있음 (점수로 정렬) → Sorted Set
8. 객체(여러 필드) 통째로 저장?
9. 키 하나 안에 필드 여러 개 → Hash
10. 이벤트 로그 (시간순 추가 전용)?
11. 추가만, 재처리 가능 → Stream

이 흐름만 익혀도 자료구조 미스매치는 거의 안 나요. 데이터 모델 설계 가 Redis 활용의 80%이고, 명령어 외우기는 나머지 20% 정도.

한 줄 정리 — 13종 중 자주 6종(String·Hash·List·Set·Sorted Set·Stream) 먼저, 나머지는 필요할 때. 자료구조 선택은 "값이 하나/컬렉션 → 중복/순서 → 객체/이벤트" 흐름으로.

공식 문서: Redis Data Types Overview 에서 13종 전체와 각 타입의 명령어 reference를 확인할 수 있어요.

시험 직전 한 번 더 — Redis 데이터 타입 매칭 함정

• Redis 데이터 타입 = 13종 (String·Hash·List·Set·Sorted Set·Stream + Bitmap·Bitfield·Geo·JSON·Vector·TimeSeries·Probabilistic)
• 자주 쓰는 = 6종 (앞 6개)
• 가끔 쓰는 = 7종 (뒤 7개, 특수 영역)
• 초보자 최소 = String·Hash·Sorted Set 세 가지
• String = 가장 기본, 캐시·카운터·세션
• Hash = 객체 한 개 통째로 (Java HashMap)
• List = 양 끝 빠른 큐·스택 (Java LinkedList, 중간 접근 O(n))
• Set = 중복 없는 컬렉션, 멤버십 체크
• Sorted Set = 점수 정렬, 랭킹의 표준 도구
• Stream = 추가 전용 로그, Kafka 토픽과 비슷
• Stream vs Pub/Sub = Stream은 과거 메시지 남음, Pub/Sub은 지금 듣는 사람만
• Hash vs JSON String = Hash는 필드 단위 업데이트, JSON String은 통째로 read/write
• Bitmap = 비트 플래그, 1억 사용자 12.5MB
• Bitfield = 비트 단위 정수 packing
• Geospatial = 위경도, 근처 N km 단순 검색
• JSON = RedisJSON 모듈, 부분 업데이트 가능 (74편)
• Vector = AI 임베딩, 코사인 유사도 (77편)
• Time Series = 시계열 (76편)
• Probabilistic = HyperLogLog·Bloom Filter, 메모리 절약 근사값
• 자료구조 선택 = 값 하나/컬렉션 → 중복/순서 → 객체/이벤트 3단계
• 데이터 모델 설계가 = Redis 활용의 80%, 명령어 외우기는 20%
• 같은 문제를 여러 타입으로 풀 수 있음 (예: 카운터 = String·Hash·Sorted Set 다 가능)
• 어느 타입 선택은 = 읽기·쓰기 패턴 + 메모리 효율 기준
• 모든 명령어는 단일 스레드 = atomic 자동 보장

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

• 43편 — postgresql.conf 핵심 설정
• 44편 — 사용자·역할 관리 CREATE ROLE GRANT
• 45편 — 데이터베이스 관리 생성·복제·드롭
• 46편 — 백업과 복구 pg_dump·PITR
• 47편 — Redis란 + PostgreSQL과의 역할 분담

다음 글:

• 49편 — Redis String 깊이 + 분산 락 패턴
• 50편 — Redis Hash + 객체 캐싱 패턴
• 51편 — Redis List + 큐·캡 리스트 패턴
• 52편 — Redis Set + 집합 연산 패턴
• 53편 — Redis Sorted Set + 랭킹·Sliding Window Rate Limiter 패턴