Valkey와 Redis 상세 비교

한 줄 요약

범용 캐시·세션·레이트 리밋을 새로 구축한다면 라이선스가 단순하고 AWS 가격 우대가 있는 Valkey가 좋은 기본값이다. JSON·검색·벡터·시계열을 통합해서 쓰거나 Redis Cloud·Redis Software 생태계가 필요하면 Redis가 유리하다.

먼저 읽을 결론

2026년 8월 4일 기준 Valkey는 Redis 7.2.4에서 갈라져 나온 Linux Foundation 산하의 BSD-3-Clause 오픈소스 인메모리 데이터 저장소다. 최신 안정 버전은 Valkey 9.1.1이고 Redis Open Source의 최신 GA는 Redis 8.10.0이다.

두 제품은 Redis 7.2 계열의 핵심 명령을 넓게 공유하지만 이제 같은 제품의 이름만 바꾼 관계는 아니다. 라이선스, 거버넌스, 신규 명령, 모듈 통합, 클라우드 가격이 서로 다른 방향으로 발전하고 있다.

상황	우선 검토할 제품	이유
새 범용 캐시·세션·레이트 리밋	Valkey	BSD 라이선스, Redis 7.2 호환성, AWS 가격 우대
Redis 7.2 핵심 명령만 사용 중	Valkey 이전 검토	비교적 낮은 전환 위험
JSON·전문 검색·벡터·시계열 통합	Redis	Redis 8 배포판에 관련 기능 통합
Redis Cloud·Redis Software 기능 필요	Redis	상용 운영 생태계와 지원
자체 관리형 DBaaS·어플라이언스	Valkey	permissive BSD 라이선스
최고 QPS 또는 최소 메모리가 목표	직접 벤치마크	데이터 분포와 설정에 따라 결과가 달라짐

순수 GET/SET 성능만으로 어느 한쪽이 항상 빠르다고 말할 근거는 없다. Valkey와 Redis가 공개한 수치는 주로 각자의 이전 버전과 비교한 결과다. 최신 Valkey 9.1과 Redis 8.10을 동일한 하드웨어·데이터·HA·영속성 조건에서 비교한 중립적 보편 벤치마크는 아직 없다.

왜 저장했나

Redis의 라이선스 변경 이후 Valkey가 주요 클라우드의 관리형 엔진으로 자리 잡으면서 신규 캐시의 기본 선택지가 달라졌다. 이름과 호환성만 보고 결정하면 라이선스, 모듈 의존성, 메모리 구조, 클라우드 가격과 장애 시 지연을 놓치기 쉽다.

이 문서는 제품 소개에 그치지 않고 실제 선택과 용량 계획, Spring 애플리케이션 마이그레이션, 운영 벤치마크에 필요한 기준을 한곳에 모은다.

정리한 질문

Valkey는 왜 만들어졌고 Redis와 무엇이 다른가? 라이선스, 기능, 성능, 가격, 사용량, 메모리, CPU와 운영 최적화 관점에서 어떤 제품을 선택해야 하는가?

Valkey가 생긴 배경

Redis Ltd.는 2024년 3월 Redis 7.4부터 기존 BSD 라이선스를 RSALv2와 SSPLv1 이중 라이선스로 바꿨다. 이에 AWS, Google Cloud, Oracle, Ericsson, Snap 등의 참여 아래 Redis 7.2.4 코드를 이어 개발하는 Valkey가 출범했다.

Valkey는 Linux Foundation 산하의 커뮤니티 거버넌스를 채택하고 코어를 BSD-3-Clause로 배포한다. 초기에는 BSD Redis 7.2의 후속 포크에 가까웠지만, 이후 독자적인 변화가 쌓였다.

Valkey 8: 비동기 I/O 스레딩 재설계와 클러스터 메모리 구조 개선
Valkey 8.1: 캐시라인 친화적인 새 해시 테이블
Valkey 9.0: 클러스터 다중 DB, 원자적 슬롯 마이그레이션, Hash field TTL, 파이프라인 prefetch
Valkey 9.1: DB 단위 ACL, Lua 모듈화, TLS 인증서 자동 재적재, 스레드별 사용량 지표

