Redis 8.8: Array 자료구조·INCREX·XNACK — 운영자가 알아야 할 기능 확장과 성능 변화

왜 지금 Redis 8.8을 봐야 하나

Redis 8.8이 2026년 6월에 출시됐다. Redis 8.0(2025년 5월)이 I/O 스레딩 개선과 8개 새 자료구조를 한꺼번에 가져왔다면, 8.8은 그 토대 위에서 하나의 큰 구조적 추가와 두 개의 운영 관련 명령, 그리고 확실한 성능 수치를 가져왔다.

이번 글에서 다룰 세 가지 핵심 변화:

1. Array 자료구조: Salvatore Sanfilippo가 직접 기여한 새로운 원시 자료구조. List, Set과 다른 용도.
2. INCREX 명령: 레이트 리미터 구현을 단일 원자 연산으로 줄이는 window counter.
3. XNACK 명령: Streams의 미결 메시지(PEL)를 더 세밀하게 제어하는 NACK 메커니즘.

성능 측면에서는 동기 복제(full synchronization)가 최대 60% 빨라지고, 핵심 명령 처리량이 최대 83% 향상됐다. 이 두 수치는 Redis를 복제 기반으로 운영하는 환경에서 체감 가능한 변화다.

이 글은 Valkey 9(Redis 포크, 2026년 5월 기준 별도 진화)가 아닌 Redis 오픈소스 8.8에 관한 내용이다.

Redis 8.0~8.8 맥락: 누적된 기반

Redis 8.8을 이해하려면 8.0에서 추가된 것을 먼저 알아야 한다.

Redis 8.0 (2025년 5월) 주요 추가 사항:

• I/O 스레딩 재설계: 멀티코어 CPU에서 I/O 처리를 8스레드까지 병렬화. 단일 코어 한계를 넘어 처리량 최대 2배 개선.
• 벡터 세트(beta): 벡터 저장·검색 지원. pgvector와 유사한 ANN 검색 기능을 Redis 안에서 제공.
• JSON, Time Series, 확률적 구조 기본 통합: Bloom filter, Cuckoo filter, Count-Min Sketch, Top-K, T-Digest가 별도 모듈 설치 없이 기본 제공됨.
• 복제 속도 향상: 18% 빠른 복제.

Redis 8.8은 이 위에서 Array 자료구조, INCREX, XNACK을 추가하고 복제와 핵심 명령 성능을 다시 한 번 끌어올렸다.

새 자료구조: Array (AR*)

Array란 무엇인가

Array는 Redis 8.8에서 처음 도입된 원시(native) 자료구조다. Salvatore Sanfilippo가 직접 기여했다. 인덱스로 직접 접근 가능한 문자열 값의 모음으로, 희소(sparse) 배열을 허용한다. 즉, 인덱스 0과 인덱스 1000에만 값을 저장하고 중간은 비워둘 수 있다.

Array 핵심 명령 패밀리 (AR*)

링 버퍼 모드(ARRING) 는 실용적 사용 예가 명확하다. 최근 N개의 센서 측정값, 슬라이딩 윈도우 내 이벤트 로그, 순환 버퍼가 필요한 시계열 데이터에 바로 쓸 수 있다.

# 센서 슬롯 1000번에 최신 온도 저장
ARSET sensor:rack-A 1000 "24.5"

# 인덱스 직접 읽기
ARGET sensor:rack-A 1000
# "24.5"

# 링 버퍼: 최근 100개 이벤트만 유지
ARRING event:login 100 "user:42:2026-06-15T10:30:00Z"

어디에 쓰는가

Array가 기존 자료구조보다 명확히 유리한 경우:

• 고정 슬롯 데이터: 서버 ID별 메트릭, 포트별 통계처럼 인덱스가 물리적 의미를 가질 때
• 임베딩 벡터 원본 보관: 벡터 세트에 인덱싱된 벡터의 원본 값을 인덱스로 빠르게 조회
• 링 버퍼: 최근 N개 로그를 메모리 내에서 자동 순환 보관

레이트 리미터: INCREX 명령

