
Redis 라이선스 전쟁: 오픈소스의 배신인가, 생존인가?
15년간 BSD 라이선스로 세계에서 가장 사랑받던 인메모리 DB Redis가 어느 날 갑자기 오픈소스를 포기했다. 그리고 1년 뒤 다시 돌아왔다. 이 극적인 드라마의 전말과, 그 뒤에 숨겨진 오픈소스 생태계의 구조적 문제를 파헤친다.

15년간 BSD 라이선스로 세계에서 가장 사랑받던 인메모리 DB Redis가 어느 날 갑자기 오픈소스를 포기했다. 그리고 1년 뒤 다시 돌아왔다. 이 극적인 드라마의 전말과, 그 뒤에 숨겨진 오픈소스 생태계의 구조적 문제를 파헤친다.
2024년 3월 20일, 전 세계 개발자들의 타임라인이 들끓었다.
"Beginning with Redis 7.4, Redis is dual-licensed under RSALv2 and SSPLv1."
Redis가 오픈소스를 포기했다. 15년 동안 3-Clause BSD 라이선스 — 사실상 "뭐든 해도 된다" 수준의 허용적 라이선스 — 아래에서 자유롭게 사용되던 Redis가, 하루아침에 소스 공개(source-available) 라이선스로 전환한 것이다.

Hacker News에는 수천 개의 댓글이 달렸다. "배신이다", "당연한 선택이다", "또 시작이다" — 의견은 극명하게 갈렸다. 며칠 만에 Linux Foundation이 Valkey라는 이름의 포크를 발표했고, AWS, Google, Oracle 등 거대 클라우드 기업들이 즉시 지지를 선언했다.
그리고 1년 뒤인 2025년 5월, 반전이 일어났다. Redis의 원래 창시자 antirez(Salvatore Sanfilippo)가 복귀하면서, Redis는 다시 오픈소스 라이선스(AGPLv3)를 채택했다.
이 글은 단순한 뉴스 요약이 아니다. 왜 이런 일이 반복되는지, 오픈소스 라이선스의 역사부터 클라우드 시대의 구조적 모순, 그리고 2026년 현재의 공존 모델까지 — 이 드라마의 전체 맥락을 풀어본다.
오픈소스의 역사는 프린터 한 대에서 시작한다.
1980년, MIT 인공지능연구소의 프로그래머 리처드 스톨만(Richard Stallman)은 새로 도입된 Xerox 레이저 프린터에 불만이 있었다. 종이가 걸리면 알림이 안 와서, 인쇄물을 가지러 갔다가 빈손으로 돌아오는 일이 반복됐다. 이전 프린터에서는 소스 코드를 수정해서 종이 걸림 알림 기능을 직접 추가했었는데, Xerox는 소스 코드를 제공하지 않았다.
이 경험이 스톨만을 분노하게 만들었다. "소프트웨어는 자유로워야 한다." 1983년, 그는 GNU 프로젝트를 시작하고 자유 소프트웨어 재단(FSF)을 설립했다.
1989년, 스톨만은 자유 소프트웨어의 법적 보호장치인 GPL(GNU General Public License)을 발표한다. 핵심 원칙은 간단했다:
하지만 모든 개발자가 GPL의 "전파" 조건을 좋아한 건 아니었다. BSD(Berkeley Software Distribution) 라이선스와 MIT 라이선스는 다른 철학을 택했다:
"코드를 가져다 쓰세요. 출처만 밝히면 됩니다. 상업적으로 써도 됩니다. 소스를 공개하지 않아도 됩니다."
이것이 퍼미시브(permissive) 라이선스다. 기업 친화적이라서 상업적 채택이 폭발적으로 늘었다.
| 구분 | 카피레프트 (GPL) | 퍼미시브 (BSD/MIT) |
|---|---|---|
| 핵심 원칙 | 자유의 전파 — 수정하면 공개 의무 | 최대한의 자유 — 제한 거의 없음 |
| 상업적 사용 | 가능하나, 소스 공개 필수 | 자유롭게 가능, 소스 공개 불필요 |
| 대표 프로젝트 | Linux, GCC, WordPress | Redis, Node.js, React, PostgreSQL |
| 기업 선호도 | 부담스러움 (법률팀 검토 필수) | 매우 높음 (제약 거의 없음) |
| 비유 | "레시피를 공유했으니, 네가 개선한 것도 공유해" | "레시피 가져가. 뭘 하든 네 자유" |
1998년, OSI(Open Source Initiative)가 설립되면서 "오픈소스"라는 용어가 공식화됐다. OSI가 인증한 라이선스만이 공식적으로 "오픈소스"로 불릴 수 있다. 이 기준이 나중에 Redis 논쟁에서 핵심 쟁점이 된다.
2009년, 이탈리아 시칠리아의 프로그래머 살바토레 산필리포(Salvatore Sanfilippo) — 온라인에서 antirez로 알려진 — 는 자신이 운영하던 웹 분석 서비스의 확장성 문제와 씨름하고 있었다. MySQL로는 실시간 통계 처리가 너무 느렸다.
해결책은 메모리에서 직접 데이터를 다루는 것이었다. 그는 TCP 서버 위에 키-값 저장소를 구현하기 시작했고, 이것을 Redis(REmote DIctionary Server)라고 이름 붙였다.
antirez는 Redis를 처음부터 3-Clause BSD 라이선스로 공개했다. 가장 자유로운 라이선스 중 하나다. "가져다 쓰세요. 뭘 해도 됩니다."
이 선택은 Redis의 폭발적 성장을 가능하게 했다. GitHub, Instagram, Twitter, Stack Overflow — 2010년대의 거의 모든 유명 서비스가 Redis를 사용했다. 캐싱, 세션 관리, 실시간 랭킹, 메시지 큐 — Redis는 "만능 인메모리 DB"로 자리잡았다.