한눈에 보는 차이

항목	Valkey	Redis
출발점	Redis 7.2.4 기반 커뮤니티 포크	원래 Redis 프로젝트를 Redis Ltd.가 계속 개발
2026-08-04 최신 안정 버전	9.1.1	8.10.0
거버넌스	Linux Foundation, 커뮤니티 중심	Redis Ltd. 중심
코어 라이선스	BSD-3-Clause	8.x부터 RSALv2·SSPLv1·AGPLv3 중 선택
Redis 7.2 API	높은 호환성	원본
최신 전용 명령	Valkey 고유 기능	Redis 8 고유 기능
JSON·검색	공식 모듈과 Bundle	코어 배포판에 통합
시계열·확률 자료구조	모듈별 지원 확인 필요	TimeSeries·Bloom 계열 통합
관리형 서비스	AWS·Google Cloud 등 빠르게 확대	기존 설치 기반과 Redis Cloud·Software
AWS ElastiCache 가격	명시적 우대	Valkey보다 높은 엔진 가격

라이선스

Valkey

Valkey 코어는 BSD-3-Clause다. 저작권과 라이선스 고지를 유지하고 프로젝트 이름을 무단 보증에 사용하지 않는 일반적인 조건 아래 사내 사용, 수정, 비공개 운영, 상용 제품 포함, 관리형 서비스 제공과 재배포가 가능하다.

공급망 정책과 법무 검토가 단순해야 하거나 Redis 호환 서비스를 직접 판매하려는 경우 Valkey의 장점이 크다.

Redis

Redis는 버전별 라이선스가 다르다.

Redis 버전	라이선스
7.2 이하	BSD-3-Clause
7.4~7.8	RSALv2 또는 SSPLv1
8.0 이상	RSALv2, SSPLv1, AGPLv3 중 선택

Redis 8부터 AGPLv3가 추가돼 OSI 승인 오픈소스 선택지가 다시 생겼다. 다만 AGPLv3는 BSD처럼 permissive한 라이선스가 아니라 네트워크 사용 조항을 포함한 강한 copyleft다. RSALv2와 SSPLv1은 source-available이지만 OSI 승인 오픈소스 라이선스가 아니다.

공식 Redis 바이너리를 수정하지 않고 별도 프로세스로 사용하는 일반적인 Spring Boot 서비스라면, Redis를 쓴다는 이유만으로 애플리케이션 전체를 공개해야 하는 것은 아니다. Redis 공식 FAQ도 7.2 이하에서 Redis 8 공식 코드를 그대로 사용하는 대부분의 사용자는 영향을 받지 않는다고 설명한다.

Redis 서버 코드를 수정해 네트워크 서비스로 제공하거나 Redis와 경쟁하는 관리형 서비스·어플라이언스를 만들면 조건이 달라진다.

RSALv2는 Redis 기능 자체를 제3자에게 관리형 서비스로 상용화하는 일을 제한한다.
SSPLv1은 관리형 서비스 제공 시 관리 계층까지 포함한 넓은 소스 공개 의무가 문제가 될 수 있다.
AGPLv3를 선택하고 수정 서버를 네트워크로 제공하면 대응 소스 제공 의무를 검토해야 한다.

이는 법률 자문이 아니다. 서버 수정, 모듈 결합, 재배포, 관리형 판매가 포함되면 별도 법무 검토가 필요하다.

기능

공통 기능

둘 다 Redis 7.2 계열의 핵심 기능을 상당 부분 공유한다.

String, Hash, List, Set, Sorted Set
Bitmap, HyperLogLog, Geo
Streams와 Consumer Group
Pub/Sub
트랜잭션과 optimistic locking
TTL과 eviction
RDB와 AOF
복제, Sentinel, Cluster
ACL, TLS
Lua 또는 서버 측 함수
RESP2·RESP3 클라이언트

