Valkey 전환이 만든 Redis 생태계의 변화와 성능 검증

Redis 라이선스 변경 이후 Valkey가 클라우드 관리형 캐시에서 채택된 배경과 성능, 마이그레이션 설계를 정리한다.

2026-08-14 · 최초 발행 2026-05-05

라이선스 선택이 바꾼 캐시 생태계

Redis가 2024년 3월 BSD-3-Clause에서 RSALv2·SSPLv1 이중 라이선스로 이동한 뒤, Linux Foundation 산하에서 Valkey 포크가 출범했다. Redis는 2025년 5월 AGPLv3를 추가하며 오픈소스 복귀를 선언했지만, AWS·Google Cloud·Oracle Cloud는 이미 Valkey를 관리형 서비스의 기본 엔진으로 채택한 상태였다.

이 변화는 라이선스 정책만의 문제가 아니다. 관리형 서비스를 운영하는 사업자에게는 소스 공개 의무와 서비스 제공 조건이 제품 전략에 직접 연결된다. Valkey 8.0이 초당 100만 요청을 넘긴 벤치마크 역시 이 선택이 기술적으로도 독립적인 흐름을 갖게 했음을 보여준다.

SSPL과 AGPLv3가 남긴 운영상 제약

Redis Ltd.는 2024년 3월 Redis 7.4부터 RSALv2(Redis Source Available License v2)와 SSPLv1(Server Side Public License)을 채택했다. MongoDB가 고안한 SSPL은 소프트웨어를 서비스로 제공할 때 전체 스택의 소스 코드를 공개해야 하는 조항을 포함한다. 이 때문에 사실상 오픈소스 정의(OSD)를 충족하지 못하는 라이선스로 분류된다.

2025년 5월 Redis는 전략을 바꿔 AGPLv3를 세 번째 선택지로 추가했다. Redis 8.0 사용자는 RSALv2, SSPLv1, AGPLv3 중 하나를 고를 수 있다. AGPLv3는 OSI 승인 라이선스라 기술적으로 오픈소스에 해당하지만, SaaS 사업자에게는 네트워크 조항이 남는다.

AGPLv3 소프트웨어를 수정해 네트워크로 사용자에게 제공하면 수정한 소스 코드를 공개해야 한다. GPL이 소프트웨어 배포 시점에 소스 공개 의무를 부과하는 것과 달리, AGPL은 네트워크 접근만으로 의무가 발생한다. Redis를 수정 없이 백엔드 캐시로 쓰는 경우에는 의무가 없지만, Redis 코드에 패치를 적용하거나 커스텀 모듈을 내장한 서비스를 제공하는 경우에는 판단이 달라진다.

상업적 예외 라이선스(Commercial Exception License)를 구매하는 것이 이 의무를 우회하는 유일한 공식 경로다. Redis Ltd.는 이를 통해 대형 클라우드 사업자와 엔터프라이즈 SaaS 기업에서 수익을 확보하려 했지만, AWS·Google·Oracle은 이미 Valkey를 선택한 뒤였다.

관리형 캐시 서비스가 Valkey로 이동한 이유

AWS ElastiCache는 2024년 6월부터 Valkey를 지원 엔진으로 추가했고, 이후 빠르게 기본 권장 엔진으로 전환했다. AWS는 Valkey 채택 고객이 ElastiCache 비용을 최대 60% 절감할 수 있다고 공식 블로그에서 밝혔다. 노드 기반 클러스터는 20%, ElastiCache Serverless는 33% 낮은 가격으로 책정되어 있다.

Google Cloud는 Memorystore for Valkey를 정식 출시했으며 Valkey 7.2, 8.0, 9.0을 지원한다. 기존 관리형 Redis인 Memorystore for Redis와는 별도 서비스로 운영하고, Valkey 전환을 위한 마이그레이션 가이드도 공식 문서로 제공한다.

Oracle Cloud Infrastructure도 Valkey 기반 관리형 캐시 서비스를 제공한다. Oracle은 Linux Foundation 산하 Valkey 프로젝트의 주요 후원사이며, 50개 이상의 기업이 거버넌스 모델에 기여하고 있다.

Valkey는 Linux Foundation이 관리하고 BSD-3-Clause 라이선스를 유지한다. 상업적 사용에 제약이 없고 네트워크 조항이나 소스 공개 의무도 없다. 관리형 서비스를 제공하는 클라우드 사업자에게는 라이선스 리스크를 줄이는 명확한 선택지다.

처리량과 지연 시간에서 확인된 변화

Valkey 개발팀은 초당 100만 요청 돌파를 목표로 아키텍처를 개편했다. Valkey 공식 블로그는 AWS Graviton3에서 Valkey 8.0이 초당 119만 요청(1.19M RPS)을 달성했다고 밝혔다. Valkey 7.2의 36만 RPS와 비교하면 230% 증가한 수치이며, 평균 지연 시간은 1.792ms에서 0.542ms로 69.8% 감소했다.

2026년 초 기준의 독립적인 제3자 벤치마크에서는 Valkey 8.1.1과 Redis 8.0을 직접 비교했다. SET 연산에서 Valkey는 999.8K RPS, Redis는 729.4K RPS를 기록해 약 37% 차이를 보였다. 읽기 p99 지연 시간도 Valkey가 60% 이상 빠른 결과를 나타냈다.

메모리 사용량도 비교 대상이다. 5,000만 엔트리에서 Valkey는 3.77GB, Redis는 4.83GB를 사용해 약 28% 차이가 났다. Momento의 분석에 따르면 이 차이는 엔트리 수가 늘수록 더 벌어진다.

