💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

1. 2026년 캐싱 지도 — Redis vs Valkey 분열의 시대

2026년의 인메모리 캐시는 더 이상 "Redis 면 끝" 인 단순한 시장이 아닙니다. 2024년 3월 Redis Ltd. 가 BSD 라이선스를 버리고 RSALv2 / SSPL 듀얼 라이선스로 전환하면서, 클라우드 벤더들이 더 이상 Redis 를 매니지드 서비스로 자유롭게 팔 수 없게 됐고, 그 반발로 Linux Foundation 이 Valkey 라는 포크를 받아들였습니다. 결과적으로 1년 반 만에 캐시 시장은 다섯 갈래로 갈라졌습니다.

- Redis 8 — RSALv2 / SSPL 로 살아남은 본가

- Valkey — Linux Foundation 산하 오픈소스 포크 (AWS / GCP / Oracle / Snap / Alibaba 후원)

- Dragonfly — 멀티 스레드 RESP 호환 신예 (Roman Gershman 창업)

- KeyDB — 멀티 스레드 Redis 포크, Snap 이 인수

- Garnet — Microsoft Research 가 2024년 3월 공개한 .NET 기반 RESP 호환 서버

여기에 Memcached(여전히 단순함), Apache Ignite / Hazelcast / Infinispan(JVM 진영), Aerospike(하이브리드 메모리/디스크), Tarantool(러시아), Skytable(Rust), 그리고 RocksDB 포크인 Speedb 까지 합치면 — 2026년의 캐싱 선택지는 \"무엇을 안 골라도 되나\" 가 더 어려워졌습니다.

이 글은 그 모든 캐시 / KV 스토어를 2026년 5월 기준으로 한 번에 훑는 가이드입니다. 단순 사이드캐시가 필요한 작은 팀부터, 멀티 리전 글로벌 시스템을 짜는 큰 팀까지, 자기에게 맞는 도구를 고르는 지도를 그려 드리는 게 목표입니다.

2. Redis 8 — RSALv2/SSPL 라이선스 변경 이후

Redis Ltd. 는 2024년 3월 20일, Redis 7.4 부터 BSD 3-Clause 를 버리고 Redis Source Available License v2 (RSALv2) 와 Server Side Public License v1 (SSPLv1) 의 듀얼 라이선스로 전환한다고 발표했습니다. 그리고 2025년 5월, BSD 시절의 마지막 분기였던 Valkey 와 충돌을 의식한 듯 Redis 8 을 BSD 가 아닌 AGPLv3 옵션을 더해 발표했습니다 — 즉 비클라우드 사용자는 다시 \"오픈소스\" 로 받을 수 있게 됐지만, 클라우드 벤더가 매니지드로 팔려면 여전히 RSALv2 / SSPL / 상용 라이선스가 필요한 구조입니다.

Redis 8 의 핵심 변화를 빠르게 정리하면 다음과 같습니다.

- 멀티 스레드 I/O 강화 — 기존 단일 스레드 코어는 그대로지만, 네트워크 I/O 와 디스크 I/O 를 별도 스레드 풀로 분리

- Vector Sets 정식 진입 — 임베딩 벡터를 코어에 1급 시민으로 (RediSearch 의 HNSW 보다 가벼움)

- Streams 의 Consumer Group 자동 페일오버 개선

- HyperLogLog, Bitfield, Geo 명령들의 RESP3 응답 정비

- Cluster mode 의 자동 슬롯 리밸런싱 알고리즘 개선

- RedisJSON, RediSearch, RedisTimeSeries, RedisBloom 모듈을 코어에 통합 (단, AGPL 옵션 시 모듈은 별도)

Redis 8 의 라이선스 정책은 결국 \"AWS / GCP / Azure 같은 하이퍼스케일러가 Redis 를 매니지드로 팔지 못하게 막는다\" 가 본질입니다. 일반 개발자는 그대로 도커로 띄워 쓸 수 있지만, EKS 위에서 Redis 를 \"공식 매니지드\" 처럼 SaaS 로 다시 파는 행위는 SSPL 위반이 됩니다.

Redis 8 도커 실행 (개인 / 사내 사용은 자유)

docker run -d --name redis8 \

-p 6379:6379 \

-v redis8-data:/data \

redis:8

벡터 셋 사용 (Redis 8 신규 자료구조)

redis-cli VSET.ADD myset:vectors "doc-1" 0.1 0.2 0.3 0.4

redis-cli VSET.SEARCH myset:vectors VECTOR 0.1 0.2 0.3 0.4 COUNT 10

Redis 8 의 한국어 / 일본어 한국형 운영 환경에서 가장 큰 변화는 Sentinel 의 deprecate 입니다. Redis Ltd. 는 7.x 시절부터 Sentinel 대신 Cluster mode 를 권장했고, 8 부터는 Sentinel 코드 자체가 \"maintenance only\" 모드로 들어갑니다. 카카오, 토스 같이 Sentinel 기반 HA 를 운영하던 곳은 Cluster mode 마이그레이션이 2026년 가장 큰 인프라 작업 중 하나가 됐습니다.

3. Valkey — Linux Foundation Redis fork (2024.3)

Valkey 는 Redis 라이선스 변경 발표 후 단 8일 만에 출범한 Linux Foundation 산하 포크입니다. AWS, Google Cloud, Oracle, Snap, Alibaba, Verizon, Ericsson 등이 주요 후원사로 참여하며, 사실상 \"하이퍼스케일러 연합의 Redis 백업\" 으로 자리잡았습니다.

