Redis 자료구조 완전 정리 (실무에서 가장 많이 쓰는 구조들)

이전 글에서는 Redis 캐시가 무엇이고 왜 필요한지에 대해 정리했습니다.

이번 글에서는 Redis를 강력하게 만드는 핵심 요소인 “자료구조”에 대해 알아보겠습니다 ✨

많은 사람들이 Redis를 단순한 캐시 서버라고 생각하지만 실제로 Redis는 “자료구조 서버(Data Structure Server)”라고 불릴 정도로 다양한 구조를 제공합니다.

그리고 이 자료구조들을 잘 활용하면 복잡한 기능도 매우 간단하게 구현할 수 있습니다.

 

그리고 본격적으로 설명하기전에 이 글을 쓸 때 참고하게 된 유튜브 강의 2개를 추천하고 정리를 시작해 보겠습니다 

https://youtu.be/92NizoBL4uA?si=uy_yYhhKpZneuRas

https://youtu.be/mPB2CZiAkKM?si=AUZUIpTufkLPY_I_

---

Redis 자료구조를 알아야 하는 이유

예를 들어 이런 기능을 구현한다고 가정해 봅시다

• 로그인 토큰 저장
• 메시지 큐 처리
• 사용자 프로필 캐싱
• 친구 목록 관리

이러한 기능을 구현하려고 했을 때 Redis를 사용하지 않는다면 일반적으로

DB 테이블 설계,트랜잭션 처리, 동시성 처리, 인덱스 설계까지 고민을 해야 합니다

 

하지만 Redis에서는 자료구조 하나 선택하는 것 만으로 해결되는 경우가 많습니다 

 

Redis의 자료구조는 다음 그림과 같이 엄청 많지만, 이제 이 자료구조를  간단하게 라도 하나하나 정리해 보겠습니다

 

---

String - 가장 기본적인 자료 구조 

String은 Redis에서 가장 많이 사용하는 구조입니다. 특징은 단순한 Key-Value 형태로 데이터를 저장합니다.

String의 기본 사용법은 다음과 같습니다 

 

기본 사용법

기본 사용법 (단일)

• Set <key> <value>
• Get <key>

기본 사용법 (멀티)

• mset <key1> <value1> <key2> <value2> ….. <keyN> <valueN>
• mget <key1> <key2> <key3> … <keyN>

예를 들어 

SET token:123 abcdefg 
GET token:123

 

처럼 인증 토큰을 저장할 수도 있습니다 

 

 

String - 사용 사례 

로그인 토큰 저장

SET token:user123 abcdefg EX 3600

 

 

• Key → token
• Value → 실제 토큰값
• EX → TTL 설정

 

조회수 / 좋아요 수 증가 

Redis는 숫자 증가 연산을 매우 빠르게 처리합니다.

redis> SET score:a 10
"OK"
redis > INCR score:a
(integer) 11
redis > INCRBY score:a 4
(integer) 15

 

INCR post:view:555

 

이 방식은

• DB Lock 없음
• 동시성 문제없음
• 매우 빠른 처리 가능

이라는 장점을 가지고 있습니다 

---

Bitmap — 메모리 절약 카운팅

 

Bitmap은 String의 확장 개념으로 bit 단위로 데이터를 관리하는 구조입니다.

특히 카운팅 할 때 Bitmap을 사용하면 저장공간을 절약할 수 있습니다 

 

 

기본 사용법 

• SETBIT <key>  <bit 자릿수>  <설정값>
• BITCOUNT <key>

 

Bitmap - 사용 사례 

대표적인 Bitmap 사용사례는 방문자 수 카운트입니다

오늘 접속한 유저 수를 알고 싶으면 Key를 오늘 날짜로 해두고 bitmap을 이용하면 편리합니다 

 

유저 ID (unique 한 값)을 사용해 해당 유저가 방문했으면 그 자리의 비트를 1로 설정하면 됩니다

예를 들어 userId = 123 이면 

SETBIT visit:20260320 123 1

 

이렇게 설정하고 BITCOUNT 커맨드를 활용해 방문자 수를 조회하면 됩니다 

 

메모리효율 

• 유저 1명 = 1 bit 임으로 
• 천만 유저 = 약 1.2MB 
• 10 조명 유저 = 1TB

이렇듯 매우 강력한 메모리 절약 효과를 가지고 있습니다 

 

 

주의할 점 

하지만 이 방식은 모든 데이터를 정수로 표현할 수 있어야 합니다

