Redis vs Memcached

캐시를 쓰려고 하면 Memcached,Redis 두 개가 있다.

둘 다 “인메모리 캐시”지만, 성격이 다르다.
실무 기준으로 어떤 걸 언제 쓰면 좋은지만 간단히 정리해보겠다.

 

1. 한 줄 요약

• Memcached
  •  단순 key-value 캐시. 가볍고 빠르다.
  •  그냥 “DB 앞에 두는 캐시”만 필요할 때.
• Redis
  • 인메모리 데이터 스토어. 자료구조, 기능이 매우 많다.
  • 캐시 + 세션 + 토큰 + 랭킹 + 큐 + 락 등 “상태”를 다루고 싶을 때.

 

2. 공통점

• 메모리에 데이터를 올림
• key → value 로 읽기
• DB 앞단에 두고 읽기 부하 줄이는 용도

예를 들어, 상품 상세 조회의 이 패턴까지는 Redis, Memcached 모두 동일하게 가능하다.

1) 캐시에서 product:{id} 조회
2) 있으면 바로 반환
3) 없으면 DB 조회 후 캐시에 저장

 

3. Memcached

특징

• value는 거의 String(바이트 배열)만 쓴다고 보면 된다.
• 지원 연산: get, set, delete, incr/decr 정도.
• 디스크 저장 없음 → 재시작하면 전부 날아감.
• 구조가 단순해서 순수 캐시 성능/메모리 효율은 좋다.

언제 쓰면 괜찮나?

• HTML이나 JSON 응답처럼 렌더링 결과를 통째로 캐시할 때,
  혹은 세션이 날아가도 “다시 로그인하면 그만”인 수준의 아주 단순한 세션 캐시만 필요할 때처럼,
  캐시 이외의 기능을 쓸 일이 거의 없다고 확신되는 상황이라면
  Memcached처럼 진짜 “캐시 전용” 도구를 선택해도 충분하다.

 

4. Redis

특징

Redis는 자료구조가 다양하다.

• String, Hash, List, Set, Sorted Set
• 그리고 Pub/Sub, Stream, Geo, HyperLogLog 등등
• RDB/AOF 같은 persistence 옵션으로 디스크 저장 가능
• 분산 락, 큐, 랭킹, 세션 스토어 등 “상태 관리” 패턴을 구현하기 좋다.

언제 쓰면 괜찮나?

• Redis는 단순히 상품 정보나 메타데이터 같은 캐시뿐 아니라, 세션·토큰 저장, 호출 횟수 카운터/레이트 리밋, 랭킹, 간단한 작업 큐, 분산 락까지 한 번에 처리할 수 있는 “캐시 + 상태 관리”용 도구다. 그래서 처음엔 캐시로만 시작해도, 나중에는 세션·큐·락 요구 때문에 Redis로 확장되는 경우가 많다.

실무에서 자주 쓰는 패턴

• 캐시
  • 상품 정보, 메타데이터 캐시
• 세션 / 토큰
  • session:{id}, access:{token}, refresh:{userId} 형태로 저장
• 카운터 / rate limit
  • INCR + TTL로 유저별 호출 횟수 제한
• 랭킹
  • Sorted Set으로 “오늘 판매 TOP N” 같은 데이터 관리
• 간단한 큐
  • List + RPUSH / BLPOP 으로 작업 큐 구성
• 분산 락
  • SET key value NX PX ... 로 여러 서버에서 공유 락 구현

 

5. 선택 기준

Memcached를 고려할 상황

• 진짜로, 캐시밖에 안 쓴다 는 게 거의 확실함
• value는 문자열/바이트 배열로만 충분
• 장애 시 데이터 날아가도 상관 없음
• 조직이 이미 Memcached 위주로 잘 쓰고 있음

Redis를 고려할 상황 (요즘 대부분 여기에 해당)

• 캐시 + 세션 + 토큰 + 랭킹 + 큐 같은 것들을 같은 스토어에서 처리하고 싶을 때
• 나중에 요구사항이 늘어날 가능성이 높음
• 관리형 Redis(ElastiCache for Redis 등)를 이미 쓰고 있거나, 운영 경험이 있음
• 상품 데이터, member 세션, access/refresh token 같이 로그인/상태 값도 올릴 계획일 때

 

6. 결론

 

단순 캐시만 필요하면 Memcached, 앞으로 이것저것 상태를 다루고 싶으면 Redis.

요즘 백엔드/AI/커머스 서비스들은 대체로 후자에 가깝기 때문에 새로 시작하는 서비스라면 보통 Redis 한 방향으로 통일하는 편이 운영·확장 모두 편하다.