여기서 “3배 처리량”은 Valkey 7.2와 Valkey 8.0의 비교 결과다. Redis 최신 버전과 비교해 절대적 우위가 3배라는 뜻은 아니다. 다만 같은 시기 Redis의 성능 개선 폭보다 Valkey의 개선 기울기가 훨씬 가팔랐다는 점은 구분해 볼 필요가 있다.

230% 향상37% 차이Valkey 7.2360K RPSValkey 8.01,190K RPSRedis 8.0729K RPSValkey 8.1999K RPSp99 지연 0.542msp99 지연 60%+ 개선

메인 스레드를 실행에 집중시키는 방식

Valkey의 성능 향상은 파라미터 조정보다 아키텍처 재설계에 가깝다. Redis는 단일 스레드 이벤트 루프 모델을 기반으로 한다. 일관성 관리를 단순하게 만들지만, 멀티코어 CPU의 병렬 처리 능력을 충분히 쓰기 어렵다는 한계가 있다. Redis 6.0에서 I/O 멀티스레딩이 들어왔어도 커맨드 실행은 메인 스레드가 맡는다.

Valkey 8.0은 I/O 스레드의 역할을 소켓 읽기·쓰기에서 커맨드 초기 파싱(parsing)까지 확장했다. 메인 스레드는 실제 커맨드 실행에 집중할 수 있고, 이 분리가 처리 속도 개선으로 이어진다.

실행 경로는 여전히 단일 메인 스레드에 둔다. 복잡한 동기화 문제를 피하면서 I/O 스레드는 네트워크 입출력과 파싱처럼 분리 가능한 작업만 담당한다. 활성 I/O 스레드 수는 부하에 맞춰 동적으로 조정된다.

비동기 메모리 해제(async memory deallocation), 개선된 데이터 구조 인코딩, listpack 기반 소규모 컨테이너 최적화도 함께 적용됐다. Valkey 8.1에서는 메모리 할당자 개선으로 대용량 데이터셋의 메모리 효율을 더 높였다.

동적 스케일네트워크 요청I/O 스레드(읽기·파싱·쓰기)메인 스레드(커맨드 실행)데이터 구조(listpack·ziplist·hashtable)복제 버퍼I/O 스레드 N개비동기 메모리 해제

ElastiCache 전환에서 점검할 운영 경로

Valkey는 Redis API와 완전히 호환되므로 클라이언트 라이브러리를 바꾸지 않고 엔드포인트를 교체할 수 있다. 다만 운영 전환은 호환성 확인만으로 끝나지 않는다.

기존 ElastiCache Redis 클러스터를 Valkey로 옮기는 방식은 블루-그린 배포와 인플레이스 업그레이드(in-place upgrade)로 나뉜다. 블루-그린 방식은 새 Valkey 클러스터를 만들고 데이터를 복제한 뒤 트래픽을 전환한다. 인플레이스 업그레이드는 기존 클러스터를 Valkey 버전으로 올린다. AWS는 롤백 경로를 확보할 수 있는 블루-그린 방식을 권장한다.

AOF(Append Only File)와 RDB 스냅샷 설정은 Valkey에서도 동일하게 적용된다. Valkey 8.0부터 AOF 쓰기 성능이 개선됐으므로 기존 fsync 설정은 내구성과 성능의 균형 관점에서 다시 검토할 수 있다.

INFO 명령의 출력 포맷은 Redis와 거의 같다. 기존 Redis 모니터링 대시보드를 대부분 재사용할 수 있지만, I/O 스레드 활용률처럼 Valkey에 추가된 지표는 별도로 구성하는 편이 권장된다.

블루-그린데이터 복제엔드포인트 전환(코드 변경 없음)검증ElastiCacheRedis 7.xElastiCacheValkey 8.xRDB 스냅샷전송애플리케이션마이그레이션 완료비용 20~60% 절감

포크가 독립적인 선택지가 되기까지

Valkey 사례에서 먼저 눈에 띄는 것은 거버넌스의 중립성이다. Linux Foundation이 프로젝트를 관리하면서 특정 기업 이해관계에 종속되지 않는 신뢰를 만들었고, AWS·Google·Oracle처럼 경쟁 관계의 기업들도 같은 프로젝트에 기여할 수 있었다.

BSD-3-Clause의 명확성도 핵심이다. 상업적 이용과 네트워크 제공에 제약이 없다는 점은 AGPLv3를 선택한 Redis와의 결정적 차이로 작용한다.

Redis 클라이언트 라이브러리와 완전히 호환되는 API는 전환 비용을 낮춘다. 사용자는 엔드포인트 변경 외에 추가 작업을 거의 하지 않아도 된다. 동시에 Valkey는 단순한 복사본에 머무르지 않고 I/O 스레드 개선, 메모리 효율화, 독립적인 릴리스 주기를 발전시켰다. Valkey 9.0은 2025년 10월 독자적으로 출시됐다.

Redis의 라이선스 변경과 Valkey 포크는 오픈소스 지속 가능성을 둘러싼 구조적 갈등을 드러냈다. AWS, Google Cloud, Oracle의 선택은 BSD 라이선스의 명확성과 Linux Foundation 거버넌스에 대한 신뢰를 보여준다. Valkey 8.0의 230% 처리량 향상과 메모리 효율 개선까지 고려하면, 새 Redis 기반 시스템이나 기존 ElastiCache 운영 환경에서 Valkey 마이그레이션은 라이선스 리스크 제거와 비용 절감을 함께 검토할 수 있는 경로다.

Sources

ValkeyRedisElastiCache오픈소스 라이선스캐시