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

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

## Backend — Java 24 출시

Oracle이 **25년 3월 18일 JDK 24**를 GA로 공개했습니다.

Java 24에는 총 **24개의 JEP(Java Enhancement Proposal)**가 포함됐으며, Language Feature와 API뿐 아니라 JVM 성능, Garbage Collection, Startup, Security까지 Java Platform 전반에 걸친 개선이 이루어졌습니다.

Java가 이미 성숙한 언어임에도 6개월 Release Cadence를 유지하면서 **Pattern Matching, Constructor 문법, Concurrency, JVM 내부 구조 같은 영역을 지속적으로 현대화하고 있다는 점**을 보여주는 Release였습니다.

다만 Java 24는 **LTS(Long-Term Support)가 아닌 Feature Release**였습니다.

따라서 Spring 기반 기업 서비스에서 Java 21 LTS를 바로 Java 24로 교체하기보다는 새로운 기능을 검증하고 차기 LTS로 이어질 변화를 미리 확인하는 용도로 접근하는 것이 현실적인 시점이었습니다.

[Oracle - The Arrival of Java 24](https://blogs.oracle.com/java/the-arrival-of-java-24)

---

### Java의 6개월 Release Cycle

과거 Java의 Major Version은 상당한 간격을 두고 등장했습니다.

```text
Java 6
  ↓
Java 7
  ↓
Java 8
```

새로운 Language Feature를 사용하려면 몇 년을 기다려야 하는 경우도 있었습니다.

하지만 현재 Java는 **6개월 단위 Feature Release**를 유지하고 있습니다.

```text
Java 21 LTS
     ↓
Java 22
     ↓
Java 23
     ↓
Java 24
     ↓
Java 25 LTS
```

새로운 기능을 작은 단위로 지속적으로 공개하고 개발자의 Feedback을 받아 다음 Release에서 발전시키는 방식입니다.

---

### Preview 기능이 반복적으로 발전한다

최근 Java 기능 중 상당수는 한 번에 Final Feature로 들어오지 않습니다.

```text
Proposal
   ↓
Preview
   ↓
Developer Feedback
   ↓
2nd Preview
   ↓
추가 개선
   ↓
Final
```

이 방식을 통해 실제 개발자가 새로운 기능을 사용해보고 API나 Syntax에 대한 Feedback을 제공할 수 있습니다.

Java 24에서도 이전 Version에서 Preview였던 여러 기능이 수정된 형태로 다시 등장했습니다.

---

### Pattern Matching의 지속적인 확장

Modern Java에서 가장 큰 Language 변화 중 하나는 **Pattern Matching**입니다.

과거에는 Type을 검사하고 Casting하는 Code가 반복되는 경우가 많았습니다.

```java
if (value instanceof String) {
    String text = (String) value;

    System.out.println(text.length());
}
```

최근 Java에서는 다음과 같이 작성할 수 있습니다.

```java
if (value instanceof String text) {
    System.out.println(text.length());
}
```

Pattern Matching은 이후 `switch`, Record Pattern 등으로 계속 확장됐습니다.

```text
Pattern Matching

instanceof
    ↓
switch
    ↓
Record
    ↓
Primitive Type
```

Java 24에서도 **Primitive Type을 Pattern Matching에 통합하려는 작업**이 이어졌습니다.

---

### Primitive Type Pattern

기존 Pattern Matching은 주로 Reference Type을 중심으로 발전했습니다.

```java
if (value instanceof Integer number) {
    // ...
}
```

하지만 Java의 Type System에는 Primitive Type도 존재합니다.

```text
int
long
double
float
boolean
```

Java는 Pattern Matching을 Language 전반에 일관되게 적용하기 위해 Primitive Type까지 지원 범위를 확장하는 방향으로 발전하고 있습니다.

```text
Reference Type
      +
Primitive Type
      ↓
Unified Pattern Matching
```

단순 Syntax Sugar가 아니라 **Java Type System 자체를 보다 일관되게 만드는 장기적인 변화**입니다.

---

### Constructor 문법 개선

Java Constructor에서도 오래된 제약을 개선하려는 작업이 이어졌습니다.

기존 Java에서는 `super()`나 `this()` 호출 전에 Statement를 작성할 수 없었습니다.

```java
class Child extends Parent {

    Child(int value) {
        super(value);
    }
}
```

Constructor에서 값을 검증하거나 계산해야 하는 경우 별도의 Method를 사용하는 등의 우회가 필요할 수 있었습니다.

새로운 Constructor 관련 개선은 `super()` 호출 이전에도 제한된 형태로 Logic을 수행할 수 있도록 Language Rule을 개선하는 방향입니다.

```text
기존

Constructor
   ↓
super()
   ↓
Initialization Logic


새로운 방향

일부 Validation / Calculation
   ↓
super()
   ↓
Initialization
```

Java가 기존 호환성을 유지하면서도 오래된 Language 제약을 점진적으로 제거하고 있는 사례입니다.

---

### Java 문법이 점점 간결해진다

최근 Java Release를 보면 반복적으로 등장하는 방향이 있습니다.

```text
과거 Java

Verbose
+
Boilerplate
```

에서

```text
Modern Java

Records
+
Pattern Matching
+
var
+
Switch Expression
+
Sealed Classes
```

방향으로 발전하고 있습니다.

Java가 동적 언어처럼 완전히 간결한 Syntax를 추구하는 것은 아니지만 **Static Type Safety를 유지하면서 불필요한 Boilerplate를 줄이는 방향**은 명확합니다.

---

### JVM 내부 개선도 계속된다

Java Version Update에서 Language Syntax만 보면 전체 변화의 절반만 보는 것입니다.

Java Application은 결국 JVM 위에서 실행됩니다.

```text
Spring Boot
     ↓
Java Bytecode
     ↓
JVM
     ↓
Operating System
```

따라서 다음 요소도 Backend Performance에 직접적인 영향을 줍니다.

```text
JVM

├─ JIT
├─ Garbage Collector
├─ Memory Layout
├─ Class Loading
├─ Startup
└─ Runtime Optimization
```

Java 24에서도 JVM 내부 성능과 Runtime 구조를 개선하기 위한 여러 JEP가 포함됐습니다.

---

### Compact Object Headers

Java Object는 실제 Field 데이터만 Memory에 가지고 있는 것이 아닙니다.

JVM이 Object를 관리하기 위한 Header 정보도 존재합니다.

```text
Java Object

├─ Object Header
└─ Object Data
```

Application에서 Object가 매우 많이 생성되면 각각의 Object Header도 상당한 Memory를 사용합니다.

```text
Millions of Objects
        ↓
Object Header × Millions
        ↓
Memory Usage
```

Java 24에서는 **Compact Object Headers** 같은 JVM 개선도 실험적인 형태로 진행됐습니다.

Object의 Memory Overhead를 줄이는 것은 대규모 Java Application의 Heap 효율과도 연결될 수 있습니다.

---

### Garbage Collector도 계속 발전한다

Java의 강점 중 하나는 오랫동안 다양한 GC를 발전시켜 왔다는 점입니다.

```text
Java GC

├─ G1
├─ ZGC
└─ Shenandoah
```

Application 특성에 따라 Throughput이나 Pause Time 등 서로 다른 목표를 선택할 수 있습니다.

Backend Application에서는 GC가 Latency에 영향을 줄 수 있습니다.

```text
많은 Object 생성
       ↓
Heap 증가
       ↓
GC
       ↓
Pause / CPU Cost
```

따라서 GC 개선 역시 Java Backend Performance의 중요한 부분입니다.

---

### Generational GC 방향

대부분의 Object는 생성된 뒤 비교적 빠르게 사용되지 않게 됩니다.

```text
Object 생성
   ↓
짧게 사용
   ↓
Garbage
```

이를 **Generational Hypothesis**라고 합니다.

그래서 Heap을 세대 단위로 나누면 GC를 더 효율적으로 수행할 수 있습니다.

```text
Heap

Young Generation

Old Generation
```

Java Runtime 역시 여러 Collector에서 이런 Generational Architecture를 적용하거나 확장하는 방향으로 발전하고 있습니다.

---

### Startup Performance

Java는 전통적으로 Startup Time이 Native Application보다 느리다는 평가를 받아왔습니다.

```text
Application Start
       ↓
Class Loading
       ↓
Initialization
       ↓
JIT
       ↓
Ready
```

장시간 실행되는 Server에서는 큰 문제가 아닐 수 있습니다.

하지만 Cloud-native 환경에서는 상황이 달라집니다.

```text
Container Start

Serverless

Autoscaling

Short-lived Process
```

새 Instance가 빠르게 시작될수록 Scaling에도 유리합니다.

그래서 최근 JVM에서는 AOT 관련 기술이나 Class Loading 최적화처럼 **Startup을 개선하기 위한 작업**도 계속 진행되고 있습니다.

---

### Cloud-native 시대에는 Startup도 중요하다

예를 들어 Kubernetes에서 Traffic이 증가해 Pod가 Scale Out된다고 가정할 수 있습니다.

```text
Traffic 증가
    ↓
New Pod 생성
    ↓
JVM Start
    ↓
Spring Boot Start
    ↓
Readiness
    ↓
Traffic 처리
```

Startup이 20초 걸리는 Application과 3초 걸리는 Application은 Scale-out 반응 속도에서 차이가 발생할 수 있습니다.

```text
Startup Time
     ↓
Autoscaling Response
     ↓
Cloud-native Performance
```

Java Runtime의 Startup 개선이 Backend 운영에도 직접적으로 연결되는 이유입니다.

---

### Security 개선

Java 24에서는 Security 관련 Platform 정리도 계속됐습니다.

오래된 Security 기능이나 사용되지 않는 구조를 제거하고 현대적인 Cryptography API를 추가하는 방향입니다.

Java 같은 기업용 Runtime에서는 새로운 기능 추가만큼 **오래된 기능을 안전하게 정리하는 것**도 중요합니다.

```text
Platform Evolution

새로운 API 추가
      +
Legacy 제거
      +
Security 강화
```

수십 년간 유지된 Platform일수록 이런 작업이 장기적인 유지보수성과 보안에 영향을 줍니다.

---

### Concurrency 역시 계속 발전한다

Java의 최근 변화에서 빼놓을 수 없는 영역이 **Concurrency**입니다.

Java 21에서는 Virtual Thread가 정식 기능으로 들어왔습니다.

```text
Platform Thread
       ↓
Virtual Thread
```

그리고 Java는 그 이후에도 Structured Concurrency, Scoped Values 같은 새로운 Programming Model을 계속 발전시키고 있습니다.

```text
Modern Java Concurrency

├─ Virtual Threads
├─ Structured Concurrency
└─ Scoped Values
```

단순히 Thread를 가볍게 만드는 것에서 끝나는 것이 아니라 **Concurrent Application을 어떻게 구조적으로 작성할 것인지**까지 개선하려는 방향입니다.

---

### Structured Concurrency

일반적인 Backend Request에서 여러 작업을 동시에 실행한다고 가정해보겠습니다.

```text
Request
  │
  ├─ User API
  ├─ Order API
  └─ Payment API
```

각각 별도의 Future나 Thread로 관리하면 Error와 Cancellation 처리가 복잡해질 수 있습니다.

```text
Task A Success

Task B Failure

Task C Running

→ 어떻게 정리할 것인가?
```

Structured Concurrency는 이런 Child Task를 하나의 Scope로 관리하려는 접근입니다.

```text
Request Scope
     │
     ├─ Task A
     ├─ Task B
     └─ Task C
          ↓
    하나의 Lifecycle
```

Modern Java Backend의 중요한 방향 중 하나입니다.

---

### Spring Boot와 Java Version

기업 Backend에서는 Java 자체보다 Spring Boot와 함께 사용하는 경우가 많습니다.

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

따라서 새로운 Java Version을 도입하려면 Spring과 주변 Library의 Compatibility까지 확인해야 합니다.

```text
Java Upgrade

├─ Spring Boot
├─ Gradle / Maven
├─ JDBC Driver
├─ ORM
├─ Monitoring Agent
└─ Third-party Library
```

JDK가 Released 됐다고 Production Application을 바로 Upgrade하는 것은 일반적인 운영 전략이 아닙니다.

---

### Java 24는 LTS가 아니다

Java 24를 실무에서 판단할 때 가장 중요한 부분입니다.

```text
Java 21

LTS


Java 22

Feature Release


Java 23

Feature Release


Java 24

Feature Release


Java 25

LTS
```

Java 24는 장기 운영을 위한 LTS Release가 아니었습니다.

기업 환경에서는 보통 Java 21 같은 LTS를 기준으로 Production을 운영하는 경우가 많습니다.

```text
Production
    ↓
Java 21 LTS
```

Java 24는 새로운 기능과 Runtime 변화를 확인하기 위한 환경에서 사용할 수 있습니다.

```text
Development

Testing

Benchmark

Compatibility Test
```

---

### 무조건 최신 JDK가 좋은 것은 아니다

Backend Platform에서는 최신 기능보다 안정성과 Support 기간이 더 중요할 수 있습니다.

```text
최신 Feature
      vs
Long-term Stability
```

예를 들어 금융, 공공, 대규모 Enterprise Application에서는 Runtime을 6개월마다 Upgrade하기 어려울 수 있습니다.

```text
Runtime Upgrade

Compatibility Test
Migration
Performance Test
Deployment
Monitoring
```

따라서 Feature Release마다 Production을 따라가는 것보다는 LTS 간 Migration 전략을 사용하는 것이 일반적입니다.

---

### 현실적인 운영 전략

Java 21을 사용하고 있는 기업이라면 다음과 같은 방식이 현실적일 수 있습니다.

```text
Production

Java 21 LTS
     │
     ├─ Java 22 변화 확인
     ├─ Java 23 변화 확인
     ├─ Java 24 변화 확인
     │
     ↓
Java 25 LTS Migration 검토
```

중간 Release를 무시하는 것이 아니라 **다음 LTS에 들어올 기능을 미리 검증하는 용도**로 보는 것입니다.

---

### 개발 환경에서는 Java 24를 테스트할 가치가 있다

Production은 Java 21을 유지하더라도 개발팀은 새로운 JDK에서 Application이 정상적으로 동작하는지 확인할 수 있습니다.

```text
CI Matrix

Java 21
   +
Java 24
```

이를 통해 향후 Upgrade에서 발생할 수 있는 문제를 미리 확인할 수 있습니다.

```text
Deprecated API

Library Compatibility

Compiler Warning

Build Tool Compatibility

Runtime Behavior
```

LTS Migration 시점에 모든 문제를 한 번에 해결하는 것보다 부담을 줄일 수 있습니다.

---

### Java의 변화 속도는 생각보다 빠르다

Java는 오래된 Enterprise Language라는 이미지 때문에 변화가 느리다고 생각하기 쉽습니다.

하지만 현재 Release Cycle을 보면 상당히 빠릅니다.

```text
6개월마다

JDK Release
```

그리고 매 Release마다 다음 영역이 계속 개선됩니다.

```text
Java Platform

├─ Language
├─ JVM
├─ GC
├─ Concurrency
├─ Security
├─ API
└─ Tooling
```

기존 Compatibility를 유지하면서 Platform을 점진적으로 현대화하는 방식입니다.

---

### Java가 오래 살아남은 이유

Java의 중요한 특징 중 하나는 **Backward Compatibility를 유지하면서도 Platform을 계속 교체하고 있다는 점**입니다.

```text
Legacy Application
       +
Modern JVM
       +
New Language Feature
```

오래된 Java Code도 비교적 안정적으로 유지하면서 새로운 Application에서는 Records, Pattern Matching, Virtual Threads 같은 기능을 사용할 수 있습니다.

```text
Old Java Style

class + getter + setter


Modern Java

record
pattern matching
sealed class
virtual thread
```

같은 언어 안에서도 Programming Model이 계속 발전하고 있습니다.

---

### Backend 개발자가 봐야 할 부분

Java Backend 개발자에게 중요한 것은 JEP 24개를 모두 암기하는 것이 아닙니다.

변화의 방향을 이해하는 것이 더 중요합니다.

```text
Modern Java

Language

→ Boilerplate 감소


Concurrency

→ Virtual Thread / Structured Concurrency


Runtime

→ Memory / Startup / GC 개선


Security

→ Legacy 제거 / Crypto 강화
```

이 변화들이 결국 Spring Boot 같은 Framework 안으로 흡수됩니다.

---

### Java → Spring으로 내려오는 과정

Java Platform에서 새로운 기능이 등장한다고 Spring Application에서 바로 사용하는 것은 아닙니다.

보통 다음 과정을 거칩니다.

```text
JDK Feature
    ↓
Stable
    ↓
Framework Support
    ↓
Library Ecosystem Support
    ↓
Production Adoption
```

Virtual Thread가 대표적인 사례입니다.

```text
Java
 ↓
Virtual Thread
 ↓
Spring Boot 지원
 ↓
Application 적용
```

따라서 Feature Release를 추적하면 몇 년 뒤 Spring Backend 개발 방식이 어떻게 변할지도 미리 볼 수 있습니다.

---

### Java 25 LTS를 준비하는 Release

Java 24의 또 다른 의미는 **다음 LTS인 Java 25 직전 Feature Release**라는 점입니다.

```text
Java 21 LTS
      ↓
Java 22
      ↓
Java 23
      ↓
Java 24
      ↓
Java 25 LTS
```

Java 22~24에서 실험되고 발전한 기능들이 이후 LTS 시대의 Java 개발 경험으로 이어질 수 있습니다.

기업 개발자에게 Java 24는 단순히 지나가는 Version이라기보다 **다음 LTS의 방향을 확인할 수 있는 Release**에 가깝습니다.

---

### 실무 영향

Spring 기반 Production 서비스가 Java 21 LTS에서 안정적으로 운영되고 있다면 단순히 Java 24가 나왔다는 이유로 즉시 Migration할 필요는 없었습니다.

현실적인 전략은 다음과 같습니다.

```text
Production

Java 21 LTS 유지


Development / CI

Java 24 Compatibility Test


새로운 기능

PoC / Benchmark


향후

Java 25 LTS Migration 검토
```

이 방식이면 운영 안정성을 유지하면서도 Java Platform의 변화를 놓치지 않을 수 있습니다.

특히 다음 요소를 미리 확인할 수 있습니다.

```text
Pattern Matching

Constructor 변화

Concurrency

JVM Optimization

GC

Startup

Security
```

결국 Java 24는,

> **Java가 6개월 Release Cycle을 안정적으로 유지하면서 Language와 JVM을 동시에 빠르게 현대화하고 있음을 보여주는 Release**

라고 볼 수 있습니다.

기업 Backend에서는 최신 Feature Release를 무조건 Production에 적용하기보다 **LTS를 운영 기준으로 유지하면서 중간 Release를 다음 LTS를 준비하기 위한 검증 단계로 활용하는 전략**으로 가야할것으로 보입니다.

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

독자의 메모