Redis란 무엇인가? 구조, 동작 원리, Persistence 전략까지 한 번에 정리

Redis, 왜 이렇게 많이 쓰일까? — 빠르다는 말로는 부족한 이야기

몇 년 전, 트래픽이 갑자기 치솟던 서비스를 운영하던 때가 떠오릅니다. 모니터링 대시보드에는 latency 그래프가 들쭉날쭉 튀고 있었고, database CPU 사용량은 거의 천장을 찍고 있었죠. 회의실 공기는 묘하게 건조했고, 다들 말은 없는데 키보드 소리만 유독 크게 들렸습니다.

그때 나온 질문은 단순했어요.

“이거… 당장 어떻게 줄이지?”

그 순간 자연스럽게 후보에 오른 게 바로 Redis였습니다.

아마 이런 검색을 해보셨을지도 모르겠습니다.

• “Redis 왜 빠른가요?”
• “Redis system design에서 어떻게 확장하나요?”
• “Redis를 cache로만 써야 하나요?”

 

이 글에서는 그런 궁금증을 하나씩 풀어보려 합니다. 복잡한 용어 대신, 실제로 시스템을 굴려본 사람의 시선으로요.

 

Redis는 메모리 위에 올려둔 초고속 메모장 같은 존재입니다. 그런데 단순한 메모장이 아니라, 정렬도 하고, 집계도 하고, 순위도 매길 줄 아는 똑똑한 메모장이죠.

 

이 한 줄이 Redis의 본질에 꽤 가깝습니다.

 

Redis란 무엇인가? — 어렵지 않게 이해해보기

 

---

Redis란 무엇인가? — 어렵지 않게 이해해보기

Redis는 Remote Dictionary Server의 약자입니다. 하지만 이름은 잠시 잊어도 괜찮습니다.

핵심은 이겁니다.

• single-threaded 구조로 동작하고
• 데이터를 RAM에 저장하며
• 문자열, 리스트, 해시, set, sorted set, stream 같은 다양한 data structure를 기본으로 제공하는 key-value 저장소라는 점

 

쉽게 비유해볼까요?

책상 위에 모든 자료를 펼쳐두고 일하는 사람을 떠올려보세요. 서랍을 열 필요도 없고, 창고에 갈 필요도 없습니다. 손만 뻗으면 바로 집을 수 있죠. 대신, 한 번에 한 사람의 요청만 차분히 처리합니다.

이게 바로 Redis의 감각입니다.

메모리에 올려둔 상태에서, 순서대로, 정확하게.

 

 

---

single-threaded인데 왜 빠를까?

“single-threaded면 느린 거 아닌가요?”

처음 Redis를 접하면 대부분 이렇게 묻습니다. 저도 그랬고요.

하지만 실제로 운영해보면 생각이 바뀝니다.

Redis는 모든 command를 순차적으로 처리합니다. 덕분에:

• race condition을 걱정할 필요가 없고
• lock을 직접 다룰 일도 거의 없으며
• 동시성 버그에서 비교적 자유롭습니다

 

한 명이 계산대를 맡고 있지만, 손이 엄청 빠른 계산원이라고 생각해보세요. 서로 밀치지도 않고, 계산 순서가 꼬일 일도 없습니다.

Redis 6부터는 I/O thread가 추가되긴 했습니다. 네트워크 처리 성능을 높이기 위한 변화죠. 하지만 실제 command 실행 로직은 여전히 single-threaded입니다.

아이러니하게도, 이 단순함이 안정성을 만듭니다.

 

 

---

Redis가 체감상 “번개처럼” 빠른 이유

 

1. 모든 것이 RAM에 있다

disk와 RAM의 차이는 생각보다 큽니다. 아니, 꽤 압도적입니다.

disk I/O가 필요한 database와 달리, Redis는 기본적으로 메모리에서 바로 읽고 씁니다. 마치 종이 뭉치를 찾으러 창고까지 가는 대신, 책상 위에서 바로 꺼내 보는 느낌이죠.

그래서 latency가 sub-millisecond 수준으로 내려가기도 합니다.

 

2. Pipelining

일반적으로는 command 하나를 보내고, 응답을 받고, 그 다음 command를 보냅니다.

Redis에서는 여러 command를 한 번에 묶어 보내는 pipelining이 가능합니다. 네트워크 round trip을 줄이니 체감 성능이 훨씬 좋아집니다.

한 마디로, 주문을 한 번에 몰아서 하는 셈이죠.

 

3. Atomic operation

INCR 같은 command는 atomic합니다.

