# Redis와 야망의 대가 > Clean Markdown view of GeekNews topic #29451. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29451](https://news.hada.io/topic?id=29451) - GeekNews Markdown: [https://news.hada.io/topic/29451.md](https://news.hada.io/topic/29451.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-13T10:04:51+09:00 - Updated: 2026-05-13T10:04:51+09:00 - Original source: [charlesleifer.com](https://charlesleifer.com/blog/redis-and-the-cost-of-ambition/) - Points: 4 - Comments: 1 ## Topic Body - 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](https://github.com/redis/redis/pull/15162)은 Hash, List, Stream이 각각 임의 조회, append/trim, append-only 이벤트에는 강점이 있지만, 배열처럼 중간 접근과 범위 가시성을 함께 제공하지 못한다는 문제에서 출발함 - Redis에는 이미 JSON 배열, time-series, sorted-set처럼 배열처럼 쓸 수 있는 기능이 있지만, 다시 새 타입을 추가하려는 방향 자체가 기능 확장의 성격을 잘 드러냄 - Redis가 처음 성공한 이유였던 **단순함**, 명확한 프로토콜, 좁고 직교적인 명령, 개념적 일관성이 약해지는 것이 핵심 문제임 ### 지난 10년간의 변화 - ## 라이선스와 회사의 방향 - Redis Inc는 2024년에 [BSD 라이선스를 중단](https://github.com/redis/redis/pull/13157)했고, 이후 AGPLv3를 유일한 OSI 옵션으로 포함하는 3중 라이선스 체계로 물러남 - AGPLv3 덕분에 Redis Inc는 오픈소스라고 말할 수 있지만, BSD와는 매우 다른 성격의 라이선스임 - Redis 뒤의 VC 지원 회사는 원래 Garantia Data라는 NoSQL 클라우드 호스팅 서비스였고, Redis 호스팅으로 옮긴 뒤 Redis 계열 이름으로 바꾸고 antirez를 합류시켜 정당성을 확보함 - 몇 년 뒤 상표권을 넘겨받은 과정은 이후 라이선스 전환의 기반이 되었고, 과거 관련 글과 댓글은 [예상 가능한 방식으로 낡아 보임](https://antirez.com/news/121) - ## 기능 팽창과 제품 포지셔닝 - Redis는 소수의 유용한 데이터 타입으로 시작했지만, 시간이 지나며 이국적인 자료구조, Streams 같은 복잡한 stateful 시스템, 버전에 따라 반독점적 성격을 띠는 모듈까지 품게 됨 - 2026년 Redis의 랜딩 페이지 포지셔닝은 “**The Real-Time Context Engine for AI Apps**”로 바뀌어 있음 - 랜딩 페이지에는 “Try Redis for Free”와 “Get a Demo” 버튼이 함께 보이며, [스크린샷](https://media.charlesleifer.com/blog/photos/redis-gets-ai.png)에서도 확인 가능함 - ## 웹스케일 데이터베이스 지향 - Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex®, Redis-on-Flash® 같은 기능은 Redis가 “웹스케일 데이터베이스”를 지향해왔음을 보여줌 - ## 프로토콜 변화와 클라이언트 측 캐싱 - [RESP3](https://www.youtube.com/watch?v=veMiNQifZcM)는 RESP2의 기본 전제였던 요청/응답 모델을 깨는 지점이 많고, Brooks가 말한 두 번째 시스템 실패 양상에 가깝게 평가됨 - Redis는 원래 캐시로 널리 쓰였지만, 이제는 클라이언트 측 캐싱을 지원하기 위해 새 프로토콜까지 필요한 상태가 됨 ### 초기 Redis가 잘 맞아떨어졌던 이유 - ## 시대적 배경 - 2011년 전후 웹 개발자 사이에서는 NoSQL, “web scale”, [Bigtable](https://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdf), [Dynamo](https://www.amazon.science/publications/dynamo-amazons-highly-available-key-value-store), Ruby on Rails, REST, JSON 같은 흐름이 강했음 - [Redis](https://redis.io/)는 이 분위기에 잘 맞았고, 거의 하룻밤 사이에 많은 스택에 들어간 도구가 됨 - 2011년 말 Redis 소개는 자신을 **advanced key-value store**와 **data structure server**라고 표현했고, “database”라는 단어는 없었음 - ## Memcached보다 나은 원격 딕셔너리 - [memcached](https://memcached.org/)는 많은 웹 서버에서 조용히 돌아가는 필수 인프라였고, 캐싱 외에도 락, 카운터, 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](https://charlesleifer.com/blog/building-a-simple-redis-server-with-python/) 튜토리얼은 약 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](https://redis.io/docs/latest/develop/data-types/json/)가 되어야 한다는 방향 - ElasticSearch가 full-text search를 제공하니 Redis도 [search engine](https://redis.io/docs/latest/develop/ai/search-and-query/)이 되어야 한다는 방향 - Graph database가 주목받자 Redis도 [graph database](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/deprecated-features/graph/)가 되려 했지만, 이후 [RedisGraph EOL](https://redis.io/blog/redisgraph-eol/)로 이어짐 - Kafka가 주목받자 Redis도 [event streaming platform](https://redis.io/docs/latest/develop/data-types/streams/)이 되려 함 - ZooKeeper와 강한 일관성 데이터베이스가 중요해지자 [Redis-Raft](https://redis.io/blog/redisraft-new-strong-consistency-deployment-option/)가 나왔고, Aphyr의 [Jepsen 분석](https://jepsen.io/analyses/redis-raft-1b3fbf6)은 필독에 가까운 자료로 꼽힘 - InfluxDB가 주목받자 Redis도 [time series database](https://redis.io/docs/latest/develop/data-types/timeseries/)가 되려 함 - AI 흐름에 뒤처지지 않기 위해 [vector sets](https://redis.io/docs/latest/develop/data-types/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](https://github.com/antirez/disque#readme)를 발표했고, 당시 실제 사용 사례에서 출발한 것이 아니라 Redis를 메시지 큐처럼 쓰는 사람들과 다른 메시지 큐를 보며 “astronaut mode”로 설계했다고 밝힘 - 실제 사용 사례 없이 개인적 도전이나 학습 과제로 만든 프로젝트도 훌륭할 수 있지만, 사용자가 늘어난 뒤 등장하는 긴 꼬리의 어려운 문제를 계속 해결할 수 있는지는 별개의 문제임 - 고가용성 메시지 전달은 제대로 풀기 어려운 문제이며, CAP 정리의 어느 쪽을 최적화하든 트레이드오프와 어려운 문제 해결을 피할 수 없음 - 2015년에는 이미 성숙한 메시지 브로커가 많았고, 사람들이 Redis를 메시지 브로커로 쓴 이유는 Redis를 이미 쓰고 있었고 충분히 단순했기 때문임 - 필요한 것은 새로운 메시지 브로커도, Redis가 더 복잡한 메시지 브로커가 되는 것도 아니었음 - Disque는 발표 직후 사실상 abandonware가 되었고, GitHub에서 8K stars를 얻었음에도 방치됨 - 이후 Redis 모듈로 다시 작성되었지만, 그 프로젝트도 지난 7~8년간 방치된 상태임 ### Valkey가 보여주는 다른 방향 - Redis의 흐름을 움직인 힘은 복잡한 문제를 풀려는 개발자의 야망, 모두를 위한 모든 것이 되려는 야망, Redis의 소유자가 AWS와 GCP에 밀리기 전에 최대 수익을 뽑아내려는 야망으로 묶임 - 야망 자체가 문제는 아니지만, 성공의 이유를 잃어버리게 만들 때 문제가 됨 - [Valkey](https://valkey.io/)의 존재와 채택은 이 동학에 대한 더 넓은 시장의 최종 판단으로 제시됨 - Valkey는 기능 추격이나 [비교표의 bullet point](https://redis.io/compare/valkey/) 대신, 멀티스레드 성능, 메모리 효율, 클러스터 신뢰성, 처리량 개선 같은 덜 화려한 작업에 투자함 - Valkey의 성능 벤치마크는 인상적이며, 2011년 Redis가 제공하던 기능이면 충분한 Redis 사용자 80%를 정면으로 겨냥함 - Valkey의 세계에서는 새로운 **array type**이 필요하지 않다는 결론으로 이어짐 ## Comments ### Comment 57364 - Author: neo - Created: 2026-05-13T10:04:52+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/oznirn/redis_cost_ambition) - 오픈소스를 꽤 큰 규모로 키우고, 회사를 세워 수억 달러 매출과 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](https://codeberg.org/redict/redict)가 있음 그래도 Redis의 시간은 끝나가고 있다고 봄. 지금의 이상한 상업적 지형에서는 각 포크가 저마다 어딘가 절뚝거림. 가장 덕이 있는 redict조차 antirez가 독재자처럼 원 프로젝트를 밀던 시절과 같은 방식으로 Redis를 앞으로 밀고 나가려는 진짜 관심은 부족함. 소프트웨어가 “완성”되는 게 나쁘다는 뜻은 아니지만, Redis가 아직 해볼 수 있는 멋진 미발견 영역이 있다고 보며 상업적 포크들이 그런 생태계를 만들지는 의심스러움. 물론 Arrays와 AI 관련 응용의 가치를 과소평가하고 있을 수도 있으니 귀는 열어두려 함 돌이켜보면 Redis Labs가 이 모든 걸 그렇게 심하게 망친 게 놀라울 정도고, 시간이 충분히 지나 이제 화가 덜 난 건 다행임 - 기업들이 돈을 내지 않고 최대한 가져가려는 게 아닌가 싶음. 그래서 **Redis, MongoDB, HashiCorp**도 결국 라이선스를 바꾼 것 아닌가 함 - 회사에서 Lua 스크립트로 더 공정한 작업 큐 시스템을 만드는 중인데, Redis가 매우 이상하게 느껴짐. 머릿속 모델은 늘 “단순한 키-값 저장소”였는데, 글로벌 잠금 안에서 Lua 스크립트를 실행하는 기능 같은 온갖 기능을 배우게 됨 그런데 문서는 반짝거리는 웹사이트에 올라와 있고, 명확하게 알려주지 않음. 설정값도 설정 샘플 안에서만 설명되는 식임 Redis가 잘 동작한다는 건 알고 모두 그렇게 말하지만, Redis 기능을 배워가는 경험은 꽤 불편함. 누군가 정말 좋은 프로그램을 만들고, 좋은 프로그램이라면 보통 갖춰야 할 훌륭한 문서는 잊어버린 느낌임 이상한 불평이긴 함. Redis는 극도로 잘 동작하는 듯하고, Postgres 문서처럼 “전부” 설명해주는 문서를 좋아함 - TDM 지향이 덜한 제품의 문서가 더 이해하기 쉬운지 궁금함: https://valkey.io/topics/programmability/ 많은 오픈소스 프로젝트도 문서가 약하다는 걸 잘 알고 있어서, 이 실험에는 뾰족머리 상사 변수만 있는 건 아닌 듯함 - Redis에는 예전에 온갖 문서가 있었고, 다행히 Wayback Machine으로 Redis Labs가 만든 손상을 되돌릴 수 있음. 여기에서 원하는 걸 찾을 수 있을지도 모름: https://web.archive.org/web/20190725152042/https://redis.io/documentation redict도 문서가 좋아 보임: https://redict.io/docs/scripting/