핵심 명령만 사용하는 애플리케이션은 클라이언트 코드를 바꾸지 않고 서버 주소만 변경해도 동작하는 경우가 많다. 하지만 Redis 8 또는 Valkey 9의 고유 명령과 모듈까지 자동으로 호환되는 것은 아니다.

Redis가 강한 영역

Redis 8 배포판에는 Query Engine, 전문 검색, 벡터·하이브리드 검색, RedisJSON, RedisTimeSeries, Bloom Filter, Cuckoo Filter, Count-Min Sketch, Top-K, t-digest 계열이 통합돼 있다.

Redis 8.10은 같은 필드 스키마를 공유하는 Hash의 필드 이름을 한 번만 저장하는 compact hash, 대량 삽입용 HIMPORT, 복제 스트림 압축과 여러 신규 명령을 추가했다.

JSON 문서를 필드별로 검색하거나 벡터와 전문 검색을 한 쿼리로 묶고, 시계열과 확률 자료구조까지 하나의 제품으로 운영한다면 Redis가 자연스럽다.

Valkey가 강한 영역

Valkey는 코어와 모듈을 분리하는 방향이 강하다. 공식 Search, JSON, Bloom 모듈과 Valkey Bundle이 있으며 Search는 벡터, 숫자, 태그, 전문 검색과 hybrid workload를 지원한다. 다만 배포 이미지와 클라우드 서비스가 어떤 모듈을 제공하는지 따로 확인해야 한다.

Valkey 9.1은 Lua를 선택적 모듈로 분리했다. 스크립팅이 필요 없다면 공격 표면과 의존성을 줄일 수 있지만, 기존 EVAL 기반 애플리케이션은 Lua 모듈 포함 여부를 확인해야 한다.

성능

CPU 아키텍처를 먼저 이해해야 한다

두 제품 모두 모든 명령을 여러 CPU에서 완전히 병렬 실행하는 데이터베이스는 아니다. 한 샤드의 main thread가 명령을 순차 실행하고, I/O thread가 소켓 읽기, 명령 파싱, 응답 쓰기, event polling과 일부 메모리 해제를 나눠 처리한다.

16코어 서버에 단일 인스턴스를 띄워도 GET/SET 명령 실행이 자동으로 16배 병렬화되지는 않는다. 네트워크·TLS·파싱 부하는 여러 코어로 분산할 수 있지만, 한 샤드의 명령 처리량은 main thread 성능과 명령 복잡도에 계속 영향을 받는다. 더 높은 명령 실행 병렬성이 필요하면 인스턴스나 Cluster로 샤딩해야 한다.

공식 발표 수치

발표 주체와 비교 범위	발표한 최대 개선	해석할 때 주의할 점
Valkey 9.0의 pipeline prefetch	처리량 40%	이전 Valkey의 특정 파이프라인 조건 대비
Valkey 9.0의 large-response zero-copy	처리량 20%	큰 응답 워크로드 한정
Valkey 9.0의 BITCOUNT·HyperLogLog SIMD	처리량 200%	특정 명령 최적화
Valkey 9.0의 MPTCP	지연 25% 감소	MPTCP 환경 한정
Valkey 대형 클러스터 실험	2,000노드, 10억 RPS 이상	일반 단일 노드 캐시와 다른 규모
Redis 8.6 대 Redis 7.2	처리량 5배 이상	16코어 Graviton4, 11 I/O threads, 2,000 clients, 1KB 값, SET:GET 1:10
Redis 8.6 pipeline 16	350만 ops/sec	Redis 자체 테스트 환경
Redis 8.6 대 8.4	짧은 String GET 지연 15%, ZSet 지연 35% 감소	최신 Valkey와의 비교가 아님
Google Memorystore Valkey 8 대 Redis Cluster	microsecond급 지연에서 최대 2배 QPS	Google 관리형 서비스의 특정 비교