antirez의 BSD 라이선스 선택은 양날의 검이었다.
축복: 누구나 자유롭게 쓸 수 있으니 채택률이 폭발적이었다. Redis는 빠르게 세계에서 가장 인기 있는 인메모리 데이터 스토어가 됐다.
저주: 누구나 자유롭게 쓸 수 있다는 건, AWS도 자유롭게 쓸 수 있다는 뜻이었다.
2010년대 중반, 클라우드 컴퓨팅이 폭발적으로 성장하면서 새로운 비즈니스 모델이 등장했다. AWS는 2013년 Amazon ElastiCache for Redis를, 이어서 Azure와 Google Cloud도 Redis 기반 관리형 서비스를 출시했다.
이 서비스들은 단순했다. 오픈소스 Redis 코드를 그대로 가져다가, 클라우드 인프라 위에 올리고, "Redis as a Service"로 판매한 것이다. 고객은 클릭 몇 번으로 Redis 인스턴스를 띄울 수 있었고, 요금은 AWS에 지불했다.
문제는 이 구조에서 원래 개발자/회사에게 돌아가는 돈이 거의 없다는 것이었다.
Redis Labs(현 Redis Ltd.)는 Redis의 상업적 지원과 엔터프라이즈 기능을 판매하는 회사였다. 하지만 고객 대부분은 AWS ElastiCache를 선택했다. 왜? AWS 생태계 안에서 클릭 한 번으로 쓸 수 있으니까. 별도의 계약이나 설치가 필요 없으니까.
이 상황이 얼마나 비대칭적이었는지 보자:
AWS의 ElastiCache(Redis 기반) 추정 매출이 Redis Ltd. 자체 매출의 약 7~10배에 달했다. Redis가 만든 기술로 Redis보다 훨씬 더 많은 돈을 버는 구조. 이것이 "클라우드 무임승차(cloud free-riding)" 문제의 핵심이다.
Hacker News의 한 댓글이 이 상황을 정확히 짚었다:
"It's like a farmer growing the best tomatoes in the world, and a giant corporation building a fence around the farm, charging admission to eat the tomatoes, and giving the farmer nothing."
— Hacker News 유저
Redis가 라이선스를 바꾸기 전, 다른 회사가 먼저 움직였다.
2018년 10월, NoSQL 데이터베이스의 대표주자 MongoDB가 폭탄 선언을 했다. 자사의 라이선스를 기존 AGPL에서 새로 만든 SSPL(Server Side Public License)로 변경한 것이다.
SSPL의 핵심 조항은 이랬다:
MongoDB는 이것을 OSI에 오픈소스 라이선스로 승인해달라고 제출했지만, 2019년 스스로 신청을 철회했다. 2021년 OSI는 SSPL을 공식적으로 "오픈소스가 아니다(fauxpen source)"라고 선언했다.
MongoDB의 선례는 다른 회사들에게 길을 열어주었다.
2021년 1월, Elastic NV가 Elasticsearch와 Kibana의 라이선스를 Apache 2.0에서 SSPL + Elastic License 이중 라이선스로 변경했다. 이유는 같았다 — AWS가 Elasticsearch를 그대로 가져다 Amazon Elasticsearch Service로 팔고 있었기 때문이다.
AWS의 대응은 빨랐다. 2021년 4월, OpenSearch라는 이름으로 Elasticsearch를 포크하고, Apache 2.0 라이선스를 유지했다. (이 이야기는 OpenSearch 완전 정복 글에서 자세히 다뤘다.)
패턴이 보이는가? 오픈소스 프로젝트가 라이선스를 제한하면, 클라우드 기업이 포크한다. 매번 같은 시나리오가 반복됐다.
Redis Ltd.의 CEO Rowan Trollope은 공식 블로그를 통해 라이선스 변경을 발표했다. Redis 7.4부터 모든 새 버전은 RSALv2(Redis Source Available License v2)와 SSPLv1 이중 라이선스로 제공된다.
기존 BSD 라이선스와 무엇이 달라졌을까?
| 사용 사례 | BSD (이전) | RSALv2/SSPL (변경 후) |
|---|---|---|
| 내부 서비스에서 사용 | 자유 | 자유 |
| 자사 앱의 백엔드로 사용 | 자유 | 자유 |
| Redis 클라이언트 라이브러리 개발 | 자유 | 자유 |
| 컨설팅/교육 | 자유 | 자유 |
| Redis 기반 관리형 서비스 판매 | 자유 | 금지 (파트너 계약 필요) |
| Redis 경쟁 제품 출시 | 자유 | 금지 |
| OSI 인증 오픈소스 여부 | 예 | 아니오 |
대부분의 개발자에게는 실질적으로 변하는 게 없었다. 내 서비스에서 Redis를 캐시로 쓰는 것, 사이드 프로젝트에서 Redis를 쓰는 것, Redis 라이브러리를 만드는 것 — 모두 이전과 동일하게 자유다.
타깃은 명확했다: AWS, Azure, Google Cloud. Redis를 "as a Service"로 팔아서 돈을 벌면서 원작자에게 돌려주지 않는 클라우드 제공자들.
Redis Ltd.는 동시에 제품명도 변경했다. 더 이상 "Redis OSS(Open Source Software)"가 아닌 "Redis Community Edition"으로. 이름에서부터 "오픈소스"를 지운 것이다.
Hacker News의 반응은 격렬했다.
지지하는 쪽:
"클라우드 기업들이 오픈소스 개발자의 노동을 착취하는 구조를 바꿔야 한다. Redis의 선택은 이해할 수 있다."
"대부분의 개발자에게는 아무것도 바뀌지 않는다. 이건 AWS를 겨냥한 것이지, 커뮤니티를 겨냥한 게 아니다."
반대하는 쪽:
"오픈소스의 정의는 '누구든 어떤 목적으로든' 쓸 수 있어야 한다는 것이다. 특정 사용자를 차별하는 순간, 그건 오픈소스가 아니다."
"HashiCorp이 그랬고 Elastic이 그랬다. 매번 같은 패턴이다. 라이선스를 바꾸면 → 포크가 나오고 → 원래 프로젝트가 쪼그라든다."
"더 심각한 문제: Redis는 아무런 사전 고지 없이 오픈 거버넌스 위원회를 해산했다. 커뮤니티와 대화도 없이."
가장 논쟁적이었던 지점은 거버넌스 문제였다. Redis에는 커뮤니티 기여자들로 구성된 거버넌스 위원회가 있었는데, 라이선스 변경 발표 전에 이 위원회가 조용히 해산됐다. 한 기여자는 "블로그 포스트를 통해 알게 됐다"고 분노했다.