여러 client가 동시에 같은 key를 증가시켜도 값이 꼬이지 않습니다. single-threaded 구조 덕분에 자연스럽게 보장되는 특성입니다.

그래서 Redis는 다음과 같은 용도에 잘 어울립니다.

• distributed counter
• rate limiting
• leaderboard
• 실시간 집계

 

 

---

빠름의 대가 — Durability 문제

여기서 반드시 짚고 넘어가야 할 지점이 있습니다.

Redis는 기본적으로 in-memory 시스템입니다.

서버가 내려가면, 메모리에 있던 데이터는 사라질 수 있습니다.

그래서 가장 중요한 질문이 나옵니다.

 

Redis를 source of truth로 쓸 것인가, 아니면 performance layer로만 둘 것인가?

 

대부분의 팀은 Redis를 cache로 사용합니다.

• 중요한 데이터는 database에 저장하고
• Redis에는 빠르게 접근해야 할 데이터만 두는 방식이죠

 

Redis가 죽어도 database에서 다시 채워 넣으면 됩니다.

이 접근이 가장 현실적이고 안전한 패턴입니다.

그렇다고 Redis가 persistence를 전혀 지원하지 않는 건 아닙니다.

 

 

---

Redis Persistence 전략 — RDB와 AOF

 

1. RDB (Snapshot 방식)

RDB는 일정 주기마다 메모리 상태를 snapshot으로 저장합니다.

예를 들어:

• 5분마다 저장
• 특정 write 횟수 이상 발생 시 저장

서버가 재시작되면 마지막 snapshot을 불러옵니다.

단점은 명확합니다.

마지막 snapshot 이후의 데이터는 유실될 수 있습니다.

cache 용도라면 감수할 만하지만, 결제 정보라면 얘기가 달라지겠죠.

 

 

2. AOF (Append-Only File)

AOF는 모든 write operation을 로그 형태로 기록합니다.

재시작 시 해당 로그를 replay하여 데이터를 복구합니다.

설정에 따라 durability 수준이 달라집니다.

• appendfsync everysec → 최대 1초 데이터 유실 가능
• appendfsync always → 가장 안전하지만 성능 저하 가능

 

결국 성능과 안정성 사이의 균형을 어떻게 잡을지의 문제입니다.

그럼에도 불구하고, 많은 시스템에서는 핵심 데이터는 여전히 database에 두고 Redis는 보조 역할로 사용합니다.

이 조합이 꽤 안정적입니다.

 

 

---

Redis 확장 전략 — 한 대에서 여러 대로

 

1단계: 단일 인스턴스

처음에는 대부분 single Redis instance로 시작합니다.

생각보다 많은 트래픽을 감당합니다. 웬만한 서비스 초기 단계에서는 충분합니다.

 

2단계: Read replica 추가

read 트래픽이 늘어나면 replica를 붙입니다.

• primary는 write 담당
• replica는 read 분산 처리

 

primary 장애 시 replica를 승격해 failover할 수도 있습니다.

메모리 사용량은 늘어나지만, 가용성과 read 처리량은 좋아집니다.

 

3단계: Client-side sharding

write 자체가 병목이 되면 shard를 고려해야 합니다.

application에서 key를 hash하여 여러 Redis node에 분산하는 방식입니다.

Ketama 같은 consistent hashing 라이브러리를 사용하면 node 추가/제거 시 전체 key 재배치 부담을 줄일 수 있습니다.

각 node는 독립적으로 동작합니다.

단순하지만 강력한 방식입니다.

 

Redis Cluster는 언제?

Redis Cluster는 자동 sharding과 failover를 제공합니다.

다만 운영 복잡도가 올라갑니다. 디버깅 난이도도 함께요.

그래서 cache 중심 워크로드라면 client-side sharding을 선호하는 팀도 많습니다.

항상 최신 기능이 정답은 아닙니다. 운영 편의성도 중요한 변수니까요.

 

 

---

Redis의 대표적인 활용 사례

 

1. Cache Layer

가장 전형적인 패턴입니다.

1. 먼저 Redis 조회
2. hit이면 바로 반환
3. miss면 database 조회 후 Redis에 저장

 

TTL을 설정해 자동 만료되도록 하고, 메모리 제한과 LRU 같은 eviction policy를 함께 구성합니다.

이 패턴만으로도 database 부하는 눈에 띄게 줄어듭니다.

 

 

2. Distributed Counter

API rate limiting이 필요할 때, INCR와 TTL 조합은 거의 교과서적인 선택입니다.

