Redis와 Valkey, 한 이름이 둘이 된 이야기

자주 쓰는 가위를 창고 깊숙한 상자에 넣어 두는 사람은 드물어요. 조금 좁아도 손이 바로 닿는 책상 서랍에 둬요. 컴퓨터도 같은 선택을 해요. 오래 보관할 데이터는 넉넉한 데이터베이스에 두고, 자주 찾는 것은 더 빠른 자리에 사본을 올려 둬요.

그 빠른 자리가 메모리이고, 원본의 임시 사본을 거기 두는 방법이 캐시(cache)예요. 다만 상품 가격을 복사해 두었다면 원본 가격이 바뀔 때 사본도 바꿔야겠죠. 이런 값들이 서로 맞는 성질을 정합성이라고 해요. 캐시의 기본 동작을 알았다면 다음으로는 그 저장소를 누가, 어떤 규칙으로 이어 가는지도 봐야 해요. Redis와 Valkey가 갈라진 이야기가 바로 그 질문으로 이어져요.

모두의 책상 위에 올라온 Redis

Redis는 메모리를 중심으로 데이터를 보관하는 프로그램이에요. 웹사이트가 같은 상품 정보를 수천 번 요청받을 때마다 큰 데이터베이스를 뒤지는 대신, Redis가 먼저 답하게 하면 화면을 더 빨리 보여 줄 수 있어요. 구조가 단순하고 응답이 빨라 작은 서비스부터 거대한 서비스까지 널리 쓰였어요.

맡은 일도 캐시 하나에 그치지 않았어요. 로그인한 사람을 기억하는 세션, 점수를 순서대로 보여 주는 순위표, 처리할 일을 차례로 세워 두는 큐(queue)에도 Redis가 자리 잡았어요. 큐는 은행의 대기표처럼 먼저 들어온 일을 순서대로 꺼내기 위한 줄이에요. 사용자는 Redis라는 이름을 몰라도, 로그인 상태가 이어지고 순위가 바로 바뀌는 경험 속에서 이미 Redis를 만나고 있었던 셈이에요.

평온하던 이름이 갈라진 2024년 봄

오랫동안 Redis는 누구나 소스 코드를 읽고 사용하고 고칠 수 있는 오픈소스로 개발됐고, 그 규칙은 BSD 3-Clause라는 라이선스에 담겨 있었어요. 라이선스는 소프트웨어를 누가 사용하고 고치고 다시 나눌 수 있는지 정한 약속이에요. BSD 3-Clause는 그 제약이 적어서 기업도 Redis를 바탕으로 제품과 서비스를 만들기 쉬웠어요.

그러나 Redis를 만드는 회사 Redis Ltd.에는 불편한 장면이 있었어요. 거대한 클라우드 업체들이 Redis를 관리형 상품으로 제공해 수익을 내는 동안, 원래 프로젝트에 돌아오는 몫은 충분하지 않다고 본 것이에요. Redis는 2024년 3월 20일 앞으로 나올 Redis 7.4부터 BSD 대신 Redis Source Available License v2(RSALv2)와 Server Side Public License v1(SSPLv1) 가운데 하나를 고르게 하겠다고 발표했어요. 코드는 계속 볼 수 있었지만, Redis와 경쟁하는 관리형 서비스를 만드는 데에는 새로운 제한이 생겼어요.

회사에는 사업을 지키는 울타리였고, 공동체 일부에는 오래 함께 가꾼 광장의 규칙이 갑자기 바뀐 사건이었어요. Redis도 훗날 이 결정이 공동체와의 관계를 해쳤다고 인정했어요.

발표 뒤 불과 여드레가 지난 3월 28일, Linux Foundation은 Valkey의 출범을 알렸어요. Linux Foundation은 여러 기업과 개발자가 한 회사에 매이지 않고 오픈소스 프로젝트를 운영하도록 돕는 비영리 재단이에요. 기존 오픈소스 Redis 7.2.4의 공개 코드를 복사해 별도 방향으로 이어 가는 포크(fork)가 시작됐고, 이름은 Valkey가 됐어요. Amazon Web Services(AWS), Google Cloud, Oracle, Ericsson, Snap 같은 회사들도 지원에 나섰어요.

