Redis와 야망의 비용: 기능 크리프가 정체성을 침식할 때
우아함의 시대: 데이터 구조 서버로서의 Redis
초기 시절에 Redis는 2010년대 초반의 시대 정신을 포착했다. "웹 스케일"이 실제적인 아키텍처 목표였고 업계가 NoSQL 패턴으로 이동하던 시기에 등장했다. Redis는 완전한 데이터베이스로 자리매김하지 않았으며, 대신 고급 키-값 저장소이자 데이터 구조 서버였다.
그 초기 성공은 세 가지 핵심 설계 기둥에 기반했다:
- 단순하고 표현력 있는 프로토콜: 와이어 프로토콜이 직관적이라 몇 시간 안에 구현할 수 있었으며, 클라이언트 라이브러리 개발을 깔끔하고 접근하기 쉽게 만들었다.
- 목적 지향 아키텍처: 단일 스레드 이벤트 기반 모델과 인메모리 저장소를 결합함으로써 Redis는 복잡한 락 메커니즘을 없애고 모든 연산에 원자성을 보장하여 시스템을 이해하기 쉽게 만들었다.
- 세련된 기본 구조: 문자열, 리스트, 집합, 정렬된 집합과 같은 데이터 구조 선택은 캐싱, 큐잉, 리더보드 등 일반적인 웹 애플리케이션 요구에 완벽히 부합했다.
야망으로의 전환
시간이 지나면서 프로젝트의 야망이 변했다. Redis는 보조 유틸리티 역할을 넘어 주요 데이터베이스와 경쟁하기 시작했다. 이 전환 과정에서 개발자 생태계의 "최신 트렌드"를 반영한 기능들이 도입되었다:
- 문서 저장소: MongoDB와 경쟁하기 위해 JSON 지원을 추가했다.
- 검색 및 질의: ElasticSearch와 경쟁하기 위해 전체 텍스트 검색을 구현했다.
- 이벤트 스트리밍: Kafka 열풍을 포착하기 위해 Streams를 도입했다.
- 강한 일관성: etcd 또는 ZooKeeper와 경쟁하기 위해
Redis-Raft구현을 시도했다. - AI 통합: 벡터 저장소를 활용해 "AI 앱을 위한 실시간 컨텍스트 엔진"이 되려는 방향으로 전환했다.
이러한 "우주인 모드" 개발—특정 사용자 문제점보다 개인적인 도전이나 유행에 대한 반응으로 기능을 만드는 방식—은 종종 미완성 구현으로 이어졌다. 대표적인 예가 Disque라는 전용 메시지 브로커인데, 사람들은 Redis를 메시징에 사용한 이유가 다른 복잡한 브로커를 관리하고 싶지 않았기 때문이라는 점을 오해하여 대부분 포기되었다. didn't
기술적·전략적 비용
이 확장은 대가를 수반한다. 저자는 RESP3로의 전환에서 "두 번째 시스템 효과"가 드러났으며, 이는 RESP2의 기본 요청/응답 가정을 깨뜨렸다라고 주장한다. 또한 Redis Inc.의 기업 수익화 추진은 2024년에 BSD에서 벗어난 논란이 되는 라이선스 변경으로 이어져 오픈소스 커뮤니티와의 균열을 만들었다.
핵심은 "범용 데이터베이스"가 되려는 야망이 근본적인 진실을 무시한다는 점이다: 전문 수준의 검색 엔진이나 강한 일관성을 갖춘 분산 락 매니저가 필요한 사용자는 일반적으로 해당 목적에 맞게 설계된 전용 도구를 원할 뿐, 캐시 위에 얹어진 모듈을 원하지 않는다.
반론 및 시장 반응
모두가 이 확장이 실패라고 동의하는 것은 아니다. 일부는 Redis의 핵심 기능이 여전히 유지되고 있으며, 더 많은 데이터 구조를 추가한다고 해서 단순 키-값 저장소로 사용하는 경험이 본질적으로 악화되는 것은 아니라고 주장한다. 또 다른 사람들은 PostgreSQL을 성공적인 "모두를 처리하는" 데이터베이스의 예로 들며, JSON, 벡터, 관계형 데이터를 처리하면서도 정체성을 잃지 않았다고 지적한다.
하지만 시장은 이미 판결을 내리기 시작했다. Valkey의 등장은 핵심으로의 전략적 후퇴를 의미한다. 기능 체크리스트를 쫓는 대신 Valkey는 화려하지 않지만 필수적인 작업—멀티스레드 성능, 메모리 효율성, 클러스터 신뢰성—에 집중한다. 이는 2011년의 Redis와 같은 고성능, 예측 가능한 도구를 단순히 원하는 80%의 사용자를 목표로 한다.
결론
Redis의 여정은 원래 가치 제안을 잃어버리는 위험성을 보여준다. 도구가 특정 문제에 대한 집중된 솔루션을 멈추고 모든 문제를 해결하려 하면, 결국 자체 복잡성의 무게에 무너지는 "바벨탑"이 될 위험이 있다.