2024년 3월 28일 — Redis 라이선스 변경 발표 불과 8일 만에 — Linux Foundation이 새로운 프로젝트를 발표했다.
Valkey — Redis 7.2.4(마지막 BSD 라이선스 버전)에서 포크된 인메모리 데이터 스토어. BSD 라이선스를 유지한다.
후원사 명단이 놀라웠다:
AWS, Google, Oracle, Alibaba, Tencent, Huawei — 세계 6대 클라우드 기업이 전부 모였다. 이것은 단순한 오픈소스 포크가 아니었다. 클라우드 산업의 연합 대응이었다.
포크 이후 불과 6개월 만에 Valkey 8.0이 출시됐다. 단순한 Redis 복사본이 아니었다. 향상된 멀티스레딩, 성능 최적화 등 Redis에 없던 개선이 들어갔다.
2025년 12월에는 Valkey 9.0.1까지 출시됐다. 주요 사용자에는 Twitter, Airbnb, Tinder, Adobe, Hulu, Amazon, OpenAI 등이 포함된다.
클라우드 기업들이 합심하면 포크가 얼마나 빠르게 성숙할 수 있는지를 보여주는 사례다. Redis가 우려한 시나리오 — "포크가 원본을 대체한다" — 가 현실이 되고 있었다.
Redis에 더 극적인 반전이 남아 있었다.
antirez — Redis를 만든 그 사람 — 가 돌아온 것이다.
antirez는 2020년 6월 Redis 메인테이너에서 물러났었다. 번아웃과 개인적인 이유였다. 그는 블로그에 이렇게 썼었다:
"Redis는 내 아이와 같다. 하지만 이제는 다른 사람이 키울 때가 됐다."
그런데 2024년 12월, antirez가 Redis Ltd.에 정식 합류했다. 5년 만의 복귀. 그리고 그가 복귀하자마자 밀어붙인 것이 라이선스 재전환이었다.