Valkey 의 핵심 약속.

- BSD 3-Clause 라이선스 — 영구적, 변경 불가

- Redis 7.2.4 코드 베이스에서 분기 (RESP2 / RESP3 호환)

- 거버넌스는 LF 의 기술 위원회 (TSC) 가 결정

- AWS, Google, Oracle 의 코어 엔지니어들이 메인 컨트리뷰터

2025년 4월 Valkey 8.0 이 발표됐고, 2026년 5월 기준 Valkey 8.1 이 stable. Valkey 의 핵심 차별화 포인트는 다음과 같습니다.

- 멀티 스레드 I/O 가 기본 — Redis 8 보다 도입이 빠름

- Per-key 락 (key-level locking) 으로 핫키 분산 처리 향상

- RDMA(원격 직접 메모리 액세스) 기반 클러스터 통신 옵션

- Asynchronous replication 의 reliability 개선

- VKEYS 라는 새 자료구조 (벡터 검색, Redis 의 Vector Sets 와 별개 구현)

AWS 는 2024년 말부터 Elasticache for Valkey 를 정식 출시했고, 같은 시점 \"기존 Elasticache for Redis 보다 33% 저렴\" 이라는 가격표를 내걸었습니다. GCP 의 MemoryStore 도 2025년 중반부터 Valkey 옵션을 제공합니다.

Valkey 도커 실행

docker run -d --name valkey \

-p 6379:6379 \

-v valkey-data:/data \

valkey/valkey:8.1

Redis-cli 가 그대로 동작 (RESP 호환)

redis-cli -h localhost SET key1 "Valkey value"

redis-cli -h localhost GET key1

→ "Valkey value"

기존 Redis 클라이언트(redis-py, ioredis, lettuce, jedis, go-redis) 는 코드 변경 없이 Valkey 에 붙습니다. 마이그레이션 비용이 낮은 게 Valkey 의 최대 강점입니다.

4. KeyDB — Snap 인수

KeyDB 는 2019년 EQ Alpha Technology 가 만든 멀티 스레드 Redis 포크입니다. 코어 자체는 Redis 와 동일한 자료구조 / 명령을 지원하지만, 멀티 스레드 이벤트 루프로 단일 호스트에서 더 많은 코어를 사용할 수 있게 한 게 차별점이었습니다.

2022년 1월 Snap (Snapchat 모회사) 이 EQ Alpha 를 인수했고, KeyDB 는 Snap 의 내부 캐시 인프라로 흡수됐습니다. 한동안 \"진짜 죽은 거 아니냐\" 는 우려가 있었지만, 2024년 Snap 이 KeyDB 코드 베이스의 일부를 Valkey 에 기여하면서 다시 활성화됐습니다.

KeyDB 의 차별화.

- Multi-threading — 단일 인스턴스가 여러 코어 사용

- Active-Active replication — 양방향 동기 (Multi-master)

- FLASH 모드 — RocksDB 백엔드로 메모리 일부를 SSD 로 오프로드

- Subkey expiration — Hash 필드별 TTL 지정 가능

KeyDB 도커

docker run -d --name keydb \

-p 6379:6379 \

-e KEYDB_THREADS=4 \

eqalpha/keydb

Active-Active 양방향 동기 설정 (개념)

keydb-cli REPLICAOF 192.168.1.10 6379

keydb-cli REPLICAOF 192.168.1.11 6379

양쪽이 서로의 replica 가 되어 양방향 동기

2026년 시점에서 KeyDB 의 위치는 애매합니다. 단일 호스트 멀티 스레드는 Dragonfly 가 더 빠르고, Active-Active 는 Redis Enterprise 의 CRDT 가 더 안정적이고, Snap 의 적극적 마케팅도 끊긴 상태입니다. 그래도 기존 KeyDB 사용자가 \"라이선스 걱정 없이 멀티 스레드 Redis 를 쓰고 싶다\" 면 KeyDB 7.x 는 여전히 매력적인 선택지입니다.

5. Dragonfly — 멀티 스레드 경쟁자

Dragonfly 는 2022년 5월 Roman Gershman (前 Google 엔지니어) 이 공개한 RESP 호환 인메모리 데이터스토어입니다. \"Redis 보다 25배 빠르다\" 는 벤치마크로 화제가 됐고, 2026년 현재 캐시 진영에서 가장 빠르게 성장하는 신예입니다.

Dragonfly 의 핵심 차별화는 진짜 멀티 스레드 아키텍처입니다. Redis 는 단일 스레드 이벤트 루프, KeyDB / Valkey 는 \"멀티 스레드 I/O + 단일 스레드 코어\" 인데, Dragonfly 는 코어 자체가 shard-per-thread 구조입니다. 즉 8 코어 머신에서 8개의 독립적인 샤드가 같은 프로세스 안에서 동작합니다.

기술적 차별화.

- Shard-per-thread — 한 코어가 한 샤드의 모든 키를 소유

- Threadsafe IO — io_uring 기반 비동기 I/O

- Memory-efficient — Redis 대비 메모리 사용량 30~50% 절감 (LRU + 압축)

- Snapshot — fork-less BGSAVE (Redis 의 fork() 폭탄 회피)

- BulSearch / Vector search 내장

Dragonfly 도커

docker run -d --name dragonfly \

