Redis와 야망의 대가

두 번째 문제는 full-text search, event stream processing, strong-consistency key/value, time-series, vector storage를 진지하게 통합하려는 사용자는 Redis 제한을 물려받은 반쯤 익은 모듈이 아니라 전문 도구를 원한다는 데 있음

Redis의 고가용성은 복잡하고, 영속성에는 미묘한 트레이드오프가 있으며, 프로토콜 부담과 클라이언트 파편화도 실제 장애물이 됨

Redis는 Postgres를 대체하려는 도구가 아니며, ElasticSearch와 RabbitMQ 같은 시스템도 각자의 기반 기둥으로 남아야 한다는 입장임

Aphyr의 초기 Redis-Raft 구현 분석은 21개의 문제를 찾았다고 적고 있음

건강한 클러스터에서의 장시간 사용 불능

8건의 크래시

3건의 stale read

1건의 aborted read

커밋된 업데이트 손실로 이어지는 5건의 버그

1건의 무한 루프

클라이언트에 논리적으로 손상된 응답을 보낼 수 있는 2건의 문제

테스트한 첫 버전 1b3fbf6은 사실상 사용할 수 없는 수준이었다고 평가됨

캐시이자 데이터 구조 서버인 Redis와 “Redis the etcd” 또는 다른 전문 데이터베이스를 지향하는 Redis는 근본적으로 다른 제안이며, 이 간극이 핵심 문제임

Disque가 드러낸 같은 패턴

antirez는 2015년에 Disque를 발표했고, 당시 실제 사용 사례에서 출발한 것이 아니라 Redis를 메시지 큐처럼 쓰는 사람들과 다른 메시지 큐를 보며 “astronaut mode”로 설계했다고 밝힘

실제 사용 사례 없이 개인적 도전이나 학습 과제로 만든 프로젝트도 훌륭할 수 있지만, 사용자가 늘어난 뒤 등장하는 긴 꼬리의 어려운 문제를 계속 해결할 수 있는지는 별개의 문제임

고가용성 메시지 전달은 제대로 풀기 어려운 문제이며, CAP 정리의 어느 쪽을 최적화하든 트레이드오프와 어려운 문제 해결을 피할 수 없음

2015년에는 이미 성숙한 메시지 브로커가 많았고, 사람들이 Redis를 메시지 브로커로 쓴 이유는 Redis를 이미 쓰고 있었고 충분히 단순했기 때문임

필요한 것은 새로운 메시지 브로커도, Redis가 더 복잡한 메시지 브로커가 되는 것도 아니었음

Disque는 발표 직후 사실상 abandonware가 되었고, GitHub에서 8K stars를 얻었음에도 방치됨

이후 Redis 모듈로 다시 작성되었지만, 그 프로젝트도 지난 7~8년간 방치된 상태임

Valkey가 보여주는 다른 방향

Redis의 흐름을 움직인 힘은 복잡한 문제를 풀려는 개발자의 야망, 모두를 위한 모든 것이 되려는 야망, Redis의 소유자가 AWS와 GCP에 밀리기 전에 최대 수익을 뽑아내려는 야망으로 묶임