이야기는 거기서 끝나지 않았어요. 2024년 11월에는 Redis를 처음 만든 Salvatore Sanfilippo, 활동명 antirez가 Redis로 돌아와 회사와 개발자 공동체를 잇는 역할을 맡았어요. 그리고 2025년 5월 공개된 Redis 8에는 GNU Affero General Public License version 3(AGPLv3)가 세 번째 선택지로 추가됐어요. AGPLv3는 오픈소스 기준을 관리하는 Open Source Initiative가 인정한 라이선스예요. Redis가 예전의 BSD 규칙으로 돌아간 것은 아니지만, 누구나 오픈소스 조건으로 사용할 길은 다시 생겼어요.

닮은 출발점, 달라진 운영자

Valkey는 오픈소스 Redis 7.2.4에서 출발했기 때문에 익숙한 명령과 통신 방식을 이어받았어요. 애플리케이션의 말을 저장소의 명령으로 바꿔 주는 클라이언트 라이브러리도 대체로 그대로 연결할 수 있어요. Valkey의 공식 이전 문서는 오픈소스 Redis 7.2 이하와의 호환을 명시해요.

다만 두 프로젝트가 영원히 같은 제품이라는 뜻은 아니에요. Valkey는 갈라져 나온 시점의 BSD 조건을 그대로 이어받았고 재단이 방향을 정해요. Redis는 앞의 세 선택지 위에 있고 회사가 방향을 정해요. 갈림길 이후 두 쪽은 각자의 기능을 더하며 따로 발전하고 있으므로, 고를 때 보게 되는 것은 결국 세 가지예요.

무엇을 보고 고르나	확인할 것	놓치면
라이선스	내 배포 형태가 그 조건에 걸리는가	재배포나 호스팅 단계에서 뒤늦게 막힌다
관리 주체	앞으로의 방향을 누가 정하는가	필요한 기능이 한쪽에만 생긴다
옮기는 경로	되돌릴 길을 남겨 두었는가	전환 중 문제가 저도 앞으로만 갈 수 있다

평범한 캐시나 세션처럼 오래된 공통 기능을 쓰는 사람에게 둘은 여전히 무척 닮아 있어요. 새로운 기능을 쓰거나 최신 버전 사이를 옮기려는 사람에게는 운영 주체와 라이선스, 달라진 기능을 따로 살펴볼 이유가 생겼어요.

저는 이 이야기를 어떻게 만났나

저는 이 일을 뉴스가 아니라 운영 중인 서비스에서 만났어요. AWS가 대신 관리해 주는 캐시 서비스인 ElastiCache의 Redis를 Valkey로 바꾸는 작업이었어요. 이름만 교체하면 될 것 같았지만, 실제로 신경 쓴 것은 옮기는 순서였어요.

먼저 더는 쓰지 않는 키를 정리했어요. 순서를 그렇게 잡은 이유는 청소가 아니라 산정 때문이었어요. 쓰레기를 안은 채 옮기면 새 환경에 얼마를 잡아야 하는지 알 수 없고, 옮긴 뒤에 줄어든 사용량이 정리 덕인지 전환 덕인지도 구분되지 않아요. 그다음 개발 환경을 먼저 바꿔 명령과 클라이언트가 그대로 도는지 확인하고, 운영을 옮긴 뒤 메모리와 적중률이 예상 범위인지 다시 봤어요.

이때는 원본을 따로 보관하고 캐시를 다시 채울 수 있는 구조라, 사본이 줄어들 때의 영향을 살펴보며 옮길 수 있었어요. 그렇다고 모든 Redis가 비어도 괜찮은 것은 아니에요. 세션이나 아직 처리하지 않은 작업을 유일하게 보관한다면 같은 삭제가 로그인 해제나 작업 유실로 이어질 수 있어요.

돌아보면 제품 이름보다 그 안에 무엇을 맡겼는지가 먼저였어요. 복원할 수 있는 사본인지, 사라지면 되찾을 수 없는 원본인지부터 구별하고 나니 전환할 때 지켜야 할 것도 훨씬 분명해졌어요.