이 수치들은 Valkey 9.1 대 Redis 8.10의 직접 대결이 아니다. 제품 선택에는 실제 키 길이, 값 크기, TTL 분포, 파이프라인, TLS, 연결 수, replica, AOF/RDB와 Cluster 구성을 반영한 측정이 필요하다.

워크로드별 예상

워크로드	판단
단순 GET/SET, 높은 동시성	Valkey가 경쟁력 있지만 최신 Redis와 실측 필요
파이프라인이 많은 배치 요청	Valkey 9의 prefetch·zero-copy가 유리할 가능성
낮은 동시성의 단건 요청	서버 차이보다 RTT와 직렬화가 더 중요
큰 Hash·ZSet	버전별 최적화 차이가 커 실제 분포로 측정
JSON·검색·시계열	Redis 통합 엔진의 기능과 운영 편의가 강점
작은 TTL 키 수백만 개	Valkey 해시 테이블·TTL 메모리 개선이 유리할 가능성
같은 스키마의 Hash 대량	Redis 8.10 compact hash가 유리할 가능성
단일 hot key	양쪽 모두 main thread·단일 샤드 한계가 먼저 나타남

평균 QPS보다 p99.9 지연과 동일 비용당 처리량을 봐야 한다. eviction, snapshot, AOF rewrite와 failover 중 tail latency가 급증하지 않는지가 평균 처리량 차이보다 중요할 수 있다.

CPU 최적화

CPU 병목은 세 종류로 나눠야 한다.

Main thread 병목

큰 SMEMBERS, HGETALL, LRANGE, KEYS, 긴 Lua, 큰 키의 동기식 DEL, 대형 응답, hot key, 고비용 Set·ZSet 연산은 main thread를 막는다.

KEYS 대신 SCAN
전체 컬렉션 대신 범위·페이지 조회
큰 키 삭제는 UNLINK
Lua 실행 시간을 짧게 제한
hot key는 로컬 캐시·복제·키 분할 검토
Cluster 샤드 확장

이 병목에서는 I/O thread 수를 늘려도 효과가 작다.

네트워크·파싱·TLS 병목

연결 수가 많고 작은 명령이 매우 많거나 TLS와 대형 응답을 처리한다면 I/O threads가 효과적이다. vCPU 수와 같은 값으로 무조건 맞추지 말고 2·4·6개 같은 후보를 실제 부하로 비교한다. main thread, OS, 복제와 background 작업에 쓸 CPU도 남겨야 한다.

겉으로 높아 보이는 CPU

Valkey 9.1에서는 main thread와 I/O thread가 busy loop로 작업을 기다려 OS CPU가 거의 100%처럼 보이면서 실제 부하는 낮을 수 있다. 프로세스 CPU만 보지 말고 main/I/O thread 누적 사용량, QPS, 지연과 queueing을 함께 본다.

Java·Spring에서 자주 생기는 낭비

요청마다 새 연결 생성
과도한 JSON 직렬화와 Java 기본 직렬화
필요 이상으로 긴 키
blocking 명령을 일반 연결에서 실행
지나치게 큰 pipeline
과도한 connection pool
Cluster topology refresh 미설정
재시도 폭풍과 중복 요청

Lettuce는 Netty 기반 연결 multiplexing을 지원하므로 일반 명령용 풀을 크게 만들 필요가 없는 경우가 많다. Blocking 명령, Pub/Sub, 트랜잭션은 일반 요청과 연결을 분리하는 편이 안전하다.

메모리

프로세스 메모리는 키와 값의 합보다 크다.

프로세스 RSS
= 실제 데이터
+ 키·객체 헤더
+ 해시 테이블과 TTL 메타데이터
+ allocator fragmentation
+ 클라이언트 입출력 버퍼
+ replication backlog와 AOF 버퍼
+ 모듈·검색 인덱스
+ RDB/AOF rewrite 중 copy-on-write

Valkey의 개선