--ulimit memlock=-1 \

-p 6379:6379 \

docker.dragonflydb.io/dragonflydb/dragonfly

Redis 와 동일한 클라이언트 사용

redis-cli SET large_key "value"

redis-cli MEMORY USAGE large_key

→ Dragonfly 는 Redis 보다 작게 표시

Dragonfly 의 license 는 BSL 1.1 (Business Source License) 입니다. 즉 4년 후 Apache 2.0 으로 자동 전환되지만, 그 전에는 \"Dragonfly 와 경쟁하는 SaaS\" 로는 못 씁니다. 일반 개발자 / 사내 운영자는 무료로 사용 가능합니다.

Dragonfly Inc. 는 Dragonfly Cloud (매니지드 서비스) 와 Dragonfly Swarm (멀티 노드 클러스터) 을 상용으로 팔고 있고, 2024 ~ 2025년 사이 시리즈 B 펀딩까지 받았습니다.

6. Memcached — 여전히 간단함

Memcached 는 2003년 Brad Fitzpatrick 이 LiveJournal 을 위해 만든 최초의 분산 인메모리 캐시입니다. 23년이 지난 2026년에도 살아있고, 일부 영역에서는 여전히 1순위입니다.

Memcached 가 살아남은 이유는 단순함입니다.

- 키 / 값만 저장 (자료구조 없음 — Hash / List / Set 모두 클라이언트에서 직렬화)

- LRU 정책으로 자동 eviction

- Multi-thread 가 기본 (Redis 보다 먼저)

- 영구화 없음 — 재시작 시 데이터 손실 (의도된 선택)

- Slab allocator — 메모리 단편화 회피

Memcached 도커 실행 (단순한 캐시)

docker run -d --name memcached \

-p 11211:11211 \

memcached:1.6 \

-m 512 \

-t 4

telnet 으로 직접 접근 (단순한 텍스트 프로토콜)

telnet localhost 11211

> set hello 0 60 5

> world

> STORED

> get hello

> VALUE hello 0 5

> world

> END

Facebook, Twitter (구), Pinterest 같은 거대 웹 서비스들이 Memcached 를 \"순수 캐시\" 로 사용합니다. Redis 의 자료구조 / 영구화 / 트랜잭션이 필요 없는 상황에서는 Memcached 가 더 가볍고 빠릅니다.

2026년 한국 사례로는 네이버 검색의 일부 캐시 계층 (검색 키워드 → 결과 ID) 이 여전히 Memcached 위에서 돌아갑니다. 일본에서는 LINE 메신저 일부 백엔드, Yahoo Japan 검색이 Memcached 를 사용합니다.

7. Garnet (Microsoft, 2024.3) — .NET 기반 RESP 호환

Garnet 은 Microsoft Research 가 2024년 3월 18일 깜짝 공개한 .NET 기반 RESP 호환 인메모리 데이터스토어입니다. 그리고 가장 충격적인 부분은 \"Redis 대비 단일 노드 처리량 100~900% 향상\" 이라는 벤치마크였습니다.

Garnet 의 핵심.

- .NET 8 / 9 기반 — C# 으로 작성됨 (Garbage collector 위에서 작동)

- RESP2 / RESP3 호환 — Redis 클라이언트가 그대로 붙음

- Tsavorite KV store — Microsoft 의 자체 KV 엔진 (FASTER 의 후계)

- Pub/Sub, Streams, Cluster mode 지원

- 멀티 스레드 + Lock-free 자료구조

Garnet 도커

docker run -d --name garnet \

-p 6379:6379 \

ghcr.io/microsoft/garnet

Redis-cli 가 그대로 동작

redis-cli PING

→ PONG

redis-cli SET hello "Garnet"

redis-cli GET hello

→ "Garnet"

Garnet 의 특이점은 \"GC 위에서 도는 .NET 캐시가 C 로 짠 Redis 보다 빠를 수 있다\" 는 증명입니다. Microsoft 가 Tsavorite KV (이전 FASTER) 를 수년간 다듬어 온 결과로, 멀티 코어 환경에서 lock-free 큐 / hash 가 큰 차이를 만듭니다.

라이선스는 MIT — Apache 2.0 / BSD 진영의 가장 자유로운 모델입니다. 즉 클라우드 벤더가 Garnet 을 매니지드로 팔아도 됩니다. Azure 는 \"Garnet for Azure Cache\" 미리보기를 2025년 말에 공개했습니다.

단점은 .NET 의존성입니다. 운영자가 .NET 런타임을 잘 모르면 GC 튜닝 / 메모리 프로파일링이 어렵습니다. 그래서 \"Garnet 은 .NET 회사가 쓰기 좋다\" 가 현재 시장의 일반론입니다.

8. Apache Ignite / Hazelcast / Infinispan — JVM 진영

JVM 진영에는 인메모리 \"데이터 그리드\" 라는 별개 카테고리가 있습니다. Redis 처럼 단순한 KV 가 아니라, SQL 쿼리 / 트랜잭션 / Compute / 머신러닝 추론까지 함께 처리하는 큰 통합 플랫폼입니다.

Apache Ignite

Apache Foundation 의 인메모리 데이터 그리드 + 컴퓨팅 플랫폼. SQL ANSI-99 호환, 분산 트랜잭션, 머신러닝 모듈, 그리고 디스크 영구화 (Native Persistence) 까지 지원합니다.

// Java 에서 Ignite 클러스터에 접근

