2024년 8월 9일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/2a3741f8-626e-4237-b985-d52de10bb444_thumbnail_1.png)

## Database — Redis 7.4 + 라이선스 변화

Redis가 **7월 29일 Redis 7.4 Community Edition**을 GA로 공개했습니다.

Redis 7.4에는 **Hash Field Expiration** 같은 새로운 데이터 관리 기능이 추가됐고, Redis Stack에서 제공하던 Search, JSON, Vector Search 등도 Community Edition에 통합되면서 Redis의 역할이 더욱 넓어졌습니다.

하지만 기술적인 변화만큼 중요한 부분이 하나 더 있었습니다.

Redis 7.4는 **RSALv2와 SSPLv1 Dual License가 적용된 첫 번째 Redis Community Edition 정식 버전**이었습니다.

---

### Redis는 더 이상 단순한 Cache가 아니다

Redis는 오랫동안 대표적인 In-Memory Key-Value Store로 사용돼 왔습니다.

```text
Application
    ↓
Redis
    ↓
Key-Value Cache
```

대표적인 활용 사례도 비교적 명확했습니다.

- API Response Cache
- Session Storage
- Rate Limiting
- Distributed Lock
- Queue
- Pub/Sub

하지만 Redis의 기능은 점점 단순한 Key-Value Cache를 넘어 확장되고 있었습니다.

```text
Redis

├─ Cache
├─ Search
├─ Vector Search
├─ JSON
├─ Time Series
└─ Streams
```

즉 Redis가 단순히 DB 앞단에 위치하는 Cache가 아니라 **실시간 데이터 처리를 위한 범용 Data Platform에 가까운 방향으로 확장**되고 있었습니다.

---

### Hash Field Expiration

Redis 7.4에서 눈에 띄는 기능 중 하나는 **Hash Field Expiration**입니다.

기존 Redis에서는 일반적으로 Key 단위로 TTL을 설정했습니다.

```text
user:100
├─ name
├─ email
└─ verificationCode

TTL → 전체 Key
```

Key가 만료되면 내부의 모든 Field도 함께 사라지는 구조였습니다.

Redis 7.4에서는 Hash 내부의 특정 Field에 개별적으로 Expiration을 설정할 수 있게 됐습니다.

```text
user:100
├─ name
├─ email
└─ verificationCode → TTL
```

이를 통해 Hash 전체를 삭제하지 않고 특정 데이터만 일정 시간이 지난 후 만료시키는 방식이 가능해졌습니다.

예를 들어 다음과 같은 데이터에서 활용할 수 있습니다.

- 인증 코드
- 임시 Token
- 사용자별 임시 상태
- 일정 시간이 지나면 사라져야 하는 Metadata
- Session 내부의 일부 상태

Redis의 데이터 모델을 조금 더 세밀하게 제어할 수 있게 된 것입니다.

---

### Vector Search의 중요성

생성형 AI와 RAG가 확산되면서 Redis에서도 Vector Search가 중요한 기능으로 자리 잡기 시작했습니다.

```text
Document
   ↓
Embedding Model
   ↓
Vector
   ↓
Redis
   ↓
Similarity Search
```

기존 Redis가 단순한 Key 기반 데이터 조회에 강했다면 Vector Search를 활용하면 의미적으로 비슷한 데이터를 검색할 수 있습니다.

예를 들어 다음과 같은 구조입니다.

```text
User Question
      ↓
Embedding
      ↓
Vector Search
      ↓
Relevant Documents
      ↓
LLM
      ↓
Answer
```

Redis를 이미 Cache나 Session Store로 운영하고 있는 서비스라면 별도의 Vector Database를 추가하지 않고 Redis 기반으로 간단한 RAG Architecture를 구성하는 선택지도 생기게 됩니다.

---

### Redis Stack 기능의 통합

Redis 7.4 시기의 또 다른 중요한 변화는 기존 Redis Stack에서 제공되던 기능들이 Redis Community Edition으로 통합되기 시작했다는 점입니다.

Redis의 역할이 다음과 같이 확장되는 흐름입니다.

```text
기존 Redis

Key-Value
    +
Cache


확장된 Redis

Key-Value
+
Cache
+
JSON
+
Search
+
Vector Search
+
Time Series
```

Redis가 단순한 Cache Layer가 아니라 애플리케이션의 다양한 실시간 데이터 처리를 담당할 수 있는 플랫폼으로 발전하고 있었던 것입니다.

---

### 라이선스 변화

Redis 7.4를 이야기할 때 기술 기능만큼 중요한 것이 **라이선스 변화**입니다.

Redis는 기존에 BSD 3-Clause License 기반으로 배포됐지만, 2024년 Redis는 Community Edition에 다음 두 라이선스를 적용하는 방식으로 변경했습니다.

```text
Redis Community Edition

├─ RSALv2
│  Redis Source Available License 2.0
│
└─ SSPLv1
   Server Side Public License 1.0
```

Redis 7.4는 이러한 **RSALv2 + SSPLv1 Dual License 체계가 적용된 첫 Community Edition 정식 릴리스**였습니다.

즉 Redis를 사용하는 입장에서는 단순히 기술적인 기능뿐 아니라 **어떤 방식으로 Redis를 사용하고 서비스하는지에 따라 라이선스 조건까지 확인해야 하는 상황**이 됐습니다.