레이트 리미터를 Redis로 구현할 때 기존 방법은 Lua 스크립트나 MULTI/EXEC 트랜잭션이었다. 여러 명령을 조합하는 구조라 원자성과 성능 사이에서 타협이 필요했다.

INCREX는 이 용도를 위한 단일 원자 명령이다.

INCREX 시그니처

INCREX key increment [MAX max-val] [MIN min-val] [EX seconds | PX ms | EXAT timestamp | PXAT ms-timestamp | KEEPTTL] [GET]

• MAX 100: 카운터가 100을 초과하면 오류 반환.
• EX 60: 키가 없을 때 TTL 60초로 새로 생성. 이미 있으면 갱신하지 않음(KEEPTTL 기본값).
• 음수 increment로 DECR 효과도 가능.
• float increment 지원 (INCRBYFLOAT와 동등).
• GET 옵션: 이전 값 함께 반환.

TTL 60초 윈도우에서 최대 100회 허용하는 고정 윈도우 레이트 리미터를 단 한 줄로 구현한다.

Streams NACK: XNACK 명령

Redis Streams의 소비자 그룹(Consumer Group)은 메시지를 처리한 뒤 XACK으로 확인하거나, 처리하지 못하면 PEL(Pending Entry List)에 남긴다. Redis 8.8 이전에는 명시적 거부(NACK) 방법이 없었다.

문제: 처리할 수 없는 메시지(poison message)를 소비자가 받았을 때, XACK으로 삭제하거나 PEL에 그냥 방치하는 것 외에 선택지가 없었다. 다른 소비자가 빠르게 재처리하도록 하려면 PEL을 수동으로 조작해야 했다.

XNACK: 소비자가 메시지를 명시적으로 거부(NACK)하면 즉시 다른 소비자가 처리할 수 있도록 PEL 앞쪽(head)으로 이동시킨다.

PEL 내 우선순위 규칙

XNACK된 메시지는 PEL head(맨 앞)에 FIFO 순서로 배치된다. PEL 내 순서:

1. NACK된 메시지들 (head, FIFO 순)
2. ACK도 NACK도 되지 않은 일반 pending 메시지 (기존 순서 유지)

# XNACK 사용 예
XNACK mystream mygroup consumer-A msg-id-1234

# XPENDING으로 PEL 상태 확인
XPENDING mystream mygroup - + 10

이 메커니즘은 DLQ(Dead Letter Queue)와 구분된다. XNACK은 재처리 우선순위 제어이고, DLQ 패턴은 별도로 구현해야 한다. 메시지를 완전히 포기하려면 여전히 XACK 후 DLQ로 이동시키는 별도 로직이 필요하다.

성능 변화: 60% 빠른 복제, 83% 처리량 향상

두 수치 모두 실제 운영에 영향을 주는 영역이다.

동기 복제(Full Synchronization) 60% 빠름

Full sync는 Primary가 Replica에게 전체 데이터셋을 전송하는 과정이다. 발생하는 경우:

• 새 Replica 추가 시
• Replica가 Primary와 replication offset이 너무 벌어졌을 때
• Primary 재시작 후 Replica 재연결

이 과정이 느리면:

• Replica가 데이터를 받는 동안 Primary에 추가 메모리 부하가 생긴다.
• Replica가 준비되기까지 읽기 부하를 분산하지 못한다.
• 장애 상황에서 Replica 투입이 늦어진다.

Redis 8.8의 Full Sync 개선은 이 시간을 60% 단축한다. 구체적 메커니즘은 복제 스트림의 데이터 직렬화 방식과 전송 효율 개선이다.

핵심 명령 처리량 83% 향상

Redis 8.8 성능 개선 블로그에서 MGET, MSET, Streams 관련 명령, SCAN 등 주요 명령에서 최대 83% 처리량 향상을 측정했다.

이 수치는 최적 조건(다중 코어, I/O 스레딩 활성화)에서 측정된 것이다. 단일 코어 환경이나 I/O 스레딩이 비활성화된 경우 개선 폭이 다를 수 있다.

추가 변경 사항

Redis 8.8이 함께 가져온 작은 변화들:

Hash 서브키 알림(Subkey Notifications)

기존 keyspace notification은 키 전체 단위로 이벤트를 발행했다. Redis 8.8부터 Hash의 특정 필드(서브키) 변경만 구독할 수 있다.

# 특정 Hash 필드 변경 알림 구독
SUBSCRIBE __keyevent@0__:hset:user:42:email

사용자 프로필 Hash에서 이메일 필드만 변경됐을 때 알림을 받아 관련 캐시를 무효화하는 패턴이 가능해진다.

Time Series 쿼리 개선

단일 TS.RANGE / TS.MRANGE 쿼리에서 여러 집계 함수를 동시에 요청할 수 있다. 기존에는 집계 함수 하나당 쿼리 하나가 필요했다.

Sorted Set UNION/INTERSECT COUNT

ZUNIONSTORE, ZINTERSTORE에 COUNT 집계 옵션이 추가됐다. 결과 키를 별도로 저장하지 않고 교집합/합집합의 원소 수만 반환받을 수 있다.

업그레이드와 호환성

Redis 8.0 → 8.8

마이너 버전 업그레이드다. 주요 Breaking Change는 없다. 새 명령(INCREX, XNACK, AR* 패밀리)은 추가 사항이므로 기존 코드에 영향 없다.

Redis 7.x → 8.8

Redis 8.0 변경 사항(I/O 스레딩 설정, 모듈 통합 방식 변화)을 먼저 확인해야 한다. 일부 모듈 기반 기능(RedisJSON, RedisTimeSeries 등)이 8.x에서 기본 통합됐으므로 별도 모듈 로드 설정이 필요 없어졌다. 오히려 기존 loadmodule 설정이 충돌할 수 있어 정리가 필요하다.

Valkey와의 관계

Redis 8.8은 Redis Ltd.가 관리하는 오픈소스다. Valkey는 Linux Foundation 산하 커뮤니티 포크다. 두 프로젝트는 명령 수준 호환성을 유지하고 있지만 내부 구현과 기능 추가 방향이 다르다. 운영 환경에서 Redis 8.8을 선택했다면 Valkey 마이그레이션은 별도 검토가 필요한 결정이다.

운영자 도입 체크리스트

이 릴리스를 한 문장으로 요약하면

Redis 8.8은 구조적 추가(Array)와 운영 편의 명령(INCREX, XNACK), 그리고 실측 가능한 성능 개선(복제 60%, 처리량 83%)을 한 번에 가져온 릴리스다.

대규모 레이트 리미터를 Lua 스크립트로 구현해왔다면 INCREX로 교체할 이유가 충분하다. Streams 기반 메시지 파이프라인에서 poison message 처리에 머리를 썼다면 XNACK이 그 복잡도를 줄여준다. Array는 기존 패턴이 List로도 충분했던 경우엔 도입 필요성이 낮지만, 고정 인덱스 기반 희소 데이터가 있다면 살펴볼 가치가 있다.

References

• Redis 8.8 공식 발표 블로그 (2026-06): https://redis.io/blog/announcing-redis-8-8/
• Redis 8.8 공식 문서: https://redis.io/docs/latest/develop/whats-new/8-8/
• Redis Array 자료구조 문서: https://redis.io/docs/latest/develop/data-types/arrays/
• Redis Array 심층 분석 블로그 — redis.io: https://redis.io/blog/diving-deep-into-rediss-new-array-data-type/
• Redis 8.8 성능 개선 블로그 (MGET, MSET, Streams, SCAN): https://redis.io/blog/redis-88-performance-improvements-faster-mget-mset-streams-and-more/
• Redis 8.8 릴리스 노트 — GitHub: https://github.com/redis/redis/releases/tag/8.8.0
• Redis 8.8 릴리스 노트 공식 문서: https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisce/redisos-8.0-release-notes/
• ARRING 명령 공식 문서: https://redis.io/docs/latest/commands/arring/
• Redis 8.0 GA 발표 — redis.io: https://redis.io/blog/redis-8-ga/
• Redis 8.8 분석 — Phoronix: https://www.phoronix.com/news/Redis-8.8-Released