나는 올해 초 회사 인프라에서 Redis를 Valkey로 교체하는 작업을 했다. 5명짜리 팀, AWS 기반 스택, Redis 7.x를 캐싱과 세션 스토어로 쓰고 있었다. 처음엔 “오픈소스 포크니까 거의 똑같겠지”라고 생각했는데—나중에 알고 보니 그게 맞기도 하고 아니기도 했다.
2024년 3월, Redis가 오픈소스가 아니게 된 날
시작은 2024년 3월이었다. Redis, Inc.가 Redis의 라이선스를 바꿨다. 기존 BSD 3-Clause에서 SSPL(Server Side Public License)과 RSALv2(Redis Source Available License) 듀얼 라이선스 체계로.
BSD는 말 그대로 자유 소프트웨어였다. 어떤 회사든 Redis를 서비스에 탑재해서 돈을 벌어도 아무 제약이 없었다. AWS ElastiCache, Google Cloud Memorystore, Azure Cache for Redis가 수십억 달러짜리 서비스를 Redis 위에 올린 게 그래서 가능했다.
SSPL은 다르다. MongoDB가 먼저 채택했던 라이선스인데, OSI(Open Source Initiative)는 이걸 오픈소스로 인정하지 않는다. 핵심 조항이 뭐냐면—이 소프트웨어로 서비스를 운영한다면, 그 서비스를 구성하는 모든 소스코드를 공개해야 한다는 것이다. AWS 입장에서는 ElastiCache 전체 코드를 공개하라는 얘기가 되니, 사실상 클라우드 제공업체를 겨냥한 조항이었다.
Redis, Inc.의 입장도 이해는 간다. 오픈소스 커뮤니티가 수십 년 쌓아온 걸 클라우드 업체들이 가져다 관리형 서비스로 팔면서 코드 기여는 거의 없었으니까. 그 불만이 쌓여서 나온 결정이었다. 정당하냐 아니냐는 별론으로 하고.
그런데 그 결정의 부작용이 예상보다 컸다.
AWS와 구글이 Linux Foundation을 선택한 건 우연이 아니다
라이선스 변경 발표 직후, 핵심 기여자들이 빠르게 움직였다. Redis의 원 창시자인 Salvatore Sanfilippo(antirez)는 이미 2020년에 Redis Inc.를 떠난 상태였는데, 이번 라이선스 변경에 대해 공개적으로 불만을 표했다. 커뮤니티 분위기도 급격히 냉각됐다. 그리고 한 달도 안 돼서 Linux Foundation이 Valkey 프로젝트를 발표했다. 2024년 3월 26일이었다.
초기 후원사 명단이 꽤 인상적이었다. AWS, Google Cloud, Oracle, Ericsson, Snap. AWS와 구글은 동기가 명확했다—관리형 Redis 서비스를 계속 운영하려면 오픈소스 기반이 필요했으니까. Linux Foundation 아래 두면서 중립적인 거버넌스를 확보한 게 핵심이었다. 어느 한 회사가 나중에 또 라이선스를 바꿀 수 없게.
Valkey의 첫 번째 릴리스는 7.2.5였다. Redis 7.2.4 코드베이스에서 포크한 것. 이름은 “Value” + “Key”의 합성어라고 한다.
솔직히 처음엔 “그냥 이름만 바꾼 Redis 아니야?”라고 생각했다. 그게 틀린 말은 아니었는데—Valkey가 이후로 독자적인 방향으로 꽤 빠르게 움직였다. Valkey 8.0이 2024년 후반에 나왔고, I/O 스레드 모델을 크게 개선했다. 기존 Redis의 단일 스레드 이벤트 루프 구조를 유지하면서도 네트워킹 레이어에서 멀티스레딩을 더 공격적으로 활용하는 방식으로. 그때부터 “아, 이게 진짜 독립 프로젝트구나” 싶었다.
2주 동안 프로덕션에 올려보니—예상치 못했던 부분들
우리 팀이 Valkey로 넘어가기로 한 건 올해 1월이었다. AWS가 ElastiCache에서 Valkey를 공식 지원하기 시작했고, MemoryDB for Redis가 슬그머니 “MemoryDB for Valkey”로 이름을 바꾸고 있었다. 클라우드 인프라 방향성이 그쪽으로 가는 게 보였다.
마이그레이션 자체는 생각보다 훨씬 쉬웠다. RESP(REdis Serialization Protocol)가 그대로라서 기존 Redis 클라이언트—우리는 Node.js에서 ioredis를 쓰고 있었다—를 그냥 연결 엔드포인트만 바꿔도 됐다.
// 변경 전 (Redis)
const client = new Redis({
host: 'my-redis.cache.amazonaws.com',
port: 6379,
});
// 변경 후 (Valkey) — 클라이언트 코드는 한 줄도 안 건드렸다
const client = new Redis({
host: 'my-valkey.cache.amazonaws.com', // 엔드포인트만 변경
port: 6379,
});
// 연결 후 서버 확인
const info = await client.call('HELLO');
// { server: 'valkey', version: '8.0.1', proto: 2, ... }
명령어가 동일하니 코드 변경은 없었다. 처음엔 이게 오히려 불안했다. “이렇게 쉬워도 돼?” 싶어서 하루 내내 로그 뒤졌는데 아무 문제가 없었다.
진짜 문제는 스테이징 환경에서 Sentinel을 직접 설정할 때 생겼다. valkey-sentinel이 별도 바이너리로 분리됐고, 설정 파일 일부 옵션 이름이 미묘하게 달라져 있었다. 기존 redis-sentinel.conf를 그대로 복사했더니 deprecated 경고가 줄줄이 떴다. 동작은 했는데—공식 문서가 아직 Redis 관련 자료만큼 풍부하지 않아서 GitHub 이슈를 직접 뒤져야 하는 순간들이 있었다. 이건 미리 알았으면 한 시간은 절약했을 것 같다.
모니터링 쪽도 확인이 필요했다. 우리가 쓰던 Datadog 에이전트의 Redis 통합은 Valkey에서도 그냥 작동했는데(INFO 명령어 출력 형식이 거의 동일하다), 대시보드에 여전히 “Redis”라고 표시되는 건 좀 어색했다. 기능 문제는 아니지만, 팀원이 처음 보고 “Redis로 롤백된 거야?” 하고 물었다.
그리고 진짜 예상 못 한 건 성능이었다. 내심 “포크니까 비슷하겠지”라고 생각했는데—Valkey 8.x의 I/O 멀티스레딩 덕분에 high-throughput 시나리오에서 차이가 났다. 우리 부하 테스트에서 초당 약 150k RPS 정도 되는 시점부터 Valkey가 Redis 7.2x보다 처리량이 10~15% 정도 높게 나왔다. p99 지연시간도 고부하 구간에서 Valkey 쪽이 약간 낮았다. 잘 됐지만 솔직히 몰랐다가 알게 된 부분이었다.
Redis와 Valkey, 2026년 기준으로 실제로 다른 점
명령어 호환성: 거의 완벽하다. GET, SET, HSET, ZADD, Lua 스크립팅, Pub/Sub, Streams—다 된다. Redis Cluster 프로토콜도 동일하다. redis-py, ioredis, jedis 같은 클라이언트를 그대로 쓸 수 있다. 단, Redis 7.4 이후에 추가된 일부 기능들은 Valkey에서 없거나 구현 방식이 다를 수 있으니 확인이 필요하다.
Redis Stack 문제: 이게 좀 복잡하다. Redis Stack은 Redis, Inc.가 독자적으로 관리하는 모듈 묶음인데—RediSearch(전문 검색), RedisJSON, RedisTimeSeries 등이 포함된다. 이쪽 라이선스는 더 제한적이다. Valkey 생태계에서 대응 모듈들이 나오고는 있는데, 2026년 현재 Redis Stack 수준의 완성도는 아니다. 전문 검색이 핵심인 프로젝트라면 이 부분을 신중하게 봐야 한다.
Cluster 모드 트랜잭션: Valkey도 Redis Cluster와 동일하게 cross-slot 연산 제약이 있다. MULTI/EXEC 트랜잭션이나 파이프라인을 Cluster 모드에서 쓸 때 같은 해시 슬롯에 키를 몰아넣는 패턴이 필요하다.
# Valkey Cluster에서 같은 슬롯 보장 (Redis와 완전히 동일한 방식)
# 중괄호 {} 안의 내용으로 해시 슬롯이 결정된다
pipe = client.pipeline()
pipe.set("{user:1234}:session", session_data)
pipe.set("{user:1234}:profile", profile_data)
pipe.expire("{user:1234}:session", 3600)
results = pipe.execute() # 같은 슬롯 → atomic 처리 가능
Redis에서 이 패턴 쓰던 사람이라면 Valkey에서도 그냥 쓰면 된다. 완전히 동일하다.
생태계 성숙도: 이건 인정해야 한다. Redis는 10년 넘게 쌓인 커뮤니티 자료, StackOverflow 답변, 블로그 포스트가 압도적으로 많다. Valkey 관련 구체적인 설정 문제를 검색하면 아직 답이 없는 경우가 있다. GitHub Issues가 1차 자료가 되는 상황이고, 당분간은 이걸 감수해야 한다.
내 결론: 신규 프로젝트라면 Valkey다
6개월 전이었으면 더 망설였을 것 같다. 지금은 아니다.
신규 프로젝트라면 Valkey를 쓴다. 라이선스 걱정 없고, AWS와 GCP 모두 1급 지원하고, 성능도 뒤지지 않는다. 일반적인 캐싱, 세션 스토어, Pub/Sub, Rate limiting 용도라면 지금도 충분하다. 오픈소스 생태계가 2년 뒤 어디 있을지를 놓고 베팅을 해야 한다면, Valkey 쪽이 더 안전하다고 본다.
기존 Redis 7.2 이하 사용자는 급하게 바꿀 필요 없다. 라이선스 변경 전 버전이니 BSD가 그대로 적용된다. 마이그레이션 계획은 세워두되 지금 당장 서두를 이유는 없다.
Redis 7.4+ 사용자는 RSALv2를 한 번 읽어보길 권한다. 내부 서비스로만 쓴다면 대부분 문제없다. 다만 Redis를 SaaS 형태로 제공하는 경우라면 법무팀에 확인해보는 게 낫다. 우리 팀도 그랬고, “문제는 없지만 Valkey가 더 깔끔하다”는 결론이 나왔다.
Redis Stack 핵심 사용자: 이건 신중하게. RediSearch를 프로덕션에서 쓰고 있다면 Valkey 이전이 단순 연결 변경이 아니다. Elasticsearch, OpenSearch, Meilisearch 같은 대안을 먼저 평가하는 데 시간을 써야 한다.
나는 2주 테스트 후 프로덕션에 올렸고 지금 두 달째 별 탈 없이 쓰고 있다. 우리 팀 규모와 트래픽에서 그렇다는 거고, 대형 서비스라면 다른 고려사항이 있을 수 있다. 하지만 적어도 “Valkey는 실험적”이라는 말은 2026년엔 더 이상 맞지 않는다.