Redis vs Valkey vs Memcached 선택 가이드와 마이그레이션 런북

"Redis 쓰면 되지 않나요?"가 더 이상 안전한 대답이 아닌 이유

몇 년 전만 해도 캐시 계층 회의는 5분이면 끝났습니다. "Redis 붙이죠" 한마디로 정리됐으니까요. 그런데 2024년 3월 Redis가 BSD 3-Clause에서 RSALv2/SSPLv1 듀얼 라이선스로 전환하면서 상황이 달라졌습니다. 결과는 코드 저장소 안에서만 끝나지 않았습니다.

• 주요 리눅스 배포판들이 기본 패키지 저장소에서 Redis를 걷어내고 포크 엔진으로 교체하는 방향을 택했습니다(예: Fedora, openSUSE, Debian 계열의 패키지 정책 변경 논의).
• AWS·Google Cloud·Oracle 등이 참여한 커뮤니티 포크 Valkey가 Linux Foundation 산하로 이관됐고, 클라우드 매니지드 서비스에 별도 엔진 옵션으로 편입됐습니다.
• 클라우드 벤더는 포크 엔진을 더 낮은 단가로 밀고 있습니다. 즉, 이제 라이선스는 법무 이슈이자 동시에 요금 이슈입니다.
• 2025년 Redis는 AGPLv3를 라이선스 옵션으로 추가했지만, 이는 "원복"이 아니라 선택지 추가입니다. AGPL 자체가 조직에 따라서는 RSAL보다 더 부담스러운 조항일 수 있습니다.

이 글은 개념 소개가 아닙니다. Redis / Valkey / Memcached 세 후보를 6개 축으로 판정하고, 시나리오별로 단일 후보를 지목하는 의사결정 문서입니다. 비슷한 구조의 판정이 필요하다면 Terraform vs OpenTofu 실무 선택: BSL 이후 뭘 쓰고 언제 옮길까도 같은 프레임으로 읽으시면 됩니다.

30초 판정표: 이럴 땐 이걸

스크롤 없이 결론부터 가져가세요.

판정이 갈리는 3가지 변수

표에서 결론이 뒤집히는 축은 사실 세 개뿐입니다.

1. 값 크기 분포 — 값이 크면 네트워크 대역폭이 먼저 포화돼 엔진 차이가 희석됩니다.
2. 자료구조 의존도 — SETEX/GET만 쓴다면 Memcached가 진지한 후보입니다. ZADD가 한 줄이라도 있으면 후보에서 탈락합니다.
3. 재판매 여부 — 캐시를 고객에게 서비스로 제공하는지가 라이선스 판정의 유일한 결정타입니다.

아래 섹션들이 이 셋을 각각 검증합니다.

라이선스 판정: 내 회사는 실제로 무엇이 문제가 되는가

타임라인

사용 형태별 위험도 판정

회의 전에 꺼내볼 사내 문서 체크리스트

• 고객 계약서의 오픈소스 조항 — "GPL 계열 및 유사 카피레프트 라이선스 사용 금지" 문구가 있는가?
• 소프트웨어 BOM(SBOM) — Redis 버전이 라이선스 전환 이전(7.2 이하)인가 이후인가?
• 컨테이너 이미지 베이스에 포함된 Redis 바이너리 목록 (사이드카·번들 이미지 포함)
• 공공/금융 납품 시 제출한 오픈소스 고지 문서의 라이선스 표기 정합성

⚠️ 이 섹션은 법률 자문이 아닙니다. 라이선스 조항의 최종 해석과 적용은 반드시 사내 법무 또는 외부 자문을 통해 확인하세요. 여기서 드리는 건 "무엇을 물어봐야 하는지"의 목록입니다.

판정 원칙 하나만 기억하세요. "라이선스가 무섭다"는 감정으로 옮기지 마십시오. (a)에 해당하는 조직이 급하게 마이그레이션하다 장애를 내는 게 훨씬 큰 손실입니다. 반대로 (c)·(d)라면 지금 당장 일정을 잡으셔야 합니다.

기능·성능·비용 3면 비교

기능 비교표

Memcached가 확실히 이기는 칸: 운영 단순성(설정 파라미터가 압도적으로 적음), 순수 KV 캐시에서의 메모리 효율, 멀티스레드 기본 동작, 그리고 "장애 시 그냥 버리면 되는" 상태 없는 설계. 세션 스토어가 아니라 DB 쿼리 결과 캐시라면 Memcached는 여전히 옳은 답입니다.

Memcached가 지는 칸: 영속성 없음, 자료구조 없음, 복제 없음, 원자적 카운터 이상의 복합 연산 불가.

벤치마크: 남의 숫자 말고 우리 값으로

