Redis와 야망의 대가

• Redis는 2026년 array type PR까지 검토하며, 단순한 데이터 구조 서버에서 여러 영역을 포괄하는 제품으로 변해왔음
• 초기 Redis는 Remote Dictionary Server답게 빠른 인메모리 딕셔너리, 좁은 명령, 단순한 프로토콜로 웹 스택에 빠르게 자리 잡았음
• 지난 10년간 Redis는 Streams, JSON, search, graph, time-series, Redis-Raft, vector sets 등으로 확장하며 database 지향이 강해짐
• 기능 팽창은 Redis의 강점이던 단순함과 일관성을 약화시키고, 전문 도구가 필요한 영역에 반쯤 익은 통합을 늘림
• Valkey는 화려한 기능 추격보다 멀티스레드 성능, 메모리 효율, 클러스터 신뢰성에 집중하며 2011년식 Redis 사용자층을 겨냥함

Redis가 잃어버린 정체성

• Redis는 2026년에 array type 추가를 위한 대형 PR을 검토하는 단계까지 왔고, 이는 단순한 데이터 구조 서버에서 여러 영역을 포괄하려는 제품으로 변한 모습을 상징함
• antirez의 array type PR은 Hash, List, Stream이 각각 임의 조회, append/trim, append-only 이벤트에는 강점이 있지만, 배열처럼 중간 접근과 범위 가시성을 함께 제공하지 못한다는 문제에서 출발함
• Redis에는 이미 JSON 배열, time-series, sorted-set처럼 배열처럼 쓸 수 있는 기능이 있지만, 다시 새 타입을 추가하려는 방향 자체가 기능 확장의 성격을 잘 드러냄
• Redis가 처음 성공한 이유였던 단순함, 명확한 프로토콜, 좁고 직교적인 명령, 개념적 일관성이 약해지는 것이 핵심 문제임

지난 10년간의 변화

• 라이선스와 회사의 방향

  • Redis Inc는 2024년에 BSD 라이선스를 중단했고, 이후 AGPLv3를 유일한 OSI 옵션으로 포함하는 3중 라이선스 체계로 물러남
  • AGPLv3 덕분에 Redis Inc는 오픈소스라고 말할 수 있지만, BSD와는 매우 다른 성격의 라이선스임
  • Redis 뒤의 VC 지원 회사는 원래 Garantia Data라는 NoSQL 클라우드 호스팅 서비스였고, Redis 호스팅으로 옮긴 뒤 Redis 계열 이름으로 바꾸고 antirez를 합류시켜 정당성을 확보함
  • 몇 년 뒤 상표권을 넘겨받은 과정은 이후 라이선스 전환의 기반이 되었고, 과거 관련 글과 댓글은 예상 가능한 방식으로 낡아 보임

• 기능 팽창과 제품 포지셔닝

  • Redis는 소수의 유용한 데이터 타입으로 시작했지만, 시간이 지나며 이국적인 자료구조, Streams 같은 복잡한 stateful 시스템, 버전에 따라 반독점적 성격을 띠는 모듈까지 품게 됨
  • 2026년 Redis의 랜딩 페이지 포지셔닝은 “The Real-Time Context Engine for AI Apps”로 바뀌어 있음
  • 랜딩 페이지에는 “Try Redis for Free”와 “Get a Demo” 버튼이 함께 보이며, 스크린샷에서도 확인 가능함

• 웹스케일 데이터베이스 지향

  • Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex®, Redis-on-Flash® 같은 기능은 Redis가 “웹스케일 데이터베이스”를 지향해왔음을 보여줌

• 프로토콜 변화와 클라이언트 측 캐싱

  • RESP3는 RESP2의 기본 전제였던 요청/응답 모델을 깨는 지점이 많고, Brooks가 말한 두 번째 시스템 실패 양상에 가깝게 평가됨
  • Redis는 원래 캐시로 널리 쓰였지만, 이제는 클라이언트 측 캐싱을 지원하기 위해 새 프로토콜까지 필요한 상태가 됨

초기 Redis가 잘 맞아떨어졌던 이유

• 시대적 배경

  • 2011년 전후 웹 개발자 사이에서는 NoSQL, “web scale”, Bigtable, Dynamo, Ruby on Rails, REST, JSON 같은 흐름이 강했음
  • Redis는 이 분위기에 잘 맞았고, 거의 하룻밤 사이에 많은 스택에 들어간 도구가 됨
  • 2011년 말 Redis 소개는 자신을 advanced key-value store와 data structure server라고 표현했고, “database”라는 단어는 없었음