---

### 왜 라이선스를 변경했을까

Redis를 직접 사용하는 일반적인 애플리케이션과 Redis 자체를 기반으로 Managed Service를 제공하는 사업자는 상황이 다릅니다.

```text
일반 서비스

Application
    ↓
Redis

vs

Cloud Provider

Redis
    ↓
Managed Redis Service
    ↓
Customer
```

Redis 측에서는 대형 Cloud Provider가 Redis를 Managed Database 상품으로 제공하면서 Redis 프로젝트 자체에는 충분한 경제적 기여가 돌아오지 않는 문제를 지속적으로 제기해 왔습니다.

라이선스 변화는 이러한 Cloud Provider의 Redis 상용 서비스 제공 방식에 제한을 두려는 성격이 강했습니다.

---

### Valkey의 등장

Redis의 라이선스 변경은 Redis 생태계 전체에도 큰 영향을 줬습니다.

Redis 라이선스 변경 이후 기존 Redis 프로젝트를 기반으로 한 **Valkey**가 등장했습니다.

```text
Redis
  │
  │ License Change
  ↓
Redis Community Edition
RSALv2 / SSPLv1


Redis Fork
  ↓
Valkey
  ↓
Open Source
```

Valkey는 Linux Foundation 산하에서 개발되는 Redis 호환 Key-Value Store입니다.

기존 Redis의 API와 Protocol을 최대한 유지하면서 Open Source 생태계를 이어가는 방향으로 개발되기 시작했습니다.

---

### 왜 중요한가

Database나 Infrastructure 기술을 선택할 때 개발자는 일반적으로 다음 요소를 먼저 봅니다.

```text
Performance
Scalability
Features
Stability
```

하지만 Redis의 라이선스 변화는 여기에 또 하나의 요소가 필요하다는 것을 보여줬습니다.

```text
Technology Selection

├─ Performance
├─ Features
├─ Scalability
├─ Stability
├─ License
└─ Vendor Dependency
```

특히 Infrastructure에 깊게 들어가는 기술일수록 나중에 다른 제품으로 교체하는 비용이 커질 수 있습니다.

---

### Vendor Dependency

Redis는 애플리케이션 Architecture 깊숙한 곳에서 사용되는 경우가 많습니다.

```text
Application
   ↓
Redis

├─ Cache
├─ Session
├─ Rate Limit
├─ Queue
├─ Lock
└─ Pub/Sub
```

처음에는 단순한 Cache로 도입했더라도 시간이 지나면서 여러 기능이 Redis에 의존하게 될 수 있습니다.

이 상태에서 라이선스나 제품 정책이 변경되면 Migration 비용이 커질 수 있습니다.

```text
Redis Dependency 증가
        ↓
Architecture 결합도 증가
        ↓
Migration Cost 증가
```

따라서 Redis 같은 Infrastructure를 선택할 때는 현재 기능만 보는 것이 아니라 **프로젝트의 방향성과 라이선스 정책까지 장기적으로 검토할 필요가 있습니다.**

---

### Backend 관점에서의 변화

Backend 개발자 입장에서 Redis는 이미 매우 다양한 역할을 담당하고 있습니다.

```text
Backend
   ↓
Redis

├─ Cache
├─ Session
├─ Distributed Lock
├─ Rate Limiting
├─ Pub/Sub
├─ Streams
├─ Search
└─ Vector Search
```

Redis의 기능이 확장될수록 별도의 Infrastructure를 추가하지 않고 Redis 하나로 처리할 수 있는 영역도 많아집니다.

하지만 반대로 Redis에 너무 많은 역할을 집중시키면 시스템 전체가 Redis에 강하게 결합될 수도 있습니다.

따라서 Architecture를 설계할 때는 다음과 같은 판단이 필요합니다.

- Redis가 정말 필요한가
- 단순 Cache 용도인가
- Primary Database 역할까지 맡길 것인가
- Vector Search까지 Redis에서 처리할 것인가
- Redis 장애 시 영향 범위는 어디까지인가
- 대체 기술로 Migration할 수 있는 구조인가
- 라이선스 변화가 서비스에 영향을 주는가

---

### 실무 영향

Redis 7.4의 변화는 Redis를 단순한 Cache로만 바라보기 어려워지고 있다는 것을 보여줬습니다.

기능적인 측면에서는

```text
Cache
+
Search
+
Vector
+
JSON
+
Time Series
```

같은 방향으로 계속 확장되고 있습니다.

동시에 생태계 측면에서는

```text
Redis
vs
Valkey
```

라는 새로운 선택지가 등장했습니다.

따라서 Redis를 도입하거나 기존 Redis Infrastructure를 유지하는 기업에서는 이제 다음을 함께 검토할 필요가 있습니다.

- Redis가 제공하는 기능
- 운영 비용
- Cloud Provider 지원
- 라이선스
- Vendor Dependency
- Valkey와의 호환성
- 장기적인 Migration 가능성

결국 Redis 7.4는 단순한 Database Version Update라기보다,

> **Redis가 Cache를 넘어 범용 Data Platform으로 확장되는 동시에, Infrastructure 기술을 선택할 때 라이선스와 Vendor Dependency까지 고려해야 한다는 것을 보여준 시점**

이라고 볼 수 있습니다.

2024년 8월 2일(금) 주간 개발트렌드

독자의 메모