Ignite ignite = Ignition.start();

IgniteCache cache = ignite.cache("orders");

cache.put("order:1", new Order(...));

// SQL 도 그대로

SqlFieldsQuery query = new SqlFieldsQuery(

"SELECT id, amount FROM Order WHERE customerId = ? LIMIT 100");

List rows = cache.query(query.setArgs(42)).getAll();

Apache Ignite 는 2026년 현재 GridGain 의 상용 디스트리뷰션이 메인 채널입니다. 미국 항공 / 금융 / 헬스케어 같은 규제 산업에서 인메모리 SQL 그리드로 활발히 쓰입니다.

Hazelcast

상용 인메모리 데이터 그리드의 대표 주자. Java / Node / Python / C++ 클라이언트, Jet (스트림 처리), Hazelcast IMDG / Hazelcast Platform 등 풀 스택을 제공합니다.

- 분산 Map / Queue / Set / Lock / Semaphore

- Compute Grid — 분산 작업 실행

- Jet — Stream Processing (Apache Flink 와 유사)

- Hazelcast Mancenter — 클러스터 모니터링 / 관리

Infinispan (Red Hat)

Red Hat 의 오픈소스 인메모리 데이터 그리드. JBoss / Quarkus / Wildfly 와의 통합이 강점이고, JCache (JSR 107) 표준 구현체입니다.

JVM 진영의 도구들은 \"단순 캐시\" 가 아니라 \"인메모리 데이터 플랫폼\" 입니다. JVM 위에서 일하는 큰 엔터프라이즈 (은행, 보험, 통신, 공공) 가 주요 고객입니다.

9. Aerospike — 하이브리드 메모리/디스크

Aerospike 는 \"인덱스는 RAM, 데이터는 SSD\" 라는 하이브리드 모델로 유명한 분산 KV 스토어입니다. Redis 처럼 모든 데이터를 RAM 에 올리지 않고, NVMe SSD 의 랜덤 액세스 성능에 의존해 매우 큰 데이터셋을 다룹니다.

핵심 차별화.

- Hybrid Memory Architecture — 인덱스만 RAM, 값은 SSD 직접 액세스

- Strong consistency 옵션 (Aerospike SC)

- Cross-datacenter Replication (XDR)

- Aerospike Vector Search — 2024년 추가

- TPS — 단일 클러스터에서 백만 TPS 이상 검증

Aerospike 도커

docker run -d --name aerospike \

-p 3000-3002:3000-3002 \

aerospike/aerospike-server

Python 클라이언트

python3 << EOF

client = aerospike.client({'hosts': [('localhost', 3000)]}).connect()

key = ('test', 'demo', 'foo')

client.put(key, {'name': 'Alice', 'age': 30})

(key, meta, bins) = client.get(key)

print(bins)

EOF

Aerospike 의 주요 고객은 광고 기술 (AppLovin, Criteo, Trade Desk), 금융 (PayPal, Wells Fargo), 게임 (King, Riot Games) 입니다. \"단일 인스턴스에 100억 키, 1ms 응답\" 같은 시나리오에서 강합니다.

2026년 현재 Aerospike 8.0 이 stable 이고, 벡터 검색 / 그래프 / 시계열 기능을 통합한 \"Multi-model database\" 로 포지셔닝하고 있습니다.

10. Tarantool — 러시아 출신 인메모리 DB

Tarantool 은 2010년 Russian Mail.ru (지금 VK) 이 만든 인메모리 데이터베이스입니다. 단순한 캐시가 아니라 Lua 기반 stored procedure, SQL, 영구화, 클러스터링까지 통합된 풀 스택 DB 입니다.

- In-memory + WAL — 메모리에 두지만 디스크에 영구화

- Lua 기반 stored procedure — 백엔드 비즈니스 로직 임베드

- SQL (Tarantool SQL) + NoSQL (tuples)

- Vinyl engine — LSM 트리 기반 디스크 엔진 (대용량용)

- Cluster — Cartridge 프레임워크로 클러스터 운영

-- Tarantool 에서 Space 정의 + 데이터 삽입 (Lua)

box.cfg{ listen = 3301 }

s = box.schema.space.create('users', {

format = { {name='id', type='unsigned'}, {name='name', type='string'} }

})

s:create_index('primary', { parts = {'id'} })

s:insert{1, 'Alice'}

s:insert{2, 'Bob'}

print(s:get{1})

-- → [1, 'Alice']

러시아 / 동유럽에서는 Tarantool 이 Redis 대안으로 활발히 쓰이고, 일본에서는 NTT 가 5G Core Network 의 세션 저장소로 Tarantool 을 채택한 사례가 유명합니다. 한국에서는 거의 안 보이지만, 글로벌 시장 (특히 통신 / 게임) 에는 깊은 사용자 베이스가 있습니다.

2022년 이후 러시아 IT 의 국제 제재 영향으로 핵심 개발팀이 분리되어 \"Picodata\" 라는 새 프로젝트로 분기됐고, 두 갈래로 발전 중입니다.

11. AWS Elasticache vs MemoryDB vs Valkey 옵션

AWS 의 인메모리 캐시 / KV 서비스는 2026년 시점에서 세 갈래로 나뉘어 있습니다. 어떤 걸 골라야 하는지 표로 정리하면.

| 서비스 | 라이선스 | 영구화 | 가격 | 사용 시나리오 |

|--------|----------|---------|------|---------------|

