레디스 7.4 라이선스 변경 뒤 7.2.4에 멈춰 있던 팀이 발키로 복제 이전을 끝낸 케이스다. BSD와 알살, 에스에스플, AGPL, 7.4 덤프 비호환, 정보 명령의 서버 이름을 오픈소스, 캐시, 백엔드, API, AWS, 도커, 클라우드, 개발자, 데이터 기준으로 나눈다. 스탬피드 장애 글과 각을 섞지 않고 라이선스와 패치 창만 본다.
2024년 3월 20일 레디스가 7.4부터 BSD를 끊었습니다. 세션과 캐시, 요청 제한을 레디스 7.2.4에 두고 있던 팀은 그날 법무 메일부터 받았습니다. 앱이 관리형 상품과 경쟁하는 자리는 아니었지만, 국내 법인 스택을 오픈소스 허용 목록에 맞춰 두는 조항이 있었습니다. 7.2에 멈춰 두면 라이선스는 그대로인데, 보안 패치와 이미지 태그는 점점 끊깁니다. 그 팀은 키디비와 드래곤플라이를 보고, 레디스 8 삼중 라이선스를 검토한 뒤 발키로 복제 이전을 끝냈습니다.
캐시가 한꺼번에 만료되며 디비를 때리는 장애는 스탬피드 72시간에 있습니다. 재고 락은 분산 락 글을, 같은 라이선스 포크는 오픈토푸를 보면 자리가 겹치지 않습니다. 기업명과 일부 수치는 익명입니다. 숫자는 2026년 8월 공개 문서 기준.
법무 메일이 온 날부터 7.2에 멈춘 18개월
라이선스가 먼저 막혔고, 장애는 나중에 왔습니다. 2024년 3월 20일 레디스(Redis)는 7.4부터 소스 이용 가능 이중 라이선스, 알살(RSALv2)과 에스에스플(SSPLv1)로 바꾼다고 적었습니다. 그 전 줄인 7.2.4까지는 BSD 3조항이 그대로입니다. 여드레 뒤인 3월 28일 리눅스 재단은 레디스 7.2.4에서 갈라 낸 발키(Valkey)를 BSD 3조항으로 둔다고 발표했습니다.
날짜
사건
팀이 한 일
2024-03-20
레디스 7.4부터 알살·에스에스플
이미지 태그를 7.2.4로 고정, 업그레이드 이슈 동결
2024-03-28
리눅스 재단 발키 출범, BSD 유지
워치 목록에만 추가. 프로덕션은 손대지 않음
2024 하반기
자체 호스팅 7.2.4 유지
세션, 페이지 캐시, 요청 제한, 발행-구독 네 칸
2025
레디스 8 삼중 라이선스에 AGPLv3 추가
법무가 카피레프트 검토를 다시 염. 결정은 보류
2026-02-28
레디스 소프트웨어 7.2 지원 종료
자체 7.2.4도 같은 줄로 보이기 시작. 이전 일정 확정
2026-07-21
발키 9.1.1, 8.1.9, 7.2.14 동시 패치
프로덕션은 발키 8 줄, 스테이징은 9.1.1
공식 안내는 레디스 이중 라이선스 발표와 리눅스 재단 발키 출범에 날짜가 있습니다. 레디스 쪽 비교문은 오픈소스 7.2.4가 마지막 BSD 줄이라고 적고, 소프트웨어 7.2 지원 종료는 2026년 2월 28일로 따로 적습니다. 자체 바이너리와 상용 제품은 다른 줄입니다. 다만 보안 담당은 “7.2라는 숫자만 남은 이미지”를 같은 위험으로 읽었습니다.
그 팀이 쓰던 칸 | 노드 프로세스 뒤의 세션 저장, 목록 페이지 캐시, 아이피당 요청 제한, 알림용 발행-구독. 벡터 검색이나 시계열은 없었습니다. 프로토콜만 맞으면 클라이언트 라이브러리를 갈 이유가 없었습니다.
7.2 동결이 안전해 보이던 이유
동결은 법무가 가장 빨리 승인한 선택입니다. 이미 받은 7.2.4는 BSD가 유지됩니다. 알살과 에스에스플은 7.4부터입니다. 앱은 레디스와 경쟁하는 관리형 상품이 아니어서, 레디스 쪽 안내만 보면 당장 소송을 걱정할 자리는 아니었습니다. 그래도 국내 허용 목록에 “오픈소스여야 한다”가 있으면 7.4 이미지는 올릴 수 없었습니다.
18개월은 조용했습니다. 캐시 적중은 평소 88~92%였고, 세션 만료와 요청 제한도 기존 키 규칙 그대로였습니다. 문제는 조용함 자체였습니다. 베이스 이미지 스캔에 7.2 줄의 미패치 항목이 쌓이기 시작했습니다. 담당자가 바뀌면 “왜 레디스만 버전이 멈췄나”를 다시 설명해야 했습니다. 컨테이너 레지스트리의 최신 태그를 습관적으로 당기는 잡이 한 번 스테이징을 7.4로 올렸고, 그날 배포는 되돌렸습니다.
캐시 장애 글에서 본 스탬피드와는 다른 종류의 빚입니다. 트래픽이 아니라 라이선스와 패치 창이 쌓입니다. 요청 제한을 레디스로 걸고 있다면 레이트 리밋 설계의 키 규칙도 이미지 태그와 같이 적어야 합니다. 태그 없이 “레디스 최신”만 적힌 차트는 다음 배포에서 라이선스가 바뀝니다.
세션·캐시·요청 제한을 한 인스턴스에 둔 자리. 라이선스가 바뀌면 네 칸이 같이 멈춘다
키디비와 드래곤플라이, 레디스 8을 같은 표에 올린 이유
동결을 끝내기로 한 뒤, 후보는 넷이었습니다. 레디스 8, 발키, 키디비, 드래곤플라이. 벤치 숫자로 고르지 않았습니다. 법무 한 장과 클라이언트 호환, 스냅샷 이전이 먼저였습니다.
후보
라이선스
7.2 스냅샷
그 팀이 본 걸림
레디스 8
알살, 에스에스플, AGPLv3 중 하나
같은 제품 줄. 다만 7.4 이후 스냅샷은 발키와 호환되지 않음
허용 목록에 AGPL 네트워크 조항 검토가 남음
발키
BSD 3조항, 리눅스 재단
오픈소스 2.x~7.2.x 스냅샷을 읽는다고 공식 이전 문서가 적음
시계열·하이브리드 검색은 레디스 8 쪽이 넓음
키디비
포크 계열
명령은 닮았으나 메인 줄 속도가 불확실
장기 패치 창을 법무에 설명하기 어려움
드래곤플라이
자체 엔진
호환 범위가 제품 문서에 따로 있음
발행-구독과 스크립트 칸을 다시 검증해야 함
레디스 공식 비교는 8줄이 제이슨, 시계열, 확률 구조, 벡터 집합을 코어에 넣는다고 적습니다. 발키 9는 클러스터 논리 디비, 슬롯 이전, 공식 모듈 묶음으로 갈라집니다. 그 팀 워크로드는 문자열·해시·정렬 집합·스트림·발행-구독이 전부였습니다. 빠진 자료형이 없어서 발키가 탈락하지 않았습니다. 테라폼이 비에스엘로 바뀐 뒤 오픈토푸를 고른 자리와 같습니다. 언어를 바꾸는 비교가 아니라, 같은 프로토콜을 오픈소스로 고정하는 비교입니다.
발키를 고른 세 가지 조건
고른 이유는 로고가 아닙니다. 허용 목록에 BSD가 이미 있었고, 기존 클라이언트 라이브러리를 갈 필요가 없었으며, 공식 이전 문서가 7.2 스냅샷과 복제를 구체적으로 적었습니다. 아마존 엘라스티캐시와 구글 메모리스토어가 발키 엔진을 따로 열고 있어, 나중에 관리형으로 옮길 때도 같은 이름을 유지할 수 있었습니다.
발키 사이트는 자신을 BSD 인메모리 저장소라고 적습니다. 캐시, 메시지 큐, 주 저장소로 쓸 수 있다고 적습니다. 2026년 7월 21일 기준으로 9.1.1, 8.1.9, 7.2.14가 같이 나왔습니다. 7.2 줄만 패치하고 싶으면 발키 7.2.14가 그 자리입니다. 그 팀은 기능을 늘리기보다 패치 창을 되살리는 게 목적이라, 프로덕션은 8줄, 스테이징은 9줄을 골랐습니다.
레디스 쪽 비교문은 거버넌스가 한 회사인지 재단인지를 갈라 적습니다. 발키는 재단 아래 여러 회사가 참여한다고 적혀 있습니다. 출범 당시 아마존, 구글 클라우드, 오라클, 에릭슨, 스냅이 이름을 올렸습니다. 법무는 “한 회사가 라이선스를 다시 바꿀 수 있는가”를 질문지에 넣었고, 재단 거버넌스가 그 칸을 채웠습니다. 이 판단이 법률 자문을 대신하지는 않습니다.
발키는 레디스 7.2.4에서 갈라 리눅스 재단에 둔 BSD 줄이다
복제 이전은 어느 명령부터인가
공식 이전 문서는 세 갈래입니다. 스냅샷 파일을 복사해 띄우기, 복제로 따라가게 한 뒤 승격, 특정 키만 옮기기. 쓰기 트래픽이 있는 프로덕션은 복제 갈래가 맞았습니다. 스냅샷 복사는 연결을 끊고 저장한 뒤에만 안전하다고 문서가 적습니다. 그 팀은 스테이징에서 스냅샷을 한 번 검증하고, 프로덕션은 복제로 잘랐습니다.
순서는 문서와 같습니다. 키 개수를 먼저 적습니다. 발키를 레디스의 복제로 붙입니다. 복제 링크가 올라온 뒤에 앱 연결을 발키로 돌립니다. 레디스를 끄고, 발키에서 복제를 뗍니다. 클러스터면 발키 노드를 복제로 넣은 뒤 페일오버로 승격하고 옛 노드를 뺍니다.
스테이징에서 키 개수와 복제 링크를 확인
redis-cli -h 127.0.0.1 -p 6379 INFO KEYSPACE
valkey-cli -h 127.0.0.1 -p 6380 REPLICAOF 127.0.0.1 6379
valkey-cli -h 127.0.0.1 -p 6380 INFO REPLICATION
# master_link_status:up 을 확인한 뒤 앱 엔드포인트를 발키로 돌린다
valkey-cli -h 127.0.0.1 -p 6380 REPLICAOF NO ONE
valkey-cli -h 127.0.0.1 -p 6380 INFO KEYSPACE
클라이언트는 그대로였습니다. 노드용 아이오레디스, 파이썬 레디스 패키지 모두 포트만 바꿨습니다. 문서는 레스프2와 레스프3를 발키가 받는다고 적습니다. 정보 명령은 호환을 위해 레디스 버전 칸에 7.2.4를 남긴다고 적혀 있습니다. 실제 엔진을 보려면 서버 이름과 발키 버전 칸을 봐야 합니다. 모니터링 대시보드가 레디스 버전만 긁고 있으면, 이전 후에도 “아직 7.2”로 보입니다. 그 팀이 반나절을 쓴 자리입니다.
도커로 먼저 띄울 때는 공식 태그를 씁니다. 2026년 7월 21일 화면 기준 예시는 valkey/valkey:9.1.1입니다. 컴포즈로 충분한 서비스를 클러스터로 옮기는 문제는 컴포즈와 쿠버네티스에 맡깁니다. 여기서 고르는 것은 엔진 이름과 스냅샷 호환입니다.
공식 이미지로 발키 한 번 띄우기
docker run --rm -p 6379:6379 valkey/valkey:9.1.1
7.4 스냅샷을 가져오면 깨지는 자리
공식 이전 표가 한 줄을 굵게 긋습니다. 오픈소스 2.x부터 7.2.x는 발키 7.2 이후로 올리면 됩니다. 커뮤니티 에디션 7.4 이후가 만든 데이터 파일은 발키가 읽지 않습니다. 스테이징이 한 번 7.4로 올라간 뒤 남긴 덤프를 발키에 넣으면 기동이 거절됩니다. 그 팀은 그 덤프를 버리고, 동결해 둔 7.2.4에서 다시 떴습니다.
설정 파일은 레디스 7.2 지시어를 받는다고 문서가 적습니다. 모듈은 레디스 모듈 에이피아이로 만든 것이 동작한다고 적혀 있습니다. 다만 레디스 8 코어에 들어간 시계열, 쿠쿠 필터, 하이브리드 검색 명령은 발키에 없습니다. 그 명령을 쓰는 잡이 하나라도 있으면 이전 전에 목록을 뽑아야 합니다. COMMAND와 슬로우로그, 앱 저장소의 레디스 호출을 같이 검색했습니다.
외부 의존성이 느려질 때 재시도가 전체를 묶는 구조는 회로 차단기 케이스와 닮았습니다. 캐시 엔진을 바꾸는 주말에도 폴백 페이지와 짧은 타임아웃을 먼저 켭니다. 이전 창에 원 디비로 떨어지는 읽기가 있으면, 스탬피드 글의 락과 스테일 캐시가 같이 필요합니다.
한 줄 가드 | 7.4 이후 덤프로 발키를 시드하지 않습니다. 7.2.4에서 복제를 붙이거나, 그 버전이 만든 스냅샷만 복사합니다. 정보 명령의 레디스 버전 칸만 보고 엔진을 단정하지 않습니다.
스냅샷 복사와 복제 승격. 7.4 이후 덤프는 발키 시드에 쓰지 않는다
레디스 8이 다시 열린 뒤에도 발키를 둔 이유
레디스 8은 삼중 라이선스에 AGPLv3를 넣었습니다. 오픈소스 정의로 다시 들어왔다는 설명이 레디스 라이선스 페이지에 있습니다. 수정하지 않고 백엔드로만 쓰면 네트워크 조항이 바로 열리지 않는다는 해석이 흔합니다. 그 팀 법무는 그 해석을 메모로 남기되, 허용 목록의 기본값을 허용적 라이선스로 유지했습니다. AGPL은 예외 승인입니다. 모듈을 고치거나 내부 포크로 서비스를 열 계획이 없더라도, 예외 승인은 분기마다 다시 받습니다.
그래서 발키를 되돌리지 않았습니다. 이미 복제 이전이 끝났고, 클라이언트와 키 규칙이 안정이었습니다. 레디스 8의 시계열과 하이브리드 검색이 로드맵에 생기면 그때 엔진을 나눕니다. 캐시 칸은 발키, 검색 칸은 다른 제품. 한 인스턴스에 모든 자료형을 넣는 전제는 버렸습니다.
관리형으로 갈 때는 엔진 이름을 콘솔에서 다시 봅니다. 엘라스티캐시는 발키와 레디스 오픈소스를 나누고, 버전 업그레이드 문서에 레디스 오픈소스에서 발키로 건너가는 안내가 있습니다. 메모리스토어도 발키를 따로 엽니다. 테라폼 모듈의 엔진 파라미터가 옛 이름이면, 차트만 바꿔서는 엔진이 바뀌지 않습니다. 이전 후 일주일은 정보 명령의 서버 이름, 키 개수, 복제 오프셋, 캐시 적중을 같은 대시보드에 붙였습니다.
결과만 적습니다. 앱 코드 변경은 연결 문자열과 헬스 체크 두 줄이었습니다. 주말 컷오버는 스테이징 한 번, 프로덕션 한 번이었습니다. 키 개수는 컷 전후가 같았습니다. 세션 만료와 요청 제한 오차는 관측 오차 안이었습니다. 벤치로 몇 퍼센트가 빨라졌는지는 이 팀이 주장하지 않았습니다. 목적은 허용 목록과 패치 창이었습니다.
라이선스와 호환 범위는 수시로 바뀝니다. 위 표는 2026년 8월 공개 페이지 기준 점검용이며, 계약과 적용의 최종 근거는 공식 화면과 법률 검토입니다.
자주 묻는 질문
레디스 7.2.4를 그대로 두면 안 되나?
라이선스만 보면 7.2.4는 BSD가 유지됩니다. 다만 레디스 오픈소스의 마지막 BSD 줄이고, 상용 소프트웨어 7.2는 2026년 2월 28일에 지원이 끝났습니다. 이미지 스캔과 패치 창이 막히면 동결 비용이 커집니다. 같은 7.2 줄을 이어가려면 발키 7.2.14처럼 재단이 패치하는 바이너리를 봅니다.
클라이언트 라이브러리를 바꿔야 하나?
공식 이전 문서는 기존 레디스 클라이언트가 그대로 붙는다고 적습니다. 그 팀도 포트와 헬스 체크만 바꿨습니다. 정보 명령이 레디스 버전 칸에 7.2.4를 남기므로, 모니터링은 서버 이름과 발키 버전 칸을 같이 봐야 합니다.
레디스 7.4 덤프를 발키에 넣으면?
읽지 않습니다. 공식 표가 커뮤니티 에디션 7.4 이후 데이터 파일은 호환되지 않는다고 적습니다. 7.2.x에서 만든 스냅샷이나, 7.2.x를 원본으로 한 복제만 씁니다. 7.4로 한 번 올라간 스테이징 덤프는 버립니다.
레디스 8 AGPL이면 다시 레디스로 가나?
백엔드로만 쓰고 수정본을 네트워크 서비스로 열지 않으면 조항이 바로 열리지 않는다는 해석이 있습니다. 허용 목록이 허용적 라이선스를 기본값으로 두면 AGPL은 예외입니다. 시계열이나 하이브리드 검색이 필요할 때 엔진을 나누는 편이 그 팀에는 맞았습니다.
엘라스티캐시에서 엔진만 바꾸면 되나?
콘솔과 업그레이드 문서에 레디스 오픈소스에서 발키로 건너가는 안내가 있습니다. 엔진 이름, 버전, 파라미터 그룹을 같이 봅니다. 테라폼 모듈이 옛 엔진 값을 들고 있으면 차트만 바꿔서는 엔진이 바뀌지 않습니다. 이전 후 정보 명령으로 서버 이름을 확인합니다.
키디비나 드래곤플라이가 더 빠르지 않나?
처리량만 보면 다른 엔진이 앞설 수 있습니다. 그 팀은 벤치보다 스냅샷 호환과 패치 창, 허용 목록을 먼저 봤습니다. 발행-구독과 스크립트를 쓰는 칸이 있으면 호환 표를 다시 검증해야 합니다. 속도가 목표면 별도 벤치 케이스가 됩니다.