Redis와 Valkey: SSPL 전환이 MongoDB와 반대로 끝난 이유

Fedora 41부터 배포판 저장소에서 Redis 자리를 Valkey가 대신합니다.

Redis가 깔려 있던 시스템을 업그레이드하면 valkey-compat 패키지가 설정과 데이터를 옮깁니다. 흔한 구성이라면 바뀐 줄도 모르고 지나가도록 설계돼 있습니다. Arch는 [extra] 저장소에서 Redis를 Valkey로 교체했고, Debian 13과 Ubuntu 24.04 이후에도 Valkey가 기본 저장소에 들어 있습니다.

이 교체를 결정한 개발자는 아무도 없습니다. 라이선스 문서를 한 줄도 읽지 않아도 스택은 이미 바뀌어 있습니다.

개발자가 라이선스를 안 읽어도 결정이 끝나는 경로

라이선스 변경 소식이 뜨면 대개 법무 문제로 분류합니다. 우리가 이걸 재배포하는가, 사내에서만 쓰는가, 그럼 해당 없겠네. 여기서 검토가 끝납니다.

빠진 고리가 있습니다. 라이선스는 패키지 저장소를 거쳐 기술 결정으로 번역됩니다. 배포판 관리자는 OSI 승인 라이선스가 아닌 소프트웨어를 기본 저장소에 둘 수 없고, 그래서 패키지가 빠지거나 교체됩니다. 그 결과가 apt install 한 줄에 도착합니다.

사슬을 적으면 이렇습니다. 라이선스 변경, 배포판 정책 위반, 패키지 교체, 베이스 이미지 변경, CI와 프로덕션. 이 사슬 어디에도 우리 팀의 판단이 들어갈 자리가 없습니다. 그래서 저는 라이선스 변경을 법무 이슈가 아니라 공급망 이벤트로 보는 편이 맞다고 봅니다.

라이선스 변경 8일 뒤에 나온 포크

2024년 3월 20일, Redis Inc.는 라이선스를 BSD-3-Clause에서 RSALv2와 SSPLv1 이중 체제로 바꿨습니다. 목적은 분명했습니다. 클라우드 업체가 Redis를 관리형으로 팔아 수익을 가져가면서 돌려주는 것이 없는 구조를 끊겠다는 것이었습니다.

3월 28일, 리눅스 재단이 Valkey를 발표했습니다. 8일 만입니다. Redis 7.2.4에서 갈라져 나왔고, 라이선스는 BSD-3-Clause 그대로입니다. AWS, 구글 클라우드, 오라클, 에릭슨, 스냅이 붙었습니다.

숫자보다 중요한 건 명단입니다. 기술 리더십 위원회가 전직 Redis 메인테이너들로 채워졌습니다. Madelyn Olson은 Redis 메인테이너였고 지금은 AWS 소속이며, Viktor Söderqvist는 co-maintainer였고 에릭슨 소속입니다. 외부인이 코드를 복제한 게 아니라 만들던 사람들이 자리를 옮긴 쪽에 가깝습니다.

같은 수를 두고 반대로 끝난 MongoDB

2018년 10월, MongoDB는 AGPLv3에서 SSPL로 옮겼습니다. 명분은 6년 뒤 Redis가 댄 것과 같습니다.

결과가 달랐습니다. MongoDB 코드를 이어받는 포크는 끝내 나오지 않았습니다. AWS는 대신 DocumentDB를 만들었는데, MongoDB 통신 규약에 맞춰 드라이버는 그대로 쓸 수 있지만 내부는 다른 엔진입니다. 오픈소스 쪽에서 나온 대안도 포크가 아니었습니다. FerretDB는 MongoDB 코드를 가져오는 대신 규약을 SQL로 번역해 PostgreSQL 위에서 돌립니다.

그리고 MongoDB는 지금도 SSPL입니다. 문서형 데이터베이스 1위 자리도 그대로입니다.

	MongoDB (2018)	Redis (2024)
이전 라이선스	AGPLv3	BSD-3-Clause
바꾼 라이선스	SSPL	RSALv2 + SSPLv1
코드 기반 포크	나오지 않음	Valkey, 8일
클라우드 업체 대응	별도 엔진으로 규약만 구현	포크에 합류
배포판 기본 패키지	제거된 채로 유지	Valkey로 교체
현재	SSPL 유지	AGPLv3 추가

배포판은 두 번 다 같은 결정을 했습니다

여기서 흔한 오해가 하나 갈립니다. Redis는 배포판에서 쫓겨났고 MongoDB는 무사했다고 정리하면 사실이 아닙니다.

배포판들은 MongoDB에도 똑같이 했습니다. Fedora는 법무 검토 끝에 SSPL을 패키지 가능한 라이선스가 아니라고 판단하고 Fedora 30부터 MongoDB 서버를 제거했습니다. Debian은 SSPL이 DFSG의 취지에 맞지 않는다고 보고 아카이브에서 뺐고, RHEL 8에도 MongoDB는 들어가지 않았습니다.