Valkey 8은 Cluster에서 키마다 필요했던 슬롯 연결 메타데이터 16바이트를 제거했다. 공식 테스트의 약 632만 키 데이터셋은 693.64MB에서 550.56MB로 줄어 20.63% 개선됐다. 이는 Valkey 7.2 대비 Valkey 8의 특정 데이터셋 결과다.

Valkey 8.1의 새 해시 테이블은 일반 key-value에서 약 20바이트/키, TTL이 있는 key-value에서 약 30바이트/키, 큰 Hash·Set·Sorted Set에서 약 10~20바이트/element 절감을 보고했다.

Redis의 개선

Redis 8.6은 Redis 8.4 대비 특정 데이터셋에서 Hash 메모리 최대 16.7%, Sorted Set 메모리 최대 30.5% 절감을 발표했다. Redis 8.10의 compact hash는 같은 필드 스키마를 공유하는 여러 Hash의 필드 이름을 한 번만 저장한다.

데이터 분포에 따른 판단

데이터 형태	유리할 가능성이 있는 쪽
작은 top-level 키 수백만 개와 TTL	Valkey 8.1 이상
Cluster에서 매우 많은 키	Valkey의 per-slot dictionary
동일 스키마 Hash 대량	Redis 8.10 compact hash
JSON·검색 인덱스	제품 코어보다 문서 표현과 인덱스 설계가 지배
큰 value 중심	키당 수십 바이트 차이의 영향이 작음
큰 복제·AOF·클라이언트 버퍼	코어 객체보다 운영 설정이 중요

maxmemory=20GB는 RSS가 항상 20GB 이하라는 뜻이 아니다. 복제·AOF 버퍼, allocator fragmentation과 fork copy-on-write가 별도로 커질 수 있다.

초기 headroom

아래 값은 제품 보장이 아니라 용량 계획의 출발점이다.

구성	전체 RAM 중 `maxmemory` 시작점
순수 캐시, persistence 없음	75~80%
replica 있음, 쓰기 중간	70~75%
RDB/AOF 사용, 쓰기 많음	55~70%
큰 키·rewrite·fragmentation 위험 큼	50~60%

32GiB 컨테이너라면 순수 캐시는 24~~26GiB, AOF/RDB와 쓰기가 많으면 18~~22GiB부터 검증할 수 있다. 실제 값은 peak RSS와 장애·rewrite 테스트로 정한다.

가격

셀프 호스팅

Valkey BSD 버전과 Redis 8의 AGPLv3 선택지는 소프트웨어 라이선스 비용 없이 사용할 수 있다. 실제 TCO는 노드, replica, 네트워크, 백업, 모니터링, 운영 인력, 장애 비용과 상용 지원을 포함한다.

월 비용
= 노드 단가 × primary/replica 수 × 월 시간
+ cross-AZ 네트워크
+ 백업 저장소
+ 운영 인력과 모니터링
+ 장애 비용과 상용 지원

HA를 위해 primary마다 replica 하나를 두면 데이터 메모리 용량도 거의 두 배 필요하다. Cluster 비용은 샤드 수 × (primary + replica 수)로 계산한다.

AWS ElastiCache

AWS는 Valkey에 명시적인 가격 우대를 적용한다.

Node 기반 Valkey는 다른 지원 엔진보다 20% 낮은 가격
ElastiCache Serverless for Valkey는 33% 낮은 가격
Serverless 최소 과금 저장량은 Valkey 100MB, Redis OSS·Memcached 1GB
기존 Redis OSS Reserved Node 할인은 같은 인스턴스 계열과 리전의 Valkey에 적용 가능

AWS에서 말하는 Redis OSS는 관리형 BSD Redis 계열 엔진이다. 이 가격 차이를 최신 Redis 8.10과 Valkey 9.1 소프트웨어의 동일 버전 비교로 해석하면 안 된다. Cross-AZ 트래픽과 payload가 크면 엔진 가격보다 네트워크 비용이 더 커질 수도 있다.

Google Cloud Memorystore

