본 문서는 루비(Ruby)의 전역 인터프리터 잠금(GVL: Global Interpreter Lock)의 역할, 스레드 안전성과의 관계, 그리고 GVL 제거 논의의 복잡성을 탐구합니다. 전통적으로 루비 온 레일즈(Ruby on Rails) 애플리케이션이 대부분 IO 바운드(IO-bound)이므로 GVL이 큰 문제가 아니라는 인식이 있었으나, 저자는 이에 이의를 제기하며 멀티코어 활용을 위해 `fork(2)` 시스템 호출이 필요한 현 상황을 지적합니다. 일부에서는 GVL의 단순 제거를 주장하지만, 본 글은 이것이 생각보다 간단하지 않음을 다양한 관점에서 분석합니다.
GVL은 사용자 코드의 일반적인 레이스 컨디션이 아닌 루비 VM 자체를 보호합니다. 예시 코드를 통해 GVL 하에서도 레이스 컨디션이 발생할 수 있으나, MRI에서는 C로 구현된 메서드 호출 시 GVL 보호로 사실상 원자적 작동을 보장합니다. GVL이 없는 JRuby/TruffleRuby에서는 동일 코드가 충돌할 수 있습니다. GVL 단순 제거는 C 기반 MRI의 메모리 비안정성을 유발하며, 객체별 원자적 카운터나 잠금 도입은 C 코드 전반의 수정, 메모리/성능 오버헤드, 그리고 루비 예외 처리 방식과의 복잡한 통합을 수반합니다. 저자는 GVL 제거의 필요성에 회의적입니다. 루비의 주 사용처(웹)와 CoW 효율성(GC 방식 덕분)을 고려할 때, GVL 제거의 장점(메모리 절감 등)이 파이썬보다 적을 수 있으며, 단일 스레드 성능 저하 위험과 CoW 효율 저해 가능성이 있습니다. GVL 경쟁 문제는 인정하지만, 제거보다 스레드 스케줄러 개선이나 GVL 해제 상태에서의 C API 활용 범위 확장이 더 현실적이고 단기적인 해결책이라고 제안합니다.
결론적으로 저자는 GVL 제거가 가져올 잠재적 단일 스레드 성능 저하와 구현의 복잡성에 비해 얻을 수 있는 이점이 크지 않다고 판단하며, 현재로서는 GVL 제거에 반대하는 입장입니다. 대신 스레드 스케줄러 개선, GVL 해제 영역 확장 등 보다 현실적이고 효과적인 대안을 통해 루비의 동시성 문제를 해결해 나갈 것을 제안합니다. 루비의 미래 방향은 Matz와 커뮤니티의 결정에 달려 있지만, 현재는 Ractor 제안이 수용되는 등 다른 방향으로 나아가고 있음을 언급하며 글을 마무리합니다.