Redis 자리를 노리는 프로젝트가 또 나왔어요
KiviDB라는 오픈소스 프로젝트가 공개됐어요. 내세우는 건 두 가지예요. 하나는 Redis와 호환되면서 더 빠른 인메모리 데이터베이스, 다른 하나는 벡터 캐시예요. 각각은 낯설지 않은데, 이 둘을 한 제품으로 묶었다는 점이 요즘 흐름을 잘 보여줘요. 아직 초기 프로젝트라 오늘은 KiviDB 하나만 파기보다는, 이런 프로젝트가 왜 계속 나오는지와 새 Redis 대안을 만났을 때 뭘 확인해야 하는지를 같이 정리해볼게요.
‘Redis 호환’이 뭐길래
Redis는 데이터를 디스크가 아니라 메모리에 두고 쓰는 키-값 저장소예요. 로그인 세션, 캐시, 실시간 랭킹, 선착순 이벤트 대기열처럼 빨라야 하는 곳엔 거의 다 들어가 있죠.
‘Redis 호환’은 Redis가 클라이언트와 대화할 때 쓰는 규칙인 RESP 프로토콜을 똑같이 구현했다는 뜻이에요. 그러면 지금 쓰는 redis-py, ioredis, Lettuce 같은 클라이언트를 그대로 두고 접속 주소만 바꾸면 돼요. 콘센트 모양이 같으면 어느 회사 플러그든 꽂히는 것과 같아요. 애플리케이션 코드를 거의 안 고치고 갈아탈 수 있다는 게 가장 큰 매력이에요.
왜 다들 Redis보다 빠르다고 할까
Redis는 명령 실행을 기본적으로 스레드 하나에서 처리해요. 단순하고 예측 가능한 대신, 코어가 수십 개인 요즘 서버에서는 CPU를 다 못 쓰는 셈이에요. 그래서 대안들은 대부분 여기를 파고들어요.
- KeyDB: Redis를 포크해서 멀티스레드로 바꾼 초기 시도예요.
- Dragonfly: 처음부터 새로 짠 엔진으로, 데이터를 코어별로 나눠 맡기는 구조라 코어가 늘수록 성능도 따라 올라가요.
- Garnet: 마이크로소프트 리서치가 C#으로 만든 RESP 호환 캐시 서버예요.
- Valkey: 2024년 Redis 라이선스 변경 이후 리눅스 재단 아래에서 나온 포크로, I/O 스레딩을 개선하며 성능을 꾸준히 올리고 있어요.
벡터 캐시는 또 뭐예요?
이게 뭐냐면, LLM 서비스를 위한 의미 기반 캐시예요. 고객센터 챗봇에 누가 “환불 어떻게 해요?”라고 묻고, 다음 사람이 “환불 방법 알려주세요”라고 물었다고 해볼게요. 일반 캐시는 문자열이 정확히 같아야 결과를 재사용하니까 두 번째 질문은 놓쳐요. 결국 LLM을 또 호출하고 비용과 시간이 또 들죠.
벡터 캐시는 질문을 임베딩 벡터(문장의 의미를 숫자 배열로 바꾼 것)로 저장해두고, 새 질문이 오면 의미가 충분히 가까운 이전 질문을 찾아 그 답을 돌려줘요. 비슷한 질문이 반복되는 서비스라면 LLM 호출 비용과 응답 시간을 꽤 줄일 수 있어요.
Redis 진영도 이미 이 방향이에요. Redis는 검색 엔진 기능으로 벡터 검색을 지원해왔고, Redis 8에는 벡터 셋(Vector Set)이라는 자료형까지 들어갔어요. 인메모리 DB가 벡터를 다루는 건 이제 업계 표준에 가까운 흐름이고, KiviDB는 이걸 처음부터 핵심 기능으로 내건 셈이에요.
새 Redis 대안을 볼 때 체크리스트
1. 벤치마크 조건: 파이프라이닝을 켰는지, 커넥션과 스레드는 몇 개인지, 값 크기는 얼마인지, 평균 말고 p99 지연시간(가장 느린 1% 요청의 응답 시간)은 어떤지.
2. 호환 범위: GET/SET만 되는지, Lua 스크립트, MULTI/EXEC 트랜잭션, Pub/Sub, Streams, 클러스터 모드까지 되는지.
3. 영속성과 복제: 서버가 죽어도 데이터가 남는지, 레플리카 구성이 되는지.
4. 성숙도와 라이선스: 커밋이 꾸준한지, 이슈에 답이 오는지, 상업적으로 써도 되는지.
KiviDB가 이 항목을 어디까지 채웠는지는 저장소에서 직접 확인하고, memtier_benchmark 같은 도구로 우리 서비스와 비슷한 패턴의 부하를 걸어보는 게 제일 확실해요.
한국 개발자에게는
국내 서비스는 Redis 의존도가 정말 높아요. 쿠폰 발급, 티켓팅 대기열, 게임 랭킹처럼 순간 트래픽이 몰리는 곳에서 특히 그렇죠. 그래서 Redis 대안은 ‘빠르다’보다 ‘안 깨진다’가 먼저예요. 운영 환경을 바로 바꾸기보다 스테이징에서 실제 트래픽을 재생해보거나, 날아가도 괜찮은 캐시 용도부터 시험해보길 추천해요.
반대로 RAG 챗봇이나 LLM 기능을 만들고 있다면 벡터 캐시는 지금 바로 실험해볼 만해요. 다만 한국어는 조사와 어미 변화가 많아서 유사도 기준값을 영어 예제 그대로 쓰면 엉뚱한 답을 재사용할 수 있어요. ‘환불’과 ‘교환’처럼 비슷하지만 다른 질문을 테스트 세트에 꼭 넣어보세요.
마무리
인메모리 DB 경쟁은 이제 속도만이 아니라 AI 워크로드를 얼마나 잘 받아내느냐로 넘어가고 있어요.
여러분 팀은 Valkey나 Dragonfly 같은 Redis 대안으로 옮겨본 적 있나요? LLM 응답에 시맨틱 캐시를 붙여봤다면, 캐시 적중률과 엉뚱한 답 사이의 균형은 어떻게 잡으셨는지 궁금해요.
🔗 출처: Hacker News