antirez는 자신의 블로그에서 솔직하게 말했다:
"나는 커리어 대부분을 오픈소스 소프트웨어를 작성하며 보냈다. 다른 것을 시작하기엔 너무 늙었다."
"SSPL은 커뮤니티에 의해 받아들여지지 못했다. OSI도 인정하지 않았고, 개발자들도 인정하지 않았다."
그가 주장한 것은 SSPL 대신 AGPLv3(GNU Affero General Public License)를 채택하자는 것이었다. AGPL은 GPL과 비슷하지만, 네트워크를 통해 서비스를 제공하는 경우에도 소스 코드 공개를 요구한다. 차이점이 중요하다:
| 라이선스 | SSPL | AGPL |
|---|---|---|
| OSI 인증 | 아니오 (비오픈소스) | 예 (공식 오픈소스) |
| 서비스 제공 시 | 전체 인프라 코드 공개 필요 | 수정한 부분의 소스 공개 필요 |
| 실질적 강도 | 거의 사용 불가능 수준 | 현실적으로 지킬 수 있는 수준 |
| 커뮤니티 인식 | "페이크 오픈소스" | "진짜 오픈소스" |
| 리눅스 배포판 | Debian, Fedora에서 제거 | 배포판에 포함 가능 |
antirez의 주장은 명확했다. SSPL은 "오픈소스인 척하는 것"이지만, AGPL은 진짜 오픈소스면서도 클라우드 기업의 무임승차를 어느 정도 방지할 수 있다. AWS가 Redis를 수정해서 서비스하면, 그 수정 사항을 공개해야 하니까.
Redis Ltd.는 antirez의 주장을 받아들였다. 2025년 5월 1일, Redis 8.0 출시와 함께 라이선스가 트리플 라이선스(RSALv2 + SSPLv1 + AGPLv3)로 변경됐다. 사용자는 세 라이선스 중 하나를 선택할 수 있다.
Redis Ltd.의 발표문에는 흥미로운 문장이 있었다:
"포크가 공평한 경쟁의 장을 만들었고, Redis는 라이선스 변경 이후 기록적인 성장을 달성했다."
포크(Valkey)를 경쟁이 아닌 "공평한 경쟁의 장"으로 표현한 것이 의미심장하다. SSPL 시절의 방어적 태도에서, AGPL로 돌아오며 자신감을 회복한 것처럼 읽힌다.
Redis만의 이야기가 아니다. 2018년부터 2024년까지, 거의 동일한 시나리오가 반복됐다.
| 프로젝트 | 라이선스 변경 | 커뮤니티 포크 | 현재 상태 (2026) |
|---|---|---|---|
| MongoDB | AGPL → SSPL (2018) | FerretDB (PostgreSQL 기반) | MongoDB 독주 유지, 포크 영향 미미 |
| Elasticsearch | Apache 2.0 → SSPL (2021) | OpenSearch (AWS 주도) | 시장 분할 — 둘 다 활발 |
| Terraform | MPL → BSL (2023) | OpenTofu (Linux Foundation) | HashiCorp → IBM 인수. 법적 분쟁 중 |
| Redis | BSD → SSPL → AGPL (2024-25) | Valkey (Linux Foundation) | Redis AGPL로 회귀, Valkey도 성장 |
HashiCorp의 사례는 더 극적이다. 2023년 8월, Terraform을 BSL(Business Source License)로 변경하자 커뮤니티가 OpenTofu를 포크했다. 그런데 2024년 4월, HashiCorp이 OpenTofu에 저작권 침해 경고장(Cease and Desist)을 보냈다. OpenTofu 측은 "문제된 코드는 MPL 시절 버전에서 가져온 것"이라고 반박했다.
이 법적 분쟁이 이어지는 와중에, 2024년 말 IBM이 HashiCorp을 $64억에 인수했다. 라이선스 변경이 수익성을 개선했는지, 아니면 매각을 위한 포석이었는지는 여전히 논쟁 중이다.
MariaDB가 만든 BSL은 독특한 모델이다:
이 모든 전쟁의 근본 원인은 하나다: 오픈소스는 라이선스이지, 비즈니스 모델이 아니다.
퍼미시브 라이선스(BSD/MIT)로 코드를 공개한 회사가 돈을 버는 방법은 제한적이다:
흥미로운 반례가 있다. PostgreSQL은 비슷한 상황인데도 라이선스 전쟁이 없다. 이유는:
Hacker News에서 가장 많은 추천을 받은 대안 중 하나가 바로 "PostgreSQL 모델을 따르라"였다:
"Redis의 실수는 BSD 라이선스가 아니라, 한 회사가 프로젝트를 통제하려 한 것이다. PostgreSQL처럼 재단이 관리했다면 이런 일은 없었을 것이다."