벤더 벤치마크는 대부분 작은 값 + 높은 파이프라이닝 조건에서 측정됩니다. 조건이 다르면 결론도 바뀝니다. memtier_benchmark로 직접 재현하세요.

# 1) 기준선: 파이프라이닝 없음, 작은 값(32B) — 지연 시간 중심
memtier_benchmark -s 10.0.1.10 -p 6379 \
  --protocol=redis --clients=50 --threads=4 \
  --data-size=32 --ratio=1:9 --pipeline=1 \
  --test-time=60 --hide-histogram

# 2) 처리량 상한: 파이프라이닝 16 — 엔진의 I/O 스레드 효과가 드러나는 구간
memtier_benchmark -s 10.0.1.10 -p 6379 \
  --clients=50 --threads=8 \
  --data-size=32 --ratio=1:9 --pipeline=16 \
  --test-time=60

# 3) 큰 값 구간: 100KB — 여기서부터는 NIC 대역폭이 먼저 포화된다
memtier_benchmark -s 10.0.1.10 -p 6379 \
  --clients=20 --threads=4 \
  --data-size=102400 --ratio=1:4 --pipeline=1 \
  --test-time=60

결과 해석 가이드

우리 값 크기 분포 뽑는 법 (운영 노드에서는 반드시 복제본 또는 스냅샷 복원 인스턴스에서 실행하세요. --bigkeys/MEMORY USAGE는 부하를 줍니다):

# 큰 키 상위 목록 (샘플링, 부하 낮음)
redis-cli -h <host> --bigkeys

# 랜덤 샘플 200개의 실제 메모리 사용량 히스토그램
for i in $(seq 1 200); do
  k=$(redis-cli -h <host> RANDOMKEY)
  redis-cli -h <host> MEMORY USAGE "$k"
done | sort -n | awk '{a[NR]=$1} END {
  print "p50:", a[int(NR*0.5)];
  print "p90:", a[int(NR*0.9)];
  print "p99:", a[int(NR*0.99)];
}'

p90이 10KB를 넘으면 "멀티스레드 벤치마크 수치"는 우리 상황과 무관합니다.

실비용 계산: 계산식을 그대로 공개합니다

💰 아래 단가는 2026년 8월 조회 기준의 예시값이며, 리전·약정·엔진별로 수시 변동합니다. 반드시 AWS ElastiCache 공식 요금 페이지에서 최신 단가를 재확인한 뒤 아래 계산식에 대입하세요.

계산식은 단순합니다.

월 노드 비용 = 시간당 온디맨드 단가(USD) × 노드 수 × 730시간

서울 리전(ap-northeast-2), cache.r7g.large × 2노드(프라이머리 1 + 복제본 1) 기준 템플릿:

절감률 산출도 회의 자료에 그대로 넣으세요.

절감률(%) = (A - B) / A × 100

예를 들어 Valkey 단가가 Redis OSS 대비 20% 낮게 책정돼 있다면, 2노드 기준 월 절감액은 A × 1,460 × 0.20 입니다. 노드 수가 늘수록 선형으로 커지므로, 샤드 10개 이상 운영 중이라면 라이선스와 무관하게 비용만으로 전환 검토 가치가 생깁니다.

EC2 자체 운영 TCO 개략 비교 (동일 스펙 2노드 가정)

공수 시간에 팀의 시간당 인건비를 곱해 넣으면, 인스턴스 단가 차이가 뒤집히는 지점이 대부분 보입니다. 페일오버를 직접 구성한다면 Redis Sentinel — 고가용성과 자동 페일오버 구성의 절차를 그대로 Valkey에도 적용할 수 있습니다(설정 문법 호환).

마이그레이션 런북: Redis 7.2 → Valkey 8 무중단 전환

Valkey는 Redis 7.2.4 코드 기반이라 프로토콜·명령어 호환성이 매우 높습니다. 하지만 "높다"는 게 "전부"는 아닙니다.

0단계: 사전 인벤토리 (전환 가능 여부 판정)

# 서버 정보 및 모듈 목록
redis-cli -h <host> INFO server
redis-cli -h <host> MODULE LIST

# 지원 명령어 수 (전후 비교용)
redis-cli -h <host> COMMAND COUNT

# 실제로 어떤 명령을 쓰고 있는지 (짧게, 부하 주의)
redis-cli -h <host> --stat
timeout 30 redis-cli -h <host> MONITOR | awk '{print $4}' | sort | uniq -c | sort -rn | head -30

예상 정상 결과: MODULE LIST가 빈 배열((empty array))이면 전환 진행 가능.

