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

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

## Backend — Ruby 3.4 출시

Ruby가 **12월 25일 Ruby 3.4**를 정식 출시했습니다.

이번 버전에서는 **Prism이 기본 Parser로 전환**됐고, YJIT 성능 개선, Modular GC 도입, 새로운 `it` Block Parameter 등 Runtime과 Language 전반에 걸친 변화가 포함됐습니다.

특히 Ruby 3.4는 단순히 새로운 Syntax를 추가하는 Release라기보다 **Parser, JIT, GC 같은 Ruby Runtime 내부 구조를 현대화하는 작업이 계속되고 있다는 점**에서 의미가 있었습니다.

[Ruby - Ruby 3.4.0 Released](https://www.ruby-lang.org/en/news/2024/12/25/ruby-3-4-0-released/)

---

### Ruby의 변화는 언어 문법만이 아니다

Programming Language의 Version Update라고 하면 일반적으로 새로운 Syntax나 API를 먼저 떠올립니다.

```text
Language Update

├─ 새로운 Syntax
├─ 새로운 API
└─ 새로운 Standard Library
```

하지만 실제 Language 성능과 개발 경험에는 Runtime 내부 구조도 큰 영향을 줍니다.

```text
Ruby

Source Code
    ↓
Parser
    ↓
VM / JIT
    ↓
Garbage Collector
    ↓
Application
```

Ruby 3.4에서는 이 여러 계층이 동시에 개선됐습니다.

---

### Prism이 기본 Parser로 전환

Ruby 3.4에서 가장 상징적인 변화 중 하나는 **Prism이 기본 Parser가 됐다는 점**입니다.

기존 Ruby에서는 오랫동안 `parse.y` 기반 Parser가 사용됐습니다.

```text
기존 Ruby

Ruby Source
    ↓
parse.y
    ↓
AST
```

Ruby 3.4에서는 기본 구조가 다음과 같이 바뀌었습니다.

```text
Ruby 3.4

Ruby Source
    ↓
Prism
    ↓
AST
```

Ruby의 Source Code를 해석하는 핵심 Infrastructure 자체가 교체된 것입니다.

---

### Parser가 왜 중요한가

Parser는 개발자가 작성한 Source Code를 Runtime이 이해할 수 있는 구조로 변환하는 역할을 합니다.

예를 들어 다음 Ruby Code가 있다고 가정할 수 있습니다.

```ruby
user = User.find(1)

puts user.name
```

Parser는 이 코드를 읽어 내부적으로 처리할 수 있는 Syntax Tree로 변환합니다.

```text
Ruby Code
    ↓
Parser
    ↓
Syntax Tree
    ↓
Ruby Runtime
```

따라서 Parser는 Ruby Language Toolchain의 가장 기본적인 Component 중 하나입니다.

---

### Prism의 목적

Prism은 Ruby를 위한 새로운 Parser Infrastructure입니다.

중요한 점은 단순히 Ruby Interpreter 내부에서 사용하는 Parser 하나를 교체하는 것이 아니라 **Ruby Tooling 전체가 공통으로 사용할 수 있는 Parser 기반을 만드는 방향**이라는 점입니다.

```text
Ruby Source
    ↓
Prism
    ↓
 ┌──────────┬──────────┬──────────┐
Ruby       IDE        Linter     Tooling
```

Parser가 일관된 구조를 제공하면 여러 개발 도구가 같은 Syntax 정보를 공유하기 쉬워집니다.

---

### Tooling과 Parser

현대적인 개발 환경에서는 Parser가 Runtime 외에도 많은 곳에서 사용됩니다.

```text
Parser

├─ IDE
├─ Linter
├─ Formatter
├─ Static Analyzer
├─ Refactoring Tool
└─ Code Intelligence
```

예를 들어 IDE가 다음 작업을 수행하려면 Source Code 구조를 정확하게 이해해야 합니다.

```text
Go to Definition

Rename Symbol

Code Completion

Find References

Syntax Highlighting
```

따라서 새로운 Parser Infrastructure는 장기적으로 Ruby Developer Tooling 개선에도 영향을 줄 수 있습니다.

---

### YJIT

Ruby는 동적 Language이기 때문에 Runtime Performance가 오랫동안 중요한 주제였습니다.

Ruby에는 이러한 성능을 개선하기 위한 **YJIT**가 존재합니다.

```text
Ruby Code
    ↓
Ruby VM
    ↓
YJIT
    ↓
Machine Code
```

JIT는 자주 실행되는 Code를 Runtime에서 Native Machine Code로 변환해 실행 성능을 높이는 방식입니다.

---

### Interpreter와 JIT

일반적인 Interpreter 방식에서는 Ruby VM이 Code를 실행합니다.

```text
Ruby Code
    ↓
Interpreter
    ↓
Execution
```

JIT가 활성화되면 반복적으로 실행되는 Code 일부를 Machine Code로 변환할 수 있습니다.

```text
Ruby Code
    ↓
Hot Code 탐지
    ↓
JIT Compile
    ↓
Machine Code
    ↓
Execution
```

특히 Web Application처럼 동일한 Code Path가 반복적으로 실행되는 환경에서는 JIT Optimization의 이점을 얻을 수 있습니다.

---

### Rails와 YJIT

Ruby를 사용하는 대표적인 Backend Framework가 Rails입니다.

```text
Client
  ↓
Rails
  ↓
Ruby
  ↓
YJIT
```

Rails Application에서는 Request마다 Controller, Service, ORM 등 많은 Ruby Code가 반복적으로 실행됩니다.

따라서 Ruby Runtime과 YJIT의 성능 개선은 장기적으로 Rails Application Performance에도 영향을 줄 수 있습니다.

```text
Ruby Runtime 개선
        ↓
YJIT 개선
        ↓
Rails Execution 효율 개선
```

Application Code를 변경하지 않아도 Runtime Upgrade만으로 일부 성능 향상을 얻을 가능성이 생기는 것입니다.

---

### Modular GC

Ruby 3.4에서는 **Modular Garbage Collector** 관련 구조도 도입됐습니다.

Garbage Collector는 더 이상 사용하지 않는 Object의 Memory를 자동으로 회수합니다.

```text
Object 생성
   ↓
사용
   ↓
더 이상 참조되지 않음
   ↓
Garbage Collector
   ↓
Memory 회수
```

Ruby처럼 Memory Management를 Runtime이 담당하는 Language에서는 GC가 Performance에 상당한 영향을 줄 수 있습니다.

---

### GC가 중요한 이유

Backend Application에서는 매우 많은 Object가 생성되고 제거됩니다.

```text
HTTP Request
    ↓
Controller
    ↓
Service
    ↓
ActiveRecord
    ↓
Response

각 단계에서 Object 생성
```

Traffic이 증가하면 Object Allocation도 증가합니다.

```text
Request 증가
    ↓
Object Allocation 증가
    ↓
GC Work 증가
```

GC가 비효율적이면 CPU 사용량이나 Pause Time에 영향을 줄 수 있습니다.

---

### Modular GC의 방향

Modular GC는 Ruby Runtime과 Garbage Collector 구현 사이의 결합을 줄이는 방향입니다.

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

```text
기존

Ruby Runtime
     ↓
내부 GC 구현


새로운 방향

Ruby Runtime
     ↓
GC Interface
     ↓
GC Implementation
```

즉 Garbage Collector를 Runtime의 고정된 일부로만 보는 것이 아니라 보다 독립적으로 발전시킬 수 있는 구조를 만드는 것입니다.

---

### Runtime Architecture의 변화

이러한 구조가 중요한 이유는 향후 GC 실험과 최적화를 더욱 유연하게 할 수 있기 때문입니다.

```text
Ruby Runtime

├─ Parser
├─ VM
├─ JIT
└─ GC Interface
```

Ruby Runtime 내부 Component들이 점점 명확하게 분리되고 현대화되고 있습니다.

---

### 새로운 `it` Block Parameter

Ruby 3.4에서는 Language Syntax 측면에서도 새로운 기능이 추가됐습니다.

대표적인 것이 **`it` Block Parameter**입니다.

기존에는 짧은 Block에서도 Parameter를 명시해야 했습니다.

```ruby
users.map { |user| user.name }
```

Ruby 3.4에서는 특정 상황에서 `it`을 사용할 수 있습니다.

```ruby
users.map { it.name }
```

단순한 Block에서는 Parameter 선언을 생략할 수 있어 Code를 조금 더 간결하게 작성할 수 있습니다.

---

### 기존 `_1`과의 관계

Ruby에는 이미 Numbered Parameter가 존재했습니다.

```ruby
users.map { _1.name }
```

`it`은 짧은 Block에서 조금 더 읽기 쉬운 표현을 제공하려는 방향입니다.

```text
기존

{ |user| user.name }


Numbered Parameter

{ _1.name }


Ruby 3.4

{ it.name }
```

작은 기능이지만 Ruby가 오랫동안 중요하게 생각해온 **간결하고 읽기 쉬운 Syntax** 방향을 보여줍니다.

---

### 왜 중요한가

Ruby 3.4의 특징을 보면 서로 다른 영역처럼 보입니다.

```text
Prism

YJIT

Modular GC

it
```

하지만 전체적으로 보면 공통적인 방향이 있습니다.

```text
Ruby Modernization

├─ Parser 현대화
├─ JIT 성능 개선
├─ GC Architecture 개선
├─ Language Syntax 개선
└─ Tooling 기반 강화
```

Ruby가 단순히 Language Feature를 추가하는 것이 아니라 **Runtime Infrastructure 전체를 장기적으로 개선하고 있는 것**입니다.

---

### Ruby Performance의 변화

Ruby는 과거부터 Developer Productivity가 높은 Language로 평가받았지만 Runtime Performance는 자주 비교 대상이 됐습니다.

```text
Ruby

Developer Productivity ↑

Runtime Performance
→ 지속적인 개선 대상
```

최근 Ruby는 YJIT 같은 기술을 통해 이 부분을 적극적으로 개선하고 있습니다.

```text
Ruby Performance

Interpreter
    ↓
YJIT
    ↓
Runtime Optimization
```

즉 Ruby의 개발 경험을 유지하면서 실행 성능을 개선하려는 방향입니다.

---

### Rails Application에는 어떤 영향을 주는가

Rails 개발자가 Ruby 3.4로 Upgrade한다고 해서 Application Architecture가 갑자기 바뀌는 것은 아닙니다.

```text
Rails

Controller
Service
ActiveRecord
View
```

이 구조 자체는 그대로 유지됩니다.

하지만 아래 계층이 바뀝니다.

```text
Rails Application
       ↓
Ruby 3.4
       ↓
Prism
YJIT
GC
VM
```

즉 Application Code보다 **Runtime Layer가 개선되는 Release**에 가깝습니다.

---

### Framework와 Runtime의 관계

Rails는 Ruby Runtime 위에서 실행됩니다.

```text
Rails
  ↓
Ruby
  ↓
Runtime
  ↓
Operating System
```

따라서 Runtime의 작은 성능 개선도 대규모 Rails Application에서는 의미가 있을 수 있습니다.

예를 들어 다음과 같은 요소입니다.

```text
Startup Time

Request Throughput

Memory Usage

GC Overhead

CPU Usage
```

Runtime Optimization은 Infrastructure Cost와도 연결될 수 있습니다.

---

### Tooling 측면에서도 중요한 Prism

Prism 도입은 Performance만의 이야기가 아닙니다.

Ruby Source를 분석하는 Tool들이 공통 Parser Infrastructure를 사용할 수 있다면 Developer Experience도 개선될 가능성이 있습니다.

```text
Ruby Source
    ↓
Prism
    ↓
 ┌─────────┬─────────┬─────────┐
 IDE      Linter    Formatter  Analysis
```

향후 Ruby Language Server나 Static Analysis Tool, Refactoring Tool 등에서도 활용할 수 있는 기반이 됩니다.

---

### Compiler / Runtime 경쟁

현대 Programming Language는 Syntax만으로 경쟁하지 않습니다.

```text
Language Platform

├─ Compiler
├─ Parser
├─ Runtime
├─ JIT
├─ GC
├─ Tooling
└─ Package Ecosystem
```

Java에는 JVM과 JIT, GC가 있고,

```text
Java
 ↓
JVM
 ↓
JIT / GC
```

.NET에는 CLR과 JIT, GC가 있습니다.

```text
C#
 ↓
.NET Runtime
 ↓
JIT / GC
```

Ruby 역시 Parser, VM, YJIT, GC 같은 Runtime Infrastructure를 지속적으로 개선하면서 Language Platform 전체를 현대화하고 있습니다.

---

### Backend 관점에서의 의미

Backend Developer가 Framework만 보는 것보다 Runtime까지 이해해야 하는 이유도 여기에 있습니다.

```text
Rails
  ↓
Ruby
  ↓
YJIT
  ↓
GC
  ↓
OS
```

Application Performance 문제가 발생했을 때 원인이 항상 Business Logic에 있는 것은 아닙니다.

다음 요소도 영향을 줄 수 있습니다.

- Runtime Version
- GC
- JIT
- Memory Allocation
- Dependency
- Database
- Network

따라서 Production Application에서는 Runtime Upgrade도 중요한 Performance Optimization 전략이 될 수 있습니다.

---

### Ruby의 현대화

Ruby 3.x 시대의 방향을 단순화하면 다음과 같습니다.

```text
Ruby

Language Productivity
        +
Runtime Performance
        +
Modern Tooling
```

기존 Ruby의 강점이었던 개발 생산성과 표현력을 유지하면서 Runtime과 Tooling을 현대화하려는 흐름입니다.

Ruby 3.4는 이러한 변화가 Language Syntax 수준이 아니라 Runtime 내부까지 깊게 진행되고 있음을 보여줬습니다.

---

### 실무 영향

Rails Application 개발자가 Ruby 3.4 출시 직후 반드시 Application Code를 크게 변경해야 했던 것은 아닙니다.

오히려 중요한 변화는 아래 Runtime Layer에 있었습니다.

```text
Rails Application
        ↓
Ruby 3.4

├─ Prism
├─ YJIT
├─ Modular GC
└─ Runtime Improvement
```

단기적으로는 Rails와 Gem Compatibility를 확인하며 Upgrade를 검토해야 했고,

장기적으로는 이러한 변화가 다음 영역의 개선 기반이 됩니다.

```text
Runtime Performance

Startup Performance

Memory Efficiency

Developer Tooling

Static Analysis

IDE Integration
```

결국 Ruby 3.4는,

> **Ruby가 언어 기능뿐 아니라 Parser, JIT, GC 같은 Runtime Infrastructure 자체를 현대화하며 장기적인 성능과 Tooling 기반을 강화하고 있음을 보여주는 Release**

라고 볼 수 있습니다.


2024년 12월 27일(금) 주간 개발트렌드

독자의 메모