Redis 창시자 antirez가 말하는 DS4 — 데이터 구조 서버의 다음 진화

Redis의 아버지가 다시 키보드를 잡았다

Redis를 만든 Salvatore Sanfilippo(필명 antirez)가 자신의 블로그에 올린 글이 개발자 커뮤니티에서 회자되고 있어요. 제목은 "A few words on DS4"인데, 여기서 DS4는 Data Structures 4, 즉 antirez가 구상하는 차세대 데이터 구조 서버 프로젝트를 가리켜요. Redis가 사실상 "DS1"이었다고 본다면, 그가 지난 수년간 머릿속에서 굴려온 "네 번째 세대 데이터 구조 서버"의 아이디어를 풀어낸 글이에요.

이 이야기가 왜 흥미롭냐면, antirez는 2020년 Redis 메인테이너 자리에서 물러나며 "이제 코드보다 글을 쓰고 싶다"고 선언했었거든요. 그런데 2024년경 다시 Redis Labs(현 Redis Inc.)로 복귀했고, 이번에 본격적으로 차세대 데이터 시스템에 대한 비전을 공개한 거예요. Redis가 인메모리 DB의 표준이 된 지 15년이 넘은 지금, 창시자가 직접 "이대로는 부족하다"고 말하는 셈이라 무게감이 다르죠.

DS4가 풀려는 문제

antirez가 짚은 핵심 문제는 크게 세 가지예요. 첫째, 데이터 구조의 조합 가능성(composability) 문제예요. 지금 Redis는 String, List, Hash, Set, Sorted Set, Stream, Bitmap 같은 데이터 구조를 제공하지만, 이들을 자유롭게 조합하기는 어려워요. 예를 들어 "Sorted Set 안의 각 멤버에 또 다른 Hash를 붙이고 싶다" 같은 중첩 구조는 직접 키 네이밍으로 흉내 내거나 클라이언트 단에서 처리해야 했어요. DS4는 이런 구조를 언어처럼 조합 가능한 1급 객체(first-class object)로 만드는 걸 목표로 한다고 해요.

둘째, 메모리와 디스크의 경계를 더 매끄럽게. Redis는 본질적으로 인메모리 DB라 비싼 RAM을 많이 써야 하는 단점이 있어요. RDB, AOF 같은 영속화 옵션이 있지만 어디까지나 "백업" 성격이지 "활성 스토리지"는 아니거든요. antirez는 SSD 시대에 맞춰 자주 쓰는 데이터는 메모리에, 안 쓰는 데이터는 자동으로 디스크에 두는 계층형 구조를 그리고 있어요. 비슷한 시도로는 Dragonfly DB, KeyDB, Garnet(Microsoft) 같은 프로젝트가 있고, antirez도 이들을 의식하는 분위기예요.

셋째, API의 단순함을 잃지 않는 것. Redis가 사랑받는 가장 큰 이유는 "명령어 외우면 끝"인 단순함이거든요. SET, GET, LPUSH, ZADD 정도만 알면 바로 쓸 수 있어요. DS4가 강력해지더라도 이 단순함을 깨면 안 된다는 게 antirez의 철학이에요. 그는 글에서 "개발자가 5분 안에 첫 명령을 실행하지 못하는 시스템은 실패한 시스템"이라는 취지의 말을 해요.

기술적으로 무엇이 달라질까

글에서 언급된 구체적 방향들을 정리하면 이래요. 우선 타입 시스템의 확장이에요. 현재 Redis 타입을 "원시 타입"으로 두고, 사용자가 이들을 조합해서 만든 복합 타입을 서버 단에서 1급으로 다룰 수 있게 하는 거예요. 마치 SQL의 JOIN 같은 게 아니라, 데이터 구조 자체의 중첩을 네이티브로 지원하는 방향이죠.

다음은 저수준 스크립팅의 재설계예요. 현재 Redis는 Lua 스크립팅이나 Redis Functions를 쓰는데, antirez는 더 가벼우면서도 안전한 스크립팅 환경, 그리고 단일 명령으로 표현하기 어려운 트랜잭션 패턴을 자연스럽게 표현할 수 있는 DSL(도메인 특화 언어)을 고민하고 있어요.

또 하나는 클러스터 모델의 재정비. Redis Cluster는 강력하지만 운영이 까다롭다는 평가를 받아왔어요. 슬롯 기반 샤딩, MOVED/ASK 리다이렉션, 마스터-슬레이브 페일오버 같은 개념이 클라이언트에 노출되거든요. DS4는 클라이언트가 "단일 서버에 접속하는 것처럼" 느낄 수 있는 더 매끄러운 클러스터 추상을 목표로 한다고 해요.

경쟁 환경 — Redis만의 시대는 끝났다

사실 인메모리 데이터 구조 서버 시장은 더 이상 Redis 독점이 아니에요. Dragonfly DB는 멀티스레드 아키텍처로 Redis 대비 25배 처리량을 주장하고, KeyDB는 멀티스레드 Redis 포크로 자리 잡았어요. Microsoft Garnet은 .NET 기반으로 Redis 프로토콜을 호환하면서 더 빠른 성능을 내세워요. 그리고 2024년 Redis Inc.가 라이선스를 SSPL/RSAL로 바꾸면서 갈라져 나온 Valkey(리눅스 재단 산하)가 진짜 오픈소스 후계자를 자처하고 있어요.

이 와중에 antirez의 DS4 발표는 "Redis 진영이 아직 살아 있다"는 신호예요. 단순히 멀티스레드로 빨라지는 차원이 아니라, 데이터 구조 서버라는 카테고리 자체를 한 단계 끌어올리겠다는 의도예요. 다만 antirez 자신도 "DS4는 아직 아이디어 단계"라고 분명히 했고, 실제 구현이 어떻게 나올지는 시간이 걸릴 거예요.

한국 개발자에게 주는 시사점

Redis는 한국에서도 거의 모든 백엔드의 기본 컴포넌트로 자리 잡았어요. 세션 저장, 캐시, 큐, 실시간 랭킹, 분산 락까지 안 쓰이는 곳이 없어요. 그래서 Redis의 미래 방향은 곧 우리 시스템 설계의 미래에 직접 영향을 줘요.

당장 실무에 영향을 줄 일은 없지만, 두 가지는 지금부터 챙겨두면 좋아요. 하나는 Valkey와 Redis의 라이선스 분기점을 이해하는 거예요. 회사에서 Redis를 클라우드로 쓰고 있다면 어느 쪽으로 정렬할지가 중장기 의사결정이 돼요. 다른 하나는 인메모리 DB의 대안들(Dragonfly, KeyDB, Garnet)을 한 번씩 벤치마킹해보는 거예요. 워크로드에 따라 의외로 큰 성능 차이가 나는 경우가 있어요.

그리고 antirez의 글을 직접 읽어보는 것도 추천해요. 영어로 길지 않고, 시스템 설계자가 "좋은 추상화란 무엇인가"를 고민하는 사고 과정을 그대로 보여주는 글이거든요. 코드를 짤 때보다 설계를 할 때 도움이 되는 글이에요.

마무리

DS4는 아직 코드 한 줄 없는 비전 문서지만, 그 비전을 던진 사람이 antirez라는 점에서 가볍지 않아요. Redis가 그랬듯, 단순한 아이디어가 업계 표준이 되는 데는 그리 오랜 시간이 걸리지 않을 수도 있어요.

여러분은 Redis의 어떤 점이 가장 아쉬우셨나요? DS4가 그걸 해결한다면 갈아탈 의향이 있으세요? 아니면 "Redis는 지금도 충분하다"는 입장이세요?