• Memcached보다 나은 원격 딕셔너리

  • memcached는 많은 웹 서버에서 조용히 돌아가는 필수 인프라였고, 캐싱 외에도 락, 카운터, rate limit 같은 임시 용도로 자주 쓰였음
  • Redis는 당시 “memcached but way better”에 가까운 도구로 받아들여졌고, 이름인 Remote Dictionary Server도 빠른 인메모리 딕셔너리라는 성격을 강조함
  • Redis는 바이트 blob뿐 아니라 linked-list, hash-table, set, sorted-set 같은 잘 고른 자료구조를 제공해 임시적이고 실용적인 사용처를 크게 넓힘

• 단순하고 충분히 표현력 있는 프로토콜

  • Redis wire protocol은 한 시간 안에 이해하고 구현할 수 있을 만큼 단순하면서도 여러 데이터 타입을 표현할 만큼 충분히 강력했음
  • 클라이언트 라이브러리 구현이 단순하고 깔끔했으며, 프로토콜 자체도 자연스럽게 느껴졌다는 평가를 받음
  • Redis 프로토콜과 단순 서버를 직접 만드는 write your own Redis 튜토리얼은 약 10년 전 작성된 인기 글로 남아 있음

• 단일 스레드, 이벤트 기반, 인메모리

  • Redis의 단일 스레드 설계는 모든 연산의 원자성을 보장해 복잡성을 크게 줄이고 추론을 쉽게 만듦
  • 단일 스레드가 성립하려면 서버가 non-blocking I/O로 구현되어야 하고, 데이터 연산도 매우 빨라야 했음
  • 이 조합은 많은 클라이언트를 처리할 수 있는 빠른 key/value store를 하나의 스레드로 가능하게 함

• 웹 애플리케이션에 맞는 자료구조

  • 문자열과 만료 시간은 캐시에, 리스트는 큐에, 해시는 구조화 데이터에 적합했음
  • 락, 카운터, rate limiting, liveness, 모니터링, 리더보드 같은 용도도 내장 데이터 타입만으로 쉽게 구성 가능했음

데이터베이스가 되려는 야망

• Redis의 채택은 빠르게 늘었고 큰 성공을 거뒀지만, 어느 시점부터 프로젝트의 야망은 database가 되는 방향으로 바뀜
• 일부 기능은 실제로 유용했으며, Redis 5.0에 추가된 BZPOPMIN은 sorted-set을 priority queue로 쓸 때 blocking pop을 가능하게 해 실용성을 높였음
• 반면 ACL 같은 기능은 Redis답지 않게 보였고, 전반적으로 Redis를 모두를 위한 모든 것으로 만들려는 욕망이 두드러짐
• Redis의 기능 추가는 지난 10년간 개발자들이 Hacker News에서 이야기하던 “최신 유행”을 따라간 양상과 맞닿아 있음
  • MongoDB가 JSON을 저장하니 Redis도 document database가 되어야 한다는 방향
  • ElasticSearch가 full-text search를 제공하니 Redis도 search engine이 되어야 한다는 방향
  • Graph database가 주목받자 Redis도 graph database가 되려 했지만, 이후 RedisGraph EOL로 이어짐
  • Kafka가 주목받자 Redis도 event streaming platform이 되려 함
  • ZooKeeper와 강한 일관성 데이터베이스가 중요해지자 Redis-Raft가 나왔고, Aphyr의 Jepsen 분석은 필독에 가까운 자료로 꼽힘
  • InfluxDB가 주목받자 Redis도 time series database가 되려 함
  • AI 흐름에 뒤처지지 않기 위해 vector sets 같은 AI 관련 기능도 필요해짐

기능 확장의 대가

• 첫 번째 문제는 Redis를 모두의 스택에 필수적인 도구로 만든 요인을 스스로 약화시킨다는 데 있음
  • 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에 밀리기 전에 최대 수익을 뽑아내려는 야망으로 묶임
• 야망 자체가 문제는 아니지만, 성공의 이유를 잃어버리게 만들 때 문제가 됨
• Valkey의 존재와 채택은 이 동학에 대한 더 넓은 시장의 최종 판단으로 제시됨
• Valkey는 기능 추격이나 비교표의 bullet point 대신, 멀티스레드 성능, 메모리 효율, 클러스터 신뢰성, 처리량 개선 같은 덜 화려한 작업에 투자함
• Valkey의 성능 벤치마크는 인상적이며, 2011년 Redis가 제공하던 기능이면 충분한 Redis 사용자 80%를 정면으로 겨냥함
• Valkey의 세계에서는 새로운 array type이 필요하지 않다는 결론으로 이어짐