분기: search, json, timeseries, bloom 등 Redis Stack 모듈이 나오면 단순 전환 불가입니다. 이때 선택지는 ① Redis 유지(라이선스 조항 재검토) ② 해당 기능을 OpenSearch/PostgreSQL 등으로 분리 ③ Valkey 진영의 대응 모듈 검증 후 이관 — 세 가지입니다. ③은 검증 공수를 반드시 별도 산정하세요.

절차

1. Valkey 8 신규 노드 기동 (기존 Redis와 동일 서브넷, 동일 스펙 이상)
   Bash복사

   valkey-server /etc/valkey/valkey.conf --port 6379 --daemonize yes

2. 기존 Redis를 마스터로 복제 연결
   Bash복사

   valkey-cli -h <valkey-host> REPLICAOF <redis-host> 6379
   # 인증이 있다면
   valkey-cli -h <valkey-host> CONFIG SET masterauth "<password>"

3. 복제 상태 확인 — 이 값이 정상이어야 다음 단계로 갑니다.
   Bash복사

   valkey-cli -h <valkey-host> INFO replication

   예상 정상 결과: master_link_status:up, master_sync_in_progress:0, 그리고 마스터 쪽 INFO replication의 lag:0. 분기: master_link_status:down이 지속되면 보안그룹/bind/protected-mode/requirepass를 먼저 확인하세요. master_sync_in_progress:1이 오래 유지되면 RDB 전송 중이므로 데이터셋 크기만큼 기다립니다.
4. 읽기 트래픽 일부를 Valkey로 선반영 (선택) — 카나리 5~10%로 지연·에러율 관찰.
5. 클라이언트 엔드포인트 전환 — DNS CNAME 또는 설정 스위치. TTL을 사전에 30초 이하로 낮춰두세요.
6. 승격
   Bash복사

   valkey-cli -h <valkey-host> REPLICAOF NO ONE

7. 관찰 구간(최소 24시간) — 아래 롤백 임계값을 대시보드에 걸어둡니다.
8. 구 Redis 정리 — 최소 7일은 스냅샷과 함께 정지 상태로 보존(3-2-1 백업 원칙 유지).

클라이언트 라이브러리 확인 포인트

공통 확인 명령:

valkey-cli -h <valkey-host> INFO server | grep -E "redis_version|valkey_version|server_name"

일부 클라이언트는 redis_version 필드 존재를 전제로 동작합니다. Valkey는 호환을 위해 해당 필드를 유지하지만, 자체 구현한 헬스체크·모니터링 스크립트가 문자열을 하드코딩했는지 반드시 grep하세요.

롤백 조건 (정량 임계값)

다음 중 하나라도 5분 이상 지속되면 즉시 5단계 엔드포인트를 원복합니다.

원복 절차: DNS를 구 Redis로 되돌리고 → Valkey는 REPLICAOF로 다시 복제본 복귀 → 승격 이후였다면 양쪽 쓰기 발생 여부를 먼저 확인(양방향 쓰기가 있었다면 캐시 무효화 후 재적재가 안전).

ElastiCache 사용 시 제약

ElastiCache는 클러스터의 엔진 자체를 인플레이스로 임의 변경할 수 없는 경우가 있습니다(콘솔의 업그레이드 경로 제공 여부는 엔진·버전 조합에 따라 다르므로 반드시 콘솔/공식 문서에서 확인). 경로가 없다면 우회 절차는 다음과 같습니다.

1. 기존 클러스터에서 수동 스냅샷 생성
2. 해당 스냅샷으로 Valkey 엔진의 신규 클러스터 생성(Seed RDB 복원)
3. 스냅샷 시점 이후 델타는 애플리케이션 레벨 워밍 또는 원본 대상 REPLICAOF(자체 관리형 노드 경유)로 보정
4. 엔드포인트 전환 → 관찰 → 구 클러스터 삭제

델타 보정이 어려운 순수 캐시라면 TTL 만료를 이용해 자연 워밍시키는 편이 더 단순합니다. 단, 전환 직후 원본 DB에 쿼리가 몰리므로 **캐시 스탬피드 방어(요청 병합 또는 지터 TTL)**를 사전에 넣으세요.

결론: 3개 시나리오별 최종 추천

① 스타트업 단일 인스턴스 (트래픽 낮음, 인프라 인력 1~2명)

결론: Valkey (매니지드, 단일 샤드 + 복제본 1)

이유는 간단합니다. 기능은 Redis와 동일하고, 매니지드 단가는 더 낮으며, 라이선스는 앞으로 고민할 일이 없습니다. 지금 Redis를 쓰고 있어도 급히 옮길 필요는 없지만, 신규 클러스터를 만들 때는 Valkey로 만드세요.

• 지금 당장 할 일 1가지: 다음에 생성하는 캐시 클러스터의 엔진 기본값을 Valkey로 바꾸고, IaC 템플릿(Terraform 모듈 등)의 engine 값을 함께 수정.