2026년 4월 현재, Redis와 Valkey는 각자의 영역에서 성장하고 있다.
| 구분 | Redis 8.x (AGPLv3) | Valkey 9.x (BSD) |
|---|---|---|
| 라이선스 | AGPLv3 / RSALv2 / SSPLv1 (선택) | BSD 3-Clause |
| 운영 주체 | Redis Ltd. | Linux Foundation |
| 주요 기능 | Vector Sets, Redis Stack 통합 | 향상된 멀티스레딩 |
| 클라우드 서비스 | Redis Cloud (공식) | AWS ElastiCache, GCP Memorystore 등 |
| 주요 사용자 | 엔터프라이즈, AI/ML 워크로드 | 클라우드 네이티브, 대규모 서비스 |
| 방향성 | 기능 혁신 (벡터 검색, AI) | 성능 최적화, API 호환성 |
Redis는 AGPLv3를 통해 "진짜 오픈소스"의 정체성을 회복하면서, Vector Sets 같은 AI 시대의 새로운 기능으로 차별화를 추구하고 있다. antirez가 직접 개발한 Vector Sets는 Redis를 단순한 캐시에서 AI 인프라의 핵심 구성요소로 진화시키는 야심찬 시도다.
Valkey는 BSD 라이선스의 자유로움을 무기로, 클라우드 기업들의 전폭적인 지원을 받으며 안정성과 성능에 집중하고 있다.
새로운 오픈소스 프로젝트를 시작한다면, 어떤 라이선스를 골라야 할까?
2026년의 추세는 명확하다: AGPL이 "실용적 카피레프트"로 부상하고 있다. SSPL처럼 커뮤니티에서 배척당하지도 않고, BSD처럼 완전히 무방비 상태도 아닌 — 그 사이의 균형점이다.
Redis 라이선스 전쟁은 기술적인 사건이 아니다. 경제적 사건이다.
오픈소스는 지난 40년간 소프트웨어 산업의 근간이 됐다. Linux, PostgreSQL, Kubernetes, React — 우리가 매일 쓰는 거의 모든 기술이 오픈소스 위에 서 있다. 하지만 "누구나 자유롭게"라는 이상과, "개발자도 먹고살아야 한다"는 현실 사이의 긴장은 점점 커지고 있다.
2024년 xz-utils 백도어 사건 — 번아웃에 시달리던 유일한 메인테이너가 악의적 기여자에게 접근 권한을 넘겨준 사건 — 이 보여주듯, 오픈소스의 지속가능성 문제는 보안 문제이기도 하다.
Redis의 여정은 하나의 해답을 제시한다. 완벽한 라이선스는 없다. 하지만 커뮤니티와 대화하고, 투명하게 결정하고, 실수를 인정하고 돌아올 수 있는 용기가 있다면 — 코드와 커뮤니티 모두 살아남을 수 있다.
antirez는 이렇게 말했다:
"오픈소스는 어떤 한 회사보다 큰, 인류의 공동 노력이다."
Redis 8.0은 지금 AGPLv3 아래에서 자유롭게 사용할 수 있다. Valkey 9.0은 BSD 아래에서 자유롭게 사용할 수 있다. 2026년의 개발자들은, 이 복잡한 전쟁의 결과로 만들어진 더 많은 선택지를 누리고 있다.
어쩌면 그것이 오픈소스의 진짜 힘일지도 모른다. 하나가 막히면, 다른 길이 열린다. 코드는 — 결국 — 자유를 향해 흐른다.
참고 자료: