2025년 6월 27일(금) 주간 트렌드

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


## AI — Gemini 2.5 Pro / Flash GA, Reasoning도 비용에 따라 선택하는 시대

Google이 **6월 17일 Gemini 2.5 Pro와 Gemini 2.5 Flash를 Stable/GA**로 전환했습니다.

동시에 더 낮은 비용과 높은 처리량을 목표로 한 **Gemini 2.5 Flash-Lite**도 Preview로 공개했습니다.

Gemini 2.5는 Google이 **Thinking Model Family**로 정의한 모델 계열로, 단순히 답변을 생성하는 것뿐 아니라 문제를 해결하기 전에 추가적인 Reasoning Compute를 사용할 수 있도록 설계됐습니다.

특히 개발자는 Workload에 따라 Thinking 수준을 조절할 수 있어 **성능, Latency, Cost 사이의 균형을 Application에서 직접 설계**할 수 있게 됐습니다.

[Google Developers Blog - Gemini 2.5 Thinking Model Updates](https://developers.googleblog.com/gemini-2-5-thinking-model-updates/)

---

### Reasoning Model의 초기 모습

2024년 OpenAI o1이 등장하면서 AI Model 경쟁에 새로운 축이 생겼습니다.

기존 LLM을 단순화하면 다음과 같았습니다.

```text
Prompt
  ↓
LLM
  ↓
Answer
```

Reasoning Model에서는 문제를 해결하기 위해 추가적인 Compute를 사용합니다.

```text
Problem
   ↓
Reasoning
   ↓
Inference Compute
   ↓
Answer
```

특히 다음과 같은 문제에서 효과가 컸습니다.

```text
Coding

Mathematics

Science

Complex Planning

Logical Reasoning
```

하지만 초기 Reasoning Model은 상대적으로 비싸고 느린 **고난도 작업용 모델**이라는 성격이 강했습니다.

---

### Reasoning이 기본 Model Family로 내려오기 시작했다

2025년에 들어오면서 상황이 빠르게 바뀌었습니다.

```text
OpenAI o-series

DeepSeek R1

Claude 3.7

Gemini 2.5
```

주요 AI Provider들이 Reasoning을 핵심 Model Architecture로 가져오기 시작했습니다.

Gemini 2.5에서는 더 나아가 하나의 고성능 Reasoning Model만 제공하는 것이 아니라 서로 다른 비용과 성능 특성을 가진 Model Family를 구성했습니다.

```text
Gemini 2.5

├─ Pro
├─ Flash
└─ Flash-Lite
```

Reasoning 자체가 일부 고급 사용자만 사용하는 특수 기능에서 **일반 Application에서도 선택할 수 있는 Compute 옵션**으로 내려오기 시작한 것입니다.

---

### Gemini 2.5 Pro

Gemini 2.5 Pro는 복잡한 Reasoning과 Coding, 긴 Context 처리 같은 고난도 작업을 위한 상위 Model입니다.

```text
Complex Task
     ↓
Gemini 2.5 Pro
     ↓
Deep Reasoning
     ↓
Result
```

대표적인 Workload는 다음과 같습니다.

```text
Complex Coding

Architecture Analysis

Large Document Analysis

Mathematics

Research

Multi-step Reasoning
```

Latency와 Cost보다 높은 Capability가 중요한 작업에 적합한 방향입니다.

---

### Gemini 2.5 Flash

Flash는 높은 처리 속도와 비용 효율을 고려한 Model입니다.

```text
Normal Request
      ↓
Gemini 2.5 Flash
      ↓
Reasoning
      ↓
Fast Response
```

모든 작업에 Pro 수준의 Compute가 필요하지 않기 때문에 일반적인 AI Application에서는 Flash 같은 Model의 활용도가 높을 수 있습니다.

예를 들어 다음과 같은 작업입니다.

```text
Chat

Summarization

Classification

Data Extraction

Simple Coding

Content Processing
```

Reasoning Capability를 제공하면서도 **Production Traffic을 처리하기 위한 속도와 비용을 함께 고려한 Model**입니다.

---

### Flash-Lite

Google은 동시에 **Gemini 2.5 Flash-Lite Preview**도 공개했습니다.

Flash보다 더 높은 처리량과 낮은 비용을 목표로 하는 Model입니다.

```text
Large Volume
     ↓
Flash-Lite
     ↓
Low Cost
     ↓
High Throughput
```

대표적으로 다음과 같은 작업에서 의미가 있습니다.

```text
Classification

Tagging

Simple Extraction

Content Filtering

High-volume Processing

Batch Processing
```

AI Service에서는 Request 하나의 가격 차이는 작아 보여도 Traffic이 커지면 전체 비용에 큰 영향을 줍니다.

---

### Reasoning도 하나의 Resource가 된다

이전에는 Model을 선택하면 Reasoning 수준 역시 거의 Model에 의해 결정됐습니다.

```text
Model 선택
   ↓
Capability 결정
```

Gemini 2.5의 Thinking Model 구조에서는 개발자가 **Thinking Budget을 조절하는 방식**을 사용할 수 있습니다.

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

```text
Low Thinking

빠른 응답
낮은 Cost


Medium Thinking

속도와 성능의 균형


High Thinking

더 많은 Reasoning
높은 Capability
```

즉 Model뿐 아니라 **Inference 과정에서 Reasoning에 얼마나 많은 Compute를 사용할 것인지**도 Application 설정으로 들어오기 시작했습니다.

---

### Thinking Budget

Thinking Budget은 Model이 문제를 해결하기 위해 Reasoning에 사용할 수 있는 Compute를 조절하기 위한 개념입니다.

```text
Request
   ↓
Thinking Budget
   ↓
Reasoning
   ↓
Response
```

단순한 요청에는 많은 Reasoning이 필요하지 않습니다.

```text
"이 문장을 영어로 번역해줘"

→ 낮은 Reasoning
```

반면 복잡한 Architecture 문제라면 더 많은 Reasoning이 유용할 수 있습니다.

```text
"이 Distributed System의
동시성 문제를 분석해줘"

→ 높은 Reasoning
```

모든 Request에서 동일한 Compute를 사용할 필요가 없는 것입니다.

---

### 기존 Model Routing

Model Routing은 이미 2024년부터 중요해지고 있었습니다.

```text
Simple Task
     ↓
Small Model


Complex Task
     ↓
Large Model
```

저렴한 Model의 성능이 높아지면서 모든 Request를 가장 큰 Model에 보내는 Architecture가 비효율적으로 보이기 시작했습니다.

Gemini 2.5 Model Family는 이 구조를 더 세분화합니다.

```text
Simple Task
     ↓
Flash-Lite


General Task
     ↓
Flash


Complex Task
     ↓
Pro
```

---

### Model Routing + Reasoning Routing

이제 Model뿐 아니라 Reasoning 수준도 선택할 수 있습니다.

```text
Request
   ↓
Task Analyzer
   ↓
Model 선택
   ↓
Thinking Budget 선택
   ↓
Inference
```

예를 들어 다음과 같은 구조를 만들 수 있습니다.

```text
Simple Extraction
      ↓
Flash-Lite
      ↓
Low Thinking


Normal Chat
      ↓
Flash
      ↓
Medium Thinking


Complex Coding
      ↓
Pro
      ↓
High Thinking
```

AI Backend에서 **Model Routing과 Compute Routing이 결합**되기 시작한 것입니다.

---

### 왜 중요한가

초기의 AI Application은 하나의 Model만 연결해도 충분했습니다.

```text
Application
     ↓
LLM
```

하지만 Model Family가 다양해지면서 Architecture가 달라집니다.

```text
Application
     ↓
AI Router
     │
     ├─ Flash-Lite
     ├─ Flash
     └─ Pro
```

Backend가 단순히 LLM API를 호출하는 Layer에서 **요청의 특성에 따라 적절한 Model과 Compute를 선택하는 Layer**로 발전합니다.

---

### AI Backend Architecture

Model Routing이 들어가면 Backend 구조는 다음과 같이 확장될 수 있습니다.

```text
Client
  ↓
Backend
  ↓
AI Gateway
  ↓
Task Classifier
  ↓
Model Router
  │
  ├─ Gemini 2.5 Flash-Lite
  ├─ Gemini 2.5 Flash
  └─ Gemini 2.5 Pro
```

Router에서는 다음 요소를 판단할 수 있습니다.

```text
Task Complexity

Latency Requirement

Expected Context Size

Reasoning 필요성

Cost Budget

User Tier
```

AI Model 자체보다 **어떤 요청을 어디로 보내는가**가 서비스 품질과 비용에 직접적인 영향을 주게 됩니다.

---

### Cost Optimization

예를 들어 하루에 100만 개의 요청을 처리한다고 가정할 수 있습니다.

모든 요청에 가장 높은 성능의 Model을 사용하면 다음 구조가 됩니다.

```text
1,000,000 Requests
        ↓
Gemini 2.5 Pro
```

하지만 실제 요청 대부분이 단순한 작업일 수 있습니다.

```text
전체 요청

├─ 60% Simple
├─ 30% Normal
└─ 10% Complex
```

Routing을 사용하면 다음과 같이 구성할 수 있습니다.

```text
60%

Flash-Lite


30%

Flash


10%

Pro
```

Model Capability를 필요한 작업에만 사용하는 것입니다.

---

### AI의 Unit Economics

AI Service에서는 Model Cost가 서비스의 Unit Economics와 직접 연결됩니다.

```text
User 증가
   ↓
Request 증가
   ↓
Token 증가
   ↓
Inference Cost 증가
```

전통적인 Backend에서는 CPU와 Database 비용을 최적화했다면 AI Application에서는 **Model Inference 자체가 주요 Infrastructure Cost**가 될 수 있습니다.

따라서 다음과 같은 계산이 중요해집니다.

```text
Request당 Cost
      ×
Request 수
      =
Total AI Cost
```

Model Routing은 단순한 Architecture Pattern이 아니라 비용 관리 전략입니다.

---

### Latency도 함께 고려해야 한다

높은 Reasoning에는 더 많은 Compute가 필요할 수 있습니다.

```text
Reasoning 증가
     ↓
Capability 증가 가능
     ↓
Latency 증가 가능
```

따라서 모든 Request에서 최대 Reasoning을 사용하면 사용자 경험이 오히려 나빠질 수도 있습니다.

```text
Simple Question
      ↓
Deep Reasoning
      ↓
불필요한 대기
```

Workload에 맞는 Reasoning 수준이 필요합니다.

---

### Quality, Cost, Latency

AI Backend에서는 세 가지 요소를 동시에 고려해야 합니다.

```text
Quality
  △
 / \
Cost ─ Latency
```

높은 Quality가 필요하면 더 강한 Model이나 많은 Reasoning을 사용할 수 있습니다.

반대로 실시간 서비스에서는 Latency가 더 중요할 수 있습니다.

```text
Realtime Chat

Latency 중요
      ↓
Flash
```

복잡한 분석에서는 Quality가 중요합니다.

```text
Architecture Analysis

Reasoning Quality 중요
        ↓
Pro
```

대량 처리에서는 Cost가 중요합니다.

```text
Batch Processing

Cost 중요
     ↓
Flash-Lite
```

하나의 Model로 모든 Workload를 처리하기 어려워지는 이유입니다.

---

### Coding에서도 Model Routing이 중요하다

Coding Request 역시 복잡도가 매우 다릅니다.

```text
변수 이름 변경

→ Flash


DTO 생성

→ Flash


복잡한 Bug 분석

→ Pro


Architecture 설계

→ Pro
```

모든 Coding Request에 가장 강한 Model을 사용할 필요가 없습니다.

Coding Agent에서는 작업 단계에 따라 Model을 바꿀 수도 있습니다.

```text
Repository Search
      ↓
Flash


Complex Reasoning
      ↓
Pro


결과 요약
      ↓
Flash
```

하나의 Agent Workflow 안에서도 여러 Model을 사용할 수 있는 것입니다.

---

### Agent에서도 비용 문제가 커진다

Agent는 한 번의 Request에서 Model을 여러 번 호출할 수 있습니다.

```text
User Goal
    ↓
Model
    ↓
Tool
    ↓
Model
    ↓
Tool
    ↓
Model
```

따라서 Agent 한 번의 실행 비용은 일반 Chat보다 훨씬 커질 수 있습니다.

```text
Agent Cost

Model Call
+
Model Call
+
Model Call
+
Tool Cost
```

모든 Step에서 Pro를 사용하면 비용이 빠르게 증가할 수 있습니다.

---

### Agent 내부 Model Routing

Agent Workflow에서도 Step별로 다른 Model을 사용할 수 있습니다.

```text
Agent

Planning
   ↓
Pro


Simple Tool Result Processing
   ↓
Flash


Classification
   ↓
Flash-Lite


Complex Error Analysis
   ↓
Pro
```

Model Routing이 단순 Request Routing을 넘어 **Agent Execution Strategy**가 됩니다.

---

### Routing 기준

실제 Application에서는 다양한 기준을 사용할 수 있습니다.

```text
Routing Criteria

├─ Task Type
├─ Complexity
├─ Input Length
├─ User Plan
├─ Latency SLA
├─ Cost Budget
└─ Accuracy Requirement
```

예를 들어 유료 사용자는 더 높은 Reasoning Model을 사용할 수도 있습니다.

```text
Free User
   ↓
Flash


Premium User
   ↓
Pro
```

Product Pricing과 Model Architecture가 연결될 수도 있습니다.

---

### Fallback Strategy

여러 Model을 사용하면 Fallback Architecture도 만들 수 있습니다.

```text
Flash
  ↓
Result 부족
  ↓
Pro
```

처음부터 가장 비싼 Model을 사용하는 대신 작은 Model을 먼저 시도하고 필요한 경우 상위 Model로 Escalation할 수 있습니다.

```text
Request
   ↓
Flash
   ↓
Confidence 충분?
 ├─ Yes → Response
 └─ No
      ↓
     Pro
      ↓
   Response
```

AI Cost를 줄이기 위한 방법 중 하나입니다.

---

### Model Routing이 쉬운 문제는 아니다

다만 Task Complexity를 정확하게 판단하는 것 자체도 하나의 문제입니다.

```text
Request
   ↓
Simple?
Complex?
```

Routing Model이 잘못 판단하면,

```text
Complex Task
    ↓
Cheap Model
    ↓
Quality 감소
```

하거나,

```text
Simple Task
    ↓
Expensive Model
    ↓
Cost 증가
```

할 수 있습니다.

따라서 Routing Logic 역시 지속적으로 측정하고 개선해야 합니다.

---

### Evaluation이 중요해진다

Model이 많아질수록 Benchmark만으로 선택하기 어려워집니다.

실제 서비스의 Workload를 기준으로 평가해야 합니다.

```text
Production Tasks
       ↓
Model A
Model B
Model C
       ↓
Evaluation
```

다음과 같은 Metric을 사용할 수 있습니다.

```text
Accuracy

Task Success Rate

Latency

Token Usage

Cost

User Satisfaction
```

AI Backend에서도 **Application-specific Benchmark**가 중요해집니다.

---

### Observability도 필요하다

어떤 Request가 어떤 Model로 Routing됐는지 확인할 수 있어야 합니다.

```text
Request

Task Type: Coding

Model: Gemini 2.5 Pro

Thinking: High

Latency: 8s

Cost: X
```

이런 데이터를 수집해야 Routing Strategy가 실제로 효율적인지 판단할 수 있습니다.

```text
AI Observability

├─ Model
├─ Token
├─ Latency
├─ Reasoning
├─ Cost
└─ Result Quality
```

AI Infrastructure에서도 Monitoring과 Optimization이 중요해집니다.

---

### Reasoning Model이 Commodity가 되기 시작한다

2024년에는 Reasoning Model 자체가 매우 특별한 기능처럼 보였습니다.

```text
Reasoning
   ↓
Special Model
```

하지만 2025년 중반에는 상황이 바뀝니다.

```text
Reasoning

Pro

Flash

Lite
```

Reasoning Capability 자체가 다양한 가격대와 Performance Tier로 제공되기 시작한 것입니다.

AI 경쟁이

```text
Reasoning이 가능한가?
```

에서

```text
얼마나 빠르고
얼마나 저렴하게
Reasoning을 제공하는가?
```

로 이동합니다.

---

### Model Family 전략

Google의 Gemini 2.5 Family를 보면 이런 방향이 명확합니다.

```text
High Capability
      ↓
Pro


Balanced
      ↓
Flash


High Volume / Low Cost
      ↓
Flash-Lite
```

하나의 Model로 전체 시장을 처리하기보다 Workload별로 서로 다른 Model Tier를 제공하는 방식입니다.

---

### Cloud Compute와 비슷해진다

이 구조는 Cloud Instance를 선택하는 것과도 비슷합니다.

```text
Cloud

Small Instance
Medium Instance
Large Instance
```

Application 요구사항에 맞게 Resource를 선택합니다.

AI에서도 비슷해집니다.

```text
AI Compute

Flash-Lite
Flash
Pro
```

그리고 Thinking Budget까지 추가되면 더 세밀한 Resource Allocation이 가능합니다.

```text
Model
+
Reasoning Compute
```

Inference Compute 자체가 하나의 Cloud Resource처럼 관리되는 방향입니다.

---

### AI Backend의 역할 변화

초기 AI Backend는 단순했습니다.

```text
Prompt
 ↓
Model
 ↓
Response
```

이제는 다음과 같은 요소가 추가됩니다.

```text
AI Backend

├─ Model Routing
├─ Thinking Budget
├─ Context Management
├─ Tool Calling
├─ Cost Control
├─ Fallback
└─ Observability
```

Backend가 단순 LLM Wrapper가 아니라 **AI Compute를 관리하는 Orchestration Layer**로 발전하고 있습니다.

---

### 왜 중요한가

Gemini 2.5 Pro와 Flash의 GA는 Reasoning Model 자체가 Production Application에서 사용할 수 있는 일반적인 선택지가 됐다는 것을 보여줬습니다.

2025년 초까지만 해도

```text
Reasoning
→ High-end Model
```

이라는 이미지가 강했다면,

이제는

```text
Reasoning

High
Medium
Cheap
```

형태로 세분화되고 있습니다.

개발자는 단순히

```text
Gemini를 사용할까?
GPT를 사용할까?
```

를 선택하는 것이 아니라,

```text
이 Request에는
어떤 수준의 Model과
얼마나 많은 Reasoning이 필요한가?
```

를 판단해야 합니다.

---

### 실무 영향

현실적인 AI Backend는 다음과 같은 구조로 발전할 수 있습니다.

```text
Client
  ↓
AI Backend
  ↓
Task Analyzer
  ↓
Model Router
  │
  ├─ Simple / High Volume
  │        ↓
  │    Flash-Lite
  │
  ├─ General
  │        ↓
  │      Flash
  │
  └─ Complex Reasoning
           ↓
          Pro
```

그리고 각 Model에서도 Reasoning 수준을 조절할 수 있습니다.

```text
Model Routing
      +
Thinking Budget
      ↓
Cost / Latency / Quality 최적화
```

결국 Gemini 2.5 Pro와 Flash의 GA는,

> **Reasoning Model이 고난도 작업을 위한 특수 Model에서 벗어나 성능과 비용에 따라 선택할 수 있는 일반적인 AI Compute Resource로 이동했음을 보여주는 변화**

라고 볼 수 있습니다.

AI Backend에서도 하나의 Model을 고정해서 사용하는 구조보다 **Task에 따라 Pro, Flash, Flash-Lite를 선택하고 Reasoning Compute까지 조절하는 Model Routing Architecture**가 비용과 Latency, 서비스 품질을 결정하는 핵심 요소로 자리 잡을 것으로 보여집니다.

2025년 6월 20일(금) 주간 트렌드

2025년 6월 13일(금) 주간 개발트렌드

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

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

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

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

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

## Backend — Node.js 24 출시

Node.js가 **25년 5월 6일 Node.js 24**를 Current 버전으로 공개했습니다.

이번 버전에는 **V8 13.6, npm 11**이 포함됐고, Web API인 `URLPattern`을 Node.js에서도 Global API로 사용할 수 있게 됐습니다.

Node.js는 최근 여러 버전에 걸쳐 `fetch`, WebSocket, Web Streams 같은 브라우저 표준 API를 Runtime 내부에 지속적으로 추가하고 있었는데, Node.js 24에서도 이런 흐름이 이어졌습니다.

다만 출시 당시 Node.js 24는 **Current Release**였으며 Production 장기 운영 기준으로는 Node.js 22 LTS를 유지하면서 24의 Compatibility를 검증하는 전략이 현실적이었습니다.

[Node.js - Node.js v24.0.0](https://nodejs.org/en/blog/release/v24.0.0)

---

### Node.js는 단순한 JavaScript 실행기가 아니다

Node.js가 처음 등장했을 때 핵심 역할은 Browser 밖에서 JavaScript를 실행하는 것이었습니다.

```text
JavaScript
    ↓
Node.js
    ↓
Server
```

이를 통해 JavaScript로 Backend Application을 만들 수 있게 됐습니다.

```text
Client
  ↓
Node.js
  ↓
Database
```

이후 Express, NestJS, Fastify 같은 Framework가 등장하면서 Node.js는 대표적인 Backend Runtime 중 하나로 자리 잡았습니다.

---

### Browser와 Node.js는 같은 JavaScript지만 API가 달랐다

언어 자체는 JavaScript지만 Browser와 Node.js에서 사용할 수 있는 API는 오랫동안 상당히 달랐습니다.

```text
Browser

├─ fetch
├─ WebSocket
├─ FormData
├─ URL
└─ Web Streams
```

반면 과거 Node.js에서는 같은 기능을 사용하기 위해 별도의 Library를 설치하는 경우가 많았습니다.

```text
Node.js

├─ HTTP Client Library
├─ WebSocket Library
├─ Stream API
└─ Node-specific API
```

즉 같은 JavaScript를 사용해도 Runtime에 따라 개발 방식이 달랐습니다.

---

### Node.js가 Web API를 흡수하기 시작했다

최근 Node.js는 Browser와 호환되는 Web Standard API를 계속 Runtime에 추가하고 있습니다.

```text
Browser Web API
       ↕
Node.js Web API
```

대표적으로 다음과 같은 기능들이 있습니다.

```text
fetch

Request

Response

Headers

FormData

Blob

URL

AbortController

Web Streams

WebSocket
```

Node.js 24에서는 여기에 `URLPattern`도 Global API로 사용할 수 있게 됐습니다.

---

### URLPattern

`URLPattern`은 URL을 일정한 Pattern으로 정의하고 Matching할 수 있도록 만들어진 Web API입니다.

예를 들어 다음과 같은 URL이 있다고 가정할 수 있습니다.

```text
/users/10

/users/20

/users/100
```

이를 다음과 같은 Pattern으로 표현할 수 있습니다.

```javascript
const pattern = new URLPattern({
  pathname: '/users/:id'
});
```

URL을 Matching하면 Path Parameter도 확인할 수 있습니다.

```javascript
const result = pattern.exec(
  'https://example.com/users/100'
);

console.log(result.pathname.groups.id);
```

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

```text
/users/100
    ↓
/users/:id
    ↓
id = 100
```

Routing이나 URL Matching Logic을 만들 때 활용할 수 있습니다.

---

### Framework Router와는 다르다

`URLPattern`이 추가됐다고 Express나 NestJS의 Router가 필요 없어지는 것은 아닙니다.

Framework Router는 훨씬 많은 기능을 담당합니다.

```text
NestJS / Express Router

├─ HTTP Method
├─ Middleware
├─ Controller
├─ Validation
├─ Guard
├─ Authentication
└─ Error Handling
```

반면 `URLPattern`은 URL Pattern을 Matching하는 비교적 Low-level API입니다.

```text
URL
 ↓
Pattern Matching
```

따라서 Framework를 대체한다기보다 **Node.js Core에서 활용할 수 있는 기본 Building Block이 하나 더 생긴 것**에 가깝습니다.

---

### 외부 Dependency 없이 해결할 수 있는 영역이 늘어난다

과거 Node.js 개발에서는 간단한 기능도 npm Package를 추가하는 경우가 많았습니다.

```text
Need Feature
    ↓
npm install package
```

하지만 Node Core가 제공하는 기능이 많아지면서 일부 작업은 외부 Dependency 없이 해결할 수 있습니다.

예를 들어 HTTP Request의 경우 과거에는 다음과 같은 Library가 많이 사용됐습니다.

```text
axios

node-fetch
```

현재는 Node.js의 Global `fetch()`를 사용할 수 있습니다.

```javascript
const response = await fetch(
  'https://api.example.com/users'
);

const users = await response.json();
```

---

### WebSocket도 같은 흐름

Node.js 22에서는 WebSocket Client API가 Stable로 승격됐습니다.

```javascript
const socket = new WebSocket(
  'wss://example.com/socket'
);
```

과거에는 `ws` 같은 Library를 사용하는 경우가 많았습니다.

```text
기존

Node.js
   ↓
ws Package
   ↓
WebSocket


최근

Node.js
   ↓
WebSocket
```

Node.js 24의 `URLPattern` 역시 이런 **Web Platform API 통합 흐름의 연장선**에서 볼 수 있습니다.

---

### Node.js가 Web Platform에 가까워진다

전체 흐름을 보면 다음과 같습니다.

```text
과거

Browser API
     │
     │ 차이 큼
     │
Node.js API
```

점점

```text
        Web Standards
          ↙     ↘
     Browser   Node.js
```

형태로 바뀌고 있습니다.

JavaScript 개발자가 Runtime마다 완전히 다른 API를 학습해야 하는 영역이 조금씩 줄어드는 것입니다.

---

### Full Stack JavaScript에서도 의미가 있다

Frontend와 Backend 모두 JavaScript 또는 TypeScript를 사용하는 환경에서는 이런 변화가 특히 의미가 있습니다.

```text
Frontend

React / Next.js
      ↓
JavaScript Web API


Backend

Node.js
      ↓
JavaScript Web API
```

Client와 Server에서 비슷한 API를 사용할 수 있는 영역이 증가합니다.

예를 들어 다음 기능들은 양쪽 환경에서 비슷한 Programming Model을 사용할 수 있습니다.

```text
fetch

URL

Request

Response

Headers

AbortController

Streams
```

Runtime 간 Mental Model 차이가 줄어드는 것입니다.

---

### NestJS에서도 영향을 받는다

NestJS는 Node.js Runtime 위에서 동작합니다.

```text
NestJS
  ↓
Node.js
  ↓
Operating System
```

NestJS 자체는 Controller, Dependency Injection, Guard, Pipe 같은 Application Architecture를 제공합니다.

```text
NestJS

├─ Controller
├─ Service
├─ DI
├─ Guard
├─ Pipe
└─ Middleware
```

하지만 그 아래에서는 Node.js API를 사용합니다.

Node Core 기능이 발전하면 Application 내부 Utility나 Infrastructure Code에서 외부 Library 없이 처리할 수 있는 영역도 늘어납니다.

---

### Express와 Fastify도 마찬가지

Express나 Fastify 역시 Node Runtime 위에서 실행됩니다.

```text
Express / Fastify
       ↓
Node.js
       ↓
Runtime API
```

Framework가 HTTP Application 구조를 담당한다면 Node.js는 그 아래의 Runtime Capability를 제공합니다.

```text
Framework

Routing
Middleware
Validation


Node.js

HTTP
Web API
Streams
Runtime
File System
Network
```

Node.js Core가 강해질수록 Framework 개발자와 Library Author가 활용할 수 있는 기본 기능도 많아집니다.

---

### V8 13.6

Node.js 24에는 **V8 13.6**이 포함됐습니다.

V8은 JavaScript를 실제로 실행하는 Engine입니다.

```text
JavaScript
    ↓
V8
    ↓
Machine Execution
```

Node.js Architecture를 단순화하면 다음과 같습니다.

```text
Application

JavaScript / TypeScript
        ↓
Node.js
        ↓
V8
        ↓
Operating System
```

따라서 V8 Upgrade는 JavaScript Language Feature와 Runtime Performance에도 영향을 줄 수 있습니다.

---

### Node.js와 V8의 관계

Node.js는 JavaScript Language 자체를 직접 실행하는 Engine이 아닙니다.

JavaScript Execution은 V8이 담당합니다.

```text
Node.js

├─ V8
├─ libuv
├─ File System
├─ Network
├─ Web APIs
└─ Node APIs
```

Node.js는 V8 위에 Server Application을 위한 다양한 Runtime API를 추가한 Platform이라고 볼 수 있습니다.

따라서 Node Version이 올라가면 함께 포함되는 V8 Version도 Backend Developer에게 영향을 줄 수 있습니다.

---

### npm 11

Node.js 24에는 **npm 11**도 함께 제공됐습니다.

Node.js Application에서는 Package Manager 역시 개발 환경의 핵심 부분입니다.

```text
Node.js
  ↓
npm
  ↓
Dependencies
```

Application 하나에서도 수백 개의 Dependency가 연결될 수 있습니다.

```text
Application

├─ NestJS
├─ TypeORM
├─ Prisma
├─ Zod
├─ Jest
└─ 기타 Packages
```

따라서 npm의 Version 변화 역시 Dependency Resolution, 설치 성능, CLI 동작 등에 영향을 줄 수 있습니다.

---

### Node Core Tooling도 계속 커지고 있다

최근 Node.js의 또 다른 흐름은 **Runtime 자체에서 제공하는 개발 도구가 많아지고 있다는 점**입니다.

과거에는 많은 기능을 외부 Tool에 의존했습니다.

```text
Node.js
+
External Package
+
External Tool
```

최근 Node에는 다음과 같은 기능들이 포함돼 있습니다.

```text
Node.js Core

├─ Test Runner
├─ Watch Mode
├─ Env File
├─ fetch
├─ WebSocket
└─ node --run
```

Runtime과 Toolchain의 경계도 점점 넓어지고 있습니다.

---

### Dependency가 줄어드는 장점

외부 Dependency가 적다고 무조건 좋은 것은 아니지만 불필요한 Dependency를 줄이면 몇 가지 장점이 있습니다.

```text
Dependency 감소

↓
Update 대상 감소

↓
Security Surface 감소

↓
Compatibility 문제 감소
```

특히 Node.js 생태계는 작은 Package까지 Dependency로 사용하는 경우가 많기 때문에 Dependency Tree가 매우 커질 수 있습니다.

```text
Application
   ↓
Package A
   ↓
Package B
   ↓
Package C
```

Core API로 해결할 수 있는 기능이라면 외부 Package가 정말 필요한지 다시 판단할 수 있습니다.

---

### 그렇다고 Node Core만 사용해야 하는 것은 아니다

Node.js에 기능이 들어왔다고 기존 Library를 무조건 제거해야 하는 것은 아닙니다.

예를 들어 `fetch`보다 Axios가 필요한 경우도 있습니다.

```text
Axios

Interceptors

Request Configuration

Convenient Error Handling

기존 Project Integration
```

Framework와 Library는 Node Core보다 높은 수준의 Abstraction을 제공합니다.

따라서 중요한 것은

```text
Core에 기능이 있으니
Library를 무조건 제거한다
```

가 아니라

```text
우리 Application에
추가 Dependency가 실제로 필요한가?
```

를 판단하는 것입니다.

---

### Current와 LTS

Node.js를 Production에서 운영할 때 가장 중요한 개념 중 하나가 **Release Channel**입니다.

Node.js Version은 일반적으로 먼저 Current로 출시됩니다.

```text
New Version
    ↓
Current
```

이후 일정 기간이 지나면 짝수 Major Version이 LTS로 전환됩니다.

```text
Current
  ↓
LTS
  ↓
Maintenance
```

Node.js 24 역시 2025년 5월 출시 당시에는 Current였습니다.

---

### Current는 무엇인가

Current Release에서는 최신 Node.js 기능을 가장 빠르게 사용할 수 있습니다.

```text
Current

최신 Feature
최신 V8
새로운 API
```

하지만 기업 Production에서 필요한 장기 Support 관점에서는 LTS보다 안정성이 검증되는 기간이 짧습니다.

따라서 다음과 같은 용도로 활용할 수 있습니다.

```text
Development

Compatibility Test

Benchmark

PoC

Library Testing
```

---

### LTS는 무엇인가

LTS(Long-Term Support)는 Production Application에서 장기간 유지하기 위한 Channel입니다.

```text
Production
    ↓
Node.js LTS
```

Framework와 Library 생태계 역시 대체로 LTS Version을 중심으로 Compatibility를 관리합니다.

따라서 장기 운영 Backend에서는 LTS가 기본 선택인 경우가 많습니다.

---

### 당시 현실적인 선택

Node.js 24가 나온 2025년 5월 시점에는 Node.js 22가 LTS였습니다.

따라서 Production 전략은 다음과 같이 가져갈 수 있었습니다.

```text
Production

Node.js 22 LTS


Development / CI

Node.js 24 Test


향후

Node.js 24 LTS 전환 후 Migration
```

안정적인 운영 환경을 유지하면서 새로운 Version의 Compatibility를 미리 확인하는 방식입니다.

---

### 무조건 최신 Node.js가 좋은 것은 아니다

Backend Runtime은 Application 전체의 기반입니다.

```text
Application
    ↓
Framework
    ↓
Node.js
```

Node.js Version을 변경하면 많은 Dependency에 영향을 줄 수 있습니다.

```text
Node Upgrade

├─ NestJS
├─ Express
├─ Fastify
├─ Native Module
├─ ORM
├─ Build Tool
└─ Test Tool
```

따라서 Production에서는 최신 Version이라는 이유만으로 즉시 Upgrade하는 것보다 Compatibility를 확인하는 것이 중요합니다.

---

### Node.js Upgrade에서 확인할 것

실제 Backend Project에서는 다음 요소를 확인할 수 있습니다.

```text
Node Upgrade

├─ Framework Compatibility
├─ Package Compatibility
├─ Native Addon
├─ npm Version
├─ Build
├─ Test
├─ Container Image
└─ CI/CD
```

예를 들어 Native Addon을 사용하는 Dependency는 Node/V8 Version 변화에 영향을 받을 가능성이 있습니다.

따라서 Test Suite가 충분하다면 Upgrade 검증이 훨씬 쉬워집니다.

---

### CI에서 여러 Node Version을 검증할 수 있다

Library나 중요한 Backend Service라면 CI에서 여러 Node Version을 테스트할 수도 있습니다.

```text
CI

├─ Node 22
└─ Node 24
```

이를 통해 Production Migration 전에 Compatibility 문제를 찾을 수 있습니다.

```text
Node 24
  ↓
npm install
  ↓
Test
  ↓
Build
```

Runtime Upgrade 역시 자동화된 Test의 가치가 큰 영역입니다.

---

### Docker 환경에서도 Node Version이 중요하다

Container 기반 Backend에서는 Node Version이 Base Image에 포함되는 경우가 많습니다.

```dockerfile
FROM node:22
```

Node 24를 테스트하려면 다음처럼 변경할 수 있습니다.

```dockerfile
FROM node:24
```

하지만 Version만 바꾸는 것으로 끝내지 않고 Application Build와 Runtime 동작을 검증해야 합니다.

```text
Base Image 변경
      ↓
Install
      ↓
Build
      ↓
Test
      ↓
Runtime Test
```

---

### Node.js가 범용 Runtime으로 발전한다

Node.js의 역할 변화를 보면 방향이 명확합니다.

초기에는

```text
JavaScript
    ↓
Server Runtime
```

이었다면,

점점

```text
JavaScript Runtime

├─ Server
├─ CLI
├─ Tooling
├─ Worker
├─ Web APIs
└─ Build Tools
```

형태로 확대되고 있습니다.

단순히 Express Server를 실행하기 위한 Runtime이라고 보기 어려워진 것입니다.

---

### Browser와 Server의 경계도 줄어든다

Web Standard API를 계속 지원하면서 Browser와 Node.js 사이의 개발 경험도 가까워지고 있습니다.

```text
Browser
   ↕
Web Standards
   ↕
Node.js
```

예를 들어 같은 `fetch()` API를 양쪽에서 사용할 수 있습니다.

```javascript
const response = await fetch('/api/users');
```

물론 Runtime 환경은 여전히 다릅니다.

```text
Browser

DOM
Window
User Interface


Node.js

File System
Process
Server
Network
```

하지만 공통으로 사용할 수 있는 기본 API 영역은 계속 확대되고 있습니다.

---

### Full Stack Framework에도 영향을 준다

Next.js 같은 Framework는 Browser와 Server 양쪽에서 Code가 실행됩니다.

```text
Next.js

├─ Client
└─ Server
```

Node.js가 Web Standard API를 더 많이 제공하면 Framework가 Client와 Server 사이에서 동일한 API를 사용하는 것도 쉬워집니다.

```text
Client
   ↓
Web API


Server
   ↓
Web API
```

Full Stack JavaScript Framework가 발전하기 좋은 기반이 되는 것입니다.

---

### Backend 개발자의 Mental Model도 단순해진다

과거에는 Runtime마다 별도의 API 사용법을 기억해야 했습니다.

```text
Browser

fetch()


Node.js

외부 HTTP Library
```

최근에는 다음처럼 공통적인 Programming Model을 사용할 수 있는 경우가 늘어납니다.

```text
JavaScript Developer
       ↓
Web Standard
       ↓
Browser / Server
```

특히 Frontend와 Backend를 모두 다루는 개발자에게는 의미가 큽니다.

---

### 왜 중요한가

Node.js 24의 중요성은 `URLPattern`이라는 API 하나가 추가됐다는 데만 있지 않습니다.

Node.js의 장기적인 방향이 계속 유지되고 있다는 점이 중요합니다.

```text
Node.js

과거

Server-specific Runtime


현재

Server Runtime
+
Web Standards
+
Developer Tooling
```

Browser JavaScript와 Node.js JavaScript 사이의 API 차이가 조금씩 줄어들면서 JavaScript Platform 전체가 점점 더 일관된 형태로 발전하고 있습니다.

---

### 실무 영향

NestJS, Express, Fastify, Next.js Backend 같은 Node Application에서는 Node Core에서 해결할 수 있는 영역이 계속 증가하고 있습니다.

```text
Node Core

fetch

WebSocket

URLPattern

Streams

Test Runner

Env File
```

따라서 새로운 Feature를 구현할 때 기존처럼 바로 npm Package를 찾기보다 **Node Runtime에서 이미 제공하는 기능인지 먼저 확인할 가치**가 커졌습니다.

Production에서는 당시 Node.js 24가 Current였기 때문에 다음과 같은 전략이 현실적이었습니다.

```text
Node.js 22 LTS

Production 유지
      ↓
Node.js 24

Development / CI 검증
      ↓
Framework / Dependency Compatibility 확인
      ↓
LTS 이후 Production Migration 검토
```

결국 Node.js 24는,

> **Node.js가 단순한 웹 서버용 JavaScript Runtime에서 Web Standard API와 자체 Tooling을 폭넓게 제공하는 범용 JavaScript Platform으로 계속 발전하고 있음을 보여주는 Release**

라고 볼 수 있습니다.

Backend 개발자 입장에서는 최신 Node API를 이해하는 것도 중요하지만 Production에서는 **LTS 정책과 Framework Compatibility를 함께 고려해 Runtime Upgrade를 관리하는 능력**이 더욱 중요해지고 있습니다.

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일(금) 주간 개발트렌드

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

## Cloud / DevOps — Kubernetes 1.33 출시

Kubernetes가 **25년 4월 23일 Kubernetes 1.33 Octarine**을 정식 출시했습니다.

이번 버전에는 총 **64개의 Enhancement**가 포함됐으며, 그중 **18개가 Stable 단계로 승격**됐습니다.

Kubernetes는 여전히 새로운 기능을 추가하고 있지만, 최근 Release의 핵심은 새로운 기능의 숫자보다 **기존 기능을 안정화하고 운영 환경에서 장기간 사용할 수 있도록 Platform을 성숙시키는 것**에 가까워지고 있습니다.

특히 Resource Management, Storage, Security, Scheduling 등 Kubernetes의 핵심 Infrastructure 영역이 지속적으로 개선되면서 Kubernetes가 새로운 Container Platform을 넘어 **Cloud-native Infrastructure의 사실상 표준 운영 Platform**으로 자리 잡았다는 흐름을 보여줬습니다.

[Kubernetes - Kubernetes v1.33: Octarine](https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/)

---

### Kubernetes의 Release Lifecycle

Kubernetes의 새로운 기능은 일반적으로 여러 단계를 거쳐 안정화됩니다.

```text
Alpha
  ↓
Beta
  ↓
Stable
```

각 단계는 단순한 Version 표시가 아니라 해당 기능의 성숙도를 의미합니다.

```text
Alpha

실험적인 기능
변경 가능성 높음
Production 사용 주의


Beta

기능이 어느 정도 안정화
API 변경 가능성 존재
실제 사용 사례 축적


Stable

Production 사용을 고려한 안정 단계
호환성과 장기적인 유지보수 중요
```

Kubernetes 1.33에서는 18개의 Enhancement가 Stable 단계로 이동했습니다.

이는 Kubernetes가 계속 기능을 추가하는 동시에 **기존 기능을 Production 수준으로 끌어올리는 작업에도 많은 비중을 두고 있다는 의미**입니다.

---

### 초기 Kubernetes

Kubernetes 초기에는 Container Orchestration 자체가 새로운 기술이었습니다.

당시 중요한 문제는 다음과 같았습니다.

```text
Container를 어떻게 배포할까?

Container가 죽으면 어떻게 복구할까?

Traffic은 어떻게 분산할까?

Container를 어떻게 Scale-out 할까?
```

Kubernetes는 이런 문제를 해결하기 위한 기능을 빠르게 추가했습니다.

```text
Pod

Deployment

Service

Ingress

ConfigMap

Secret

StatefulSet

DaemonSet
```

Platform 자체가 빠르게 확장되던 시기였습니다.

---

### 현재 Kubernetes

현재 Kubernetes는 이미 매우 많은 Production Infrastructure에서 사용되고 있습니다.

따라서 Platform의 우선순위도 달라집니다.

```text
초기

새로운 Feature
      ↓
Platform Capability 확대


현재

Stability
+
Compatibility
+
Security
+
Resource Management
+
Upgrade
```

새로운 기능을 추가하는 것만큼 **기존 Cluster를 안전하게 유지하고 Upgrade할 수 있는가**가 중요해진 것입니다.

---

### Kubernetes는 Infrastructure Platform이 됐다

Kubernetes를 단순한 Container Scheduler라고 보기에는 역할이 너무 커졌습니다.

```text
Kubernetes

├─ Scheduling
├─ Networking
├─ Storage
├─ Security
├─ Service Discovery
├─ Configuration
├─ Autoscaling
├─ Resource Management
└─ Extension API
```

그리고 Kubernetes 위에는 다양한 생태계가 올라옵니다.

```text
Kubernetes
   ↓
Cloud-native Ecosystem

├─ Argo CD
├─ Prometheus
├─ cert-manager
├─ Ingress Controller
├─ Service Mesh
├─ Operators
└─ Custom Resources
```

Kubernetes 자체의 Version 변경이 단순한 Package Upgrade가 아닌 이유입니다.

---

### Cluster Upgrade가 중요한 이유

Kubernetes는 일정한 Release Cycle을 가지고 지속적으로 새로운 Version을 공개합니다.

따라서 운영 Cluster도 언젠가는 Version을 올려야 합니다.

```text
Kubernetes 1.31
      ↓
Kubernetes 1.32
      ↓
Kubernetes 1.33
```

하지만 실제 Cluster에는 Kubernetes Core만 존재하지 않습니다.

```text
Cluster

├─ Kubernetes
├─ CNI
├─ CSI
├─ Ingress Controller
├─ Monitoring
├─ GitOps
├─ Operators
├─ CRD
└─ Workloads
```

Kubernetes Version을 바꾸면 이 전체 생태계의 Compatibility를 함께 확인해야 합니다.

---

### 신규 기능보다 Upgrade Strategy

Kubernetes가 성숙하면서 운영팀의 관심도 달라지고 있습니다.

초기에는 다음과 같은 질문이 중요했습니다.

```text
이번 Version에
무슨 기능이 추가됐지?
```

하지만 Production Cluster에서는 점점 다음 질문이 더 중요해집니다.

```text
현재 Version에서
안전하게 Upgrade 가능한가?

Deprecated API는 무엇인가?

삭제되는 기능은 있는가?

CNI와 CSI는 호환되는가?

Ingress Controller는 지원하는가?

Operator는 정상 동작하는가?
```

즉 관심의 중심이 Feature Adoption에서 **Lifecycle Management**로 이동합니다.

---

### API Deprecation

Kubernetes Upgrade에서 특히 중요한 것이 **API Deprecation**입니다.

Kubernetes Resource는 `apiVersion`을 사용합니다.

```yaml
apiVersion: apps/v1
kind: Deployment
```

새로운 API가 등장하면서 기존 API Version이 Deprecated될 수 있습니다.

```text
v1beta1
   ↓
Deprecated
   ↓
Removed
```

문제는 Deprecated된 API가 완전히 제거되면 기존 Manifest가 더 이상 동작하지 않을 수 있다는 점입니다.

```text
Old Cluster

v1beta1
   ↓
정상 동작


New Cluster

v1beta1
   ↓
Removed
   ↓
Deployment 실패
```

---

### Deprecated와 Removed는 다르다

Deprecated됐다고 바로 사용할 수 없는 것은 아닙니다.

```text
Deprecated

현재는 사용 가능
하지만 향후 제거 예정
```

반면 Removed 상태가 되면 실제로 사용할 수 없습니다.

```text
Removed

API Server에서 지원하지 않음
```

따라서 Kubernetes Upgrade를 준비할 때는 **현재 Deprecated된 API뿐 아니라 Target Version에서 실제 제거되는 API까지 확인해야 합니다.**

---

### Helm Chart도 확인해야 한다

Application Manifest를 직접 관리하지 않고 Helm을 사용하는 조직도 많습니다.

```text
Application
    ↓
Helm Chart
    ↓
Kubernetes Resource
```

Helm Chart 안에서도 Kubernetes API Version을 사용합니다.

따라서 Cluster Version이 올라가면 Chart Compatibility도 확인해야 합니다.

```text
Kubernetes Upgrade
       ↓
Helm Chart 확인
       ↓
Deprecated API 확인
       ↓
Chart Upgrade
```

Application Code가 바뀌지 않았더라도 Deployment Configuration 때문에 문제가 발생할 수 있습니다.

---

### CRD Compatibility

Kubernetes는 CRD(Custom Resource Definition)를 통해 Platform 기능을 확장할 수 있습니다.

```text
Kubernetes 기본 Resource

Pod
Deployment
Service

        +

Custom Resource

Application
Certificate
ServiceMonitor
etc.
```

예를 들어 Argo CD는 `Application`, Prometheus Operator는 `ServiceMonitor` 같은 Custom Resource를 사용합니다.

```text
Kubernetes
    ↓
CRD
    ↓
Custom Controller
```

Cluster Version을 Upgrade할 때는 이런 CRD와 Controller의 Compatibility도 확인해야 합니다.

---

### Controller Compatibility

Kubernetes 환경에는 수많은 Controller가 존재할 수 있습니다.

```text
Controllers

├─ Ingress Controller
├─ cert-manager
├─ Prometheus Operator
├─ Argo CD
├─ External Secrets
└─ Custom Operator
```

Kubernetes 자체가 정상적으로 Upgrade됐더라도 Controller가 새로운 Version을 지원하지 않으면 문제가 발생할 수 있습니다.

```text
Kubernetes Upgrade
       ↓
Controller Compatibility 문제
       ↓
Resource Reconciliation 실패
```

따라서 Platform Engineer는 Kubernetes뿐 아니라 주변 생태계 전체의 Version Matrix를 관리해야 합니다.

---

### CNI

CNI(Container Network Interface)는 Kubernetes Networking을 담당합니다.

대표적으로 다음과 같은 Solution이 있습니다.

```text
CNI

Calico

Cilium

Flannel

Cloud Provider CNI
```

Pod Networking은 Cluster의 핵심 기능이기 때문에 CNI 문제가 발생하면 전체 Application 통신에 영향을 줄 수 있습니다.

```text
Pod A
  ↓
Network
  ↓
Pod B
```

Cluster Upgrade 전에 CNI가 Target Kubernetes Version을 지원하는지 확인하는 것이 중요합니다.

---

### CSI

Storage 역시 마찬가지입니다.

Kubernetes에서는 CSI(Container Storage Interface)를 통해 Storage Provider와 연결합니다.

```text
Pod
 ↓
PVC
 ↓
CSI
 ↓
Storage
```

Database나 Stateful Workload가 존재한다면 CSI Compatibility 문제는 더욱 중요합니다.

```text
Database Pod
     ↓
Persistent Volume
     ↓
Storage
```

Storage 문제는 단순 Application Restart보다 훨씬 큰 장애로 이어질 수 있기 때문입니다.

---

### Resource Management

Kubernetes가 성숙하면서 Resource Management 역시 계속 발전하고 있습니다.

기본 Resource는 다음과 같습니다.

```text
CPU

Memory
```

Pod에서 요청과 제한을 정의합니다.

```yaml
resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"
```

Scheduler는 이 정보를 기준으로 Pod를 적절한 Node에 배치합니다.

```text
Pod Resource Request
        ↓
Scheduler
        ↓
Node 선택
```

---

### Resource 관리가 중요한 이유

Resource 설정이 잘못되면 Cluster 운영에 직접적인 문제가 생길 수 있습니다.

Requests가 너무 크면,

```text
Resource 과다 요청
      ↓
Pod Scheduling 어려움
      ↓
Cluster Resource 낭비
```

반대로 너무 작으면,

```text
Resource 부족
      ↓
CPU Throttling

또는

OOMKill
```

문제가 발생할 수 있습니다.

Kubernetes Platform이 성숙하면서 단순히 Pod를 실행하는 것보다 **Cluster Resource를 얼마나 효율적으로 활용하는가**가 중요해지고 있습니다.

---

### Storage 기능의 성숙

초기 Kubernetes는 Stateless Web Application에 특히 적합하다는 이미지가 강했습니다.

```text
Web App
 ↓
Pod
 ↓
Stateless
```

하지만 StatefulSet, Persistent Volume, CSI 등이 발전하면서 Database나 Stateful Workload도 Kubernetes에서 운영하는 사례가 증가했습니다.

```text
Kubernetes

├─ Web
├─ Backend
├─ Queue
├─ Search
└─ Stateful Workload
```

따라서 Storage의 안정성과 Lifecycle도 Kubernetes Release에서 중요한 영역이 됐습니다.

---

### Security도 Platform 기본 기능이다

Kubernetes Cluster는 수많은 Workload와 Secret, Network Resource를 관리합니다.

```text
Cluster

├─ Application
├─ Database Credential
├─ API Token
├─ Service Account
└─ Network
```

따라서 Kubernetes Security는 별도의 부가 기능이 아니라 Platform 자체의 핵심 영역입니다.

주요 개념은 다음과 같습니다.

```text
RBAC

Service Account

Pod Security

Network Policy

Secrets

Admission Control
```

Kubernetes Version이 발전하면서 Security Model 역시 지속적으로 정리되고 강화됩니다.

---

### Version Skew

Kubernetes Upgrade에서는 Control Plane과 Node Component 사이의 Version Compatibility도 고려해야 합니다.

```text
Control Plane
     ↓
kubelet
     ↓
Node
```

모든 Component를 아무 Version 조합으로 사용할 수 있는 것은 아닙니다.

따라서 Upgrade 순서와 지원되는 Version Skew를 확인해야 합니다.

```text
Control Plane Upgrade
        ↓
Node Upgrade
        ↓
Addon Upgrade
```

Managed Kubernetes라고 하더라도 이런 Lifecycle 자체가 완전히 사라지는 것은 아닙니다.

---

### Managed Kubernetes도 Upgrade가 필요하다

EKS, GKE, AKS 같은 Managed Kubernetes를 사용하면 Control Plane 관리 부담은 줄어듭니다.

```text
Cloud Provider
      ↓
Managed Control Plane
```

하지만 Application과 Add-on Compatibility까지 Cloud Provider가 자동으로 해결해주는 것은 아닙니다.

```text
Managed Kubernetes Upgrade
         ↓
Application
CNI
CSI
Ingress
CRD
Controller
```

따라서 Managed Kubernetes에서도 Upgrade Planning은 여전히 필요합니다.

---

### Production Cluster Upgrade Workflow

실제 운영 환경에서는 다음과 같은 흐름을 사용할 수 있습니다.

```text
Release Note 확인
      ↓
Deprecated / Removed API 확인
      ↓
CNI / CSI Compatibility 확인
      ↓
Controller / Operator 확인
      ↓
Helm / Manifest 확인
      ↓
Development Cluster Upgrade
      ↓
Staging 검증
      ↓
Production Upgrade
      ↓
Monitoring
```

Version 숫자만 변경하는 작업이 아니라 **전체 Platform Compatibility를 검증하는 과정**입니다.

---

### Pre-upgrade Check

Upgrade 전에 자동화된 검사 Tool을 사용할 수도 있습니다.

예를 들어 Repository에서 사용 중인 Kubernetes Resource를 분석해 Deprecated API를 탐지할 수 있습니다.

```text
Git Repository
      ↓
Manifest Scan
      ↓
Deprecated API
      ↓
Upgrade 전에 수정
```

GitOps 환경이라면 특히 효과적입니다.

```text
Git
 ↓
Manifest
 ↓
Argo CD
 ↓
Kubernetes
```

Cluster에 적용되기 전에 Configuration 단계에서 문제를 발견할 수 있기 때문입니다.

---

### GitOps와 Upgrade

GitOps 환경에서는 Infrastructure와 Application Configuration이 Git Repository에 존재합니다.

```text
Git
 ↓
Desired State
 ↓
Argo CD
 ↓
Cluster
```

Kubernetes Upgrade를 준비할 때도 Manifest와 Helm Chart를 먼저 수정할 수 있습니다.

```text
Target Version 분석
        ↓
Git 변경
        ↓
Review
        ↓
Staging
        ↓
Production
```

Cluster Lifecycle 역시 Code Review와 자동화된 Workflow 안으로 들어오는 것입니다.

---

### Rollback도 중요하다

Upgrade는 항상 성공한다는 보장이 없습니다.

```text
Upgrade
 ↓
Problem
 ↓
Rollback?
```

Kubernetes에서는 Component와 API 변화 때문에 단순 Downgrade가 항상 쉬운 것은 아닙니다.

따라서 Upgrade 전에

```text
Backup

etcd Strategy

Application Rollback

Node Rollout Strategy

Disaster Recovery
```

등을 준비해야 합니다.

---

### 신규 기능보다 운영 능력이 중요해진다

Kubernetes가 성숙하면서 기술 역량의 기준도 조금씩 달라집니다.

초기에는

```text
Deployment 만들기

Service 만들기

Ingress 만들기
```

정도를 알아도 Kubernetes를 사용할 수 있었습니다.

Production 환경에서는 훨씬 많은 것을 이해해야 합니다.

```text
Kubernetes Operations

├─ Upgrade
├─ Resource Management
├─ Networking
├─ Storage
├─ Security
├─ Observability
├─ Backup
└─ Failure Recovery
```

Kubernetes를 **사용할 줄 아는 것과 운영할 줄 아는 것은 다른 문제**가 된 것입니다.

---

### Platform Engineering과 Kubernetes

최근 Kubernetes 운영은 점점 Platform Engineering 영역으로 이동하고 있습니다.

개별 개발자가 Kubernetes Resource를 모두 직접 다루기보다 Platform Team이 공통 환경을 제공합니다.

```text
Platform Team

Kubernetes
+
CI/CD
+
GitOps
+
Observability
+
Security
+
Developer Platform
```

Application Team은 그 위에서 서비스를 배포합니다.

```text
Developer
    ↓
Internal Platform
    ↓
Kubernetes
```

Kubernetes가 Infrastructure 내부 구현으로 내려가는 방향입니다.

---

### Kubernetes가 인프라 표준이 됐다는 의미

기술이 성숙하면 사용자가 내부 구현을 덜 신경 쓰게 되는 경우가 많습니다.

```text
초기

Kubernetes 자체가 Product


성숙

Kubernetes가 Platform 기반
```

새로운 서비스를 만들 때 Kubernetes 자체를 도입하는 것이 프로젝트의 목표가 아니라,

```text
서비스를 안정적으로 운영하기 위한
Infrastructure 기반
```

으로 사용하는 것입니다.

---

### Feature Competition에서 Lifecycle Management로

Kubernetes의 변화는 다음처럼 정리할 수 있습니다.

```text
초기

새 기능
+
빠른 Platform 확장


현재

Stable Feature
+
Compatibility
+
Security
+
Upgrade
+
Operations
```

Platform이 성숙할수록 Feature 숫자보다 **운영 안정성과 Lifecycle 관리 능력**이 더 중요해집니다.

---

### 개발자에게도 영향을 준다

Cluster Upgrade는 Platform Engineer만의 문제는 아닙니다.

Application 개발자가 작성한 Manifest나 Helm Chart도 영향을 받을 수 있습니다.

```text
Application
    ↓
Deployment / Service
    ↓
Kubernetes API
```

Deprecated API를 사용하거나 오래된 Chart에 의존하고 있다면 Platform Upgrade가 막힐 수 있습니다.

따라서 Application Team도 최소한 다음 요소는 관리할 필요가 있습니다.

```text
Manifest Version

Helm Chart

Resource Requests

Health Check

Security Context
```

Infrastructure와 Application 사이의 책임이 완전히 분리되는 것은 아닙니다.

---

### 왜 중요한가

Kubernetes 1.33의 핵심 의미는 특정 Feature 하나에 있지 않습니다.

총 64개의 Enhancement가 진행되고 18개가 Stable 단계로 이동했다는 것은 Kubernetes가 계속 발전하면서도 **많은 기능을 안정적인 Production 기능으로 정착시키고 있다는 흐름**을 보여줍니다.

Kubernetes의 역할도 다음처럼 변해왔습니다.

```text
초기

Container Scheduler


이후

Container Orchestrator


현재

Cloud-native Infrastructure Platform
```

그리고 Platform이 성숙하면서 운영자의 관심도 달라졌습니다.

```text
새 기능 도입

보다

Version Policy
+
API Compatibility
+
Cluster Upgrade
```

가 더 중요해지고 있습니다.

---

### 실무 영향

Kubernetes 1.33 같은 새로운 Version이 출시됐을 때 Production 운영팀이 가장 먼저 해야 할 일은 새로운 기능을 전부 적용하는 것이 아닙니다.

다음 항목을 먼저 확인하는 것이 중요합니다.

```text
Target Kubernetes Version

        ↓

Deprecated API

Removed Feature

CNI Compatibility

CSI Compatibility

Ingress Controller

Operator / CRD

Helm Chart

Monitoring Stack
```

그리고 단계적으로 Upgrade합니다.

```text
Development
    ↓
Staging
    ↓
Production
```

결국 Kubernetes 1.33은,

> **Kubernetes가 빠르게 기능을 추가하는 초기 Container Platform에서 안정적인 Lifecycle과 Compatibility를 관리해야 하는 성숙한 Infrastructure Standard로 이동했음을 보여주는 Release**

라고 볼 수 있습니다.

Kubernetes 운영에서 중요한 역량 역시 새로운 YAML Syntax를 많이 아는 것보다 **Version Policy를 이해하고, Deprecated API를 관리하며, Cluster와 주변 Ecosystem을 안전하게 Upgrade할 수 있는 능력**으로 이동하고 있습니다.

개발트렌드

이 주제의 기록