2024년 11월 29일(금) 주간 개발트렌드

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


# 2024년 11월 22일(금) 주간 트렌드

## Backend — Spring Boot 3.4 출시

Spring이 **11월 21일 Spring Boot 3.4**를 정식 출시했습니다.

이번 버전에는 **Structured Logging, Virtual Thread 지원 확대, Docker Compose와 Testcontainers 개선, ARM Container Image Build 지원, Actuator 개선** 등이 포함됐습니다.

특히 Java 21에서 등장하거나 강화된 기능들이 Spring 생태계에 점점 자연스럽게 통합되면서 **Java Platform의 변화가 실제 Backend 개발 경험으로 내려오기 시작했다는 점**이 중요했습니다.

[Spring - Spring Boot 3.4.0 Available Now](https://spring.io/blog/2024/11/21/spring-boot-3-4-0-available-now/)

---

### Java 21 이후의 Spring

Spring Boot는 Java Platform 위에서 동작합니다.

```text
Spring Boot
     ↓
Java
     ↓
JVM
```

따라서 Java Runtime과 Language가 발전하면 Spring에서도 해당 기능을 Application 개발자가 쉽게 사용할 수 있도록 지원해야 합니다.

Java 21 이후 특히 중요한 변화 중 하나가 **Virtual Thread**였습니다.

```text
Java 21
   ↓
Virtual Thread
   ↓
Spring Boot
   ↓
Backend Application
```

Spring Boot 3.4에서는 이러한 최신 Java 기능들이 Framework 내부에 더욱 자연스럽게 녹아들고 있었습니다.

---

### Structured Logging

Spring Boot 3.4에서 특히 눈에 띄는 기능 중 하나가 **Structured Logging**입니다.

기존 Application Log는 일반적으로 문자열 중심으로 작성됐습니다.

```text
User login failed: id=10
```

사람이 읽기에는 어렵지 않지만 Log System에서 데이터를 추출하려면 Parsing이 필요합니다.

```text
Log String
   ↓
Parser
   ↓
Field Extraction
   ↓
Search
```

Structured Logging에서는 Log 자체를 구조화된 데이터 형태로 기록합니다.

```json
{
  "event": "LOGIN_FAILED",
  "userId": 10
}
```

이렇게 되면 각 정보가 명확한 Field로 존재합니다.

---

### 문자열 Log의 문제

운영 환경에서 다음과 같은 Log가 수백만 건 쌓인다고 가정할 수 있습니다.

```text
2024-11-21 User login failed: id=10
2024-11-21 User login failed: id=20
2024-11-21 Payment failed: order=300
```

사용자 ID를 검색하려면 Log Format을 알고 Parsing해야 합니다.

```text
Raw Log
   ↓
Regex / Parser
   ↓
userId
```

Log Format이 변경되면 Parser 역시 수정해야 할 수 있습니다.

---

### Structured Log

구조화된 Log에서는 각 값이 명확한 Field로 저장됩니다.

```json
{
  "timestamp": "...",
  "level": "WARN",
  "event": "LOGIN_FAILED",
  "userId": 10
}
```

이 경우 Log Platform에서 바로 Field를 기준으로 Query할 수 있습니다.

```text
event = LOGIN_FAILED

userId = 10

level = ERROR
```

Observability 환경에서는 훨씬 다루기 쉬운 형태입니다.

---

### Observability와 연결

현대 Backend Application에서는 Log가 단순히 Terminal에 출력되는 문자열이 아닙니다.

```text
Application
     ↓
Logs
     ↓
Log Collector
     ↓
Observability Platform
```

예를 들어 다음과 같은 Stack을 사용할 수 있습니다.

```text
Spring Boot
    ↓
Container
    ↓
Kubernetes
    ↓
Log Collector
    ↓
Elasticsearch / Loki
    ↓
Grafana / Kibana
```

Structured Logging을 사용하면 이 Pipeline에서 별도의 복잡한 Parsing 과정을 줄일 수 있습니다.

---

### Kubernetes에서 특히 중요한 이유

Container 환경에서는 Application Log를 중앙화하는 것이 일반적입니다.

```text
Pod A ─┐
Pod B ─┼→ Log Collector → Central Logging
Pod C ─┘
```

수십 개 또는 수백 개의 Pod가 동시에 Log를 생성하면 사람이 각각의 Log를 직접 보는 것은 현실적이지 않습니다.

따라서 다음과 같은 Field 기반 검색이 중요합니다.

```text
service.name

trace.id

user.id

request.id

error.code
```

Structured Logging은 이러한 Cloud-native Observability와 잘 맞습니다.

---

### Virtual Thread

Spring Boot 3.4에서는 **Virtual Thread 지원도 계속 개선**됐습니다.

기존 Java Thread는 OS Thread와 밀접하게 연결돼 있기 때문에 매우 많은 Thread를 생성하면 Resource 부담이 커질 수 있습니다.

```text
Request
  ↓
Platform Thread
  ↓
OS Thread
```

Virtual Thread는 JVM이 훨씬 가벼운 Thread를 관리하도록 만드는 방식입니다.

```text
Request A → Virtual Thread
Request B → Virtual Thread
Request C → Virtual Thread
Request D → Virtual Thread

          ↓

        JVM
          ↓
소수의 OS Thread
```

Blocking 기반 코드를 유지하면서도 높은 Concurrency를 처리할 수 있는 선택지가 생긴 것입니다.

---

### Reactive Programming과 다른 접근

Java Backend에서 많은 Concurrent Request를 처리하기 위한 대표적인 접근 중 하나가 Reactive Programming이었습니다.

```text
Spring WebFlux
      ↓
Non-blocking
      ↓
Event Loop
```

높은 효율을 얻을 수 있지만 Programming Model이 기존 MVC 방식과 상당히 다릅니다.

```text
Imperative

Controller
 ↓
Service
 ↓
Repository


Reactive

Mono
Flux
Pipeline
```

Virtual Thread는 다른 방향을 제공합니다.

```text
기존 Blocking Code
        +
Virtual Thread
        ↓
높은 Concurrency
```

기존 Spring MVC Programming Model을 유지하면서도 많은 Concurrent Task를 처리할 수 있는 가능성이 커진 것입니다.

---

### Virtual Thread가 항상 정답은 아니다

Virtual Thread가 등장했다고 해서 모든 Backend Application에서 기존 Thread Model을 바로 교체해야 하는 것은 아닙니다.

다음과 같은 요소를 확인해야 합니다.

- Blocking I/O 비율
- Database Connection Pool
- External API
- ThreadLocal 사용
- Library Compatibility
- CPU-bound Workload
- Monitoring

예를 들어 Virtual Thread를 수천 개 생성할 수 있다고 하더라도 Database Connection이 30개라면 Database 처리량 자체가 자동으로 수천 배 증가하는 것은 아닙니다.

```text
10000 Virtual Threads
        ↓
30 DB Connections
        ↓
실제 DB 동시 처리 = 제한
```

Application 전체 Architecture를 함께 봐야 합니다.

---

### Docker Compose 개선

Spring Boot는 Docker Compose Integration도 계속 강화하고 있습니다.

Local Development에서 Backend Application은 보통 여러 Infrastructure Service가 필요합니다.

```text
Spring Boot
    +
PostgreSQL
    +
Redis
    +
Kafka
```

기존에는 개발자가 각각의 Connection 정보를 직접 설정해야 했습니다.

```text
docker compose up

        ↓

Host 확인
Port 확인
Credential 확인

        ↓

application.yml 설정
```

Spring Boot는 Docker Compose 환경을 인식해 이런 Local Development 과정을 단순화하는 방향으로 발전하고 있습니다.

---

### Testcontainers

Integration Test에서는 실제 Database나 Infrastructure 환경이 필요할 수 있습니다.

```text
Test
 ↓
PostgreSQL
Redis
Kafka
```

Mock으로 모든 것을 대체하면 실제 Production 환경과 다른 결과가 나올 수도 있습니다.

Testcontainers는 Test 실행 과정에서 Container를 생성해 실제 Infrastructure에 가까운 환경을 제공합니다.

```text
Integration Test
      ↓
Testcontainers
      ↓
PostgreSQL Container
      ↓
Test
      ↓
Container 제거
```

Spring Boot가 Testcontainers Integration을 계속 개선하면서 Integration Test 환경 구성도 점점 단순해지고 있습니다.

---

### Local과 Production의 차이를 줄인다

Docker Compose와 Testcontainers 지원의 핵심은 **개발 환경과 실제 Infrastructure 사이의 차이를 줄이는 것**입니다.

```text
Local

Docker Compose


Test

Testcontainers


Production

Container / Kubernetes
```

모든 환경에서 Container 기반 Infrastructure를 사용하면 환경 차이 때문에 발생하는 문제를 줄일 수 있습니다.

```text
Works on my machine
        ↓
환경 차이 감소
```

Cloud-native Application 개발 방식이 Spring Boot의 기본 Developer Experience 안으로 들어오는 것입니다.

---

### ARM Container Image Build

ARM Architecture의 사용도 계속 늘어나고 있습니다.

대표적으로 다음과 같은 환경입니다.

```text
Apple Silicon
AWS Graviton
ARM Server
```

Cloud Provider 역시 ARM 기반 Instance를 적극적으로 제공하고 있습니다.

```text
Application
    ↓
Container
    ↓
ARM64
```

Spring Boot 3.4에서 ARM Container Image Build 지원이 개선되면서 이러한 환경에 Application을 배포하는 과정도 단순해졌습니다.

---

### Actuator

Spring Boot Actuator는 Production Application의 상태와 Metric을 확인하는 기능을 제공합니다.

```text
Spring Boot
    ↓
Actuator

├─ Health
├─ Metrics
├─ Info
├─ Environment
└─ Prometheus
```

Cloud-native 환경에서는 Application이 정상적으로 동작하는지 Platform이 판단해야 합니다.

예를 들어 Kubernetes에서는 다음과 같은 Probe가 중요합니다.

```text
Liveness Probe
Readiness Probe
```

Spring Boot Actuator는 이런 운영 환경과 Application을 연결하는 중요한 역할을 합니다.

---

### Observability가 기본 기능이 된다

과거 Backend Application에서는 Logging과 Monitoring이 Application 개발 이후에 추가되는 기능처럼 취급되는 경우도 있었습니다.

```text
Application 개발
      ↓
Deployment
      ↓
나중에 Monitoring 추가
```

하지만 Cloud-native 환경에서는 Observability 자체가 Application Architecture의 일부가 됩니다.

```text
Application

├─ Logs
├─ Metrics
├─ Traces
└─ Health
```

Spring Boot 역시 이러한 기능을 Framework 내부에서 기본적으로 지원하는 방향으로 발전하고 있습니다.

---

### OpenTelemetry와의 흐름

Modern Observability에서는 Log 하나만 보는 것이 아니라 **Trace, Metric, Log를 연결해서 보는 것**이 중요합니다.

```text
Request
   ↓
Trace ID
   ↓
Service A
   ↓
Service B
   ↓
Database
```

문제가 발생했을 때 동일한 Trace ID를 기반으로 전체 요청 흐름을 추적할 수 있습니다.

```text
Trace
+
Metric
+
Log
```

Structured Logging 역시 이런 Observability Architecture와 잘 맞습니다.

---

### 왜 중요한가

Spring Boot 3.4의 변화들을 보면 하나의 공통적인 흐름이 보입니다.

```text
Modern Java
+
Cloud-native
+
Observability
+
Container
```

Java 자체에서 Virtual Thread 같은 기능이 등장하고,

Infrastructure에서는 Container와 Kubernetes가 보편화됐으며,

운영에서는 Structured Logging과 Observability가 중요해졌습니다.

Spring Boot는 이러한 변화를 Application Developer가 쉽게 사용할 수 있도록 Framework 안으로 흡수하고 있습니다.

---

### 과거의 Spring Backend

전통적인 Spring Backend를 단순화하면 다음과 같았습니다.

```text
Spring MVC
    ↓
Tomcat
    ↓
Database
```

최근 Spring Boot Application은 훨씬 많은 Infrastructure와 연결됩니다.

```text
Spring Boot

├─ Virtual Threads
├─ Containers
├─ Kubernetes
├─ Observability
├─ Metrics
├─ Tracing
├─ Structured Logs
└─ Cloud Services
```

Spring Boot 자체가 단순 Web Framework를 넘어 **Production Backend Application Platform**에 가까워지고 있습니다.

---

### Backend 개발자에게 중요한 변화

Spring Backend 개발자 역시 이제 Controller와 Service만 구현하는 것으로 끝나지 않습니다.

```text
Backend Developer

Application Code
+
Database
+
Concurrency
+
Container
+
Observability
+
Infrastructure
```

특히 다음 기술들이 서로 연결됩니다.

```text
Java 21
   ↓
Virtual Thread

Spring Boot
   ↓
Application

Docker
   ↓
Container

Kubernetes
   ↓
Deployment

OpenTelemetry
   ↓
Observability
```

Framework 기능을 이해하는 것뿐 아니라 **Application이 Production에서 어떻게 실행되는지까지 이해하는 것**이 점점 중요해지고 있습니다.

---

### 실무 영향

Spring Boot 3.4에서는 다음과 같은 Modern Backend 환경을 보다 자연스럽게 구성할 수 있게 됐습니다.

```text
Spring Boot 3.4

├─ Structured Logging
├─ Virtual Threads
├─ Docker Compose
├─ Testcontainers
├─ ARM Container
└─ Actuator
```

개발 환경에서는

```text
Docker Compose
+
Testcontainers
```

를 활용해 Infrastructure 구성과 Integration Test를 단순화하고,

운영 환경에서는

```text
Structured Logging
+
Actuator
+
Observability
```

를 통해 Monitoring과 Troubleshooting을 개선할 수 있습니다.

그리고 Java 21의 Virtual Thread를 활용해 기존 Imperative Programming Model을 유지하면서 높은 Concurrency를 처리하는 방식도 점점 현실적인 선택지가 됐습니다.

결국 Spring Boot 3.4는,

> **Java 21과 Cloud-native Infrastructure의 기능들이 Spring Backend 개발자의 기본 개발 경험으로 흡수되고 있음을 보여주는 Release**

라고 볼 수 있습니다.

2024년 11월 22일(금) 주간 개발트렌드

독자의 메모