② 트래픽 큰 SaaS (멀티테넌트, 재판매 요소 있음)

결론: Valkey (전면 전환)

멀티테넌트 SaaS는 라이선스 판정표의 (b)~(c) 경계에 걸칩니다. 여기에 샤드 수가 많아 절감액이 유의미합니다. 법무 해석을 기다리는 동안 노드는 계속 늘어납니다.

• 전환 우선순위: ① 모듈 미사용 + 순수 캐시 클러스터(가장 안전) → ② 세션 스토어 → ③ Rate limiter / 분산 락 → ④ 모듈 의존 클러스터(별도 과제로 분리)
• Redis Stack 모듈에 묶인 기능은 전환 대상에서 빼고 기능 자체를 다른 저장소로 옮기는 과제로 재정의하세요.

③ 규제 산업 온프레미스 (폐쇄망, 벤더 감사 대응)

결론: Valkey (또는 순수 KV라면 Memcached)

번들 배포와 오픈소스 고지 의무가 걸리는 영역이라, BSD 3-Clause라는 단순명료함이 곧 감사 대응 비용 절감입니다.

• 라이선스 증빙 준비물: ① 사용 버전의 LICENSE 파일 사본 ② SBOM(CycloneDX/SPDX) 갱신본 ③ 오픈소스 고지 문서(NOTICE) ④ 패키지 출처(공식 릴리스 URL/체크섬) 기록

우리 팀 판정 체크리스트 (복사해서 쓰세요)

[ ] 1. 우리는 캐시를 고객에게 "서비스로" 제공하거나 제품에 번들 배포하는가? (Yes → Valkey 필수)
[ ] 2. Sorted Set / Stream / Bitmap 중 하나라도 쓰는가? (No → Memcached 후보 진입)
[ ] 3. Redis Stack 모듈(Search/JSON/TimeSeries)에 의존하는가? (Yes → 단순 전환 불가, 별도 과제)
[ ] 4. 값 크기 p90이 10KB를 넘는가? (Yes → 멀티스레드 성능 마케팅은 무시)
[ ] 5. 캐시 노드가 10개를 넘는가? (Yes → 라이선스와 무관하게 비용만으로 전환 검토)

결정 회의 전에 반드시 뽑아둘 데이터 3가지

1. 값 크기 분포 — 위 MEMORY USAGE 샘플링 스크립트의 p50/p90/p99
2. 사용 중인 명령어 목록 — MONITOR 30초 샘플의 상위 30개 + MODULE LIST 결과
3. 현재 월 캐시 요금 — Cost Explorer에서 ElastiCache 태그 기준 최근 3개월 실비

이 세 가지가 없으면 회의는 "그래도 Redis가 안정적이지 않나요"로 끝납니다. 숫자가 있으면 30분 안에 결론이 납니다.

자주 묻는 질문 (FAQ)

Q. Valkey는 Redis와 100% 호환되나요? A. Valkey는 Redis 7.2.4 코드에서 분기했기 때문에 명령어·프로토콜·설정 파일·복제 프로토콜 수준에서 호환성이 매우 높습니다. 다만 ① Redis Stack 모듈(Search/JSON/TimeSeries 등) ② Redis 8 이후 추가된 신규 기능 ③ 서버 버전 문자열을 하드코딩한 자체 스크립트 — 이 세 가지는 별도 검증이 필요합니다. 두 프로젝트가 독립적으로 발전 중이므로 시간이 지날수록 차이는 벌어집니다.

Q. 지금 사내에서만 Redis를 캐시로 쓰고 있는데, 급히 Valkey로 옮겨야 하나요? A. 대부분의 경우 급하지 않습니다. 사내 인프라 내부 사용은 라이선스 판정표의 (a)에 해당해 실무상 문제가 되지 않는 형태입니다. 다만 신규 클러스터는 Valkey로 만들고, 매니지드 요금 차이가 유의미해지는 시점(노드 수 증가)에 전환을 검토하는 순서가 합리적입니다. 최종 판단은 고객 계약서의 오픈소스 조항을 법무와 함께 확인한 뒤 내리세요.

Q. 세션 스토어에 Memcached를 써도 되나요? A. 권장하지 않습니다. Memcached는 영속성과 복제를 지원하지 않아 노드 재시작 시 데이터가 전량 소실되고, 그러면 전체 사용자가 로그아웃됩니다. 세션처럼 유실 시 사용자 경험이 즉시 깨지는 데이터는 복제와 영속성을 갖춘 Valkey/Redis가 맞습니다. Memcached는 "다시 계산하면 되는" DB 쿼리 결과 캐시에 최적입니다.