MemoryDB 는 \"Redis 호환 인터페이스를 가진 영구 KV DB\" 입니다. Multi-AZ WAL 로 데이터 손실 0 을 보장하지만, 대신 가격이 Elasticache 의 3 ~ 4배입니다. 즉, Elasticache 는 \"DB 앞의 캐시\", MemoryDB 는 \"DB 그 자체\" 라는 포지션입니다.

AWS CLI 로 Elasticache for Valkey 클러스터 생성

aws elasticache create-cache-cluster \

--cache-cluster-id my-valkey \

--engine valkey \

--engine-version 8.1 \

--cache-node-type cache.t4g.small \

--num-cache-nodes 1

MemoryDB for Valkey 클러스터 (영구 + Multi-AZ)

aws memorydb create-cluster \

--cluster-name my-memorydb \

--engine valkey \

--node-type db.t4g.small \

--num-shards 1 \

--num-replicas-per-shard 2

2026년 5월 기준 AWS 의 권장 사항은 \"새 프로젝트는 Valkey 부터 시작하고, 기존 Redis 와이어 호환만 필요하면 Elasticache for Valkey, Multi-AZ 영구화가 필요하면 MemoryDB for Valkey\" 입니다. 라이선스 변경의 충격이 가격표에 그대로 반영된 셈입니다.

12. Skytable / Speedb — Rust + RocksDB fork

\"차세대 후보\" 로 분류되는 두 프로젝트가 2026년 주목받고 있습니다.

Skytable

Skytable 은 Rust 로 작성된 BSL 라이선스 NoSQL 데이터베이스입니다. RESP / Skyhash 두 가지 프로토콜 지원, SQL 비슷한 BlueQL 쿼리 언어, 그리고 \"행 기반 + 키-값 하이브리드\" 모델입니다.

Skytable 도커

docker run -d --name skytable -p 2003:2003 skytable/sky:latest

Skytable CLI (skysh)

skysh -p 2003

> create model app.users(username: string, password: string)

> insert into app.users('alice', 'secret123')

> select * from app.users where username = 'alice'

Skytable 의 강점은 Rust 의 안전성 + 멀티 스레드 + 단일 바이너리입니다. \"Redis 대안인데 SQL 비슷한 게 가능했으면 좋겠다\" 는 작은 팀들 사이에서 점진적으로 채택되고 있습니다.

Speedb

Speedb 는 Meta 의 RocksDB 를 포크해서 만든 \"빠른 RocksDB\" 입니다. RocksDB 의 API 는 그대로 유지하면서, 컴팩션 / Bloom Filter / 메모리 관리를 다시 짜서 동일 워크로드에서 2~5배 처리량을 냅니다.

- API 완전 호환 — RocksDB 코드 변경 없이 라이브러리 교체만으로 적용 가능

- Apache 2.0 라이선스

- 압축 후 메모리 사용량 약 40% 절감

// C++ 에서 Speedb 사용 (RocksDB 와 동일한 인터페이스)

#include <rocksdb/db.h>

rocksdb::Options options;

options.create_if_missing = true;

rocksdb::DB* db;

rocksdb::DB::Open(options, "/tmp/speedb_test", &db);

db->Put(rocksdb::WriteOptions(), "hello", "world");

std::string value;

db->Get(rocksdb::ReadOptions(), "hello", &value);

// → "world"

Speedb 는 단독 KV 스토어가 아니라 임베디드 라이브러리이므로, Redis 알트보다는 \"RocksDB 를 쓰는 모든 시스템(Kafka, MyRocks, TiKV) 의 성능 업그레이드\" 로 자리매김했습니다.

13. 인메모리 라이브러리 — node-cache / lru-cache / cachetools / Caffeine

분산 캐시 서버 외에, 애플리케이션 프로세스 내부의 인메모리 캐시도 따로 봐야 합니다. \"DB 앞에 Redis\" 가 아니라 \"애플리케이션 내부 Map 에 5분짜리 TTL\" 인 경우가 매우 많습니다.

Node.js — lru-cache, node-cache, keyv

- lru-cache (Isaac Schlueter, npm 의 저자) — 사실상 표준. LRU + TTL + max size

- node-cache — 단순 TTL 기반 (LRU 없음)

- keyv — 멀티 어댑터(Redis, SQLite, Memory) 추상화 라이브러리

// lru-cache 사용 예

const cache = new LRUCache({

max: 500,

ttl: 1000 * 60 * 5, // 5분

updateAgeOnGet: true,

})

cache.set('user:42', { name: 'Alice' })

console.log(cache.get('user:42'))

Python — cachetools, functools.lru_cache, diskcache

- functools.lru_cache — 표준 라이브러리, 데코레이터 기반

- cachetools — LRU, LFU, TTL, RR (Random Replacement) 등 다양한 정책

- diskcache — 디스크 백엔드 캐시 (단일 프로세스용 임베디드)

cachetools 사용

from cachetools import TTLCache, cached

cache = TTLCache(maxsize=100, ttl=300) # 5분

@cached(cache)

def expensive_query(user_id):

return db.query("SELECT * FROM users WHERE id = ?", user_id)

Java — Caffeine, Guava Cache, EHCache

- Caffeine (Ben Manes) — 사실상 표준. W-TinyLFU 정책, async loader, 매우 빠름

- Guava Cache — 오래된 표준. 지금은 Caffeine 으로 교체 권장

