08 · 무엇을 고를 것인가 — Redis · Valkey · memcached 판단표

왜 이 문서인가. 앞 7개 문서는 각각 “무엇이 사실인가” 를 소유합니다. 이 문서는 새 사실을 도입하지 않고 그 사실들을 결정으로 압축합니다. 모든 행에 근거 문서로 가는 링크가 붙고 근거 없는 취향 서술은 넣지 않았습니다 — 근거가 부족한 자리는 §7 에 미확인으로 남겼습니다.

배지 규약. ✓ = 앞 문서가 1차 근거(소스·릴리스노트·공식 문서 원문)로 확정한 사실에서 곧바로 나오는 판단. ≈ = 2차 근거이거나 조건이 붙어야 성립하는 판단. Σ = 여러 사실을 엮은 종합 판단 — 사실이 아니라 추론이므로 전제가 깨지면 결론도 깨집니다. 기준일 2026-08-06, 기준 버전은 Redis Open Source 8.10.0(2026-07-29) · Valkey 9.1.1(2026-07-21) · memcached 1.6.45(2026-07-09) 입니다.

1. 한눈에 — 세 줄 결론

세 줄은 서로 다른 축을 봅니다. 신규 채택은 거버넌스가, 기존 Redis 는 RDB 버전이, 순수 캐시는 관리형 지원 버전이 결정합니다 Σ.

2. 3자 판단표

각 칸은 앞 문서가 확정한 사실이고 판정 열이 이 문서의 기여입니다.

3. 케이스별 판단

3.1 신규로 캐시만 필요하다

• 조건 — 값이 blob 이고 잃어도 되고 다중 키 원자성이 필요 없고 TTL·CAS·incr 이면 표현이 끝납니다.
• 선택 — 자체 운영이면 memcached 1.6.45, 관리형으로 가야 하면 ElastiCache Valkey(캐시 용도로) Σ.
• 왜 — memcached 는 이 조건에서 Redis 계열에 없는 것을 줍니다 — 프로세스 하나로 코어를 먹는 확장, 느린 커맨드가 존재할 수 없는 지연 예측성, 프로토콜 내장 stampede 방어(02) ✓. 그런데 관리형으로 가면 그 강점이 사라집니다 — ElastiCache 의 확인 최신이 1.6.22 이므로 1.6.34 의 slab mover 재작성(재배치 시 아이템 손실 제거)과 1.6.4x 보안 수정을 못 받습니다 ✓. 아이템 크기 분포가 시간에 따라 변하는 캐시에서 calcification 리스크를 지고 갈 이유가 없습니다 Σ.
• 되돌릴 수 있나 — 거의 공짜로 되돌릴 수 있습니다. 영속성이 없어 이주 대신 재구축이 되고 대가는 cold cache 창의 thundering herd 하나입니다 ✓. 이 케이스는 이 문서에서 리스크가 가장 낮은 결정이라 오래 고민할 가치가 없습니다 Σ.

3.2 신규로 자료구조·영속성이 필요하다

• 조건 — sorted set·stream·hash 필드 TTL 같은 서버측 자료구조 연산이 필요하고 RDB/AOF 로 복구할 수 있어야 합니다.
• 선택 — Valkey 9.1.x Σ.
• 왜 — 세 축이 같은 방향을 가리킵니다. (a) 라이선스가 BSD-3 이고 재변경 장벽이 조문으로 있습니다(03) ✓. (b) 8.1 의 새 hashtable 이 키당 20~30B 를 설정 변경 없이 회수하고 9.0 부터 io-threads 를 런타임에 켤 수 있습니다(05) ✓. (c) ElastiCache 에서 7.1 위로 갈 수 있는 유일한 엔진이라 self-host → 관리형 경로가 열려 있습니다(07) ✓.
• 되돌릴 수 있나 — Valkey 9.x 를 고르는 순간 파일 레벨 복귀는 끝납니다. RDB 80 은 Valkey 8.x 도 거부하고 12~79 예약 때문에 Redis 쪽으로 돌아가는 경로도 없습니다 ✓. 롤백 계획은 “RDB 되돌리기” 대신 “전환 직전 스냅샷 보관 + 논리적 재적재” 로 세워야 합니다 Σ. 이 제약을 감당할 수 없다면 8.1.x 에 머무는 선택도 있습니다(RDB 11 이라 Redis 와 파일 호환) — 대가로 HFE·cluster multi-DB·DB 단위 ACL 을 포기합니다 ✓.