즉 빈자리는 두 번 다 똑같이 생겼습니다. 정책도 같았고 반응 속도도 비슷했습니다.

갈린 것은 그 자리를 채울 후계자였습니다

차이는 빈자리가 생긴 뒤에 나옵니다. MongoDB 자리는 비워진 채로 남았고, Redis 자리에는 8일 만에 들어갈 것이 준비돼 있었습니다.

포크는 코드를 복사한다고 성립하지 않습니다. 계속 유지보수할 수 있어야 성립합니다. 두 제품은 이 조건에서 갈립니다.

Redis는 단일 노드 중심의 성숙한 C 코드베이스이고, 외부 인터페이스인 RESP 프로토콜이 오래 고정돼 있었습니다. 클라이언트 라이브러리 수백 개가 이 프로토콜에 맞춰져 있으니, 포크가 프로토콜만 지키면 생태계를 통째로 물려받습니다. 게다가 원래 메인테이너들이 그 포크에 있었습니다.

MongoDB는 샤딩과 복제, 트랜잭션, 쿼리 플래너가 얽힌 분산 시스템입니다. 코드를 받아도 이걸 계속 따라갈 팀이 따로 필요합니다. AWS조차 포크 대신 자기 엔진 위에 규약만 얹는 쪽을 골랐다는 사실이, 저는 이 난이도 차이를 가장 잘 보여준다고 봅니다.

2024년의 재단이 며칠 만에 움직인 이유

8일이라는 속도는 그 자체로 설명이 필요합니다. 2018년에는 이런 대응이 없었습니다.

그사이에 선례가 쌓였습니다. 2023년 HashiCorp가 Terraform을 BUSL로 바꾸자 몇 주 만에 OpenTofu가 만들어져 리눅스 재단으로 들어갔습니다. 포크를 띄우고, 재단이 상표와 거버넌스를 받고, 경쟁 관계인 클라우드 업체들을 한 테이블에 앉히는 절차가 이미 한 번 돌아본 각본이 된 것입니다.

Redis 때는 그 각본을 그대로 실행하면 됐습니다. 라이선스를 바꾸는 쪽 입장에서는, 상대의 대응 시간이 몇 달에서 며칠로 줄어든 셈입니다.

"목표는 달성했다"는 말의 뜻

2025년 5월, Redis는 8 버전부터 AGPLv3를 추가하며 OSI 승인 라이선스로 돌아왔습니다. 그 발표문에 이런 문장이 있습니다.

This achieved our goal—AWS and Google now maintain their own fork—but the change hurt our relationship with the Redis community.

목표를 달성했다는 문장과 그 근거로 든 사실이 같은 줄에 있습니다. 클라우드 업체가 남의 코드로 장사하는 걸 막는 게 목표였고, 실제로 그들은 이제 자기 포크를 유지합니다. 그런데 그 포크가 배포판 기본 패키지가 됐습니다.

라이선스를 무기로 쓸 때 가정하는 것은 상대가 내 코드를 계속 필요로 한다는 것입니다. 그 가정이 깨지면 라이선스는 상대를 묶는 대신 나를 밀어냅니다. 저는 이 문장이 그 순간을 정확히 기록했다고 봅니다.

내 의존성에서 같은 일이 생기면 볼 것

이 비교에서 실제로 건질 수 있는 건 다음 사건을 판별하는 기준입니다. 어떤 의존성의 라이선스가 바뀌었다는 소식을 봤을 때, 그게 나에게 도달할지는 세 가지로 갈립니다.

배포판 기본 저장소에 있었는가. 있었다면 그 자리는 비게 되고, 언젠가 내 Dockerfile 이나 베이스 이미지가 조용히 바뀝니다. 벤더 저장소로만 설치하던 것이라면 이 경로는 없습니다.

외부 인터페이스가 고정돼 있는가. 프로토콜이나 API가 안정돼 있고 클라이언트 생태계가 거기 묶여 있다면, 후계자는 그 인터페이스만 지키면 됩니다. 갈아타는 비용이 접속 주소를 바꾸는 수준으로 떨어집니다.

원래 만들던 사람들이 어디로 갔는가. 코드는 복사할 수 있어도 유지보수 능력은 복사할 수 없습니다. 메인테이너가 따라간 쪽이 실질적인 후계자입니다.

여기까지가 지난 두 사례에서 읽어낼 수 있는 부분입니다. 다음 라이선스 변경이 같은 방식으로 흘러갈지는 저도 모릅니다. 다만 이 셋이 모두 해당하는 의존성이라면, 라이선스 변경은 남의 일이 아니라 내 배포 파이프라인의 일정 문제라고 보는 편이 안전합니다.

참고: Valkey 발표, Redis AGPLv3 전환, Fedora의 Redis 교체 결정