- EHCache — Terracotta / Ehcache 3, JCache 표준 구현체

// Caffeine 사용

LoadingCache cache = Caffeine.newBuilder()

.maximumSize(10_000)

.expireAfterWrite(Duration.ofMinutes(5))

.recordStats()

.build(key -> loadFromDb(key));

User user = cache.get("user-42");

Go — bigcache, ristretto, groupcache

- ristretto (Dgraph) — 동시성 최적화, W-TinyLFU

- bigcache (Allegro) — GC 최적화 (포인터 없이 byte slice)

- groupcache (Brad Fitzpatrick, Memcached 만든 사람) — singleflight 내장

라이브러리 캐시는 분산 캐시보다 훨씬 빠릅니다 (1ns vs 1ms 정도 차이). 그래서 \"L1 = 프로세스 내 라이브러리, L2 = Redis/Valkey\" 같은 다단계 캐시가 일반적 패턴입니다.

14. 분산 캐시 패턴 — cache-aside / read-through / write-through / write-back / write-around

분산 캐시를 쓸 때, 캐시와 백엔드 DB 사이의 동기화 방식을 어떻게 설계하느냐가 정확성 / 성능 / 일관성의 트레이드오프를 결정합니다.

Cache-aside (Lazy loading)

가장 흔한 패턴. 애플리케이션이 직접 캐시와 DB 를 다룹니다.

def get_user(user_id):

1. 캐시 조회

user = cache.get(f"user:{user_id}")

if user:

return user

2. 캐시 미스 → DB 조회

user = db.query("SELECT * FROM users WHERE id = ?", user_id)

3. 캐시 업데이트

cache.set(f"user:{user_id}", user, ttl=300)

return user

장점은 단순함과 캐시 장애 대응 (DB fallback). 단점은 캐시 미스 시 응답 지연.

Read-through

캐시 서버가 직접 DB 를 조회합니다. 애플리케이션은 캐시만 봅니다.

캐시 라이브러리가 loader 를 받음

@cached_loader(loader=lambda k: db.query(f"SELECT * FROM users WHERE id = '{k}'"))

def get_user(user_id):

return cache.get(f"user:{user_id}")

Caffeine 의 LoadingCache, Hazelcast 의 MapStore 가 이 패턴입니다.

Write-through

쓰기 시 캐시 → DB 순서로 동기 쓰기. 정합성은 보장되지만 쓰기가 느립니다.

Write-back (Write-behind)

쓰기 시 캐시만 업데이트하고, DB 는 비동기로 나중에 갱신. 빠르지만 캐시 장애 시 데이터 손실 위험.

Write-around

쓰기는 DB 에만, 읽기 시에만 캐시 채움. 자주 안 읽히는 쓰기가 많은 워크로드(로그, 이벤트) 에 적합.

| 패턴 | 읽기 성능 | 쓰기 성능 | 정합성 | 복잡도 |

|------|------------|------------|---------|--------|

| Read-through | 미스 시 자동 | 빠름 | 중간 | 중간 |

| Write-through | 빠름 | 느림 (2번 쓰기) | 강함 | 중간 |

| Write-around | 미스 시 느림 | 빠름 | 강함 | 낮음 |

대부분의 웹 서비스는 Cache-aside 로 시작합니다. 쓰기 패턴이 명확해지면 Write-around 또는 Read-through 로 진화하고, 정합성이 중요한 트랜잭션 시스템은 Write-through 를 채택합니다.

15. Hot key + cache stampede 문제 — singleflight + dogpile 회피

분산 캐시 운영에서 가장 자주 만나는 두 가지 사고가 \"hot key\" 와 \"cache stampede\" 입니다.

Hot key 문제