Google Cloud는 Memorystore for Valkey와 Redis Cluster를 비슷한 가격대로 제공하면서 Valkey 8이 특정 테스트에서 microsecond급 지연을 유지한 채 최대 2배 QPS를 냈다고 발표했다. 이는 같은 가격에서 필요한 노드 수가 줄 가능성을 뜻하며, Valkey가 항상 절반 비용이라는 보장은 아니다.

Redis Cloud

Redis Cloud 가격에는 검색·JSON·벡터·시계열, 자동 확장, 지원과 엔터프라이즈 운영 기능이 포함될 수 있다. 단순 Valkey 노드와 비교하려면 기능, replica, SLA와 지원 범위를 맞춰야 한다.

사용량과 생태계

신뢰할 만한 전 세계 Redis 대 Valkey 시장 점유율 통계는 아직 없다. Redis는 오랜 설치 기반, 클라이언트, 문서와 상용 도구가 강하다. Valkey는 Linux Foundation과 클라우드 사업자를 중심으로 빠르게 확산하고 있다.

Linux Foundation은 2025년 4월, 출범 약 1년 만에 Valkey에 거의 50개 회사가 기여했고 GitHub 19.8K stars, 761 forks, 150 contributors, Docker pull 500만 회 이상을 기록했다고 밝혔다. 성장의 근거는 되지만 Redis보다 사용량이 많다는 뜻은 아니다.

AWS와 Google Cloud는 관리형 Valkey를 제공하고 Valkey 공식 사이트에는 Oracle, Aiven, Heroku, DigitalOcean 등 여러 공급자와 참여사가 올라와 있다.

Spring 생태계

기존 Spring Data Redis와 Lettuce/Jedis는 Redis 7.2 호환 핵심 명령 범위에서 Valkey와 대체로 동작한다.
Valkey 전용 신규 명령은 클라이언트 버전의 지원이 필요하다.
Spring Data Valkey는 별도 community module이다.
Spring Data Redis는 공식 Spring Data release train에 포함돼 있다.

서버 주소만 바꾸는 전환은 가능할 수 있지만, Valkey 고유 기능까지 쓴다면 클라이언트와 Spring 모듈의 지원 범위를 확인한다.

운영 최적화

데이터 모델

서버 설정보다 데이터 모델이 더 큰 차이를 만드는 경우가 많다. 작은 필드를 여러 top-level 키로 나누기보다 하나의 Hash로 묶으면 객체·키 헤더를 줄일 수 있다. 다만 필드마다 TTL이 다르면 Hash field expiration과 명령 호환성을 확인해야 한다.

수백만 키에서는 긴 prefix도 실제 메모리 비용이다. 충돌을 막을 만큼의 namespace는 유지하되 운영자가 해석할 수 있는 범위에서 줄인다.

TTL은 정각에 몰리지 않게 jitter를 준다. 1시간 TTL이라면 55~65분처럼 분산해 동시 만료와 cache stampede를 완화할 수 있다.

Eviction

데이터 성격	초기 후보
모든 키를 재구성할 수 있는 순수 캐시	`allkeys-lfu`
최근 접근성이 중요한 단순 캐시	`allkeys-lru`
TTL 키만 제거해야 함	`volatile-*` 계열
세션·락·멱등성·상태	`noeviction` 우선 검토
원본 데이터	eviction에 의존하지 않음

세션과 일반 캐시를 같은 인스턴스에 섞으면 eviction 정책을 정하기 어렵다. 데이터 손실의 의미가 다르면 인스턴스나 클러스터도 분리한다.

파이프라이닝

파이프라이닝은 RTT와 syscall을 줄이지만 너무 크게 묶으면 client output buffer, tail latency와 장애 시 재시도가 커진다. pipeline 8·16·32를 비교하되 사용자 요청 경로에서는 작게, 배치와 warm-up 경로에서는 더 크게 시작한다.

큰 키

수십 MB String, 수백만 element Set, 무제한 Stream, 거대한 Hash, 대형 키의 동기식 삭제와 전체 컬렉션 반환은 p99.9와 failover 시간을 악화한다.