오픈소스를 꽤 큰 규모로 키우고, 회사를 세워 수억 달러 매출과 IPO, 수십억 달러 매각까지 겪어봤으며, 그 과정에서 OSS에서 벗어나는 라이선스 변경도 해본 입장에서 보면 Redis의 “AI 앱을 위한 실시간 컨텍스트 엔진” 포지셔닝은 방향상 맞아 보임
소프트웨어 구매에는 실사용자와 기술 의사결정자(TDM) 가 있는데, Redis 랜딩 페이지는 실사용 개발자보다 예산권을 가진 TDM을 겨냥한 사이트처럼 보임. 많은 TDM은 “IBM을 골라서 해고된 사람은 없다”는 식으로 해고되지 않는 결정을 선호하고, Gartner나 McKinsey가 AI 전략과 컨텍스트 관리를 강조하면 “AI 앱용 Context Engine”은 방어 가능한 구매 사유가 됨
HashiCorp에서도 terraform.io는 실무자용, hashicorp.com은 TDM용으로 나누려 했고 어느 정도는 통했지만 한계도 있었음. 개발자 주도 OSS 회사에는 어려운 문제임
“무료로 Redis 사용”과 “데모 받기” 버튼도 TDM 관점에서는 이상하지 않음. TDM은 기술 결정의 책임을 지기 싫어하고 오히려 돈을 내고 소프트웨어를 사고 싶어 하므로, 무료는 체험판처럼 낮추고 사람과 연결되는 콜투액션을 전면에 둠
Redis Inc. 경영진은 개발자/운영자보다 TDM에게 어필하는 쪽이 더 중요하다고 결론낸 듯하고, 내부 데이터 없이는 맞다 틀리다 말하기 어렵지만 의도 없이 한 전략은 아닐 것임
기능을 계속 붙이는 것도 새 도구를 도입하는 비용보다 기존 도구를 확장하는 비용이 훨씬 낮기 때문임. 상업적 동기가 없어도 프로그래밍 언어들이 핵심 정체성을 지키기보다 모든 기능의 최소공통분모가 되는 일이 많고, 상업적 회사에서는 “land and expand”가 강하게 작동함. 대표 기능으로 첫 계약을 따낸 뒤, 평균 수준의 부가 기능을 붙여 팔아도 조달 부서는 새 계약보다 기존 계약 확장을 더 쉽게 처리함
“진지한 고객은 전문 검색/이벤트 스트림/강한 일관성 KV/시계열/벡터 저장소에는 진짜 전문 제품을 원할 것”이라는 주장도 매우 논쟁적임. 공개 소프트웨어 회사 데이터만 봐도 고객은 비기술적 이유로 더 나쁜 선택지를 자주 고름
Valkey가 시장의 최종 판결이라는 말도 단정하기 어려움. Valkey는 평균 포크보다 훨씬 잘하고 있지만(https://redmonk.com/sogrady/2026/04/06/valkey-at-two/), Redis 회사도 외부에서 보기엔 잘 버티는 듯함. ElasticSearch나 MongoDB처럼 라이선스를 바꾸고 포크가 생겼어도 공개 시장 평가에는 큰 타격이 없었던 회사들을 보면 다른 결론도 가능함. 개발자 버블에서는 다르게 보일 수 있지만, 매출이 최종 후행 지표라면 “그게 정말 중요했나?”라고도 물을 수 있음
상업적 이해를 옹호하려는 건 아니고, 그쪽에서 본 관점을 공유하는 것임. 같은 농산물을 두고도 장보는 사람과 농부가 보는 질문과 목표가 완전히 다른 것과 비슷함

상업적 관점의 “왜”가 잘 설명됐고, Redis가 순수 소프트웨어 진공 상태에 있는 게 아니며 OSS 괴짜들이 타깃이 아니고 의사결정자는 시스템 엔지니어와 다른 기준을 가진다는 맥락이 붙음
다만 이 논리는 모두의 목표가 돈이라고 전제하는 느낌이 있음. Redis로 엄청난 돈을 벌겠다는 야망은 특정한 야망일 뿐이고, antirez가 글에서 보인 태도로는 돈을 크게 신경 쓴 사람처럼 읽히지 않음
반례로 SQLite가 있음. 수백만 매출이나 수십억 달러 매각을 이야기하지 않고, 잘 정의된 무언가를 조용히 제공하는 데 집중함. SQLite는 가장 인기 있는 임베디드 데이터베이스가 된 이유를 잃지 않았고, 큰 데이터베이스 쪽에서는 Postgres도 마찬가지임. 돈과 상업적 이해관계의 세계만큼이나 이런 세계에서도 반례를 끌어올 수 있음
Redis에 대해서는 “이미 AWS/GCP를 쓰니 그쪽 Redis 비슷한 걸 쓰자”가 수평 확장의 자연스러운 결과로 보임. 더 IBM다운 경로는 클라우드 제공자를 고르고 그들의 Redis를 쓰는 것인데, 요즘은 그게 Valkey가 됨
사람들이 더 나쁜 선택지를 고른다는 건 논쟁거리가 아니라 사실이고, Redis가 그런 모드로 확장된 것이 바로 강조하고 싶었던 야망과 표류의 한 사례임

Redis Labs에서 일했으니 거의 문자 그대로 악마의 개발자 대변인 입장이었음. 퇴사할 때 베스팅된 옵션을 행사하지 않았고, Silicon Valley와 멀리 떨어진 곳에 살아서 다리를 너무 많이 태울 걱정 없이 말할 수 있음
예전에는 redis.com이 TDM 사이트였고 redis.io가 개발자용이었는데, Redis Labs가 antirez가 갖고 있던 redis.io를 가져온 뒤 다운로드 링크조차 찾기 어려울 정도로 망가뜨렸고 이제 두 URL 모두 TDM 사이트로 보냄. 지금도 Redis 다운로드 링크를 쉽게 찾기 어렵고 직접 찾아보라고 하고 싶을 정도임
핵심 문제는 Redis Labs가 늘 마케팅 리더십을 형편없이 뽑았다는 데 있음. CMO와 VP들이 와서 짧은 시간에 호감을 최대한 태워버리고 6개월 뒤 “다음 모험”으로 떠났음. redis.io 트래픽이 redis.com보다 훨씬 많다는 걸 보고, 다운로드 링크를 찾지 못한 사람들이 “try free”를 누르길 바라며 redis.io를 망친 것도 그런 단기 클릭 욕심의 전형으로 보임
부가 기능 판매는 경쟁사와 체크박스상 차별화하는 데도 도움이 됨. 특히 가격으로 경쟁하기 어려울 때 그렇고, AWS는 ElastiCache에 강한 클라우드 할인을 묶어 팔 수 있었으며 최악의 경쟁자는 무료인 오픈소스 Redis였음
Valkey는 일반적인 포크보다 훨씬 많은 돈이 들어가고 있음. 예를 들어 Redis Labs의 전 개발자 관계 책임자가 지금 AWS에서 Valkey를 하고 있음
다만 Valkey가 “화려하지 않은 작업”만 한다는 평가는 아쉬움. Redis는 이미 오래전부터 다중 스레드였고, 제어 평면은 여전히 단일 스레드지만 I/O는 다중 스레드라서 Valkey의 작업이 글쓴이가 생각하는 것만큼 새롭지는 않음
Valkey는 노골적으로 AWS 등 클라우드 회사들이 누구에게도 돈을 내지 않고 Redis를 계속 팔 수 있게 하는 작전임. 다른 논리는 그들이 계속 하고 싶은 일을 하도록 설득하기 위한 마케팅 도구일 뿐이고, Redis와의 호환성을 깨는 게 상업적으로 유리하다고 판단하면 그렇게 할 것임. 이미 양쪽에서 일부 그랬을 가능성에도 적당히 걸 수 있지만, 충분히 따라보진 않았음
화려하지 않은 작업을 하면서 단순함을 유지하려는 진짜 Redis 포크를 원한다면 redict가 있음
그래도 Redis의 시간은 끝나가고 있다고 봄. 지금의 이상한 상업적 지형에서는 각 포크가 저마다 어딘가 절뚝거림. 가장 덕이 있는 redict조차 antirez가 독재자처럼 원 프로젝트를 밀던 시절과 같은 방식으로 Redis를 앞으로 밀고 나가려는 진짜 관심은 부족함. 소프트웨어가 “완성”되는 게 나쁘다는 뜻은 아니지만, Redis가 아직 해볼 수 있는 멋진 미발견 영역이 있다고 보며 상업적 포크들이 그런 생태계를 만들지는 의심스러움. 물론 Arrays와 AI 관련 응용의 가치를 과소평가하고 있을 수도 있으니 귀는 열어두려 함
돌이켜보면 Redis Labs가 이 모든 걸 그렇게 심하게 망친 게 놀라울 정도고, 시간이 충분히 지나 이제 화가 덜 난 건 다행임

기업들이 돈을 내지 않고 최대한 가져가려는 게 아닌가 싶음. 그래서 Redis, MongoDB, HashiCorp도 결국 라이선스를 바꾼 것 아닌가 함

회사에서 Lua 스크립트로 더 공정한 작업 큐 시스템을 만드는 중인데, Redis가 매우 이상하게 느껴짐. 머릿속 모델은 늘 “단순한 키-값 저장소”였는데, 글로벌 잠금 안에서 Lua 스크립트를 실행하는 기능 같은 온갖 기능을 배우게 됨
그런데 문서는 반짝거리는 웹사이트에 올라와 있고, 명확하게 알려주지 않음. 설정값도 설정 샘플 안에서만 설명되는 식임
Redis가 잘 동작한다는 건 알고 모두 그렇게 말하지만, Redis 기능을 배워가는 경험은 꽤 불편함. 누군가 정말 좋은 프로그램을 만들고, 좋은 프로그램이라면 보통 갖춰야 할 훌륭한 문서는 잊어버린 느낌임
이상한 불평이긴 함. Redis는 극도로 잘 동작하는 듯하고, Postgres 문서처럼 “전부” 설명해주는 문서를 좋아함