IT/DB 운영

Redis vs Valkey, 지금 갈아탈 때인가

gfrog 2026. 8. 2. 00:19

작년 여름부터 팀 회의 때마다 반복해서 나오는 주제가 있다. "우리도 Valkey로 옮겨야 하지 않을까요?" 처음에는 라이선스 이슈 정도로 가볍게 봤는데, 2026년이 되니 이야기가 좀 달라졌다. AWS ElastiCache 기본값이 Valkey로 바뀌고, Aiven이 15,000대 서버를 옮겼다는 얘기까지 들리니 무시하기 어려워졌다.

우리 팀은 캐시 클러스터 40여 대, 세션 스토어 12대, 그리고 실시간 랭킹용 소규모 Redis 몇 개를 굴리고 있다. 각각의 워크로드가 조금씩 달라서 하나의 결론을 내기가 애매했다. 이 글은 그동안 실무자로서 두 진영을 비교하면서 정리한 내용이다. 결론부터 말하면 "무조건 갈아타야 한다"도 아니고 "굳이?"도 아니다.

라이선스, 이게 진짜 이슈였다

Redis 7.2까지는 BSD 3-clause였다. 그런데 2024년 3월에 SSPL과 RSAL로 이중 라이선스가 걸렸고, 2025년 5월에는 AGPLv3까지 포함한 트리 라이선스로 정리됐다. AGPL이 추가된 게 "다시 오픈소스로 돌아왔다"고 마케팅되는데, 사실 트리 라이선스 안에서 하나를 선택해야 하는 구조라 완전히 자유롭지는 않다.

Valkey는 여기서 갈라져 나왔다. Linux Foundation이 관리하고, BSD 3-clause 그대로 유지된다. 특정 회사가 어느 날 갑자기 라이선스를 바꿀 수 없다는 것. 이게 진짜 핵심이다.

법무팀이 이 부분을 정리하는 데 두 달이 걸렸다. 결론은 이랬다.

  • 사내 인프라 캐시: AGPL 조항을 뜯어보니 크게 걸릴 게 없다. Redis 8 계속 써도 문제 없음
  • 관리형 SaaS 형태로 외부 제공하는 제품군: SSPL/AGPL 조합이 애매하다. 여기는 Valkey가 안전

우리처럼 B2B SaaS를 부분적으로 운영하는 팀이면 이 구분을 먼저 해봐야 한다. 아니면 나중에 감사팀에서 지적 나올 수 있다.

성능은 정말 차이 나는가

여러 벤치마크가 돌아다니는데, Valkey 8.1이 Redis 8보다 대략 8% 정도 빠르고 메모리 효율은 15~20% 좋다는 게 대체적인 결과다. 근데 여기서 조심해야 할 게 있다. 벤치마크는 대부분 단일 노드, 단순 GET/SET 위주로 돌린다.

실제로 우리 팀에서 스테이징에 Valkey 8.1을 올려서 프로덕션 트래픽 30%를 미러링해봤다. 결과는 이랬다.

  • 캐시 워크로드(GET 위주, 5~10KB 페이로드): P99 레이턴시 12% 감소, CPU 사용률 8% 감소
  • 세션 스토어(GET/SET 반반, TTL 짧음): 큰 차이 없음. P99가 오차 범위 내에서 왔다갔다
  • Lua 스크립트 많이 쓰는 랭킹 클러스터: 오히려 Valkey가 3~4% 느렸다. 원인은 아직 파악 중

세 번째 케이스가 흥미로웠다. Valkey 팀이 Lua 스크립트 실행 경로를 일부 리팩터링했는데, 아주 특정한 스크립트 패턴에서는 아직 최적화가 덜 된 것 같다. 이런 게 있으니 무조건 "Valkey가 빠르다"고 단정하기는 어렵다.

마이그레이션 난이도

RDB 파일 호환된다. AOF도 호환된다. CLUSTER SLOTS, INFO, 관리 명령어 다 그대로 나온다. 이론상으로는 replica로 붙였다가 failover 한 번이면 끝이다.

실제로 우리도 세션 스토어부터 옮겨봤는데 이 과정에서 걸리 게 몇 가지 있다.