Stream 길이를 제한하고 큰 삭제에는 UNLINK를 사용하며 컬렉션은 페이지 단위로 조회한다.

영속성

원본 DB에서 재구성 가능한 캐시이고 warm-up 전략이 있다면 persistence를 끄는 편이 CPU·디스크·메모리 운영이 단순하다. 데이터 손실을 허용할 수 없다면 AOF, RDB, replica와 관리형 durability 기능을 함께 검토한다.

AOF rewrite와 RDB snapshot의 fork는 copy-on-write로 일시적인 메모리 증가와 지연을 만들 수 있다. Redis나 Valkey를 주 데이터베이스로 사용한다면 캐시와 다른 용량·복구·백업 검증이 필요하다.

반드시 볼 지표

영역	주요 지표
지연·처리량	QPS, p50·p95·p99·p99.9, slowlog, command별 호출·CPU, 연결·timeout·retry
메모리	`used_memory`, dataset, overhead, RSS, fragmentation, output buffer, backlog, evicted·expired keys
CPU	main/I/O thread usage, background save·AOF rewrite, context switch, network softirq
캐시 품질	hit·miss·eviction rate, TTL 분포, hot key, stampede, 원본 DB 전이 부하

Valkey 9.1에서는 단순 프로세스 CPU 대신 main/I/O thread usage 지표를 함께 본다.

Redis에서 Valkey로 이전

위험이 낮은 경우

Redis 7.2 이하
String·Hash·List·Set·ZSet 중심
기본 Streams·Pub/Sub
일반 TTL·eviction
제한적인 Lua
외부 Redis 모듈을 사용하지 않음

위험이 높은 경우

Redis 8 전용 명령
RedisJSON, RediSearch, Hybrid Search
RedisTimeSeries
Bloom·TopK·Count-Min Sketch
Redis Enterprise·Cloud 전용 기능
특정 RDB/AOF 버전 호환성
복잡한 Lua·Functions
Cluster 슬롯 마이그레이션 동작 의존

권장 절차

COMMANDSTATS와 APM에서 실제 사용 명령을 수집한다.
모듈, Lua, Functions, ACL과 Cluster 동작을 목록화한다.
동일 데이터셋을 Valkey에 로드한다.
기존 Lettuce/Jedis 코드로 회귀 테스트한다.
TTL, 직렬화, Stream consumer 상태를 검증한다.
동일 조건에서 성능과 메모리를 비교한다.
read-only 또는 일부 트래픽 canary를 거친다.
failover와 rollback을 실제로 실행한다.

RDB가 로드된다는 사실만으로 애플리케이션 마이그레이션이 끝난 것은 아니다. TTL, consumer group, Lua, ACL, Cluster routing과 장애 전환까지 확인해야 한다.

비교 벤치마크 설계

축	동일하게 맞출 조건
하드웨어	CPU, RAM, NIC, NUMA
배포	컨테이너 제한 또는 VM
네트워크	AZ, TLS, RTT
HA	replica 수와 failover 정책
persistence	둘 다 off 또는 동일 AOF/RDB
데이터	실제 키 길이, 값 크기, TTL 분포
명령	실제 GET/SET/Hash/ZSet 비율
연결	동시 연결 수와 client 설정
pipeline	1, 8, 16, 32
측정	QPS, p99.9, CPU/core, RSS, 비용
장애	failover, snapshot, rewrite 중 측정

Spring Boot 서비스라면 세 가지 시나리오를 최소한 돌린다.

일반 캐시

GET 90%
SET 9%
DEL/EXPIRE 1%
1KB value
TTL 5~60분
pipeline 1 / 8 / 32

세션·멱등성

Hash GET/SET
NX + TTL
작은 key/value
쓰기 비중 30~50%
noeviction
replica 1개

최악 조건

hot key
큰 Hash/ZSet
동시 만료
AOF rewrite 또는 snapshot
replica failover
연결 재수립 폭풍

판정은 다음 순서로 한다.