3.3 이미 Redis 7.2 이하를 쓰고 있다

먼저 라이선스 경계에 걸리는지부터 판정합니다. 걸리지 않으면 이 절의 나머지는 읽을 필요가 없습니다 Σ.

• 선택 A — 위 표에서 하나도 걸리지 않습니다 → 7.2 라인에 머무르거나 Redis 8.2 로 올립니다 Σ. 7.2 는 Extended 로 EOL 2029-12-01 이고 6.2 도 2027-04-01 까지 살아 있습니다(04) ✓. 7.2 는 2023-08-15 이후 기능이 동결돼 있고 보안 유지의 실질 상류가 어디인지도 봐야 합니다 — Debian 의 redis 패키지는 CVE-2026-21863 패치를 Valkey 커밋에서 복사해 붙였는데 반환값 의미가 반대여서 새 DoS 가 생겼습니다. 이 계보에서 보안 패치가 실제로 어떻게 흐르는지가 이 사례(#1136392)에 그대로 드러납니다(03) ✓.
• 선택 B — 걸립니다 → Valkey 로 갑니다. 그리고 지금이 그 이주가 싼 마지막 구간입니다 Σ. 7.2 이하는 양쪽 RDB 11 이라 복제로 컷오버합니다 — Redis 의 host/port 를 확인해 Valkey 에서 REPLICAOF → INFO REPLICATION 동기 확인 → 애플리케이션 전환 → REPLICAOF NO ONE 승격, 사실상 무중단입니다(05) ✓. Redis 를 7.4 로 한 번 올리면 이 경로가 영구히 닫힙니다 ✓.
• 되돌릴 수 있나 — 선택 B 는 되돌릴 수 있습니다, 단 Valkey 8.x 에 머무는 동안만입니다. 8.x 는 RDB 11 이라 Redis 가 읽습니다 ✓. 9.x 로 올리면 그 창이 닫힙니다(§3.2) ✓.

3.4 이미 Redis 8.x 를 쓰고 있다

• 조건 — 7.4 이상, 즉 RDB 12 이상.
• 선택 — Redis 에 머뭅니다. 그리고 버전을 정리합니다 Σ.
• 왜 — 이주 경로가 사실상 없습니다. RDB·복제·DUMP/RESTORE 세 경로가 모두 막혀 있고(05) 남는 것은 애플리케이션 이중 쓰기 또는 논리적 재적재 + import-mode yes + CLIENT IMPORT-SOURCE ON 뿐입니다 ✓. 이 비용을 지불할 이유는 §3.3 표의 라이선스 경계에 실제로 걸릴 때뿐이고 사내 캐시 용도라면 걸리지 않습니다 Σ.
• 정리해야 하는 것 — (a) 8.0 은 2026-12-01 에 지원이 끝납니다 ✓. (b) 5년 지평이 필요하면 8.x 안에서 Extended 는 8.2 하나(EOL 2030-09-01)입니다 ✓. (c) ACL 을 다중 테넌시 경계로 쓰고 있다면 8.6 의 MSETEX key-pattern 우회와 8.10 의 SORT/GEORADIUS/XREAD 계열 우회(#15478)를 받았는지 확인해야 합니다 — 04는 이 근거로 “8.10 이 사실상 최소 버전” 이라고 판정합니다 ✓. 8.2 유지보수 라인에 #15478 이 백포트됐는지는 앞 문서들에 근거가 없습니다 ? — “5년 지원(8.2)” 과 “ACL 경계(8.10)” 가 충돌하면 백포트를 확인하기 전에 8.2 를 고르지 마십시오 Σ.
• 되돌릴 수 있나 — 8.6 이후로는 없습니다. RDB 가 13·14·15 로 매 릴리스 오르므로 다운그레이드는 replication 대신 논리적 재적재로 계획해야 하고 그 RESTORE 경로 자체가 8.8 CVE 목록이 지목한 공격면입니다 Σ.

3.5 벡터 검색·JSON·전문검색이 필요하다

• 조건 — Search/Vector/JSON/TimeSeries/확률형 자료구조 중 하나 이상이 애플리케이션 요구사항입니다.
• 선택 — Redis 8.x. 단 세 개의 조건을 받아들일 때만입니다 Σ.
• 왜 — 이 축에서만 Valkey 가 명확히 집니다. Valkey 코어에 검색·JSON·시계열·확률형이 없고 공식 모듈 4개에 TimeSeries·Cuckoo·Count-min·Top-K·t-digest 대응물이 아예 없으며 valkey-json 최신이 2025-09-08 로 1년 가까이 멈춰 있습니다(05) ✓.
• 받아들여야 하는 조건 — (1) “core 통합” 은 번들입니다. 소스에서 make 만 하면 코어뿐이고 모듈을 원하면 8.0 계열은 빌드 중 네트워크와 Rust 1.80.1 을 요구합니다(에어갭은 8.10 의 tarball 경로) ✓. 설정은 redis.conf 가 아니라 redis-full.conf 를 가리켜야 하고 그 파일은 make modules-update 마다 재생성됩니다 — 직접 넣은 설정이 사라집니다(04가 빌드 구조를 소유합니다) ✓. (2) Vector Set 은 8.0 에서 beta 로 나온 뒤 GA 선언 문장이 없습니다 — 8.6~8.8 에 SIMD 최적화와 크래시 수정이 집중됐고 문서에서 beta 문구가 사라진 것까지가 확인 가능한 성숙도입니다 ✓. big-endian 에서 8.2 이전에 벡터셋을 썼다면 그 RDB 는 신뢰할 수 없습니다 ✓. (3) 관리형이 아닙니다 — ElastiCache 에 Redis 8.x 가 없으므로 self-host 를 전제합니다(07) ✓.
• Valkey 로 이 요구를 받으려면 — valkey-search 를 추가하는 선택은 있지만 모듈을 하나라도 로드하면 CLUSTER MIGRATESLOTS 가 거부됩니다 — 공식 4개 모듈 전부가 ASM opt-in 플래그를 선언하지 않고 valkey-bundle 이미지는 4개를 다 로드합니다(06) ✓. Valkey + 모듈 + atomic slot migration 은 함께 성립하지 않으므로, 리샤딩을 일상 작업으로 쓸 계획이면 이 조합을 배제해야 합니다 Σ.
• 되돌릴 수 있나 — 모듈 데이터는 RDB 롤백 논의 밖에 있습니다. 7.4~8.4 구간은 RDB 12 로 같아 코어 데이터의 롤백 여지가 있었지만 그것도 “모듈 데이터 제외” 조건이 붙습니다 ✓. 검색 인덱스·벡터를 재구축하는 시간을 롤백 계획의 실제 소요로 잡아야 합니다 Σ.

3.6 AWS 관리형에 얹혀 있다

• 조건 — ElastiCache 또는 MemoryDB 를 쓰고 있고 엔진 선택을 다시 검토합니다.
• 선택 — ElastiCache Valkey. 사실상 선택지가 없습니다 ✓.
• 왜 — Redis OSS 는 7.1 에서 멈췄고 그 위는 전부 Valkey 입니다. ElastiCache 에 Redis 8 은 없습니다(07) ✓. 엔진 전환의 리스크는 모드 전환과 정반대로 낮습니다 — in-place 이고 “including the endpoint DNS name, will remain unchanged” 이며 바뀌는 것은 노드 IP 뿐입니다 ✓. 다운타임은 Redis OSS 5.0.6 이상이면 failover 몇 초, 그 미만이면 DNS 전파 동안 30~60초입니다 ✓.
• 섞으면 안 되는 두 작업 — 엔진 전환(Redis OSS → Valkey)과 모드 전환(CMD → CME)은 리스크 등급이 다릅니다 Σ. 전자는 엔드포인트가 유지되고 롤백 경로가 하나 있습니다(Valkey 7.2 → Redis OSS 7.1) ✓. 후자는 엔드포인트 문자열 + 클라이언트 클래스 + 애플리케이션의 다중 키 연산 + 파라미터 그룹 네 층이 함께 바뀌고 AWS 문서가 “Reverting this configuration is not possible” 로 명시한 단방향입니다 ✓. 두 작업을 한 변경 창에 넣으면 실패 원인을 분리할 수 없습니다 Σ.
• DNS TTL 을 먼저 손댑니다 — 엔진 전환에서 노드 IP 가 바뀌므로 07의 networkaddress.cache.ttl 5~10초 지시가 그대로 걸립니다. 기본값이면 “never refresh DNS entries until the JVM is restarted” 이고 security property 라서 -D 로는 안 들어갑니다 ✓. failover 자체는 몇 초이고 장애 시간을 만드는 것은 클라이언트 캐시라는 사실이 여기서 그대로 반복됩니다 ✓.
• MemoryDB 는 판단 근거가 2026-06 에 바뀌었습니다 — AWS 자신의 권고가 “multi-Region active-active replication with conflict-free data types (CRDTs)” 로 좁아졌고 단일 리전 durable 워크로드는 durability 를 켠 ElastiCache 를 권합니다 ✓. “내구성이 필요하면 MemoryDB” 는 더 이상 AWS 의 권고가 아닙니다 ✓. 엔진 버전 격차도 실무 요소입니다(MemoryDB 문서 목록은 7.3 / Valkey 7.2.6 까지) ✓.
• 관리형을 벗어날 이유가 있는지 — config·debug·bgsave·replicaof 가 막혀 있고 MemoryDB 는 acl setuser·cluster setslot·module 까지 막습니다 ✓. 남는 유일한 설정 경로가 파라미터 그룹이므로 런타임 CONFIG SET·모듈·직접 슬롯 통제 셋 중 하나가 요구사항이면 self-host 가 후보가 됩니다 — 그 외에는 관리형을 벗어나는 것이 손해입니다 Σ.
• 되돌릴 수 있나 — 엔진 전환은 Valkey 7.2 → Redis OSS 7.1 한 경로만 있습니다(user/user group 이 engine type REDIS 여야 합니다) ✓. 8.0 이상으로 올린 뒤에는 없습니다 ✓. 모드 전환은 compatible 단계에서만 되돌릴 수 있고 enabled 를 넘으면 없습니다 ✓.

4. 버전 선택 — 지금 무엇을 깔아야 하나

4.1 Redis 진영

8.10 을 장기 지원으로 가정하면 안 됩니다 — 지원 표에 등재조차 되지 않았고 Standard/Extended 구분이 미정입니다 ✓. 이 진영의 실제 선택은 “5년(8.2) vs 최신 보안 표면(8.10)” 이고, 둘이 충돌할 때 판정은 §3.4 의 마지막 줄에 있습니다 Σ.

4.2 Valkey 진영

“9.1 은 2031년까지 안전하다” 를 계획의 전제로 삼지 않습니다 — security 5년은 각 major 의 “최신 minor” 에만 붙고 9.2.0 GA 목표가 2026-11-15입니다. 지위를 잃으면 규칙상 2029-05-19 로 당겨지지만 “되돌린다” 고 명시한 문장은 확인되지 않았습니다 ≈. 지원 종료일을 계약이나 감사 근거로 써야 하면 이 불확실성을 그대로 문서에 남기는 편이 안전합니다 Σ.

4.3 memcached

성숙도 판정은 한 줄입니다 — 프로젝트는 살아 있지만 기능 개발은 멈춰 있습니다. 최근 1년의 사용자 노출 신기능은 1.6.40 의 mg 조건부 CAS 페치 하나이고 1.6.45 는 33 커밋 전부가 한 사람입니다 ✓. 이것을 “안정” 으로 읽을지 “정체” 로 읽을지가 이 진영 선택의 실제 쟁점입니다 Σ.

5. 마이그레이션 경로표

표를 관통하는 규칙이 하나 있습니다. 되돌릴 수 없는 전환은 전부 버전 숫자 하나(RDB 12 / RDB 80 / ClusterMode: enabled)로 표시되고 그 숫자를 넘기 전에는 거의 모든 것을 되돌릴 수 있습니다 Σ. 마이그레이션 계획의 첫 항목은 방법을 고르는 일이 아닙니다. “이번 창에서 넘는 편도 경계가 몇 개인가” 를 먼저 셉니다 — 두 개 이상이면 창을 쪼갭니다 Σ.

6. 고르지 않아도 되는 것

이 절은 앞 다섯 절을 부분적으로 무력화합니다. 위 판단표가 거의 중요하지 않은 케이스가 있고 그 경우 이주 자체가 순손실입니다 Σ.

여기서 나오는 마지막 판정이 이 문서의 결론입니다. 엔진 선택은 라이선스·번들 모듈·관리형 지원 버전이 실제로 우리를 제약할 때만 결정으로서 존재하고 그 셋 중 아무것도 걸리지 않으면 지금 쓰는 쪽을 계속 쓰는 것이 정답입니다 Σ. 앞 7개 문서가 확정한 사실 중 이주를 강제하는 것은 딱 세 개입니다 — 8.0 의 EOL 2026-12-01, 외부 제공·재배포가 로드맵에 있는 경우의 라이선스 경계, 그리고 관리형에서 7.1 위로 가려는 경우 ✓.

7. 근거

이 문서는 새 1차 근거를 만들지 않습니다. 모든 사실의 소유 문서는 다음과 같습니다.

• 자료구조 서버의 제약이 왜 이 모양인가(단일 스레드 = API 계약, threaded I/O 의 경계, RDB_VERSION 이 곧 다운그레이드 차단선) — 01 · 2009 첫 커밋부터 6.2 까지
• memcached 의 구조와 2026년 상태(slab calcification 연대기, 4단 segmented LRU, 워커별 이벤트 루프, meta 프로토콜과 stampede 방어, extstore·restartable cache 가 영속성이 아닌 이유, 관리형 현황, 버스 팩터) — 02 · memcached
• 라이선스 원문과 거버넌스 구조(RSALv2 금지형 vs SSPLv1 조건형, AGPL 추가가 철회가 아닌 이유, CLA vs DCO + 1/3 상한 + 2/3 super-majority, 사내 사용 허용 FAQ #20, 걸리는 네 케이스, 배포판 반응) — 03 · 왜 찢어졌나
• Redis 7.0 → 8.10 의 실제 내용(9.x 부재 전수 확인, 짝수 마이너 케이던스, 모듈 번들의 실제 형태, Vector Set 의 beta 상태, 성능 주장의 조건, Standard/Extended 지원선과 EOL, 릴리스별 breaking·CVE) — 04 · Redis 7.0 → 8.10
• Valkey 8.0 → 9.1 의 실제 내용(async I/O 스레딩 교체, dual channel 의 와이어 비호환, 8.1 새 hashtable, RDB 80 분기와 foreign 예약, HFE 동작 차이, 지원 정책 3년+5년, 모듈 생태계, 마이그레이션 사실관계) — 05 · Valkey 8.0 → 9.1
• cluster mode 가 강제하는 것(16384 의 gossip 예산 근거, MOVED/ASK 구분, 잃는 것 8종, 양 진영 ASM 의 반대 방향, 모듈이 ASM 을 막는 게이트, cluster_state:ok 의 세 구멍) — 06 · cluster mode
• AWS 엔드포인트·엔진·모드(엔드포인트 판별 규칙, CMD→CME 단방향, 엔진 전환의 in-place 성격, DNS TTL 지시, TLS 전환이 엔드포인트 마이그레이션인 이유, 관리형이 막는 커맨드, MemoryDB 포지셔닝 변화) — 07 · AWS 에서 엔드포인트는 어떻게 바뀌나

이 문서가 근거 없이 판정하지 않은 것 — 앞 문서들이 미확인으로 남긴 항목은 이 문서에서도 결론으로 쓰지 않았습니다.

• 성능 배수 비교 — memcached 와 Redis 계열을 같은 하드웨어에서 1:1 로 측정한 1차 출처가 없고(02), Redis·Valkey 의 수치는 전부 발행 주체가 당사자입니다(Ⓥ). 그래서 §2 의 성능 행은 판정을 “비교 불가” 로 적었고 어느 엔진이 몇 배 빠르다는 서술은 넣지 않았습니다 ?
• Redis 8.2 유지보수 라인에 8.10 의 ACL 우회 수정(#15478)이 백포트됐는지 — 2026-07-23 일괄 패치 웨이브는 8.10.0(2026-07-29)보다 앞서므로 그 웨이브에 포함될 수 없습니다. 앞 문서에 이후 패치의 근거가 없어 §3.4·§4.1 에서 ? 로 남겼습니다
• Vector Set 의 GA 시점 — 릴리스노트에 beta 해제 선언이 없고 redis.io 문서끼리 불일치합니다(04). §3.5 는 “GA 선언 문장이 없다” 까지만 씁니다 ?
• Valkey 9.1 의 security 종료일 — 9.2 GA 후 “최신 minor 지위를 잃으면 5년을 되돌린다” 고 명시한 문장이 확인되지 않았습니다(05). §4.2 는 2031-05-19 를 전제로 쓰지 말라는 형태로만 판정했습니다 ≈
• Valkey 9.x → Redis 방향의 차단 — 앞 문서의 마이그레이션 표에 이 행이 없습니다. VALKEY080 magic 과 foreign 예약 규칙에서 나오는 추론이라 §5 에서 Σ 로 표시했습니다
• 그룹사·계열사 간 유상 제공이 라이선스상 “third parties” 인지 — 원문으로는 판정되지 않습니다(03). §3.3 표에서 ? 로 남겼고 이 케이스는 원문만으로 판정하지 말라는 03의 경고를 그대로 승계합니다
• ElastiCache 의 compatible 상태 API 응답 · enabled 후 구 엔드포인트 삭제 여부 · config endpoint 이름의 동일성 — AWS 1차 문서에 없습니다(07). §5 의 CMD→CME 행은 “재조회 단계를 반드시 넣는다” 로만 처리했습니다 ?
• ElastiCache for Memcached / MemoryDB 의 날짜 박힌 EOL 캘린더, MemoryDB 의 Valkey 8/9 지원 여부 — 확인되지 않았습니다(02·07). §2 의 관리형 지원 행은 “웹 확인 최신” 이라는 한정을 붙였습니다 ?
• AWS 가격 인하율의 현재성 — 2024-10-08 발표문 수치이고 2026-08 현재도 같은지 확인되지 않았습니다(03·07). 그래서 이 문서는 가격을 판정 축에 넣지 않았습니다 ?
• 클라이언트 라이브러리의 cluster 클래스명·최소 버전, valkey-glide 의 언어별 기능 격차 — 검증되지 않았습니다(06). §2 의 클라이언트 생태계 행은 “이 축은 판정에 거의 기여하지 않는다” 로 처리했습니다 ?