GVL이란 무엇이며 Ruby에서 동시성은 어떻게 동작하나요?

Question

Accepted Answer

MRI Ruby의 **GVL**(Global VM Lock, 이전 GIL)은 **한 번에 하나의 스레드만 Ruby 코드를 실행**하도록 허용합니다 — 따라서 스레드는 진정한 CPU 병렬성을 제공하지 않습니다. 하지만 GVL은 **I/O 동안 해제**되므로, 스레드는 I/O 바운드 작업에는 *도움이 됩니다*. CPU 병렬성을 위해서는 여러 프로세스를 사용합니다. 이는 Python의 GIL 상황을 반영합니다.

## GVL: 한 번에 하나의 스레드가 Ruby 코드 실행

```text
MRI(표준 Ruby)에는 GLOBAL VM LOCK이 있음:
  → 어떤 순간에도 하나의 스레드만 Ruby 코드 실행 (스레드로부터 CPU 병렬성 없음)
  → 하지만 GVL은 블로킹 I/O(네트워크, 파일, DB) 동안 해제됨
따라서: 스레드는 I/O 바운드 작업에는 도움이 되지만, CPU 바운드에는 아님.
```

## 스레드 — I/O 바운드 동시성에 좋음

```ruby
# ✅ I/O 바운드 — 스레드가 대기를 중첩 (I/O 동안 GVL 해제) → 실질적 이점
threads = urls.map do |url|
  Thread.new { fetch(url) }      # 하나가 네트워크를 기다리는 동안 다른 것이 진행
end
threads.each(&:join)

# ❌ CPU 바운드 — 스레드가 이를 가속하지 않음 (GVL이 Ruby 실행을 직렬화)
threads = data.map { |d| Thread.new { heavy_computation(d) } }  # 속도 향상 없음
```

스레드는 I/O 바운드 작업(네트워크, 파일, DB)에 도움이 됩니다. 대기 동안 GVL이 해제되어 다른 스레드가 실행되기 때문입니다. CPU 바운드 작업은 가속하지 **못합니다**(GVL이 Ruby 실행을 직렬화).

## 프로세스 — CPU 바운드 병렬성용

```ruby
# ✅ CPU 바운드 병렬성 → 여러 프로세스 사용 (각각 자체 GVL 보유)
# fork, 또는 Parallel 같은 gem:
results = Parallel.map(data, in_processes: 4) { |d| heavy_computation(d) }
# → 4개의 별도 프로세스, 코어 전반에 걸친 진정한 병렬성
```

CPU 바운드 병렬성을 위해서는 **여러 프로세스**(각각 자체 GVL/인터프리터 보유)를 사용합니다 — `fork`, `parallel` gem, 또는 여러 워커 프로세스 실행(Puma 같은 Rails 서버가 확장하는 방식).

## 현대적 동시성 도구

```text
✓ Ractor (Ruby 3) — Ruby를 병렬로 실행할 수 있는 액터 모델 병렬성 (Ractor마다 공유 GVL 없음)
  — 실험적, 진정한 병렬성
✓ Fiber / async gem — 높은 I/O 작업을 위한 경량 협력적 동시성
✓ 백그라운드 잡 (Sidekiq) — 별도 워커 프로세스로 작업을 떠넘김
참고: 대체 Ruby 구현(JRuby, TruffleRuby)에는 GVL이 없음 → 진정한 스레드 병렬성
```

## 왜 중요한가

GVL과 Ruby 동시성을 이해하는 것은 — Python의 GIL 상황과 매우 비슷하게 — 성능 좋은 Ruby 애플리케이션을 구축하는 데 중요하고 빈번히 오해되는 지식입니다.

핵심 통찰은 MRI Ruby의 **GVL이 한 번에 하나의 스레드만 Ruby 코드를 실행하도록 허용**하므로, 스레드가 CPU 병렬성을 제공하지 *않는다*는 것 — 흔한 혼란 지점입니다.

결정적으로, GVL은 **I/O 동안 해제**되며, 이는 올바른 동시성 접근이 작업 부하에 따라 다름을 의미합니다: **스레드는 I/O 바운드 작업에 잘 동작**(네트워크 호출, 파일/데이터베이스 접근 — 대기 동안 GVL이 해제되어 스레드가 중첩됨)하지만, **CPU 바운드 병렬성은 여러 프로세스가 필요**(각각 자체 GVL 보유, 코어 전반에 진정한 병렬성 달성 — `fork`, `parallel` gem, 또는 여러 워커 프로세스를 통해, 이것이 Rails 서버가 확장하는 방식)합니다.

GVL을 오해하면 비효율적인 동시성 코드(예: 속도 향상을 기대하며 CPU 무거운 작업에 스레드 사용)로 이어집니다.

I/O 대 CPU 결정(I/O 동시성에는 스레드, CPU 병렬성에는 프로세스), 현대적 도구(실험적 진정한 병렬성을 위한 Ractor, 높은 I/O 협력적 동시성을 위한 Fiber/async, Sidekiq 같은 백그라운드 잡 프로세서), 그리고 대체 구현(JRuby, TruffleRuby)에 GVL이 없다는 것을 아는 것은 실제로 성능을 내는 동시성 Ruby를 작성하는 데 중요합니다.

동시성은 흔한 요구이고 GVL이 올바른 접근을 근본적으로 형성하므로, 이를 이해하는 것 — 스레드가 왜 CPU 작업을 병렬화하지 않는지, I/O에는 도움이 된다는 것, CPU 병렬성에는 프로세스가 필요하다는 것 — 은 빈번한 실수를 방지하는 중요한 시니어 수준 지식이자, Ruby의 동시성 모델과 GVL 제약에 대한 이해를 반영하는 흔한 면접 주제입니다.