즉 user id와 같은 값이 0 이상의 정수 이상 이어야 , 사용가능하고 그런 값이 없을 때 에는 사용할 수 없습니다.

---

List — Queue 구현에 최적화

List는 순서가 있는 자료구조입니다. 왼쪽 / 오른쪽에서 데이터를 넣고 뺄 수 있습니다

이로 인해 큐로 사용하기 적절합니다 

 

기본사용법

기본 사용법 (insert)

• Lpush <key> <A>
  • Key: (A)
• Rpush <key> <B>
  • Key: (A, B)

 

기본 사용법 (pop)

• Key: (C, A, B, D, A)
• LPOP <key>
  • POP C , Key: (A, B, D, A)
• RPOP <key>
  • Pop A , Key: (A, B, D)

 

 

List - 사용 사례 

List는 메시지 큐로 사용하기 적절합니다

ClientA는 BRPOP 커맨드를 통해 myqueue에서 데이터를 꺼내려 하는데 현재 리스트 안에 데이터가 없어 대기를 하고 있는 상황입니다 

 

 

이때 B가 hi라는 값을 넣어주면 client a가 바로 이 값을 확인할 수 있다

 

List는 자체적으로 Blocking 기능을 제공하기 때문에 이를 적절히 사용하면 불필요한 Polling을 막을 수 있다

특히 LPUSHX / RPUSHX와 같은 커맨드를 사용을 하면 키가 있을 때만 데이터를 저장 가능합니다 

 

이는 다양한 곳에서 사용할 수 있는데 

SNS에는 각 유저별로 타임라인이 존재하고 그 타임라인에 내가 팔로우한 사람들의 데이터가 뜹니다.

각 유저의 타임라인에 보일 게시물을 캐싱하기 위해 Redis의 리스트의 RPUSHX 사용하면 됩니다.

 

이를 이용해서 자주 이용하던 유저의 타임라인에만 새로운 데이터를 캐시 할 수 있고 ,

자주 사용하지 않는 유저는 캐싱 키가 존재하지 않기 때문에 그런 유저들을 위해 데이터를 미리 쌓아놓는 것과 같은 비효율적인 작업을 방지할 수 있습니다

 

---

Hash — 객체 캐싱에 최적

Hash는 하나의 키 안에 또다시 여러 개의 필드와 밸류 쌍으로 데이터를 저장하는 자료 구조입니다 

 

기본 사용법 

• Hmset <key> <subkey1> <value1> <subkey2> <value2> …
• Hgetall <key>  (해당 key의 모든 subkey와 value를 가져옴)
• Hget <key> <subkey>
• Hmget <key> <subkey1> <subkey2> ….. <subkeyN>

 

Hash - 사용 사례 

Hash의 대표적인 사용 사례는 사용자 프로필을 캐싱할 때 사용됩니다 

 

사용자 프로필 캐싱

HMSET user:123 name donguk age 27 job backend

 

조회할 때는

HGET user:123 name

 

이렇게 특정 필드만 가져올 수도 있습니다.

 

---

Set — 중복 없는 데이터 관리

Set은 중복을 허용하지 않는 집합 구조입니다.

이미 존재하는 값은 추가되지 않습니다.

 

기본 사용법

• SADD <key> <value>
  • Value가 이미 있으면 key에 추가 되지 않는다
• SMEMBERS <Key>
  • 모든 value를 돌려준다
• SISMEMBER <key> <value>
  • vlaue 가 존재하면 1 , 없으면 0

 

Set-사용 사례

 

친구 목록

 

• 중복 친구 추가 방지
• 빠른 포함 여부 확인

좋아요 누른 사용자 목록

• 한 사용자가 여러 번 좋아요 못 누르게 가능

---

Sorted Set — 랭킹 시스템의 핵심

Sorted Set은 Redis에서 가장 실무 활용도가 높은 자료구조 중 하나입니다.

기본적으로

값(Value) + 점수(Score)

 

형태로 저장되며 점수 기준으로 자동 정렬됩니다.

 

기본 사용법

• ZADD <Key> <Score> <Value>
  • Value가 이미 key 에 있으면 해당 Score 가 변경 된다
• ZRANGE <Key> <StartIndex> <EndIndex>
  • 해당 Index 범위 값을 모두 돌려줌
  • ZRANGE testKey 0 -1 
    →  모든 범위의 데이터를 가져온다 이때 점수기준으로 자동 정렬되어 결과를 가져옵니다

 

Sorted Set - 사용 사례

랭킹

 

• 점수 기반 정렬
• 상위 N명 조회 가능

ZREVRANGE ranking 0 9

 

 

 

