지난 글들
752개의 글이 있습니다
SDB: GVL 없이 효율적인 Ruby 스택 스캐닝
[EN] SDB: Efficient Ruby Stack Scanning Without the GVL / Mike Yang @yfractal
- SDB는 GVL(Global VM Lock) 없이 Ruby 스택을 스캔하여 기존 프로파일러의 성능 저하 문제를 해결하고, 1ms의 낮은 샘플링 간격과 3% 미만의 CPU 사용률로 고성능을 제공합니다.
- 기존 계측(instrumentation) 방식의 사각지대와 높은 오버헤드를 극복하기 위해, SDB는 GVL 없이 64비트 메모리 읽기/쓰기의 원자성을 활용하여 스택 데이터를 안전하게 수집합니다.
- SDB는 지연 및 오프라인 분석, 캐싱된 심볼화, 고정 객체 의존성을 통해 프로덕션 환경에 미치는 영향을 최소화하며, 상시 활성화 가능한 기본 관측성 솔루션으로서의 잠재력을 가집니다.
RubyKaigi
2025년 05월 27일
Ruby Class#new 고속화: 새로운 접근 방식
[JA] Speeding up Class#new / Aaron Patterson @tenderlove
- Ruby의 Class#new 메서드를 C에서 Ruby로 재구현하고 인라인화를 통해 객체 할당 성능을 획기적으로 개선할 수 있습니다.
- 메서드 호출 시 발생하는 언어 간 호출 규약 전환 비용과 인라인 캐시의 효율이 전체 애플리케이션 속도에 큰 영향을 미칩니다.
- 새로운 프리미티브와 컴파일러 변경을 통해 Class#new의 인라인화를 달성했으며, 인자 유형 및 개수에 따라 최대 6.2배의 속도 향상을 확인했습니다.
RubyKaigi
2025년 05월 27일
Ruby C 확장 코드에서 Write Barrier 자동 삽입을 위한 정적 분석 도구 WBCheck 개발
[JA] Write you a Barrier - Automatic Insertion of Write Barriers / @duerst @joetake
- WBCheck는 Ruby C 확장 코드에 정적 분석을 수행하여 Write Barrier가 필요한 참조 변경 지점을 감지하고 자동 삽입하는 도구입니다.
- Ruby의 세대별 가비지 컬렉션(GC) 효율성을 높이는 Write Barrier의 중요성과 C 확장 내 TypedData 객체 사용 시 완벽한 Write Barrier 삽입의 필요성을 강조합니다.
- Tree-sitter 기반의 구문 분석과 2단계 탐색 방식을 통해 C 코드 내 변수 및 구조체 필드의 VALUE 타입 참조 변경을 추적합니다.
RubyKaigi
2025년 05월 27일
QuickJS RB: Ruby에서 JavaScript를 실행하는 여정 및 실제 활용 사례
[EN] Running JavaScript within Ruby / Kengo Hamasaki @hmsk
- QuickJS RB는 Ruby에서 JavaScript 코드를 실행하는 Gem으로, FaaS 기반 시스템을 대체하여 비용 절감 및 성능 향상을 성공적으로 달성했습니다.
- C 언어 기반 QuickJS 엔진을 Ruby 바인딩으로 래핑하여 샌드박싱, 국제화 지원, Ruby 함수 호출 등 실제 서비스에 필요한 기능을 구현했습니다.
- Ruby의 네이티브 확장 및 패턴 매칭을 활용한 점진적 C 코드 개발과, 백엔드-프론트엔드 단일 JavaScript 코드 재사용의 이점을 발견했습니다.
RubyKaigi
2025년 05월 27일
TCP 소켓을 행복하게 만들기
[JA] Making TCPSocket.new "Happy"! / Misaki Shioi @coe401_
- Ruby 3.4에 Happy Eyeballs Version 2 알고리즘이 도입되어 `Socket.tcp` 및 `TCPSocket.new`의 네트워크 연결 효율성이 크게 향상되었습니다.
- 초기 `Socket.tcp` 구현의 상태 관리 복잡성과 `TCPSocket.new`의 `FD_SETSIZE` 한계 문제를 `rb_fd_select` 활용으로 해결하며 견고성을 확보했습니다.
- Happy Eyeballs 도입으로 특정 최악의 시나리오에서 연결 시간이 132배 단축되었으나, 미미한 성능 오버헤드가 관찰되어 필요시 비활성화 기능이 제공됩니다.
RubyKaigi
2025년 05월 27일
루비 문법에서의 개행이란 무엇인가?
[JA] Ruby's Line Breaks / Yuichiro Kaneko @spikeolaf
- 루비에서 개행은 문법적으로 문(statement)이 종료될 수 있는 곳에서 문을 종료시키는 역할을 하지만, 렉서(Lexer)의 상태(lex_state)에 따라 무시되거나 강제로 토큰화되는 복잡한 예외가 존재합니다.
- `lex_state`는 루비 렉서의 핵심적인 부분이면서도 개발자들에게 '혼돈의 문'으로 불릴 만큼 관리 및 이해가 어렵지만, 이를 문법에 통합하여 오토마톤으로 모델링함으로써 동작 원리를 체계적으로 분석할 수 있었습니다.
- 엔드리스 레인지, 익명 인자, 전역 변수 별칭, BEGIN/END 블록 등 특정 구문에서 개행 처리의 예외 사례가 발견되었으며, 향후 파서가 렉서에게 개행 처리 방식을 명시적으로 전달하도록 문법을 확장하는 방향을 제안합니다.
RubyKaigi
2025년 05월 27일
Steep의 타입 가드: 유형 좁히기와 사용자 정의 타입 가드
[JA] Introducing Type Guard to Steep / Takeshi KOMIYA @tk0miya
- Steep 1.10에 TYPE for Union Types가 병합되어 `ActiveSupport`의 `present?`와 같은 메서드 호출을 타입 가드로 활용하여 유형 좁히기가 가능해졌습니다.
- 사용자 정의 타입 가드(User-Defined Type Guards)는 RBS 어노테이션을 통해 개발자가 직접 메서드를 타입 가드로 지정하여 유형을 좁힐 수 있도록 하는 기능으로 현재 개발 중입니다.
- 타입 가드는 코드의 안정성을 높이고 더 정확한 타입 체크를 가능하게 하여 개발 생산성 향상에 기여하며, 조건부 타입 표현 등 고급 활용 사례도 제시되었습니다.
RubyKaigi
2025년 05월 27일
Ruby에서 Linux PFD(Process File Descriptor)를 활용한 고급 프로세스 관리
[EN] Bringing Linux pidfd to Ruby / Maciej Mensfeld @maciejmensfeld
- PID 재사용 및 시그널 경합 등 기존 Ruby 프로세스 관리 방식의 한계를 극복하기 위해 Linux PFD(Process File Descriptor) API의 필요성을 강조합니다.
- FFI를 사용하여 Ruby 애플리케이션에서 Linux PFD API(pidfd_open, pidfd_send_signal, waitid)를 직접 호출하여 안정적인 프로세스 참조, 경합 없는 시그널 전달, 그리고 고급 모니터링 기능을 구현하는 방법을 제시합니다.
- PFD는 특정 엣지 케이스(잦은 프로세스 생성 및 종료, 비직계 자식 프로세스 모니터링)에 유용하지만, 대부분의 장기 실행 프로세스 관리에는 오버킬이며, 향후 실시간 시그널 지원 및 페이로드 처리 기능에 대한 Ruby 개선을 제안합니다.
RubyKaigi
2025년 05월 27일
5만 레코드/초 처리: Ruby와 JRuby 이야기
[EN] 50.000 processed records per second: a CRuby & JRuby story / Cristian Planas @cristian_planas
- Zendesk는 Ruby와 JRuby를 활용하여 초당 5만 건의 레코드를 처리하는 ETL 마이크로서비스를 15년간 성공적으로 운영하며 Ruby의 확장 가능성을 입증했습니다.
- JRuby는 실제 스레드와 Java 라이브러리 접근을 제공하여 과거 Ruby의 GVL 및 메모리 관리 한계를 극복하고 고성능 시스템 구축을 가능하게 했습니다.
- 최신 C Ruby는 YJIT, Ractors, Concurrent Ruby 등 지속적인 성능 및 동시성 개선을 통해 과거의 단점을 해소하고 있으며, 대다수의 기업에게 Ruby는 여전히 생산성 높은 선택지입니다.
RubyKaigi
2025년 05월 27일
Fat Gem과의 이별: 루비 개발의 더 나은 미래를 위한 제안
[JA] Goodbye fat gem 2025 / Sutou Kouhei @ktou
- Fat Gem이 최신 루비 호환성, 취약성 관리, 높은 유지보수 비용 등 다양한 문제를 야기함을 지적하고, 이를 해결하기 위한 자동 빌드 환경 도입을 제안합니다.
- RubyGems의 `requirements` 필드를 활용하여 시스템 의존 라이브러리를 자동 설치하는 `rubygems-requirements-system` 젬을 소개하며 Fat Gem 없는 개발 환경을 구현하는 방안을 제시합니다.
- Fat Gem 제거 시 발생할 수 있는 설치 시간 증가 및 시스템 변경 문제에 대한 해결책을 논의하고, 루비 커뮤니티 내 Fat Gem 도입(휠) 논의라는 상반된 흐름을 공유하며 미래 방향을 모색합니다.
RubyKaigi
2025년 05월 27일
Robocop의 진화: 플러그인, LSP 통합, AST 변화를 통한 미래 지향적 개발
[JA] RuboCop: Modularity and AST Insights / Koichi ITO @koic
- Robocop은 비공식적인 몽키 패치 방식의 플러그인 시스템을 공식적인 LintRoller 기반의 방식으로 전환하여 유지보수성과 확장성을 개선했습니다.
- Ruby LSP와 Robocop 내장 LSP 런타임이 어댑터를 통해 통합되어 코드 재사용성을 높이고 중복 파싱을 줄여 성능 향상을 도모합니다.
- Ruby 3.4 이상 버전에서 Robocop의 기본 파서가 Parser Gem에서 Prism (prism_translation_parser)으로 변경되어 최신 Ruby 문법 지원 및 유지보수성이 강화되었습니다.
RubyKaigi
2025년 05월 27일
Compo 업데이트 및 구현 내용: Ruby 프로젝트의 원 바이너리화
[JA] The Ruby One-Binary Tool, Enhanced with Kompo / ahogappa @ahogappa
- Compo는 Ruby 프로젝트를 단일 실행 파일(원 바이너리)로 만들어 추가 설치 없이 어디서든 빠르게 실행 가능하게 하는 도구입니다.
- 이전 버전의 `require` 오버라이딩 방식은 `autoload` 및 파일 접근 제한 등의 문제로 Rails와 같은 대규모 프로젝트에 적용할 수 없었습니다.
- 가상 파일 시스템(VFS) 구축과 `dlsym`을 활용한 `libc` 함수 랩핑을 통해 `Rails` 프로젝트의 원 바이너리화에 성공했으며, 향후 Gem화 및 크로스 플랫폼 지원을 목표로 합니다.
RubyKaigi
2025년 05월 27일
런타임 코드 자동 리팩토링을 통한 Deprecation 처리 제안
[JA] On-the-fly Suggestions of Rewriting Method Deprecations / Masato Ohba @ohbarye
- RubyDepre Gem은 런타임에 Deprecated 메서드 호출을 감지하고, 정의된 규칙에 따라 사용자 코드를 자동으로 리팩토링하거나 패치 파일을 생성하여 Deprecation 해소를 돕는 도구입니다.
- 이 도구는 Pharo 언어의 DepreWriter에서 영감을 받아 동적 타입 언어의 정적 분석 한계를 극복하고, 개발자의 마이그레이션 부담을 줄이는 것을 목표로 합니다.
- 현재는 테스트 및 로컬 환경 사용을 전제로 하며, 복잡한 케이스 처리, 효율성 개선, 그리고 Ruby 에코시스템 내 통합 방안 모색이 향후 과제입니다.
RubyKaigi
2025년 05월 27일
IRB에서 Ruby 코드 분석: Ripper에서 Prism으로의 전환
[JA] Analyzing Ruby Code in IRB / tomoya ishida @tompng
- IRB는 구문 강조, 자동 들여쓰기, 코드 완성 등 다양한 Ruby 코드 분석 기능을 제공하며, 기존 Ripper::Lexer 기반의 한계를 Prism으로 전환하여 개선하고 있습니다.
- 구문 분석의 정확도와 유지보수성 향상을 위해 Ripper의 토큰 기반 분석에서 Prism의 AST(추상 구문 트리) 기반 분석으로 전환하는 하이브리드 접근 방식이 도입되고 있습니다.
- 코드 종료 판정 및 자동 완성 기능은 Prism의 API를 활용하여 기존의 복잡하고 부정확했던 방식들을 표준화하고, 런타임 정보를 더욱 효과적으로 활용하여 정확도를 높일 계획입니다.
RubyKaigi
2025년 05월 27일
RBS와 Steep 문서화 기능 및 내부 API 개선 방안
[EN] API for docs / Soutaro Matsumoto @soutaro
- Steep은 LSP를 통해 RBS 파일에 정의된 주석 기반의 문서화 기능(호버, 자동 완성, 시그니처 도움말)을 제공합니다.
- 현재 문서화 시스템은 타입 체커와 긴밀히 결합되어 주석 변경 시 불필요한 전체 타입 검사가 발생하며, 이를 해결하기 위해 '인덱스' API 도입이 제안되었습니다.
- 메서드 오버로드 식별의 복잡성을 해결하기 위해 정규화된 메서드 타입을 식별자로 사용하는 방안이 제시되었으며, 이는 시스템 분리와 재활용성을 높일 것으로 기대됩니다.
RubyKaigi
2025년 05월 27일