p99.9가 SLA 안에 있는가?
failover 중 오류율이 허용 범위인가?
동일 데이터에서 RSS가 얼마나 다른가?
동일 비용으로 감당할 최대 QPS는 얼마인가?
peak에서 eviction, swap, OOM이 발생하지 않는가?

최종 선택표

상황	추천
새 Spring Boot 캐시	Valkey 우선
HTTP 세션 저장소	Valkey 우선, eviction·HA 검증
레이트 리밋·멱등성 키	Valkey 우선
Redis 7.2 핵심 명령만 사용	Valkey 이전 적극 검토
AWS ElastiCache 비용 절감	Valkey
라이선스·벤더 중립성	Valkey
Redis 호환 관리형 서비스 판매	Valkey
RedisJSON·Search·TimeSeries 다수 사용	Redis 유지 가능성이 높음
벡터와 전문 검색 통합 운영	Redis 우세, Valkey Search도 실측
Redis Cloud·Redis Software 기능	Redis
최고 QPS	제품명으로 결정하지 말고 동일 환경 벤치마크

범용 Spring Boot 백엔드에서 GET/SET, Hash, TTL 중심의 캐시·세션·분산 상태를 새로 도입한다면 Valkey를 기본 후보로 둘 만하다. Redis를 택할 이유는 오랜 인지도 자체가 아니라 Redis 8의 통합 검색·JSON·시계열 기능이나 상용 생태계를 실제로 사용할 때다.

한계와 주의점

Valkey와 Redis의 성능·메모리 수치는 대부분 각 프로젝트나 클라우드 사업자가 발표한 자체 벤치마크다.
Valkey 9.1과 Redis 8.10의 최신 직접 비교가 없어 제품명만으로 성능 우열을 확정할 수 없다.
클라우드 가격은 리전, 노드, 예약, replica, 네트워크와 SLA에 따라 달라진다. 이 문서의 AWS 비율은 2026-08-04 공식 가격 페이지 기준이다.
Redis와 Valkey의 명령·RDB·AOF·모듈 호환성은 사용하는 버전에 따라 달라진다.
라이선스 설명은 일반적인 기술 판단을 위한 요약이며 법률 자문이 아니다.
75~80% 같은 maxmemory 비율과 pipeline 8·16·32는 벤치마크의 출발점이지 보장값이 아니다.

검증이 필요한 주장

Redis와 Valkey의 전 세계 실사용 점유율을 직접 비교할 신뢰할 만한 중립 통계는 아직 없다.
최신 버전의 동일 비용당 처리량과 p99.9 비교는 실제 워크로드 벤치마크가 필요하다.
Spring Data Valkey와 각 Java 클라이언트의 Valkey 9 고유 명령 지원 범위는 버전별로 다시 확인해야 한다.
Redis 8.10 compact hash와 Valkey 9.1 해시 테이블 중 어느 쪽이 실제 데이터에서 효율적인지는 스키마별 측정이 필요하다.

Source Fidelity Notes

핵심 수치를 보존했다: Valkey 9.1.1, Redis 8.10.0, Valkey 9.0의 40%·20%·200%·25%, 2,000노드·10억 RPS, Redis 8.6의 5배·350만 ops/sec·15%·35%·16.7%·30.5%, Valkey 메모리 20.63%와 키당 20~30바이트, AWS 20%·33%·100MB 대 1GB, Valkey 생태계의 약 50개 회사·500만 Docker pull.
라이선스 버전표, 기능 비교, CPU 병목 세 분류, RSS 구성식, headroom 표, TCO 식, eviction 선택표와 관측 지표를 유지했다.
마이그레이션 위험 분류와 8단계 절차, 세 가지 벤치마크 시나리오와 판정 기준을 보존했다.
원문의 반복 설명과 Spring 개인 맞춤형 표현은 일반 독자를 위한 문장으로 압축했다.
압축으로 인한 해석 위험을 줄이려고 벤더 자체 벤치마크와 권장 시작값의 한계를 각 절에 남겼다.