이렇게 TOP 10 조회할 수도 있습니다 

 

인기 게시글 

 

• 조회수 / 좋아요 기반 정렬
• 실시간 인기 콘텐츠 구현 가능

 

주의할 점 

Sorted Set의 Score는 Double 타입입니다.

 따라서 값이 정확하지 않을 수 있습니다. 이는 특히 JavaScript 사용 시 주의해야 합니다 

 

---

HyperLogLogs — 대용량 유니크 카운트

 

굉장히 많은 데이터를 다룰 때 사용하며 , 중복되지 않는 값의 개수를 카운트할 때 사용합니다.

Set과 비슷하지만 다른 점은 대량의 데이터를 다룰 때 더 적절한다는 점입니다 

 

왜냐하면 HyperLogLogs는  저장 되는 값과 상관 없이 모든 값이 12KB로 고정되어 저장 되기 때문입니다

즉 장되는 값이 몇백, 몇천과 상관없이 모두 12KB입니다 

 

대신 한번 저장된 값은 다시 불러올 수 없다

 

기본 사용법

추가

• PFADD visitors ip1 ip2 ip3

조회 

• PFCOUNT visitors

 

HyperLogLogs - 사용 사례

주된 사용처는 우리 사이트에 방문한 IP가 몇 건인지

• 정확한 IP 목록 필요 없음
• 단순 “몇 명 방문했는가”만 중요

 

하루 종일 크롤링한 URL 개수가 몇 개인지

• 수억 개 URL 처리 가능
• 메모리 고정

 

검색엔진에서 검색된 유니크한 단어가 몇 개가 되는지

 

등등 엄청 크고 유니크한 값을 계산할 때 적절합니다 

 

---

Streams — 로그 / 메시징 시스템

 

Stream은 Redis에서 가장 현대적인 자료구조입니다.

특히 Kafka 개념을 많이 차용했습니다.

 

기본 사용법

데이터 저장 

XADD mystream * message hello

 

XADD라는 커맨드를 이용해 mystream이라는 키에 데이터를 저장을 하고 ,

키 이름 옆에 * 는 id 값을 의미하며 직접 지정할 수 있지만 일반적으로* 로 하면 레디스가 알아서 저장하고 id를 반환해 줍니다 

이때 이 반환되는 id 값은 데이터가 저장된 시간을 의미합니다 

 

데이터 조회 

스트림의 데이터를 읽는 방법은 다양한데

• id 값을 이용해 시간 대역대로 저장된 값을 검색할 수 있습니다 
• 또는 실제 서버에서 로그를 읽을 때 tail-f를 사용하는 것처럼 새로 들어온 데이터만 읽을 수 있습니다.
• 또 카프카처럼 소비자 그룹이라는 개념이 존재하기 때문에 원하는 소비자만 특정 데이터를 읽게 할 수 있습니다 

 

Strams - 실제 사용 사례

로그 시스템

• append-only 구조
• 데이터 변경 없음
• 시간 순 조회 가능

메시지 중개인

• Consumer Group 지원
• 특정 worker만 메시지 처리 가능

---

Collections 사용 시 주의할 점 

마지막으로 위에 소개한 자료구조를 사용할 때 꼭 주의해야 할 점을 정리해보겠습니다 

 

우선 하나의 컬렉션에 너무 많은 아이템을 담으면 좋지 않습니다

이후에 정리하겠지만  가능하면 Collection당 10000개 이하 몇천 개 수준으로 유지하는 게 좋습니다 

 

Expire는 Collection의 item 개별로 걸리지 않고 전체 Collection에 대해서만 걸립니다

Redis에서는 Collection 안에 들어가 있는 Item에 Expire (TTL)을 걸 수가 없습니다 

따라서 10000개의 아이템을 가진 Collection에 expire가 걸려있다면 그 시간 후에 10000개의 아이템이 모두 삭제가 됩니다 

보통 10만 개의 아이템을 삭제할 때 보통 1~2초가 걸리게 됩니다 

매우 매우 주의해야 합니다 왜냐면 Redis는 싱글 스레드 이기 때문입니다!

 

---

마무리

이번 글에서는 Redis의 자료구조와 간단한 사용법, 사용처  그리고 주의점을 정리해 봤습니다.

이러한 자료구조를 잘 사용하면 서비스 성능 개선, 시스템 구조 단순화, 개발 생산성까지 향상할 수 있습니다

다음 글에서는 Redis 캐싱 전략, Cache Stampede 문제처럼 중요한 설게 개념을 정리해 보겠습니다