조금 더 정교한 로직이 필요하면 Lua script를 활용할 수 있습니다.

별도의 coordination 서비스 없이도 꽤 많은 요구사항을 충족합니다.

 

3. Leaderboard (Sorted Set)

sorted set은 점수를 기준으로 자동 정렬됩니다.

• 점수 업데이트
• 상위 N명 조회
• 특정 사용자 순위 조회

 

이 모든 게 효율적으로 가능합니다.

게임 랭킹, 인기 게시물, 판매 순위 등 “Top N” 문제에 최적입니다.

SQL로 구현하면 쿼리가 복잡해지지만, Redis에서는 비교적 간결합니다.

 

 

4. Session Storage

웹 session을 Redis에 저장하면:

• 빠른 조회
• 여러 서버 간 공유
• TTL 기반 자동 만료

 

확장성이 좋은 구조를 만들 수 있습니다.

 

 

5. Real-time 처리

stream, pub/sub 등을 활용해 서비스 간 실시간 이벤트 전달에도 사용됩니다.

가볍지만 민첩한 연결 고리 역할을 합니다.

 

 

---

System Design 관점에서 Redis의 매력

Redis의 진짜 장점은 단순히 빠르다는 데 있지 않습니다.

예측 가능성입니다.

single-threaded execution 덕분에 동작이 비교적 직관적입니다.

data structure가 기본 제공되기 때문에, 복잡한 로직을 애플리케이션 코드나 database query로 억지로 구현할 필요가 줄어듭니다.

확장 방식도 단계적입니다.

• 한 대로 시작하고
• replica를 붙이고
• shard로 나누고
• 필요하면 Redis Cluster를 도입하는 식

 

성장 곡선에 맞춰 구조를 키워갈 수 있습니다.

이 점이 실제 운영에서 굉장히 큰 장점으로 다가옵니다.

 

 

---

가장 중요한 한 문장

Redis는 database를 대체하기 위한 도구가 아닙니다.

성능을 증폭시키는 레이어에 가깝습니다.

이 데이터를 잃어도 되는지, 안 되는지를 먼저 판단하세요.

그 기준이 명확해지면, Redis의 역할도 자연스럽게 정리됩니다.

 

 

---

2026년 기준, 자주 묻는 질문

1. Redis는 왜 multi-threaded가 아닌가요?

single-threaded 구조가 오히려 locking과 race condition을 줄여 예측 가능한 동작을 보장하기 때문입니다.

2. Redis는 database인가요, cache인가요?

둘 다 가능하지만, 대부분은 cache 용도로 사용합니다.

3. 실제 운영에서 얼마나 빠른가요?

sub-millisecond latency를 보이는 경우도 많으며, 초당 수십만~수백만 operation을 처리할 수 있습니다.

4. Redis가 장애 나면 어떻게 되나요?

persistence 설정에 따라 다릅니다. RDB 또는 AOF를 사용하면 일정 수준 복구가 가능합니다.

5. RDB와 AOF 중 무엇을 선택해야 하나요?

유실 허용 범위와 성능 요구사항에 따라 다릅니다. cache 중심이면 RDB만으로도 충분한 경우가 많습니다.

6. Redis Cluster는 필수인가요?

대규모 환경에서 자동 sharding과 failover가 필요할 때 고려합니다. 그렇지 않다면 client-side sharding으로도 충분할 수 있습니다.

7. Rate limiting에 Redis가 적합한가요?

네. INCR와 TTL 조합이 매우 효율적입니다.

8. Write가 많아지면 어떻게 확장하나요?

여러 node로 shard하여 분산합니다.

9. 금융 시스템에도 Redis를 써도 되나요?

가능하지만, 핵심 데이터는 여전히 안정적인 database에 저장하는 것이 일반적입니다.

10. Redis는 수평 확장이 가능한가요?

replica와 sharding을 통해 가능합니다.

 

 

---

마무리하며

Redis는 단순합니다. 그런데 그 단순함이 강력합니다.

명확한 실행 모델, 분명한 trade-off, 단계적인 확장 전략.

이 세 가지를 이해하면 Redis는 더 이상 “빠른 무언가”가 아니라, 설계 의도를 담아 쓰는 도구가 됩니다.

시스템이 커질수록 복잡함은 늘어나지만, Redis는 그 안에서 오히려 구조를 정돈해주는 역할을 합니다.

빠르기 때문만은 아닙니다.

이해하기 쉬워서, 그리고 예측 가능해서 — 오래 쓰이게 되는 겁니다.