특정 키 (예: \"홈페이지 인기 상품 TOP 10\", \"오늘의 환율\") 가 모든 트래픽을 한 샤드에 집중시키는 현상. Redis Cluster 모드에서도 단일 키는 단일 샤드에 고정이라, 그 샤드의 CPU 가 100% 가 됩니다.

대응 전략.

- 키 샤딩 — \"top10:1\", \"top10:2\" 등으로 의도적 분산 후 클라이언트가 임의 선택

- 클라이언트 사이드 캐시 — Redis 6.0+ 의 client-side caching 또는 lru-cache L1

- Read replica — Redis Cluster + replica read

Cache stampede (Thundering herd / Dogpile)

캐시가 만료되는 순간 모든 요청이 DB 로 몰리는 현상. 1000 RPS 의 트래픽이 갑자기 1000개의 DB 쿼리로 변신합니다.

대응 패턴.

singleflight 패턴 — Go groupcache 에서 가져온 개념

_locks = {}

_lock_lock = threading.Lock()

def get_or_load(key, loader):

cached = cache.get(key)

if cached:

return cached

같은 키에 대해 단 1개의 로더만 동작

with _lock_lock:

if key not in _locks:

_locks[key] = threading.Lock()

key_lock = _locks[key]

with key_lock:

다시 한 번 캐시 확인 (앞선 요청이 채웠을 수 있음)

cached = cache.get(key)

if cached:

return cached

진짜 로더 실행

value = loader()

cache.set(key, value, ttl=300)

return value

다른 패턴.

- Probabilistic early expiration — 만료 직전 일부 요청만 갱신 (XFetch 알고리즘)

- Stale-while-revalidate — 만료된 값을 일단 반환하고 백그라운드 갱신

- Refresh-ahead — 만료 전 자동 백그라운드 새로고침 (Caffeine 의 refreshAfterWrite)

XFetch (Probabilistic early expiration) — Redis 7+ 의 CLIENT NO-EVICT 와 조합 가능

def xfetch(key, ttl, beta=1.0):

val, delta, expiry = cache.get_with_meta(key)

if val is None:

캐시 미스 → 항상 갱신

return refresh(key)

if time.time() - delta * beta * math.log(random.random()) >= expiry:

만료 전이지만 일부 요청만 갱신

return refresh(key)

return val

토스 / 카카오 의 운영 사례에서는 \"singleflight + Refresh-ahead\" 조합이 가장 자주 등장합니다. 즉, 한 키에 대해 단 1개의 로더만 돌고, 만료 직전 백그라운드로 자동 갱신하는 패턴입니다.

16. Redis 모듈 분열 — RedisJSON, RediSearch, RedisGraph (sunset), RedisTimeSeries, RedisBloom

Redis Ltd. 의 라이선스 변경은 모듈 생태계에도 큰 충격을 줬습니다. 2026년 시점에서 Redis 의 주요 모듈은 다음과 같은 상태입니다.

- RedisJSON — Redis 8 코어에 통합 (단, AGPL/RSAL/SSPL 라이선스)

- RediSearch — Redis 8 코어에 통합, Vector search 와 Full-text search

- RedisGraph — 2023년 7월 sunset 발표, 2025년 EOL

- RedisTimeSeries — Redis 8 코어에 통합

- RedisBloom — Redis 8 코어에 통합 (Bloom, Cuckoo, Count-Min Sketch)

Valkey 진영은 자체 대안을 개발 중입니다.

- VKEYS Vector Search — Valkey 자체 벡터 검색 (Redis 의 Vector Sets 와 별개)

- Valkey JSON — Cocoa 라는 모듈로 개발 중

- Valkey Search — RediSearch 대체로 개발 중

- Valkey Bloom — Bloom Filter 모듈 별도 개발

RedisGraph 의 EOL 은 그래프 DB 사용자들에게 충격이었습니다. 대안으로는 Memgraph (인메모리 그래프 DB), Neo4j, ArangoDB 가 거론됩니다.

Redis 8 코어에서 JSON 자료구조 사용 (모듈 별도 로드 불필요)

redis-cli JSON.SET user:1 $ '{"name":"Alice","age":30}'

redis-cli JSON.GET user:1 $.name

→ "Alice"

Vector Search (RediSearch 통합)

redis-cli FT.CREATE products ON HASH PREFIX 1 product: \

SCHEMA name TEXT embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE

모듈 통합 / 분열은 결국 \"누구의 Redis 가 표준이냐\" 의 정치적 문제입니다. 큰 회사들은 Valkey 진영의 모듈 발전 속도를 지켜보면서 천천히 마이그레이션 계획을 세우고 있습니다.

17. 한국 / 일본 — 카카오, 토스, 메르카리, NTT

각 지역의 캐시 운영 사례를 빠르게 정리합니다.

한국 — 카카오, 토스, 네이버, 쿠팡

- 카카오 — Redis Cluster + Sentinel 기반, 2024년 라이선스 변경 후 Valkey 마이그레이션 시작. 카카오톡 메시지 큐 / 친구 목록 / 채팅방 캐시

- 토스 — Redis 7.x + 자체 운영, MSA 아키텍처에서 서비스별 독립 Redis 클러스터. \"Redis 가 죽으면 토스가 멈춘다\" 는 표현이 내부에 있을 정도

- 네이버 — Memcached + Redis 혼합. 검색 결과 캐시는 여전히 Memcached, 추천 시스템은 Redis Cluster

- 쿠팡 — AWS Elasticache for Redis 대량 사용. 라이선스 충격 이후 Valkey 마이그레이션 진행 중

- 라인 (LY Corp) — Redis Sentinel + 자체 솔루션, 글로벌 데이터센터별 독립 클러스터

일본 — 메르카리, NTT, 야후재팬, LINE

- 메르카리 (Mercari) — GCP MemoryStore for Redis, 상품 검색 캐시 / 사용자 세션. 2025년부터 일부 Valkey 마이그레이션 PoC

- NTT — Tarantool 을 5G Core 의 세션 저장소로 채택한 사례가 유명. 통신 회사 특유의 안정성 요구로 Redis 보다 Tarantool 선호

- 야후재팬 — Memcached + 자체 KV. 검색 / 광고 캐시는 Memcached, 사용자 데이터는 자체 분산 KV

- LINE — Redis Cluster 대량 사용, 일본 LINE / 대만 LINE 별도 운영

- 사이게임즈 (Cygames) — Redis Cluster + Aerospike 혼합, 모바일 게임의 실시간 랭킹 / 인벤토리

한일 양국의 공통점은 \"Redis 라이선스 변경 이후 Valkey 마이그레이션을 검토 중\" 입니다. 차이는 일본이 더 보수적이라 \"검토만 길게\" 하는 반면, 한국은 \"PoC 빠르게 → 실서비스 적용\" 이 더 일반적이라는 점입니다.

18. 누가 무엇을 골라야 하나 — 단순 / 복잡 자료구조 / 분산 / 엔터프라이즈

마지막으로 \"누구에게 무엇을 권할지\" 를 정리합니다.

단순한 캐시 (TTL 만 있으면 됨)

→ Memcached. 단일 노드면 도커 한 줄, 클러스터면 클라이언트 사이드 sharding. \"Redis 의 자료구조가 필요 없다\" 는 게 확실하면 Memcached 가 가장 가볍습니다.

복잡한 자료구조 (Hash / List / Set / Sorted Set / Stream)

→ Redis 8 (라이선스 OK 면) 또는 Valkey 8.1 (오픈소스 우선). 사실상 표준이라 클라이언트 / 도구 / 문서가 가장 풍부합니다.

멀티 스레드 단일 노드 처리량

→ Dragonfly. 단일 머신에서 최대 처리량 / 최소 메모리. Redis 1:1 대체 가능.

.NET / Azure 환경

→ Garnet. MIT 라이선스 + C# 운영 친화. Azure 에서는 Cache for Garnet 미리보기 활용.

SQL + 인메모리 그리드 + 트랜잭션

→ Apache Ignite (오픈소스) 또는 Hazelcast (상용 지원). 금융 / 통신 / 헬스케어 같은 큰 엔터프라이즈 워크로드.

메모리보다 큰 데이터셋 (Hybrid)

→ Aerospike. RAM 인덱스 + SSD 데이터의 모델로 100억 키도 가능.

Lua 임베디드 비즈니스 로직 + 인메모리 DB

→ Tarantool. 통신 / 게임에 특히 적합.

AWS 매니지드

→ 새 워크로드는 Elasticache for Valkey 또는 MemoryDB for Valkey. 기존 Redis 호환만 필요하면 Elasticache for Redis 유지.

Rust / 안전성 우선

→ Skytable (또는 Dragonfly, 후자는 C++). 단일 바이너리, 메모리 안전.

RocksDB 기반 임베디드 KV

→ Speedb. 코드 변경 없이 성능 업그레이드.

프로세스 내 캐시 (애플리케이션 라이브러리)

→ Java: Caffeine. Node: lru-cache. Python: cachetools. Go: ristretto.

패턴 가이드

- 읽기 중심 + 약한 정합성 → Cache-aside + lru-cache (L1) + Redis (L2)

- 쓰기 중심 + 강한 정합성 → Write-through + Caffeine + MemoryDB

- 매우 큰 데이터 → Aerospike 또는 Ignite Native Persistence

- 글로벌 멀티 리전 → Redis Enterprise CRDT 또는 KeyDB Active-Active

- 단순 LRU → Memcached + 클라이언트 lru-cache

2026년의 캐싱 결정은 \"Redis 면 됨\" 이 아니라 \"Redis 의 어느 버전 / 포크를 어떤 패턴으로 어떤 라이브러리와 함께 쓸 것인가\" 의 다층 결정입니다. 라이선스 변경의 후폭풍은 결국 시장의 다양성을 늘렸고, 우리는 그 다양성을 잘 골라야 하는 입장이 됐습니다.

19. 참고 / References

- Redis — https://redis.io/

- Redis 8 Release Notes — https://redis.io/blog/redis-8-ga/

- Redis License FAQ — https://redis.io/legal/licenses/

- Valkey — https://valkey.io/

- Valkey GitHub — https://github.com/valkey-io/valkey

- Linux Foundation Valkey 발표 — https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community

- KeyDB — https://docs.keydb.dev/

- KeyDB GitHub — https://github.com/Snapchat/KeyDB

- Dragonfly — https://www.dragonflydb.io/

- Dragonfly GitHub — https://github.com/dragonflydb/dragonfly

- Memcached — https://memcached.org/

- Microsoft Garnet — https://microsoft.github.io/garnet/

- Garnet GitHub — https://github.com/microsoft/garnet

- Apache Ignite — https://ignite.apache.org/

- Hazelcast — https://hazelcast.com/

- Infinispan — https://infinispan.org/

- Aerospike — https://aerospike.com/

- Tarantool — https://www.tarantool.io/

- Skytable — https://skytable.io/

- Speedb — https://www.speedb.io/

- AWS Elasticache — https://aws.amazon.com/elasticache/

- AWS Elasticache for Valkey — https://aws.amazon.com/elasticache/valkey/

- AWS MemoryDB — https://aws.amazon.com/memorydb/

- GCP Memorystore — https://cloud.google.com/memorystore

- Caffeine — https://github.com/ben-manes/caffeine

- lru-cache (Node) — https://github.com/isaacs/node-lru-cache

- node-cache — https://github.com/node-cache/node-cache

- cachetools (Python) — https://github.com/tkem/cachetools

- ristretto (Go) — https://github.com/hypermodeinc/ristretto

- bigcache (Go) — https://github.com/allegro/bigcache

- groupcache (Go) — https://github.com/golang/groupcache

- XFetch 알고리즘 (Probabilistic early expiration) — https://www.vldb.org/pvldb/vol8/p886-vattani.pdf

- RedisJSON — https://github.com/RedisJSON/RedisJSON

- RediSearch — https://github.com/RediSearch/RediSearch

- RedisGraph EOL — https://redis.io/blog/redisgraph-eol/

- RedisTimeSeries — https://github.com/RedisTimeSeries/RedisTimeSeries

- RedisBloom — https://github.com/RedisBloom/RedisBloom

- Speedb vs RocksDB — https://www.speedb.io/blog

- Memgraph (RedisGraph 대안) — https://memgraph.com/

- Picodata (Tarantool 분기) — https://picodata.io/