Redis vs Memcached — 캐시 선택 완벽 가이드

캐시 솔루션을 고를 때 가장 많이 비교하는 두 가지입니다. 결론부터 말하면 대부분의 경우 Redis를 선택하는 게 맞습니다. 그 이유와 Memcached가 유효한 상황을 설명합니다.

한눈에 비교

항목	Redis	Memcached
데이터 구조	String, Hash, List, Set, Sorted Set, Stream 등	String만
영속성	✅ RDB + AOF	❌ 재시작 시 데이터 소멸
복제	✅ Master-Replica	❌
클러스터	✅ Redis Cluster	클라이언트 샤딩
Pub/Sub	✅	❌
트랜잭션	✅ MULTI/EXEC	❌
메모리 효율	보통	✅ 약간 높음
멀티스레드	단일 스레드 (6.0+ 일부 멀티)	✅ 멀티스레드
성능	매우 빠름	매우 빠름
운영 복잡도	보통	낮음

Redis가 압도적으로 선택받는 이유

1. 다양한 데이터 구조

# String — 기본 캐시
SET user:123 '{"name":"홍길동"}' EX 3600

# Hash — 객체 부분 업데이트
HSET user:123 name "홍길동" age 30
HGET user:123 name

# Sorted Set — 실시간 랭킹
ZADD leaderboard 1500 "user:123"
ZREVRANGE leaderboard 0 9 WITHSCORES  # 상위 10명

# List — 최근 본 상품
LPUSH user:123:history "product:456"
LTRIM user:123:history 0 9  # 최근 10개만 유지

# Set — 중복 없는 집합 (좋아요 누른 사용자)
SADD post:789:likes "user:123"
SCARD post:789:likes  # 좋아요 수

Memcached는 String만 지원하므로 위 기능을 모두 직접 구현해야 합니다.

2. 영속성 — 재시작해도 데이터 유지

# redis.conf
# RDB: 주기적 스냅샷
save 900 1      # 900초 내 1건 변경 시 저장
save 300 10     # 300초 내 10건 변경 시 저장

# AOF: 모든 쓰기 명령 로그
appendonly yes
appendfsync everysec

캐시가 날아가도 DB에서 다시 채우면 되므로 영속성이 필수는 아니지만, 세션 데이터나 중요 임시 데이터는 영속성이 있어야 합니다.

3. Pub/Sub — 간단한 메시지 브로커

# Publisher
import redis
r = redis.Redis()
r.publish('notifications', '{"type": "order_complete", "user_id": 123}')

# Subscriber
pubsub = r.pubsub()
pubsub.subscribe('notifications')
for message in pubsub.listen():
    print(message)

Kafka나 RabbitMQ 도입 전 간단한 이벤트 전달에 유용합니다.

Memcached가 유리한 경우

단순 String 캐시 + 멀티스레드 성능

# Memcached — 단순 key-value 캐시
import pymemcache
client = pymemcache.Client(('localhost', 11211))
client.set('user:123', json.dumps(user_data), expire=3600)
result = client.get('user:123')

Memcached가 유효한 상황:

✅ 대용량 단순 캐시 (수백 GB)
✅ 멀티스레드로 CPU 코어를 최대 활용해야 할 때
✅ 운영 단순성이 최우선일 때
✅ 기존 Memcached 인프라가 있을 때

실제로는 이런 경우가 많지 않아서, 현재 신규 프로젝트에서 Memcached를 선택하는 경우는 드뭅니다.

Redis 클러스터 vs 단일 인스턴스

단일 인스턴스:
→ 수십 GB 이하, 단일 서버로 충분
→ 설정 간단

Redis Sentinel (고가용성):
→ Master 장애 시 자동 failover
→ 읽기 부하를 Replica로 분산

Redis Cluster (수평 확장):
→ 수백 GB 이상 데이터
→ 여러 노드에 자동 샤딩
→ 설정 복잡도 증가

캐시 전략 선택

Cache-Aside (Lazy Loading):
→ 대부분의 경우 기본 전략
→ DB 조회 후 캐시에 저장

Write-Through:
→ 쓰기 시 캐시와 DB 동시 업데이트
→ 데이터 일관성 중요할 때

TTL 설정:
→ 모든 캐시에 반드시 TTL 설정
→ 만료 없으면 메모리 무한 증가

결론

신규 프로젝트         → Redis (기능 풍부, 생태계 표준)
단순 캐시만 필요      → Redis (그래도 Redis)
기존 Memcached 있음  → 유지 (성능 문제 없다면 전환 불필요)

다음 단계

이 가이드를 내 서비스에 직접 적용해 보세요.

TestForge 무료 스캔 시작 →