Redis 8.8 — 배열 자료구조와 내장 레이트 리미터가 들어왔다

Redis가 또 한 발 나아갔어요

백엔드 개발자치고 Redis 안 써본 사람 찾기 어렵죠. 캐시로 쓰든, 세션 저장소로 쓰든, 큐로 쓰든 거의 만능처럼 등장하는 인메모리(메모리 기반) 데이터 저장소예요. 디스크가 아니라 메모리에 데이터를 두니까 엄청 빠른 게 핵심이고요. 이번에 나온 Redis 8.8은 단순 성능 개선을 넘어, 그동안 우리가 '직접 손으로 구현하던' 패턴들을 아예 기본 기능으로 끌어안았다는 점에서 눈여겨볼 만해요.

새 배열(Array) 자료구조

그동안 Redis에서 '순서 있는 목록'을 쓰려면 List(연결 리스트 기반)나 Sorted Set을 활용했어요. 그런데 List는 가운데 임의 위치의 원소를 인덱스로 빠르게 접근하기엔 약하고, Sorted Set은 점수(score) 개념을 억지로 끼워 맞춰야 하는 불편함이 있었죠.

새로 들어온 배열 자료구조는 이름 그대로, 우리가 프로그래밍 언어에서 쓰는 배열처럼 인덱스로 원소에 바로바로 접근하는 데 최적화된 타입이에요. 이게 뭐냐면, arr[5] 같은 접근이 빠르고, 메모리도 연속적으로 효율적으로 쓰는 구조라는 거예요. 고정된 크기의 순서 데이터(예: 시계열 버킷, 좌표 묶음, 고정 슬롯 데이터)를 다룰 때 List보다 훨씬 자연스럽고 가벼워요.

내장 레이트 리미터(Rate Limiter)

개인적으로 제일 반가운 부분이에요. API 호출 횟수 제한 같은 기능, 다들 한 번쯤 직접 만들어봤잖아요. "한 유저가 1분에 100번까지만 요청 가능" 같은 거요.

예전엔 이걸 Redis로 구현하려면 Sorted Set에 타임스탬프를 쌓거나, INCR과 EXPIRE를 조합하거나, 정확성을 위해 Lua 스크립트로 원자적(atomic) 처리를 직접 짜야 했어요. 이게 뭐냐면, 여러 요청이 동시에 들어올 때 카운트가 꼬이지 않게 하려고 꽤 신경 써서 코드를 짜야 했다는 거예요. 토큰 버킷이니 슬라이딩 윈도우니 알고리즘도 직접 골라 구현해야 했고요.

Redis 8.8은 이 레이트 리미팅을 명령어 하나로 처리할 수 있게 내장했어요. 한도와 시간 창을 지정하면 '허용/차단'과 남은 횟수를 알아서 원자적으로 계산해주는 거죠. 동시성 문제를 서버 내부에서 처리해주니까, 우리가 직접 Lua를 붙들고 씨름할 일이 크게 줄어든 거예요.

성능 개선과 업계 맥락

여기에 더해 전반적인 처리량과 메모리 효율 개선도 함께 들어갔어요. Redis는 최근 라이선스 변경 이슈로 Valkey라는 포크(갈라져 나온 프로젝트)가 생기면서 경쟁 구도가 만들어졌거든요. 이런 상황에서 Redis 본가가 '우리는 계속 의미 있는 새 기능을 빠르게 낸다'는 걸 보여주는 행보로도 읽혀요. 레이트 리미터나 배열처럼 개발자가 실제로 자주 부딪히는 문제를 기본 제공으로 흡수하는 전략이죠.

한국 개발자에게는

트래픽 많은 서비스를 운영한다면 내장 레이트 리미터는 당장 검토 대상이에요. 직접 짠 Lua 기반 리미터를 표준 명령어로 교체하면 코드가 단순해지고 버그 여지도 줄어요. 다만 곧바로 운영에 올리기 전에, 기존 자체 구현과 동작이 정확히 일치하는지 부하 테스트로 검증하는 건 꼭 거치세요. 한도 경계에서의 동작(정확히 100번째 요청 처리 등)은 구현마다 미묘하게 다를 수 있거든요.

또 새 배열 타입은 기존 List를 무조건 대체하는 게 아니라 용도에 맞을 때 쓰는 거예요. 끝에서 push/pop이 잦은 큐라면 여전히 List가 맞고, 인덱스 접근이 핵심이면 배열이 유리해요.

정리하면

Redis 8.8은 '자주 쓰던 패턴을 기본기로 내재화'한 업데이트예요. 우리가 매번 다시 짜던 레이트 리미터와 배열 접근을 표준으로 가져온 거죠.

여러분은 지금 레이트 리미팅을 어떻게 구현하고 있나요? 내장 기능으로 갈아탈 생각이 드시나요, 아니면 세밀한 제어 때문에 직접 짠 코드를 유지하실 건가요?