2025년 5월 9일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

## Database — Redis 8 GA + 오픈소스 라이선스 변화

Redis가 **어제날짜인 25년 5월 1일 Redis 8**을 정식 출시했습니다.

Redis 측 발표 기준으로 Redis 8에는 **30개 이상의 성능 개선**이 포함됐고, 기존에 별도 Module이나 Redis Stack 기능으로 다뤄지던 **JSON, Search, Time Series, Bloom Filter** 등의 기능이 Redis 본체에 통합됐습니다.

또한 AI와 Vector Search 활용을 고려한 **Vector Set** 기능도 추가됐습니다.

라이선스 측면에서도 변화가 있었습니다. 기존 RSALv2와 SSPLv1에 더해 **AGPLv3를 선택할 수 있게 되면서 Redis가 다시 OSI 승인 Open Source License 선택지를 제공**하기 시작했습니다.

[Redis - Redis 8 GA](https://redis.io/blog/redis-8-ga/)

---

### 기존 Redis

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

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

Backend에서는 주로 다음과 같은 용도로 활용했습니다.

```text
Redis

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

특히 Database 앞에 Cache Layer를 추가하는 용도가 가장 대표적이었습니다.

```text
Application
    ↓
Redis Cache
    ↓
Database
```

자주 조회되는 데이터를 Memory에 저장해 Database 접근을 줄이고 Response Latency를 낮추는 방식입니다.

---

### 하지만 Redis의 역할은 계속 확대됐다

Redis 생태계에는 기본 Key-Value 기능 외에도 다양한 Module이 존재했습니다.

```text
Redis

RedisJSON

RediSearch

RedisTimeSeries

RedisBloom
```

각 기능은 Redis를 서로 다른 Workload에 사용할 수 있도록 확장했습니다.

예를 들어 JSON Module을 사용하면 JSON Document를 저장하고,

```text
RedisJSON
   ↓
JSON Document
```

RediSearch를 사용하면 Search와 Vector Search 기능을 사용할 수 있었습니다.

```text
RediSearch
   ↓
Search
+
Vector Search
```

Time Series 데이터나 Probabilistic Data Structure 역시 별도 기능으로 제공됐습니다.

---

### Redis 8의 변화

Redis 8에서는 이러한 기능들이 Redis 본체에 더 깊게 통합됐습니다.

```text
기존

Redis
+
RedisJSON
+
RediSearch
+
RedisTimeSeries
+
RedisBloom
```

점점 다음과 같은 형태로 바뀝니다.

```text
Redis 8

├─ Key-Value
├─ JSON
├─ Search
├─ Time Series
├─ Bloom Filter
└─ Vector
```

개발자 입장에서는 Redis를 단순 Cache Engine이 아니라 **여러 Data Structure와 Search 기능을 제공하는 Data Platform**으로 바라볼 수 있게 된 것입니다.

---

### JSON

현대 Backend에서는 모든 데이터를 완전히 정규화된 Relational Structure로 저장하지 않는 경우가 많습니다.

예를 들어 User Metadata 같은 데이터는 JSON 형태가 더 자연스러울 수 있습니다.

```json
{
  "userId": 100,
  "preferences": {
    "theme": "dark",
    "language": "ko"
  }
}
```

Redis에서 JSON을 직접 다룰 수 있다면 Application에서 다음과 같은 구조를 사용할 수 있습니다.

```text
Application
    ↓
Redis
    ↓
JSON Document
```

단순 String Value를 저장하는 것보다 데이터 일부를 조회하거나 수정하기 쉬워집니다.

---

### Search

Redis가 Search 기능을 제공하면 Key를 정확하게 알고 있지 않아도 데이터를 검색할 수 있습니다.

기존 Key-Value 접근은 일반적으로 다음과 같습니다.

```text
Key
 ↓
Value
```

예를 들어

```text
user:100
```

이라는 Key를 알고 있어야 데이터를 빠르게 가져올 수 있습니다.

Search가 추가되면 다음처럼 조건 기반 검색이 가능합니다.

```text
Document
   ↓
Index
   ↓
Search Query
   ↓
Results
```

Application에서 별도의 Search Engine을 추가해야 하는 상황을 일부 줄일 수 있습니다.

---

### Time Series

Monitoring이나 IoT, Metric 데이터에서는 시간 순서대로 값이 계속 들어옵니다.

```text
10:00 → CPU 30%

10:01 → CPU 40%

10:02 → CPU 35%
```

이런 데이터를 일반적인 Key-Value 형태로만 관리하기는 불편할 수 있습니다.

Time Series 기능을 사용하면 다음과 같은 데이터를 다루기 쉬워집니다.

```text
Timestamp
   ↓
Value
```

대표적인 활용 사례는 다음과 같습니다.

```text
Metrics

IoT Sensor

Stock / Price Data

Application Monitoring

Real-time Analytics
```

Redis가 단순 Cache뿐 아니라 실시간 데이터 처리 영역까지 확대되는 이유입니다.

---

### Bloom Filter

Bloom Filter는 어떤 값이 **존재하지 않는다는 것을 빠르게 판단**할 수 있는 Probabilistic Data Structure입니다.

예를 들어 수억 개의 데이터가 있는 상황에서 특정 ID가 존재하는지 빠르게 확인한다고 가정할 수 있습니다.

```text
Input
 ↓
Bloom Filter
 ↓
Probably Exists

또는

Definitely Not Exists
```

실제 Database Query 전에 Bloom Filter를 사용하면 불필요한 조회를 줄일 수 있습니다.

```text
Request
 ↓
Bloom Filter
 ↓
없음
 ↓
DB Query 생략
```

대규모 System에서 Cache Penetration을 줄이는 방식 등에도 활용할 수 있습니다.

---

### Vector Search

생성형 AI가 확산되면서 Redis에서 가장 주목받는 영역 중 하나가 **Vector Search**입니다.

문서나 이미지 같은 데이터를 Embedding Model에 전달하면 Vector로 변환할 수 있습니다.

```text
Document
   ↓
Embedding Model
   ↓
Vector
```

사용자의 질문 역시 Vector로 변환합니다.

```text
User Query
   ↓
Embedding
   ↓
Query Vector
```

두 Vector 사이의 유사도를 비교하면 의미적으로 비슷한 데이터를 찾을 수 있습니다.

```text
Query Vector
     ↓
Similarity Search
     ↓
Relevant Documents
```

---

### RAG와 Redis

RAG(Retrieval-Augmented Generation)는 LLM에게 관련 문서를 찾아 Context로 제공하는 Architecture입니다.

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

이때 Vector Search를 담당하기 위해 별도의 Vector Database를 도입할 수 있습니다.

```text
Application

├─ PostgreSQL
├─ Redis
└─ Vector DB
```

하지만 Redis가 이미 Vector Search를 제공한다면 상황에 따라 새로운 Database를 추가하지 않고 Redis로 처리하는 것도 검토할 수 있습니다.

```text
Application
    ↓
Redis

├─ Cache
└─ Vector Search
```

Infrastructure Component를 하나 줄일 수 있는 것입니다.

---

### Vector Set

Redis 8에서는 **Vector Set**이라는 새로운 Data Type도 추가됐습니다.

기존 Redis Collection처럼 Vector 데이터를 보다 직접적으로 다루기 위한 기능입니다.

개념적으로는 다음과 같습니다.

```text
Vector Set

├─ Vector A
├─ Vector B
├─ Vector C
└─ Vector D
```

여기에 Query Vector를 전달하면 유사한 Vector를 검색할 수 있습니다.

```text
Query Vector
     ↓
Vector Set
     ↓
Nearest Vectors
```

Vector Search를 Redis의 기본 Data Structure에 가까운 형태로 다루려는 방향입니다.

---

### AI 서비스에서 의미가 큰 이유

AI Application에서는 일반 Backend보다 Infrastructure 종류가 빠르게 증가할 수 있습니다.

```text
AI Application

├─ PostgreSQL
├─ Redis
├─ Object Storage
├─ Vector DB
├─ Queue
└─ LLM API
```

각 Infrastructure가 추가될 때마다 운영해야 할 것도 함께 증가합니다.

```text
Monitoring

Backup

Security

Scaling

Connection

Upgrade

Cost
```

따라서 기존 Redis로 Vector Search 요구사항까지 처리할 수 있다면 Architecture를 단순화할 수 있습니다.

```text
기존

PostgreSQL
+
Redis
+
Vector DB


가능한 대안

PostgreSQL
+
Redis
```

특히 작은 SaaS나 초기 AI Application에서는 의미가 클 수 있습니다.

---

### 그렇다고 Vector DB가 필요 없어지는 것은 아니다

Redis가 Vector Search를 제공한다고 해서 전문 Vector Database가 항상 필요 없어지는 것은 아닙니다.

Architecture는 Workload에 따라 결정해야 합니다.

```text
Simple RAG

적은 Vector
기존 Redis 사용 중
낮은 운영 Complexity 중요
        ↓
Redis 검토


Large-scale Vector Search

매우 많은 Vector
복잡한 Filtering
전문적인 Retrieval
        ↓
Vector DB 검토
```

전문 Vector Database는 Vector Search에 특화된 Index, Filtering, Distributed Architecture 등의 장점을 제공할 수 있습니다.

중요한 것은 처음부터 무조건 새로운 Database를 추가하는 것이 아니라 **현재 Infrastructure로 요구사항을 해결할 수 있는지 먼저 확인하는 것**입니다.

---

### Database를 추가하는 것은 공짜가 아니다

새 Database 하나를 도입하면 Application Architecture도 복잡해집니다.

```text
Application
     ↓
Database A

     ↓
Database B

     ↓
Database C
```

각각 다음 문제를 관리해야 합니다.

```text
Connection Pool

Monitoring

Backup

Upgrade

Authentication

Network

Failure Handling
```

따라서 Infrastructure 선택에서는 기능뿐 아니라 **Operational Complexity**도 중요한 비용입니다.

---

### Redis 하나로 어디까지 할 것인가

Redis 8의 기능이 많아지면서 반대 문제도 생깁니다.

```text
Redis

Cache
+
Session
+
Search
+
Vector
+
Time Series
+
Queue
```

하나의 Redis Cluster에 너무 많은 역할을 몰아넣으면 장애 영향 범위가 커질 수 있습니다.

```text
Redis Failure
    ↓
Cache 장애

Session 장애

Vector Search 장애

Queue 장애
```

따라서 Redis가 기능을 지원한다고 해서 모든 Workload를 반드시 Redis 하나에 넣어야 하는 것은 아닙니다.

---

### 기능 통합과 Architecture 통합은 다르다

Redis가 여러 기능을 제공하는 것과 실제 Production Architecture에서 모든 기능을 하나의 Cluster에 넣는 것은 다른 문제입니다.

```text
Feature Availability
       ≠
Single Cluster Architecture
```

필요하다면 Redis를 역할별로 분리할 수도 있습니다.

```text
Redis Cache Cluster

Redis Session Cluster

Redis AI/Search Cluster
```

같은 기술을 사용하더라도 Failure Domain을 분리할 수 있습니다.

---

### Redis 성능 개선

Redis 8에서는 기능 추가뿐 아니라 **30개 이상의 Performance Improvement**도 강조됐습니다.

Redis는 In-memory Database이기 때문에 Latency와 Throughput이 매우 중요한 제품입니다.

```text
Request
 ↓
Redis
 ↓
Memory
 ↓
Response
```

특히 다음과 같은 Backend 기능에서는 Redis의 응답 시간이 Application 전체 성능에 직접적으로 영향을 줍니다.

```text
Cache

Session

Rate Limiting

Real-time Data

Search
```

Redis가 지원하는 Workload가 많아질수록 Core Engine의 Performance Improvement 역시 중요해집니다.

---

### Redis 라이선스 변화

Redis 생태계에서는 기술 기능만큼 라이선스가 큰 이슈였습니다.

2024년 Redis는 기존 BSD License에서 벗어나 **RSALv2 + SSPLv1 Dual License** 구조를 도입했습니다.

```text
Redis 7.4

RSALv2
+
SSPLv1
```

이 변화는 Redis Community와 Cloud Provider 생태계에서 큰 논쟁을 만들었습니다.

그리고 Redis 8에서는 새로운 선택지가 추가됩니다.

```text
Redis 8

RSALv2
+
SSPLv1
+
AGPLv3
```

AGPLv3가 추가되면서 다시 OSI 승인 Open Source License 선택지가 제공되기 시작했습니다.

---

### 왜 AGPLv3가 중요한가

Open Source Software에서 License는 단순한 법률 문서가 아닙니다.

기업이 기술을 선택할 때 매우 중요한 조건입니다.

```text
Technology Selection

├─ Performance
├─ Features
├─ Stability
├─ Community
└─ License
```

특히 Cloud Service나 SaaS처럼 Software를 Network를 통해 제공하는 경우 License 조건이 Business Model과 직접적으로 연결될 수 있습니다.

따라서 Infrastructure Software를 도입할 때는 기능뿐 아니라 **어떤 License로 사용할 것인지 반드시 확인해야 합니다.**

---

### Valkey와의 경쟁

Redis의 2024년 License 변경 이후 Community에서는 Redis Fork인 **Valkey**가 등장했습니다.

```text
Redis
  ↓
License Change
  ↓
Valkey Fork
```

Valkey는 Linux Foundation 산하 프로젝트로 발전하면서 기존 Redis 사용자를 위한 대안으로 자리 잡기 시작했습니다.

```text
Key-Value Ecosystem

Redis
  vs
Valkey
```

Redis 8의 AGPLv3 추가 역시 이러한 생태계 변화와 무관하지 않습니다.

---

### Redis와 Valkey를 선택할 때

기업에서는 단순한 Benchmark만 비교하면 안 됩니다.

다음 요소를 함께 봐야 합니다.

```text
Selection Criteria

├─ Feature
├─ Performance
├─ Compatibility
├─ Cloud Support
├─ License
├─ Community
├─ Ecosystem
└─ Long-term Roadmap
```

기존 Redis를 이미 깊게 사용하고 있다면 Migration 비용도 고려해야 합니다.

```text
Redis Dependency
      ↓
Cache
Session
Lock
Queue
Search
      ↓
Migration Cost 증가
```

Infrastructure 기술은 한번 깊게 들어가면 교체 비용이 커질 수 있기 때문입니다.

---

### Backend 관점에서 Redis의 변화

예전 Backend Architecture에서 Redis의 위치는 비교적 명확했습니다.

```text
Backend
   ↓
Redis
   ↓
Cache
```

현재는 역할이 훨씬 다양합니다.

```text
Backend
   ↓
Redis

├─ Cache
├─ Session
├─ Lock
├─ Rate Limit
├─ Pub/Sub
├─ Streams
├─ JSON
├─ Search
├─ Time Series
└─ Vector
```

Redis가 Application Architecture에서 담당할 수 있는 역할이 크게 늘어난 것입니다.

---

### 범용 Data Platform으로 이동

Redis의 방향을 단순화하면 다음과 같습니다.

```text
과거

Key-Value Cache
```

이후

```text
Cache
+
Data Structure
+
Messaging
```

그리고 Redis 8에서는 더욱 확장됩니다.

```text
Redis

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

단순한 Cache Server보다 **Real-time Data Platform**에 가까운 방향으로 발전하고 있습니다.

---

### PostgreSQL과도 비슷한 흐름

최근 Database 생태계에서는 하나의 Database가 여러 Workload를 지원하는 흐름이 나타나고 있습니다.

PostgreSQL도 다음과 같이 확장되고 있습니다.

```text
PostgreSQL

Relational
+
JSON
+
Vector
+
GIS
+
Time Series
```

Redis 역시 비슷합니다.

```text
Redis

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

각 Database가 기존 핵심 영역을 넘어 주변 Workload까지 흡수하고 있습니다.

---

### Database 선택이 더 어려워진다

과거에는 각 Database의 역할이 상대적으로 명확했습니다.

```text
PostgreSQL
→ RDBMS


Redis
→ Cache


Elasticsearch
→ Search
```

현재는 기능이 서로 겹치기 시작했습니다.

```text
PostgreSQL
→ JSON / Vector


Redis
→ Search / Vector / JSON


Search Engine
→ Vector Search
```

따라서 Architecture에서 중요한 질문도 달라집니다.

```text
이 기능을 지원하는가?
```

보다

```text
우리 Workload에서
어떤 Database가 가장 적합한가?
```

를 판단해야 합니다.

---

### RAG Architecture에서도 같은 문제

RAG Application을 만든다고 해서 반드시 Vector Database부터 도입할 필요는 없습니다.

먼저 현재 Infrastructure를 확인할 수 있습니다.

```text
Current Stack

PostgreSQL
+
Redis
```

그리고 다음과 같이 판단할 수 있습니다.

```text
Vector 규모는?

검색 성능 요구사항은?

Metadata Filtering은?

Traffic은?

기존 Redis 운영 경험은?

별도 DB 운영 비용은?
```

요구사항이 단순하다면 Redis를 먼저 검토할 수도 있습니다.

```text
RAG

Embedding
   ↓
Redis Vector
   ↓
Retrieval
   ↓
LLM
```

---

### 작은 SaaS에서는 특히 의미가 있다

초기 SaaS에서는 Infrastructure를 많이 추가할수록 개발과 운영 부담이 커집니다.

```text
Small Team

Application
+
PostgreSQL
+
Redis
+
Vector DB
+
Search Engine
+
Queue
```

기능마다 Infrastructure를 추가하면 Product보다 운영에 더 많은 시간을 사용할 수도 있습니다.

Redis 8 같은 Platform은 일부 Workload를 통합해 Architecture를 단순화할 수 있는 선택지를 제공합니다.

```text
Simpler Stack

Application
+
PostgreSQL
+
Redis
```

작은 팀에게는 이런 단순성이 큰 장점이 될 수 있습니다.

---

### 규모가 커지면 다시 분리할 수 있다

초기 Architecture를 단순하게 시작했다고 영원히 같은 구조를 유지할 필요는 없습니다.

```text
초기

Redis Vector Search
      ↓

Traffic 증가
Data 증가
Requirement 복잡화
      ↓

전문 Vector DB 검토
```

이런 방식으로 Infrastructure를 단계적으로 확장할 수 있습니다.

```text
Start Simple
    ↓
Measure
    ↓
Scale
    ↓
Specialize
```

처음부터 최대 규모의 Architecture를 설계하는 것보다 실제 요구사항에 맞춰 발전시키는 방식입니다.

---

### 실무 영향

Redis 8에서는 기존 Redis Stack 기능들이 본체로 통합되면서 Redis를 사용하는 방식 자체가 단순해졌습니다.

```text
기존

Redis
+
RedisJSON
+
RediSearch
+
RedisTimeSeries
+
RedisBloom
```

에서

```text
Redis 8

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

형태로 이동했습니다.

Backend 개발자 입장에서는 새로운 요구사항이 생겼을 때 무조건 새로운 Database부터 추가하기보다 **기존 Redis가 해당 Workload를 처리할 수 있는지 먼저 검토할 수 있는 범위가 넓어진 것**입니다.

특히 AI와 RAG 서비스에서는

```text
Embedding
 ↓
Vector Search
 ↓
Retrieval
 ↓
LLM
```

구조에서 Redis를 Vector Search Layer로 활용할 수 있는 선택지가 더욱 명확해졌습니다.

동시에 AGPLv3 License 선택지가 추가되면서 Redis의 Open Source 생태계에도 다시 변화가 생겼습니다.

결국 Redis 8은,

> **Redis가 단순한 In-memory Key-Value Cache에서 Search, JSON, Time Series, Vector까지 제공하는 범용 Real-time Data Platform으로 확장되고 있음을 보여주는 Release**

라고 볼 수 있습니다.

다만 기능이 많아졌다고 모든 Workload를 Redis 하나에 넣는 것이 정답은 아닙니다.

실제 Architecture에서는 **성능, 데이터 규모, 장애 영향 범위, 운영 Complexity, License를 함께 고려해 Redis로 통합할 영역과 별도의 전문 Database로 분리할 영역을 결정하는 것**이 중요합니다.

2025년 5월 2일(금) 주간 개발트렌드

독자의 메모