Redis를 떠나 만든 Valkey, 9.1로 어디까지 왔나

Redis 라이선스 사태가 만든 갈림길

인메모리 키-값 스토어의 사실상 표준이던 Redis는 2024년 3월, 오픈소스 라이선스(BSD)를 소스 공개형(SSPLv1·RSALv2 듀얼)으로 바꿨습니다. 코드는 볼 수 있지만 클라우드 사업자가 자유롭게 서비스로 제공하긴 어려워진, 이른바 'source-available' 모델이었죠.

반발한 커뮤니티는 곧바로 움직였습니다. 같은 달 28일, Linux Foundation이 Redis의 오픈소스 대안으로 Valkey 출범을 발표했습니다. 마지막 BSD 버전인 Redis OSS 7.2.4를 기반으로 포크했고, AWS·Google·Oracle·Ericsson·Snap이 후원에 이름을 올렸습니다. 인메모리 스토어를 둘러싼 지형이 하루아침에 갈라진 순간이었습니다.

Valkey란 Linux Foundation의 BSD 포크

Valkey는 Redis에서 갈라져 나온 오픈소스(BSD 3-Clause) 인메모리 데이터스토어입니다. Redis와 같은 RESP 프로토콜과 명령어를 쓰기 때문에, 기존 Redis 클라이언트·도구를 그대로 두고 엔진만 바꾸는 드롭인 대체를 목표로 설계됐습니다.

버전은 2024년 9월 첫 메이저인 8.0으로 시작해, 8.1(2025년 3월)과 9.0(2025년 10월)을 거쳐 왔습니다. 여기서 한 가지 짚을 점이 있습니다. Valkey의 버전 번호는 Redis와 무관하게 독립적으로 매겨집니다. 즉 'Valkey 9.1'은 'Redis 9'가 아니며, Redis의 현재 메이저는 Redis 8입니다. 이름이 비슷해 헷갈리기 쉬운 부분이죠.

9.1이 가져온 것 (2026년 5월 19일)

가장 최신인 Valkey 9.1.0은 2026년 5월 19일 공개됐고, 80명 넘는 기여자가 참여했습니다. 보안·관측성·성능·효율·도구 전반을 손봤는데, 실무에서 체감될 만한 것들을 추리면 다음과 같습니다.

• 성능 — 특정 벤치마크 조건(512바이트 페이로드·다중 IO 스레드·파이프라인)에서 단일 서버 처리량이 초당 약 210만 요청에 도달했습니다. IO 스레딩 통신 모델을 재설계해 워크로드에 따라 최대 17% 향상됐고, 스트림의 XRANGE·XREVRANGE는 최대 30% 빨라졌습니다.

• 메모리 효율 — 내부 포인터 최적화로 128바이트 미만 문자열의 메모리를 최대 20% 절감했고, 정렬 집합(sorted set) 메모리도 최대 10% 줄였습니다.

• 새 명령 3종 — 해시 필드를 원자적으로 읽고 지우는 HGETDEL, 공통 TTL로 여러 키를 한 번에 설정하는 MSETEX, 클러스터 전역 키를 훑는 CLUSTERSCAN이 추가됐습니다.

• 보안·관측성 — 사용자가 실행할 수 있는 명령을 데이터베이스 단위로 제한하는 접근 제어가 들어왔고, Lua 스크립팅 엔진을 별도 모듈로 분리했습니다. 로그를 JSON 형식으로 남기는 log-format json과 메인·IO 스레드 사용량 메트릭도 추가됐습니다. 또 TLS 인증서 만료일을 INFO 명령으로 확인하고 무중단으로 인증서를 자동 갱신하는 기능도 들어와, 인증서 만료로 인한 장애를 줄이는 데 도움이 됩니다.

한편, Redis도 돌아왔습니다

Valkey 이야기를 하면서 Redis가 그 뒤 어떻게 됐는지도 빼놓을 수 없습니다. Redis는 2025년 5월 Redis 8을 내놓으며 AGPLv3를 추가해 오픈소스로 복귀했습니다. 다만 주의할 점은, 예전의 BSD로 되돌린 것이 아니라는 사실입니다. 현재 Redis는 RSALv2·SSPLv1·AGPLv3를 함께 제공하는 '트라이 라이선스' 형태입니다.

AGPLv3는 OSI가 인정하는 오픈소스 라이선스이지만, 네트워크로 제공하는 서비스에도 소스 공개 의무가 미칠 수 있는 강한 카피레프트입니다. 누구나 자유롭게 쓰고 재배포할 수 있는 BSD 계열(Valkey)과는 성격이 다르죠. 그래서 "Redis가 다시 오픈소스가 됐으니 똑같다"고 단순화하기보다, 두 진영의 라이선스 성격 차이를 도입 단계에서 따져보는 편이 정확합니다.

도입 관점 어떻게 봐야 하나

실무에서 둘 중 무엇을 고를지는 결국 운영 환경과 라이선스 정책에 달려 있습니다. 몇 가지만 짚어두겠습니다.

• 매니지드 서비스 — AWS는 ElastiCache·MemoryDB for Valkey를, Google Cloud는 Memorystore for Valkey를 정식 제공합니다. 직접 운영이 부담스럽다면 클라우드 매니지드로 시작할 수 있습니다.

• 호환성 — Valkey는 Redis와 프로토콜·명령이 호환돼 마이그레이션 부담이 비교적 작습니다. 다만 RediSearch·RedisJSON 같은 Redis Stack 모듈을 쓰고 있다면 이야기가 달라집니다. 이 모듈들은 Valkey 코어에 포함돼 있지 않아, 그 기능에 의존하는 경우 '엔진만 교체'하는 드롭인 대체가 성립하지 않을 수 있습니다. 사용 중인 명령·모듈의 호환 여부를 먼저 확인해야 합니다.

• 라이선스 — 자유로운 재배포가 중요하면 BSD인 Valkey가, Redis 생태계의 상용 모듈·지원이 필요하면 Redis가 맞을 수 있습니다. 정답이 하나는 아닙니다.

어떤 엔진을 쓰든 변하지 않는 것도 있습니다. 인메모리 스토어는 메모리 관리와 이중화 설계가 안정성의 핵심입니다. 메모리 한계나 OOM으로 서버가 죽는 상황은 Redis든 Valkey든 똑같이 찾아오니, 엔진 선택만큼 운영 정책을 함께 점검하는 것이 중요합니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)