# Redis primary에 Valkey replica 붙이기
valkey-cli -h valkey-node-01 REPLICAOF redis-primary.internal 6379

# 동기화 완료 확인
valkey-cli -h valkey-node-01 INFO replication | grep master_sync_in_progress

# failover는 sentinel이 알아서 처리
redis-cli -h sentinel-01 -p 26379 SENTINEL failover mymaster

여기까지는 문제 없다. 문제는 클라이언트 라이브러리다.

  • Jedis, Lettuce (JVM): 아무 문제 없음. Valkey를 Redis로 인식한다
  • redis-py: 3.x 이하 버전에서 특정 커맨드 파싱 이슈. 4.x 이상은 괜찮음
  • go-redis v9: OK
  • ioredis: OK, 근데 클러스터 모드에서 노드 discovery 로그가 좀 이상하게 찍힘

우리는 legacy 서비스 하나가 redis-py 3.5를 쓰고 있었다. 이걸 업그레이드하는 데 예상보다 오래 걸렸다. 다른 팀 코드였는데 pin된 버전이 있어서 의조성 지옥이었다. 마이그레이션 계획 세울 때 클라이언트 인벤토리 먼저 뽑아보는 걸 강력 추천한다.

AWS 환경에서는 어떤가

ElastiCache Serverless와 신규 클러스터에서 Valkey가 기본값이 됐다. Redis OSS 클러스터도 여전히 지원하지만, 신규 노드 타입이 Valkey 우선으로 나오는 걸 보면 방향은 명확하다.

가격도 다르다. 우리 스팟 체크로는 동급 노드 기준 Valkey가 20% 정도 싸다. Amazon Ads 팀이 45% 비용 절감했다는 사례가 화제였는데, 그건 아키텍처 최적화까지 포함된 수치라 액면 그대로 받아들이면 안 된다. 순수 노드 가격 차이만 놓고 봐도 대규모 캐시 팜에서는 무시하기 어려운 금액이 나온다.

MemoryDB도 Valkey 지원한다. 우리는 여기까지는 안 옮겼다. MemoryDB 자체가 durable하다는 특성 때문에 도입한 곳들이라 굳이 라이선스 이슈로 옮길 유인이 크지 않았다.

그래서 어떻게 결정했나

우리 팀 기준으로는 이렇다.

캐시 클러스터 40대는 순차적으로 Valkey 8.1로 옮기고 있다. 라이선스 정리 + 비용 절감이 둘 다 매력적이었다. 3분기 안에 마무리 목표.

세션 스토어는 다음 유지보수 창에 옮길 예정. 큰 이유는 없고, 어차피 옮길 거 한 번에 정리하려고.

Lua 스크립트 많이 쓰는 랭킹 클러스터는 보류. 성능 회귀 원인을 좀 더 파악한 다음에 결정하려고 한다. Valkey 8.2에서 개선된다는 이야기도 있어서 일단 지켜보는 중이다.

Redis Enterprise 계약된 곳(다른 팀 소관)은 계약 만료 시점에 재검토. 상용 지원이 필요한 워크로드까지 굳이 뒤집을 이유는 없다.

아직 정답은 없다

라이선스 자체가 문제가 되지 않는 조직이라면, Redis 8을 계속 쓰는 것도 여전히 합리적인 선택이다. 벡터 검색이나 JSON 모듈 같은 걸 Redis Stack에서 쓰던 팀이면 마이그레이션이 훨씬 복잡해진다. 이 부분은 아직 Valkey 진영의 대응이 완전하지는 않다.

반대로 우리처럼 대규모 캐시 팜을 굴리고, 오픈소스 원칙과 비용 절감 둘 다 신경 쓰는 팀이라면 옮길 유인은 확실하다. 다만 "다 잘 될 거야"라고 밀어붙이지 말고 워크로드별로 나눠서 검증하는 게 안전하다. 우리도 Lua 케이스에서 한 번 데였다.

혹시 다른 팀에서 옮기신 분들 있으면, 클라이언트 라이브러리 호환성이나 관측성 도구(Datadog, New Relic 쪽 Redis integration이 Valkey를 잘 인식하는지)에 대한 경험 공유 부탁드립니다. 이 부분은 아직 정보가 파편적이라.

저작자표시 비영리 동일조건 (새창열림)